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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 07/21 13:53 / Filesize : 166 KB / Number-of Response : 549
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：名前は開発中のものです。 [2008/05/23(金) 21:10:59 ID:8M1gqhPX]: 具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。

関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。

前スレ
pc11.2ch.net/test/read.cgi/gamedev/1155209226/

テンプレ追加事項あったらよろすく
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