ゲームにおけるデータ構造・クラス設計・パターン2

1 ：2008/05/23 〜 最終レス ：2012/10/13

具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく

2 ：

■デザインパターン
必須ではないが用語として便利なのでしばしば話題に上がる
[参考サイト]
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乙
一応デザパタ軽く。

3 ：

3ゲトー1乙。ずっと待ってたぜ。

4 ：

・オブジェクト指向といったら特に指定しない限りクラスベース（所謂最も一般的なオブジェクト指向）
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。

5 ：

インスタンスってつまりは実体のこと？
Foo foo = new Foo() とすると foo がインスタンス？

6 ：

デザインパターンとOpen-Closed Principle
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも

7 ：

>>5
揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね？
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。

8 ：

「ゲームとはPrettyなインターフェースを備えたデータベースである」
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな

9 ：

スクリプト指向の意味がさっぱりわからない

10 ：

今最高峰のプログラマって、全員ＷＥＢ系じゃん？
ＷＥＢ系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな？

11 ：

>>8
ゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。

12 ：

メリットやデメリットを言えないくせに
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?

13 ：

>>12
今出てるのってそんな話か？
俺には世間話に>>10が適当な横槍入れただけに見えるが

14 ：

プ板から厨房誘致すればこのｽﾚは盛り上がる。間違い無いｗ

15 ：

たてなきゃいいのに布教スレなんかたてるからこうなる

16 ：

もう厨房が数匹住み着いたのか

17 ：

プ板？
ム板のことか？

18 ：

マ板じゃね？

19 ：

これも貼っておこう
やる夫で学ぶデザインパターン
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

20 ：

途中からゲーム関係なくね？

21 ：

俺には全部ゲームに関係した話に見えるけど？
サンプルコードもゲームだしわかりやすくていいと思うが

22 ：

なんか、無理矢理ゲームに例えてる感がひしひしと。

23 ：

日本語も満足に読めないのか

24 ：

お、2スレ目立ってたのね。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。

25 ：

>>22
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ！」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い

26 ：

俺のレベルではよくわからんが
ゲーム屋からみれば変な設計なん？

27 ：

デザインパターンを丸々入れ込むとゲームだと描画とかで
速度でないゴミになりそうな悪寒

28 ：

関数呼び出しとか仮想関数分のオーバーヘッドってそんなに響くか？
まぁ使い過ぎが良くないってのには同意だけど

29 ：

クラスというか、同じ関数名が増えまくるオブジェクト思考言語は、GTAGS使えないので嫌いです。継承構造とかも嫌い。
こんなんじゃ、ゲーム屋って無理？

30 ：

>>29
マならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…

31 ：

>>29
利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど

32 ：

cscopeならglobalと同じような事をC++やjavaのコードに対してもできるぜ

33 ：

CodeWarriorとか、OOPでもばんばんタグジャンプできるから問題ないのでは？
どうしてもGTAGSがいいの？GTAGSってGNU Tags？Google Tags？

34 ：

>>33
>GTAGSってGNU Tags？Google Tags？
ｶｴﾚw

35 ：

>>27
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。

36 ：

シューティング作っているんだけど
参考になるサイトでもある？

37 ：

積み木ファイターのひととか

38 ：

ゲーム作るときってどうやってプログラム組んでいく？
全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル

39 ：

>>38
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ？

40 ：

>>38
まず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。

41 ：

趣味で1人で作るのか、同人誌即売会狙いで数人で作るのか、会社の業務として作るのかで変わるとは思うけどな。
まあ、最後はありえねーとしてもｗ

42 ：

>>38
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz

43 ：

>>42
でも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。

44 ：

まずはトップダウンでモデル作って、作りながら問題があれば
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。

45 ：

それができないから、他に方法が無いかと模索してるんでしょうね。お察しください。

46 ：

あのgoogleですらボトムアップだという

47 ：

それはプロジェクト的な意味でだろ。

48 ：

デバイスへのポインタってグローバルにしたほうが明らかに管理しやすいよな

49 ：

>>48 は？なんで？

50 ：

俺はどっかにまとめるなあ
グローバルとか、デバイス差の吸収とか必要になったとき困らね

51 ：

Direct3Dのデバイスの話とまず仮定。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との２択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。

52 ：

ヘッダーが重たくなるから一部のソースでデバイス関連のインクルードして、
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。

53 ：

オレはシングルトンクラスに持たせてそこからgetter呼ぶかなあ

54 ：

レイヤスーパータイプじゃないの
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど

55 ：

デバイスを使うような処理は関数で囲っちゃって、
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな？

56 ：

>>55
俺もー

57 ：

↑でも、ビューアとかデバッグ系のプログラムは別だけどね。

58 ：

お前らシーンの遷移ってどういう風に管理してる？
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。

59 ：

シーンクラスじゃなくて管理クラスの方を積むの？
俺の鳥頭じゃちょっとイメージしにくい・・・

60 ：

シーンなぞ市販のゲームだって両手の指で足りるくらいしかないのに
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの？

61 ：

シーンねぇ
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。

62 ：

それで問題感じなきゃ無問題
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね

63 ：

シーンの切替で驚いた事といえば、
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。

64 ：

システムによっては、フィールドと町の中とではまるっきり違うやつもあるから、
そーゆーんじゃないのん？

65 ：

まぁドラクエ的な物なら自分もフィールド、街、ダンジョンは同列に扱うかな。

66 ：

>>58
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う

67 ：

俺はステータス画面の中の項目や、更に細かい項目もシーン扱いしちゃうなー
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど

68 ：

サブメニュー系は別で作ってhas関係にしてるな
シーン単一保持だと元シーン内のアニメも止める事になるし（※無論それが前提なら無問題だけど）
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな

69 ：

>67
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。

70 ：

自分はCだけど、シーン毎にゲームループを作る。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。

71 ：

システムデザインに拘ると、抽象化についてこれないメンバーいるからなぁ・・
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。

72 ：

>>71
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。

73 ：

むしろ日本の問題は、会社の枠で情報が閉ざされがちで、
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。

74 ：

閉ざしたくて閉ざしているわけでもないと思うんだけどね。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。

75 ：

それは違うな、設計能力を持つ人間が極めて少数しか世界に存在していない
守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか

76 ：

>>75
きもい、長い

77 ：

>>75
> 守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
> または公開することもできるだろう
もちろん社内で議論はしてるだろう。仕事してるんだから。
それと公開するかどうかは別の話だ。
ここでの話は、企業として技術情報を公開することについてじゃないの？
少なくとも>>72はそういう話でしょう。
それとも>>75は単に多くの日本の開発者を無能扱いしたいだけ？

78 ：

アメリカと日本じゃ、プログラマの流動性も違う品。
業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。

79 ：

外国人すげぇ日本人だめ、みたいなステロタイプの意見が多いな
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
＞外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
＞まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下（兵隊）の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね

80 ：

＞アマチュア間で情報をやり取りする開発者のフォーラムとか
＞あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンｗｗ」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお（＃^ω^）」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏＝3Dキチガイの巣窟。日本語圏＝虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない

81 ：

ゲーム開発に限った話じゃないけど、長引く不況のせいで日本人は
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。

82 ：

>>81
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。

83 ：

ノウハウ流出に厳しいってほんとかよ。
Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、８０年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ１０年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。

84 ：

単なる欧米コンプレックスだろ

85 ：

>>83
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。

86 ：

Google の論文は、個人的には就職者ホイホイのような気がしてる。
SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよｗ

87 ：

論文の質・量で言うとMicrosoft Researchのほうがすごくない？

88 ：

専門知識を蓄えてしまうと、ますます話の合う人間がいなくなりそうな予感。

89 ：

>>84
ソフトウェアに携わる人間で米コンプレックスを感じない人は
無能あるいは情報弱者だろう
欧州はそれほどとも思わないけどアメリカリードしすぎ

90 ：

>>89
海外はすごいよ。
開発するにしてもニッチな物になればなるほど日本側で
解説してるのが少ない。
結局は翻訳サイトで翻訳しながら自力で学習してる。

91 ：

それ、英語の普及範囲を評価してるだけだろ
日本人の英会話力の低さは別問題だよもう

92 ：

米コンプレックスとは世界の「知」が集まる「場」「国家」に対するコンプレックス
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ

93 ：

>>91
かぶったスR

94 ：

ところで休暇中に発見した格安で愉快な英語おしゃべり上達法
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ

95 ：

米国の現場における労働集約型闘争が生み出した兵隊の質の低下は
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数の変態テクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる

96 ：

くねくねハニィのコラムによると、
日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか？知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。

97 ：

切羽詰って偽装請負みたいなことやっちゃってたりするよな

98 ：

>>96
＞日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
＞海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
＞ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。

99 ：

>>80
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ（同人）市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○　絵（とくに３Ｄ）がきれい。
○　音楽も一般受けする質の高いものが標準。
○　ゲーム中以外のシーン（デモ、オプション設定）が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。

日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い（よくできたものもあるが）。
グローバルな金儲けには関心なく、村市場（コミックマーケット）で満足してしまっている奴が多いんだろうな。

100 ：

最近の家庭用の大規模RPGのデータってどう管理されてるのが多いんですか？
RDBですか？それともタダのファイル？

101 ：

普通はゲームデータ制作ツールとゲーム実行エンジンを並行して作っていく。
データはファイルが多い。ゲームデータ制作ツールの仕様にもよるけど、バイナリファイルの場合が多い。
C構造体のバイナリダンプは実装が楽だからね。
PCゲーには、ユーザがテキストファイルを弄ってデータや設定を変えられるものもある。

102 ：

国単位になるとステレオタイプのイメージに支配されちゃう人っているんだねぇ

103 ：

マの話はマ板でやってくれ
>>100
某タイトルはSQLite使ってるな

104 ：

