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

1 名前：名前は開発中のものです。 [2008/05/23(金) 21:10:59 ID:8M1gqhPX] 具体的なゲーム名を挙げて、 どのようにクラス設計をすればよいか、 継承・委譲関係はどのようにすればよいか、 使えそうなパターンは何かなど語るのもよし。 自作ゲームの内容とクラス図を書いて 改善案を聞くもよし。 設計に関して困ったことを質問するもよし。 関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。 大いに語れ。 前スレ pc11.2ch.net/test/read.cgi/gamedev/1155209226/ テンプレ追加事項あったらよろすく 109 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 11:44:02 ID:qX1NKMBA] 俺は、海外のインディゲームデベロッパーを結構チェックしているが、 絵がきれー、とか音楽すげーとかってなかなかないよ それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。 たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり（日本かとおもうけど、海外の話だよ） 110 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 11:44:46 ID:qX1NKMBA] 連投ごめん、音楽すげーはけっこうあるわｗ まあ俺がテクノ好きなだけかもしれんけど 111 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 13:29:28 ID:E9y2cnx1] 雑談スレに移動すべきだと思うけど二つだけ。 そもそも一国と世界を比べることに意味があるのかな。 言語障壁はローカルのコミュニティが栄えない理由にならないよね。 112 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 20:57:12 ID:UjEcMe9W] >>108 >>109 >>99のリンク先のコンテンツを見た上で、のたまっているのか？ 優れたリソースの利用可能性も、市場発展度合いの目安。 113 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 21:01:08 ID:rip3o1Gr] 日本の職人はゲームじゃなくて、ニコ動に集ってるだけだろ。 114 名前：名前は開発中のものです。 mailto:sage [2008/07/05(土) 21:23:48 ID:hYTfj9Xn] 方向性が違う物を比べても何にも成らないのに 115 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:07:36 ID:Gwo/Ylg2] >>80だが >>99 繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。 IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる ＞英語圏の方が日本よりも、アマチュアというかインディーズ（同人）市場が発展しているという印象を受ける ＞ttp://www.gametunnel.com/ ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか？してないだろ 特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる （下半身産業が絡んで不公平になるので全年齢のみで比較してもいい） ＞日本のフリーとかシェアは（中略） ＞グローバルな金儲けには関心なく、村市場（コミックマーケット）で満足してしまっている奴が多いんだろうな。 だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに 「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい？毎日好きでもないものを延々作らされてる 腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために 真剣に取り組んでるよｗ素人に八つ当たりする前に自分の胸に手を当てて考えろっての。 あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。 他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない 弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい 116 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:20:54 ID:Gwo/Ylg2] 外国すげぇ日本だめ論が好きな連中は日本の文化を否定する傾向にあってあまり好かん。 アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。 趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。 エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。 世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。 あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい 117 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:32:11 ID:ADZbZeYt] 日本人はどちらかといえば何か分からんが動いたから良いやって人が多 い気がするね。 昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ てるって何かの本に書いてた気がしないでもない。 SEやらPGやってる人なら分かると思うけど「なんで？どういうこと？」っていう のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア には向かないと思う。 まぁ外人云々じゃなくて正確か？？ 118 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:33:49 ID:Gwo/Ylg2] ただし、技術屋を志向する趣味プログラマは技術的ガラパゴス状態に陥ったら負けだな。 この点だけは外国すげぇ日本だめ論を展開するアジテーター共の意見に一理ある。 お国柄のせいか虹派が多数派の我が国ではアマチュアプログラマに要求される 技術水準はそれほど高くはない。それはそれでいいのだが、その技術ガラパゴスの中で タスクシステム知ってる俺tuee状態とかになっては格好が悪い。俺tueeする時はもっと 見識を広めたほうが良い 119 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:34:25 ID:Gwo/Ylg2] >>117 かぶったスマン 120 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:34:55 ID:7QhD5OiR] 熱く語ってもらってるとこ悪いけどお前らスレ違いだ 121 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:42:02 ID:Gwo/Ylg2] ああ、悪い。次に長文レスするときは↓に投げることにする 現役開発者が質問に答えるスレ pc11.2ch.net/test/read.cgi/gamedev/1214321147/l50 122 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:44:51 ID:VtZ5ywY1] >>115 ＞腹いせに素人に因縁付けてるようで感心しないな。 感じやすいんだな。 一つ俺が言いたいのはさ、スキルがあるんだったら、 小規模ながらもグローバルな金儲け（変な言葉だ）に挑戦すること考えた方が、 面白えんじゃねえのってことだよ。 自身の嗜好に自信がないって？ じゃあ、そいつは一体何をやっているんだ。 123 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 00:48:46 ID:mek7cAwO] スレ違いだボケども 124 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 01:43:19 ID:D1fZ4Z3G] > SEやらPGやってる人なら分かると思うけど PG以外がこのｽﾚに居るのかと問い詰める必要があるな 125 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 07:26:44 ID:XCulGsMF] すみません。話を脱線させた一人です。。。 小さな会社でケータイゲー作ってる業界人です。底辺です。分かってます 俺も職場の仲間はみんなゲーム専門学校卒です。 英語とか読めないしGPGの日本語版も難しすぎてわからないので や○う○おさんの本とかCマガのタスク記事が職場のバイブルです。 某スレでタスクシステムが馬鹿にされて自棄になってて 俺の職場のレベルが低いのはきっと日本の閉鎖性のせいだと 考えるようになってました。 だってPS3とか箱○のゲーム作ってるクライアント（大手です）は 自分たちのノウハウを俺ら底辺には絶対教えてくれないし。。。 発注したケータイゲーをおとなしく作ってろって感じの扱いです。。。 ぜんぜん頭よくなれそうにない知育ゲーとか糞つまんねー クイズものばっかり作らされて気が狂いそうです。。。 126 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 07:43:01 ID:XCulGsMF] 日経のサイトのベーマガ２．０の記事も読んでました。 ベーマガがどんなものか実は知らないのですが日本の アマゲーコミュニティがないから悪いって言ってたので 我が意を射たりって感じでした。 土日スレで投稿してましたがいつも荒らされてました。 PCゲーム板のフリゲ厨とか氏ねと思ってました 俺は今もＤｉｒｅｃｔ３Ｄとかわけわかんないです。そういうのを 教えてくれるベーマガみたいなものに出会えなかったから ファミ通の特集記事のゲーム専門学校すごいと思って 高校の先生の反対を押し切ってゲーム専門学校に行きました。 でも専門学校の講師も３Ｄ苦手でした。 おまえらには３D無理だから２Ｄで卒業制作作れって言われたので 言う通りにしました。今思えば先生が分からないもの作られると 質問されても答えられないから嫌だったんだと思います。 ゲーム専門学校に行ったことをすごく後悔してます。 ファミ通氏ねと思いました。きっとベーマガがあれば俺の人生 違ってたかもと思いました。やっぱおまえらが悪い 127 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 07:59:00 ID:XCulGsMF] すみません。ついカッとなってまたスレ違いのこと書いちゃいました 消えます 128 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 08:43:38 ID:S3/2UtrA] ネタじゃなかったら真面目に一度精神科に行くべき。 明らかに躁鬱の傾向が見て取れる。 過度のストレスで脳に器質的な損傷が出来てるかもしれん。 129 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 09:01:33 ID:VtZ5ywY1] >>123 何も語れない馬鹿よりはマシ。 130 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 09:28:24 ID:I4JuM713] まあ、消えなくていいからまた、スレ違いじゃなくてよさげな情報あったら教えてくれよ 131 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 10:03:51 ID:4WjvpweZ] >>129 さすがにそれはねーよｗ スレ違いでも知識をひけらかすほうが賢いと？ まあ、あまり過疎ってもらってもつまらんのだが・・・ 132 名前：名前は開発中のものです。 [2008/07/06(日) 13:03:17 ID:cXpJQpiz] tunnelでおすすめのゲームを教えてｋれ 133 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 15:04:16 ID:ZiAdcqL1] VIPから来ました ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて 134 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 16:19:57 ID:le8Gr2pO] いや、作者じゃないと殴り込めないわけだが 135 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 16:49:47 ID:NhLrwJLQ] おかしな奴の言い分もわかるぜ 日本の企業は総じて、コミュニケーション能力だのなんだの わけのわからない能力やノウハウを好んでそれを要求するくせに それらを他人に教えるようなことはしないからな、ヒントすらも 異常なほど排他的だ 数年前に某大作RPGの下請けの社長様が 「3Dできる奴なんて腐るほどいる死ね、コミュニケーション能力のない奴は死ね」(意訳) って新聞記事に載せてたの思い出した 笑える、うひゃ 136 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 17:01:01 ID:a3zGOuXr] マ板でやれっつの あーあ 137 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 17:06:30 ID:NhLrwJLQ] ほらクソども設計について語れや レイヤスーパータイプは class Devicer { static Device device; } で、スーパークラスとしてDevicerを使うことだ覚えとけ Application Controllerは class AP { View GetView(入力と状態値); Command GetCommand(入力と状態値); } 引数に入力情報や状態を判断する値を入力すると それに適したViewやModelに対するCommandを返すものだ 覚えておけ、クソども 138 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 17:44:48 ID:bleemPMj] みんな独自のウィンドウマネージャー(画面管理)クラス作ってるのかなあ 139 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 22:29:37 ID:mQf6Jrcq] >>135 良いこというなぁ。 禿同。 社長に。 140 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 22:41:15 ID:NhLrwJLQ] シーン遷移をきれいに実装したいという話なら、俺は否定するぞ ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない 後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない こういう部分に、色々な知恵を絞ったコードを書くことに意味はない 逆にそのクラスの為に他の部分にしわ寄せが行って、 難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む 無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる やるんだったら他の部分に影響を及ぼさない程度にしておけ 無意味に分断しすぎて複雑にするな 141 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 23:15:17 ID:bOQhFRQW] >>140 めんどくさいのは、シーン遷移よりキャラクターの状態遷移だよな。仕様変更が わりと発生しがちな部分だし。 142 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 23:34:33 ID:NhLrwJLQ] >>141 同感だ そういう箇所に擬似コルーチンを使ってる 前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ 単純ならそのまま状態変数で適当に書いてもいいが コルーチンのほうが書いてて楽しいな 143 名前：名前は開発中のものです。 mailto:sage [2008/07/06(日) 23:47:58 ID:bleemPMj] 状態が変わる時は自滅させてから、見た目同じで中身は別の敵オブジェクトを生成するとか。 144 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 00:57:38 ID:FUQ1BpEu] >擬似コルーチン 浅学な俺にコレについて詳しく 145 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 04:37:03 ID:ohkg3t4w] >>144 以前けっこう調べた俺がコレについて詳しく コルーチン 　並列実行をさせない（できない）スレッドのこと。外国人はコーディングの際 coro と略すこと多し。 　メリットは、排他処理が不要、ネイティブスレッドに比べてコンテキスト切り替えが軽い（もちろん実装次第だが）。 　デメリットは、切り替えタイミングをプログラマが指示する必要がある、CPUがデュアルコアでも恩恵が受けられない。 　最近ゲーム関係でよく聞くようになったが、アルゴリズム的にはすんごく昔のクヌース本にも載っているらしい。 　マイクロスレッド、協調的マルチスレッド、ファイバー（Windowsのみ）、などの言い方があるが、 　ゲーム業界ではコルーチンが一般的かな？ 　ネイティブスレッドではないので擬似的なスレッドと言えるが、「擬似スレッド」という呼び方は 　よく混乱を招くようなのでお勧めしない（後述するように、スレッドを擬似的に再現する手法は他にもある）。 　Ｃで実装する場合は、たいてい手動でスタックポインタを切り替えることで実現する。 　主な実装： 　　アセンブリで実装：作成難度高、コンパイラ依存、移植性なし、使い手にもスキルが必要（スタック溢れ対策など） 　　大域ジャンプで実装：作成難度中、コンパイラ依存、やや制限がある 　　スクリプトで実装：スクリプトのVM（例えばLuaやSquirrel）に任せる。使うのは簡単で制限も少ない 擬似コルーチン 　コルーチンっぽいことを擬似的にやること（を、>>141は言っているのだと思われる）。 　主な実装： 　　マクロで実装：作成難度低、移植性高い、制限多い、読み手には超分かりずらい 感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。 以下は直接関係ないので、混乱するようなら読み飛ばして。 ・昔のMacOSやWindowsで言うところの「プリエンプティブでない」マルチタスクの仕組みは、コルーチンの親戚。 ・RubyやPythonのスレッドも、一般的な実装ではネイティブスレッドではなく擬似的なスレッドらしいが、 　明示的にコンテキスト切り替えを行うわけではないのでコルーチンとは異なる。 　Javaではこのような擬似的に実装したスレッドをネイティブスレッドに対してグリーンスレッドと呼ぶ。 146 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 07:19:25 ID:1RaeXbIY] コルーチンを使わなかった場合 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 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 07:20:47 ID:1RaeXbIY] ミスった orz for (i = 0; i < 100; i++) { 　GoToLeft(); yield; } for (i = 0; i < 100; i++) { 　GoToRight(); yield; } 　： 148 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 07:24:44 ID:1RaeXbIY] コルーチンは、タスクシステム総合スレで話題が出てたね 149 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 08:00:36 ID:FUQ1BpEu] あー、マイクロスレッドのことか！ それなら一応分かるような気がしないでもない でもC++じゃあ無理だよね・・・ 150 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 08:00:37 ID:0ql4peFo] fiber? 151 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 09:17:09 ID:1RaeXbIY] >>149 ネイティブに落とされる言語だと実現するにはコンパイラ依存になるんじゃないのかなあ？ スタックいじるし。 >>150 Windows用語ではそうかと。 てか、要点は>>145に書いてあるなｗ うまいまとめだ 152 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 10:04:53 ID:BeipJAsv] コンパイラ依存じゃなくてアーキテクチャ依存だ。 setjmp()でコンテキストを保存したあと、保存したコンテキストの スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。 C++だけで実装可能だぞっと。 153 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 13:31:17 ID:yE1V62Sc] fiberはRubyでも使われてるよ スレッド（糸）より細いものだからファイバ（繊維） あとJavaScriptにも1.7から導入されてるぜい 154 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 22:11:23 ID:oT4ePMXj] マイクロスレッドは理想だけどそこまでトリッキーなことやる踏ん切りが付かない 155 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 22:26:27 ID:yE1V62Sc] やっぱスクリプト以外ではやる気しないな 156 名前：名前は開発中のものです。 mailto:sage [2008/07/07(月) 22:30:56 ID:nV3j1Oo/] タスクシステムはコルーチン実装の一つだね 157 名前：名前は開発中のものです。 [2008/07/07(月) 23:47:06 ID:ZC8HSbxq] コルーチンの「コ」って子供の子って意味じゃないよね？ 158 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 00:00:56 ID:2Ffcfnsn] cooperativeと一緒のco-だろ？ 159 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 01:20:29 ID:DPfKtgJc] 俺はオブジェクト指向で、シングルスレッドだな。 常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。 また一方で、オブジェクト発生イベントのリストを持っていて、 順次、メインループにオブジェクトが登録されていく。 この「オブジェクト発生イベントのリスト」はシーンに相当していて、 シーンを切替えたければ、今登録されているオブジェクトを破棄して、 イベントのリストを差し替えるだけでいい。 while (1) { 　　for i=0... 　　{ 　　　　オブジェクト[i]->行動(); 　　　　オブジェクト[i]->描画(); 　　　　オブジェクト[i]->当たり判定(); 　　} 　　イベント発生() } 160 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 17:13:03 ID:8FRUZW5m] >>159 PACに似てるが違う、オブジェクトの追加に強そうだが そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感 ドメインロジックのテストを行うときにビューが関わってくる 逆にビューのテストを行うときにドメインロジックが関わってくるため テストに多大な労力がかかる事が予想される 常にプログラム全体をテストしなければならないため、試行錯誤すると死ねる render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き 2Dにしても描画に関する処理が単純でなければうまく動かないだろう 規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め 私はお勧めしない、追加のメリットが多大である場合は考慮に値するが ゲームには不向きだと思う、特に3Dの場合は 俺は怖くて使えない 161 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 17:19:39 ID:8FRUZW5m] >>160 追加 リソースの追加が障害にならなければロジックのテストは問題ない場合もある やるんだったらそんな半端な構造ではなく 関連まで含めて、PACアーキテクチャ使った方がよくないか? 162 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 22:56:21 ID:8FRUZW5m] 小規模な状態遷移の実装は 今持ってる手で四つ 1.擬似コルーチン 2.スレッド 3.スクリプトで隠蔽したスレッド 4.通常の状態変数による管理(State含む) 設計が明確でない初期のもの、プロトタイプ 又は小規模な場合の初期のとりあえず書いておくコードに向いているのは 擬似コルーチン又は状態変数だろう まだ設計方針が明確に決まっていない場合や試行錯誤しなければならない状態で スレッドやスクリプトの導入を決めるのは早すぎる、リスクが大きい ある程度、方針が固まってから適切なものを選択するのがいいだろう 状態変数での管理が大手を振っているのも 初期コストが低いという部分が大きい このため、状態変数やState以外の選択肢は簡単には普及しないだろう ただし、スレッドの積極的採用が処理速度向上に繋がるのならその限りではない 163 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 23:04:46 ID:gy2iNnCl] コルーチンで擬似ってどういうこと？ 164 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 23:41:41 ID:8FRUZW5m] >>163 擬似じゃなくていいのか、訂正 1.コルーチン、又は擬似のそれ 言語仕様に含まれてるときはそのままコルーチンとして呼び出し c/c++の場合は以下のものが使える、又は自分で作る www.chiark.greenend.org.uk/~sgtatham/coroutines.html それ以外なら ソースコードを変換するプログラムでも作る gotoやthrowやswitchやラベルなんかが含まれない言語では無理、又は面倒くさい 165 名前：名前は開発中のものです。 mailto:sage [2008/07/08(火) 23:46:18 ID:iq4s5004] まぁいいけど、ライセンスがGPLで良けりゃこっちを使おうぜ。 ttp://www.xmailserver.org/libpcl.html 166 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 01:10:17 ID:vZNCPgy9] 言語機能として付いてないC++で無理やんこやるのはいろいろ怖い気が すんごい便利そうなんだけどなぁ・・・ 167 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 07:23:21 ID:eQNI5n3r] そこまでするならスクリプト組み込んだほうが よっぽど安全で楽だと思うけどな 168 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 09:40:38 ID:nYED4jrh] >>162 スレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。 ＞小規模な状態遷移の実装 >>146のような、行動予約の状態遷移を前提にしているのかな。 だとしたら、もっぱら自分は、C++で、 ＞4.通常の状態変数による管理(State含む) と動作制御用独自スクリプトだな。 基本は、ゲーム開発で言うところのタスクシステムで処理。 各オブジェクトは、単一クラス中に、状態ごとに処理関数（メンバ関数）を用意する。 フレーム毎に、その時点の状態に該当する処理関数を、１回ずつ呼び出す。 その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。 状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。 動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。 表現くどいけど、悪しからず。 169 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 17:57:35 ID:7MZGZOjk] 巣に帰れ タスクシステム総合スレ part2 pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50 おまえらタスクシステム信者がクソでカスでゴミクズな理由は 自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ または、それを考えようとしないところだ ただ使えばいいと思い込んで、それで完結している 考えることを放棄したおまえらに設計能力を向上する機会はない 戦略のない戦術はただのテロだ 170 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 18:38:12 ID:vZNCPgy9] ひどいな・・・ なんでそんな暴言が吐けるの 171 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 18:47:18 ID:vvjjLorC] 良く知らんがタスクシステムって言葉が出ると荒れるようだ なんかそういうgdgdな経緯でもあったんだろうな 172 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 18:55:55 ID:nYED4jrh] >>169 pc11.2ch.net/test/read.cgi/gamedev/1215129226/4n 173 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 18:56:55 ID:iC3IHDcB] >>171 ゲーム業界の造語みたいなものだからな。 OS屋に言わせると「なにそれ？プ」というものらしい。 まあ一定60FPSとか30FPSといったフレームで常に動いてて 物の動きとか制御してるのがOSがタスクを処理してるのに見えるから そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人 が言い始めたのそもそもらしい 174 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 19:21:37 ID:eQNI5n3r] やっぱり顔真っ赤にして噛み付くヤツが出ると思ったよ しょうがないからその辺の単語は誤魔化して話進めてくれ いつまで経っても話進まねーからな 175 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 19:22:14 ID:anjhk7B8] 名前負けしてるよね、完全に。 176 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 21:10:22 ID:7MZGZOjk] 話が進むわけないだろ 言ってる奴が、メリットもデメリットも把握していないんだから ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない 宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ 誰かこれを理解してみろクソが 177 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 21:12:45 ID:iC3IHDcB] 噛み付いてはないけど・・すまんな まあ俺的にはそんな何とかシステム（自称）はどうでもいいよ。 市販のゲームでも売り出す際は自称ｘｘｘシステム採用とかいう 元からそういうの好きな業界だし。 178 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 21:30:52 ID:4OXXlyYN] >>176 少し落ち着けよｗ ＞宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ お前はこういう事を言うやつに馬鹿だのアホだの必死に噛み付くのか？ 俺はスルーするけどな 179 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:16:56 ID:EYwlC03l] 「面白いこと書いた」と思ってるんだろうなぁ。 端からはただのバカにしか見えてないけどね。 180 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:19:25 ID:SF8ehHxO] >>173 ＞OSがタスクを処理してるの ってどんな実装してるの？ 181 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:22:48 ID:uQp1o0/n] タスクシステムってゲームプログラミング固有のもんじゃなくて リアルタイムOSとか便利なもんがなかった時代の組み込みシステム開発に 起源があるような気がする。 まあ、C++で真っ当にオブジェクト指向やってれば、こんな古臭いもんを 有難がる必要はないと思う。 182 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:23:19 ID:iC3IHDcB] >>180 そりゃ・・・その辺はがんばって勉強して キューだとかスレッドだとかタスクだとか タイムスライスだとか まあ同時に複数のものが動いてる（ように処理してる）風に出来るものかな 乱暴な言い方だけど。 183 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:24:41 ID:7MZGZOjk] そろそろ潮時か 君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった 有益だったぜw また暇なときに挑発に乗ってやる この完璧な捨て台詞を覚えておけよ 184 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 22:48:57 ID:XmNOce7Z] >>183 巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。 感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。 会社でタスクシステムで組みたいと同僚が言ったとして、 烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。 ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。 185 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 23:14:23 ID:nYED4jrh] ＞7MZGZOjk なんというか、要するに、 ただの孤独なレス乞食。 もしくはタスク・スレへの誘導係。 マンネリだな。 効率的な挑発方法については、再考した方がいい。 186 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 23:17:00 ID:md3RJLJr] タスクスレに託すか。 187 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 23:26:06 ID:30d6bQh7] コードが繁雑になって来たので、大革命を起こしたら 以前より良い設計ができない上に、収集がつかなくなった。 svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。 188 名前：名前は開発中のものです。 mailto:sage [2008/07/09(水) 23:50:08 ID:XmNOce7Z] >>186 189 名前：名前は開発中のものです。 mailto:sage [2008/07/10(木) 00:33:17 ID:rFEYqRAa] >>186 神は自らタスクる者をタスク。 190 名前：名前は開発中のものです。 mailto:sage [2008/07/10(木) 00:51:19 ID:A+tXgG+V] >>180 タスクスレの話題を続けるのはよくなさそうなので情報だけ pc11.2ch.net/test/read.cgi/gamedev/1196711513/456 OSだからできることを思いっきり使ってるんで 管理手法以外はあまり参考にならんよ。 OS自体に興味があるならOS板にいくといいよ 191 名前：名前は開発中のものです。 mailto:sage [2008/07/10(木) 00:54:31 ID:MjVgJsdw] PG系隔離スレの2大巨塔でタスク厨の押し付け合いイクナイ！ 192 名前：名前は開発中のものです。 mailto:sage [2008/07/10(木) 05:56:13 ID:nnoBQqoI] Google，自社開発のデータ構造化ツール「Protocol Buffers」を公開 ttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/ 193 名前：名前は開発中のものです。 mailto:sage [2008/07/10(木) 07:41:02 ID:99kxezye] >>186 【小さく審議中】 　　　 ,､_,､　 ,､_,､ 　 ,､_('・ω)(ω・`)､_,､ 　('・ω)uﾟ 　ﾟuu(ω・`) 　 ﾞuuﾟ(　'・) (・`　)uu' 　　　　ﾟuuﾟ 　ﾟuJ 194 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 00:51:10 ID:eBw+YtUV] 素人です つくりかけのゲームってどうやって動かしてテストするんですか？ 195 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 01:06:26 ID:47vlxomf] ワタクシ ハ インクリメンタル ナ カイハツ ホウシキをとっているので ちまちまと小規模な物を作って、それを拡張していく形になります。 例 第一段階： ウィンドウを表示する 第二段階： キャラクターを一つ表示する 第三段階： キャラクターを動かしてみる 第四段階： 飽きる 196 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 01:25:52 ID:eBw+YtUV] >>195 なんで途中までカタコトなんですか？ そういう個人規模でなくて、複数のPGで役割分担してる場合はどうするんでしょう？ 197 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 01:29:50 ID:R4nPLnnD] そんなことシロウトせんでいいいよ 198 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 02:53:02 ID:lqrHuCir] 動くところまで作ってからテストする 199 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 03:04:31 ID:uUrGa3AK] 改めて言われるとあれだな 他にやりようないな 200 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 03:23:29 ID:eBw+YtUV] >>198 他人がつくったクラスがないと動かない場合はテストできないのでしょうか？ 201 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 03:29:10 ID:uUrGa3AK] つ 単体テスト いや出しゃばった　俺はweb系なので実情は判らん まあロジック側は業種問わずどうグズったところで、 「何々渡したときに何々返す関数作ってー！」しか分業方法ないと思うけど 202 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 03:29:54 ID:edzJ8FGN] たぶん、作りかけってのが何処までか分からんけど 目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。 プログラムの作りかけを動かす＝エラーが出ないで動く　なので 203 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 03:32:16 ID:edzJ8FGN] wiki.game-develop.com/ wikiのチュートリアル→段階的学習でもやってみては 204 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 04:56:24 ID:tw1/nxGs] >>200 そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。 プロキシとかスタブって聞いたこと無いかな？ そもそもあなたの言っているテストとは何をどうするテストなのか、 自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。 205 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 09:43:53 ID:47vlxomf] >>200 もし私がプログラマなら、担当部分を動かすための テストプログラム書いてます。 だから、それを見せてもらったら、大体どんなことができてるのか 把握できるんじゃないかと思います。 早い段階でCVSやSVNによるコード共有にも 慣れておくと幸せになれるかもしれません。 統合テストの段階になってからでないと 全体のMakefileが書けない、 リンク作業もできないのではどうにもなりません。 今のうちからコードを共有して、 常に全体がコンパイル/リンクが可能であることを 確認できる環境作りが云々、、、、、、、、 206 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 09:51:14 ID:timDAMYM] >>204 >>200は外注や営業職の言い訳で多発するんだよね。 あんなのはまともに相手するのも無駄。 「スタブ要るじゃん。　スタブ供給してくれないとコストにあわないんだよね」系で、素で言ってのけやがる。 超ウケルんですけど。 こういうのに仕事を与えないようにするのが業界の為だろ。 　政治的な理由により取引継続となったら、「スタブの作り方を指導しますから、 その講習料として、スタブ作成代を相殺ですね」ぐらいしか案が無い。 ・こちらはスタブなんて、要求仕様の一部で料金内。jk ・カス会社は、どちらも追加料金や有料。 ・解決してなくても解決！！！！ 207 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 10:22:09 ID:L3kGAfa0] >>194 作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。 RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、 テスト用のメニューからそれぞれ起動できるようにするとかな。 208 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 10:49:52 ID:UM30DsAY] 作業分担？ 全員が全体を上から下まできっちり把握した上で、 常に連絡を密にし、お互いが何をやってるのか理解しつつ、 各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。 209 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 11:17:51 ID:L3kGAfa0] >>208 全員が全体を把握できるのは、せいぜい3人ぐらいまでだな。その先は ヒエラルキー作って、パート毎に管理業務やる人間を立てないと無理。 210 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 13:47:03 ID:DAEU2DrC] 趣味ゲだと3人超えのマが介在するゲーム開発って ほとんどないしな。大半はマが1人、多くて2人で>>408方式 ツーといえばカーの黄金タッグ。あ、ああじゃいる 211 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 13:48:37 ID:DAEU2DrC] ×>>408　○>>208 212 名前：194 mailto:sage [2008/07/13(日) 14:07:22 ID:eBw+YtUV] 非常に参考になりました。ありがとうございます。 >>208 それ実際には各人に漏れやズレが出て手戻りが出るんで、大規模プロジェクトでは無理では 213 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 14:19:00 ID:sqmPpN2O] Cだったらmain()関数書いて実行して、デバッガ等で動き見るかな… 仕事（勿論?非ｹﾞｰﾑ）でやってたときも、自分で単体テスト仕様書書いてたんで、 こんなやり方でもOKだったｗ 個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、 中身を作っていくので、単体テストらしい単体テストはしないかな… とりあえず箱を表示するとこ書いて、テストして、 動かすところを書いて、テストして、…ってのはやるけどｗ 214 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 14:24:18 ID:RINNRPdb] 大規模が何人か明確じゃないし、作業形態もネット上だけなのか サークルのようなものなのか会社なのかもわからないから議論が発散してる フリーソフト作るのに主力のプログラマ2〜3人と、バグ修正や機能強化の パッチくれる人10人くらいでなら、MLとIRC使って>>208のような方針でやれてた 最初のバージョンはリリース済みで方向性が決まってたのが大きそうだ >>212 作業するタスクを割り振りはちゃんとやって、頻繁なイテレーションと 継続的インテグレーションやるっつうのは何人くらいで破綻する？ 215 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 15:08:38 ID:eBw+YtUV] >>214 １チーム１０人以下で、各チームにリーダー２人ぐらいで、２００人ぐらいのプロジェクトも回ってました。 素人なのでこれくらいしかわかりません。 216 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 15:15:30 ID:uaqPI4FP] >>215 プログラマの数は？ 217 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 15:23:34 ID:L3kGAfa0] >>215 まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の I/O 決まってれば、各人の作業は依存が少ない（DB に仕様どおりのテスト データ作れば良い)から、スケールしやすい。 基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような 設計をするかにかかってる。DB とかメッセージングシステム使う世界は、 そこで切れてることが多いから分けやすい。 218 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 17:47:09 ID:eBw+YtUV] >>216 150人はプログラマでした 219 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 18:56:00 ID:UM30DsAY] >>208は半分冗談、半分マジだったんだが意外と受け入れられてるｗ >>218 なんの素人なんだｗ ゲームでプログラマ150人規模って洋げーでも多分ないのでは。予算的に。 マジレスしますと、 小さい規模ならメインプログラマがほとんど一人で下位システムを作っちゃうし、 大きい規模なら別の部署が作るから、 「作りかけの状態でどうやってテスト・・・」という事態があんまり無いでつ 220 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 21:19:15 ID:Q/hESmSh] 大規模金融システムで、SEの数ってことならありうるが ゲームのスタッフロールにマが150人も並んでたら壮観だな ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人 サブプログラマが12人で残りは大半がデザイナー 221 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 21:20:02 ID:6QYOrVUt] ネトゲじゃねーの？ 222 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 22:39:48 ID:3VGnVE92] マ150人てどんなネトゲだよ。。。 223 名前：218 [2008/07/13(日) 23:00:22 ID:eBw+YtUV] ゲームのプロジェクトじゃないです。 詳細は言えませんが。 ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。 やはり手動でテスターがテストするんでしょうか。 224 名前：名前は開発中のものです。 mailto:sage [2008/07/13(日) 23:23:02 ID:UM30DsAY] 俺の知る限り、ゲーム開発では基本的にテストは無いです 単体テスト→結合テスト→受け入れテスト、みたいな流れは無い 昔ながらの職人的やり方というと聞こえは悪いですが、 衝突判定とか文字列処理部分のような仕様が明確な箇所なら 自動テストは有効だし実際にやっている会社もあるようだけど、 「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」 みたいな仕様書があったとして、それをテストする基準がないし自動テストできません なので大部分がデバッグチーム頼みです 225 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 00:00:22 ID:yOzfOKcB] 3Dの衝突判定ライブラリを書いていたときは、単体テスト使いまくりだったぞ。 >224 みたいな場合はどうしようもないけど、表示以前のコアな部分では 単体テストも結構使う 226 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 00:02:24 ID:IEzc7ZIH] グラフィックやサウンドが絡む部分は自動化は難しいけど ネットワーク部分やスクリプトの読み込み部分なんかは いくらでも自動化できるっしょ 227 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 00:10:58 ID:cIaZ6JxY] 一人で作ってる分には単体テストに拘る必要はないと思うな。 逆に（自分含めて）しっかり単体テストできるなら、複数PG開発も悪くないと思う。 　　　　　　　　　　　^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁ｗ テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな！ 228 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 12:30:06 ID:Hnt5WQTk] (NetBSDをOSに使ってる)リコーのプリンタの開発チームは PGだけで1500人だそうです 229 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 15:33:56 ID:xdO9+1xM] 数万行の同人ソフトしか作ったことないけど、ゲームってプログラムとしては割合小規模じゃね？ 乗っかってるリソースの量がとんでもないだけで。 実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。 ゲームシステム（シーン別）、描画系、サウンド系、ツールやエディタ系と分けていけば それほどカオスな状態にはならないイメージがあるけど。 もちろんプログラマの数の２乗程度の複雑性はあるだろうけど。 見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。 あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて そいつがほとんどの重要なコード書いてしまってそう。なんとなく。 230 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 15:36:32 ID:Hy149M4+] >>229 勘定系だってそれほど変わらんよ。 231 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 15:40:51 ID:0Th48wDt] RPGみたいないろんな要素のあるゲームのプログラミングってどこから手をつけていったらいいですか？ 232 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 15:47:11 ID:wxUymIt7] お好きなところからどうぞ 233 名前：名前は開発中のものです。 mailto:sage [2008/07/14(月) 16:22:48 ID:Hnt5WQTk] MSXのドラクエ２も大学生が一人で全部作ったんだよね 234 名前：名前は開発中のものです。 mailto:sage [2008/07/15(火) 13:15:33 ID:IiJYDS4l] RPGっていってもいまだといろんなシステムあるからな〜 古典的なドラクエ初期のように2Dオンリー チョンゲーに代表される3D使ってるクリックゲー 235 名前：名前は開発中のものです。 mailto:sage [2008/07/15(火) 13:29:25 ID:Hl1v93zY] P6のゼビウスは小学生が一人で作ったんだよね (発売時は中学生？) www.ne.jp/asahi/shiba/mic/nori/xevi_tiny1/index.html 236 名前：名前は開発中のものです。 mailto:sage [2008/07/16(水) 17:02:22 ID:WbuXgq6y] >>230 勘定系は、人数は増えるけど PM しっかりしてればカオスにはならんよな。 金回りの話なのでミスが許されず、テスト工数がやったら膨らむから、 プロジェクト管理大変だけど。 237 名前：名前は開発中のものです。 mailto:sage [2008/07/16(水) 17:02:59 ID:WbuXgq6y] >>231 メモリ管理 238 名前：名前は開発中のものです。 mailto:sage [2008/07/17(木) 20:17:04 ID:uAQ9zE97] >>231 要素の洗い出し 239 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 02:44:36 ID:gpI6Slf5] 先人のろくにコメントもないコードの解析だけで一ヶ月ぐらいコーディングもしないってことはありますか？ 240 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 02:56:31 ID:L2XNyVag] >>239 移植モノで、しかも元のプログラマが辞めて連絡取れないという条件で 一度やったことがある。二度とやりたくない。 241 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 03:05:04 ID:x+htBSIe] ソースがあるだけマシだよ アーケード版のバイナリだけ渡されて 「これをPS2に移植してください。ソースは紛失してしまいました。」 と言った大田区の某大手ゲーム会社があったそうな。 242 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 03:08:22 ID:ZbM+kRVz] >>241 すみません…　それ、たぶんウチだ orz 243 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 03:39:46 ID:18o8S9Zj] 最悪だなそれ MAMEでも進呈したほうがいいな 244 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 15:36:02 ID:gpI6Slf5] オブジェクト指向のくずれてるウンココードに出会ったらどうしますか？ 245 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 17:18:51 ID:g88tpUo2] 見なかったことにする 246 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 17:43:16 ID:1Zabkxz6] それ俺だな。 どうやれば良いか分からないから、手探りで書いてる(´・ω・｀) 247 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 22:53:25 ID:zgBZw03q] シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない？ 248 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 23:02:17 ID:Tcsf7iZJ] >>247 各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。 数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。 249 名前：名前は開発中のものです。 mailto:sage [2008/07/20(日) 23:02:30 ID:USb+9tXO] どういう意味？ シングルトンが2つも3つもあるならそれはシングルトンじゃないし シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど？ 250 名前：名前は開発中のものです。 mailto:sage [2008/07/21(月) 01:05:54 ID:9zclfNbN] >>247の文章が破綻 251 名前：名前は開発中のものです。 mailto:sage [2008/07/21(月) 14:17:23 ID:Y7Mzeak+] コメントにシングルトンと書かれてるのに２つも３つもインスタンスが 出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn 252 名前：名前は開発中のものです。 mailto:sage [2008/07/21(月) 18:53:57 ID:9zclfNbN] XBOX360, PS3, Wii　売れ行きに関係なく、開発しやすいプラットフォームはどれ？ 253 名前：名前は開発中のものです。 mailto:sage [2008/07/21(月) 18:54:50 ID:NGr1sFSW] 箱○ 254 名前：名前は開発中のものです。 mailto:sage [2008/07/21(月) 23:51:13 ID:yo6BY71C] 箱○は個人で十分開発できるからなぁ 255 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 00:00:52 ID:grvq6f3A] 箱○　天国 Wii 　 普通 PS3 言わせるなｗ という感じか？ 256 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 00:03:34 ID:9zclfNbN] >>255 詳しく 257 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 00:08:34 ID:zCVKhHD7] お前ら本当に3機種の開発ツール使ったことあるのかとｗ 258 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 00:21:20 ID:inlA4ozd] なんで個人開発限定なんだよ 259 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 00:35:03 ID:88jYUtHh] XNAのことを言ってると予想 260 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 02:21:06 ID:TRIzaodv] XNAの市販ゲームが出たってニュースは前に見た気がするけど 実際どんなもんなんだろ 261 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 02:44:01 ID:kfP9Fty3] サターンのSBL,SGLしか使ったこと無い 262 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 02:45:19 ID:zCVKhHD7] 360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話？ 263 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 16:12:48 ID:k5fUsZQo] Wiiはインターネットチャンネルどころじゃない 264 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 18:29:14 ID:c7QeI/ED] ゲーム機はDirectXを使うの？ 265 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 18:36:04 ID:Jekk8SUv] DirectXはMSだけ あ、Dreamcastという例外があるか 266 名前：名前は開発中のものです。 mailto:sage [2008/07/22(火) 20:52:26 ID:6od3yLDu] ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。 DirectXそのものを使ってるかどうかは知らないが。 267 名前：名前は開発中のものです。 mailto:sage [2008/07/25(金) 15:29:12 ID:9vpYBrtF] やってみて、無理と判断され、チームを外されることってある？ 268 名前：名前は開発中のものです。 mailto:sage [2008/07/25(金) 20:06:41 ID:66T6bhjF] >>267 板違い プログラマー＠2ch掲示板 pc11.2ch.net/prog/ 269 名前：名前は開発中のものです。 mailto:sage [2008/07/26(土) 01:19:05 ID:+2uolo1R] いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。 270 名前：名前は開発中のものです。 mailto:sage [2008/07/26(土) 02:28:02 ID:Esaqa0cW] アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね？ 271 名前：名前は開発中のものです。 mailto:sage [2008/07/28(月) 18:13:52 ID:9GhNVVJ3] 前者は状態フラグの配列なり持っておけば十分だろ 後者はなんだ？状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ 272 名前：名前は開発中のものです。 mailto:sage [2008/07/29(火) 14:37:45 ID:kHD6g876] >>271 なるほど。フラグの状態で、出るコマンドを制御すればいいのか。 サンクス 273 名前：名前は開発中のものです。 mailto:sage [2008/07/31(木) 18:14:30 ID:ucHp1Nqp] メニューコマンドってみんなクラス化しているもんなのかな？ メニューオブジェクトを生成してどうこうみたいな。 274 名前：名前は開発中のものです。 mailto:sage [2008/07/31(木) 21:20:41 ID:Gc2qBZ+R] ベタコードで記述したり構造体・配列のままより クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。 まーメニュー触るコードが一箇所ならどっちでもいいんでね？ ようはクラスにするしないじゃなくて 複雑さを無くしたり楽するためにどうするかだから。 275 名前：名前は開発中のものです。 [2008/07/31(木) 21:26:22 ID:NXR7vyyv] フロントコントローラーパターンとコマンドパターンでやります。 276 名前：名前は開発中のものです。 mailto:sage [2008/07/31(木) 21:38:09 ID:A+bu5iPx] メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは だいたい同じインターフェースを実装してる。 277 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:01:16 ID:yD3o9/Uf] クラスメンバって全部privateにしてgetterでしか取得できないようにするべき？ privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし 278 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:11:49 ID:yp70Uz6t] >>277 クラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。 たぶん何か間違っている。 279 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:14:41 ID:GzWnlC6Z] >>277 俺も同じようなこと悩んでて、気がついたら両方混在してた。 「これはクラスじゃない、構造体なんだ！」 って言い聞かせながらところどころpublicにしてたりw 280 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:22:47 ID:z2aBgJTr] 全部て 全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて 281 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:28:14 ID:4UGZmRTZ] 排他制御や状態確認が不要ならどうでもいいかもだけど コード書くのがマンドイだけなんじゃ？ まっしなIDEやプロパティのある言語つかうとかかな。 282 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:32:32 ID:GzWnlC6Z] >>280 例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。 仕様変更により、これら三つを「守備力」に統合しようとしたとき、 各メンバ変数へのアクセスが全てアクセサメソッド経由なら、 そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。 283 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:36:38 ID:z2aBgJTr] まて、そら元々アクセサの設計が統合可能だった場合だろ すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが…… 守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。 ちょっとエスパー疲れるぞ？ 284 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:47:59 ID:GzWnlC6Z] >>283 まあ、そういうこともあるさ(汗) ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。 あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。 シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。 285 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 00:54:19 ID:b/gVwGdZ] getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、 publicにした方が使う側は書きやすくでいいんじゃないの？と思うわけ。 ああ、でもsetterに値のチェックとか入れれるのか・・・・ 286 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:01:50 ID:b/gVwGdZ] しかもget()で取得するのが配列だったりすると、 取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、 非常に手間。 287 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:02:58 ID:tFL87oCT] とりあえずpublicで書いていって、 気が向いたらprivateにして、 それまで直接アクセスしたるところを、 大河の流れのように涙を流しながら直せば無問題。 288 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:07:26 ID:b/gVwGdZ] >>287 なるほど。あまりスッキリしないやり方ですが、しょうがないですかね。 いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。 289 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:09:03 ID:b/gVwGdZ] 特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。 290 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:19:38 ID:ua9U6ROu] c++での話だが速度はインライン展開されるの期待できるから問題ないし メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。 データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。 コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。 291 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 01:32:56 ID:b/gVwGdZ] >>290 こういうのって、センスが必要ですね・・・・。 ちょっと気になった事があるんですが、 自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、 わざわざgetterで呼び出して使う必要はないですよね？ class Foo{ private int a; public int get(){ return a;} public int calc(){ return get() * 2; } このようなcalc()の書き方に利点はあるのでしょうか？ 292 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 02:26:05 ID:ua9U6ROu] getter,setterがpublicなら外部参照する可能性があるということで 内部だけで使うprivateメンバ変数と意識して区別できるとか 関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。 命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。 293 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 03:52:45 ID:eorE7C0S] getterロボ 294 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 04:12:11 ID:gQhqelIh] メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。 まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。 295 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 18:37:49 ID:YDkT93Ih] >>294 今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。 296 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 19:02:25 ID:m4Vy5Xwk] 理想と現実はだいぶ違うよな 個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど それにこだわって完成させられない場合が多い気がする 297 名前：名前は開発中のものです。 mailto:sage [2008/08/01(金) 20:43:12 ID:mQpnHwPh] インターフェース中心の設計でプログラミングするんだったら プライベートメンバ変数にはアクセッサを用意すべき。 単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い メンバはパブリックのほうが良いかと思う。 298 名前：名前は開発中のものです。 mailto:sage [2008/08/02(土) 00:14:18 ID:n2w2ONnP] ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる（ﾄｲｲﾅw 299 名前：名前は開発中のものです。 mailto:sage [2008/08/02(土) 00:25:25 ID:MidBaG0Q] しかしgetやsetが乱れ飛んで読みづらくなることも 300 名前：名前は開発中のものです。 mailto:sage [2008/08/02(土) 06:50:04 ID:xZ8r6Jdx] >>299 プロパティが欲しいと。 301 名前：名前は開発中のものです。 mailto:sage [2008/08/02(土) 11:52:40 ID:eytLWJfu] C#はそういう意味ではスマートだなぁ 302 名前：名前は開発中のものです。 mailto:sage [2008/08/02(土) 23:43:30 ID:Pnu26psa] ゲームのシーン管理ってどうすりゃいいんだろう 303 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 02:53:56 ID:DVblpxWK] シーンつったってゲームによって全然違うからな もう少し具体的に 304 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 16:40:36 ID:HN+lqKwd] >>301 現行のゲーム機はまだC++なんだよな 305 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 21:47:19 ID:XQeDRsrL] >>302 シーンってのが何を指してるのかが微妙すぎ。 VMCに分けろじゃないけど、 Visual面だけでシーンを切り分けるのがいい時もあるし、 Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。 そうじゃなくて、Loopを二つぐらい回しながら、 片っぽでバックの処理こなしつつリアルタイム進行で、 残りで、Interfaceを回してくタイプとかもあるし、 結局どんな処理が必要などんなゲームなのか？ どれを止めると不味いか、どれは止めても復帰させれば問題ないか？ とかによると思う。 306 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 21:52:25 ID:qGD4tU/f] シーンて、どのゲームも タイトルー本編ーゲームオーバ てな感じジャンか。細かいところは違えども。 ゲーム全体の状態遷移をどうするか聞いてんじゃないの？ 307 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 22:00:54 ID:0ZCECk8O] おいどんのシーンは一種のタスクシステム(笑)で、 ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。 シーンの切替えはこのセットをまるごと取り換える作業なのですたい。 308 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 23:21:42 ID:HN+lqKwd] FFとかのムービーシーンの管理はどうやればよかですたい？ 309 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 23:31:02 ID:+gPnPllx] プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。 Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。 ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。 いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と 310 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 23:31:41 ID:+gPnPllx] あれ？　ここCG板じゃねえじゃん。 うわ俺凄く恥ずかしいマジレス？ 311 名前：名前は開発中のものです。 mailto:sage [2008/08/03(日) 23:31:45 ID:0ZCECk8O] >>308 ムービーシーンなんて作ったことないからわからんですたい。 脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。 312 名前：名前は開発中のものです。 mailto:sage [2008/08/04(月) 17:38:42 ID:OcXTlg2n] うさんくさか博多弁多かたいね。なんかぐらぐらこく 馬鹿にしないでください＞＜ 313 名前：名前は開発中のものです。 mailto:sage [2008/08/04(月) 23:28:56 ID:Vp8LYTR0] >>312 こらあげにまっことすまんかったぜよ。 314 名前：302 mailto:sage [2008/08/04(月) 23:40:39 ID:OTznAvMd] >>306 そうそうそんな感じ。 1シーンの処理は画像やその他のデータの読み込み、メインループ、 次のシーンに移る前の要らないデータの破棄のような感じにするつもり。 前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。 315 名前：名前は開発中のものです。 mailto:sage [2008/08/07(木) 02:18:10 ID:iFGNdN4x] 　　しーん… 316 名前：名前は開発中のものです。 mailto:sage [2008/08/07(木) 15:44:15 ID:J5sJkFaL] 【 審議中 】 　　∴∵ 317 名前：名前は開発中のものです。 mailto:sage [2008/08/24(日) 00:35:34 ID:kCbI2Ziv] （審議が長引いています。今しばらくお待ちください） 318 名前：名前は開発中のものです。 mailto:sage [2008/08/27(水) 21:03:35 ID:pp3RgERm] キャラクターの状態って、どうやって実装してますか？ 例えばマリオなら、 enum { SMALL, BIG, FIRE }; enum { STAR, NOT_STAR }; のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか？ stateパターンでは無理？？？ 319 名前：名前は開発中のものです。 mailto:sage [2008/08/27(水) 21:31:52 ID:tgwWcjRq] それだけだとモーション中とかが実装できないよね FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。 その辺の細部を徹底的に見つめていくと、 適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。 マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々 実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。 320 名前：318 mailto:sage [2008/08/28(木) 00:48:01 ID:Z+eKsEJG] >>319 いろいろ考えないといけない事多いですね。 この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか？ 状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。 ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。 でも、こういうケースでは、これがベストなのかなぁ。 321 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 01:16:45 ID:q3w3U78u] >コードが汚く感じてあまり好きじゃないんですよね。 好みと言うより仕方がない気も。 よくわからんなら下手に「なんとかパターン使うべきなのかな！」って 考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、 あとはめくらめっぽう試した方がいいよ。 ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。 で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねｗ 322 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 01:34:35 ID:O/+Qqs/2] 最初ってそういうの考えちゃうよな 世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ 今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる 仕事じゃないからこそだな 323 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 03:20:26 ID:tq3ymPlL] 関数ポインタで飛ばせば見た目は良くなるね。 可視性に問題が出てきそうで自分では使ってないけど。 324 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 09:12:41 ID:y2qhH8VC] そこで goto ですよ 325 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 10:11:26 ID:MS2hHN8x] 某シューティングツクール的にはそもそも「状態」という概念が無くて、 全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。 326 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 11:46:09 ID:Qlb2/Pnm] javaは関数ポインタ使えないんだ・・・・ 327 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 11:57:21 ID:MS2hHN8x] >>326 Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。 328 名前：318 mailto:sage [2008/08/28(木) 17:59:10 ID:Z+eKsEJG] >>321,322 汚いコードって書き直したくなってくるんですよね。 綺麗に書けないと達成感がないというか・・・。 また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたｗ)。 完成させることが第一と思っていてもついつい・・。 >>323,327 stateパターンですよね？ >>325 そういう方法でやってるところもあるんですね。 でも、オブジェクトのコピーが効率悪そう。 329 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 18:35:54 ID:CuTVRbF+] 自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。 それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。 つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる？ 330 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 19:03:37 ID:Jt4Hw7jN] むしろ可能な全ての表記法を試す勢いで！ 次のプログラムからは気に入った表記で。 昔の事は忘れましょう。 331 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 19:43:21 ID:MS2hHN8x] 人が書いたソースを読むのって勉強になるけど、読む気が出ない…… >>328 >stateパターンですよね？ パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。 332 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 20:37:26 ID:xedxyhWb] ＞状態という概念が無い 敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。 333 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 21:28:28 ID:MS2hHN8x] >>332 他に良い方法があるならどうぞ。 MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。 334 名前：318 mailto:sage [2008/08/28(木) 21:30:31 ID:Z+eKsEJG] >>329 コードの正しさ、綺麗さの２つは曖昧な表現で使うべきではなかったですね。 私はコードには、実行効率、保守性、読みやすさの３つがあると思っています。 今問題にしてるのは、主にこのうち後者２つです。 ただ、読みやすさは人それぞれなのかもしれません。 >>331 状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。 335 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 21:59:24 ID:O/+Qqs/2] 保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの？ 336 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 22:18:17 ID:qtCAmqfQ] ダライアス継承ってどんな継承？ 337 名前：名前は開発中のものです。 mailto:sage [2008/08/28(木) 22:22:03 ID:xedxyhWb] >333 爆発オブジェクトを自身と同じ場所に生成して、自身を削除する って認識で合ってる？ 338 名前：318 mailto:sage [2008/08/28(木) 23:04:17 ID:Z+eKsEJG] >>335 保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。 読みやすさは個人的な好みかもしれません。 保守性、読みやすさともにstateパターンの方が好きです。 でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。 うまい方法が見つからなければ、enumとifでいくつもりでした。 >>336 ダイアモンド継承の方が一般的な呼び方なのかもしれません。 仮想継承を使うことによって、継承グラフが菱形になるやつです。 339 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 00:44:03 ID:hcEje8O4] ダライアス継承なんて初めて聞いたなあ 英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。 あとダライアス（Darius？）はペルシャ人の名前のようだ。 まゆに唾つけて聞いておこうかな 340 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 00:50:36 ID:rESH+j3C] ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える 341 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 02:39:33 ID:VLtb7ZED] Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は 違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん 342 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 06:43:42 ID:gdp2Jatd] ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50 343 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 10:26:08 ID:ESvglHwU] >>337 合ってると思うよ。 問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。 そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ) 344 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 14:31:33 ID:UaA8GGvx] >>341 >ダライアスっていうとシューティングゲームしか思い浮かびませーん ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw 345 名前：名前は開発中のものです。 mailto:sage [2008/08/29(金) 14:34:13 ID:nV9hYRuE] >だったりしてw いやだったりしてっつーかそれしかなくね 346 名前：名前は開発中のものです。 mailto:sage [2008/08/30(土) 13:56:18 ID:vqGqt03L] ダイヤモンドが2個も3個もあるような継承のことか。 C3 MRO の解説でしか見たこと無いが。 347 名前：名前は開発中のものです。 [2008/08/30(土) 14:18:00 ID:gGJd0yLw] ドラえもん 「ことわざゲーム」 これはいいアニメ。 ... ドラえもん 藤子Ｆ不二雄 アニメ ドラえもん後期 ドラえもん本編 教育アニメ コメント非 表示推奨 緑 ... ex-co-jp.8866.org/gourmet/080803.rar 348 名前：名前は開発中のものです。 mailto:sage [2008/08/30(土) 14:23:18 ID:h7pQaJrI] なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク 349 名前：名前は開発中のものです。 mailto:sage [2008/08/30(土) 14:32:04 ID:hoYQeFVI] 夏休みも終わりって事さｗ 350 名前：名前は開発中のものです。 mailto:sage [2008/08/30(土) 14:40:33 ID:vqGqt03L] Bot使った宣伝書き込みかなぁ 351 名前：名前は開発中のものです。 mailto:sage [2008/08/30(土) 15:36:27 ID:h7pQaJrI] なんかのマルウェアって聞いたが 352 名前：名前は開発中のものです。 mailto:sage [2008/08/31(日) 15:40:22 ID:5jP5dBFC] A has B B has C C has Dのようなクラス構成で Aで作ったEをＤで使うために、Ａから呼び出したB、Bから呼んだＣ、Ｃから呼んだＤのそれぞれの関数の引数に Ｅを渡していくのはいいのかな？ 353 名前：名前は開発中のものです。 mailto:sage [2008/08/31(日) 15:45:26 ID:eaWcmeF0] いいんじゃね。 354 名前：名前は開発中のものです。 mailto:sage [2008/08/31(日) 15:47:56 ID:fQJxWw7j] 別に悪くはないと思うよ Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね なんにせよその構成だけじゃいいとも悪いとも言えない 355 名前：名前は開発中のものです。 mailto:sage [2008/08/31(日) 15:54:48 ID:5jP5dBFC] >>353 >>354 サンクス AからDは直接呼べないけど、Eを使うのはDなので、 AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と 思ったんだよね 356 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 03:29:08 ID:m23QvXa7] このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠 357 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 03:31:07 ID:m23QvXa7] >>352 >>355 コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、 それは普通にアリ。　っていうか、>>354 も言ってるけど、その構成だけだと（意図する形の意味づけが見えないと） 本当はいいとも悪いとも言えないが。 358 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 17:16:20 ID:BpB/a+5N] CarクラスはTireクラスを４つ持っているとして、 TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか？ 359 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 17:22:14 ID:Kf1ObPTz] コールバックしたいならインターフェース化してポインタ渡すとよい TireクラスでCarクラスを生成するとかなら論外 360 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 17:30:36 ID:BpB/a+5N] TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば いいということでしょうか？ 361 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 17:36:03 ID:NydWLubY] >>360 Tireが常にCarのポインタを持っている必要もなくて、 CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。 362 名前：名前は開発中のものです。 [2008/09/02(火) 17:40:44 ID:IXiySr/S] タイヤが車に関心があるってどういう状況？ 363 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 17:42:28 ID:NydWLubY] 「パンクしたよ」って知らせてくれるんじゃね？ 364 名前：名前は開発中のものです。 [2008/09/02(火) 17:44:29 ID:IXiySr/S] なるほど 365 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 19:17:31 ID:gmtfIbjx] それ車が「パンクしたか？」メソッド持ってるんじゃダメなの？ 366 名前：名前は開発中のものです。 [2008/09/02(火) 19:20:27 ID:IXiySr/S] 車が、常に「パンクしたか？」ってタイヤに聞くの？ 367 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 19:24:40 ID:gmtfIbjx] うん パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな 車のメソッドじゃなくなったけど 368 名前：名前は開発中のものです。 [2008/09/02(火) 19:38:46 ID:IXiySr/S] メディエーターみたいなの？ 369 名前：名前は開発中のものです。 mailto:sage [2008/09/02(火) 20:44:39 ID:F4HrtZLF] >>366 実際のTPMS（タイヤ空気圧監視システム）はそういうものだよ。 ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる 具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる ポーリング処理。 float _pressure = m_wheel[n]->GetPressureState(); 370 名前：名前は開発中のものです。 mailto:sage [2008/09/19(金) 19:13:57 ID:FmM/zRja] ほしゅ 371 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 14:32:14 ID:tMuqv+yj] このスレはJavaでも大丈夫なの？ 372 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 14:52:40 ID:v7IsXRIY] >>371 質問内容の分野がよくわからないなら、以下へどうぞ。 【初心者】ｽﾚを立てる前にｺｺで質問を【Part17】 pc11.2ch.net/test/read.cgi/gamedev/1210443288 373 名前：名前は開発中のものです。 mailto:sage [2008/10/05(日) 17:40:56 ID:6np9SFhP] >372がエスパーすぎる 374 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 11:27:07 ID:g//jQFBy] データ(アイテムとかマップとか)ってどうやって作ってます？ エクセルで打ち込んでcsvで保存？ 375 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 12:46:01 ID:YmfIaKZ8] 別にそれでいいし 専用にエディタ作ってもいいし ありもので済ませてもいいし 俺はPlatinum map editor使ってるし 376 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 12:58:04 ID:g//jQFBy] >>375 マップに関しては、フリーのエディタがあるんですね。 規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。 377 名前：名前は開発中のものです。 mailto:sage [2008/11/01(土) 16:47:28 ID:NlVHrve1] 既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。 378 名前：名前は開発中のものです。 mailto:sage [2008/11/02(日) 08:08:32 ID:JeGt0JB9] 海岸線自動生成とかやってくれるエディタあるっけ？ 379 名前：名前は開発中のものです。 mailto:sage [2008/11/02(日) 09:02:07 ID:i1X6CLvS] >378 エディタでやるの？ 380 名前：名前は開発中のものです。 mailto:sage [2008/11/04(火) 18:29:40 ID:CIBt14+U] 機能としてはエディタ側じゃね？ 381 名前：名前は開発中のものです。 mailto:sage [2008/11/06(木) 00:16:08 ID:46fvhfrF] ツクールで海岸線をシフト＋右クリックすると分かる 382 名前：名前は開発中のものです。 mailto:sage [2008/11/11(火) 20:24:09 ID:rtOtwyEd] 最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。 今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。 他の初心者がこんなことが起きないように、勝手にメモ。 1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。 →クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される（変数として保持される側の）クラスの再利用が容易。 →相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。（関連する側が冗長になるが。） 2、再利用を考えたフレームワークは（初心者は）作らない。 →再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。 他に鉄則があったらだれか教えてください　orz 383 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 01:30:10 ID:LsEQ4TEa] 相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな クラスA「Bさん、お先にどうぞどうぞ」 クラスB「いえいえ、ここはAさんがお先に」 クラスA「どうぞどうぞ」 OS「おまえら、どっちもさっさとイケ！」 ピー… 384 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 09:02:45 ID:QWqH0Tgg] > Gofのデザインパターン GOF本でわかったならよいけど、退屈でわからない人は First Headの本オススメ Head Firstデザインパターン―頭とからだで覚えるデザインパターンの基本: エリック フリーマン, キャシー シエラ, エリザベス フリーマン, バート ベイツ, Eric Freeman, Kathy Sierra, Elisabeth Freeman, Bert Bates, 佐藤 直生, 木下 哲也, 福龍興業: Amazon.co.jp: 本 www.amazon.co.jp/dp/4873112494 images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg 385 名前：名前は開発中のものです。 mailto:sage [2008/11/12(水) 23:23:14 ID:hxIHNKys] ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。 たとえば、ある単純な機能のクラスがいくつかあります。 これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、 1、大きなクラスをネスト先の名前空間に入れる。（HogeLibrary.Composite） 2、小さなクラスをネスト先の名前空間に入れる。（HogeLibrary.SmallComponent） 3、そもそもが間違い。同一名前空間に配置する。 どれが適切でしょうか？ 386 名前：名前は開発中のものです。 mailto:sage [2008/11/13(木) 21:08:31 ID:3NMFClPL] >>385 boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。 ってそういう話じゃない？ 387 名前：名前は開発中のものです。 mailto:sage [2008/11/14(金) 01:18:47 ID:USS/q0/d] >>385 名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。 388 名前：名前は開発中のものです。 mailto:sage [2008/11/16(日) 02:04:27 ID:OW89wflh] ライブラリ利用者の立場にたって、 どうなってると使いやすいかを考えて臨機応変に決める。 389 名前：名前は開発中のものです。 mailto:sage [2008/11/19(水) 20:47:58 ID:oq/eqnIP] >>382-384 まだ読んでいない俺には勉強になったthx 390 名前：名前は開発中のものです。 mailto:sage [2008/11/20(木) 09:17:22 ID:jP0yKBYe] >>384 のFirst Head本は、読み物形式で 悪いコードをよいコードに変更していきながら、解説しているようになっているので、 GOF本よりかなり読みやすいよ ただ、いくつかのパターンが省略されて適当解説になっているので、注意。 適当になってる後半部分も解説されていたらかなり神本だった （まああのペースで全部網羅すると、値段とページがすごいことになりそうだがｗ） 391 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:02:56 ID:GlMxgFAf] すいませんというか疑問です。 特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。 (1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。) 1、この関数を採用する場合、名前の付け方 Polls()、CanPoll()、IsPolling()　…主目的が『必要ならば読み取る』なので何かしっくりしない。 2、何かよりよい代替の設計があるだろうか 何か設計が変な気がする、が、なぜそう思うのはわからない。 どなたか導きをお願いします 392 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:03:41 ID:GlMxgFAf] なんかいっぱい改行が入ってるorz 393 名前：名前は開発中のものです。 mailto:sage [2008/11/30(日) 20:44:16 ID:O5396ILY] >>391 関数の名前は内部での処理なんて割とどうでもいいので、 とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。 ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、 そのイベントによって適切なリスナーの関数が起動されます。 プログラムの本流が直接読みに行くことなんてしません。 394 名前：名前は開発中のものです。 mailto:sage [2008/12/02(火) 23:03:37 ID:QPPOGJkH] >>393 気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。 DirectInputのBufferedは偉大ですね、と。 395 名前：名前は開発中のものです。 mailto:sage [2008/12/03(水) 00:00:25 ID:QPPOGJkH] ついでにスレを読み返してメモメモ、と思った情報をまとめてみた。 コルーチン、マイクロスレッド、ファイバ >>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 名前：名前は開発中のものです。 mailto:sage [2008/12/13(土) 14:29:53 ID:lcU0tpK0] ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。 このスレがあるので必要ないのでは？という意見があり、新スレを立てるべきかどうか迷っています。 ご意見頂けないでしょうか？ ↓ゲーム開発論スレ要望の経緯 pc11.2ch.net/test/read.cgi/gamedev/1206381315/ ＫＯＮＡＭＩ、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議 「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」 game.watch.impress.co.jp/docs/20080916/cedec_dev.htm 「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る，有効なゲーム開発プロセス www.4gamer.net/news/history/2007.03/20070309215934detail.html Agile型開発でのゲームデザイン www.4gamer.net/news/history/2007.03/20070311002313detail.html 397 名前：名前は開発中のものです。 [2008/12/14(日) 06:46:04 ID:foB3PhGt] >>396 ここは実装について話すスレなので、開発論は全くのお門違い。 とっとと失せろ！！ 398 名前：名前は開発中のものです。 mailto:sage [2008/12/14(日) 06:47:43 ID:3zIx1sHY] 想定通りでワロタ 399 名前：名前は開発中のものです。 mailto:sage [2008/12/15(月) 01:28:13 ID:AODSdSoN] >>395 ありがとう助かるよ 400 名前：名前は開発中のものです。 [2008/12/18(木) 23:54:28 ID:QLMqRIYY] キャラクタのデータはテキストファイルにゆだねて動的にできるけど ふるまいはどうすればいいんだろう。 基本ふるまいをプログラムに実装して(静的)、テキストファイルで その呼び出しを記述する(動的)とかなのかな。他に思いつかん。 401 名前：名前は開発中のものです。 mailto:sage [2008/12/19(金) 12:11:03 ID:ygbWfkiR] 俺はそうしてる。 402 名前：名前は開発中のものです。 mailto:sage [2008/12/21(日) 09:35:05 ID:7nb+zy1b] つまりスクリプトですね。 403 名前：名前は開発中のものです。 mailto:sage [2008/12/25(木) 19:24:07 ID:QpPf00tD] 知ってるよDIって言うんだよね 404 名前：名前は開発中のものです。 mailto:sage [2008/12/26(金) 01:45:37 ID:NBeqwEQB] 最近でたセガのあれな本を読んで、自分がずっと詰まってたしょーもないことを勝手にメモ。 結論としては基本中の基本で、データと処理は独立させましょ、ってことなんだけど。 ゲーム中ができたけど、ポーズ機能を追加、ポーズメニュー表示関連をクラスで作って実装するには、という感じの想定。 こんな感じに管理してるとして(具体的にはもっと複雑だけど。) 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 名前：名前は開発中のものです。 mailto:sage [2008/12/26(金) 08:47:36 ID:Y8oI6MzT] 「勝手にメモ」を書き込んでくれる人（達？）の存在は、正直ありがたい 406 名前：名前は開発中のものです。 mailto:sage [2008/12/28(日) 17:34:36 ID:pzJs6/UU] MVCでいうと、 M:StgScene V,C:Menu,Playing ってことなのだろうか？ Stateパターンという風にも捉えられる？ 407 名前：名前は開発中のものです。 mailto:sage [2008/12/29(月) 00:45:07 ID:THn3O3Oz] 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 名前：名前は開発中のものです。 mailto:sage [2009/01/07(水) 23:21:00 ID:rBsXmGd8] なんか話題無いなー的なので、>>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 名前：名前は開発中のものです。 mailto:sage [2009/01/07(水) 23:25:20 ID:rBsXmGd8] しかもミスってる。 # unfocusing　･･･『戻り値に次の遷移先シーンかnull返す。』　←× 正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。 410 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 00:07:48 ID:vYDzTrO8] 自作の状態遷移クラスに似てるな。 ・状態に親子関係がある。 ・戻り値の意味によって遷移先を決める。 ・自分の子、先祖の子以外は直接遷移できない。 ってあたり、ほぼ同じっぽい。 戻り値って具体的に何を返しているの？ 自分の場合、STAGE_CLEARとかの定数を返している。 その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。 411 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 01:05:35 ID:2TNYOX7D] >>410 このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。 C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。 で、戻り値に対する処理はこんな感じ。 戻り値がnullなら、フォーカスシーンが孫以下であることを表します。 戻り値sceneのGetType()と、 ・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。) ・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。 ・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。 ・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。 ってかんじでしょうかね。 412 名前：名前は開発中のものです。 mailto:sage [2009/01/09(金) 01:28:17 ID:vYDzTrO8] インスタンスそのものを返すのかぁ。 確かにそのほうが直接的ですっきりするかもね。 413 名前：名前は開発中のものです。 mailto:sage [2009/01/10(土) 23:29:07 ID:GXwf3cbn] インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ 危険があるから1個間にはさみたいな。 生成メソッドはstaticにするとかなんとか。 414 名前：名前は開発中のものです。 mailto:sage [2009/01/11(日) 00:09:06 ID:dWwzUAmX] まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。 どう考えても使いきれるとは思えん 415 名前：名前は開発中のものです。 mailto:sage [2009/01/11(日) 02:43:39 ID:cWr0moum] あれか？　NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か？ 416 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 02:58:31 ID:8xCnbJpy] >>414 PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、 DSにいたっては4MBしかないからね。 417 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 03:30:42 ID:mDvqZ10E] シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、 そのコンストラクタへシーン用引数を指定できるのがメリットかな。 あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、 シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、 メモリが足りないということは殆どなくなると思うけどね。 それから、個人的な意見としては、 シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。 このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。 418 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 03:32:37 ID:mDvqZ10E] ごめん ×ライフサイクル ○ライフタイム 419 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 11:14:49 ID:pb2pea9L] そのあたりの話は研究しがいがあるな。 420 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 13:32:30 ID:YXD0YS+N] >>418 一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな？ クラス図の関連が木構造で、枝をはさみで切るイメージ。 421 名前：名前は開発中のものです。 mailto:sage [2009/01/12(月) 14:12:02 ID:sqS0O25/] シーンをまたぐデータは、そもそもシーンが管理すべきなのか 検討した方がいいかも。 422 名前：名前は開発中のものです。 mailto:sage [2009/01/13(火) 22:46:08 ID:BhFnEm7r] シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが そのポインタを渡すのにシーン生成を先にしたいという感じかな。 オレは管理マネージャ作るけど。 423 名前：名前は開発中のものです。 mailto:sage [2009/01/13(火) 22:46:54 ID:BhFnEm7r] 管理マネージャじゃマネージャマネージャだなｗ まあC++になって楽になったものよ。 424 名前：名前は開発中のものです。 mailto:sage [2009/01/14(水) 03:24:31 ID:0DnXfUAy] >>421 原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。 あるシーンが持つデータを子シーンが使いたかったら、 >>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。 まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく) 425 名前：名前は開発中のものです。 mailto:sage [2009/01/14(水) 03:32:21 ID:0DnXfUAy] 親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。 ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、 スコアの点数がまたぐデータになる。 RootScene>GameScene>GamePlaying から RootScene>GameScene>GamePlaying>GameOver となり、その後 RootScene>HighScoreScene に遷移する。 その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。 426 名前：名前は開発中のものです。 mailto:sage [2009/01/17(土) 14:39:28 ID:AWtASysq] YAGNI 427 名前：名前は開発中のものです。 mailto:sage [2009/01/21(水) 22:53:35 ID:sHv/LIGj] スレが止まってるとさびしいな。 独り言でも言ってるか。 STGを作るときに、解決すべき内容は。 ・1/60秒や入力情報など、最も基本的なものの構築。 ・シーン遷移等、シーン管理の構築。 ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。 実際のゲーム中の解決すべき内容は ・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。 ・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。) ・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。) ・オブジェクト同士の衝突判定の記述。衝突判定まで。 ・誘導弾など、常に依存先がかわるオブジェクトの記述方法。 で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。 428 名前：名前は開発中のものです。 mailto:sage [2009/01/21(水) 23:23:50 ID:sHv/LIGj] オブジェクトの構造とそれらの管理。 前提として、管理のことを踏まえスーパークラスで多態性する。 publicにしそうな変数は　位置、速度、耐久力(=生存判定) publicにしそうな関数は　更新、描画 いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。 どこまでを1オブジェクトとするか。 ・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。 （本質的にバリアや耐久力表示と同じ関係なので。） 429 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:12:28 ID:P249I5A7] ステージ情報の管理。 これを管理するクラスを一つ作る。主なデータとしては 敵出現データ情報（背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。 基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。 wait、enemy、background、musicがあれば十分。 ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。 簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。 (waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。) この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。 430 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:45:44 ID:P249I5A7] で、今は あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。) ・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。 ・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。 (スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。) ・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。 >>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。 431 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 00:57:55 ID:P249I5A7] オブジェクト同士の衝突判定の記述。衝突判定まで。 ・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。) →バウンディングボックスも実装。 ・後々考えると、回転可能な矩形判定が後腐れない。 →バウンディングサークルにしといた方が、記述の割りに回転に対応できる。 衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。 オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。 誘導弾などの実装、は思案中。いい感じが思いつかない。 432 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 04:27:16 ID:lwlInfIx] >>427-431 とりあえず「管理」という言葉を使わないように考えることをおすすめする。 www.google.co.jp/search?q=SomethingManager 433 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 04:40:32 ID:P249I5A7] >>432 サンクス。こんな考え方があったのか 言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。 今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。 434 名前：名前は開発中のものです。 mailto:sage [2009/01/22(木) 15:25:00 ID:x7I7tNfu] 大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。 435 名前：名前は開発中のものです。 mailto:sage [2009/01/29(木) 21:46:47 ID:dRfTqeNw] そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ 管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい 436 名前：名前は開発中のものです。 mailto:sage [2009/01/30(金) 16:55:21 ID:O2nIHOeq] >>434は別に口答えしてるわけじゃない気がするｗ 437 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 08:12:45 ID:qu7YpnnP] アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな？ とたまに悩む 438 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 12:07:33 ID:2t9biDkM] Ｇｅｍｓにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい 439 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 19:06:11 ID:mhj1e1O5] そのへん追求し始めたらキリ無いよねw 最近はもう深く考えるのはやめた 440 名前：名前は開発中のものです。 mailto:sage [2009/01/31(土) 19:11:05 ID:L0OEs6zN] >>437 悩む悩むｗ 441 名前：名前は開発中のものです。 mailto:sage [2009/02/01(日) 19:03:38 ID:tMKL4U61] >>437 1番近い敵キャラが攻撃してくる って処理を書いたときに同じ疑問を俺も感じた。 int near = CEnemy::returnNearNum(); enemy[near].attack(); ↑こんな感じで静的なメンバ変数を返して貰っていたけど STGみたいに「自機」対「敵機達」ならこれでもいいんだけど ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。 442 名前：名前は開発中のものです。 mailto:sage [2009/02/02(月) 20:35:13 ID:esDSGZyH] ステージ側でやってることが多くなって どこかに細分化できないかなと悩み出すんですね わかります 443 名前：名前は開発中のものです。 mailto:sage [2009/02/03(火) 03:59:27 ID:cOF6NPxT] キャラの位置をステージ側で管理する手法も 割と普通だとは思うけど、OOP前提なら避けたいかなあ 近傍キャラの検索スピードを最適化したいということなら ステージ側に直前のフレームでの位置情報のコピーを作るとか 444 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:51:27 ID:+KF0MHRv] たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、 ・石に重力を働かせる処理 ・石と石の衝突処理 ・石とマップの衝突処理 は、それぞれどのクラスが担当すべきだろうか。 445 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:56:52 ID:jTgjQpbm] >>444 物の理を司る GOD class 446 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:57:18 ID:sBGSiXKq] 分からないから指向をそのままレスとして出力。 ・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。 ・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。 ・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。 ・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。 ごめん、適当に書いただけ。 447 名前：名前は開発中のものです。 mailto:sage [2009/02/06(金) 21:58:24 ID:y5Y5dk+m] 唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん 448 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 00:34:27 ID://aDzdii] > ・石に重力を働かせる処理 石クラス > ・石と石の衝突処理 マップクラスに位置情報を登録して一括処理 > ・石とマップの衝突処理 石クラス 449 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 01:46:53 ID:HaVHq232] > ・石に重力を働かせる処理 石クラス > ・石と石の衝突処理 衝突判定クラス > ・石とマップの衝突処理 衝突判定クラス 450 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 13:25:16 ID:bH//onUq] > ・石に重力を働かせる処理 ゲーム管理クラス > ・石と石の衝突処理 ゲーム管理クラス > ・石とマップの衝突処理 ゲーム管理クラス 451 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 14:22:20 ID:VS035g6S] > ・石に重力を働かせる処理 石に重力クラス > ・石と石の衝突処理 石と石の衝突処理クラス > ・石とマップの衝突処理 右とマップの衝突処理クラス 452 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 14:51:09 ID:VC/wpjC+] >>451 オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり？ 453 名前：名前は開発中のものです。 mailto:sage [2009/02/07(土) 16:19:23 ID:Pn1Dl7Zh] >>450 CGameManagerですね、わかります 454 名前：447 mailto:sage [2009/02/07(土) 16:35:33 ID:oHEfOG3S] みんな何のことだかわかっていて俺涙目 455 名前：名前は開発中のものです。 mailto:sage [2009/02/13(金) 17:17:04 ID:gamtZzLZ] テーマが石なら、 >・石に重力を働かせる処理 シーン管理クラス >・石と石の衝突処理 シーン管理クラス >・石とマップの衝突処理 シーン管理クラス だな。 石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。 シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。 石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。 だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。 これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。 456 名前：名前は開発中のものです。 mailto:sage [2009/02/13(金) 17:35:30 ID:gamtZzLZ] 455だけど、修正 やっぱ衝突判定クラス作るわ。 シーン管理は保持オブジェクトと描画などについて司るだけで、 オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。 457 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 00:06:30 ID:wuF2UeZP] 沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな 458 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 00:20:27 ID:+0ELSliX] >>457 じゃあ新たなネタ出せよ 459 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 01:01:03 ID:1cFYmXpg] ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。 新しいネタか……。じゃあ、１つだけ。 ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、 その過程でゲーム特有のデバッグ手法があれば教えてほしい。 リークチェックやAssert使うとかの普遍的な手法の話というよりは、 ゲーム特化で、データ構造・クラス・パターンの観点から、、 いかにしてスクリプト上の変な挙動を見破れる技法だとか、 デバッグメニューとして必要なものは何かだとかそういうのが知りたい。 自分のようなアマチュアではそこまで手が回らないんで、 いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。 そんな中、どのように効率よく(少ないコード＆短かい時間で)デバッグできるか教えてほしい。 そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。 460 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 03:08:07 ID:qKH3GStO] 人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。 無敵モードとかステージセレクトみたいな。 当然ながら、バランスチェックを含めたテストプレイならこれらの機能はＯＦＦで。 コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。 エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。 ボタン一発で勝利／敗北または成功／失敗。必要に応じて、強制クリティカルとか強制回避なども。 アニメーションやオブジェクトの移動の速度コントロール（数十倍〜数十分の一まで）。 特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。 スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。 461 名前：名前は開発中のものです。 mailto:sage [2009/02/14(土) 10:08:02 ID:hPf9zE7f] リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。 462 名前：名前は開発中のものです。 mailto:sage [2009/02/15(日) 16:27:42 ID:933sIzgh] 速度調整機能つけたりログ吐かしたり そんくらいしかやっていないな。 463 名前：名前は開発中のものです。 mailto:sage [2009/02/18(水) 14:05:52 ID:1weRwVko] >>460-462 いろいろありがとう。 あらかたデバッグ用に実装してみました。 464 名前：名前は開発中のものです。 mailto:sage [2009/02/18(水) 14:39:48 ID:0gTNCSoI] 行動力あるね 素晴らしい。見習いたい 465 名前：名前は開発中のものです。 mailto:sage [2009/02/19(木) 03:37:37 ID:4unT5BXH] いやいや。実装したのはこんだけです。 コリジョン可視化:テクスチャ読み込み後に四隅に沿って緑色で四角線を書くだけ パラメータ操作:テンキーで実装 　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 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 07:24:48 ID:3Qcrn5pr] 洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、 ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。 467 名前：名前は開発中のものです。 mailto:sage [2009/02/21(土) 12:50:08 ID:YLpnm94h] pc11.2ch.net/test/read.cgi/gamedev/1234977661/ 468 名前：名前は開発中のものです。 [2009/02/24(火) 16:03:05 ID:xS4ZudQO] スマートポインタの使いどころ教えて 469 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 02:46:38 ID:1o4GjPkR] 使いどころっつーわけじゃないけど 次のC++規格が決まれば、早ければ今年中にも 　std::shared_ptr として使えるようになる予定 今でも既に std::tr1::shared_ptr になってるけど 470 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 05:08:14 ID:M8Pe/6zZ] >>468 まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。 使いどころは、 ・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき ・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき ・ヒープの参照状態を把握したいとき ・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき だと思う。 471 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 11:43:26 ID:woJXacCs] 要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか 472 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 18:18:12 ID:QjeqtKpK] Yes いろんなとこから参照されていて、開放時期が掴めないときは最高に便利 理論的には、参照カウンタが0になったら自動的に消えていってくれるよ 473 名前：名前は開発中のものです。 [2009/02/25(水) 18:28:42 ID:nKINhS/o] つまり、いらなくなったらすぐに消されるってことですね 私のように 474 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 18:31:43 ID:Z+e+XbPJ] 不況だもんな・・・ 475 名前：名前は開発中のものです。 mailto:sage [2009/02/25(水) 18:55:09 ID:1o4GjPkR] いや、それは地球の資源不足で君の給料が確保できないだけだ スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・ 476 名前：名前は開発中のものです。 mailto:sage [2009/02/27(金) 15:15:39 ID:MDeQuwXl] 例えばDirectxのDeviceインスタンスなど、あらゆる所で使われそうなインスタンスは、どう使ってますでしょうか？ Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、 リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、 Deviceインスタンスは 1、Drawの引数に渡す 2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。 3、グローバル変数 4、そもそもその設計はまずい 5、その他 現在2です。 1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、 発見がかなりめんどくさそうな所でしょうか? 477 名前：名前は開発中のものです。 mailto:sage [2009/02/27(金) 15:58:46 ID:XnWaU4Ou] デバイスホルダー的なシングルトン作るとか 478 名前：名前は開発中のものです。 mailto:sage [2009/02/27(金) 17:33:53 ID:lChaxYTz] 俺もシングルトンかな。参照回数が0になったらreleaseで。 479 名前：名前は開発中のものです。 mailto:sage [2009/02/28(土) 00:40:47 ID:OR4wkfx2] ハッシュテーブルのキーって文字列じゃなくてもいいのかな？ 符号なし整数とか。 どっかにそういう例ないです？ 480 名前：名前は開発中のものです。 mailto:sage [2009/02/28(土) 08:42:03 ID:Cadu6Xk7] ハッシュが計算できるなら、キーはなんでもいいよ 481 名前：名前は開発中のものです。 mailto:sage [2009/03/04(水) 04:45:32 ID:y6+tTW6F] >>479 こんなんでいいか？ ttp://codezine.jp/article/detail/2171?p=2 482 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 11:34:39 ID:7UNSgj8M] C++でシングルトンするのってなんか滑稽じゃね？ Javaじゃないんだし そこまでクラス原理主義にならんでもいいのにと思う 483 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 13:08:45 ID:A313Daxt] >>482 グローバル変数が欲しいんではなくて、システム全体で一つしかないということを 明示的にする為のパターンだから 484 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 14:26:30 ID:7UNSgj8M] グローバル変数関係ないやろ 普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン よーく考えよう 485 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 14:28:31 ID:7UNSgj8M] あ、ちょっとちがうな。 「クラス定義必須、インスタンシエーション普通」の言語だな。 486 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 15:48:06 ID:A313Daxt] >>484-485 エンド ユーザーがそのクラスを作成できてしまうじゃないか 作成できないようにしたのがシングルトンだろ 話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど C言語でも出来るんだよなー 487 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:07:52 ID:7UNSgj8M] >>486 そのクラスのインスタンスが１つであることを保証するのがシングルトン クラス(原因)が無ければインスタンス(問題)も無い だからシングルトン(解決策)も要らんと言っているんだ C++でのシングルトンはマッチポンプなんだよ 488 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:18:21 ID:7UNSgj8M] www.geocities.jp/ky_webid/design_pattern/009.html 「C++ シングルトン」でググったら出てきたページ この労力を指して滑稽だと笑ってるんだけどな Javaなら習得必須の概念だし俺も普通に使うが C++でこんなん無理してやったら馬鹿みたいだと思わね？ // 生成やコピーを禁止する ↑アホじゃね？　最初からクラスにしなきゃいいじゃん クラス原理主義に陥って思考停止しちゃってるんじゃないか 目的と手段の関係について考え直してみるといい 489 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:29:34 ID:7UNSgj8M] まあ、要件に多態性があるならクラス化した方が楽かもしれんけど それ以外だとやっぱり儀式めいたものを感じるな 490 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:29:53 ID:oPKUKLY9] 先にクラス原理主義という単語を発してしまった時点で ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件 491 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:34:17 ID:7UNSgj8M] >>490 アンチクラスなんて単語あったんだ 知らなかった C++でもクラス使いまくりなんだけど C++でシングルトンやらないだけでアンチクラスか 492 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:39:54 ID:7UNSgj8M] クラスアンチだしｗ 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 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 16:57:37 ID:12yJl3As] 労力って コンストラクタをprivateにしたり、 コピーコンストラクタを宣言だけ記述したりするだけじゃん >↑アホじゃね？　最初からクラスにしなきゃいいじゃん クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ 494 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 17:07:43 ID:7UNSgj8M] >クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう いくらでもあるのか そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな あとは>>489 俺にはこの２つくらいしか思いつかんが こういう風にクラス化する理由があるならいいんじゃね >じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ >>484 495 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 17:20:31 ID:12yJl3As] >>484の方が楽だとは思えない まあでもお前がその方が楽だと言うなら尊重するよ 一緒に仕事する相手じゃないからな 496 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 18:55:30 ID:Erqh3NJs] namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、 素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。 ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、 シングルトンのほうが便利だよね。 それと、あとから「やっぱシングルトンやめ」ってなったときに、 変更が少なくてすむのも利点かなあ。 497 名前：名前は開発中のものです。 mailto:sage [2009/03/06(金) 20:00:35 ID:z7QigqBL] まぁ疑問を持つのは悪い事じゃない 他人に強要しなければね 498 名前：名前は開発中のものです。 mailto:sage [2009/03/12(木) 10:42:00 ID:X7nBBwQA] 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 名前：名前は開発中のものです。 mailto:sage [2009/03/12(木) 10:43:53 ID:X7nBBwQA] >>498 捕捉： （わかると思うけど）使う時は、他のユニットから 　Printer.HogeMageSimasu; 見たいに使う あと抜けてるけど、実際には、finalzation節？でアプリ終了時のFPrinterの開放処理がある。 500 名前：名前は開発中のものです。 mailto:sage [2009/03/16(月) 15:21:22 ID:FTtiBwy2] また変なのが沸いてるのか 501 名前：名前は開発中のものです。 mailto:sage [2009/03/18(水) 23:45:50 ID:1sOkzJT6] デバイスに直接アクセスする処理ってどこに書いてる？ 今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。 下みたいな感じで一箇所にまとめた方がいいのかな。 今：あちこちでデバイスにアクセス 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 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 04:54:27 ID:KYbRBn+z] 久々に答え甲斐のありそうな相談が来たな だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い お前らに任せたぜっ！ 503 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 05:21:17 ID:XLj1eEa+] 描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。 504 名前：名前は開発中のものです。 mailto:sage [2009/03/19(木) 19:28:19 ID:ALN5WhPj] 俺はこの案では無いなぁ…てかどうせなら lpD3DDEV->draw(draw_data, ...); は draw_data.draw(...); みたいにしてlpD3DDEVに直接アクセスしない方が… 505 名前：501 mailto:sage [2009/03/20(金) 00:10:41 ID:/TREybMM] レスありがとう。 >>502 「案」の方に似たやり方だよね？ draw_dataがリスト相当で。 やっぱやってる人いたか。採用してるってことは使いやすいんだろうか >>503 void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) { 　　... 　　lpD3DDEV->draw(...); } みたいな感じ？ デバイスに直接アクセスする処理が複数のクラスに散らばるのはＯＫという判断？ この方が使いやすいってことかな？ うーん。。。 >>504 Draw_data::draw(...) { 　　this->lpD3DDEV->draw(this->draw_data, ...); } こんな感じ？　ラッパー作れって話？ 「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど 気になる人って少ないんだろうか。 0人では無かったけれど。 506 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 02:39:39 ID:D2lp0Ec4] まずはMVCを試みてみるのはどうだろうか 507 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 04:52:36 ID:09EDEaYz] 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 名前：名前は開発中のものです。 mailto:sage [2009/03/20(金) 04:53:53 ID:09EDEaYz] …続き 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 名前：501 mailto:sage [2009/03/21(土) 12:54:05 ID:Y4F/PoMw] >>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 名前：名前は開発中のものです。 mailto:sage [2009/03/22(日) 03:32:29 ID:O7e3N6nq] 描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが >>501だとそこをどう処理するのかがよく分からない。 各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか？ そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。 511 名前：501 mailto:sage [2009/03/23(月) 00:38:25 ID:/nVLLFvd] >>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 名前：名前は開発中のものです。 mailto:sage [2009/03/25(水) 00:59:33 ID:koP5FPqt] hamigaki::coroutines使ってみた。 513 名前：名前は開発中のものです。 mailto:sage [2009/03/25(水) 12:39:16 ID:C50L0uFm] yhamigakiさんのexec.jamモジュールにはお世話になっております 514 名前：名前は開発中のものです。 [2009/04/05(日) 14:24:00 ID:a5PaoF6B] スレッド1..n 仮想描画コマンドをメモリに積む デバイス用スレッド　仮想描画コマンドを解釈して実際のコマンドを発行 利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる 欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い 515 名前：名前は開発中のものです。 mailto:sage [2009/04/06(月) 03:21:58 ID:NgKFyYts] 仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。 516 名前：名前は開発中のものです。 [2009/07/15(水) 22:32:12 ID:1c2msACv] www6.atpages.jp/~autonomydoll/game/RPGClient.zip クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。 今のクラス構成 ScreenManger-->ScreenGame-->Title 　　　　　｜　　　　　　　　　　　　　　　 |->Main-->Map -| 　　　　　｜　　　　　　　　　　　　　　　　　　　　　-->Unit--->sprite--| 　　　　　｜--------------------------------------------------------------->GraphicsWarpper 517 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:40:07 ID:h6KyoexM] WinAPI使ってるなら、WiｎSockで送信して、ウィンドーメッセージで受信する。他はｼﾗﾈ。 518 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:41:36 ID:3ppQI3l+] >>516 > ScreenManger 画面飼槽 > GraphicsWarpper グラフィックスワープ装置 何が言いたいのかさっぱりわからないのだが。 519 名前：516 [2009/07/15(水) 22:46:53 ID:1c2msACv] >>517 忘れてました。 net frameworkを使ってます。 >>518 ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます GraphicsWarpperは単なるラッパーです。 520 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 22:57:45 ID:cL81hhcG] こんな面白い難読化もなかなかないな 521 名前：名前は開発中のものです。 mailto:sage [2009/07/15(水) 23:01:47 ID:3ppQI3l+] >>519 > net frameworkを使ってます。 .NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・ > ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます それならMangerではなくManagerだろ。 > GraphicsWarpperは単なるラッパーです。 それなら、WarpperではなくWrapperだろ。 小学校は夏休みなのか・・ せめて中学生になってからにしてくれ 522 名前：名前は開発中のものです。 [2009/07/15(水) 23:14:16 ID:1c2msACv] >>521 すまん。スペルミスった・・・。 523 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 01:35:23 ID:Ac1CnfQd] まず日本語と英語を勉強するべきでは？ そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない 自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは１つもないね ちなみに件の話に関しては書籍があるよ GameDeveloperのオンラインゲームの青本 MMORPGを作る赤本もある 2chで説明すると1スレ使っても無理だと思う 524 名前：名前は開発中のものです。 [2009/07/16(木) 02:06:03 ID:Dq9kBSTx] >>523 ありがとう。 それをあたってみる。 525 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 02:29:30 ID:lK28N0n1] 質問の内容と関係ない単語にしかつっこめない奴が多くてﾜﾗﾀ 526 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 05:49:13 ID:0eDNLm6a] 2〜3人で多いのか、寂しい生活してるんだな 527 名前：名前は開発中のものです。 mailto:sage [2009/07/16(木) 10:25:09 ID:irpkCXOF] 言われて悔しいならもっと勉強しろよ 528 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 18:57:02 ID:qfXJNhjS] コミケの影響で最近来なかったここを再び覗くように。変なテンションダァ･･･ >>395 395以前のまとめ >>404,406-407 シーン遷移考え方 >>408-413,416-425 シーン遷移実装サンプルと問題点。 >>427-433 0からSTGの作成を考える。 根本的な勘違いや非効率的なことがあるのであまり参考にはならない。 >>437-443 オブジェクトと座標管理 >>444-456 オブジェクトと衝突判定と全体効果 >>459-465 デバッグ用処理を考える。(衝突判定表示とか) >>501-511 DirectXのデバイスの管理とか使い方 >>523 ネットワーク機能参考図書紹介 529 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 19:24:51 ID:qfXJNhjS] STGのビジュアル関連向上に関するメモ。 ･･･あんま設計と関係ないな･･･ それっぽい弾の作り方 ・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。 ・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。 ・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。 ちょっと光ったエフェクトとか。 ・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。 ・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。 弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い･･･気がする。 530 名前：名前は開発中のものです。 mailto:sage [2009/08/14(金) 22:21:56 ID:FZUQWr9u] >>529 設計というよりは演出(エフェクト)の話でしょうか。 もし続けるなら専用のスレを立てた方がよいと思われ。 531 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 01:40:33 ID:mQYy5BRf] シミュレーションやRPGで 経営状況や主人公の内部パラメータと呼ばれる データ群がごっそりあると思いますが， そういったものの管理は 実際のゲーム開発でどういった形でなされるものですか？ データクラスを作ってアクセッサで操作を許す？ それとも，すべてグローバル変数で持たせる？ 532 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 04:33:25 ID:/TvwIsfE] シングルトンクラスのオブジェクトをグローバルに定義する 533 名前：名前は開発中のものです。 mailto:sage [2009/10/05(月) 07:34:29 ID:Rel4l/Gg] SQLiteとか使って手抜くってのもあり 534 名前：名前は開発中のものです。 mailto:sage [2009/10/14(水) 22:12:56 ID:TwzkU58s] グローバル変数はありえない。データクラス。 ただ、データの表示とかはいつも頭を捻らすなぁ。 535 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 07:50:05 ID:P3b4xThD] アクセッサ書くのめんどいだろ 536 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 08:41:22 ID:OtHf9VTl] なんでそんな両極端なの？ 537 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 15:54:18 ID:byjv3si3] 0と1しか無いからな オタクの頭ん中は 538 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 20:13:55 ID:P3b4xThD] 別に両極端で構いません． 意見を頂けるだけで嬉しいです． むしろ噛み付くほうが迷惑です． 539 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 22:16:10 ID:r8d5RKMA] 使う人がデータを把握できてるなら好きにすればいいんだよ。 質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。 540 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 22:18:05 ID:2byzEsEE] >>535 アクセッサ書くのめんどくさいって言ってたら コーディングが意味不明になってやる気をなくす自信がある。 実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。 541 名前：名前は開発中のものです。 mailto:sage [2009/10/15(木) 23:29:40 ID:r8d5RKMA] 俺は変数に直接アクセスでも分かりにくいと思わないし。 アクセッサ書くのもめんどくさいとは思わない。 542 名前：536 mailto:sage [2009/10/16(金) 00:35:50 ID:L+kS7tAJ] >>538 悪い、噛み付くとかそういうつもりは無かった。 普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ Facade経由でアクセスできれば良いんじゃないかと思っただけ。 グローバル変数はさすがにあり得ない… 543 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 01:18:33 ID:MsmDVyev] ２ｃｈで素直に謝られると逆に困ります． 参考になりました，ありがとうございます． 544 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 01:38:32 ID:tEeFyBBH] グローバル変数を利用側が直接更新したり参照したりするのはアウトだけど、 スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。 // 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 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 06:29:56 ID:UJ9WR3Zt] 代入の時などに別の処理を入れるんでなければ 変数を直接弄るんでもいいかな・・・。 546 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 11:40:43 ID:/PDPq+0/] 入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、 そういう可能性を考慮すると、関数を経由させたほうが便利。 547 名前：名前は開発中のものです。 mailto:sage [2009/10/16(金) 20:07:25 ID:eJ9LLkd5] アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、 そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。 548 名前：名前は開発中のものです。 mailto:sage [2009/10/18(日) 12:51:59 ID:Yr/zm5ey] >546 確かに使い方を間違えるってのはよく起こる

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef