5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

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

テンプレ追加事項あったらよろすく

2 :名前は開発中のものです。:2008/05/23(金) 22:15:47 ID:KYZLgWWh
■デザインパターン
必須ではないが用語として便利なのでしばしば話題に上がる

[参考サイト]
Gameつくろー! デザインパターン習得編
http://marupeke296.com/DP_main.html

サルでもわかる 逆引きデザインパターン
http://www.nulab.co.jp/designPatterns/designPatterns1/designPatterns1-1.html

[参考書籍(Amazonリンク)]
オブジェクト指向における再利用のためのデザインパターン
http://amazon.co.jp/o/ASIN/4797311126/

デザインパターンとともに学ぶオブジェクト指向のこころ
http://amazon.co.jp/o/ASIN/4894716844/

>>1
一応デザパタ軽く。

3 :名前は開発中のものです。:2008/05/24(土) 01:01:32 ID:hwB5uNnT
3ゲトー1乙。ずっと待ってたぜ。

4 :名前は開発中のものです。:2008/05/24(土) 01:10:28 ID:hwB5uNnT
・オブジェクト指向といったら特に指定しない限りクラスベース(所謂最も一般的なオブジェクト指向)
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。

とかスレの前提としてどうだろう。

5 :名前は開発中のものです。:2008/05/24(土) 01:16:03 ID:fCOY9f2q
インスタンスってつまりは実体のこと?
Foo foo = new Foo() とすると foo がインスタンス?

6 :名前は開発中のものです。:2008/05/24(土) 01:24:20 ID:WrI+RE5A
デザインパターンとOpen-Closed Principle
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html

これも

7 :名前は開発中のものです。:2008/05/24(土) 02:07:45 ID:hwB5uNnT
>>5
揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね?
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。


8 :名前は開発中のものです。:2008/05/24(土) 02:41:35 ID:/DdfEDqz
「ゲームとはPrettyなインターフェースを備えたデータベースである」
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな

9 :名前は開発中のものです。:2008/05/24(土) 16:24:52 ID:WrI+RE5A
スクリプト指向の意味がさっぱりわからない

10 :名前は開発中のものです。:2008/05/24(土) 17:17:01 ID:LLc7AXF7
今最高峰のプログラマって、全員WEB系じゃん?
WEB系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな?


11 :名前は開発中のものです。:2008/05/24(土) 17:53:41 ID:hwB5uNnT
>>8
ゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。

12 :名前は開発中のものです。:2008/05/24(土) 21:56:16 ID:WrI+RE5A
メリットやデメリットを言えないくせに
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな

それで、教祖様は誰がなる予定なの?

13 :名前は開発中のものです。:2008/05/24(土) 23:02:12 ID:zxthQanT
>>12
今出てるのってそんな話か?
俺には世間話に>>10が適当な横槍入れただけに見えるが


14 :名前は開発中のものです。:2008/05/24(土) 23:16:51 ID:6QB8Oyw/
プ板から厨房誘致すればこのスレは盛り上がる。間違い無いw

15 :名前は開発中のものです。:2008/05/24(土) 23:28:05 ID:PtHN405f
たてなきゃいいのに布教スレなんかたてるからこうなる

16 :名前は開発中のものです。:2008/05/25(日) 00:49:54 ID:9gKbes0q
もう厨房が数匹住み着いたのか

17 :名前は開発中のものです。:2008/05/25(日) 10:55:20 ID:9DfW5HgH
プ板?
ム板のことか?

18 :名前は開発中のものです。:2008/05/25(日) 11:05:10 ID:93aOxetu
マ板じゃね?

19 :名前は開発中のものです。:2008/05/27(火) 12:06:43 ID:NfKeIEM4
これも貼っておこう

やる夫で学ぶデザインパターン
ttp://mojalog.com/cgi/mt/mt-search.cgi?tag=%E3%82%84%E3%82%8B%E5%A4%AB%E3%81%A7%E5%AD%A6%E3%81%B6%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3&blog_id=1

20 :名前は開発中のものです。:2008/05/28(水) 00:17:53 ID:EMOoLtkb
途中からゲーム関係なくね?

21 :名前は開発中のものです。:2008/05/28(水) 09:16:17 ID:rm2+ecl2
俺には全部ゲームに関係した話に見えるけど?
サンプルコードもゲームだしわかりやすくていいと思うが

22 :名前は開発中のものです。:2008/05/28(水) 10:19:46 ID:jKXaFTfv
なんか、無理矢理ゲームに例えてる感がひしひしと。

23 :名前は開発中のものです。:2008/05/28(水) 12:07:15 ID:yrY1wCou
日本語も満足に読めないのか

24 :名前は開発中のものです。:2008/05/28(水) 12:58:54 ID:aV/WuK9Y
お、2スレ目立ってたのね。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。

25 :名前は開発中のものです。:2008/05/28(水) 19:17:39 ID:rm2+ecl2
>>22
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ!」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い

26 :名前は開発中のものです。:2008/06/01(日) 20:32:11 ID:CN3GNXI+
俺のレベルではよくわからんが
ゲーム屋からみれば変な設計なん?

27 :名前は開発中のものです。:2008/06/01(日) 20:35:37 ID:9GWV5N72
デザインパターンを丸々入れ込むとゲームだと描画とかで
速度でないゴミになりそうな悪寒

28 :名前は開発中のものです。:2008/06/01(日) 22:40:05 ID:IjC+ZLNy
関数呼び出しとか仮想関数分のオーバーヘッドってそんなに響くか?
まぁ使い過ぎが良くないってのには同意だけど

29 :名前は開発中のものです。:2008/06/02(月) 00:45:33 ID:u3nq1AKu
クラスというか、同じ関数名が増えまくるオブジェクト思考言語は、GTAGS使えないので嫌いです。継承構造とかも嫌い。
こんなんじゃ、ゲーム屋って無理?

30 :名前は開発中のものです。:2008/06/03(火) 13:20:56 ID:Up2rlfhT
>>29
マならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…

31 :名前は開発中のものです。:2008/06/03(火) 13:37:21 ID:60nvGBII
>>29
利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど

32 :名前は開発中のものです。:2008/06/03(火) 14:28:32 ID:FP0Va/Ol
cscopeならglobalと同じような事をC++やjavaのコードに対してもできるぜ

33 :名前は開発中のものです。:2008/06/03(火) 18:34:30 ID:R8vkDVly
CodeWarriorとか、OOPでもばんばんタグジャンプできるから問題ないのでは?
どうしてもGTAGSがいいの?GTAGSってGNU Tags?Google Tags?

34 :名前は開発中のものです。:2008/06/04(水) 03:53:09 ID:8a5x1JRq
>>33
>GTAGSってGNU Tags?Google Tags?
カエレw

35 :名前は開発中のものです。:2008/06/07(土) 05:38:48 ID:PKYwPYRJ
>>27
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。

デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。

皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。

36 :名前は開発中のものです。:2008/06/08(日) 20:08:17 ID:1W8n4o1x
シューティング作っているんだけど
参考になるサイトでもある?

37 :名前は開発中のものです。:2008/06/08(日) 20:17:15 ID:WckjqjCh
積み木ファイターのひととか

38 :名前は開発中のものです。:2008/06/10(火) 10:07:55 ID:nTtkz+dw
ゲーム作るときってどうやってプログラム組んでいく?

全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル


39 :名前は開発中のものです。:2008/06/10(火) 10:18:30 ID:XooPHqWt
>>38
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。

これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ?

40 :名前は開発中のものです。:2008/06/10(火) 11:31:11 ID:K9Q1TpUp
>>38
まず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。

41 :名前は開発中のものです。:2008/06/10(火) 12:26:21 ID:hsBh970A
趣味で1人で作るのか、同人誌即売会狙いで数人で作るのか、会社の業務として作るのかで変わるとは思うけどな。
まあ、最後はありえねーとしてもw

42 :名前は開発中のものです。:2008/06/10(火) 19:02:52 ID:ZqBN8Kq4
>>38
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視

エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz

43 :名前は開発中のものです。:2008/06/12(木) 08:01:35 ID:IMyaUQnN
>>42
でも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。

44 :名前は開発中のものです。:2008/06/14(土) 10:10:24 ID:ITcMwq//
まずはトップダウンでモデル作って、作りながら問題があれば
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。

45 :名前は開発中のものです。:2008/06/14(土) 14:13:33 ID:GhaLcPKx
それができないから、他に方法が無いかと模索してるんでしょうね。お察しください。

46 :名前は開発中のものです。:2008/06/14(土) 15:55:22 ID:vUcsb6CI
あのgoogleですらボトムアップだという

47 :名前は開発中のものです。:2008/06/14(土) 21:53:33 ID:TLBVclDV
それはプロジェクト的な意味でだろ。

48 :名前は開発中のものです。:2008/06/23(月) 00:38:10 ID:fMSgUVEh
デバイスへのポインタってグローバルにしたほうが明らかに管理しやすいよな

49 :名前は開発中のものです。:2008/06/23(月) 01:30:28 ID:eCdVbunT
>>48 は?なんで?

50 :名前は開発中のものです。:2008/06/23(月) 01:34:12 ID:pTJzzIh1
俺はどっかにまとめるなあ
グローバルとか、デバイス差の吸収とか必要になったとき困らね

51 :名前は開発中のものです。:2008/06/23(月) 02:05:44 ID:NUHlpJuv
Direct3Dのデバイスの話とまず仮定。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との2択から、管理しやすさについて語っているのだと推測。

で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。

引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。

52 :名前は開発中のものです。:2008/06/23(月) 02:31:28 ID:/DBWn/TJ
ヘッダーが重たくなるから一部のソースでデバイス関連のインクルードして、
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。

53 :名前は開発中のものです。:2008/06/23(月) 08:22:39 ID:mKIom38M
オレはシングルトンクラスに持たせてそこからgetter呼ぶかなあ

54 :名前は開発中のものです。:2008/06/23(月) 14:04:29 ID:/Ozl3kU4
レイヤスーパータイプじゃないの
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど

55 :名前は開発中のものです。:2008/06/23(月) 22:16:08 ID:T9NriNFy
デバイスを使うような処理は関数で囲っちゃって、
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな?

56 :名前は開発中のものです。:2008/06/23(月) 22:34:15 ID:X6Q0hHes
>>55
俺もー

57 :56:2008/06/23(月) 22:37:13 ID:X6Q0hHes
↑でも、ビューアとかデバッグ系のプログラムは別だけどね。

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

59 :名前は開発中のものです。:2008/07/02(水) 03:01:12 ID:US3ampRT
シーンクラスじゃなくて管理クラスの方を積むの?
俺の鳥頭じゃちょっとイメージしにくい・・・

60 :名前は開発中のものです。:2008/07/02(水) 08:11:54 ID:1rjp9Xph
シーンなぞ市販のゲームだって両手の指で足りるくらいしかないのに
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの?

61 :名前は開発中のものです。:2008/07/02(水) 10:15:59 ID:25mPqNml
シーンねぇ
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。

62 :名前は開発中のものです。:2008/07/02(水) 19:16:17 ID:noQk3O5d
それで問題感じなきゃ無問題
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね

63 :名前は開発中のものです。:2008/07/02(水) 22:59:17 ID:zDJJl2HF
シーンの切替で驚いた事といえば、
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。

64 :名前は開発中のものです。:2008/07/02(水) 23:04:11 ID:surY1LL8
システムによっては、フィールドと町の中とではまるっきり違うやつもあるから、
そーゆーんじゃないのん?

65 :名前は開発中のものです。:2008/07/02(水) 23:06:33 ID:25mPqNml
まぁドラクエ的な物なら自分もフィールド、街、ダンジョンは同列に扱うかな。

66 :名前は開発中のものです。:2008/07/02(水) 23:19:07 ID:Z+lS9RAU
>>58
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う

67 :名前は開発中のものです。:2008/07/02(水) 23:42:43 ID:US3ampRT
俺はステータス画面の中の項目や、更に細かい項目もシーン扱いしちゃうなー
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど

68 :名前は開発中のものです。:2008/07/02(水) 23:53:44 ID:noQk3O5d
サブメニュー系は別で作ってhas関係にしてるな

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

69 :名前は開発中のものです。:2008/07/02(水) 23:58:28 ID:surY1LL8
>67
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。

70 :名前は開発中のものです。:2008/07/03(木) 03:42:52 ID:Z+nUDepW
自分はCだけど、シーン毎にゲームループを作る。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。

71 :名前は開発中のものです。:2008/07/03(木) 12:34:48 ID:4VgEaFFX
システムデザインに拘ると、抽象化についてこれないメンバーいるからなぁ・・
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。

外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。


72 :名前は開発中のものです。:2008/07/03(木) 12:38:03 ID:e4SGKyy/
>>71
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。

日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。

73 :名前は開発中のものです。:2008/07/03(木) 12:49:08 ID:ysSgecWy
むしろ日本の問題は、会社の枠で情報が閉ざされがちで、
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。

74 :名前は開発中のものです。:2008/07/03(木) 13:01:27 ID:aUHHO03G
閉ざしたくて閉ざしているわけでもないと思うんだけどね。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。