>>87
> 論文の質・量で言うとMicrosoft Researchのほうがすごくない？
同意。世間じゃGoogleを持て囃すのが流行ってるけど、むしろ
コンピュータサイエンスはMSRのほうがすごい研究者を集めてる。

105 ：

>>104
研究者の層の厚さだと IBM 強いよなぁ。
Google は R&D でも R より D 寄り。

106 ：

>>103
まだ、主流は独自フォーマットのバイナリだと思うな。
CSV か XML っぽいフォーマットでデータファイル作っておいて、コンバータで
バイナリに変換して組み込み。

107 ：

だめだ、全然話についていけないぜ

108 ：

>>99
> ○　絵（とくに３Ｄ）がきれい。
> ○　音楽も一般受けする質の高いものが標準。
> ○　ゲーム中以外のシーン（デモ、オプション設定）が作りこまnれている。
ちょｗｗわかってかいてんのかよｗｗ
全部、投入できるリソースの違いで解決できるじゃねーかｗ

109 ：

俺は、海外のインディゲームデベロッパーを結構チェックしているが、
絵がきれー、とか音楽すげーとかってなかなかないよ
それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。
たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり（日本かとおもうけど、海外の話だよ）

110 ：

連投ごめん、音楽すげーはけっこうあるわｗ まあ俺がテクノ好きなだけかもしれんけど

111 ：

雑談スレに移動すべきだと思うけど二つだけ。
そもそも一国と世界を比べることに意味があるのかな。
言語障壁はローカルのコミュニティが栄えない理由にならないよね。

112 ：

>>108
>>109
>>99のリンク先のコンテンツを見た上で、のたまっているのか？
優れたリソースの利用可能性も、市場発展度合いの目安。

113 ：

日本の職人はゲームじゃなくて、ニコ動に集ってるだけだろ。

114 ：

方向性が違う物を比べても何にも成らないのに

115 ：

>>80だが
>>99
繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。
IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは
なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる
＞英語圏の方が日本よりも、アマチュアというかインディーズ（同人）市場が発展しているという印象を受ける
＞ttp://www.gametunnel.com/
ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか？してないだろ
特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる
（下半身産業が絡んで不公平になるので全年齢のみで比較してもいい）
＞日本のフリーとかシェアは（中略）
＞グローバルな金儲けには関心なく、村市場（コミックマーケット）で満足してしまっている奴が多いんだろうな。
だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに
「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい？毎日好きでもないものを延々作らされてる
腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために
真剣に取り組んでるよｗ素人に八つ当たりする前に自分の胸に手を当てて考えろっての。
あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。
他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが
ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない
弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい

116 ：

外国すげぇ日本だめ論が好きな連中は日本の文化を否定する傾向にあってあまり好かん。
アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。
趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。
エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。
世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。
あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい

117 ：

日本人はどちらかといえば何か分からんが動いたから良いやって人が多
い気がするね。
昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ
てるって何かの本に書いてた気がしないでもない。
SEやらPGやってる人なら分かると思うけど「なんで？どういうこと？」っていう
のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア
には向かないと思う。
まぁ外人云々じゃなくて正確か？？

118 ：

ただし、技術屋を志向する趣味プログラマは技術的ガラパゴス状態に陥ったら負けだな。
この点だけは外国すげぇ日本だめ論を展開するアジテーター共の意見に一理ある。
お国柄のせいか虹派が多数派の我が国ではアマチュアプログラマに要求される
技術水準はそれほど高くはない。それはそれでいいのだが、その技術ガラパゴスの中で
タスクシステム知ってる俺tuee状態とかになっては格好が悪い。俺tueeする時はもっと
見識を広めたほうが良い

119 ：

>>117
かぶったスマン

120 ：

熱く語ってもらってるとこ悪いけどお前らスレ違いだ

121 ：

ああ、悪い。次に長文レスするときは↓に投げることにする
現役開発者が質問に答えるスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1214321147/l50

122 ：

>>115
＞腹いせに素人に因縁付けてるようで感心しないな。
感じやすいんだな。
一つ俺が言いたいのはさ、スキルがあるんだったら、
小規模ながらもグローバルな金儲け（変な言葉だ）に挑戦すること考えた方が、
面白えんじゃねえのってことだよ。
自身の嗜好に自信がないって？
じゃあ、そいつは一体何をやっているんだ。

123 ：

スレ違いだボケども

124 ：

> SEやらPGやってる人なら分かると思うけど
PG以外がこのｽﾚに居るのかと問い詰める必要があるな

125 ：

すみません。話を脱線させた一人です。。。
小さな会社でケータイゲー作ってる業界人です。底辺です。分かってます
俺も職場の仲間はみんなゲーム専門学校卒です。
英語とか読めないしGPGの日本語版も難しすぎてわからないので
や○う○おさんの本とかCマガのタスク記事が職場のバイブルです。
某スレでタスクシステムが馬鹿にされて自棄になってて
俺の職場のレベルが低いのはきっと日本の閉鎖性のせいだと
考えるようになってました。
だってPS3とか箱○のゲーム作ってるクライアント（大手です）は
自分たちのノウハウを俺ら底辺には絶対教えてくれないし。。。
発注したケータイゲーをおとなしく作ってろって感じの扱いです。。。
ぜんぜん頭よくなれそうにない知育ゲーとか糞つまんねー
クイズものばっかり作らされて気が狂いそうです。。。

126 ：

日経のサイトのベーマガ２．０の記事も読んでました。
ベーマガがどんなものか実は知らないのですが日本の
アマゲーコミュニティがないから悪いって言ってたので
我が意を射たりって感じでした。
土日スレで投稿してましたがいつも荒らされてました。
PCゲーム板のフリゲ厨とかRと思ってました
俺は今もＤｉｒｅｃｔ３Ｄとかわけわかんないです。そういうのを
教えてくれるベーマガみたいなものに出会えなかったから
ファミ通の特集記事のゲーム専門学校すごいと思って
高校の先生の反対を押し切ってゲーム専門学校に行きました。
でも専門学校の講師も３Ｄ苦手でした。
おまえらには３D無理だから２Ｄで卒業制作作れって言われたので
言う通りにしました。今思えば先生が分からないもの作られると
質問されても答えられないから嫌だったんだと思います。
ゲーム専門学校に行ったことをすごく後悔してます。
ファミ通Rと思いました。きっとベーマガがあれば俺の人生
違ってたかもと思いました。やっぱおまえらが悪い

127 ：

すみません。ついカッとなってまたスレ違いのこと書いちゃいました
消えます

128 ：

ネタじゃなかったら真面目に一度精神科に行くべき。
明らかに躁鬱の傾向が見て取れる。
過度のストレスで脳に器質的な損傷が出来てるかもしれん。

129 ：

>>123
何も語れない馬鹿よりはマシ。

130 ：

まあ、消えなくていいからまた、スレ違いじゃなくてよさげな情報あったら教えてくれよ

131 ：

>>129
さすがにそれはねーよｗ
スレ違いでも知識をひけらかすほうが賢いと？
まあ、あまり過疎ってもらってもつまらんのだが・・・

132 ：

tunnelでおすすめのゲームを教えてｋれ

133 ：

VIPから来ました
ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて

134 ：

いや、作者じゃないと殴り込めないわけだが

135 ：

おかしな奴の言い分もわかるぜ
日本の企業は総じて、コミュニケーション能力だのなんだの
わけのわからない能力やノウハウを好んでそれを要求するくせに
それらを他人に教えるようなことはしないからな、ヒントすらも
異常なほど排他的だ
数年前に某大作RPGの下請けの社長様が
「3Dできる奴なんて腐るほどいるR、コミュニケーション能力のない奴はR」(意訳)
って新聞記事に載せてたの思い出した
笑える、うひゃ

136 ：

マ板でやれっつの
あーあ

137 ：

ほらクソども設計について語れや
レイヤスーパータイプは
class Devicer { static Device device; }
で、スーパークラスとしてDevicerを使うことだ覚えとけ
Application Controllerは
class AP {
View GetView(入力と状態値);
Command GetCommand(入力と状態値);
}
引数に入力情報や状態を判断する値を入力すると
それに適したViewやModelに対するCommandを返すものだ
覚えておけ、クソども

138 ：

みんな独自のウィンドウマネージャー(画面管理)クラス作ってるのかなあ

139 ：

>>135
良いこというなぁ。
禿同。
社長に。

140 ：

シーン遷移をきれいに実装したいという話なら、俺は否定するぞ
ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる
やるんだったら他の部分に影響を及ぼさない程度にしておけ
無意味に分断しすぎて複雑にするな

141 ：

>>140
めんどくさいのは、シーン遷移よりキャラクターの状態遷移だよな。仕様変更が
わりと発生しがちな部分だし。

142 ：

>>141
同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな

143 ：

状態が変わる時は自滅させてから、見た目同じで中身は別の敵オブジェクトを生成するとか。

144 ：

>擬似コルーチン
浅学な俺にコレについて詳しく

145 ：

>>144
以前けっこう調べた俺がコレについて詳しく
コルーチン
　並列実行をさせない（できない）スレッドのこと。外国人はコーディングの際 coro と略すこと多し。
　メリットは、排他処理が不要、ネイティブスレッドに比べてコンテキスト切り替えが軽い（もちろん実装次第だが）。
　デメリットは、切り替えタイミングをプログラマが指示する必要がある、CPUがデュアルコアでも恩恵が受けられない。
　最近ゲーム関係でよく聞くようになったが、アルゴリズム的にはすんごく昔のクヌース本にも載っているらしい。
　マイクロスレッド、協調的マルチスレッド、ファイバー（Windowsのみ）、などの言い方があるが、
　ゲーム業界ではコルーチンが一般的かな？
　ネイティブスレッドではないので擬似的なスレッドと言えるが、「擬似スレッド」という呼び方は
　よく混乱を招くようなのでお勧めしない（後述するように、スレッドを擬似的に再現する手法は他にもある）。
　Ｃで実装する場合は、たいてい手動でスタックポインタを切り替えることで実現する。
　主な実装：
　　アセンブリで実装：作成難度高、コンパイラ依存、移植性なし、使い手にもスキルが必要（スタック溢れ対策など）
　　大域ジャンプで実装：作成難度中、コンパイラ依存、やや制限がある
　　スクリプトで実装：スクリプトのVM（例えばLuaやSquirrel）に任せる。使うのは簡単で制限も少ない
擬似コルーチン
　コルーチンっぽいことを擬似的にやること（を、>>141は言っているのだと思われる）。
　主な実装：
　　マクロで実装：作成難度低、移植性高い、制限多い、読み手には超分かりずらい

