どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく
必須ではないが用語として便利なのでしばしば話題に上がる
[参考サイト]
Gameつくろー！ デザインパターン習得編
http://marupeke296.com/DP_main.html
サルでもわかる 逆引きデザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html
[参考書籍(Amazonリンク)]
オブジェクト指向における再利用のためのデザインパターン
http://amazon.co.jp/o/ASIN/4797311126/
デザインパターンとともに学ぶオブジェクト指向のこころ
http://amazon.co.jp/o/ASIN/4894716844/
>>1乙
一応デザパタ軽く。
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。
Foo foo = new Foo() とすると foo がインスタンス？
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも
揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね？
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな
ＷＥＢ系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな？
ゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?
今出てるのってそんな話か？
俺には世間話に>>10が適当な横槍入れただけに見えるが
ム板のことか？
やる夫で学ぶデザインパターン
ttp://mojalog.com/cgi/mt/mt-search.cgi?tag=%E3%82%84%E3%82%8B%E5%A4%AB%E3%81%A7%E5%AD%A6%E3%81%B6%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3&blog_id=1
サンプルコードもゲームだしわかりやすくていいと思うが
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ！」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い
ゲーム屋からみれば変な設計なん？
速度でないゴミになりそうな悪寒
まぁ使い過ぎが良くないってのには同意だけど
こんなんじゃ、ゲーム屋って無理？
マならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…
利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど
どうしてもGTAGSがいいの？GTAGSってGNU Tags？Google Tags？
>GTAGSってGNU Tags？Google Tags？
ｶｴﾚw
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。
参考になるサイトでもある？
全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ？
まず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。
まあ、最後はありえねーとしてもｗ
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz
でも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。
グローバルとか、デバイス差の吸収とか必要になったとき困らね
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との２択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな？
俺もー
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。
俺の鳥頭じゃちょっとイメージしにくい・・・
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの？
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。
そーゆーんじゃないのん？
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど
シーン単一保持だと元シーン内のアニメも止める事になるし（※無論それが前提なら無問題だけど）
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。
守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか
きもい、長い
> 守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
> または公開することもできるだろう
もちろん社内で議論はしてるだろう。仕事してるんだから。
それと公開するかどうかは別の話だ。
ここでの話は、企業として技術情報を公開することについてじゃないの？
少なくとも>>72はそういう話でしょう。
それとも>>75は単に多くの日本の開発者を無能扱いしたいだけ？
業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
＞外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
＞まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下（兵隊）の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね
＞あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンｗｗ」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお（＃^ω^）」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏＝3Dキチガイの巣窟。日本語圏＝虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。
Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、８０年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ１０年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。
SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよｗ
ソフトウェアに携わる人間で米コンプレックスを感じない人は
無能あるいは情報弱者だろう
欧州はそれほどとも思わないけどアメリカリードしすぎ
海外はすごいよ。
開発するにしてもニッチな物になればなるほど日本側で
解説してるのが少ない。
結局は翻訳サイトで翻訳しながら自力で学習してる。
日本人の英会話力の低さは別問題だよもう
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ
かぶったス
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数のテクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる
日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか？知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。
＞日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
＞海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
＞ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ（同人）市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○ 絵（とくに３Ｄ）がきれい。
○ 音楽も一般受けする質の高いものが標準。
○ ゲーム中以外のシーン（デモ、オプション設定）が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。
日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い（よくできたものもあるが）。
グローバルな金儲けには関心なく、村市場（コミックマーケット）で満足してしまっている奴が多いんだろうな。
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
Blenderで3Dゲーム作ろうぜ (466)
【初心者】ｽﾚを立てる前にｺｺで質問を【Part24】 (102)
クロックタワーの続編を作るスレ2周目 (671)
2ch版いただきストリート作りませんか？ (859)
クロックタワーの続編を作るスレ2周目 (671)
■ ゲーム製作技術板雑談スレ01 (226)
--log9.info------------------
近藤夏子 (288)
矢井田瞳 Chapter64 (316)
【ベストアルバム】 伊藤由奈 14曲目♪ 【LOVE】 (810)
〜天まで響け〜岩崎宏美−１２． (319)
土屋明子 (628)
【美人シンガー】 竹仲絵里 16 【元mawari】 (490)
綾瀬はるかpart3 (182)
上戸彩の歌唱力を語ろう (612)
浜田麻里☆Part40☆Legenda (739)
★華原朋美・復活祈願＆応援スレッド★Vol.74 (407)
石野田奈津代（いしのだなつよ）vo.11 (860)
池田綾子 Part4 (678)
【父は甲斐バンド】甲斐名都 Part3【甲斐よしひろ】 (665)
【＊】上野洋子 opus 04【yk】 (893)
Cocco Part 141 (913)
きもきもなっつんこと関奈津子は天才 (214)
--log55.com------------------
嫌韓スレで毎日朝から晩までひとり言言ってるバカな高齢無職www 12
【嫌韓ゴキブリニート限定】 日本が大好きな髭奥様集合 60 【Nippon】
バカウヨってすぐ発狂するから煽り甲斐があるよねwww★1
今日も親韓、ネトウヨ叩きスレに激怒して発狂レスしてるバカな高齢嫌韓ニートwww★3
今日も親韓、ネトウヨ叩きスレに激怒して発狂レスしてるバカな高齢嫌韓ニートwww★4
嫌韓ゴキニート「土日は昼間もチョンがいてイライラする。平日昼間はいないのに！」 ★1
世界中から愛されているK-POP嫌いになって聴くなって？絶対に無理だわｗｗｗ ★50
ジャアアアアアアアアアアアアアアッ( ´,_ゝ｀)ﾌﾟｯ