75 :名前は開発中のものです。:2008/07/03(木) 15:05:04 ID:qaYiJWl1
それは違うな、設計能力を持つ人間が極めて少数しか世界に存在していない

守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう

実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる

設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない

他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない

道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか

76 :名前は開発中のものです。:2008/07/03(木) 18:39:02 ID:9NkLv6DU
>>75
きもい、長い

77 :名前は開発中のものです。:2008/07/03(木) 19:12:29 ID:aUHHO03G
>>75
> 守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
> または公開することもできるだろう

もちろん社内で議論はしてるだろう。仕事してるんだから。
それと公開するかどうかは別の話だ。

ここでの話は、企業として技術情報を公開することについてじゃないの?
少なくとも>>72はそういう話でしょう。
それとも>>75は単に多くの日本の開発者を無能扱いしたいだけ?


78 :名前は開発中のものです。:2008/07/03(木) 20:24:00 ID:odWCpgCc
アメリカと日本じゃ、プログラマの流動性も違う品。

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


79 :名前は開発中のものです。:2008/07/03(木) 21:55:28 ID:DTx5b/+j
外国人すげぇ日本人だめ、みたいなステロタイプの意見が多いな
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ

>外人はゲームに限らず抽象化は得意

国産虹コンテンツの破壊力を目の当たりにしてそれはないよ

>まああっちは人が多いから下のレベルが高いんだろうけど

PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下(兵隊)の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね

80 :名前は開発中のものです。:2008/07/03(木) 22:23:51 ID:DTx5b/+j
>アマチュア間で情報をやり取りする開発者のフォーラムとか
>あってアマチュアも結構あれこれ知ってるからなあ

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

81 :名前は開発中のものです。:2008/07/03(木) 22:25:41 ID:4YUvzjZW
ゲーム開発に限った話じゃないけど、長引く不況のせいで日本人は
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。

82 :名前は開発中のものです。:2008/07/03(木) 22:33:05 ID:odWCpgCc
>>81
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。

情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。

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

84 :名前は開発中のものです。:2008/07/03(木) 22:47:22 ID:JMOvob5t
単なる欧米コンプレックスだろ

85 :名前は開発中のものです。:2008/07/03(木) 22:50:43 ID:odWCpgCc
>>83
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。

Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。

実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。

もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。

86 :名前は開発中のものです。:2008/07/03(木) 22:55:44 ID:odWCpgCc
Google の論文は、個人的には就職者ホイホイのような気がしてる。

SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよw


87 :名前は開発中のものです。:2008/07/03(木) 23:05:49 ID:1g03RBvk
論文の質・量で言うとMicrosoft Researchのほうがすごくない?

88 :名前は開発中のものです。:2008/07/04(金) 00:30:18 ID:lh91Gh1r
専門知識を蓄えてしまうと、ますます話の合う人間がいなくなりそうな予感。

89 :名前は開発中のものです。:2008/07/04(金) 05:23:01 ID:5KkF19ee
>>84
ソフトウェアに携わる人間で米コンプレックスを感じない人は
無能あるいは情報弱者だろう
欧州はそれほどとも思わないけどアメリカリードしすぎ

90 :名前は開発中のものです。:2008/07/04(金) 05:32:42 ID:fzMGN+kp
>>89
海外はすごいよ。
開発するにしてもニッチな物になればなるほど日本側で
解説してるのが少ない。

結局は翻訳サイトで翻訳しながら自力で学習してる。


91 :名前は開発中のものです。:2008/07/04(金) 05:48:08 ID:dN9x2gJA
それ、英語の普及範囲を評価してるだけだろ
日本人の英会話力の低さは別問題だよもう

92 :名前は開発中のものです。:2008/07/04(金) 05:56:42 ID:KBN1fM3d
米コンプレックスとは世界の「知」が集まる「場」「国家」に対するコンプレックス
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」

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

言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ


93 :名前は開発中のものです。:2008/07/04(金) 05:57:56 ID:KBN1fM3d
>>91
かぶったスマンコ

94 :名前は開発中のものです。:2008/07/04(金) 06:11:54 ID:KBN1fM3d
ところで休暇中に発見した格安で愉快な英語おしゃべり上達法
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ

95 :名前は開発中のものです。:2008/07/04(金) 06:28:19 ID:KBN1fM3d
米国の現場における労働集約型闘争が生み出した兵隊の質の低下は
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234

「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数の変態テクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる

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

97 :名前は開発中のものです。:2008/07/04(金) 06:58:00 ID:KBN1fM3d
切羽詰って偽装請負みたいなことやっちゃってたりするよな

98 :名前は開発中のものです。:2008/07/04(金) 08:23:31 ID:BChTVd/d
>>96
>日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
>海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
>ってことらしいぞ。

これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。

99 :名前は開発中のものです。:2008/07/04(金) 08:49:34 ID:BChTVd/d
>>80
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/

○ 絵(とくに3D)がきれい。
○ 音楽も一般受けする質の高いものが標準。
○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまれている。

パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。


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

100 :名前は開発中のものです。:2008/07/04(金) 10:11:43 ID:pYjEAjeh
最近の家庭用の大規模RPGのデータってどう管理されてるのが多いんですか?
RDBですか?それともタダのファイル?

101 :名前は開発中のものです。:2008/07/04(金) 12:41:59 ID:tMJHCBTq
普通はゲームデータ制作ツールとゲーム実行エンジンを並行して作っていく。
データはファイルが多い。ゲームデータ制作ツールの仕様にもよるけど、バイナリファイルの場合が多い。
C構造体のバイナリダンプは実装が楽だからね。
PCゲーには、ユーザがテキストファイルを弄ってデータや設定を変えられるものもある。

102 :名前は開発中のものです。:2008/07/04(金) 13:10:11 ID:04Qw9LMa
国単位になるとステレオタイプのイメージに支配されちゃう人っているんだねぇ

103 :名前は開発中のものです。:2008/07/04(金) 15:33:28 ID:eL1SAVRC
マの話はマ板でやってくれ

>>100
某タイトルはSQLite使ってるな

104 :名前は開発中のものです。:2008/07/04(金) 20:15:06 ID:HsoNh4J4
>>87
> 論文の質・量で言うとMicrosoft Researchのほうがすごくない?

同意。世間じゃGoogleを持て囃すのが流行ってるけど、むしろ
コンピュータサイエンスはMSRのほうがすごい研究者を集めてる。

105 :名前は開発中のものです。:2008/07/05(土) 11:31:29 ID:rip3o1Gr
>>104
研究者の層の厚さだと IBM 強いよなぁ。

Google は R&D でも R より D 寄り。

106 :名前は開発中のものです。:2008/07/05(土) 11:38:06 ID:rip3o1Gr
>>103
まだ、主流は独自フォーマットのバイナリだと思うな。

CSV か XML っぽいフォーマットでデータファイル作っておいて、コンバータで
バイナリに変換して組み込み。


107 :名前は開発中のものです。:2008/07/05(土) 11:38:38 ID:Def2so2E
だめだ、全然話についていけないぜ

108 :名前は開発中のものです。:2008/07/05(土) 11:41:27 ID:qX1NKMBA
>>99
> ○ 絵(とくに3D)がきれい。
> ○ 音楽も一般受けする質の高いものが標準。
> ○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまnれている。

ちょwwわかってかいてんのかよww
全部、投入できるリソースの違いで解決できるじゃねーかw

109 :名前は開発中のものです。:2008/07/05(土) 11:44:02 ID:qX1NKMBA
俺は、海外のインディゲームデベロッパーを結構チェックしているが、
絵がきれー、とか音楽すげーとかってなかなかないよ
それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。

たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり(日本かとおもうけど、海外の話だよ)

110 :名前は開発中のものです。:2008/07/05(土) 11:44:46 ID:qX1NKMBA
連投ごめん、音楽すげーはけっこうあるわw まあ俺がテクノ好きなだけかもしれんけど

111 :名前は開発中のものです。:2008/07/05(土) 13:29:28 ID:E9y2cnx1
雑談スレに移動すべきだと思うけど二つだけ。

そもそも一国と世界を比べることに意味があるのかな。

言語障壁はローカルのコミュニティが栄えない理由にならないよね。

112 :名前は開発中のものです。:2008/07/05(土) 20:57:12 ID:UjEcMe9W
>>108
>>109

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

113 :名前は開発中のものです。:2008/07/05(土) 21:01:08 ID:rip3o1Gr
日本の職人はゲームじゃなくて、ニコ動に集ってるだけだろ。

114 :名前は開発中のものです。:2008/07/05(土) 21:23:48 ID:hYTfj9Xn
方向性が違う物を比べても何にも成らないのに

115 :名前は開発中のものです。:2008/07/06(日) 00:07:36 ID:Gwo/Ylg2
>>80だが

>>99
繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。
IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは
なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる

>英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける
>ttp://www.gametunnel.com/

ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか?してないだろ
特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる
(下半身産業が絡んで不公平になるので全年齢のみで比較してもいい)

>日本のフリーとかシェアは(中略)
>グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。

だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに
「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい?毎日好きでもないものを延々作らされてる
腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために
真剣に取り組んでるよw素人に八つ当たりする前に自分の胸に手を当てて考えろっての。

あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。
他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが
ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない
弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい

116 :名前は開発中のものです。:2008/07/06(日) 00:20:54 ID:Gwo/Ylg2
外国すげぇ日本だめ論が好きな連中は日本の文化を否定する傾向にあってあまり好かん。
アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。
趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。
エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。

世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。
あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい

117 :名前は開発中のものです。:2008/07/06(日) 00:32:11 ID:ADZbZeYt
日本人はどちらかといえば何か分からんが動いたから良いやって人が多
い気がするね。
昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ
てるって何かの本に書いてた気がしないでもない。

SEやらPGやってる人なら分かると思うけど「なんで?どういうこと?」っていう
のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア
には向かないと思う。

まぁ外人云々じゃなくて正確か??

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

119 :名前は開発中のものです。:2008/07/06(日) 00:34:25 ID:Gwo/Ylg2
>>117
かぶったスマン

120 :名前は開発中のものです。:2008/07/06(日) 00:34:55 ID:7QhD5OiR
熱く語ってもらってるとこ悪いけどお前らスレ違いだ

121 :名前は開発中のものです。:2008/07/06(日) 00:42:02 ID:Gwo/Ylg2
ああ、悪い。次に長文レスするときは↓に投げることにする
現役開発者が質問に答えるスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1214321147/l50


122 :名前は開発中のものです。:2008/07/06(日) 00:44:51 ID:VtZ5ywY1
>>115
>腹いせに素人に因縁付けてるようで感心しないな。
感じやすいんだな。

一つ俺が言いたいのはさ、スキルがあるんだったら、
小規模ながらもグローバルな金儲け(変な言葉だ)に挑戦すること考えた方が、
面白えんじゃねえのってことだよ。

自身の嗜好に自信がないって?
じゃあ、そいつは一体何をやっているんだ。

123 :名前は開発中のものです。:2008/07/06(日) 00:48:46 ID:mek7cAwO
スレ違いだボケども

124 :名前は開発中のものです。:2008/07/06(日) 01:43:19 ID:D1fZ4Z3G
> SEやらPGやってる人なら分かると思うけど
PG以外がこのスレに居るのかと問い詰める必要があるな

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

126 :名前は開発中のものです。:2008/07/06(日) 07:43:01 ID:XCulGsMF
日経のサイトのベーマガ2.0の記事も読んでました。
ベーマガがどんなものか実は知らないのですが日本の
アマゲーコミュニティがないから悪いって言ってたので
我が意を射たりって感じでした。
土日スレで投稿してましたがいつも荒らされてました。
PCゲーム板のフリゲ厨とか氏ねと思ってました

俺は今もDirect3Dとかわけわかんないです。そういうのを
教えてくれるベーマガみたいなものに出会えなかったから
ファミ通の特集記事のゲーム専門学校すごいと思って
高校の先生の反対を押し切ってゲーム専門学校に行きました。
でも専門学校の講師も3D苦手でした。
おまえらには3D無理だから2Dで卒業制作作れって言われたので
言う通りにしました。今思えば先生が分からないもの作られると
質問されても答えられないから嫌だったんだと思います。
ゲーム専門学校に行ったことをすごく後悔してます。
ファミ通氏ねと思いました。きっとベーマガがあれば俺の人生
違ってたかもと思いました。やっぱおまえらが悪い

127 :名前は開発中のものです。:2008/07/06(日) 07:59:00 ID:XCulGsMF
すみません。ついカッとなってまたスレ違いのこと書いちゃいました
消えます

128 :名前は開発中のものです。:2008/07/06(日) 08:43:38 ID:S3/2UtrA
ネタじゃなかったら真面目に一度精神科に行くべき。
明らかに躁鬱の傾向が見て取れる。
過度のストレスで脳に器質的な損傷が出来てるかもしれん。

129 :名前は開発中のものです。:2008/07/06(日) 09:01:33 ID:VtZ5ywY1
>>123
何も語れない馬鹿よりはマシ。