感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。
以下は直接関係ないので、混乱するようなら読み飛ばして。
・昔のMacOSやWindowsで言うところの「プリエンプティブでない」マルチタスクの仕組みは、コルーチンの親戚。
・RubyやPythonのスレッドも、一般的な実装ではネイティブスレッドではなく擬似的なスレッドらしいが、
　明示的にコンテキスト切り替えを行うわけではないのでコルーチンとは異なる。
　Javaではこのような擬似的に実装したスレッドをネイティブスレッドに対してグリーンスレッドと呼ぶ。

146 ：

コルーチンを使わなかった場合
if (frame <= 100)
　GoToLeft();
else if (frame <= 200)
　GoToRight();
　：
以下延々とつづく
コルーチンを使った場合
for (i = 0; i < 100; i++)
　GoToLeft(); yield;
for (i = 0; i < 100; i++)
　GoToRight(); yield;
　：

147 ：

ミスった orz
for (i = 0; i < 100; i++) {
　GoToLeft(); yield;
}
for (i = 0; i < 100; i++) {
　GoToRight(); yield;
}
　：

148 ：

コルーチンは、タスクシステム総合スレで話題が出てたね

149 ：

あー、マイクロスレッドのことか！
それなら一応分かるような気がしないでもない
でもC++じゃあ無理だよね・・・

150 ：

fiber?

151 ：

>>149
ネイティブに落とされる言語だと実現するにはコンパイラ依存になるんじゃないのかなあ？
スタックいじるし。
>>150
Windows用語ではそうかと。
てか、要点は>>145に書いてあるなｗ
うまいまとめだ

152 ：

コンパイラ依存じゃなくてアーキテクチャ依存だ。
setjmp()でコンテキストを保存したあと、保存したコンテキストの
スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。
C++だけで実装可能だぞっと。

153 ：

fiberはRubyでも使われてるよ
スレッド（糸）より細いものだからファイバ（繊維）
あとJavaScriptにも1.7から導入されてるぜい

154 ：

マイクロスレッドは理想だけどそこまでトリッキーなことやる踏ん切りが付かない

155 ：

やっぱスクリプト以外ではやる気しないな

156 ：

タスクシステムはコルーチン実装の一つだね

157 ：

コルーチンの「コ」って子供の子って意味じゃないよね？

158 ：

cooperativeと一緒のco-だろ？

159 ：

俺はオブジェクト指向で、シングルスレッドだな。
常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。
また一方で、オブジェクト発生イベントのリストを持っていて、
順次、メインループにオブジェクトが登録されていく。
この「オブジェクト発生イベントのリスト」はシーンに相当していて、
シーンを切替えたければ、今登録されているオブジェクトを破棄して、
イベントのリストを差し替えるだけでいい。
while (1) {
　　for i=0...
　　{
　　　　オブジェクト[i]->行動();
　　　　オブジェクト[i]->描画();
　　　　オブジェクト[i]->当たり判定();
　　}
　　イベント発生()
}

160 ：

>>159
PACに似てるが違う、オブジェクトの追加に強そうだが
そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感
ドメインロジックのテストを行うときにビューが関わってくる
逆にビューのテストを行うときにドメインロジックが関わってくるため
テストに多大な労力がかかる事が予想される
常にプログラム全体をテストしなければならないため、試行錯誤するとRる
render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き
2Dにしても描画に関する処理が単純でなければうまく動かないだろう
規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め
または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め
私はお勧めしない、追加のメリットが多大である場合は考慮に値するが
ゲームには不向きだと思う、特に3Dの場合は
俺は怖くて使えない

161 ：

>>160
追加
リソースの追加が障害にならなければロジックのテストは問題ない場合もある
やるんだったらそんな半端な構造ではなく
関連まで含めて、PACアーキテクチャ使った方がよくないか?

162 ：

小規模な状態遷移の実装は
今持ってる手で四つ
1.擬似コルーチン
2.スレッド
3.スクリプトで隠蔽したスレッド
4.通常の状態変数による管理(State含む)
設計が明確でない初期のもの、プロトタイプ
又は小規模な場合の初期のとりあえず書いておくコードに向いているのは
擬似コルーチン又は状態変数だろう
まだ設計方針が明確に決まっていない場合や試行錯誤しなければならない状態で
スレッドやスクリプトの導入を決めるのは早すぎる、リスクが大きい
ある程度、方針が固まってから適切なものを選択するのがいいだろう
状態変数での管理が大手を振っているのも
初期コストが低いという部分が大きい
このため、状態変数やState以外の選択肢は簡単には普及しないだろう
ただし、スレッドの積極的採用が処理速度向上に繋がるのならその限りではない

163 ：

コルーチンで擬似ってどういうこと？

164 ：

>>163
擬似じゃなくていいのか、訂正
1.コルーチン、又は擬似のそれ
言語仕様に含まれてるときはそのままコルーチンとして呼び出し
c/c++の場合は以下のものが使える、又は自分で作る
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
それ以外なら
ソースコードを変換するプログラムでも作る
gotoやthrowやswitchやラベルなんかが含まれない言語では無理、又は面倒くさい

165 ：

まぁいいけど、ライセンスがGPLで良けりゃこっちを使おうぜ。
ttp://www.xmailserver.org/libpcl.html

166 ：

言語機能として付いてないC++で無理やんこやるのはいろいろ怖い気が
すんごい便利そうなんだけどなぁ・・・

167 ：

そこまでするならスクリプト組み込んだほうが
よっぽど安全で楽だと思うけどな

168 ：

>>162
スレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。

＞小規模な状態遷移の実装
>>146のような、行動予約の状態遷移を前提にしているのかな。
だとしたら、もっぱら自分は、C++で、
＞4.通常の状態変数による管理(State含む)
と動作制御用独自スクリプトだな。

基本は、ゲーム開発で言うところのタスクシステムで処理。
各オブジェクトは、単一クラス中に、状態ごとに処理関数（メンバ関数）を用意する。
フレーム毎に、その時点の状態に該当する処理関数を、１回ずつ呼び出す。
その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。
状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。
動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。
表現くどいけど、悪しからず。

169 ：

巣に帰れ
タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50
おまえらタスクシステム信者がクソでカスでゴミクズな理由は
自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ
または、それを考えようとしないところだ
ただ使えばいいと思い込んで、それで完結している
考えることを放棄したおまえらに設計能力を向上する機会はない
戦略のない戦術はただのテロだ

170 ：

ひどいな・・・
なんでそんな暴言が吐けるの

171 ：

良く知らんがタスクシステムって言葉が出ると荒れるようだ
なんかそういうgdgdな経緯でもあったんだろうな

172 ：

>>169
http://pc11.2ch.net/test/read.cgi/gamedev/1215129226/4n

173 ：

>>171
ゲーム業界の造語みたいなものだからな。
OS屋に言わせると「なにそれ？プ」というものらしい。
まあ一定60FPSとか30FPSといったフレームで常に動いてて
物の動きとか制御してるのがOSがタスクを処理してるのに見えるから
そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人
が言い始めたのそもそもらしい

174 ：

やっぱり顔真っ赤にして噛み付くヤツが出ると思ったよ
しょうがないからその辺の単語は誤魔化して話進めてくれ
いつまで経っても話進まねーからな

175 ：

名前負けしてるよね、完全に。

176 ：

話が進むわけないだろ
言ってる奴が、メリットもデメリットも把握していないんだから
ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない
宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
誰かこれを理解してみろクソが

177 ：

噛み付いてはないけど・・すまんな
まあ俺的にはそんな何とかシステム（自称）はどうでもいいよ。
市販のゲームでも売り出す際は自称ｘｘｘシステム採用とかいう
元からそういうの好きな業界だし。

178 ：

>>176
少し落ち着けよｗ
＞宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
お前はこういう事を言うやつに馬鹿だのアホだの必死に噛み付くのか？
俺はスルーするけどな

179 ：

「面白いこと書いた」と思ってるんだろうなぁ。
端からはただのバカにしか見えてないけどね。

180 ：

>>173
＞OSがタスクを処理してるの
ってどんな実装してるの？

181 ：

タスクシステムってゲームプログラミング固有のもんじゃなくて
リアルタイムOSとか便利なもんがなかった時代の組み込みシステム開発に
起源があるような気がする。
まあ、C++で真っ当にオブジェクト指向やってれば、こんな古臭いもんを
有難がる必要はないと思う。

182 ：

>>180
そりゃ・・・その辺はがんばって勉強して
キューだとかスレッドだとかタスクだとか
タイムスライスだとか
まあ同時に複数のものが動いてる（ように処理してる）風に出来るものかな
乱暴な言い方だけど。

183 ：

そろそろ潮時か
君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった
有益だったぜw
また暇なときに挑発に乗ってやる
この完璧な捨て台詞を覚えておけよ

184 ：

>>183
巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。
感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。
会社でタスクシステムで組みたいと同僚が言ったとして、
烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。
ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。

185 ：

＞7MZGZOjk
なんというか、要するに、



ただの孤独なレス乞食。
もしくはタスク・スレへの誘導係。
マンネリだな。
効率的な挑発方法については、再考した方がいい。

186 ：

タスクスレに託すか。

187 ：

