ゲームにおけるデータ構造・クラス設計・パターン2
■ このスレッドは過去ログ倉庫に格納されています
0001名前は開発中のものです。
2008/05/23(金) 21:10:59ID:8M1gqhPXどのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく
0002名前は開発中のものです。
2008/05/23(金) 22:15:47ID: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乙
一応デザパタ軽く。
0003名前は開発中のものです。
2008/05/24(土) 01:01:32ID:hwB5uNnT0004名前は開発中のものです。
2008/05/24(土) 01:10:28ID:hwB5uNnT・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。
0005名前は開発中のものです。
2008/05/24(土) 01:16:03ID:fCOY9f2qFoo foo = new Foo() とすると foo がインスタンス?
0006名前は開発中のものです。
2008/05/24(土) 01:24:20ID:WrI+RE5Ahttp://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも
0007名前は開発中のものです。
2008/05/24(土) 02:07:45ID:hwB5uNnT揚げ足取りな事はわかってるんだが一応。
fooは変数だから、fooが参照してる参照先の何か、がインスタンスじゃね?
文脈でわかるけど、ここら辺の表記も少し気をつけた方がいいかも。
0008名前は開発中のものです。
2008/05/24(土) 02:41:35ID:/DdfEDqzっていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな
0009名前は開発中のものです。
2008/05/24(土) 16:24:52ID:WrI+RE5A0010名前は開発中のものです。
2008/05/24(土) 17:17:01ID:LLc7AXF7WEB系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな?
0011名前は開発中のものです。
2008/05/24(土) 17:53:41ID:hwB5uNnTゲームをやる側から見た場合のRPG、特にFFなんかは5辺りから
ある意味その言葉を既に体現してる気がする。
0012名前は開発中のものです。
2008/05/24(土) 21:56:16ID:WrI+RE5A「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?
0013名前は開発中のものです。
2008/05/24(土) 23:02:12ID:zxthQanT今出てるのってそんな話か?
俺には世間話に>>10が適当な横槍入れただけに見えるが
0014名前は開発中のものです。
2008/05/24(土) 23:16:51ID:6QB8Oyw/0015名前は開発中のものです。
2008/05/24(土) 23:28:05ID:PtHN405f0016名前は開発中のものです。
2008/05/25(日) 00:49:54ID:9gKbes0q0017名前は開発中のものです。
2008/05/25(日) 10:55:20ID:9DfW5HgHム板のことか?
0018名前は開発中のものです。
2008/05/25(日) 11:05:10ID:93aOxetu0019名前は開発中のものです。
2008/05/27(火) 12:06:43ID: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
0020名前は開発中のものです。
2008/05/28(水) 00:17:53ID:EMOoLtkb0021名前は開発中のものです。
2008/05/28(水) 09:16:17ID:rm2+ecl2サンプルコードもゲームだしわかりやすくていいと思うが
0022名前は開発中のものです。
2008/05/28(水) 10:19:46ID:jKXaFTfv0023名前は開発中のものです。
2008/05/28(水) 12:07:15ID:yrY1wCou0024名前は開発中のものです。
2008/05/28(水) 12:58:54ID:aV/WuK9Yなんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。
0025名前は開発中のものです。
2008/05/28(水) 19:17:39ID:rm2+ecl2そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ!」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い
0026名前は開発中のものです。
2008/06/01(日) 20:32:11ID:CN3GNXI+ゲーム屋からみれば変な設計なん?
0027名前は開発中のものです。
2008/06/01(日) 20:35:37ID:9GWV5N72速度でないゴミになりそうな悪寒
0028名前は開発中のものです。
2008/06/01(日) 22:40:05ID:IjC+ZLNyまぁ使い過ぎが良くないってのには同意だけど
0029名前は開発中のものです。
2008/06/02(月) 00:45:33ID:u3nq1AKuこんなんじゃ、ゲーム屋って無理?
0030名前は開発中のものです。
2008/06/03(火) 13:20:56ID:Up2rlfhTマならどんな屑でもなれるし、無理じゃないよ
個人的には一緒に仕事したくないタイプだな
他社にいても移植とかサンプルとかでそういうコード渡ってきたらゲンナリする…
0031名前は開発中のものです。
2008/06/03(火) 13:37:21ID:60nvGBII利点理解した上で必要ないと言い切る奴は性質の悪い秀才
食わず嫌いで利点なしと判断してごねてるならただの馬鹿
環境によっては使わない方がいい事もあるかもしれんけど
0032名前は開発中のものです。
2008/06/03(火) 14:28:32ID:FP0Va/Ol0033名前は開発中のものです。
2008/06/03(火) 18:34:30ID:R8vkDVlyどうしてもGTAGSがいいの?GTAGSってGNU Tags?Google Tags?
0034名前は開発中のものです。
2008/06/04(水) 03:53:09ID:8a5x1JRq>GTAGSってGNU Tags?Google Tags?
カエレw
0035名前は開発中のものです。
2008/06/07(土) 05:38:48ID:PKYwPYRJデザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。
0036名前は開発中のものです。
2008/06/08(日) 20:08:17ID:1W8n4o1x参考になるサイトでもある?
0037名前は開発中のものです。
2008/06/08(日) 20:17:15ID:WckjqjCh0038名前は開発中のものです。
2008/06/10(火) 10:07:55ID:nTtkz+dw全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル
0039名前は開発中のものです。
2008/06/10(火) 10:18:30ID:XooPHqWtその場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ?
0040名前は開発中のものです。
2008/06/10(火) 11:31:11ID:K9Q1TpUpまず、誰にでも読める企画書とプレイマニュアルを作成する。
俺自身がどんなゲームを作る気なのかわかっていないことが多いから。
0041名前は開発中のものです。
2008/06/10(火) 12:26:21ID:hsBh970Aまあ、最後はありえねーとしてもw
0042名前は開発中のものです。
2008/06/10(火) 19:02:52ID:ZqBN8Kq4どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz
0043名前は開発中のものです。
2008/06/12(木) 08:01:35ID:IMyaUQnNでも一番趣味でやる構築なら手ごろな手法っぽい。
ブリッジとアダプタさえあればドウトデモナルサー的な感じで。
0044名前は開発中のものです。
2008/06/14(土) 10:10:24ID:ITcMwq//モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。
0045名前は開発中のものです。
2008/06/14(土) 14:13:33ID:GhaLcPKx0046名前は開発中のものです。
2008/06/14(土) 15:55:22ID:vUcsb6CI0047名前は開発中のものです。
2008/06/14(土) 21:53:33ID:TLBVclDV0048名前は開発中のものです。
2008/06/23(月) 00:38:10ID:fMSgUVEh0049名前は開発中のものです。
2008/06/23(月) 01:30:28ID:eCdVbunT0050名前は開発中のものです。
2008/06/23(月) 01:34:12ID:pTJzzIh1グローバルとか、デバイス差の吸収とか必要になったとき困らね
0051名前は開発中のものです。
2008/06/23(月) 02:05:44ID:NUHlpJuvそして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との2択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。
0052名前は開発中のものです。
2008/06/23(月) 02:31:28ID:/DBWn/TJそのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。
0053名前は開発中のものです。
2008/06/23(月) 08:22:39ID:mKIom38M0054名前は開発中のものです。
2008/06/23(月) 14:04:29ID:/Ozl3kU4シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど
0055名前は開発中のものです。
2008/06/23(月) 22:16:08ID:T9NriNFy普段はデバイスに直接触りすらしないようにしちゃうのは異端かな?
0056名前は開発中のものです。
2008/06/23(月) 22:34:15ID:X6Q0hHes俺もー
005756
2008/06/23(月) 22:37:13ID:X6Q0hHes0058名前は開発中のものです。
2008/07/02(水) 02:46:33ID:Z7PtKJGp俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。
0059名前は開発中のものです。
2008/07/02(水) 03:01:12ID:US3ampRT俺の鳥頭じゃちょっとイメージしにくい・・・
0060名前は開発中のものです。
2008/07/02(水) 08:11:54ID:1rjp9Xphなんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの?
0061名前は開発中のものです。
2008/07/02(水) 10:15:59ID:25mPqNmlなんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。
0062名前は開発中のものです。
2008/07/02(水) 19:16:17ID:noQk3O5d設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね
0063名前は開発中のものです。
2008/07/02(水) 22:59:17ID:zDJJl2HFRPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。
0064名前は開発中のものです。
2008/07/02(水) 23:04:11ID:surY1LL8そーゆーんじゃないのん?
0065名前は開発中のものです。
2008/07/02(水) 23:06:33ID:25mPqNml0066名前は開発中のものです。
2008/07/02(水) 23:19:07ID:Z+lS9RAUP of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う
0067名前は開発中のものです。
2008/07/02(水) 23:42:43ID:US3ampRTそこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど
0068名前は開発中のものです。
2008/07/02(水) 23:53:44ID:noQk3O5dシーン単一保持だと元シーン内のアニメも止める事になるし(※無論それが前提なら無問題だけど)
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな
0069名前は開発中のものです。
2008/07/02(水) 23:58:28ID:surY1LL8俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。
0070名前は開発中のものです。
2008/07/03(木) 03:42:52ID:Z+nUDepWフィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。
0071名前は開発中のものです。
2008/07/03(木) 12:34:48ID:4VgEaFFXゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。
0072名前は開発中のものです。
2008/07/03(木) 12:38:03ID:e4SGKyy/それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。
0073名前は開発中のものです。
2008/07/03(木) 12:49:08ID:ysSgecWy結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。
0074名前は開発中のものです。
2008/07/03(木) 13:01:27ID:aUHHO03G情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。
0075名前は開発中のものです。
2008/07/03(木) 15:05:04ID:qaYiJWl1守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか
0076名前は開発中のものです。
2008/07/03(木) 18:39:02ID:9NkLv6DUきもい、長い
0077名前は開発中のものです。
2008/07/03(木) 19:12:29ID:aUHHO03G> 守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
> または公開することもできるだろう
もちろん社内で議論はしてるだろう。仕事してるんだから。
それと公開するかどうかは別の話だ。
ここでの話は、企業として技術情報を公開することについてじゃないの?
少なくとも>>72はそういう話でしょう。
それとも>>75は単に多くの日本の開発者を無能扱いしたいだけ?
0078名前は開発中のものです。
2008/07/03(木) 20:24:00ID:odWCpgCc業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。
0079名前は開発中のものです。
2008/07/03(木) 21:55:28ID:DTx5b/+j日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
>外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
>まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下(兵隊)の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね
0080名前は開発中のものです。
2008/07/03(木) 22:23:51ID:DTx5b/+j>あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンww」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお(#^ω^)」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏=3Dキチガイの巣窟。日本語圏=虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない
0081名前は開発中のものです。
2008/07/03(木) 22:25:41ID:4YUvzjZW技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。
0082名前は開発中のものです。
2008/07/03(木) 22:33:05ID:odWCpgCc不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。
0083名前は開発中のものです。
2008/07/03(木) 22:46:20ID:4YUvzjZWGoogleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、80年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ10年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。
0084名前は開発中のものです。
2008/07/03(木) 22:47:22ID:JMOvob5t0085名前は開発中のものです。
2008/07/03(木) 22:50:43ID:odWCpgCc> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。
0086名前は開発中のものです。
2008/07/03(木) 22:55:44ID:odWCpgCcSIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよw
0087名前は開発中のものです。
2008/07/03(木) 23:05:49ID:1g03RBvk0088名前は開発中のものです。
2008/07/04(金) 00:30:18ID:lh91Gh1r0089名前は開発中のものです。
2008/07/04(金) 05:23:01ID:5KkF19eeソフトウェアに携わる人間で米コンプレックスを感じない人は
無能あるいは情報弱者だろう
欧州はそれほどとも思わないけどアメリカリードしすぎ
0090名前は開発中のものです。
2008/07/04(金) 05:32:42ID:fzMGN+kp海外はすごいよ。
開発するにしてもニッチな物になればなるほど日本側で
解説してるのが少ない。
結局は翻訳サイトで翻訳しながら自力で学習してる。
0091名前は開発中のものです。
2008/07/04(金) 05:48:08ID:dN9x2gJA日本人の英会話力の低さは別問題だよもう
0092名前は開発中のものです。
2008/07/04(金) 05:56:42ID:KBN1fM3dこういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ
0093名前は開発中のものです。
2008/07/04(金) 05:57:56ID:KBN1fM3dかぶったスマンコ
0094名前は開発中のものです。
2008/07/04(金) 06:11:54ID:KBN1fM3dネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ
0095名前は開発中のものです。
2008/07/04(金) 06:28:19ID:KBN1fM3d既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数の変態テクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる
0096名前は開発中のものです。
2008/07/04(金) 06:32:14ID:ulIK/zsc日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか?知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。
0097名前は開発中のものです。
2008/07/04(金) 06:58:00ID:KBN1fM3d0098名前は開発中のものです。
2008/07/04(金) 08:23:31ID:BChTVd/d>日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
>海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
>ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。
0099名前は開発中のものです。
2008/07/04(金) 08:49:34ID:BChTVd/d以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○ 絵(とくに3D)がきれい。
○ 音楽も一般受けする質の高いものが標準。
○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。
日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い(よくできたものもあるが)。
グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
0100名前は開発中のものです。
2008/07/04(金) 10:11:43ID:pYjEAjehRDBですか?それともタダのファイル?
0101名前は開発中のものです。
2008/07/04(金) 12:41:59ID:tMJHCBTqデータはファイルが多い。ゲームデータ制作ツールの仕様にもよるけど、バイナリファイルの場合が多い。
C構造体のバイナリダンプは実装が楽だからね。
PCゲーには、ユーザがテキストファイルを弄ってデータや設定を変えられるものもある。
0102名前は開発中のものです。
2008/07/04(金) 13:10:11ID:04Qw9LMa0103名前は開発中のものです。
2008/07/04(金) 15:33:28ID:eL1SAVRC>>100
某タイトルはSQLite使ってるな
0104名前は開発中のものです。
2008/07/04(金) 20:15:06ID:HsoNh4J4> 論文の質・量で言うとMicrosoft Researchのほうがすごくない?
同意。世間じゃGoogleを持て囃すのが流行ってるけど、むしろ
コンピュータサイエンスはMSRのほうがすごい研究者を集めてる。
0105名前は開発中のものです。
2008/07/05(土) 11:31:29ID:rip3o1Gr研究者の層の厚さだと IBM 強いよなぁ。
Google は R&D でも R より D 寄り。
0106名前は開発中のものです。
2008/07/05(土) 11:38:06ID:rip3o1Grまだ、主流は独自フォーマットのバイナリだと思うな。
CSV か XML っぽいフォーマットでデータファイル作っておいて、コンバータで
バイナリに変換して組み込み。
0107名前は開発中のものです。
2008/07/05(土) 11:38:38ID:Def2so2E0108名前は開発中のものです。
2008/07/05(土) 11:41:27ID:qX1NKMBA> ○ 絵(とくに3D)がきれい。
> ○ 音楽も一般受けする質の高いものが標準。
> ○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまnれている。
ちょwwわかってかいてんのかよww
全部、投入できるリソースの違いで解決できるじゃねーかw
0109名前は開発中のものです。
2008/07/05(土) 11:44:02ID:qX1NKMBA絵がきれー、とか音楽すげーとかってなかなかないよ
それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。
たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり(日本かとおもうけど、海外の話だよ)
0110名前は開発中のものです。
2008/07/05(土) 11:44:46ID:qX1NKMBA0111名前は開発中のものです。
2008/07/05(土) 13:29:28ID:E9y2cnx1そもそも一国と世界を比べることに意味があるのかな。
言語障壁はローカルのコミュニティが栄えない理由にならないよね。
0112名前は開発中のものです。
2008/07/05(土) 20:57:12ID:UjEcMe9W>>109
>>99のリンク先のコンテンツを見た上で、のたまっているのか?
優れたリソースの利用可能性も、市場発展度合いの目安。
0113名前は開発中のものです。
2008/07/05(土) 21:01:08ID:rip3o1Gr0114名前は開発中のものです。
2008/07/05(土) 21:23:48ID:hYTfj9Xn0115名前は開発中のものです。
2008/07/06(日) 00:07:36ID:Gwo/Ylg2>>99
繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。
IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは
なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる
>英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける
>ttp://www.gametunnel.com/
ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか?してないだろ
特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる
(下半身産業が絡んで不公平になるので全年齢のみで比較してもいい)
>日本のフリーとかシェアは(中略)
>グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに
「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい?毎日好きでもないものを延々作らされてる
腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために
真剣に取り組んでるよw素人に八つ当たりする前に自分の胸に手を当てて考えろっての。
あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。
他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが
ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない
弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい
0116名前は開発中のものです。
2008/07/06(日) 00:20:54ID:Gwo/Ylg2アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。
趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。
エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。
世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。
あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい
0117名前は開発中のものです。
2008/07/06(日) 00:32:11ID:ADZbZeYtい気がするね。
昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ
てるって何かの本に書いてた気がしないでもない。
SEやらPGやってる人なら分かると思うけど「なんで?どういうこと?」っていう
のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア
には向かないと思う。
まぁ外人云々じゃなくて正確か??
0118名前は開発中のものです。
2008/07/06(日) 00:33:49ID:Gwo/Ylg2この点だけは外国すげぇ日本だめ論を展開するアジテーター共の意見に一理ある。
お国柄のせいか虹派が多数派の我が国ではアマチュアプログラマに要求される
技術水準はそれほど高くはない。それはそれでいいのだが、その技術ガラパゴスの中で
タスクシステム知ってる俺tuee状態とかになっては格好が悪い。俺tueeする時はもっと
見識を広めたほうが良い
0119名前は開発中のものです。
2008/07/06(日) 00:34:25ID:Gwo/Ylg2かぶったスマン
0120名前は開発中のものです。
2008/07/06(日) 00:34:55ID:7QhD5OiR0121名前は開発中のものです。
2008/07/06(日) 00:42:02ID:Gwo/Ylg2現役開発者が質問に答えるスレ
http://pc11.2ch.net/test/read.cgi/gamedev/1214321147/l50
0122名前は開発中のものです。
2008/07/06(日) 00:44:51ID:VtZ5ywY1>腹いせに素人に因縁付けてるようで感心しないな。
感じやすいんだな。
一つ俺が言いたいのはさ、スキルがあるんだったら、
小規模ながらもグローバルな金儲け(変な言葉だ)に挑戦すること考えた方が、
面白えんじゃねえのってことだよ。
自身の嗜好に自信がないって?
じゃあ、そいつは一体何をやっているんだ。
0123名前は開発中のものです。
2008/07/06(日) 00:48:46ID:mek7cAwO0124名前は開発中のものです。
2008/07/06(日) 01:43:19ID:D1fZ4Z3GPG以外がこのスレに居るのかと問い詰める必要があるな
0125名前は開発中のものです。
2008/07/06(日) 07:26:44ID:XCulGsMF小さな会社でケータイゲー作ってる業界人です。底辺です。分かってます
俺も職場の仲間はみんなゲーム専門学校卒です。
英語とか読めないしGPGの日本語版も難しすぎてわからないので
や○う○おさんの本とかCマガのタスク記事が職場のバイブルです。
某スレでタスクシステムが馬鹿にされて自棄になってて
俺の職場のレベルが低いのはきっと日本の閉鎖性のせいだと
考えるようになってました。
だってPS3とか箱○のゲーム作ってるクライアント(大手です)は
自分たちのノウハウを俺ら底辺には絶対教えてくれないし。。。
発注したケータイゲーをおとなしく作ってろって感じの扱いです。。。
ぜんぜん頭よくなれそうにない知育ゲーとか糞つまんねー
クイズものばっかり作らされて気が狂いそうです。。。
0126名前は開発中のものです。
2008/07/06(日) 07:43:01ID:XCulGsMFベーマガがどんなものか実は知らないのですが日本の
アマゲーコミュニティがないから悪いって言ってたので
我が意を射たりって感じでした。
土日スレで投稿してましたがいつも荒らされてました。
PCゲーム板のフリゲ厨とか氏ねと思ってました
俺は今もDirect3Dとかわけわかんないです。そういうのを
教えてくれるベーマガみたいなものに出会えなかったから
ファミ通の特集記事のゲーム専門学校すごいと思って
高校の先生の反対を押し切ってゲーム専門学校に行きました。
でも専門学校の講師も3D苦手でした。
おまえらには3D無理だから2Dで卒業制作作れって言われたので
言う通りにしました。今思えば先生が分からないもの作られると
質問されても答えられないから嫌だったんだと思います。
ゲーム専門学校に行ったことをすごく後悔してます。
ファミ通氏ねと思いました。きっとベーマガがあれば俺の人生
違ってたかもと思いました。やっぱおまえらが悪い
0127名前は開発中のものです。
2008/07/06(日) 07:59:00ID:XCulGsMF消えます
0128名前は開発中のものです。
2008/07/06(日) 08:43:38ID:S3/2UtrA明らかに躁鬱の傾向が見て取れる。
過度のストレスで脳に器質的な損傷が出来てるかもしれん。
0129名前は開発中のものです。
2008/07/06(日) 09:01:33ID:VtZ5ywY1何も語れない馬鹿よりはマシ。
0130名前は開発中のものです。
2008/07/06(日) 09:28:24ID:I4JuM7130131名前は開発中のものです。
2008/07/06(日) 10:03:51ID:4WjvpweZさすがにそれはねーよw
スレ違いでも知識をひけらかすほうが賢いと?
まあ、あまり過疎ってもらってもつまらんのだが・・・
0132名前は開発中のものです。
2008/07/06(日) 13:03:17ID:cXpJQpiz0133名前は開発中のものです。
2008/07/06(日) 15:04:16ID:ZiAdcqL1ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて
0134名前は開発中のものです。
2008/07/06(日) 16:19:57ID:le8Gr2pO0135名前は開発中のものです。
2008/07/06(日) 16:49:47ID:NhLrwJLQ日本の企業は総じて、コミュニケーション能力だのなんだの
わけのわからない能力やノウハウを好んでそれを要求するくせに
それらを他人に教えるようなことはしないからな、ヒントすらも
異常なほど排他的だ
数年前に某大作RPGの下請けの社長様が
「3Dできる奴なんて腐るほどいる死ね、コミュニケーション能力のない奴は死ね」(意訳)
って新聞記事に載せてたの思い出した
笑える、うひゃ
0136名前は開発中のものです。
2008/07/06(日) 17:01:01ID:a3zGOuXrあーあ
0137名前は開発中のものです。
2008/07/06(日) 17:06:30ID:NhLrwJLQレイヤスーパータイプは
class Devicer { static Device device; }
で、スーパークラスとしてDevicerを使うことだ覚えとけ
Application Controllerは
class AP {
View GetView(入力と状態値);
Command GetCommand(入力と状態値);
}
引数に入力情報や状態を判断する値を入力すると
それに適したViewやModelに対するCommandを返すものだ
覚えておけ、クソども
0138名前は開発中のものです。
2008/07/06(日) 17:44:48ID:bleemPMj0139名前は開発中のものです。
2008/07/06(日) 22:29:37ID:mQf6Jrcq良いこというなぁ。
禿同。
社長に。
0140名前は開発中のものです。
2008/07/06(日) 22:41:15ID:NhLrwJLQジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる
やるんだったら他の部分に影響を及ぼさない程度にしておけ
無意味に分断しすぎて複雑にするな
0141名前は開発中のものです。
2008/07/06(日) 23:15:17ID:bOQhFRQWめんどくさいのは、シーン遷移よりキャラクターの状態遷移だよな。仕様変更が
わりと発生しがちな部分だし。
0142名前は開発中のものです。
2008/07/06(日) 23:34:33ID:NhLrwJLQ同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな
0143名前は開発中のものです。
2008/07/06(日) 23:47:58ID:bleemPMj0144名前は開発中のものです。
2008/07/07(月) 00:57:38ID:FUQ1BpEu浅学な俺にコレについて詳しく
0145名前は開発中のものです。
2008/07/07(月) 04:37:03ID:ohkg3t4w以前けっこう調べた俺がコレについて詳しく
コルーチン
並列実行をさせない(できない)スレッドのこと。外国人はコーディングの際 coro と略すこと多し。
メリットは、排他処理が不要、ネイティブスレッドに比べてコンテキスト切り替えが軽い(もちろん実装次第だが)。
デメリットは、切り替えタイミングをプログラマが指示する必要がある、CPUがデュアルコアでも恩恵が受けられない。
最近ゲーム関係でよく聞くようになったが、アルゴリズム的にはすんごく昔のクヌース本にも載っているらしい。
マイクロスレッド、協調的マルチスレッド、ファイバー(Windowsのみ)、などの言い方があるが、
ゲーム業界ではコルーチンが一般的かな?
ネイティブスレッドではないので擬似的なスレッドと言えるが、「擬似スレッド」という呼び方は
よく混乱を招くようなのでお勧めしない(後述するように、スレッドを擬似的に再現する手法は他にもある)。
Cで実装する場合は、たいてい手動でスタックポインタを切り替えることで実現する。
主な実装:
アセンブリで実装:作成難度高、コンパイラ依存、移植性なし、使い手にもスキルが必要(スタック溢れ対策など)
大域ジャンプで実装:作成難度中、コンパイラ依存、やや制限がある
スクリプトで実装:スクリプトのVM(例えばLuaやSquirrel)に任せる。使うのは簡単で制限も少ない
擬似コルーチン
コルーチンっぽいことを擬似的にやること(を、>>141は言っているのだと思われる)。
主な実装:
マクロで実装:作成難度低、移植性高い、制限多い、読み手には超分かりずらい
感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。
以下は直接関係ないので、混乱するようなら読み飛ばして。
・昔のMacOSやWindowsで言うところの「プリエンプティブでない」マルチタスクの仕組みは、コルーチンの親戚。
・RubyやPythonのスレッドも、一般的な実装ではネイティブスレッドではなく擬似的なスレッドらしいが、
明示的にコンテキスト切り替えを行うわけではないのでコルーチンとは異なる。
Javaではこのような擬似的に実装したスレッドをネイティブスレッドに対してグリーンスレッドと呼ぶ。
0146名前は開発中のものです。
2008/07/07(月) 07:19:25ID:1RaeXbIYif (frame <= 100)
GoToLeft();
else if (frame <= 200)
GoToRight();
:
以下延々とつづく
コルーチンを使った場合
for (i = 0; i < 100; i++)
GoToLeft(); yield;
for (i = 0; i < 100; i++)
GoToRight(); yield;
:
0147名前は開発中のものです。
2008/07/07(月) 07:20:47ID:1RaeXbIYfor (i = 0; i < 100; i++) {
GoToLeft(); yield;
}
for (i = 0; i < 100; i++) {
GoToRight(); yield;
}
:
0148名前は開発中のものです。
2008/07/07(月) 07:24:44ID:1RaeXbIY0149名前は開発中のものです。
2008/07/07(月) 08:00:36ID:FUQ1BpEuそれなら一応分かるような気がしないでもない
でもC++じゃあ無理だよね・・・
0150名前は開発中のものです。
2008/07/07(月) 08:00:37ID:0ql4peFo0151名前は開発中のものです。
2008/07/07(月) 09:17:09ID:1RaeXbIYネイティブに落とされる言語だと実現するにはコンパイラ依存になるんじゃないのかなあ?
スタックいじるし。
>>150
Windows用語ではそうかと。
てか、要点は>>145に書いてあるなw
うまいまとめだ
0152名前は開発中のものです。
2008/07/07(月) 10:04:53ID:BeipJAsvsetjmp()でコンテキストを保存したあと、保存したコンテキストの
スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。
C++だけで実装可能だぞっと。
0153名前は開発中のものです。
2008/07/07(月) 13:31:17ID:yE1V62Scスレッド(糸)より細いものだからファイバ(繊維)
あとJavaScriptにも1.7から導入されてるぜい
0154名前は開発中のものです。
2008/07/07(月) 22:11:23ID:oT4ePMXj0155名前は開発中のものです。
2008/07/07(月) 22:26:27ID:yE1V62Sc0156名前は開発中のものです。
2008/07/07(月) 22:30:56ID:nV3j1Oo/0157名前は開発中のものです。
2008/07/07(月) 23:47:06ID:ZC8HSbxq0158名前は開発中のものです。
2008/07/08(火) 00:00:56ID:2Ffcfnsn0159名前は開発中のものです。
2008/07/08(火) 01:20:29ID:DPfKtgJc常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。
また一方で、オブジェクト発生イベントのリストを持っていて、
順次、メインループにオブジェクトが登録されていく。
この「オブジェクト発生イベントのリスト」はシーンに相当していて、
シーンを切替えたければ、今登録されているオブジェクトを破棄して、
イベントのリストを差し替えるだけでいい。
while (1) {
for i=0...
{
オブジェクト[i]->行動();
オブジェクト[i]->描画();
オブジェクト[i]->当たり判定();
}
イベント発生()
}
0160名前は開発中のものです。
2008/07/08(火) 17:13:03ID:8FRUZW5mPACに似てるが違う、オブジェクトの追加に強そうだが
そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感
ドメインロジックのテストを行うときにビューが関わってくる
逆にビューのテストを行うときにドメインロジックが関わってくるため
テストに多大な労力がかかる事が予想される
常にプログラム全体をテストしなければならないため、試行錯誤すると死ねる
render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き
2Dにしても描画に関する処理が単純でなければうまく動かないだろう
規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め
または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め
私はお勧めしない、追加のメリットが多大である場合は考慮に値するが
ゲームには不向きだと思う、特に3Dの場合は
俺は怖くて使えない
0161名前は開発中のものです。
2008/07/08(火) 17:19:39ID:8FRUZW5m追加
リソースの追加が障害にならなければロジックのテストは問題ない場合もある
やるんだったらそんな半端な構造ではなく
関連まで含めて、PACアーキテクチャ使った方がよくないか?
0162名前は開発中のものです。
2008/07/08(火) 22:56:21ID:8FRUZW5m今持ってる手で四つ
1.擬似コルーチン
2.スレッド
3.スクリプトで隠蔽したスレッド
4.通常の状態変数による管理(State含む)
設計が明確でない初期のもの、プロトタイプ
又は小規模な場合の初期のとりあえず書いておくコードに向いているのは
擬似コルーチン又は状態変数だろう
まだ設計方針が明確に決まっていない場合や試行錯誤しなければならない状態で
スレッドやスクリプトの導入を決めるのは早すぎる、リスクが大きい
ある程度、方針が固まってから適切なものを選択するのがいいだろう
状態変数での管理が大手を振っているのも
初期コストが低いという部分が大きい
このため、状態変数やState以外の選択肢は簡単には普及しないだろう
ただし、スレッドの積極的採用が処理速度向上に繋がるのならその限りではない
0163名前は開発中のものです。
2008/07/08(火) 23:04:46ID:gy2iNnCl0164名前は開発中のものです。
2008/07/08(火) 23:41:41ID:8FRUZW5m擬似じゃなくていいのか、訂正
1.コルーチン、又は擬似のそれ
言語仕様に含まれてるときはそのままコルーチンとして呼び出し
c/c++の場合は以下のものが使える、又は自分で作る
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
それ以外なら
ソースコードを変換するプログラムでも作る
gotoやthrowやswitchやラベルなんかが含まれない言語では無理、又は面倒くさい
0165名前は開発中のものです。
2008/07/08(火) 23:46:18ID:iq4s5004ttp://www.xmailserver.org/libpcl.html
0166名前は開発中のものです。
2008/07/09(水) 01:10:17ID:vZNCPgy9すんごい便利そうなんだけどなぁ・・・
0167名前は開発中のものです。
2008/07/09(水) 07:23:21ID:eQNI5n3rよっぽど安全で楽だと思うけどな
0168名前は開発中のものです。
2008/07/09(水) 09:40:38ID:nYED4jrhスレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。
>小規模な状態遷移の実装
>>146のような、行動予約の状態遷移を前提にしているのかな。
だとしたら、もっぱら自分は、C++で、
>4.通常の状態変数による管理(State含む)
と動作制御用独自スクリプトだな。
基本は、ゲーム開発で言うところのタスクシステムで処理。
各オブジェクトは、単一クラス中に、状態ごとに処理関数(メンバ関数)を用意する。
フレーム毎に、その時点の状態に該当する処理関数を、1回ずつ呼び出す。
その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。
状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。
動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。
表現くどいけど、悪しからず。
0169名前は開発中のものです。
2008/07/09(水) 17:57:35ID:7MZGZOjkタスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50
おまえらタスクシステム信者がクソでカスでゴミクズな理由は
自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ
または、それを考えようとしないところだ
ただ使えばいいと思い込んで、それで完結している
考えることを放棄したおまえらに設計能力を向上する機会はない
戦略のない戦術はただのテロだ
0170名前は開発中のものです。
2008/07/09(水) 18:38:12ID:vZNCPgy9なんでそんな暴言が吐けるの
0171名前は開発中のものです。
2008/07/09(水) 18:47:18ID:vvjjLorCなんかそういうgdgdな経緯でもあったんだろうな
0172名前は開発中のものです。
2008/07/09(水) 18:55:55ID:nYED4jrhhttp://pc11.2ch.net/test/read.cgi/gamedev/1215129226/4n
0173名前は開発中のものです。
2008/07/09(水) 18:56:55ID:iC3IHDcBゲーム業界の造語みたいなものだからな。
OS屋に言わせると「なにそれ?プ」というものらしい。
まあ一定60FPSとか30FPSといったフレームで常に動いてて
物の動きとか制御してるのがOSがタスクを処理してるのに見えるから
そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人
が言い始めたのそもそもらしい
0174名前は開発中のものです。
2008/07/09(水) 19:21:37ID:eQNI5n3rしょうがないからその辺の単語は誤魔化して話進めてくれ
いつまで経っても話進まねーからな
0175名前は開発中のものです。
2008/07/09(水) 19:22:14ID:anjhk7B80176名前は開発中のものです。
2008/07/09(水) 21:10:22ID:7MZGZOjk言ってる奴が、メリットもデメリットも把握していないんだから
ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない
宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
誰かこれを理解してみろクソが
0177名前は開発中のものです。
2008/07/09(水) 21:12:45ID:iC3IHDcBまあ俺的にはそんな何とかシステム(自称)はどうでもいいよ。
市販のゲームでも売り出す際は自称xxxシステム採用とかいう
元からそういうの好きな業界だし。
0178名前は開発中のものです。
2008/07/09(水) 21:30:52ID:4OXXlyYN少し落ち着けよw
>宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
お前はこういう事を言うやつに馬鹿だのアホだの必死に噛み付くのか?
俺はスルーするけどな
0179名前は開発中のものです。
2008/07/09(水) 22:16:56ID:EYwlC03l端からはただのバカにしか見えてないけどね。
0180名前は開発中のものです。
2008/07/09(水) 22:19:25ID:SF8ehHxO>OSがタスクを処理してるの
ってどんな実装してるの?
0181名前は開発中のものです。
2008/07/09(水) 22:22:48ID:uQp1o0/nリアルタイムOSとか便利なもんがなかった時代の組み込みシステム開発に
起源があるような気がする。
まあ、C++で真っ当にオブジェクト指向やってれば、こんな古臭いもんを
有難がる必要はないと思う。
0182名前は開発中のものです。
2008/07/09(水) 22:23:19ID:iC3IHDcBそりゃ・・・その辺はがんばって勉強して
キューだとかスレッドだとかタスクだとか
タイムスライスだとか
まあ同時に複数のものが動いてる(ように処理してる)風に出来るものかな
乱暴な言い方だけど。
0183名前は開発中のものです。
2008/07/09(水) 22:24:41ID:7MZGZOjk君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった
有益だったぜw
また暇なときに挑発に乗ってやる
この完璧な捨て台詞を覚えておけよ
0184名前は開発中のものです。
2008/07/09(水) 22:48:57ID:XmNOce7Z巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。
感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。
会社でタスクシステムで組みたいと同僚が言ったとして、
烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。
ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。
0185名前は開発中のものです。
2008/07/09(水) 23:14:23ID:nYED4jrhなんというか、要するに、
ただの孤独なレス乞食。
もしくはタスク・スレへの誘導係。
マンネリだな。
効率的な挑発方法については、再考した方がいい。
0186名前は開発中のものです。
2008/07/09(水) 23:17:00ID:md3RJLJr0187名前は開発中のものです。
2008/07/09(水) 23:26:06ID:30d6bQh7以前より良い設計ができない上に、収集がつかなくなった。
svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。
0188名前は開発中のものです。
2008/07/09(水) 23:50:08ID:XmNOce7Z0189名前は開発中のものです。
2008/07/10(木) 00:33:17ID:rFEYqRAa神は自らタスクる者をタスク。
0190名前は開発中のものです。
2008/07/10(木) 00:51:19ID:A+tXgG+Vタスクスレの話題を続けるのはよくなさそうなので情報だけ
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/456
OSだからできることを思いっきり使ってるんで
管理手法以外はあまり参考にならんよ。
OS自体に興味があるならOS板にいくといいよ
0191名前は開発中のものです。
2008/07/10(木) 00:54:31ID:MjVgJsdw0192名前は開発中のものです。
2008/07/10(木) 05:56:13ID:nnoBQqoIttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/
0193名前は開発中のものです。
2008/07/10(木) 07:41:02ID:99kxezye【小さく審議中】
,、_,、 ,、_,、
,、_('・ω)(ω・`)、_,、
('・ω)u゚ ゚uu(ω・`)
゙uu゚( '・) (・` )uu'
゚uu゚ ゚uJ
0194名前は開発中のものです。
2008/07/13(日) 00:51:10ID:eBw+YtUVつくりかけのゲームってどうやって動かしてテストするんですか?
0195名前は開発中のものです。
2008/07/13(日) 01:06:26ID:47vlxomfちまちまと小規模な物を作って、それを拡張していく形になります。
例
第一段階: ウィンドウを表示する
第二段階: キャラクターを一つ表示する
第三段階: キャラクターを動かしてみる
第四段階: 飽きる
0196名前は開発中のものです。
2008/07/13(日) 01:25:52ID:eBw+YtUVなんで途中までカタコトなんですか?
そういう個人規模でなくて、複数のPGで役割分担してる場合はどうするんでしょう?
0197名前は開発中のものです。
2008/07/13(日) 01:29:50ID:R4nPLnnD0198名前は開発中のものです。
2008/07/13(日) 02:53:02ID:lqrHuCir0199名前は開発中のものです。
2008/07/13(日) 03:04:31ID:uUrGa3AK他にやりようないな
0200名前は開発中のものです。
2008/07/13(日) 03:23:29ID:eBw+YtUV他人がつくったクラスがないと動かない場合はテストできないのでしょうか?
0201名前は開発中のものです。
2008/07/13(日) 03:29:10ID:uUrGa3AKいや出しゃばった 俺はweb系なので実情は判らん
まあロジック側は業種問わずどうグズったところで、
「何々渡したときに何々返す関数作ってー!」しか分業方法ないと思うけど
0202名前は開発中のものです。
2008/07/13(日) 03:29:54ID:edzJ8FGN目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす=エラーが出ないで動く なので
0203名前は開発中のものです。
2008/07/13(日) 03:32:16ID:edzJ8FGNwikiのチュートリアル→段階的学習でもやってみては
0204名前は開発中のものです。
2008/07/13(日) 04:56:24ID:tw1/nxGsそのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな?
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。
0205名前は開発中のものです。
2008/07/13(日) 09:43:53ID:47vlxomfもし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。
だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。
早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、
0206名前は開発中のものです。
2008/07/13(日) 09:51:14ID:timDAMYM>>200は外注や営業職の言い訳で多発するんだよね。
あんなのはまともに相手するのも無駄。
「スタブ要るじゃん。 スタブ供給してくれないとコストにあわないんだよね」系で、素で言ってのけやがる。
超ウケルんですけど。
こういうのに仕事を与えないようにするのが業界の為だろ。
政治的な理由により取引継続となったら、「スタブの作り方を指導しますから、
その講習料として、スタブ作成代を相殺ですね」ぐらいしか案が無い。
・こちらはスタブなんて、要求仕様の一部で料金内。jk
・カス会社は、どちらも追加料金や有料。
・解決してなくても解決!!!!
0207名前は開発中のものです。
2008/07/13(日) 10:22:09ID:L3kGAfa0作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。
RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。
0208名前は開発中のものです。
2008/07/13(日) 10:49:52ID:UM30DsAY全員が全体を上から下まできっちり把握した上で、
常に連絡を密にし、お互いが何をやってるのか理解しつつ、
各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。
0209名前は開発中のものです。
2008/07/13(日) 11:17:51ID:L3kGAfa0全員が全体を把握できるのは、せいぜい3人ぐらいまでだな。その先は
ヒエラルキー作って、パート毎に管理業務やる人間を立てないと無理。
0210名前は開発中のものです。
2008/07/13(日) 13:47:03ID:DAEU2DrCほとんどないしな。大半はマが1人、多くて2人で>>408方式
ツーといえばカーの黄金タッグ。あ、ああじゃいる
0211名前は開発中のものです。
2008/07/13(日) 13:48:37ID:DAEU2DrC0212194
2008/07/13(日) 14:07:22ID:eBw+YtUV>>208
それ実際には各人に漏れやズレが出て手戻りが出るんで、大規模プロジェクトでは無理では
0213名前は開発中のものです。
2008/07/13(日) 14:19:00ID:sqmPpN2O仕事(勿論?非ゲーム)でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったw
個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどw
0214名前は開発中のものです。
2008/07/13(日) 14:24:18ID:RINNRPdbサークルのようなものなのか会社なのかもわからないから議論が発散してる
フリーソフト作るのに主力のプログラマ2〜3人と、バグ修正や機能強化の
パッチくれる人10人くらいでなら、MLとIRC使って>>208のような方針でやれてた
最初のバージョンはリリース済みで方向性が決まってたのが大きそうだ
>>212
作業するタスクを割り振りはちゃんとやって、頻繁なイテレーションと
継続的インテグレーションやるっつうのは何人くらいで破綻する?
0215名前は開発中のものです。
2008/07/13(日) 15:08:38ID:eBw+YtUV1チーム10人以下で、各チームにリーダー2人ぐらいで、200人ぐらいのプロジェクトも回ってました。
素人なのでこれくらいしかわかりません。
0216名前は開発中のものです。
2008/07/13(日) 15:15:30ID:uaqPI4FPプログラマの数は?
0217名前は開発中のものです。
2008/07/13(日) 15:23:34ID:L3kGAfa0まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない(DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。
基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。
0218名前は開発中のものです。
2008/07/13(日) 17:47:09ID:eBw+YtUV150人はプログラマでした
0219名前は開発中のものです。
2008/07/13(日) 18:56:00ID:UM30DsAY>>218
なんの素人なんだw
ゲームでプログラマ150人規模って洋げーでも多分ないのでは。予算的に。
マジレスしますと、
小さい規模ならメインプログラマがほとんど一人で下位システムを作っちゃうし、
大きい規模なら別の部署が作るから、
「作りかけの状態でどうやってテスト・・・」という事態があんまり無いでつ
0220名前は開発中のものです。
2008/07/13(日) 21:19:15ID:Q/hESmShゲームのスタッフロールにマが150人も並んでたら壮観だな
ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー
0221名前は開発中のものです。
2008/07/13(日) 21:20:02ID:6QYOrVUt0222名前は開発中のものです。
2008/07/13(日) 22:39:48ID:3VGnVE920223218
2008/07/13(日) 23:00:22ID:eBw+YtUV詳細は言えませんが。
ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。
0224名前は開発中のものです。
2008/07/13(日) 23:23:02ID:UM30DsAY単体テスト→結合テスト→受け入れテスト、みたいな流れは無い
昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません
なので大部分がデバッグチーム頼みです
0225名前は開発中のものです。
2008/07/14(月) 00:00:22ID:yOzfOKcB>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う
0226名前は開発中のものです。
2008/07/14(月) 00:02:24ID:IEzc7ZIHネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ
0227名前は開発中のものです。
2008/07/14(月) 00:10:58ID:cIaZ6JxY逆に(自分含めて)しっかり単体テストできるなら、複数PG開発も悪くないと思う。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁w
テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな!
0228名前は開発中のものです。
2008/07/14(月) 12:30:06ID:Hnt5WQTkPGだけで1500人だそうです
0229名前は開発中のものです。
2008/07/14(月) 15:33:56ID:xdO9+1xM乗っかってるリソースの量がとんでもないだけで。
実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム(シーン別)、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の2乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。
あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。
0230名前は開発中のものです。
2008/07/14(月) 15:36:32ID:Hy149M4+勘定系だってそれほど変わらんよ。
0231名前は開発中のものです。
2008/07/14(月) 15:40:51ID:0Th48wDt0232名前は開発中のものです。
2008/07/14(月) 15:47:11ID:wxUymIt70233名前は開発中のものです。
2008/07/14(月) 16:22:48ID:Hnt5WQTk0234名前は開発中のものです。
2008/07/15(火) 13:15:33ID:IiJYDS4l古典的なドラクエ初期のように2Dオンリー
チョンゲーに代表される3D使ってるクリックゲー
0235名前は開発中のものです。
2008/07/15(火) 13:29:25ID:Hl1v93zY(発売時は中学生?)
http://www.ne.jp/asahi/shiba/mic/nori/xevi_tiny1/index.html
0236名前は開発中のものです。
2008/07/16(水) 17:02:22ID:WbuXgq6y勘定系は、人数は増えるけど PM しっかりしてればカオスにはならんよな。
金回りの話なのでミスが許されず、テスト工数がやったら膨らむから、
プロジェクト管理大変だけど。
0237名前は開発中のものです。
2008/07/16(水) 17:02:59ID:WbuXgq6yメモリ管理
0238名前は開発中のものです。
2008/07/17(木) 20:17:04ID:uAQ9zE97要素の洗い出し
0239名前は開発中のものです。
2008/07/20(日) 02:44:36ID:gpI6Slf50240名前は開発中のものです。
2008/07/20(日) 02:56:31ID:L2XNyVag移植モノで、しかも元のプログラマが辞めて連絡取れないという条件で
一度やったことがある。二度とやりたくない。
0241名前は開発中のものです。
2008/07/20(日) 03:05:04ID:x+htBSIeアーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。
0242名前は開発中のものです。
2008/07/20(日) 03:08:22ID:ZbM+kRVzすみません… それ、たぶんウチだ orz
0243名前は開発中のものです。
2008/07/20(日) 03:39:46ID:18o8S9ZjMAMEでも進呈したほうがいいな
0244名前は開発中のものです。
2008/07/20(日) 15:36:02ID:gpI6Slf50245名前は開発中のものです。
2008/07/20(日) 17:18:51ID:g88tpUo20246名前は開発中のものです。
2008/07/20(日) 17:43:16ID:1Zabkxz6どうやれば良いか分からないから、手探りで書いてる(´・ω・`)
0247名前は開発中のものです。
2008/07/20(日) 22:53:25ID:zgBZw03q0248名前は開発中のものです。
2008/07/20(日) 23:02:17ID:Tcsf7iZJ各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。
0249名前は開発中のものです。
2008/07/20(日) 23:02:30ID:USb+9tXOシングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど?
0250名前は開発中のものです。
2008/07/21(月) 01:05:54ID:9zclfNbN0251名前は開発中のものです。
2008/07/21(月) 14:17:23ID:Y7Mzeak+出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn
0252名前は開発中のものです。
2008/07/21(月) 18:53:57ID:9zclfNbN0253名前は開発中のものです。
2008/07/21(月) 18:54:50ID:NGr1sFSW0254名前は開発中のものです。
2008/07/21(月) 23:51:13ID:yo6BY71C0255名前は開発中のものです。
2008/07/22(火) 00:00:52ID:grvq6f3AWii 普通
PS3 言わせるなw
という感じか?
0256名前は開発中のものです。
2008/07/22(火) 00:03:34ID:9zclfNbN詳しく
0257名前は開発中のものです。
2008/07/22(火) 00:08:34ID:zCVKhHD70258名前は開発中のものです。
2008/07/22(火) 00:21:20ID:inlA4ozd0259名前は開発中のものです。
2008/07/22(火) 00:35:03ID:88jYUtHh0260名前は開発中のものです。
2008/07/22(火) 02:21:06ID:TRIzaodv実際どんなもんなんだろ
0261名前は開発中のものです。
2008/07/22(火) 02:44:01ID:kfP9Fty30262名前は開発中のものです。
2008/07/22(火) 02:45:19ID:zCVKhHD70263名前は開発中のものです。
2008/07/22(火) 16:12:48ID:k5fUsZQo0264名前は開発中のものです。
2008/07/22(火) 18:29:14ID:c7QeI/ED0265名前は開発中のものです。
2008/07/22(火) 18:36:04ID:Jekk8SUvあ、Dreamcastという例外があるか
0266名前は開発中のものです。
2008/07/22(火) 20:52:26ID:6od3yLDuDirectXそのものを使ってるかどうかは知らないが。
0267名前は開発中のものです。
2008/07/25(金) 15:29:12ID:9vpYBrtF0268名前は開発中のものです。
2008/07/25(金) 20:06:41ID:66T6bhjF板違い
プログラマー@2ch掲示板
http://pc11.2ch.net/prog/
0269名前は開発中のものです。
2008/07/26(土) 01:19:05ID:+2uolo1R0270名前は開発中のものです。
2008/07/26(土) 02:28:02ID:Esaqa0cW0271名前は開発中のものです。
2008/07/28(月) 18:13:52ID:9GhNVVJ3後者はなんだ?状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ
0272名前は開発中のものです。
2008/07/29(火) 14:37:45ID:kHD6g876なるほど。フラグの状態で、出るコマンドを制御すればいいのか。
サンクス
0273名前は開発中のものです。
2008/07/31(木) 18:14:30ID:ucHp1Nqpメニューオブジェクトを生成してどうこうみたいな。
0274名前は開発中のものです。
2008/07/31(木) 21:20:41ID:Gc2qBZ+Rクラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね?
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。
0275名前は開発中のものです。
2008/07/31(木) 21:26:22ID:NXR7vyyv0276名前は開発中のものです。
2008/07/31(木) 21:38:09ID:A+bu5iPxだいたい同じインターフェースを実装してる。
0277名前は開発中のものです。
2008/08/01(金) 00:01:16ID:yD3o9/Ufprivateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし
0278名前は開発中のものです。
2008/08/01(金) 00:11:49ID:yp70Uz6tクラス使って日の浅い俺はset()、get()作りまくり。確かにメンドイ。
たぶん何か間違っている。
0279名前は開発中のものです。
2008/08/01(金) 00:14:41ID:GzWnlC6Z俺も同じようなこと悩んでて、気がついたら両方混在してた。
「これはクラスじゃない、構造体なんだ!」
って言い聞かせながらところどころpublicにしてたりw
0280名前は開発中のものです。
2008/08/01(金) 00:22:47ID:z2aBgJTr全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて
0281名前は開発中のものです。
2008/08/01(金) 00:28:14ID:4UGZmRTZコード書くのがマンドイだけなんじゃ?
まっしなIDEやプロパティのある言語つかうとかかな。
0282名前は開発中のものです。
2008/08/01(金) 00:32:32ID:GzWnlC6Z例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。
0283名前は開発中のものです。
2008/08/01(金) 00:36:38ID:z2aBgJTrすばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……
守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ?
0284名前は開発中のものです。
2008/08/01(金) 00:47:59ID:GzWnlC6Zまあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。
あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。
0285名前は開発中のものです。
2008/08/01(金) 00:54:19ID:b/gVwGdZpublicにした方が使う側は書きやすくでいいんじゃないの?と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・
0286名前は開発中のものです。
2008/08/01(金) 01:01:50ID:b/gVwGdZ取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。
0287名前は開発中のものです。
2008/08/01(金) 01:02:58ID:tFL87oCT気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。
0288名前は開発中のものです。
2008/08/01(金) 01:07:26ID:b/gVwGdZなるほど。あまりスッキリしないやり方ですが、しょうがないですかね。
いちいちget()で呼んで、呼び側の変数のセットして使うのって、スループット高そうなのもイヤなんですよね。
0289名前は開発中のものです。
2008/08/01(金) 01:09:03ID:b/gVwGdZ0290名前は開発中のものです。
2008/08/01(金) 01:19:38ID:ua9U6ROuメソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。
0291名前は開発中のものです。
2008/08/01(金) 01:32:56ID:b/gVwGdZこういうのって、センスが必要ですね・・・・。
ちょっと気になった事があるんですが、
自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、
わざわざgetterで呼び出して使う必要はないですよね?
class Foo{
private int a;
public int get(){ return a;}
public int calc(){
return get() * 2;
}
このようなcalc()の書き方に利点はあるのでしょうか?
0292名前は開発中のものです。
2008/08/01(金) 02:26:05ID:ua9U6ROu内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。
0293名前は開発中のものです。
2008/08/01(金) 03:52:45ID:eorE7C0S0294名前は開発中のものです。
2008/08/01(金) 04:12:11ID:gQhqelIhまず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。
0295名前は開発中のものです。
2008/08/01(金) 18:37:49ID:YDkT93Ih今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。
0296名前は開発中のものです。
2008/08/01(金) 19:02:25ID:m4Vy5Xwk個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする
0297名前は開発中のものです。
2008/08/01(金) 20:43:12ID:mQpnHwPhプライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。
0298名前は開発中のものです。
2008/08/02(土) 00:14:18ID:n2w2ONnP0299名前は開発中のものです。
2008/08/02(土) 00:25:25ID:MidBaG0Q0300名前は開発中のものです。
2008/08/02(土) 06:50:04ID:xZ8r6Jdxプロパティが欲しいと。
0301名前は開発中のものです。
2008/08/02(土) 11:52:40ID:eytLWJfu0302名前は開発中のものです。
2008/08/02(土) 23:43:30ID:Pnu26psa0303名前は開発中のものです。
2008/08/03(日) 02:53:56ID:DVblpxWKもう少し具体的に
0304名前は開発中のものです。
2008/08/03(日) 16:40:36ID:HN+lqKwd現行のゲーム機はまだC++なんだよな
0305名前は開発中のものです。
2008/08/03(日) 21:47:19ID:XQeDRsrLシーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。
そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、
結局どんな処理が必要などんなゲームなのか?
どれを止めると不味いか、どれは止めても復帰させれば問題ないか?
とかによると思う。
0306名前は開発中のものです。
2008/08/03(日) 21:52:25ID:qGD4tU/fタイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの?
0307名前は開発中のものです。
2008/08/03(日) 22:00:54ID:0ZCECk8Oウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。
0308名前は開発中のものです。
2008/08/03(日) 23:21:42ID:HN+lqKwd0309名前は開発中のものです。
2008/08/03(日) 23:31:02ID:+gPnPllxDigital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。
いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と
0310名前は開発中のものです。
2008/08/03(日) 23:31:41ID:+gPnPllxうわ俺凄く恥ずかしいマジレス?
0311名前は開発中のものです。
2008/08/03(日) 23:31:45ID:0ZCECk8Oムービーシーンなんて作ったことないからわからんですたい。
脳内妄想では、ムービーを再生できるオブジェクトが登録されてるシーンに移行するだけですたい。
0312名前は開発中のものです。
2008/08/04(月) 17:38:42ID:OcXTlg2n馬鹿にしないでください><
0313名前は開発中のものです。
2008/08/04(月) 23:28:56ID:Vp8LYTR0こらあげにまっことすまんかったぜよ。
0314302
2008/08/04(月) 23:40:39ID:OTznAvMdそうそうそんな感じ。
1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。
0315名前は開発中のものです。
2008/08/07(木) 02:18:10ID:iFGNdN4xしーん…
0316名前は開発中のものです。
2008/08/07(木) 15:44:15ID:J5sJkFaL∴∵
0317名前は開発中のものです。
2008/08/24(日) 00:35:34ID:kCbI2Ziv0318名前は開発中のものです。
2008/08/27(水) 21:03:35ID:pp3RgERm例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか?
stateパターンでは無理???
0319名前は開発中のものです。
2008/08/27(水) 21:31:52ID:tgwWcjRqFCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う
ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。
マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。
0320318
2008/08/28(木) 00:48:01ID:Z+eKsEJGいろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか?
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。
0321名前は開発中のものです。
2008/08/28(木) 01:16:45ID:q3w3U78u好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな!」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。
ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねw
0322名前は開発中のものです。
2008/08/28(木) 01:34:35ID:O/+Qqs/2世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな
0323名前は開発中のものです。
2008/08/28(木) 03:20:26ID:tq3ymPlL可視性に問題が出てきそうで自分では使ってないけど。
0324名前は開発中のものです。
2008/08/28(木) 09:12:41ID:y2qhH8VC0325名前は開発中のものです。
2008/08/28(木) 10:11:26ID:MS2hHN8x全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。
0326名前は開発中のものです。
2008/08/28(木) 11:46:09ID:Qlb2/Pnm0327名前は開発中のものです。
2008/08/28(木) 11:57:21ID:MS2hHN8xJavaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。
0328318
2008/08/28(木) 17:59:10ID:Z+eKsEJG汚いコードって書き直したくなってくるんですよね。
綺麗に書けないと達成感がないというか・・・。
また、本などで知識をつける毎に、今まで書いてきたコードが正しくない書き方だったな〜と思うことが多くて(プログラミング始めた頃はダライアス継承とかやってたw)。
完成させることが第一と思っていてもついつい・・。
>>323,327
stateパターンですよね?
>>325
そういう方法でやってるところもあるんですね。
でも、オブジェクトのコピーが効率悪そう。
0329名前は開発中のものです。
2008/08/28(木) 18:35:54ID:CuTVRbF+それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。
つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる?
0330名前は開発中のものです。
2008/08/28(木) 19:03:37ID:Jt4Hw7jN次のプログラムからは気に入った表記で。
昔の事は忘れましょう。
0331名前は開発中のものです。
2008/08/28(木) 19:43:21ID:MS2hHN8x>>328
>stateパターンですよね?
パターンのことはよく知りませんが、ポリモーフィズム(多態性)です。
0332名前は開発中のものです。
2008/08/28(木) 20:37:26ID:xedxyhWb敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。
0333名前は開発中のものです。
2008/08/28(木) 21:28:28ID:MS2hHN8x他に良い方法があるならどうぞ。
MHz世代のCPUで通用してた方法だから、致命的な効率低下があるとは思わないよ。
0334318
2008/08/28(木) 21:30:31ID:Z+eKsEJGコードの正しさ、綺麗さの2つは曖昧な表現で使うべきではなかったですね。
私はコードには、実行効率、保守性、読みやすさの3つがあると思っています。
今問題にしてるのは、主にこのうち後者2つです。
ただ、読みやすさは人それぞれなのかもしれません。
>>331
状態毎に仮想関数をオーバーライドするのが、まさにstateパターンですね。
0335名前は開発中のものです。
2008/08/28(木) 21:59:24ID:O/+Qqs/20336名前は開発中のものです。
2008/08/28(木) 22:18:17ID:qtCAmqfQ0337名前は開発中のものです。
2008/08/28(木) 22:22:03ID:xedxyhWb爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる?
0338318
2008/08/28(木) 23:04:17ID:Z+eKsEJG保守性については、仕様変更により、状態を追加したり、廃止したりする時、影響する部分を探し出すのがめんどくさいというかすっきりしないというか。
読みやすさは個人的な好みかもしれません。
保守性、読みやすさともにstateパターンの方が好きです。
でも、直交した状態群が複数あるとき、stateパターンで実装するのが難しそうなので悩んでいました。
うまい方法が見つからなければ、enumとifでいくつもりでした。
>>336
ダイアモンド継承の方が一般的な呼び方なのかもしれません。
仮想継承を使うことによって、継承グラフが菱形になるやつです。
0339名前は開発中のものです。
2008/08/29(金) 00:44:03ID:hcEje8O4英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス(Darius?)はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな
0340名前は開発中のものです。
2008/08/29(金) 00:50:36ID:rESH+j3Cデザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える
0341名前は開発中のものです。
2008/08/29(金) 02:39:33ID:VLtb7ZED違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん
0342名前は開発中のものです。
2008/08/29(金) 06:43:42ID:gdp2Jatd0343名前は開発中のものです。
2008/08/29(金) 10:26:08ID:ESvglHwU合ってると思うよ。
問題があるとすれば、状態を変化させるだけの場合、ライフとかのパラメータ引き継ぎどうすんねんとか。
そこんとこがツクールVじゃ無理だった。(最近の(95とか)はシラネ)
0344名前は開発中のものです。
2008/08/29(金) 14:31:33ID:UaA8GGvx>ダライアスっていうとシューティングゲームしか思い浮かびませーん
ダライアスの面セレクト画面が菱形継承図っぽいところから生まれた俗称だったりしてw
0345名前は開発中のものです。
2008/08/29(金) 14:34:13ID:nV9hYRuEいやだったりしてっつーかそれしかなくね
0346名前は開発中のものです。
2008/08/30(土) 13:56:18ID:vqGqt03LC3 MRO の解説でしか見たこと無いが。
0347名前は開発中のものです。
2008/08/30(土) 14:18:00ID:gGJd0yLwこれはいいアニメ。 ... ドラえもん 藤子F不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar
0348名前は開発中のものです。
2008/08/30(土) 14:23:18ID:h7pQaJrI0349名前は開発中のものです。
2008/08/30(土) 14:32:04ID:hoYQeFVI0350名前は開発中のものです。
2008/08/30(土) 14:40:33ID:vqGqt03L0351名前は開発中のものです。
2008/08/30(土) 15:36:27ID:h7pQaJrI0352名前は開発中のものです。
2008/08/31(日) 15:40:22ID:5jP5dBFCAで作ったEをDで使うために、Aから呼び出したB、Bから呼んだC、Cから呼んだDのそれぞれの関数の引数に
Eを渡していくのはいいのかな?
0353名前は開発中のものです。
2008/08/31(日) 15:45:26ID:eaWcmeF00354名前は開発中のものです。
2008/08/31(日) 15:47:56ID:fQJxWw7jEの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない
0355名前は開発中のものです。
2008/08/31(日) 15:54:48ID:5jP5dBFC>>354
サンクス
AからDは直接呼べないけど、Eを使うのはDなので、
AからDにEを渡したいけど、それだけのために間にクラスでEをたらし回しにするのがどうかな〜と
思ったんだよね
0356名前は開発中のものです。
2008/09/02(火) 03:29:08ID:m23QvXa70357名前は開発中のものです。
2008/09/02(火) 03:31:07ID:m23QvXa7コンポジッションの視点、あるいはチェインズ・オブ・レスポンシビリティの視点で言えば、
それは普通にアリ。 っていうか、>>354 も言ってるけど、その構成だけだと(意図する形の意味づけが見えないと)
本当はいいとも悪いとも言えないが。
0358名前は開発中のものです。
2008/09/02(火) 17:16:20ID:BpB/a+5NTireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか?
0359名前は開発中のものです。
2008/09/02(火) 17:22:14ID:Kf1ObPTzTireクラスでCarクラスを生成するとかなら論外
0360名前は開発中のものです。
2008/09/02(火) 17:30:36ID:BpB/a+5Nいいということでしょうか?
0361名前は開発中のものです。
2008/09/02(火) 17:36:03ID:NydWLubYTireが常にCarのポインタを持っている必要もなくて、
CarがTireのメソッド呼び出し時に必要なポインタを渡すのもアリだと思う。
0362名前は開発中のものです。
2008/09/02(火) 17:40:44ID:IXiySr/S0363名前は開発中のものです。
2008/09/02(火) 17:42:28ID:NydWLubY0364名前は開発中のものです。
2008/09/02(火) 17:44:29ID:IXiySr/S0365名前は開発中のものです。
2008/09/02(火) 19:17:31ID:gmtfIbjx0366名前は開発中のものです。
2008/09/02(火) 19:20:27ID:IXiySr/S0367名前は開発中のものです。
2008/09/02(火) 19:24:40ID:gmtfIbjxパンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
0368名前は開発中のものです。
2008/09/02(火) 19:38:46ID:IXiySr/S0369名前は開発中のものです。
2008/09/02(火) 20:44:39ID:F4HrtZLF実際のTPMS(タイヤ空気圧監視システム)はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();
0370名前は開発中のものです。
2008/09/19(金) 19:13:57ID:FmM/zRja0371名前は開発中のものです。
2008/10/05(日) 14:32:14ID:tMuqv+yj0372名前は開発中のものです。
2008/10/05(日) 14:52:40ID:v7IsXRIY質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】スレを立てる前にココで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288
0373名前は開発中のものです。
2008/10/05(日) 17:40:56ID:6np9SFhP0374名前は開発中のものです。
2008/11/01(土) 11:27:07ID:g//jQFByエクセルで打ち込んでcsvで保存?
0375名前は開発中のものです。
2008/11/01(土) 12:46:01ID:YmfIaKZ8専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
0376名前は開発中のものです。
2008/11/01(土) 12:58:04ID:g//jQFByマップに関しては、フリーのエディタがあるんですね。
規模が小さいゲームなら、アイテムとかはエクセルが効率いいのかな。
0377名前は開発中のものです。
2008/11/01(土) 16:47:28ID:NlVHrve10378名前は開発中のものです。
2008/11/02(日) 08:08:32ID:JeGt0JB90379名前は開発中のものです。
2008/11/02(日) 09:02:07ID:i1X6CLvSエディタでやるの?
0380名前は開発中のものです。
2008/11/04(火) 18:29:40ID:CIBt14+U0381名前は開発中のものです。
2008/11/06(木) 00:16:08ID:46fvhfrF0382名前は開発中のものです。
2008/11/11(火) 20:24:09ID:rtOtwyEd今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される(変数として保持される側の)クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。(関連する側が冗長になるが。)
2、再利用を考えたフレームワークは(初心者は)作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください orz
0383名前は開発中のものです。
2008/11/12(水) 01:30:10ID:LsEQ4TEaクラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ!」
ピー…
0384名前は開発中のものです。
2008/11/12(水) 09:02:45ID:QWqH0TggGOF本でわかったならよいけど、退屈でわからない人は
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
0385名前は開発中のものです。
2008/11/12(水) 23:23:14ID:hxIHNKysたとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。(HogeLibrary.Composite)
2、小さなクラスをネスト先の名前空間に入れる。(HogeLibrary.SmallComponent)
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか?
0386名前は開発中のものです。
2008/11/13(木) 21:08:31ID:3NMFClPLboostでは、ライブラリ利用者が直接触る必要ないものはdetailっていうネームスペースに入れてあるね。
ってそういう話じゃない?
0387名前は開発中のものです。
2008/11/14(金) 01:18:47ID:USS/q0/d名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
0388名前は開発中のものです。
2008/11/16(日) 02:04:27ID:OW89wflhどうなってると使いやすいかを考えて臨機応変に決める。
0389名前は開発中のものです。
2008/11/19(水) 20:47:58ID:oq/eqnIPまだ読んでいない俺には勉強になったthx
0390名前は開発中のものです。
2008/11/20(木) 09:17:22ID:jP0yKBYeのFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
(まああのペースで全部網羅すると、値段とページがすごいことになりそうだがw)
0391名前は開発中のものです。
2008/11/30(日) 20:02:56ID:GlMxgFAf特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします
0392名前は開発中のものです。
2008/11/30(日) 20:03:41ID:GlMxgFAf0393名前は開発中のものです。
2008/11/30(日) 20:44:16ID:O5396ILY関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。
0394名前は開発中のものです。
2008/12/02(火) 23:03:37ID:QPPOGJkH気持ちが悪かったから、結局色々こねくり回して何とか別の方法で実装しました。
DirectInputのBufferedは偉大ですね、と。
0395名前は開発中のものです。
2008/12/03(水) 00:00:25ID: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
0396名前は開発中のものです。
2008/12/13(土) 14:29:53ID: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
0397名前は開発中のものです。
2008/12/14(日) 06:46:04ID:foB3PhGtここは実装について話すスレなので、開発論は全くのお門違い。
とっとと失せろ!!
0398名前は開発中のものです。
2008/12/14(日) 06:47:43ID:3zIx1sHY0399名前は開発中のものです。
2008/12/15(月) 01:28:13ID:AODSdSoNありがとう助かるよ
0400名前は開発中のものです。
2008/12/18(木) 23:54:28ID:QLMqRIYYふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
0401名前は開発中のものです。
2008/12/19(金) 12:11:03ID:ygbWfkiR0402名前は開発中のものです。
2008/12/21(日) 09:35:05ID:7nb+zy1b0403名前は開発中のものです。
2008/12/25(木) 19:24:07ID:QpPf00tD0404名前は開発中のものです。
2008/12/26(金) 01:45:37ID: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クラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。
0405名前は開発中のものです。
2008/12/26(金) 08:47:36ID:Y8oI6MzT0406名前は開発中のものです。
2008/12/28(日) 17:34:36ID:pzJs6/UUM:StgScene
V,C:Menu,Playing
ってことなのだろうか?
Stateパターンという風にも捉えられる?
0407名前は開発中のものです。
2008/12/29(月) 00:45:07ID:THn3O3Ozstruct 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();
}
};
0408名前は開発中のものです。
2009/01/07(水) 23:21:00ID:rBsXmGd8自分もまだ試作中だけど、かなり自由かつ堅実に作れる。
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したシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。
・・・っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。
0409名前は開発中のものです。
2009/01/07(水) 23:25:20ID:rBsXmGd8# unfocusing ・・・『戻り値に次の遷移先シーンかnull返す。』 ←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。
0410名前は開発中のものです。
2009/01/09(金) 00:07:48ID:vYDzTrO8・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの?
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
0411名前は開発中のものです。
2009/01/09(金) 01:05:35ID:2TNYOX7Dこのソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。
0412名前は開発中のものです。
2009/01/09(金) 01:28:17ID:vYDzTrO8確かにそのほうが直接的ですっきりするかもね。
0413名前は開発中のものです。
2009/01/10(土) 23:29:07ID:GXwf3cbn危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。
0414名前は開発中のものです。
2009/01/11(日) 00:09:06ID:dWwzUAmXどう考えても使いきれるとは思えん
0415名前は開発中のものです。
2009/01/11(日) 02:43:39ID:cWr0moum0416名前は開発中のものです。
2009/01/12(月) 02:58:31ID:8xCnbJpyPCならそうかもしれないけど、コンシューマ機だと360でやっと512MB(ただしVRAM込み)、
DSにいたっては4MBしかないからね。
0417名前は開発中のものです。
2009/01/12(月) 03:30:42ID:mDvqZ10Eそのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
0418名前は開発中のものです。
2009/01/12(月) 03:32:37ID:mDvqZ10E×ライフサイクル
○ライフタイム
0419名前は開発中のものです。
2009/01/12(月) 11:14:49ID:pb2pea9L0420名前は開発中のものです。
2009/01/12(月) 13:32:30ID:YXD0YS+N一応、常にnewするのは遷移元シーン、deleteするのは対象のシーンの親、ってことになってるけどこれじゃだめかな?
クラス図の関連が木構造で、枝をはさみで切るイメージ。
0421名前は開発中のものです。
2009/01/12(月) 14:12:02ID:sqS0O25/検討した方がいいかも。
0422名前は開発中のものです。
2009/01/13(火) 22:46:08ID:BhFnEm7rそのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。
0423名前は開発中のものです。
2009/01/13(火) 22:46:54ID:BhFnEm7rまあC++になって楽になったものよ。
0424名前は開発中のものです。
2009/01/14(水) 03:24:31ID:0DnXfUAy原則として、シーンをまたぐデータはないように設計する。…言い方が悪いな
あるシーンで使われたデータは、その子シーンで使われることがあっても、祖先のシーンで使われることはないように設計する。
あるシーンが持つデータを子シーンが使いたかったら、
>>417が言ってくれているように、コンストラクタで自由に子シーンに渡してしまう。
まぁほとんどの場合はコンストラクタ時に親シーンをそのまま子シーンに渡す。(子シーンで使いたいデータはpublicにしておく)
0425名前は開発中のものです。
2009/01/14(水) 03:32:21ID:0DnXfUAyゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
0426名前は開発中のものです。
2009/01/17(土) 14:39:28ID:AWtASysq0427名前は開発中のものです。
2009/01/21(水) 22:53:35ID:sHv/LIGj独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
0428名前は開発中のものです。
2009/01/21(水) 23:23:50ID:sHv/LIGj前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
(本質的にバリアや耐久力表示と同じ関係なので。)
0429名前は開発中のものです。
2009/01/22(木) 00:12:28ID:P249I5A7これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報(背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。
0430名前は開発中のものです。
2009/01/22(木) 00:45:44ID:P249I5A7あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
0431名前は開発中のものです。
2009/01/22(木) 00:57:55ID:P249I5A7・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。
0432名前は開発中のものです。
2009/01/22(木) 04:27:16ID:lwlInfIxとりあえず「管理」という言葉を使わないように考えることをおすすめする。
http://www.google.co.jp/search?q=SomethingManager
0433名前は開発中のものです。
2009/01/22(木) 04:40:32ID:P249I5A7サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
0434名前は開発中のものです。
2009/01/22(木) 15:25:00ID:x7I7tNfu0435名前は開発中のものです。
2009/01/29(木) 21:46:47ID:dRfTqeNw管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
0436名前は開発中のものです。
2009/01/30(金) 16:55:21ID:O2nIHOeq0437名前は開発中のものです。
2009/01/31(土) 08:12:45ID:qu7YpnnPとたまに悩む
0438名前は開発中のものです。
2009/01/31(土) 12:07:33ID:2t9biDkM0439名前は開発中のものです。
2009/01/31(土) 19:06:11ID:mhj1e1O5最近はもう深く考えるのはやめた
0440名前は開発中のものです。
2009/01/31(土) 19:11:05ID:L0OEs6zN悩む悩むw
0441名前は開発中のものです。
2009/02/01(日) 19:03:38ID:tMKL4U611番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。
0442名前は開発中のものです。
2009/02/02(月) 20:35:13ID:esDSGZyHどこかに細分化できないかなと悩み出すんですね
わかります
0443名前は開発中のものです。
2009/02/03(火) 03:59:27ID:cOF6NPxT割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか
0444名前は開発中のものです。
2009/02/06(金) 21:51:27ID:+KF0MHRv・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
0445名前は開発中のものです。
2009/02/06(金) 21:56:52ID:jTgjQpbm物の理を司る GOD class
0446名前は開発中のものです。
2009/02/06(金) 21:57:18ID:sBGSiXKq・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。
0447名前は開発中のものです。
2009/02/06(金) 21:58:24ID:y5Y5dk+m0448名前は開発中のものです。
2009/02/07(土) 00:34:27ID://aDzdii石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス
0449名前は開発中のものです。
2009/02/07(土) 01:46:53ID:HaVHq232石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス
0450名前は開発中のものです。
2009/02/07(土) 13:25:16ID:bH//onUqゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス
0451名前は開発中のものです。
2009/02/07(土) 14:22:20ID:VS035g6S石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス
0452名前は開発中のものです。
2009/02/07(土) 14:51:09ID:VC/wpjC+オブジェクトの衝突判定の組み合わせの数だけクラス作るつもり?
0453名前は開発中のものです。
2009/02/07(土) 16:19:23ID:Pn1Dl7ZhCGameManagerですね、わかります
0454447
2009/02/07(土) 16:35:33ID:oHEfOG3S0455名前は開発中のものです。
2009/02/13(金) 17:17:04ID:gamtZzLZ>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。
0456名前は開発中のものです。
2009/02/13(金) 17:35:30ID:gamtZzLZやっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。
0457名前は開発中のものです。
2009/02/14(土) 00:06:30ID:wuF2UeZP0458名前は開発中のものです。
2009/02/14(土) 00:20:27ID:+0ELSliXじゃあ新たなネタ出せよ
0459名前は開発中のものです。
2009/02/14(土) 01:01:03ID:1cFYmXpg新しいネタか……。じゃあ、1つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード&短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。
0460名前は開発中のものです。
2009/02/14(土) 03:08:07ID:qKH3GStO無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はOFFで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利/敗北または成功/失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール(数十倍〜数十分の一まで)。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。
0461名前は開発中のものです。
2009/02/14(土) 10:08:02ID:hPf9zE7f0462名前は開発中のものです。
2009/02/15(日) 16:27:42ID:933sIzghそんくらいしかやっていないな。
0463名前は開発中のものです。
2009/02/18(水) 14:05:52ID:1weRwVkoいろいろありがとう。
あらかたデバッグ用に実装してみました。
0464名前は開発中のものです。
2009/02/18(水) 14:39:48ID:0gTNCSoI素晴らしい。見習いたい
0465名前は開発中のものです。
2009/02/19(木) 03:37:37ID: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なので、便利ボタンとパラメータ操作がとても役に立っています。
ありがとうございました。
0466名前は開発中のものです。
2009/02/21(土) 07:24:48ID:3Qcrn5prゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。
0467名前は開発中のものです。
2009/02/21(土) 12:50:08ID:YLpnm94h0468名前は開発中のものです。
2009/02/24(火) 16:03:05ID:xS4ZudQO0469名前は開発中のものです。
2009/02/25(水) 02:46:38ID:1o4GjPkR次のC++規格が決まれば、早ければ今年中にも
std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど
0470名前は開発中のものです。
2009/02/25(水) 05:08:14ID:M8Pe/6zZまず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。
0471名前は開発中のものです。
2009/02/25(水) 11:43:26ID:woJXacCs0472名前は開発中のものです。
2009/02/25(水) 18:18:12ID:QjeqtKpKいろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ
0473名前は開発中のものです。
2009/02/25(水) 18:28:42ID:nKINhS/o私のように
0474名前は開発中のものです。
2009/02/25(水) 18:31:43ID:Z+e+XbPJ0475名前は開発中のものです。
2009/02/25(水) 18:55:09ID:1o4GjPkRスマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・
0476名前は開発中のものです。
2009/02/27(金) 15:15:39ID:MDeQuwXlDraw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは
1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他
現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?
0477名前は開発中のものです。
2009/02/27(金) 15:58:46ID:XnWaU4Ou0478名前は開発中のものです。
2009/02/27(金) 17:33:53ID:lChaxYTz0479名前は開発中のものです。
2009/02/28(土) 00:40:47ID:OR4wkfx2符号なし整数とか。
どっかにそういう例ないです?
0480名前は開発中のものです。
2009/02/28(土) 08:42:03ID:Cadu6Xk70481名前は開発中のものです。
2009/03/04(水) 04:45:32ID:y6+tTW6Fこんなんでいいか?
ttp://codezine.jp/article/detail/2171?p=2
0482名前は開発中のものです。
2009/03/06(金) 11:34:39ID:7UNSgj8MJavaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う
0483名前は開発中のものです。
2009/03/06(金) 13:08:45ID:A313Daxtグローバル変数が欲しいんではなくて、システム全体で一つしかないということを
明示的にする為のパターンだから
0484名前は開発中のものです。
2009/03/06(金) 14:26:30ID:7UNSgj8M普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう
0485名前は開発中のものです。
2009/03/06(金) 14:28:31ID:7UNSgj8M「クラス定義必須、インスタンシエーション普通」の言語だな。
0486名前は開発中のものです。
2009/03/06(金) 15:48:06ID:A313Daxtエンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー
0487名前は開発中のものです。
2009/03/06(金) 16:07:52ID:7UNSgj8Mそのクラスのインスタンスが1つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ
0488名前は開発中のものです。
2009/03/06(金) 16:18:21ID:7UNSgj8M「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね?
// 生成やコピーを禁止する
↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい
0489名前は開発中のものです。
2009/03/06(金) 16:29:34ID:7UNSgj8Mそれ以外だとやっぱり儀式めいたものを感じるな
0490名前は開発中のものです。
2009/03/06(金) 16:29:53ID:oPKUKLY9ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件
0491名前は開発中のものです。
2009/03/06(金) 16:34:17ID:7UNSgj8Mアンチクラスなんて単語あったんだ
知らなかった
C++でもクラス使いまくりなんだけど
C++でシングルトンやらないだけでアンチクラスか
0492名前は開発中のものです。
2009/03/06(金) 16:39:54ID:7UNSgj8Mhttp://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++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい
0493名前は開発中のものです。
2009/03/06(金) 16:57:37ID:12yJl3Asコンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
0494名前は開発中のものです。
2009/03/06(金) 17:07:43ID:7UNSgj8Mいくらでもあるのか
そういや初期化を意識させたくない場合なんかもクラスで管理した方がいいな
あとは>>489
俺にはこの2つくらいしか思いつかんが
こういう風にクラス化する理由があるならいいんじゃね
>じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
>>484
0495名前は開発中のものです。
2009/03/06(金) 17:20:31ID:12yJl3Asまあでもお前がその方が楽だと言うなら尊重するよ
一緒に仕事する相手じゃないからな
0496名前は開発中のものです。
2009/03/06(金) 18:55:30ID:Erqh3NJs素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。
0497名前は開発中のものです。
2009/03/06(金) 20:00:35ID:z7QigqBL他人に強要しなければね
0498名前は開発中のものです。
2009/03/12(木) 10:42:00ID:X7nBBwQAinterface // 宣言部(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
0499名前は開発中のものです。
2009/03/12(木) 10:43:53ID:X7nBBwQA捕捉:
(わかると思うけど)使う時は、他のユニットから
Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節?でアプリ終了時のFPrinterの開放処理がある。
0500名前は開発中のものです。
2009/03/16(月) 15:21:22ID:FTtiBwy20501名前は開発中のものです。
2009/03/18(水) 23:45:50ID: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, ...);
}
もし既に案の方法でやってる人いたら使い勝手教えて!
0502名前は開発中のものです。
2009/03/19(木) 04:54:27ID:KYbRBn+zだが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ!
0503名前は開発中のものです。
2009/03/19(木) 05:21:17ID:XLj1eEa+0504名前は開発中のものです。
2009/03/19(木) 19:28:19ID:ALN5WhPjlpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…
0505501
2009/03/20(金) 00:10:41ID:/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人では無かったけれど。
0506名前は開発中のものです。
2009/03/20(金) 02:39:39ID:D2lp0Ec40507名前は開発中のものです。
2009/03/20(金) 04:52:36ID:09EDEaYzstruct 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;
};
続く…
0508名前は開発中のものです。
2009/03/20(金) 04:53:53ID:09EDEaYzelementList.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);
}
}
うーむ…。
0509501
2009/03/21(土) 12:54:05ID:Y4F/PoMw今回の話では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 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。
0510名前は開発中のものです。
2009/03/22(日) 03:32:29ID:O7e3N6nq>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。
0511501
2009/03/23(月) 00:38:25ID:/nVLLFvd確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ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()みたいにベタ書きで
どこまでいけるかやってみるかな。
0512名前は開発中のものです。
2009/03/25(水) 00:59:33ID:koP5FPqt0513名前は開発中のものです。
2009/03/25(水) 12:39:16ID:C50L0uFm0514名前は開発中のものです。
2009/04/05(日) 14:24:00ID:a5PaoF6Bデバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い
0515名前は開発中のものです。
2009/04/06(月) 03:21:58ID:NgKFyYts0516名前は開発中のものです。
2009/07/15(水) 22:32:12ID:1c2msACvクライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
| |->Main-->Map -|
| -->Unit--->sprite--|
|--------------------------------------------------------------->GraphicsWarpper
0517名前は開発中のものです。
2009/07/15(水) 22:40:07ID:h6KyoexM0518名前は開発中のものです。
2009/07/15(水) 22:41:36ID:3ppQI3l+> ScreenManger
画面飼槽
> GraphicsWarpper
グラフィックスワープ装置
何が言いたいのかさっぱりわからないのだが。
0519516
2009/07/15(水) 22:46:53ID:1c2msACv忘れてました。
net frameworkを使ってます。
>>518
ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
GraphicsWarpperは単なるラッパーです。
0520名前は開発中のものです。
2009/07/15(水) 22:57:45ID:cL81hhcG0521名前は開発中のものです。
2009/07/15(水) 23:01:47ID:3ppQI3l+> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。
小学校は夏休みなのか・・
せめて中学生になってからにしてくれ
0522名前は開発中のものです。
2009/07/15(水) 23:14:16ID:1c2msACvすまん。スペルミスった・・・。
0523名前は開発中のものです。
2009/07/16(木) 01:35:23ID:Ac1CnfQdそうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは1つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う
0524名前は開発中のものです。
2009/07/16(木) 02:06:03ID:Dq9kBSTxありがとう。
それをあたってみる。
0525名前は開発中のものです。
2009/07/16(木) 02:29:30ID:lK28N0n10526名前は開発中のものです。
2009/07/16(木) 05:49:13ID:0eDNLm6a0527名前は開発中のものです。
2009/07/16(木) 10:25:09ID:irpkCXOF0528名前は開発中のものです。
2009/08/14(金) 18:57:02ID:qfXJNhjS>>395
395以前のまとめ
>>404,406-407
シーン遷移考え方
>>408-413,416-425
シーン遷移実装サンプルと問題点。
>>427-433
0からSTGの作成を考える。
根本的な勘違いや非効率的なことがあるのであまり参考にはならない。
>>437-443
オブジェクトと座標管理
>>444-456
オブジェクトと衝突判定と全体効果
>>459-465
デバッグ用処理を考える。(衝突判定表示とか)
>>501-511
DirectXのデバイスの管理とか使い方
>>523
ネットワーク機能参考図書紹介
0529名前は開発中のものです。
2009/08/14(金) 19:24:51ID:qfXJNhjS・・・あんま設計と関係ないな・・・
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い・・・気がする。
0530名前は開発中のものです。
2009/08/14(金) 22:21:56ID:FZUQWr9u設計というよりは演出(エフェクト)の話でしょうか。
もし続けるなら専用のスレを立てた方がよいと思われ。
0531名前は開発中のものです。
2009/10/05(月) 01:40:33ID:mQYy5BRf経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが,
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか?
データクラスを作ってアクセッサで操作を許す?
それとも,すべてグローバル変数で持たせる?
0532名前は開発中のものです。
2009/10/05(月) 04:33:25ID:/TvwIsfE0533名前は開発中のものです。
2009/10/05(月) 07:34:29ID:Rel4l/Gg0534名前は開発中のものです。
2009/10/14(水) 22:12:56ID:TwzkU58sただ、データの表示とかはいつも頭を捻らすなぁ。
0535名前は開発中のものです。
2009/10/15(木) 07:50:05ID:P3b4xThD0536名前は開発中のものです。
2009/10/15(木) 08:41:22ID:OtHf9VTl0537名前は開発中のものです。
2009/10/15(木) 15:54:18ID:byjv3si3オタクの頭ん中は
0538名前は開発中のものです。
2009/10/15(木) 20:13:55ID:P3b4xThD意見を頂けるだけで嬉しいです.
むしろ噛み付くほうが迷惑です.
0539名前は開発中のものです。
2009/10/15(木) 22:16:10ID:r8d5RKMA質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。
0540名前は開発中のものです。
2009/10/15(木) 22:18:05ID:2byzEsEEアクセッサ書くのめんどくさいって言ってたら
コーディングが意味不明になってやる気をなくす自信がある。
実際それで何回も挫折した。分かりにくくなるくらいならメンドイ方がマシ。
0541名前は開発中のものです。
2009/10/15(木) 23:29:40ID:r8d5RKMAアクセッサ書くのもめんどくさいとは思わない。
0542536
2009/10/16(金) 00:35:50ID:L+kS7tAJ悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…
0543名前は開発中のものです。
2009/10/16(金) 01:18:33ID:MsmDVyev参考になりました,ありがとうございます.
0544名前は開発中のものです。
2009/10/16(金) 01:38:32ID: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);
て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。
0545名前は開発中のものです。
2009/10/16(金) 06:29:56ID:UJ9WR3Zt変数を直接弄るんでもいいかな・・・。
0546名前は開発中のものです。
2009/10/16(金) 11:40:43ID:/PDPq+0/そういう可能性を考慮すると、関数を経由させたほうが便利。
0547名前は開発中のものです。
2009/10/16(金) 20:07:25ID:eJ9LLkd5そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。
0548名前は開発中のものです。
2009/10/18(日) 12:51:59ID:Yr/zm5ey確かに使い方を間違えるってのはよく起こる
0549名前は開発中のものです。
2009/10/25(日) 23:29:18ID:tIk7fQwv次に来るシーンを各クラスに設定しておいたりとか・・?
0550名前は開発中のものです。
2009/10/25(日) 23:57:46ID:6R6DoQXiGems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。
0551名前は開発中のものです。
2009/10/26(月) 00:08:52ID:PLlfj58P0552名前は開発中のものです。
2009/11/16(月) 14:29:49ID:FF5xAAX0その後どうなった?
俺も今描画周りを考えてる
0553名前は開発中のものです。
2009/12/13(日) 15:40:07ID:Pf4hrG82void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}
void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}
って風にやったら問題あるの?
0554名前は開発中のものです。
2009/12/14(月) 01:36:46ID:etpwNEHLdevice呼び出しが長くなるが、面倒なら#define
俺はこんな感じ
無知なんだけど、デバイスて何個も必要になることあんの?
0555名前は開発中のものです。
2009/12/14(月) 01:57:52ID:ViaP5WDz0556名前は開発中のものです。
2009/12/14(月) 03:13:37ID:etpwNEHLそうでないなら同じようなクラスを用意するかな
便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる
まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな
0557名前は開発中のものです。
2009/12/14(月) 11:05:57ID:QE4kvqHrプレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。
0558名前は開発中のものです。
2009/12/14(月) 14:08:44ID:lLcah1pB(左右同時に押された場合は後からの入力を優先)
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな
0559名前は開発中のものです。
2009/12/14(月) 15:35:13ID:ViaP5WDz0560名前は開発中のものです。
2009/12/21(月) 22:25:25ID:F5CW/HFFそれらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか?
boostソース読めってのは無しでお願いします。
0561名前は開発中のものです。
2009/12/21(月) 23:10:45ID:yYVJ9W7O「スマートポインタ」でググれば解説もサンプルも見つかるよ。
0562名前は開発中のものです。
2009/12/22(火) 01:26:27ID:Q5u6VebDなんで boost::shared_ptr 使わないの?
0563501
2009/12/30(水) 05:37:23ID:CHdRD74o描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。
簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。
コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列(描画スクリプトみたいの)を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。
デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。
0564501
2009/12/30(水) 22:40:42ID:CHdRD74o>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。
つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。
たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。
0565名前は開発中のものです。
2009/12/31(木) 08:32:52ID:QBEbvaiT内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし
0566名前は開発中のものです。
2009/12/31(木) 15:10:35ID:wXwu3da7Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。
0567名前は開発中のものです。
2010/01/04(月) 06:09:33ID:JxRYn/a0たしか、mixiアプリのモバイルゲームでGAE使った事例があったな。
3000万PV/月をかなり安価で乗りきれるとか
Togetter(トゥギャッター) - まとめ「100万PV/日のmixiアプリモバイルをGoogle App Engineで実装した@gclue_akira氏に直撃インタビュー」
http://togetter.com/li/494
すれ違いの話題になるが、昨今のネットが絡むゲームの場合バックエンドの技術も必要だけど、
そういう話題を扱ったスレってないものかな
この板にネットゲームの開発時代が少ないみたいだから、需要はないのかもだけど
まーGAEならWebProg板のAppengineスレ行けばいいしな
0568名前は開発中のものです。
2010/01/04(月) 06:10:39ID:JxRYn/a0o 開発自体
0569名前は開発中のものです。
2010/04/20(火) 00:42:02ID:pYU4LjYZ0570名前は開発中のものです。
2010/05/11(火) 16:43:34ID:mK0DmPV50571名前は開発中のものです。
2010/09/20(月) 21:23:17ID:Qy1aznUBどういう風にクラス分けすればいいか悩んでます
MAPクラス
Playerクラス
GameFrameクラスの3つがあって
mainループで
switch(MODE)
{
case TITLE:~~~~;break;
case MENU:~~~~;break;
case STAGE01:~~~~;break;
case STAGE02:~~~~;break;
.
.
.
}
みたいなことをしています。
各Stageに行くたびに、ステージ前処理と、ステージ後処理をしたいです
というとコンストラクタとデストラクタ……つまりはクラスを使えばいいんじゃないか?
という感じなのですが
Playerクラスの持っている情報と、操作関連を上手く融合させたり
Mapクラスの持っている情報と、Playerクラスを上手く組み合わせたりが出来ません……
こういう部分はどういう風にデザインするのがいいのでしょうか
0572名前は開発中のものです。
2010/09/21(火) 03:43:33ID:l4LB0P7iファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。
0573名前は開発中のものです。
2010/09/23(木) 17:38:03ID:g80tUxgWTitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ?
0574名前は開発中のものです。
2010/12/04(土) 11:15:23ID:bbisnDl0貴方は俺か
クラス名と悩みが殆ど同じとかw
0575名前は開発中のものです。
2010/12/04(土) 14:39:29ID:t6Qi73J8ちょっと難しいかもしれないが
ttp://marupeke296.com/GDEV_main.html
ここはかなり参考になる気がするよ。サンプルもあるし。
その6とその7ね。
0576名前は開発中のものです。
2011/02/02(水) 03:54:28ID:uhRk4Rqb0577名前は開発中のものです。
2011/05/20(金) 08:10:28.28ID:PnmAmJ/W0578名前は開発中のものです。
2011/08/02(火) 05:21:50.11ID:jrRNxlOfhttp://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293
オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける
携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな
0579名前は開発中のものです。
2011/08/02(火) 12:43:43.47ID:w6MyIbcF0580名前は開発中のものです。
2011/08/04(木) 13:31:14.84ID:OiYK4POHあの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてw
0581名前は開発中のものです。
2011/08/09(火) 01:57:38.36ID:/4Pi5/Qb0582名前は開発中のものです。
2011/08/09(火) 20:19:58.06ID:9GJ5MiVh面倒が起きやすいんじゃないか
0583名前は開発中のものです。
2011/08/15(月) 07:32:13.82ID:zPArLam8消えてるみたい
どこか掲載されるサイトしらない?
0584名前は開発中のものです。
2011/08/21(日) 15:33:02.73ID:IUtyM1fdキャッシュとかも見たんだけどさ
0585名前は開発中のものです。
2011/09/04(日) 02:30:22.85ID:novGGJeqそうかもしれない。
その世代が今のゲーム現場で老害化してるんでむしろ行って欲しい。
■ このスレッドは過去ログ倉庫に格納されています