130 :名前は開発中のものです。:2008/07/06(日) 09:28:24 ID:I4JuM713
まあ、消えなくていいからまた、スレ違いじゃなくてよさげな情報あったら教えてくれよ

131 :名前は開発中のものです。:2008/07/06(日) 10:03:51 ID:4WjvpweZ
>>129
さすがにそれはねーよw
スレ違いでも知識をひけらかすほうが賢いと?

まあ、あまり過疎ってもらってもつまらんのだが・・・


132 :名前は開発中のものです。:2008/07/06(日) 13:03:17 ID:cXpJQpiz
tunnelでおすすめのゲームを教えてkれ

133 :名前は開発中のものです。:2008/07/06(日) 15:04:16 ID:ZiAdcqL1
VIPから来ました
ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて

134 :名前は開発中のものです。:2008/07/06(日) 16:19:57 ID:le8Gr2pO
いや、作者じゃないと殴り込めないわけだが

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

136 :名前は開発中のものです。:2008/07/06(日) 17:01:01 ID:a3zGOuXr
マ板でやれっつの
あーあ

137 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/07/06(日) 17:44:48 ID:bleemPMj
みんな独自のウィンドウマネージャー(画面管理)クラス作ってるのかなあ

139 :名前は開発中のものです。:2008/07/06(日) 22:29:37 ID:mQf6Jrcq
>>135
良いこというなぁ。
禿同。

社長に。

140 :名前は開発中のものです。:2008/07/06(日) 22:41:15 ID:NhLrwJLQ
シーン遷移をきれいに実装したいという話なら、俺は否定するぞ
ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる

やるんだったら他の部分に影響を及ぼさない程度にしておけ
無意味に分断しすぎて複雑にするな

141 :名前は開発中のものです。:2008/07/06(日) 23:15:17 ID:bOQhFRQW
>>140
めんどくさいのは、シーン遷移よりキャラクターの状態遷移だよな。仕様変更が
わりと発生しがちな部分だし。

142 :名前は開発中のものです。:2008/07/06(日) 23:34:33 ID:NhLrwJLQ
>>141
同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな

143 :名前は開発中のものです。:2008/07/06(日) 23:47:58 ID:bleemPMj
状態が変わる時は自滅させてから、見た目同じで中身は別の敵オブジェクトを生成するとか。


144 :名前は開発中のものです。:2008/07/07(月) 00:57:38 ID:FUQ1BpEu
>擬似コルーチン
浅学な俺にコレについて詳しく

145 :名前は開発中のものです。:2008/07/07(月) 04:37:03 ID:ohkg3t4w
>>144
以前けっこう調べた俺がコレについて詳しく

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

擬似コルーチン
 コルーチンっぽいことを擬似的にやること(を、>>141は言っているのだと思われる)。
 主な実装:
  マクロで実装:作成難度低、移植性高い、制限多い、読み手には超分かりずらい


感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。

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

146 :名前は開発中のものです。: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 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/07/07(月) 07:24:44 ID:1RaeXbIY
コルーチンは、タスクシステム総合スレで話題が出てたね

149 :名前は開発中のものです。:2008/07/07(月) 08:00:36 ID:FUQ1BpEu
あー、マイクロスレッドのことか!
それなら一応分かるような気がしないでもない

でもC++じゃあ無理だよね・・・

150 :名前は開発中のものです。:2008/07/07(月) 08:00:37 ID:0ql4peFo
fiber?

151 :名前は開発中のものです。:2008/07/07(月) 09:17:09 ID:1RaeXbIY
>>149
ネイティブに落とされる言語だと実現するにはコンパイラ依存になるんじゃないのかなあ?
スタックいじるし。

>>150
Windows用語ではそうかと。

てか、要点は>>145に書いてあるなw
うまいまとめだ

152 :名前は開発中のものです。:2008/07/07(月) 10:04:53 ID:BeipJAsv
コンパイラ依存じゃなくてアーキテクチャ依存だ。
setjmp()でコンテキストを保存したあと、保存したコンテキストの
スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。
C++だけで実装可能だぞっと。

153 :名前は開発中のものです。:2008/07/07(月) 13:31:17 ID:yE1V62Sc
fiberはRubyでも使われてるよ
スレッド(糸)より細いものだからファイバ(繊維)

あとJavaScriptにも1.7から導入されてるぜい

154 :名前は開発中のものです。:2008/07/07(月) 22:11:23 ID:oT4ePMXj
マイクロスレッドは理想だけどそこまでトリッキーなことやる踏ん切りが付かない

155 :名前は開発中のものです。:2008/07/07(月) 22:26:27 ID:yE1V62Sc
やっぱスクリプト以外ではやる気しないな

156 :名前は開発中のものです。:2008/07/07(月) 22:30:56 ID:nV3j1Oo/
タスクシステムはコルーチン実装の一つだね

157 :名前は開発中のものです。:2008/07/07(月) 23:47:06 ID:ZC8HSbxq
コルーチンの「コ」って子供の子って意味じゃないよね?

158 :名前は開発中のものです。:2008/07/08(火) 00:00:56 ID:2Ffcfnsn
cooperativeと一緒のco-だろ?

159 :名前は開発中のものです。:2008/07/08(火) 01:20:29 ID:DPfKtgJc
俺はオブジェクト指向で、シングルスレッドだな。

常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。
また一方で、オブジェクト発生イベントのリストを持っていて、
順次、メインループにオブジェクトが登録されていく。

この「オブジェクト発生イベントのリスト」はシーンに相当していて、
シーンを切替えたければ、今登録されているオブジェクトを破棄して、
イベントのリストを差し替えるだけでいい。

while (1) {
  for i=0...
  {
    オブジェクト[i]->行動();
    オブジェクト[i]->描画();
    オブジェクト[i]->当たり判定();
  }
  イベント発生()
}

160 :名前は開発中のものです。:2008/07/08(火) 17:13:03 ID:8FRUZW5m
>>159
PACに似てるが違う、オブジェクトの追加に強そうだが
そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感

ドメインロジックのテストを行うときにビューが関わってくる
逆にビューのテストを行うときにドメインロジックが関わってくるため
テストに多大な労力がかかる事が予想される
常にプログラム全体をテストしなければならないため、試行錯誤すると死ねる
render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き
2Dにしても描画に関する処理が単純でなければうまく動かないだろう

規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め
または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め

私はお勧めしない、追加のメリットが多大である場合は考慮に値するが
ゲームには不向きだと思う、特に3Dの場合は
俺は怖くて使えない

161 :名前は開発中のものです。:2008/07/08(火) 17:19:39 ID:8FRUZW5m
>>160
追加

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

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

163 :名前は開発中のものです。:2008/07/08(火) 23:04:46 ID:gy2iNnCl
コルーチンで擬似ってどういうこと?

164 :名前は開発中のものです。:2008/07/08(火) 23:41:41 ID:8FRUZW5m
>>163
擬似じゃなくていいのか、訂正
1.コルーチン、又は擬似のそれ

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

165 :名前は開発中のものです。:2008/07/08(火) 23:46:18 ID:iq4s5004
まぁいいけど、ライセンスがGPLで良けりゃこっちを使おうぜ。
ttp://www.xmailserver.org/libpcl.html

166 :名前は開発中のものです。:2008/07/09(水) 01:10:17 ID:vZNCPgy9
言語機能として付いてないC++で無理やんこやるのはいろいろ怖い気が
すんごい便利そうなんだけどなぁ・・・

167 :名前は開発中のものです。:2008/07/09(水) 07:23:21 ID:eQNI5n3r
そこまでするならスクリプト組み込んだほうが
よっぽど安全で楽だと思うけどな

168 :名前は開発中のものです。:2008/07/09(水) 09:40:38 ID:nYED4jrh
>>162
スレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。


>小規模な状態遷移の実装

>>146のような、行動予約の状態遷移を前提にしているのかな。
だとしたら、もっぱら自分は、C++で、

>4.通常の状態変数による管理(State含む)

と動作制御用独自スクリプトだな。


基本は、ゲーム開発で言うところのタスクシステムで処理。
各オブジェクトは、単一クラス中に、状態ごとに処理関数(メンバ関数)を用意する。

フレーム毎に、その時点の状態に該当する処理関数を、1回ずつ呼び出す。
その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。

状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。
動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。

表現くどいけど、悪しからず。

169 :名前は開発中のものです。:2008/07/09(水) 17:57:35 ID:7MZGZOjk
巣に帰れ
タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50

おまえらタスクシステム信者がクソでカスでゴミクズな理由は
自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ
または、それを考えようとしないところだ
ただ使えばいいと思い込んで、それで完結している
考えることを放棄したおまえらに設計能力を向上する機会はない

戦略のない戦術はただのテロだ

170 :名前は開発中のものです。:2008/07/09(水) 18:38:12 ID:vZNCPgy9
ひどいな・・・
なんでそんな暴言が吐けるの

171 :名前は開発中のものです。:2008/07/09(水) 18:47:18 ID:vvjjLorC
良く知らんがタスクシステムって言葉が出ると荒れるようだ
なんかそういうgdgdな経緯でもあったんだろうな

172 :名前は開発中のものです。:2008/07/09(水) 18:55:55 ID:nYED4jrh
>>169
http://pc11.2ch.net/test/read.cgi/gamedev/1215129226/4n

173 :名前は開発中のものです。:2008/07/09(水) 18:56:55 ID:iC3IHDcB
>>171
ゲーム業界の造語みたいなものだからな。
OS屋に言わせると「なにそれ?プ」というものらしい。

まあ一定60FPSとか30FPSといったフレームで常に動いてて
物の動きとか制御してるのがOSがタスクを処理してるのに見えるから
そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人
が言い始めたのそもそもらしい

174 :名前は開発中のものです。:2008/07/09(水) 19:21:37 ID:eQNI5n3r
やっぱり顔真っ赤にして噛み付くヤツが出ると思ったよ
しょうがないからその辺の単語は誤魔化して話進めてくれ
いつまで経っても話進まねーからな

175 :名前は開発中のものです。:2008/07/09(水) 19:22:14 ID:anjhk7B8
名前負けしてるよね、完全に。

176 :名前は開発中のものです。:2008/07/09(水) 21:10:22 ID:7MZGZOjk
話が進むわけないだろ
言ってる奴が、メリットもデメリットも把握していないんだから
ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない

宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
誰かこれを理解してみろクソが

177 :名前は開発中のものです。:2008/07/09(水) 21:12:45 ID:iC3IHDcB
噛み付いてはないけど・・すまんな

まあ俺的にはそんな何とかシステム(自称)はどうでもいいよ。

市販のゲームでも売り出す際は自称xxxシステム採用とかいう
元からそういうの好きな業界だし。


178 :名前は開発中のものです。:2008/07/09(水) 21:30:52 ID:4OXXlyYN
>>176
少し落ち着けよw
>宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
お前はこういう事を言うやつに馬鹿だのアホだの必死に噛み付くのか?
俺はスルーするけどな

179 :名前は開発中のものです。:2008/07/09(水) 22:16:56 ID:EYwlC03l
「面白いこと書いた」と思ってるんだろうなぁ。
端からはただのバカにしか見えてないけどね。

180 :名前は開発中のものです。:2008/07/09(水) 22:19:25 ID:SF8ehHxO
>>173
>OSがタスクを処理してるの
ってどんな実装してるの?

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

182 :名前は開発中のものです。:2008/07/09(水) 22:23:19 ID:iC3IHDcB
>>180
そりゃ・・・その辺はがんばって勉強して

キューだとかスレッドだとかタスクだとか
タイムスライスだとか

まあ同時に複数のものが動いてる(ように処理してる)風に出来るものかな
乱暴な言い方だけど。

183 :名前は開発中のものです。:2008/07/09(水) 22:24:41 ID:7MZGZOjk
そろそろ潮時か
君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった
有益だったぜw
また暇なときに挑発に乗ってやる
この完璧な捨て台詞を覚えておけよ

184 :名前は開発中のものです。:2008/07/09(水) 22:48:57 ID:XmNOce7Z
>>183
巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。
感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。

会社でタスクシステムで組みたいと同僚が言ったとして、
烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。
ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。

185 :名前は開発中のものです。:2008/07/09(水) 23:14:23 ID:nYED4jrh
>7MZGZOjk
なんというか、要するに、






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

186 :名前は開発中のものです。:2008/07/09(水) 23:17:00 ID:md3RJLJr
タスクスレに託すか。

187 :名前は開発中のものです。:2008/07/09(水) 23:26:06 ID:30d6bQh7
コードが繁雑になって来たので、大革命を起こしたら
以前より良い設計ができない上に、収集がつかなくなった。
svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。

188 :名前は開発中のものです。:2008/07/09(水) 23:50:08 ID:XmNOce7Z
>>186

189 :名前は開発中のものです。:2008/07/10(木) 00:33:17 ID:rFEYqRAa
>>186
神は自らタスクる者をタスク。