コードが繁雑になって来たので、大革命を起こしたら
以前より良い設計ができない上に、収集がつかなくなった。
svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。

188 ：

>>186

189 ：

>>186
神は自らタスクる者をタスク。

190 ：

>>180
タスクスレの話題を続けるのはよくなさそうなので情報だけ
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/456
OSだからできることを思いっきり使ってるんで
管理手法以外はあまり参考にならんよ。
OS自体に興味があるならOS板にいくといいよ

191 ：

PG系隔離スレの2大巨塔でタスク厨の押し付け合いイクナイ！

192 ：

Google，自社開発のデータ構造化ツール「Protocol Buffers」を公開
ttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/

193 ：

>>186
【小さく審議中】
　　　 ,､_,､　 ,､_,､
　 ,､_('・ω)(ω・`)､_,､
　('・ω)uﾟ 　ﾟuu(ω・`)
　 ﾞuuﾟ(　'・) (・`　)uu'
　　　　ﾟuuﾟ 　ﾟuJ

194 ：

素人です
つくりかけのゲームってどうやって動かしてテストするんですか？

195 ：

ワタクシ ハ インクリメンタル ナ カイハツ ホウシキをとっているので
ちまちまと小規模な物を作って、それを拡張していく形になります。
例
第一段階： ウィンドウを表示する
第二段階： キャラクターを一つ表示する
第三段階： キャラクターを動かしてみる
第四段階： 飽きる

196 ：

>>195
なんで途中までカタコトなんですか？
そういう個人規模でなくて、複数のPGで役割分担してる場合はどうするんでしょう？

197 ：

そんなことシロウトせんでいいいよ

198 ：

動くところまで作ってからテストする

199 ：

改めて言われるとあれだな
他にやりようないな

200 ：

>>198
他人がつくったクラスがないと動かない場合はテストできないのでしょうか？

201 ：

つ 単体テスト
いや出しゃばった　俺はweb系なので実情は判らん
まあロジック側は業種問わずどうグズったところで、
「何々渡したときに何々返す関数作ってー！」しか分業方法ないと思うけど

202 ：

たぶん、作りかけってのが何処までか分からんけど
目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす＝エラーが出ないで動く　なので

203 ：

http://wiki.game-develop.com/
wikiのチュートリアル→段階的学習でもやってみては

204 ：

>>200
そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな？
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。

205 ：

>>200
もし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。
だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。
早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、

206 ：

>>204
>>200は外注や営業職の言い訳で多発するんだよね。
あんなのはまともに相手するのも無駄。
「スタブ要るじゃん。　スタブ供給してくれないとコストにあわないんだよね」系で、素で言ってのけやがる。
超ウケルんですけど。
こういうのに仕事を与えないようにするのが業界の為だろ。
　政治的な理由により取引継続となったら、「スタブの作り方を指導しますから、
その講習料として、スタブ作成代を相殺ですね」ぐらいしか案が無い。
・こちらはスタブなんて、要求仕様の一部で料金内。jk
・カス会社は、どちらも追加料金や有料。
・解決してなくても解決！！！！

207 ：

>>194
作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。
RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。

208 ：

作業分担？
全員が全体を上から下まできっちり把握した上で、
常に連絡を密にし、お互いが何をやってるのか理解しつつ、
各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。

209 ：

>>208
全員が全体を把握できるのは、せいぜい3人ぐらいまでだな。その先は
ヒエラルキー作って、パート毎に管理業務やる人間を立てないと無理。

210 ：

趣味ゲだと3人超えのマが介在するゲーム開発って
ほとんどないしな。大半はマが1人、多くて2人で>>408方式
ツーといえばカーの黄金タッグ。あ、ああじゃいる

211 ：

×>>408　○>>208

212 ：

非常に参考になりました。ありがとうございます。
>>208
それ実際には各人に漏れやズレが出て手戻りが出るんで、大規模プロジェクトでは無理では

213 ：

Cだったらmain()関数書いて実行して、デバッガ等で動き見るかな…
仕事（勿論?非ｹﾞｰﾑ）でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったｗ
個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどｗ

214 ：

大規模が何人か明確じゃないし、作業形態もネット上だけなのか
サークルのようなものなのか会社なのかもわからないから議論が発散してる
フリーソフト作るのに主力のプログラマ2〜3人と、バグ修正や機能強化の
パッチくれる人10人くらいでなら、MLとIRC使って>>208のような方針でやれてた
最初のバージョンはリリース済みで方向性が決まってたのが大きそうだ
>>212
作業するタスクを割り振りはちゃんとやって、頻繁なイテレーションと
継続的インテグレーションやるっつうのは何人くらいで破綻する？

215 ：

>>214
１チーム１０人以下で、各チームにリーダー２人ぐらいで、２００人ぐらいのプロジェクトも回ってました。
素人なのでこれくらいしかわかりません。

216 ：

>>215
プログラマの数は？

217 ：

>>215
まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない（DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。
基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。

218 ：

>>216
150人はプログラマでした

219 ：

>>208は半分冗談、半分マジだったんだが意外と受け入れられてるｗ
>>218
なんの素人なんだｗ
ゲームでプログラマ150人規模って洋げーでも多分ないのでは。予算的に。
マジレスしますと、
小さい規模ならメインプログラマがほとんど一人で下位システムを作っちゃうし、
大きい規模なら別の部署が作るから、
「作りかけの状態でどうやってテスト・・・」という事態があんまり無いでつ

220 ：

大規模金融システムで、SEの数ってことならありうるが
ゲームのスタッフロールにマが150人も並んでたら壮観だな
ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー

221 ：

ネトゲじゃねーの？

222 ：

マ150人てどんなネトゲだよ。。。

223 ：

ゲームのプロジェクトじゃないです。
詳細は言えませんが。
ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。

224 ：

俺の知る限り、ゲーム開発では基本的にテストは無いです
単体テスト→結合テスト→受け入れテスト、みたいな流れは無い
昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません
なので大部分がデバッグチーム頼みです

225 ：

3Dの衝突判定ライブラリを書いていたときは、単体テスト使いまくりだったぞ。
>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う

226 ：

グラフィックやサウンドが絡む部分は自動化は難しいけど
ネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ

227 ：

一人で作ってる分には単体テストに拘る必要はないと思うな。
逆に（自分含めて）しっかり単体テストできるなら、複数PG開発も悪くないと思う。
　　　　　　　　　　　^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁ｗ
テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな！

228 ：

(NetBSDをOSに使ってる)リコーのプリンタの開発チームは
PGだけで1500人だそうです

229 ：

数万行の同人ソフトしか作ったことないけど、ゲームってプログラムとしては割合小規模じゃね？
乗っかってるリソースの量がとんでもないだけで。
実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム（シーン別）、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の２乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。
あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。

230 ：

>>229
勘定系だってそれほど変わらんよ。

231 ：

RPGみたいないろんな要素のあるゲームのプログラミングってどこから手をつけていったらいいですか？

232 ：

お好きなところからどうぞ

233 ：

MSXのドラクエ２も大学生が一人で全部作ったんだよね

234 ：

RPGっていってもいまだといろんなシステムあるからな〜
古典的なドラクエ初期のように2Dオンリー
チョンゲーに代表される3D使ってるクリックゲー

235 ：

P6のゼビウスは小学生が一人で作ったんだよね
(発売時は中学生？)
http://www.ne.jp/asahi/shiba/mic/nori/xevi_tiny1/index.html

236 ：

>>230
勘定系は、人数は増えるけど PM しっかりしてればカオスにはならんよな。
金回りの話なのでミスが許されず、テスト工数がやったら膨らむから、
プロジェクト管理大変だけど。

237 ：

>>231
メモリ管理

238 ：

>>231
要素の洗い出し

239 ：

先人のろくにコメントもないコードの解析だけで一ヶ月ぐらいコーディングもしないってことはありますか？

240 ：

>>239
移植モノで、しかも元のプログラマが辞めて連絡取れないという条件で
一度やったことがある。二度とやりたくない。

241 ：

ソースがあるだけマシだよ
アーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。

242 ：

>>241
すみません…　それ、たぶんウチだ orz

243 ：

最悪だなそれ
MAMEでも進呈したほうがいいな

244 ：

オブジェクト指向のくずれてるウンココードに出会ったらどうしますか？

245 ：

見なかったことにする

246 ：

それ俺だな。
どうやれば良いか分からないから、手探りで書いてる(´・ω・｀)

247 ：

シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない？

248 ：

>>247
各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。

249 ：

どういう意味？
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど？

250 ：

>>247の文章が破綻

251 ：

コメントにシングルトンと書かれてるのに２つも３つもインスタンスが
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn

252 ：

XBOX360, PS3, Wii　売れ行きに関係なく、開発しやすいプラットフォームはどれ？

253 ：

箱○

254 ：

箱○は個人で十分開発できるからなぁ

255 ：

箱○　天国
Wii 　 普通
PS3 言わせるなｗ
という感じか？

256 ：

>>255
詳しく

257 ：

お前ら本当に3機種の開発ツール使ったことあるのかとｗ

258 ：

なんで個人開発限定なんだよ

259 ：

XNAのことを言ってると予想

260 ：

XNAの市販ゲームが出たってニュースは前に見た気がするけど
実際どんなもんなんだろ

261 ：

サターンのSBL,SGLしか使ったこと無い

262 ：

360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話？

263 ：

Wiiはインターネットチャンネルどころじゃない

264 ：

ゲーム機はDirectXを使うの？

265 ：

DirectXはMSだけ
あ、Dreamcastという例外があるか

266 ：

ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。
DirectXそのものを使ってるかどうかは知らないが。

267 ：

やってみて、無理と判断され、チームを外されることってある？

268 ：

>>267
板違い
プログラマー＠2ch掲示板
http://pc11.2ch.net/prog/

269 ：

いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。

270 ：

アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね？

271 ：

前者は状態フラグの配列なり持っておけば十分だろ
後者はなんだ？状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ

272 ：

>>271
なるほど。フラグの状態で、出るコマンドを制御すればいいのか。
サンクス

273 ：

メニューコマンドってみんなクラス化しているもんなのかな？
メニューオブジェクトを生成してどうこうみたいな。

274 ：

ベタコードで記述したり構造体・配列のままより
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね？
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。

275 ：

フロントコントローラーパターンとコマンドパターンでやります。

276 ：

メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは
だいたい同じインターフェースを実装してる。

277 ：

クラスメンバって全部privateにしてgetterでしか取得できないようにするべき？
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし

278 ：

>>277
クラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。
たぶん何か間違っている。

279 ：

>>277
俺も同じようなこと悩んでて、気がついたら両方混在してた。
「これはクラスじゃない、構造体なんだ！」
って言い聞かせながらところどころpublicにしてたりw

280 ：

全部て
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて

281 ：

排他制御や状態確認が不要ならどうでもいいかもだけど
コード書くのがマンドイだけなんじゃ？
まっしなIDEやプロパティのある言語つかうとかかな。

282 ：

>>280
例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。

283 ：

まて、そら元々アクセサの設計が統合可能だった場合だろ
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……
守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ？

284 ：

>>283
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。
あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。

285 ：

getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、
publicにした方が使う側は書きやすくでいいんじゃないの？と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・

286 ：

しかもget()で取得するのが配列だったりすると、
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。

287 ：

とりあえずpublicで書いていって、
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。

288 ：

>>287
なるほど。あまりスッキリしないやり方ですが、しょうがないですかね。
いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。

289 ：

特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。

290 ：

c++での話だが速度はインライン展開されるの期待できるから問題ないし
メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。

291 ：

>>290
こういうのって、センスが必要ですね・・・・。
ちょっと気になった事があるんですが、
自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、
わざわざgetterで呼び出して使う必要はないですよね？
class Foo{
private int a;
public int get(){ return a;}
public int calc(){
return get() * 2;
}
このようなcalc()の書き方に利点はあるのでしょうか？

292 ：

getter,setterがpublicなら外部参照する可能性があるということで
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。

293 ：

getterロボ

294 ：

メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。

295 ：

>>294
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。

296 ：

理想と現実はだいぶ違うよな
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする

297 ：

インターフェース中心の設計でプログラミングするんだったら
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。

298 ：

ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる（ﾄｲｲﾅw

299 ：

しかしgetやsetが乱れ飛んで読みづらくなることも

300 ：

>>299
プロパティが欲しいと。

301 ：

C#はそういう意味ではスマートだなぁ

302 ：

ゲームのシーン管理ってどうすりゃいいんだろう

303 ：

シーンつったってゲームによって全然違うからな
もう少し具体的に

304 ：

>>301
現行のゲーム機はまだC++なんだよな

305 ：

>>302
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。
そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、
結局どんな処理が必要などんなゲームなのか？
どれを止めると不味いか、どれは止めても復帰させれば問題ないか？
とかによると思う。

306 ：

シーンて、どのゲームも
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの？

307 ：

おいどんのシーンは一種のタスクシステム(笑)で、
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。

308 ：

FFとかのムービーシーンの管理はどうやればよかですたい？

309 ：

プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。
いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と

310 ：

あれ？　ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス？

311 ：

>>308
ムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。

312 ：

うさんくさか博多弁多かたいね。なんかぐらぐらこく
馬鹿にしないでください＞＜

313 ：

>>312
こらあげにまっことすまんかったぜよ。

314 ：

>>306
そうそうそんな感じ。
1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。

315 ：

　　しーん…

316 ：

【 審議中 】
　　∴∵

317 ：

（審議が長引いています。今しばらくお待ちください）

318 ：

キャラクターの状態って、どうやって実装してますか？
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか？
stateパターンでは無理？？？

319 ：

それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う
ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。
マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。

320 ：

>>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。

321 ：

>コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな！」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。
ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねｗ

322 ：

最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな

323 ：

関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。

324 ：

そこで goto ですよ

325 ：

某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。

326 ：

javaは関数ポインタ使えないんだ・・・・

327 ：

>>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。

328 ：

>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。
完成させることが第一と思っていてもついつい・・。
>>323,327
stateパターンですよね？
>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。

329 ：

自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。

つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる？

330 ：

むしろ可能な全ての表記法を試す勢いで！
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。

331 ：

人が書いたソースを読むのって勉強になるけど、読む気が出ない……
>>328
>stateパターンですよね？
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。

332 ：

＞状態という概念が無い
敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。

333 ：

>>332
他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。

334 ：

>>329
コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。
今問題にしてるのは、主にこのうち後者２つです。
ただ、読みやすさは人それぞれなのかもしれません。
>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。

335 ：

保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの？

336 ：

ダライアス継承ってどんな継承？

337 ：

>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる？

338 ：

>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。
>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。

339 ：

ダライアス継承なんて初めて聞いたなあ
英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス（Darius？）はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな

340 ：

ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える

341 ：

Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん

342 ：

http://ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50

343 ：

>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)

344 ：

>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw

345 ：

>だったりしてw
いやだったりしてっつーかそれしかなくね

346 ：

ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。

347 ：

ドラえもん 「ことわざゲーム」
これはいいアニメ。 ... ドラえもん 藤子Ｆ不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar

348 ：

なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク

349 ：

夏休みも終わりって事さｗ

350 ：

Bot使った宣伝書き込みかなぁ

351 ：

なんかのマルウェアって聞いたが

352 ：

A has B B has C C has Dのようなクラス構成で
Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に
Ｅを渡していくのはいいのかな？

353 ：

いいんじゃね。

354 ：

別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない

355 ：

>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と
思ったんだよね

356 ：

このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠

357 ：

>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。　っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと）
本当はいいとも悪いとも言えないが。

358 ：

CarクラスはTireクラスを４つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？

359 ：

コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外

360 ：

TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか？

361 ：

>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。

362 ：

タイヤが車に関心があるってどういう状況？

363 ：

「パンクしたよ」って知らせてくれるんじゃね？

364 ：

なるほど

365 ：

それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？

366 ：

車が、常に「パンクしたか？」ってタイヤに聞くの？

367 ：

うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど

368 ：

メディエーターみたいなの？

369 ：

>>366
実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();

370 ：

ほしゅ

371 ：

このスレはJavaでも大丈夫なの？

372 ：

>>371
質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288

373 ：

>372がエスパーすぎる

374 ：

データ(アイテムとかマップとか)ってどうやって作ってます？
エクセルで打ち込んでcsvで保存？

375 ：

別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし

376 ：

>>375
マップに関しては、フリーのエディタがあるんですね。
規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。

377 ：

既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。

378 ：

海岸線自動生成とかやってくれるエディタあるっけ？

379 ：

>378
エディタでやるの？

380 ：

機能としてはエディタ側じゃね？

381 ：

ツクールで海岸線をシフト＋右クリックすると分かる

382 ：

最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。）
2、再利用を考えたフレームワークは（初心者は）作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください　orz

383 ：

相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ！」
ピー…

384 ：

> Gofのデザインパターン
GOF本でわかったならよいけど、退屈でわからない人は
First Headの本オススメ
Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: Amazon.co.jp: 本
http://www.amazon.co.jp/dp/4873112494
http://images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

385 ：

ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。
たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite）
2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent）
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか？

386 ：

>>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。
ってそういう話じゃない？

387 ：

>>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。

388 ：

ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。

389 ：

>>382-384
まだ読んでいない俺には勉強になったthx

390 ：

>>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
（まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ）

391 ：

すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling()　…主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします

392 ：

なんかいっぱい改行が入ってるorz

393 ：

>>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。

394 ：

>>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。

395 ：

ついでにスレを読み返してメモメモ、と思った情報をまとめてみた。
コルーチン、マイクロスレッド、ファイバ
>>145,>>146,>>162,>>164
楽だが応用性のないありがちな実装
>>159,>>160
分業とデバッグ
>>194-213
ADVの画面クリックとか
>>270,>>271
メニュー画面の管理とかシーン管理とか
>>59-71,>>207,>>273-276>>302,>>305-314・・・VMCはたぶんMCVのことだよね？
状態管理とか
>>318-325
priateとgetter、setter
>>277-301
設計Tips
>>352-357,>>358-367,>>382-384

396 ：

ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか？
↓ゲーム開発論スレ要望の経緯
http://pc11.2ch.net/test/read.cgi/gamedev/1206381315/
ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」
http://game.watch.impress.co.jp/docs/20080916/cedec_dev.htm
「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス
http://www.4gamer.net/news/history/2007.03/20070309215934detail.html
Agile型開発でのゲームデザイン
http://www.4gamer.net/news/history/2007.03/20070311002313detail.html

397 ：

>>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ！！

398 ：

想定通りでワロタ

399 ：

>>395
ありがとう助かるよ

400 ：

キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。

401 ：

俺はそうしてる。

402 ：

つまりスクリプトですね。

403 ：

知ってるよDIって言うんだよね

404 ：

最近でたセガのあれな本を読んで、自分がずっと詰まってたしょーもないことを勝手にメモ。
結論としては基本中の基本で、データと処理は独立させましょ、ってことなんだけど。
ゲーム中ができたけど、ポーズ機能を追加、ポーズメニュー表示関連をクラスで作って実装するには、という感じの想定。
こんな感じに管理してるとして(具体的にはもっと複雑だけど。)
class StgScene　{
　Mover movers[];
　void Update() {
　　//A
　　for(・・・) {
　　　movers[i].Move();
　　}
　　//他判定処理等
　　//B
　　for(・・・) {
　　　movers[i].Draw();
　　}
　　//C
　}
}
・A〜Bまでの処理はポーズ時すっ飛ばす、となる。ので、関数化するなりクラス化したい。
・対象性を考え、Menuクラスに対してA〜Cの処理をPlayingクラスにする。(つまりSTGSceneはデータのみ。)
・MenuクラスにもB〜Cの処理を書き、追加してMenu関連の処理も記述する。
こうすると、結果的にSTGシーンはデータしか持たなくなって、処理はPlayingクラスやMenuクラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。

405 ：

「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい

406 ：

MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか？
Stateパターンという風にも捉えられる？

407 ：

Stateパターンだとこんなかんじかね？
struct StgScene {
　void A();
　void B();
　void C();
};
class State {
　virtual void Update(StgScene&) = 0;
};
class Playing : public State {
　virtual void Update(StgScene& scene){
　　scene.A();
　　scene.B();
　　scene.C();
　}
};
class Menu : public State {
　virtual void Update(StgScene& scene){
　　scene.C();
　}
};

408 ：

なんか話題無いなー的なので、>>404の続きでも。今回もセガのあれを参考にしました。
自分もまだ試作中だけど、かなり自由かつ堅実に作れる。
StgSceneクラスの考えをもう少し推し進めると、全てのシーンの汎化クラスであるSceneクラスが作れそう。
# child　　　　　　　　　　　　// フィールド。子シーンの保持。
# childTypes　　　　　　　　// フィールド。runやUpdateの戻り値が自分の子かどうか識別するためのもの。
# run(Scene parent)　　　// メソッド。child == null のとき、自分が実行すべきシーンと認識してrunする。戻り値に次の遷移先シーンかnull返す。
# focusing　　　　　　　　 　// イベント。シーン遷移で自分が次にrunする場合の初期化処理。Update内のシーン遷移処理に際し呼ばれることが目的なので、abstractメソッドでもいいです。
# unfocusing　　　　　　　　// イベント。シーン遷移で別のシーンに移動する際の後始末。上と同様。戻り値に次の遷移先シーンかnull返す。
+Update(Scene parent)　// childがいればchildのUpdateを呼び出し、そうでなければrunする。その後、遷移先シーン(つまりUpdateやrunの戻り値)に応じた遷移処理を行う。
Updateの実装内容について
１、シーンは線形リストを形成し、末端シーンのrunを実行するように記述する。(rootScene　→ StgGame　→ StgPlayingや、rootScene　→ TitleScene → TitleHighScoreといったリスト構造になる。)
２、runのreturnに意味を決める。そしてそれによって処理が分岐するように記述する。null、自分、兄弟シーン、親以上。
・nullは、runしたシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。
･･･っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。

409 ：

しかもミスってる。
# unfocusing　･･･『戻り値に次の遷移先シーンかnull返す。』　←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。

410 ：

自作の状態遷移クラスに似てるな。
・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの？
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。

411 ：

>>410
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。

412 ：

インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。

413 ：

インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。

414 ：

まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん

415 ：

あれか？　NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か？

416 ：

>>414
PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。

417 ：

シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。

418 ：

ごめん
×ライフサイクル
○ライフタイム

419 ：

そのあたりの話は研究しがいがあるな。

420 ：

>>418
一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな？
クラス図の関連が木構造で、枝をはさみで切るイメージ。

421 ：

シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。

422 ：

シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。

423 ：

管理マネージャじゃマネージャマネージャだなｗ
まあC++になって楽になったものよ。

424 ：

>>421
原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。
あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)

425 ：

親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。

426 ：

YAGNI

427 ：

スレが止まってるとさびしいな。
独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。

428 ：

オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は　位置、速度、耐久力(=生存判定)
publicにしそうな関数は　更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
（本質的にバリアや耐久力表示と同じ関係なので。）

429 ：

ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。

430 ：

で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。

431 ：

オブジェクト同士の衝突判定の記述。衝突判定まで。
・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。

432 ：

>>427-431
とりあえず「管理」という言葉を使わないように考えることをおすすめする。
http://www.google.co.jp/search?q=SomethingManager

433 ：

>>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。

434 ：

大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。

435 ：

そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい

436 ：

>>434は別に口答えしてるわけじゃない気がするｗ

437 ：

アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな？
とたまに悩む

438 ：

Ｇｅｍｓにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい

439 ：

そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた

440 ：

>>437
悩む悩むｗ

441 ：

>>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。

442 ：

ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります

443 ：

キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか

444 ：

たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。

445 ：

>>444
物の理を司る GOD class

446 ：

分からないから指向をそのままレスとして出力。
・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。

447 ：

唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん

448 ：

> ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス

449 ：

> ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス

450 ：

> ・石に重力を働かせる処理
ゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス

451 ：

> ・石に重力を働かせる処理
石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス

452 ：

>>451
オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり？

453 ：

>>450
CGameManagerですね、わかります

454 ：

みんな何のことだかわかっていて俺涙目

455 ：

テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。

456 ：

455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。

457 ：

沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな

458 ：

>>457
じゃあ新たなネタ出せよ

459 ：

ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、１つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード＆短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。

460 ：

人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はＯＦＦで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利／敗北または成功／失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール（数十倍〜数十分の一まで）。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。

461 ：

リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。

462 ：

速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。

463 ：

>>460-462
いろいろありがとう。
あらかたデバッグ用に実装してみました。

464 ：

行動力あるね
素晴らしい。見習いたい

465 ：

いやいや。実装したのはこんだけです。
コリジョン可視化:テクスチャ読み込み後に四隅に沿って緑色で四角線を書くだけ
パラメータ操作:テンキーで実装
　4と6で対象パラメータを選択 (あらかじめ操作対象を手動でlistしておく)
　789でパラメータ上昇(7で+1,8で+10,9で+100)
　123でパラメータ下降(1で-1,2で-10,3で+100)
　0で強制0(bool値ならfalse)
便利ボタン:戦闘強制勝利機能とエンカウント無効をFXXキーに割り当て
速度コントロール:VSync非同期にして、FPSを上げることで対応
　2倍にすると早すぎたので、1.5倍(90fps)をボタンに割り当て
リプレイ機能:フレームごとの入力(キーボード/ジョイパッドを合わせた入力値)をファイルに出力
　(一見単純そうだけど、セーブ/ロードの関係でこれには実装に手間取った)
作っているのがRPGなので、便利ボタンとパラメータ操作がとても役に立っています。
ありがとうございました。

466 ：

洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。

467 ：

http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/

468 ：

スマートポインタの使いどころ教えて

469 ：

使いどころっつーわけじゃないけど
次のC++規格が決まれば、早ければ今年中にも
　std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど

470 ：

>>468
まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。

471 ：

要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか

472 ：

Yes
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ

473 ：

つまり、いらなくなったらすぐに消されるってことですね
私のように

474 ：

不況だもんな・・・

475 ：

いや、それは地球の資源不足で君の給料が確保できないだけだ
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・

476 ：

例えばDirectxのDeviceインスタンスなど、あらゆる所で使われそうなインスタンスは、どう使ってますでしょうか？
Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは
1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他
現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?

477 ：

デバイスホルダー的なシングルトン作るとか

478 ：

俺もシングルトンかな。参照回数が0になったらreleaseで。

479 ：

ハッシュテーブルのキーって文字列じゃなくてもいいのかな？
符号なし整数とか。
どっかにそういう例ないです？

480 ：

ハッシュが計算できるなら、キーはなんでもいいよ

481 ：

>>479
こんなんでいいか？
ttp://codezine.jp/article/detail/2171?p=2

482 ：

C++でシングルトンするのってなんか滑稽じゃね？
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う

483 ：

>>482
グローバル変数が欲しいんではなくて、システム全体で一つしかないということを
明示的にする為のパターンだから

484 ：

グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう

485 ：

あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。

486 ：

>>484-485
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー

487 ：

>>486
そのクラスのインスタンスが１つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ

488 ：

http://www.geocities.jp/ky_webid/design_pattern/009.html
「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね？
// 生成やコピーを禁止する
↑アホじゃね？　最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい

489 ：

まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな

490 ：

先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件

491 ：

>>490
アンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか

492 ：

クラスアンチだしｗ
http://www.google.co.jp/search?hl=ja&q=%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%A2%E3%83%B3%E3%83%81&lr=lang_ja
ググるとアンチクラスが出てくる上にプログラムカンケーねえしｗ
まあいいや
C++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい

493 ：

労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね？　最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ

494 ：

>クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
いくらでもあるのか
そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489
俺にはこの２つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね
>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484

495 ：

>>484の方が楽だとは思えない
まあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな

496 ：

namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。

497 ：

まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね

498 ：

Delphiでシングルトンする方法なんてこれだぞ(公式ライブラリVCLで使われている方法)
interface // 宣言部(C++のヘッダーにあたる)
type
　TPrinter = class　// クラスの宣言
　　：
　end;
function Printer(): TPrinter;
implementation // 実装部(ヘッダーじゃない方)
var FPrinter: TPrinter; // グローバルへんすうw
function Printer(): TPrinter;
begin
　if FPrinter = nil then FPrinter := TPrinter.Create; 　// TPrinter生成
　Result := FPrinter
end;
厳密にインスタンス化の制限とか、もはやどうでもいいクラスｗ

499 ：

>>498
捕捉：
（わかると思うけど）使う時は、他のユニットから
　Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節？でアプリ終了時のFPrinterの開放処理がある。

500 ：

また変なのが沸いてるのか

501 ：

デバイスに直接アクセスする処理ってどこに書いてる？
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。
今：あちこちでデバイスにアクセス
void draw_landform(void) {
　　...
　　lpD3DDEV->draw(...);
}
void draw_menu(void) {
　　...
　　lpD3DDEV->draw(...);
}
案：デバイスアクセスは１箇所。デバイスに渡すデータをあちこちで作る。
const DrawData *draw_landform(void) {
　　...
　　return ...;
}
const DrawData *draw_menu(void) {
　　...
　　return ...;
}
void main_loop(void) {
　　draw_data.push(draw_landform(), ...);
　　draw_data.push(draw_menu(), ...);
　　lpD3DDEV->draw(draw_data, ...);
}
もし既に案の方法でやってる人いたら使い勝手教えて！

502 ：

久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ！

503 ：

描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。

504 ：

俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…

505 ：

レスありがとう。
>>502
「案」の方に似たやり方だよね？ draw_dataがリスト相当で。
やっぱやってる人いたか。採用してるってことは使いやすいんだろうか
>>503
void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) {
　　...
　　lpD3DDEV->draw(...);
}
みたいな感じ？
デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？
この方が使いやすいってことかな？ うーん。。。
>>504
Draw_data::draw(...) {
　　this->lpD3DDEV->draw(this->draw_data, ...);
}
こんな感じ？　ラッパー作れって話？
「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか
うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど
気になる人って少ないんだろうか。
0人では無かったけれど。

506 ：

まずはMVCを試みてみるのはどうだろうか

507 ：

struct Visitor;
struct Element { // 訪問される側の基底クラス
    virtual void accept(Visitor&) = 0;
};
class Landform : Element {
public:
    virtual void accept(Visitor& x) { x.visit(*this); }
    Data* getLandData();
private:
    ...
};
class Menu : Element {
public:
    virtual void accept(Visitor& x) { x.visit(*this); }
    Data* getMenuData();
private:
    ...
};
struct Visitor { // 訪問する側の基底クラス
    virtual void visit(Landform&) = 0;
    virtual void visit(Menu&) = 0;
};
class DrawingVisitor : Visitor { // 各要素を訪れて描画を行うクラス
public:
    DrawingVisitor(LPDIRECT3DDEVICE9 p) : pDevice(p) {}
    virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
    virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
private:
    LPDIRECT3DDEVICE9  pDevice;
};
続く…

508 ：

…続き
elementList.push_back(landform);
elementList.push_back(menu);
void mainLoop() {
    DrawingVisitor visitor(lpD3DDEV);
    for(ElementList::iterator i = elementList.begin(); i != elementList.end(); ++i) {
        i->accept(visitor);
    }
}
うーむ…。

509 ：

>>506
今回の話ではModelとControllは関係なくて、Viewの枠内だけで完結する話だと思ってる
>>507
複雑すぎて俺の頭では完全には理解できないけど、
>    virtual void visit(Landform& x) { pDevice->draw(x.getLandData()); }
>    virtual void visit(Menu& x) { pDevice->draw(x.getMenuData()); }
ここを見るとデバイスに直接アクセスする処理を１クラス内、複数関数にまとめたって感じかな
うーん…、複数の関数にデバイスアクセス処理が分散してるとこがあまりうれしくないかな。
（俺には複雑過ぎるのはさておき）

俺が扱いづらいと思ってるところは、
pDeviceさえあればdraw()以外にもbegin_render()とかset_camera()とかいろいろ
デバイスに対して変更加えることができちゃうわけで、
それをばら撒くってことはいつどこでデバイスに変更が加わるか、例えばいつどこで何回begin_render()されてるのか
とかが追跡しづらくなる。これは１週間後の自分に優しくない。
こんな感じでデバイスに直接アクセスする処理をどう管理したもんかと考えて
ひとつの対策案としてデバイスアクセス処理を１関数内に限定しちゃえってのが >>501 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。

510 ：

描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。

511 ：

>>510
確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ2D的にしか使ってないし。
あとデバイスってサウンドとか入力装置とかもあるけど、それらもおんなじ感じで取り扱いたいし。
デバイスにアクセスする処理が関数１個の中に「ひとまとまりで」収まってればＯＫとするなら
下のように書いて済ませられるかな？
void dev_state1(void) {
　　lpD3DDEV->BeginScene();
　　lpD3DDEV->set_parameter(...);
　　lpD3DDEV->draw(draw_landform(), ...);
　　lpD3DDEV->set_parameter(...);
　　lpD3DDEV->draw(draw_menu(), ...);
　　lpD3DDEV->EndScene();
}
ひとまとまりってのは１フレーム分のデバイスアクセス処理全部。
描画内容を大きく変えたい時はdev_state2()とかをまた別に作っておいて、
ゲームのステートに応じてどれを実行するか切り替える。

なんか描画スクリプトの方が夢があるな。
外部GUIツールで描画内容を設計して
吐き出した描画スクリプトをゲームで解釈して表示とかおもしろそう。
でも描画システムの根幹過ぎて汎用的に作るのめんどくさそう。。。
うーん、とりあえず簡単に済ませたいからdev_state1()みたいにベタ書きで
どこまでいけるかやってみるかな。

512 ：

hamigaki::coroutines使ってみた。

513 ：

yhamigakiさんのexec.jamモジュールにはお世話になっております

514 ：

スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド　仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い

515 ：

仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。

516 ：

http://www6.atpages.jp/~autonomydoll/game/RPGClient.zip
クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
　　　　　｜　　　　　　　　　　　　　　　 |->Main-->Map -|
　　　　　｜　　　　　　　　　　　　　　　　　　　　　-->Unit--->sprite--|
　　　　　｜--------------------------------------------------------------->GraphicsWarpper

517 ：

WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。

518 ：

>>516
> ScreenManger
画面飼槽
> GraphicsWarpper
グラフィックスワープ装置

何が言いたいのかさっぱりわからないのだが。

519 ：

>>517
忘れてました。
net frameworkを使ってます。
>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
GraphicsWarpperは単なるラッパーです。

520 ：

こんな面白い難読化もなかなかないな

521 ：

>>519
> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。

小学校は夏休みなのか・・
せめて中学生になってからにしてくれ

522 ：

>>521
すまん。スペルミスった・・・。

523 ：

まず日本語と英語を勉強するべきでは？
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う

524 ：

>>523
ありがとう。
それをあたってみる。

525 ：

質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ

526 ：

2〜3人で多いのか、寂しい生活してるんだな

527 ：

言われて悔しいならもっと勉強しろよ

528 ：

コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･
>>395
395以前のまとめ
>>404,406-407
シーン遷移考え方
>>408-413,416-425
シーン遷移実装サンプルと問題点。
>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。
>>437-443
オブジェクトと座標管理
>>444-456
オブジェクトと衝突判定と全体効果
>>459-465
デバッグ用処理を考える。(衝突判定表示とか)
>>501-511
DirectXのデバイスの管理とか使い方
>>523
ネットワーク機能参考図書紹介

529 ：

STGのビジュアル関連向上に関するメモ。
･･･あんま設計と関係ないな･･･
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。

530 ：

>>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。

531 ：

シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが，
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか？
データクラスを作ってアクセッサで操作を許す？
それとも，すべてグローバル変数で持たせる？

532 ：

シングルトンクラスのオブジェクトをグローバルに定義する

533 ：

SQLiteとか使って手抜くってのもあり

534 ：

グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。

535 ：

アクセッサ書くのめんどいだろ

536 ：

なんでそんな両極端なの？

537 ：

0と1しか無いからな
オタクの頭ん中は

538 ：

別に両極端で構いません．
意見を頂けるだけで嬉しいです．
むしろ噛み付くほうが迷惑です．

539 ：

使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。

540 ：

>>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。

541 ：

俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。

542 ：

>>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…

543 ：

２ｃｈで素直に謝られると逆に困ります．
参考になりました，ありがとうございます．

544 ：

グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。
// gamedata.h
void update();
int get_parameter1();
// gamedata.cpp
static int s_paramter1 = 0;
static int s_paramter2 = 0;
....
void update() { /* 更新 */ }
int get_parameter1() { return s_paramter1; }
唯一しか存在しないゲーム中のデータをどう実装・管理するか、って視点だけで考えれば
スタティックグローバルであろうと、クラスであろうと大差ないと思うけど、
ある時点でのスナップショットを扱う必要がある、みたいな場合、
// gamedata.h
void update(Data* gamedata);
int get_parameter(Data* gamedata);
て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。

545 ：

代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。

546 ：

入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。

547 ：

アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。

548 ：

>546
確かに使い方を間違えるってのはよく起こる

549 ：

Compositeをゲームのシーン管理に使うのってどうやるんですか？
次に来るシーンを各クラスに設定しておいたりとか・・？

550 ：

何を聞いてるかがちょいと分からないけど
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。

551 ：

というか前スレの260あたりか。Compositeかどうかも微妙だな。ｽﾏｿ

552 ：

>>501
その後どうなった？
俺も今描画周りを考えてる

553 ：

よく読んでないけどEmptyProject風に
void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}
void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}
って風にやったら問題あるの？

554 ：

deviceの作成は一箇所のクラスでシングルトン
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ
無知なんだけど、デバイスて何個も必要になることあんの？

555 ：

デバイスが複数あったら複数必要なんじゃね。

556 ：

その複数てのがさ、動的に管理しないといけないものなら複数個保持するクラスにすればいいし
そうでないなら同じようなクラスを用意するかな
便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる
まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな

557 ：

ボンバーマンを拡張して繋がれてるコントローラの数だけ
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。

558 ：

プレイヤが一人でも全てのコントローラで操作できるようにしているが
（左右同時に押された場合は後からの入力を優先）
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな

559 ：

壊れたコントローラーはサポートしなくてもいいと思うよｗ

560 ：

sharedptrみたいなの実装したいのですが、
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか？
boostソース読めってのは無しでお願いします。

561 ：

>>560
「スマートポインタ」でググれば解説もサンプルも見つかるよ。

562 ：

>>560
なんで boost::shared_ptr 使わないの？

563 ：

>>552
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。
簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。
コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列（描画スクリプトみたいの）を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。
デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。

564 ：

>>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。
つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。
たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。

565 ：

sqliteを組み込んで、画像やモデルを相互変換可能な名前/IDで管理するとか夢が広がるわな
内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし

566 ：

>>565
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。