190 :名前は開発中のものです。:2008/07/10(木) 00:51:19 ID:A+tXgG+V
>>180
タスクスレの話題を続けるのはよくなさそうなので情報だけ
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/456
OSだからできることを思いっきり使ってるんで
管理手法以外はあまり参考にならんよ。
OS自体に興味があるならOS板にいくといいよ

191 :名前は開発中のものです。:2008/07/10(木) 00:54:31 ID:MjVgJsdw
PG系隔離スレの2大巨塔でタスク厨の押し付け合いイクナイ!

192 :名前は開発中のものです。:2008/07/10(木) 05:56:13 ID:nnoBQqoI
Google,自社開発のデータ構造化ツール「Protocol Buffers」を公開
ttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/

193 :名前は開発中のものです。:2008/07/10(木) 07:41:02 ID:99kxezye
>>186
【小さく審議中】
    ,、_,、  ,、_,、
  ,、_('・ω)(ω・`)、_,、
 ('・ω)u゚  ゚uu(ω・`)
  ゙uu゚( '・) (・` )uu'
    ゚uu゚  ゚uJ

194 :名前は開発中のものです。:2008/07/13(日) 00:51:10 ID:eBw+YtUV
素人です
つくりかけのゲームってどうやって動かしてテストするんですか?

195 :名前は開発中のものです。:2008/07/13(日) 01:06:26 ID:47vlxomf
ワタクシ ハ インクリメンタル ナ カイハツ ホウシキをとっているので
ちまちまと小規模な物を作って、それを拡張していく形になります。


第一段階: ウィンドウを表示する
第二段階: キャラクターを一つ表示する
第三段階: キャラクターを動かしてみる
第四段階: 飽きる


196 :名前は開発中のものです。:2008/07/13(日) 01:25:52 ID:eBw+YtUV
>>195
なんで途中までカタコトなんですか?

そういう個人規模でなくて、複数のPGで役割分担してる場合はどうするんでしょう?

197 :名前は開発中のものです。:2008/07/13(日) 01:29:50 ID:R4nPLnnD
そんなことシロウトせんでいいいよ

198 :名前は開発中のものです。:2008/07/13(日) 02:53:02 ID:lqrHuCir
動くところまで作ってからテストする

199 :名前は開発中のものです。:2008/07/13(日) 03:04:31 ID:uUrGa3AK
改めて言われるとあれだな
他にやりようないな

200 :名前は開発中のものです。:2008/07/13(日) 03:23:29 ID:eBw+YtUV
>>198
他人がつくったクラスがないと動かない場合はテストできないのでしょうか?

201 :名前は開発中のものです。:2008/07/13(日) 03:29:10 ID:uUrGa3AK
つ 単体テスト

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

202 :名前は開発中のものです。:2008/07/13(日) 03:29:54 ID:edzJ8FGN
たぶん、作りかけってのが何処までか分からんけど
目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす=エラーが出ないで動く なので

203 :名前は開発中のものです。:2008/07/13(日) 03:32:16 ID:edzJ8FGN
http://wiki.game-develop.com/
wikiのチュートリアル→段階的学習でもやってみては

204 :名前は開発中のものです。:2008/07/13(日) 04:56:24 ID:tw1/nxGs
>>200
そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな?
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。

205 :名前は開発中のものです。:2008/07/13(日) 09:43:53 ID:47vlxomf
>>200
もし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。

だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。

早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、


206 :名前は開発中のものです。:2008/07/13(日) 09:51:14 ID:timDAMYM
>>204

>>200は外注や営業職の言い訳で多発するんだよね。
あんなのはまともに相手するのも無駄。
「スタブ要るじゃん。 スタブ供給してくれないとコストにあわないんだよね」系で、素で言ってのけやがる。
超ウケルんですけど。
こういうのに仕事を与えないようにするのが業界の為だろ。

 政治的な理由により取引継続となったら、「スタブの作り方を指導しますから、
その講習料として、スタブ作成代を相殺ですね」ぐらいしか案が無い。

・こちらはスタブなんて、要求仕様の一部で料金内。jk
・カス会社は、どちらも追加料金や有料。
・解決してなくても解決!!!!

207 :名前は開発中のものです。:2008/07/13(日) 10:22:09 ID:L3kGAfa0
>>194
作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。

RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。

208 :名前は開発中のものです。:2008/07/13(日) 10:49:52 ID:UM30DsAY
作業分担?

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

209 :名前は開発中のものです。:2008/07/13(日) 11:17:51 ID:L3kGAfa0
>>208
全員が全体を把握できるのは、せいぜい3人ぐらいまでだな。その先は
ヒエラルキー作って、パート毎に管理業務やる人間を立てないと無理。

210 :名前は開発中のものです。:2008/07/13(日) 13:47:03 ID:DAEU2DrC
趣味ゲだと3人超えのマが介在するゲーム開発って
ほとんどないしな。大半はマが1人、多くて2人で>>408方式
ツーといえばカーの黄金タッグ。あ、ああじゃいる


211 :名前は開発中のものです。:2008/07/13(日) 13:48:37 ID:DAEU2DrC
×>>408 ○>>208

212 :194:2008/07/13(日) 14:07:22 ID:eBw+YtUV
非常に参考になりました。ありがとうございます。

>>208
それ実際には各人に漏れやズレが出て手戻りが出るんで、大規模プロジェクトでは無理では

213 :名前は開発中のものです。:2008/07/13(日) 14:19:00 ID:sqmPpN2O
Cだったらmain()関数書いて実行して、デバッガ等で動き見るかな…
仕事(勿論?非ゲーム)でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったw

個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどw

214 :名前は開発中のものです。:2008/07/13(日) 14:24:18 ID:RINNRPdb
大規模が何人か明確じゃないし、作業形態もネット上だけなのか
サークルのようなものなのか会社なのかもわからないから議論が発散してる

フリーソフト作るのに主力のプログラマ2〜3人と、バグ修正や機能強化の
パッチくれる人10人くらいでなら、MLとIRC使って>>208のような方針でやれてた

最初のバージョンはリリース済みで方向性が決まってたのが大きそうだ

>>212
作業するタスクを割り振りはちゃんとやって、頻繁なイテレーションと
継続的インテグレーションやるっつうのは何人くらいで破綻する?

215 :名前は開発中のものです。:2008/07/13(日) 15:08:38 ID:eBw+YtUV
>>214
1チーム10人以下で、各チームにリーダー2人ぐらいで、200人ぐらいのプロジェクトも回ってました。
素人なのでこれくらいしかわかりません。


216 :名前は開発中のものです。:2008/07/13(日) 15:15:30 ID:uaqPI4FP
>>215
プログラマの数は?

217 :名前は開発中のものです。:2008/07/13(日) 15:23:34 ID:L3kGAfa0
>>215
まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない(DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。

基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。

218 :名前は開発中のものです。:2008/07/13(日) 17:47:09 ID:eBw+YtUV
>>216
150人はプログラマでした

219 :名前は開発中のものです。:2008/07/13(日) 18:56:00 ID:UM30DsAY
>>208は半分冗談、半分マジだったんだが意外と受け入れられてるw

>>218
なんの素人なんだw
ゲームでプログラマ150人規模って洋げーでも多分ないのでは。予算的に。

マジレスしますと、
小さい規模ならメインプログラマがほとんど一人で下位システムを作っちゃうし、
大きい規模なら別の部署が作るから、
「作りかけの状態でどうやってテスト・・・」という事態があんまり無いでつ

220 :名前は開発中のものです。:2008/07/13(日) 21:19:15 ID:Q/hESmSh
大規模金融システムで、SEの数ってことならありうるが
ゲームのスタッフロールにマが150人も並んでたら壮観だな

ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー

221 :名前は開発中のものです。:2008/07/13(日) 21:20:02 ID:6QYOrVUt
ネトゲじゃねーの?


222 :名前は開発中のものです。:2008/07/13(日) 22:39:48 ID:3VGnVE92
マ150人てどんなネトゲだよ。。。

223 :218:2008/07/13(日) 23:00:22 ID:eBw+YtUV
ゲームのプロジェクトじゃないです。
詳細は言えませんが。

ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。


224 :名前は開発中のものです。:2008/07/13(日) 23:23:02 ID:UM30DsAY
俺の知る限り、ゲーム開発では基本的にテストは無いです
単体テスト→結合テスト→受け入れテスト、みたいな流れは無い

昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません

なので大部分がデバッグチーム頼みです

225 :名前は開発中のものです。:2008/07/14(月) 00:00:22 ID:yOzfOKcB
3Dの衝突判定ライブラリを書いていたときは、単体テスト使いまくりだったぞ。

>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う

226 :名前は開発中のものです。:2008/07/14(月) 00:02:24 ID:IEzc7ZIH
グラフィックやサウンドが絡む部分は自動化は難しいけど
ネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ

227 :名前は開発中のものです。:2008/07/14(月) 00:10:58 ID:cIaZ6JxY
一人で作ってる分には単体テストに拘る必要はないと思うな。
逆に(自分含めて)しっかり単体テストできるなら、複数PG開発も悪くないと思う。
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁w

テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな!

228 :名前は開発中のものです。:2008/07/14(月) 12:30:06 ID:Hnt5WQTk
(NetBSDをOSに使ってる)リコーのプリンタの開発チームは
PGだけで1500人だそうです

229 :名前は開発中のものです。:2008/07/14(月) 15:33:56 ID:xdO9+1xM
数万行の同人ソフトしか作ったことないけど、ゲームってプログラムとしては割合小規模じゃね?
乗っかってるリソースの量がとんでもないだけで。

実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム(シーン別)、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の2乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。

あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。

230 :名前は開発中のものです。:2008/07/14(月) 15:36:32 ID:Hy149M4+
>>229
勘定系だってそれほど変わらんよ。



231 :名前は開発中のものです。:2008/07/14(月) 15:40:51 ID:0Th48wDt
RPGみたいないろんな要素のあるゲームのプログラミングってどこから手をつけていったらいいですか?

232 :名前は開発中のものです。:2008/07/14(月) 15:47:11 ID:wxUymIt7
お好きなところからどうぞ

233 :名前は開発中のものです。:2008/07/14(月) 16:22:48 ID:Hnt5WQTk
MSXのドラクエ2も大学生が一人で全部作ったんだよね

234 :名前は開発中のものです。:2008/07/15(火) 13:15:33 ID:IiJYDS4l
RPGっていってもいまだといろんなシステムあるからな〜

古典的なドラクエ初期のように2Dオンリー

チョンゲーに代表される3D使ってるクリックゲー

235 :名前は開発中のものです。:2008/07/15(火) 13:29:25 ID:Hl1v93zY
P6のゼビウスは小学生が一人で作ったんだよね
(発売時は中学生?)
http://www.ne.jp/asahi/shiba/mic/nori/xevi_tiny1/index.html

236 :名前は開発中のものです。:2008/07/16(水) 17:02:22 ID:WbuXgq6y
>>230
勘定系は、人数は増えるけど PM しっかりしてればカオスにはならんよな。

金回りの話なのでミスが許されず、テスト工数がやったら膨らむから、
プロジェクト管理大変だけど。

237 :名前は開発中のものです。:2008/07/16(水) 17:02:59 ID:WbuXgq6y
>>231
メモリ管理

238 :名前は開発中のものです。:2008/07/17(木) 20:17:04 ID:uAQ9zE97
>>231
要素の洗い出し

239 :名前は開発中のものです。:2008/07/20(日) 02:44:36 ID:gpI6Slf5
先人のろくにコメントもないコードの解析だけで一ヶ月ぐらいコーディングもしないってことはありますか?

240 :名前は開発中のものです。:2008/07/20(日) 02:56:31 ID:L2XNyVag
>>239
移植モノで、しかも元のプログラマが辞めて連絡取れないという条件で
一度やったことがある。二度とやりたくない。

241 :名前は開発中のものです。:2008/07/20(日) 03:05:04 ID:x+htBSIe
ソースがあるだけマシだよ

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

242 :名前は開発中のものです。:2008/07/20(日) 03:08:22 ID:ZbM+kRVz
>>241
すみません… それ、たぶんウチだ orz

243 :名前は開発中のものです。:2008/07/20(日) 03:39:46 ID:18o8S9Zj
最悪だなそれ

MAMEでも進呈したほうがいいな

244 :名前は開発中のものです。:2008/07/20(日) 15:36:02 ID:gpI6Slf5
オブジェクト指向のくずれてるウンココードに出会ったらどうしますか?

245 :名前は開発中のものです。:2008/07/20(日) 17:18:51 ID:g88tpUo2
見なかったことにする

246 :名前は開発中のものです。:2008/07/20(日) 17:43:16 ID:1Zabkxz6
それ俺だな。
どうやれば良いか分からないから、手探りで書いてる(´・ω・`)

247 :名前は開発中のものです。:2008/07/20(日) 22:53:25 ID:zgBZw03q
シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない?

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

249 :名前は開発中のものです。:2008/07/20(日) 23:02:30 ID:USb+9tXO
どういう意味?
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど?

250 :名前は開発中のものです。:2008/07/21(月) 01:05:54 ID:9zclfNbN
>>247の文章が破綻


251 :名前は開発中のものです。:2008/07/21(月) 14:17:23 ID:Y7Mzeak+
コメントにシングルトンと書かれてるのに2つも3つもインスタンスが
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn

252 :名前は開発中のものです。:2008/07/21(月) 18:53:57 ID:9zclfNbN
XBOX360, PS3, Wii 売れ行きに関係なく、開発しやすいプラットフォームはどれ?

253 :名前は開発中のものです。:2008/07/21(月) 18:54:50 ID:NGr1sFSW
箱○

254 :名前は開発中のものです。:2008/07/21(月) 23:51:13 ID:yo6BY71C
箱○は個人で十分開発できるからなぁ

255 :名前は開発中のものです。:2008/07/22(火) 00:00:52 ID:grvq6f3A
箱○ 天国
Wii   普通
PS3 言わせるなw

という感じか?

256 :名前は開発中のものです。:2008/07/22(火) 00:03:34 ID:9zclfNbN
>>255
詳しく

257 :名前は開発中のものです。:2008/07/22(火) 00:08:34 ID:zCVKhHD7
お前ら本当に3機種の開発ツール使ったことあるのかとw

258 :名前は開発中のものです。:2008/07/22(火) 00:21:20 ID:inlA4ozd
なんで個人開発限定なんだよ

259 :名前は開発中のものです。:2008/07/22(火) 00:35:03 ID:88jYUtHh
XNAのことを言ってると予想

260 :名前は開発中のものです。:2008/07/22(火) 02:21:06 ID:TRIzaodv
XNAの市販ゲームが出たってニュースは前に見た気がするけど
実際どんなもんなんだろ

261 :名前は開発中のものです。:2008/07/22(火) 02:44:01 ID:kfP9Fty3
サターンのSBL,SGLしか使ったこと無い

262 :名前は開発中のものです。:2008/07/22(火) 02:45:19 ID:zCVKhHD7
360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話?

263 :名前は開発中のものです。:2008/07/22(火) 16:12:48 ID:k5fUsZQo
Wiiはインターネットチャンネルどころじゃない

264 :名前は開発中のものです。:2008/07/22(火) 18:29:14 ID:c7QeI/ED
ゲーム機はDirectXを使うの?

265 :名前は開発中のものです。:2008/07/22(火) 18:36:04 ID:Jekk8SUv
DirectXはMSだけ
あ、Dreamcastという例外があるか

266 :名前は開発中のものです。:2008/07/22(火) 20:52:26 ID:6od3yLDu
ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。
DirectXそのものを使ってるかどうかは知らないが。

267 :名前は開発中のものです。:2008/07/25(金) 15:29:12 ID:9vpYBrtF
やってみて、無理と判断され、チームを外されることってある?

268 :名前は開発中のものです。:2008/07/25(金) 20:06:41 ID:66T6bhjF
>>267
板違い

プログラマー@2ch掲示板
http://pc11.2ch.net/prog/

269 :名前は開発中のものです。:2008/07/26(土) 01:19:05 ID:+2uolo1R
いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。

270 :名前は開発中のものです。:2008/07/26(土) 02:28:02 ID:Esaqa0cW
アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね?

271 :名前は開発中のものです。:2008/07/28(月) 18:13:52 ID:9GhNVVJ3
前者は状態フラグの配列なり持っておけば十分だろ
後者はなんだ?状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ

272 :名前は開発中のものです。:2008/07/29(火) 14:37:45 ID:kHD6g876
>>271
なるほど。フラグの状態で、出るコマンドを制御すればいいのか。
サンクス

273 :名前は開発中のものです。:2008/07/31(木) 18:14:30 ID:ucHp1Nqp
メニューコマンドってみんなクラス化しているもんなのかな?
メニューオブジェクトを生成してどうこうみたいな。

274 :名前は開発中のものです。:2008/07/31(木) 21:20:41 ID:Gc2qBZ+R
ベタコードで記述したり構造体・配列のままより
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね?
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。

275 :名前は開発中のものです。:2008/07/31(木) 21:26:22 ID:NXR7vyyv
フロントコントローラーパターンとコマンドパターンでやります。

276 :名前は開発中のものです。:2008/07/31(木) 21:38:09 ID:A+bu5iPx
メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは
だいたい同じインターフェースを実装してる。


277 :名前は開発中のものです。:2008/08/01(金) 00:01:16 ID:yD3o9/Uf
クラスメンバって全部privateにしてgetterでしか取得できないようにするべき?
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし


278 :名前は開発中のものです。:2008/08/01(金) 00:11:49 ID:yp70Uz6t
>>277
クラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。
たぶん何か間違っている。

279 :名前は開発中のものです。:2008/08/01(金) 00:14:41 ID:GzWnlC6Z
>>277
俺も同じようなこと悩んでて、気がついたら両方混在してた。

「これはクラスじゃない、構造体なんだ!」
って言い聞かせながらところどころpublicにしてたりw

280 :名前は開発中のものです。:2008/08/01(金) 00:22:47 ID:z2aBgJTr
全部て
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて

281 :名前は開発中のものです。:2008/08/01(金) 00:28:14 ID:4UGZmRTZ
排他制御や状態確認が不要ならどうでもいいかもだけど
コード書くのがマンドイだけなんじゃ?
まっしなIDEやプロパティのある言語つかうとかかな。

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


283 :名前は開発中のものです。:2008/08/01(金) 00:36:38 ID:z2aBgJTr
まて、そら元々アクセサの設計が統合可能だった場合だろ
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……

守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ?

284 :名前は開発中のものです。:2008/08/01(金) 00:47:59 ID:GzWnlC6Z
>>283
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。

あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。

285 :名前は開発中のものです。:2008/08/01(金) 00:54:19 ID:b/gVwGdZ
getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、
publicにした方が使う側は書きやすくでいいんじゃないの?と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・

286 :名前は開発中のものです。:2008/08/01(金) 01:01:50 ID:b/gVwGdZ
しかもget()で取得するのが配列だったりすると、
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。


287 :名前は開発中のものです。:2008/08/01(金) 01:02:58 ID:tFL87oCT
とりあえずpublicで書いていって、
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。

288 :名前は開発中のものです。:2008/08/01(金) 01:07:26 ID:b/gVwGdZ
>>287
なるほど。あまりスッキリしないやり方ですが、しょうがないですかね。
いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。

289 :名前は開発中のものです。:2008/08/01(金) 01:09:03 ID:b/gVwGdZ
特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。



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

291 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/08/01(金) 02:26:05 ID:ua9U6ROu
getter,setterがpublicなら外部参照する可能性があるということで
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。

293 :名前は開発中のものです。:2008/08/01(金) 03:52:45 ID:eorE7C0S
getterロボ

294 :名前は開発中のものです。:2008/08/01(金) 04:12:11 ID:gQhqelIh
メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。

295 :名前は開発中のものです。:2008/08/01(金) 18:37:49 ID:YDkT93Ih
>>294
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。

296 :名前は開発中のものです。:2008/08/01(金) 19:02:25 ID:m4Vy5Xwk
理想と現実はだいぶ違うよな
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする

297 :名前は開発中のものです。:2008/08/01(金) 20:43:12 ID:mQpnHwPh
インターフェース中心の設計でプログラミングするんだったら
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。

298 :名前は開発中のものです。:2008/08/02(土) 00:14:18 ID:n2w2ONnP
ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる(トイイナw

299 :名前は開発中のものです。:2008/08/02(土) 00:25:25 ID:MidBaG0Q
しかしgetやsetが乱れ飛んで読みづらくなることも

300 :名前は開発中のものです。:2008/08/02(土) 06:50:04 ID:xZ8r6Jdx
>>299
プロパティが欲しいと。

301 :名前は開発中のものです。:2008/08/02(土) 11:52:40 ID:eytLWJfu
C#はそういう意味ではスマートだなぁ

302 :名前は開発中のものです。:2008/08/02(土) 23:43:30 ID:Pnu26psa
ゲームのシーン管理ってどうすりゃいいんだろう

303 :名前は開発中のものです。:2008/08/03(日) 02:53:56 ID:DVblpxWK
シーンつったってゲームによって全然違うからな
もう少し具体的に

304 :名前は開発中のものです。:2008/08/03(日) 16:40:36 ID:HN+lqKwd
>>301
現行のゲーム機はまだC++なんだよな

305 :名前は開発中のものです。:2008/08/03(日) 21:47:19 ID:XQeDRsrL
>>302
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。

そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、

結局どんな処理が必要などんなゲームなのか?
どれを止めると不味いか、どれは止めても復帰させれば問題ないか?
とかによると思う。

306 :名前は開発中のものです。:2008/08/03(日) 21:52:25 ID:qGD4tU/f
シーンて、どのゲームも
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの?


307 :名前は開発中のものです。:2008/08/03(日) 22:00:54 ID:0ZCECk8O
おいどんのシーンは一種のタスクシステム(笑)で、
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。

308 :名前は開発中のものです。:2008/08/03(日) 23:21:42 ID:HN+lqKwd
FFとかのムービーシーンの管理はどうやればよかですたい?

309 :名前は開発中のものです。:2008/08/03(日) 23:31:02 ID:+gPnPllx
プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。

いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と

310 :名前は開発中のものです。:2008/08/03(日) 23:31:41 ID:+gPnPllx
あれ? ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス?

311 :名前は開発中のものです。:2008/08/03(日) 23:31:45 ID:0ZCECk8O
>>308
ムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。

312 :名前は開発中のものです。:2008/08/04(月) 17:38:42 ID:OcXTlg2n
うさんくさか博多弁多かたいね。なんかぐらぐらこく

馬鹿にしないでください><

313 :名前は開発中のものです。:2008/08/04(月) 23:28:56 ID:Vp8LYTR0
>>312
こらあげにまっことすまんかったぜよ。

314 :302:2008/08/04(月) 23:40:39 ID:OTznAvMd
>>306
そうそうそんな感じ。

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

315 :名前は開発中のものです。:2008/08/07(木) 02:18:10 ID:iFGNdN4x

  しーん…


316 :名前は開発中のものです。:2008/08/07(木) 15:44:15 ID:J5sJkFaL
【 審議中 】
  ∴∵

317 :名前は開発中のものです。:2008/08/24(日) 00:35:34 ID:kCbI2Ziv
(審議が長引いています。今しばらくお待ちください)


318 :名前は開発中のものです。:2008/08/27(水) 21:03:35 ID:pp3RgERm
キャラクターの状態って、どうやって実装してますか?
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか?
stateパターンでは無理???

319 :名前は開発中のものです。:2008/08/27(水) 21:31:52 ID:tgwWcjRq
それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う

ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。

マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。

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

321 :名前は開発中のものです。:2008/08/28(木) 01:16:45 ID:q3w3U78u
>コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな!」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。

ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねw


322 :名前は開発中のものです。:2008/08/28(木) 01:34:35 ID:O/+Qqs/2
最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな

323 :名前は開発中のものです。:2008/08/28(木) 03:20:26 ID:tq3ymPlL
関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。

324 :名前は開発中のものです。:2008/08/28(木) 09:12:41 ID:y2qhH8VC
そこで goto ですよ

325 :名前は開発中のものです。:2008/08/28(木) 10:11:26 ID:MS2hHN8x
某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。

326 :名前は開発中のものです。:2008/08/28(木) 11:46:09 ID:Qlb2/Pnm
javaは関数ポインタ使えないんだ・・・・

327 :名前は開発中のものです。:2008/08/28(木) 11:57:21 ID:MS2hHN8x
>>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。

328 :318:2008/08/28(木) 17:59:10 ID:Z+eKsEJG
>>321,322
汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたw)。
完成させることが第一と思っていてもついつい・・。

>>323,327
stateパターンですよね?

>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。


329 :名前は開発中のものです。:2008/08/28(木) 18:35:54 ID:CuTVRbF+
自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。


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

330 :名前は開発中のものです。:2008/08/28(木) 19:03:37 ID:Jt4Hw7jN
むしろ可能な全ての表記法を試す勢いで!
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。


331 :名前は開発中のものです。:2008/08/28(木) 19:43:21 ID:MS2hHN8x
人が書いたソースを読むのって勉強になるけど、読む気が出ない……

>>328
>stateパターンですよね?
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。

332 :名前は開発中のものです。:2008/08/28(木) 20:37:26 ID:xedxyhWb
>状態という概念が無い

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

333 :名前は開発中のものです。:2008/08/28(木) 21:28:28 ID:MS2hHN8x
>>332
他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。

334 :318:2008/08/28(木) 21:30:31 ID:Z+eKsEJG
>>329
コードの正しさ、綺麗さの2つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの3つがあると思っています。
今問題にしてるのは、主にこのうち後者2つです。
ただ、読みやすさは人それぞれなのかもしれません。

>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。

335 :名前は開発中のものです。:2008/08/28(木) 21:59:24 ID:O/+Qqs/2
保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの?


336 :名前は開発中のものです。:2008/08/28(木) 22:18:17 ID:qtCAmqfQ
ダライアス継承ってどんな継承?

337 :名前は開発中のものです。:2008/08/28(木) 22:22:03 ID:xedxyhWb
>333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる?

338 :318:2008/08/28(木) 23:04:17 ID:Z+eKsEJG
>>335
保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。

>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。

339 :名前は開発中のものです。:2008/08/29(金) 00:44:03 ID:hcEje8O4
ダライアス継承なんて初めて聞いたなあ

英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス(Darius?)はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな

340 :名前は開発中のものです。:2008/08/29(金) 00:50:36 ID:rESH+j3C
ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える

341 :名前は開発中のものです。:2008/08/29(金) 02:39:33 ID:VLtb7ZED
Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん

342 :名前は開発中のものです。:2008/08/29(金) 06:43:42 ID:gdp2Jatd
http://ir9.jp/prog/ayu/datlog/tech_cpp/1106527792/1106527792_01.html#R50

343 :名前は開発中のものです。:2008/08/29(金) 10:26:08 ID:ESvglHwU
>>337
合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)

344 :名前は開発中のものです。:2008/08/29(金) 14:31:33 ID:UaA8GGvx
>>341
>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw

345 :名前は開発中のものです。:2008/08/29(金) 14:34:13 ID:nV9hYRuE
>だったりしてw
いやだったりしてっつーかそれしかなくね

346 :名前は開発中のものです。:2008/08/30(土) 13:56:18 ID:vqGqt03L
ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。

347 :名前は開発中のものです。:2008/08/30(土) 14:18:00 ID:gGJd0yLw
ドラえもん 「ことわざゲーム」
これはいいアニメ。 ... ドラえもん 藤子F不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar

348 :名前は開発中のものです。:2008/08/30(土) 14:23:18 ID:h7pQaJrI
なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク

349 :名前は開発中のものです。:2008/08/30(土) 14:32:04 ID:hoYQeFVI
夏休みも終わりって事さw

350 :名前は開発中のものです。:2008/08/30(土) 14:40:33 ID:vqGqt03L
Bot使った宣伝書き込みかなぁ

351 :名前は開発中のものです。:2008/08/30(土) 15:36:27 ID:h7pQaJrI
なんかのマルウェアって聞いたが

352 :名前は開発中のものです。:2008/08/31(日) 15:40:22 ID:5jP5dBFC
A has B B has C C has Dのようなクラス構成で
Aで作ったEをDで使うために、Aから呼び出したB、Bから呼んだC、Cから呼んだDのそれぞれの関数の引数に
Eを渡していくのはいいのかな?

353 :名前は開発中のものです。:2008/08/31(日) 15:45:26 ID:eaWcmeF0
いいんじゃね。

354 :名前は開発中のものです。:2008/08/31(日) 15:47:56 ID:fQJxWw7j
別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない

355 :名前は開発中のものです。:2008/08/31(日) 15:54:48 ID:5jP5dBFC
>>353
>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と
思ったんだよね

356 :名前は開発中のものです。:2008/09/02(火) 03:29:08 ID:m23QvXa7
このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠


357 :名前は開発中のものです。:2008/09/02(火) 03:31:07 ID:m23QvXa7
>>352 >>355
コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。 っていうか、>>354 も言ってるけど、その構成だけだと(意図する形の意味づけが見えないと)
本当はいいとも悪いとも言えないが。


358 :名前は開発中のものです。:2008/09/02(火) 17:16:20 ID:BpB/a+5N
CarクラスはTireクラスを4つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか?

359 :名前は開発中のものです。:2008/09/02(火) 17:22:14 ID:Kf1ObPTz
コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外

360 :名前は開発中のものです。:2008/09/02(火) 17:30:36 ID:BpB/a+5N
TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか?

361 :名前は開発中のものです。:2008/09/02(火) 17:36:03 ID:NydWLubY
>>360
Tireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。

362 :名前は開発中のものです。:2008/09/02(火) 17:40:44 ID:IXiySr/S
タイヤが車に関心があるってどういう状況?

363 :名前は開発中のものです。:2008/09/02(火) 17:42:28 ID:NydWLubY
「パンクしたよ」って知らせてくれるんじゃね?

364 :名前は開発中のものです。:2008/09/02(火) 17:44:29 ID:IXiySr/S
なるほど

365 :名前は開発中のものです。:2008/09/02(火) 19:17:31 ID:gmtfIbjx
それ車が「パンクしたか?」メソッド持ってるんじゃダメなの?

366 :名前は開発中のものです。:2008/09/02(火) 19:20:27 ID:IXiySr/S
車が、常に「パンクしたか?」ってタイヤに聞くの?

367 :名前は開発中のものです。:2008/09/02(火) 19:24:40 ID:gmtfIbjx
うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど

368 :名前は開発中のものです。:2008/09/02(火) 19:38:46 ID:IXiySr/S
メディエーターみたいなの?

369 :名前は開発中のものです。:2008/09/02(火) 20:44:39 ID:F4HrtZLF
>>366
実際のTPMS(タイヤ空気圧監視システム)はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。

float _pressure = m_wheel[n]->GetPressureState();

370 :名前は開発中のものです。:2008/09/19(金) 19:13:57 ID:FmM/zRja
ほしゅ

371 :名前は開発中のものです。:2008/10/05(日) 14:32:14 ID:tMuqv+yj
このスレはJavaでも大丈夫なの?

372 :名前は開発中のものです。:2008/10/05(日) 14:52:40 ID:v7IsXRIY
>>371
質問内容の分野がよくわからないなら、以下へどうぞ。

【初心者】スレを立てる前にココで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288

373 :名前は開発中のものです。:2008/10/05(日) 17:40:56 ID:6np9SFhP
>372がエスパーすぎる

374 :名前は開発中のものです。:2008/11/01(土) 11:27:07 ID:g//jQFBy
データ(アイテムとかマップとか)ってどうやって作ってます?
エクセルで打ち込んでcsvで保存?

375 :名前は開発中のものです。:2008/11/01(土) 12:46:01 ID:YmfIaKZ8
別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし

376 :名前は開発中のものです。:2008/11/01(土) 12:58:04 ID:g//jQFBy
>>375
マップに関しては、フリーのエディタがあるんですね。

規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。

377 :名前は開発中のものです。:2008/11/01(土) 16:47:28 ID:NlVHrve1
既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。


378 :名前は開発中のものです。:2008/11/02(日) 08:08:32 ID:JeGt0JB9
海岸線自動生成とかやってくれるエディタあるっけ?

379 :名前は開発中のものです。:2008/11/02(日) 09:02:07 ID:i1X6CLvS
>378
エディタでやるの?

380 :名前は開発中のものです。:2008/11/04(火) 18:29:40 ID:CIBt14+U
機能としてはエディタ側じゃね?

381 :名前は開発中のものです。:2008/11/06(木) 00:16:08 ID:46fvhfrF
ツクールで海岸線をシフト+右クリックすると分かる

382 :名前は開発中のものです。:2008/11/11(火) 20:24:09 ID:rtOtwyEd
最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。

1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される(変数として保持される側の)クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。(関連する側が冗長になるが。)

2、再利用を考えたフレームワークは(初心者は)作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。

他に鉄則があったらだれか教えてください orz




383 :名前は開発中のものです。:2008/11/12(水) 01:30:10 ID:LsEQ4TEa
相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ!」
ピー…

384 :名前は開発中のものです。: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: 本
http://www.amazon.co.jp/dp/4873112494
http://images-jp.amazon.com/images/P/4873112494.09.MZZZZZZZZZ.jpg

385 :名前は開発中のものです。:2008/11/12(水) 23:23:14 ID:hxIHNKys
ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。

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

どれが適切でしょうか?

386 :名前は開発中のものです。:2008/11/13(木) 21:08:31 ID:3NMFClPL
>>385
boostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。

ってそういう話じゃない?

387 :名前は開発中のものです。:2008/11/14(金) 01:18:47 ID:USS/q0/d
>>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。

388 :名前は開発中のものです。:2008/11/16(日) 02:04:27 ID:OW89wflh
ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。

389 :名前は開発中のものです。:2008/11/19(水) 20:47:58 ID:oq/eqnIP
>>382-384
まだ読んでいない俺には勉強になったthx

390 :名前は開発中のものです。:2008/11/20(木) 09:17:22 ID:jP0yKBYe
>>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ

ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
(まああのペースで全部網羅すると、値段とページがすごいことになりそうだがw)

391 :名前は開発中のものです。:2008/11/30(日) 20:02:56 ID:GlMxgFAf
すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)

1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。

2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。

どなたか導きをお願いします









392 :名前は開発中のものです。:2008/11/30(日) 20:03:41 ID:GlMxgFAf
なんかいっぱい改行が入ってるorz

393 :名前は開発中のものです。:2008/11/30(日) 20:44:16 ID:O5396ILY
>>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。

ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。



394 :名前は開発中のものです。:2008/12/02(火) 23:03:37 ID:QPPOGJkH
>>393
気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。

395 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/12/13(土) 14:29:53 ID:lcU0tpK0
ゲーム開発論を語るスレを立てようと思っていたんですが、すでに似たようなスレがあると聞いて相談にきました。
このスレがあるので必要ないのでは?という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか?

↓ゲーム開発論スレ要望の経緯
http://pc11.2ch.net/test/read.cgi/gamedev/1206381315/

KONAMI、スクエニ、セガ、バンナム、コーエーの大手5社がゲーム開発現場の未来を再び討議
「5年後のゲーム開発現場を考える〜ゲーム会社技術開発の現場から2〜」
http://game.watch.impress.co.jp/docs/20080916/cedec_dev.htm

「Gears of War」はいかにして生まれたのか。Cliff Bleszinski氏が語る,有効なゲーム開発プロセス
http://www.4gamer.net/news/history/2007.03/20070309215934detail.html

Agile型開発でのゲームデザイン
http://www.4gamer.net/news/history/2007.03/20070311002313detail.html

397 :名前は開発中のものです。:2008/12/14(日) 06:46:04 ID:foB3PhGt
>>396
ここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ!!

398 :名前は開発中のものです。:2008/12/14(日) 06:47:43 ID:3zIx1sHY
想定通りでワロタ

399 :名前は開発中のものです。:2008/12/15(月) 01:28:13 ID:AODSdSoN
>>395
ありがとう助かるよ

400 :名前は開発中のものです。:2008/12/18(木) 23:54:28 ID:QLMqRIYY
キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。

401 :名前は開発中のものです。:2008/12/19(金) 12:11:03 ID:ygbWfkiR
俺はそうしてる。

402 :名前は開発中のものです。:2008/12/21(日) 09:35:05 ID:7nb+zy1b
つまりスクリプトですね。

403 :名前は開発中のものです。:2008/12/25(木) 19:24:07 ID:QpPf00tD
知ってるよDIって言うんだよね

404 :名前は開発中のものです。: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 :名前は開発中のものです。:2008/12/26(金) 08:47:36 ID:Y8oI6MzT
「勝手にメモ」を書き込んでくれる人(達?)の存在は、正直ありがたい

406 :名前は開発中のものです。:2008/12/28(日) 17:34:36 ID:pzJs6/UU
MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか?
Stateパターンという風にも捉えられる?

407 :名前は開発中のものです。: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 :名前は開発中のものです。: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の実装内容について
1、シーンは線形リストを形成し、末端シーンのrunを実行するように記述する。(rootScene → StgGame → StgPlayingや、rootScene → TitleScene → TitleHighScoreといったリスト構造になる。)
2、runのreturnに意味を決める。そしてそれによって処理が分岐するように記述する。null、自分、兄弟シーン、親以上。
・nullは、runしたシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。

・・・っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。



409 :名前は開発中のものです。:2009/01/07(水) 23:25:20 ID:rBsXmGd8
しかもミスってる。
# unfocusing ・・・『戻り値に次の遷移先シーンかnull返す。』 ←×

正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。



410 :名前は開発中のものです。:2009/01/09(金) 00:07:48 ID:vYDzTrO8
自作の状態遷移クラスに似てるな。

・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。

ってあたり、ほぼ同じっぽい。

戻り値って具体的に何を返しているの?
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。

411 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/01/09(金) 01:28:17 ID:vYDzTrO8
インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。

413 :名前は開発中のものです。:2009/01/10(土) 23:29:07 ID:GXwf3cbn
インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。

生成メソッドはstaticにするとかなんとか。

414 :名前は開発中のものです。:2009/01/11(日) 00:09:06 ID:dWwzUAmX
まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん

415 :名前は開発中のものです。:2009/01/11(日) 02:43:39 ID:cWr0moum
あれか? NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か?

416 :名前は開発中のものです。:2009/01/12(月) 02:58:31 ID:8xCnbJpy
>>414
PCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。

417 :名前は開発中のものです。:2009/01/12(月) 03:30:42 ID:mDvqZ10E
シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。

あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。

それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。

418 :名前は開発中のものです。:2009/01/12(月) 03:32:37 ID:mDvqZ10E
ごめん
×ライフサイクル
○ライフタイム

419 :名前は開発中のものです。:2009/01/12(月) 11:14:49 ID:pb2pea9L
そのあたりの話は研究しがいがあるな。

420 :名前は開発中のものです。:2009/01/12(月) 13:32:30 ID:YXD0YS+N
>>418
一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな?
クラス図の関連が木構造で、枝をはさみで切るイメージ。


421 :名前は開発中のものです。:2009/01/12(月) 14:12:02 ID:sqS0O25/
シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。

422 :名前は開発中のものです。:2009/01/13(火) 22:46:08 ID:BhFnEm7r
シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。

オレは管理マネージャ作るけど。

423 :名前は開発中のものです。:2009/01/13(火) 22:46:54 ID:BhFnEm7r
管理マネージャじゃマネージャマネージャだなw

まあC++になって楽になったものよ。

424 :名前は開発中のものです。:2009/01/14(水) 03:24:31 ID:0DnXfUAy
>>421
原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。

あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)

425 :名前は開発中のものです。:2009/01/14(水) 03:32:21 ID:0DnXfUAy
親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。

RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。

その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。

426 :名前は開発中のものです。:2009/01/17(土) 14:39:28 ID:AWtASysq
YAGNI


427 :名前は開発中のものです。:2009/01/21(水) 22:53:35 ID:sHv/LIGj
スレが止まってるとさびしいな。
独り言でも言ってるか。

STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。

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




428 :名前は開発中のものです。:2009/01/21(水) 23:23:50 ID:sHv/LIGj
オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。

publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。

どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
(本質的にバリアや耐久力表示と同じ関係なので。)

429 :名前は開発中のものです。:2009/01/22(木) 00:12:28 ID:P249I5A7
ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報(背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。

基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)

この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。



430 :名前は開発中のものです。:2009/01/22(木) 00:45:44 ID:P249I5A7
で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)

・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。

>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。

431 :名前は開発中のものです。:2009/01/22(木) 00:57:55 ID:P249I5A7
オブジェクト同士の衝突判定の記述。衝突判定まで。

・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。

衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。

誘導弾などの実装、は思案中。いい感じが思いつかない。



432 :名前は開発中のものです。:2009/01/22(木) 04:27:16 ID:lwlInfIx
>>427-431
とりあえず「管理」という言葉を使わないように考えることをおすすめする。
http://www.google.co.jp/search?q=SomethingManager

433 :名前は開発中のものです。:2009/01/22(木) 04:40:32 ID:P249I5A7
>>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。

434 :名前は開発中のものです。:2009/01/22(木) 15:25:00 ID:x7I7tNfu
大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。

435 :名前は開発中のものです。:2009/01/29(木) 21:46:47 ID:dRfTqeNw
そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい

436 :名前は開発中のものです。:2009/01/30(金) 16:55:21 ID:O2nIHOeq
>>434は別に口答えしてるわけじゃない気がするw

437 :名前は開発中のものです。:2009/01/31(土) 08:12:45 ID:qu7YpnnP
アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな?
とたまに悩む

438 :名前は開発中のものです。:2009/01/31(土) 12:07:33 ID:2t9biDkM
Gemsにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい


439 :名前は開発中のものです。:2009/01/31(土) 19:06:11 ID:mhj1e1O5
そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた

440 :名前は開発中のものです。:2009/01/31(土) 19:11:05 ID:L0OEs6zN
>>437
悩む悩むw

441 :名前は開発中のものです。:2009/02/01(日) 19:03:38 ID:tMKL4U61
>>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。

int near = CEnemy::returnNearNum();
enemy[near].attack();

↑こんな感じで静的なメンバ変数を返して貰っていたけど

STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。

442 :名前は開発中のものです。:2009/02/02(月) 20:35:13 ID:esDSGZyH
ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります

443 :名前は開発中のものです。:2009/02/03(火) 03:59:27 ID:cOF6NPxT
キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか

444 :名前は開発中のものです。:2009/02/06(金) 21:51:27 ID:+KF0MHRv
たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。

445 :名前は開発中のものです。:2009/02/06(金) 21:56:52 ID:jTgjQpbm
>>444
物の理を司る GOD class

446 :名前は開発中のものです。:2009/02/06(金) 21:57:18 ID:sBGSiXKq
分からないから指向をそのままレスとして出力。

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

ごめん、適当に書いただけ。


447 :名前は開発中のものです。:2009/02/06(金) 21:58:24 ID:y5Y5dk+m
唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん

448 :名前は開発中のものです。:2009/02/07(土) 00:34:27 ID://aDzdii
> ・石に重力を働かせる処理
石クラス

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

> ・石とマップの衝突処理
石クラス

449 :名前は開発中のものです。:2009/02/07(土) 01:46:53 ID:HaVHq232
> ・石に重力を働かせる処理
石クラス

> ・石と石の衝突処理
衝突判定クラス

> ・石とマップの衝突処理
衝突判定クラス


450 :名前は開発中のものです。:2009/02/07(土) 13:25:16 ID:bH//onUq
> ・石に重力を働かせる処理
ゲーム管理クラス

> ・石と石の衝突処理
ゲーム管理クラス

> ・石とマップの衝突処理
ゲーム管理クラス

451 :名前は開発中のものです。:2009/02/07(土) 14:22:20 ID:VS035g6S
> ・石に重力を働かせる処理
石に重力クラス

> ・石と石の衝突処理
石と石の衝突処理クラス

> ・石とマップの衝突処理
右とマップの衝突処理クラス

452 :名前は開発中のものです。:2009/02/07(土) 14:51:09 ID:VC/wpjC+
>>451
オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり?


453 :名前は開発中のものです。:2009/02/07(土) 16:19:23 ID:Pn1Dl7Zh
>>450
CGameManagerですね、わかります

454 :447:2009/02/07(土) 16:35:33 ID:oHEfOG3S
みんな何のことだかわかっていて俺涙目

455 :名前は開発中のものです。:2009/02/13(金) 17:17:04 ID:gamtZzLZ
テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。

これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。

456 :名前は開発中のものです。:2009/02/13(金) 17:35:30 ID:gamtZzLZ
455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。

457 :名前は開発中のものです。:2009/02/14(土) 00:06:30 ID:wuF2UeZP
沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな

458 :名前は開発中のものです。:2009/02/14(土) 00:20:27 ID:+0ELSliX
>>457
じゃあ新たなネタ出せよ


459 :名前は開発中のものです。:2009/02/14(土) 01:01:03 ID:1cFYmXpg
ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、1つだけ。

ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。

リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。

自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード&短かい時間で)デバッグできるか教えてほしい。

そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。

460 :名前は開発中のものです。:2009/02/14(土) 03:08:07 ID:qKH3GStO
人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はOFFで。

コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利/敗北または成功/失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール(数十倍〜数十分の一まで)。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。

スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。

461 :名前は開発中のものです。:2009/02/14(土) 10:08:02 ID:hPf9zE7f
リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。

462 :名前は開発中のものです。:2009/02/15(日) 16:27:42 ID:933sIzgh
速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。

463 :名前は開発中のものです。:2009/02/18(水) 14:05:52 ID:1weRwVko
>>460-462
いろいろありがとう。
あらかたデバッグ用に実装してみました。

464 :名前は開発中のものです。:2009/02/18(水) 14:39:48 ID:0gTNCSoI
行動力あるね
素晴らしい。見習いたい


465 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/02/21(土) 07:24:48 ID:3Qcrn5pr
洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。

467 :名前は開発中のものです。:2009/02/21(土) 12:50:08 ID:YLpnm94h
http://pc11.2ch.net/test/read.cgi/gamedev/1234977661/


468 :名前は開発中のものです。:2009/02/24(火) 16:03:05 ID:xS4ZudQO
スマートポインタの使いどころ教えて


469 :名前は開発中のものです。:2009/02/25(水) 02:46:38 ID:1o4GjPkR
使いどころっつーわけじゃないけど
次のC++規格が決まれば、早ければ今年中にも
 std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど

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

471 :名前は開発中のものです。:2009/02/25(水) 11:43:26 ID:woJXacCs
要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか


472 :名前は開発中のものです。:2009/02/25(水) 18:18:12 ID:QjeqtKpK
Yes
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ

473 :名前は開発中のものです。:2009/02/25(水) 18:28:42 ID:nKINhS/o
つまり、いらなくなったらすぐに消されるってことですね

私のように

474 :名前は開発中のものです。:2009/02/25(水) 18:31:43 ID:Z+e+XbPJ
不況だもんな・・・

475 :名前は開発中のものです。:2009/02/25(水) 18:55:09 ID:1o4GjPkR
いや、それは地球の資源不足で君の給料が確保できないだけだ
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・

476 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/02/27(金) 15:58:46 ID:XnWaU4Ou
デバイスホルダー的なシングルトン作るとか


478 :名前は開発中のものです。:2009/02/27(金) 17:33:53 ID:lChaxYTz
俺もシングルトンかな。参照回数が0になったらreleaseで。

479 :名前は開発中のものです。:2009/02/28(土) 00:40:47 ID:OR4wkfx2
ハッシュテーブルのキーって文字列じゃなくてもいいのかな?
符号なし整数とか。
どっかにそういう例ないです?


480 :名前は開発中のものです。:2009/02/28(土) 08:42:03 ID:Cadu6Xk7
ハッシュが計算できるなら、キーはなんでもいいよ

481 :名前は開発中のものです。:2009/03/04(水) 04:45:32 ID:y6+tTW6F
>>479
こんなんでいいか?
ttp://codezine.jp/article/detail/2171?p=2

482 :名前は開発中のものです。:2009/03/06(金) 11:34:39 ID:7UNSgj8M
C++でシングルトンするのってなんか滑稽じゃね?
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う

483 :名前は開発中のものです。:2009/03/06(金) 13:08:45 ID:A313Daxt
>>482
グローバル変数が欲しいんではなくて、システム全体で一つしかないということを
明示的にする為のパターンだから

484 :名前は開発中のものです。:2009/03/06(金) 14:26:30 ID:7UNSgj8M
グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう

485 :名前は開発中のものです。:2009/03/06(金) 14:28:31 ID:7UNSgj8M
あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。

486 :名前は開発中のものです。:2009/03/06(金) 15:48:06 ID:A313Daxt
>>484-485
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ

話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー

487 :名前は開発中のものです。:2009/03/06(金) 16:07:52 ID:7UNSgj8M
>>486
そのクラスのインスタンスが1つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ

C++でのシングルトンはマッチポンプなんだよ

488 :名前は開発中のものです。:2009/03/06(金) 16:18:21 ID:7UNSgj8M
http://www.geocities.jp/ky_webid/design_pattern/009.html

「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね?

// 生成やコピーを禁止する
↑アホじゃね? 最初からクラスにしなきゃいいじゃん

クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい

489 :名前は開発中のものです。:2009/03/06(金) 16:29:34 ID:7UNSgj8M
まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな

490 :名前は開発中のものです。:2009/03/06(金) 16:29:53 ID:oPKUKLY9
先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件

491 :名前は開発中のものです。:2009/03/06(金) 16:34:17 ID:7UNSgj8M
>>490
アンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか

492 :名前は開発中のものです。:2009/03/06(金) 16:39:54 ID:7UNSgj8M
クラスアンチだしw
http://www.google.co.jp/search?hl=ja&q=%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%A2%E3%83%B3%E3%83%81&lr=lang_ja
ググるとアンチクラスが出てくる上にプログラムカンケーねえしw

まあいいや
C++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい

493 :名前は開発中のものです。:2009/03/06(金) 16:57:37 ID:12yJl3As
労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん

>↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう

じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ


494 :名前は開発中のものです。:2009/03/06(金) 17:07:43 ID:7UNSgj8M
>クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
いくらでもあるのか

そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489

俺にはこの2つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね

>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484

495 :名前は開発中のものです。:2009/03/06(金) 17:20:31 ID:12yJl3As
>>484の方が楽だとは思えない
まあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな


496 :名前は開発中のものです。:2009/03/06(金) 18:55:30 ID:Erqh3NJs
namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。

ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。

それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。

497 :名前は開発中のものです。:2009/03/06(金) 20:00:35 ID:z7QigqBL
まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね

498 :名前は開発中のものです。: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;

厳密にインスタンス化の制限とか、もはやどうでもいいクラスw

499 :名前は開発中のものです。:2009/03/12(木) 10:43:53 ID:X7nBBwQA
>>498
捕捉:

(わかると思うけど)使う時は、他のユニットから

 Printer.HogeMageSimasu;

見たいに使う

あと抜けてるけど、実際には、finalzation節?でアプリ終了時のFPrinterの開放処理がある。

500 :名前は開発中のものです。:2009/03/16(月) 15:21:22 ID:FTtiBwy2
また変なのが沸いてるのか

501 :名前は開発中のものです。:2009/03/18(水) 23:45:50 ID:1sOkzJT6
デバイスに直接アクセスする処理ってどこに書いてる?
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。

今:あちこちでデバイスにアクセス
void draw_landform(void) {
  ...
  lpD3DDEV->draw(...);
}
void draw_menu(void) {
  ...
  lpD3DDEV->draw(...);
}

案:デバイスアクセスは1箇所。デバイスに渡すデータをあちこちで作る。
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 :名前は開発中のものです。:2009/03/19(木) 04:54:27 ID:KYbRBn+z
久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ!

503 :名前は開発中のものです。:2009/03/19(木) 05:21:17 ID:XLj1eEa+
描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。

504 :名前は開発中のものです。:2009/03/19(木) 19:28:19 ID:ALN5WhPj
俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);

draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…

505 :501:2009/03/20(金) 00:10:41 ID:/TREybMM
レスありがとう。

>>502
「案」の方に似たやり方だよね? draw_dataがリスト相当で。
やっぱやってる人いたか。採用してるってことは使いやすいんだろうか

>>503
void LandForm::draw(LPDIRECT3DDEVICE9 lpD3DDEV) {
  ...
  lpD3DDEV->draw(...);
}
みたいな感じ?
デバイスに直接アクセスする処理が複数のクラスに散らばるのはOKという判断?
この方が使いやすいってことかな? うーん。。。

>>504
Draw_data::draw(...) {
  this->lpD3DDEV->draw(this->draw_data, ...);
}
こんな感じ? ラッパー作れって話?
「案」ではないってことは 503 さん宛てのコードと同じ感じでやってるのか

うーん、デバイスクラスに依存するクラスが増えると身動き取りづらくなると思うんだけど
気になる人って少ないんだろうか。
0人では無かったけれど。


506 :名前は開発中のものです。:2009/03/20(金) 02:39:39 ID:D2lp0Ec4
まずはMVCを試みてみるのはどうだろうか

507 :名前は開発中のものです。: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 :名前は開発中のものです。: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: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()); }
ここを見るとデバイスに直接アクセスする処理を1クラス内、複数関数にまとめたって感じかな

うーん…、複数の関数にデバイスアクセス処理が分散してるとこがあまりうれしくないかな。
(俺には複雑過ぎるのはさておき)


俺が扱いづらいと思ってるところは、
pDeviceさえあればdraw()以外にもbegin_render()とかset_camera()とかいろいろ
デバイスに対して変更加えることができちゃうわけで、
それをばら撒くってことはいつどこでデバイスに変更が加わるか、例えばいつどこで何回begin_render()されてるのか
とかが追跡しづらくなる。これは1週間後の自分に優しくない。

こんな感じでデバイスに直接アクセスする処理をどう管理したもんかと考えて
ひとつの対策案としてデバイスアクセス処理を1関数内に限定しちゃえってのが >>501 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。

510 :名前は開発中のものです。:2009/03/22(日) 03:32:29 ID:O7e3N6nq
描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。

511 :501:2009/03/23(月) 00:38:25 ID:/nVLLFvd
>>510
確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ2D的にしか使ってないし。
あとデバイスってサウンドとか入力装置とかもあるけど、それらもおんなじ感じで取り扱いたいし。

デバイスにアクセスする処理が関数1個の中に「ひとまとまりで」収まってればOKとするなら
下のように書いて済ませられるかな?
void dev_state1(void) {
  lpD3DDEV->BeginScene();
  lpD3DDEV->set_parameter(...);
  lpD3DDEV->draw(draw_landform(), ...);
  lpD3DDEV->set_parameter(...);
  lpD3DDEV->draw(draw_menu(), ...);
  lpD3DDEV->EndScene();
}

ひとまとまりってのは1フレーム分のデバイスアクセス処理全部。
描画内容を大きく変えたい時はdev_state2()とかをまた別に作っておいて、
ゲームのステートに応じてどれを実行するか切り替える。


なんか描画スクリプトの方が夢があるな。
外部GUIツールで描画内容を設計して
吐き出した描画スクリプトをゲームで解釈して表示とかおもしろそう。
でも描画システムの根幹過ぎて汎用的に作るのめんどくさそう。。。

うーん、とりあえず簡単に済ませたいからdev_state1()みたいにベタ書きで
どこまでいけるかやってみるかな。

512 :名前は開発中のものです。:2009/03/25(水) 00:59:33 ID:koP5FPqt
hamigaki::coroutines使ってみた。

513 :名前は開発中のものです。:2009/03/25(水) 12:39:16 ID:C50L0uFm
yhamigakiさんのexec.jamモジュールにはお世話になっております

514 :名前は開発中のものです。:2009/04/05(日) 14:24:00 ID:a5PaoF6B
スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行

利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い

515 :名前は開発中のものです。:2009/04/06(月) 03:21:58 ID:NgKFyYts
仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。

516 :名前は開発中のものです。:2009/07/15(水) 22:32:12 ID:1c2msACv
http://www6.atpages.jp/~autonomydoll/game/RPGClient.zip

クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。

今のクラス構成
ScreenManger-->ScreenGame-->Title
     |                |->Main-->Map -|
     |                     -->Unit--->sprite--|
     |--------------------------------------------------------------->GraphicsWarpper


517 :名前は開発中のものです。:2009/07/15(水) 22:40:07 ID:h6KyoexM
WinAPI使ってるなら、WinSockで送信して、ウィンドーメッセージで受信する。他はシラネ。

518 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/07/15(水) 22:57:45 ID:cL81hhcG
こんな面白い難読化もなかなかないな

521 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/07/16(木) 01:35:23 ID:Ac1CnfQd
まず日本語と英語を勉強するべきでは?
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは1つもないね

ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う


524 :名前は開発中のものです。:2009/07/16(木) 02:06:03 ID:Dq9kBSTx
>>523
ありがとう。
それをあたってみる。

525 :名前は開発中のものです。:2009/07/16(木) 02:29:30 ID:lK28N0n1
質問の内容と関係ない単語にしかつっこめない奴が多くてワラタ

526 :名前は開発中のものです。:2009/07/16(木) 05:49:13 ID:0eDNLm6a
2〜3人で多いのか、寂しい生活してるんだな

527 :名前は開発中のものです。:2009/07/16(木) 10:25:09 ID:irpkCXOF
言われて悔しいならもっと勉強しろよ

528 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/08/14(金) 19:24:51 ID:qfXJNhjS
STGのビジュアル関連向上に関するメモ。
・・・あんま設計と関係ないな・・・

それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。

ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。

弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い・・・気がする。




530 :名前は開発中のものです。:2009/08/14(金) 22:21:56 ID:FZUQWr9u
>>529
設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。

531 :名前は開発中のものです。:2009/10/05(月) 01:40:33 ID:mQYy5BRf
シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが,
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか?

データクラスを作ってアクセッサで操作を許す?
それとも,すべてグローバル変数で持たせる?

532 :名前は開発中のものです。:2009/10/05(月) 04:33:25 ID:/TvwIsfE
シングルトンクラスのオブジェクトをグローバルに定義する

533 :名前は開発中のものです。:2009/10/05(月) 07:34:29 ID:Rel4l/Gg
SQLiteとか使って手抜くってのもあり

534 :名前は開発中のものです。:2009/10/14(水) 22:12:56 ID:TwzkU58s
グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。

535 :名前は開発中のものです。:2009/10/15(木) 07:50:05 ID:P3b4xThD
アクセッサ書くのめんどいだろ

536 :名前は開発中のものです。:2009/10/15(木) 08:41:22 ID:OtHf9VTl
なんでそんな両極端なの?

537 :名前は開発中のものです。:2009/10/15(木) 15:54:18 ID:byjv3si3
0と1しか無いからな
オタクの頭ん中は

538 :名前は開発中のものです。:2009/10/15(木) 20:13:55 ID:P3b4xThD
別に両極端で構いません.
意見を頂けるだけで嬉しいです.

むしろ噛み付くほうが迷惑です.

539 :名前は開発中のものです。:2009/10/15(木) 22:16:10 ID:r8d5RKMA
使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。

540 :名前は開発中のものです。:2009/10/15(木) 22:18:05 ID:2byzEsEE
>>535
アクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。

541 :名前は開発中のものです。:2009/10/15(木) 23:29:40 ID:r8d5RKMA
俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。

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

543 :名前は開発中のものです。:2009/10/16(金) 01:18:33 ID:MsmDVyev
2chで素直に謝られると逆に困ります.
参考になりました,ありがとうございます.

544 :名前は開発中のものです。: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 :名前は開発中のものです。:2009/10/16(金) 06:29:56 ID:UJ9WR3Zt
代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。

546 :名前は開発中のものです。:2009/10/16(金) 11:40:43 ID:/PDPq+0/
入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。

547 :名前は開発中のものです。:2009/10/16(金) 20:07:25 ID:eJ9LLkd5
アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。

548 :名前は開発中のものです。:2009/10/18(日) 12:51:59 ID:Yr/zm5ey
>546
確かに使い方を間違えるってのはよく起こる

549 :名前は開発中のものです。:2009/10/25(日) 23:29:18 ID:tIk7fQwv
Compositeをゲームのシーン管理に使うのってどうやるんですか?
次に来るシーンを各クラスに設定しておいたりとか・・?

550 :名前は開発中のものです。:2009/10/25(日) 23:57:46 ID:6R6DoQXi
何を聞いてるかがちょいと分からないけど
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。


551 :名前は開発中のものです。:2009/10/26(月) 00:08:52 ID:PLlfj58P
というか前スレの260あたりか。Compositeかどうかも微妙だな。スマソ

552 :名前は開発中のものです。:2009/11/16(月) 14:29:49 ID:FF5xAAX0
>>501
その後どうなった?
俺も今描画周りを考えてる

553 :名前は開発中のものです。:2009/12/13(日) 15:40:07 ID:Pf4hrG82
よく読んでないけどEmptyProject風に

void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}

void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}

って風にやったら問題あるの?

554 :名前は開発中のものです。:2009/12/14(月) 01:36:46 ID:etpwNEHL
deviceの作成は一箇所のクラスでシングルトン
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ

無知なんだけど、デバイスて何個も必要になることあんの?

555 :名前は開発中のものです。:2009/12/14(月) 01:57:52 ID:ViaP5WDz
デバイスが複数あったら複数必要なんじゃね。

556 :名前は開発中のものです。:2009/12/14(月) 03:13:37 ID:etpwNEHL
その複数てのがさ、動的に管理しないといけないものなら複数個保持するクラスにすればいいし
そうでないなら同じようなクラスを用意するかな

便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる

まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな

557 :名前は開発中のものです。:2009/12/14(月) 11:05:57 ID:QE4kvqHr
ボンバーマンを拡張して繋がれてるコントローラの数だけ
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。


558 :名前は開発中のものです。:2009/12/14(月) 14:08:44 ID:lLcah1pB
プレイヤが一人でも全てのコントローラで操作できるようにしているが
(左右同時に押された場合は後からの入力を優先)
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな

559 :名前は開発中のものです。:2009/12/14(月) 15:35:13 ID:ViaP5WDz
壊れたコントローラーはサポートしなくてもいいと思うよw

560 :名前は開発中のものです。:2009/12/21(月) 22:25:25 ID:F5CW/HFF
sharedptrみたいなの実装したいのですが、
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか?

boostソース読めってのは無しでお願いします。

561 :名前は開発中のものです。:2009/12/21(月) 23:10:45 ID:yYVJ9W7O
>>560
「スマートポインタ」でググれば解説もサンプルも見つかるよ。

562 :名前は開発中のものです。:2009/12/22(火) 01:26:27 ID:Q5u6VebD
>>560
なんで boost::shared_ptr 使わないの?

563 :501:2009/12/30(水) 05:37:23 ID:CHdRD74o
>>552
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。

簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。

コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列(描画スクリプトみたいの)を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。

デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。

564 :501:2009/12/30(水) 22:40:42 ID:CHdRD74o
>>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。

つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。

たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。

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

566 :名前は開発中のものです。:2009/12/31(木) 15:10:35 ID:wXwu3da7
>>565
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。

567 :名前は開発中のものです。:2010/01/04(月) 06:09:33 ID:JxRYn/a0
おおー、ゲームのバックエンドサーバーにもGAE使う時代かw

たしか、mixiアプリのモバイルゲームでGAE使った事例があったな。
3000万PV/月をかなり安価で乗りきれるとか

Togetter(トゥギャッター) - まとめ「100万PV/日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー」
http://togetter.com/li/494

すれ違いの話題になるが、昨今のネットが絡むゲームの場合バックエンドの技術も必要だけど、
そういう話題を扱ったスレってないものかな
この板にネットゲームの開発時代が少ないみたいだから、需要はないのかもだけど

まーGAEならWebProg板のAppengineスレ行けばいいしな

568 :名前は開発中のものです。:2010/01/04(月) 06:10:39 ID:JxRYn/a0
x 開発時代
o 開発自体

569 :名前は開発中のものです。:2010/04/20(火) 00:42:02 ID:pYU4LjYZ
前スレの最後のほうに出てた描画の話題って結局どうなりました?(928ぐらい)



570 :名前は開発中のものです。:2010/05/11(火) 16:43:34 ID:mK0DmPV5
http://blog-imgs-27.fc2.com/c/h/u/chudoku200/1239712143736s.jpg

174 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)