567 ：

おおー、ゲームのバックエンドサーバーにもGAE使う時代かｗ
たしか、mixiアプリのモバイルゲームでGAE使った事例があったな。
3000万PV/月をかなり安価で乗りきれるとか
Togetter(トゥギャッター) - まとめ「100万PV／日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー」
http://togetter.com/li/494
すれ違いの話題になるが、昨今のネットが絡むゲームの場合バックエンドの技術も必要だけど、
そういう話題を扱ったスレってないものかな
この板にネットゲームの開発時代が少ないみたいだから、需要はないのかもだけど
まーGAEならWebProg板のAppengineスレ行けばいいしな

568 ：

x 開発時代
o 開発自体

569 ：

前スレの最後のほうに出てた描画の話題って結局どうなりました？（928ぐらい）

570 ：

http://blog-imgs-27.fc2.com/c/h/u/chudoku200/1239712143736s.jpg

571 ：

アクションゲーム作ってるんですが
どういう風にクラス分けすればいいか悩んでます
MAPクラス
Playerクラス
GameFrameクラスの3つがあって
mainループで
switch(MODE)
{
case TITLE:~~~~;break;
case MENU:~~~~;break;
case STAGE01:~~~~;break;
case STAGE02:~~~~;break;
.
.
.
}
みたいなことをしています。
各Stageに行くたびに、ステージ前処理と、ステージ後処理をしたいです
というとコンストラクタとデストラクタ……つまりはクラスを使えばいいんじゃないか？
という感じなのですが
Playerクラスの持っている情報と、操作関連を上手く融合させたり
Mapクラスの持っている情報と、Playerクラスを上手く組み合わせたりが出来ません……
こういう部分はどういう風にデザインするのがいいのでしょうか

572 ：

STAGE01とSTAGE02を分ける必要は無いだろ。
ファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。

573 ：

まずそのswitch文をなんとかしよう。
TitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ？

574 ：

>>571
貴方は俺か
クラス名と悩みが殆ど同じとかｗ

575 ：

>>571
ちょっと難しいかもしれないが
ttp://marupeke296.com/GDEV_main.html
ここはかなり参考になる気がするよ。サンプルもあるし。
その6とその7ね。

576 ：

保守

577 ：

良スレ保守

578 ：

Android開発でのパフォーマンスTips
http://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293
オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける

携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな

579 ：

iアプリを思い出すなーｗ

580 ：

PS時代のゲーム開発みたいだなｗ
あの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてｗ

581 ：

処理能力を操作に割かせるためにメモリに読めるだけ読むのかな

582 ：

それやりすぎるとアプリの切り替えをすることが多いスマフォじゃ
面倒が起きやすいんじゃないか

583 ：

>>19
消えてるみたい
どこか掲載されるサイトしらない？

584 ：

こないだ色々探したんだけど、糞アフィブログのリンク記事しか見つからなかった
キャッシュとかも見たんだけどさ

585 ：

>>580
そうかもしれない。
その世代が今のゲーム現場で老害化してるんでむしろ行って欲しい。

586 ：

よさげなスレなのに、あまり話が盛り上がってないな・・・
RPGのクラス設計で、「CharacterがItem（複数）を持っている」
状態を表したい時、
昔の自分は、
class Character {
　　List<Item> inventory;
}
って書いていたけど、最近の自分は、
class Inventory {
　　static List<Item> itemList;//全キャラクター分のアイテムを格納
　　Character character;
　　public int Count { get { itemListを数えて返す } }
　　public Item this[int no] { get { itemListのno番目を返す } }
}
class Character {
　　Inventory inventory;
}
って書くようになった。
どっちの書き方が多数派なのだろう？

587 ：

そこまでいったら、Interface抽出までやるかなー。

588 ：

インタフェース抽出・・・
こんな感じ？
interface IGameData<T> {
　　int Count { get; }
　　T this[int no] { get; }
　　void Add(T arg);
　　void Remove(T arg);
}
（ジェネリックの書き方は適当ですｗ）
class Inventory : IGameData<Item> {
　　static List<Item> itemList;//全キャラクター分のアイテムを格納
　　Character character;
　　public int Count { get { itemListを数えて返す } }
　　(ry)
}

589 ：

たぶんそんな感じー

590 ：

>>588
なんでitemList がstaticなんだ

591 ：

プログラム自体全くの素人なんで
取り敢えず3D空間上に地面を作ってその上をキャラクタが歩き回れるプログラムを作ったんだけど
地面を生成する際に必ず必要になる地面の各頂点の座標だけで1面につきfloat1つ分で4byte取られるんだよね
そこでふと思ったんだけど
エルダースクロール2ってどうやってそこらへんの情報を扱ってるんだろ
あのゲームのマップの大きさを計算してみたら一辺317Kmもあるみたい
1面を5m四方として扱ってもマップ全体を表すのに16078240000byteも必要
エントロピー圧縮しても1/15位が限界だと思うから約1GB
本当はこれらにさらに木や草の位置、地面のテクスチャの種類なんかが必要なんだよね
それなのにtes2のデータサイズを見ると160MBしかない
何かマップ設計自体が特殊なんだろうか

592 ：

常にそのデータをメモリ上に保持しておかなければいかんわけじゃないだろ……
100km先のデータなんて近づいてきたら読めばいいじゃない

593 ：

floatじゃなくてhalf floatなのかもしれん。これだけで半分になる。
あとは、エントロピー符号化の前に、
曲面補完とか使って圧縮かけてるのかもしれない。
ビットマップで曲線を保持すると解像度分のデータが必要だが、
ベジェ曲線なんかで表せば、上手くいけばハンドル数個分で済む。
FUELなんかはたぶんこういう方法使ってて、川が途中で途切れてたりするところが目立つのはそのためだと思う。
全部俺の勝手な予想だが、いろいろ工夫はしてると思うよ。

594 ：

>>590
ん、ごめん。判りにくいな〜と思いつつ手抜きしてしまった。
こんな感じのコーディングを想定していました。
class Inventory : IGameData<Item> {
　　static List<Item> itemList;
　　//クラスメンバ
　　Character character;
　　//プロパティ
　　public int Count { get {
　　　　int num = 0;
　　　　for(int i = 0; i < itemList.Count; i++) num += (itemList[i].Character == this.character)? 1 : 0;
　　　　return num;
　　} }
　　public Item this[int no] { get {
　　　　for(int i = 0; i < itemList.Count; i++) if (itemList[i].Character == this.character) if (--no < 0) return itemList[i];
　　　　throw new Exception();//noがオーバーしてたら例外（とかreturn null;とか）
　　} }
}
class Item { public Character Character; }
class Character { Inventory inventory = new Inventory(this); }
結局、呼び出す側からの見た目は、
class Inventory : List<Item> { }
class Character { Inventory inventory = new Inventory(); }
とあまり変わらないんだけどね・・・

595 ：

>>592
そういう問題ではないんだけど、マップの構造設計を考えるとそこも考えなきゃいけないと思う
>>593
ベジェ曲線・・・確かに全く別のアプローチ方法で面白いかも・・・
ベジェ曲線を3次元で表現するのかX、Yどちらかに絞って高さだけを表現するのか
ただそうするとどのタイミングでどこの情報を取ってくるかが問題になるのかな
単純に複数の面(25個ずつくらい)をまとめた構造体で管理してたんじゃベジェ曲線の利点が薄まる？
もう少し調べてみます。アドバイスありがとう

596 ：

>>595
以前、フラクタルで地形を作成するプログラムを書いたことがあるけど、
動的にマップデータを生成するのはどうだろう？
ランダムシードを固定値で持っていれば、再現性もあるかと思うし。

597 ：

言葉足らずすぎる気がしたので補足ｗ
広い領域を、例えば５キロ平方に区切って、
隣の領域と連続性を保つため外周だけはデータを保持。
その内側の凹凸は動的生成、って意味です。

598 ：

>>596
それ単独では制御が難しいかも。町を作りたいのに平らな地形が得られない、とか。
平らな地形の部分だけ追加データで入れるとかするのかな。
>>595
線→面への拡張は、概念はそんなにフクザツじゃない。
補間方法はベジェじゃなくてもスプラインでもいいけど、単純にXY両方でデータの無いところを補間するだけだと思う。
ただ当然実行時計算量とデータサイズのトレードオフはある。
TES2は分からんけど、TES4と同系統のエンジンのFO3なんかみると、
たまにそういう曲面のエッジが誤差か調整不足かで浮いてるところがマップのところどころにあった気がする。
これは曲面補間かどうかは分からないけども。
SourceEngineなんかも似たような技術が実装されてるし、けっこう昔からある技術なのかな？
Game Programming Gemsとか探したら取り上げられてるかもね。

599 ：

>>598
なるほど、ってことは、
街の地面：整地されてるから、メッシュを大きく平らに
平原とか砂漠とか：メッシュを大きく取って、細かい部分は補間なり動的生成なり
山岳みないな凹凸がある地形：メッシュを細かく
って感じに・・・
（と言っておいてなんですが、メッシュの大きさを変えるのは、プログラムが汚くなりそうｗ）

600 ：

>>599
偏った例で恐縮だけど、SourceEngineのディスプレースメントサーフェイスは
分割数は2,4,8とか2の倍数固定でそれほど柔軟ではないし、穴あけれないとか制約はある。
だからその辺はレベルデザイナーのほうで調節する感じ。
ただしスムージングはかけれるから、たぶん補間はしてる。
たぶんゲームエンジンはどれも似たような仕組みは実装してると思うよ。
ディスプレースメントなら頂点4つ(△ポリゴン2つ)＋差分テクスチャマップをシェーダーにぶち込んで高速処理、とか
そんなんだと思う。
あくまで予想だけど！

601 ：

特定の条件がなんなのか不明だけど、eventListenerとかgetInputとかで良いんじゃないの
設計としてはおかしくはない

602 ：

誤爆失礼

603 ：2012/10/13

保守