具体的なゲーム名を挙げて、
どのようにクラス設計をすればよいか、
継承・委譲関係はどのようにすればよいか、
使えそうなパターンは何かなど語るのもよし。
自作ゲームの内容とクラス図を書いて
改善案を聞くもよし。
設計に関して困ったことを質問するもよし。
関数の具体的な実装内容やゲーム内容に関しては他スレに譲る。
大いに語れ。
前スレ
http://pc11.2ch.net/test/read.cgi/gamedev/1155209226/
テンプレ追加事項あったらよろすく
探検
ゲームにおけるデータ構造・クラス設計・パターン2
■ このスレッドは過去ログ倉庫に格納されています
1名前は開発中のものです。
2008/05/23(金) 21:10:59ID:8M1gqhPX2008/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乙
一応デザパタ軽く。
必須ではないが用語として便利なのでしばしば話題に上がる
[参考サイト]
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乙
一応デザパタ軽く。
2008/05/24(土) 01:01:32ID:hwB5uNnT
3ゲトー1乙。ずっと待ってたぜ。
2008/05/24(土) 01:10:28ID:hwB5uNnT
・オブジェクト指向といったら特に指定しない限りクラスベース(所謂最も一般的なオブジェクト指向)
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。
・インスタンスの方がより正しい場合は極力インスタンスという用語を使い、オブジェクトの使用は避ける。
とかスレの前提としてどうだろう。
2008/05/24(土) 01:16:03ID:fCOY9f2q
インスタンスってつまりは実体のこと?
Foo foo = new Foo() とすると foo がインスタンス?
Foo foo = new Foo() とすると foo がインスタンス?
2008/05/24(土) 01:24:20ID:WrI+RE5A
デザインパターンとOpen-Closed Principle
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
これも
2008/05/24(土) 02:07:45ID:hwB5uNnT
2008/05/24(土) 02:41:35ID:/DdfEDqz
「ゲームとはPrettyなインターフェースを備えたデータベースである」
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな
っていう文言がどっかのペーパーに書いてあったけど、
スクリプト指向が進めば進むほど現実味を帯びてくるな
2008/05/24(土) 16:24:52ID:WrI+RE5A
スクリプト指向の意味がさっぱりわからない
2008/05/24(土) 17:17:01ID:LLc7AXF7
今最高峰のプログラマって、全員WEB系じゃん?
WEB系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな?
WEB系ってぶっちゃけスクリプト志向なんだよね
これでわかるかな?
2008/05/24(土) 17:53:41ID:hwB5uNnT
2008/05/24(土) 21:56:16ID:WrI+RE5A
メリットやデメリットを言えないくせに
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?
「これはすごいんですよ、これを使えば安心です」って言ってるだけか
タスクシステム信者と同じだな
それで、教祖様は誰がなる予定なの?
2008/05/24(土) 23:02:12ID:zxthQanT
2008/05/24(土) 23:16:51ID:6QB8Oyw/
プ板から厨房誘致すればこのスレは盛り上がる。間違い無いw
2008/05/24(土) 23:28:05ID:PtHN405f
たてなきゃいいのに布教スレなんかたてるからこうなる
2008/05/25(日) 00:49:54ID:9gKbes0q
もう厨房が数匹住み着いたのか
2008/05/25(日) 10:55:20ID:9DfW5HgH
プ板?
ム板のことか?
ム板のことか?
2008/05/25(日) 11:05:10ID:93aOxetu
マ板じゃね?
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
やる夫で学ぶデザインパターン
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
2008/05/28(水) 00:17:53ID:EMOoLtkb
途中からゲーム関係なくね?
2008/05/28(水) 09:16:17ID:rm2+ecl2
俺には全部ゲームに関係した話に見えるけど?
サンプルコードもゲームだしわかりやすくていいと思うが
サンプルコードもゲームだしわかりやすくていいと思うが
2008/05/28(水) 10:19:46ID:jKXaFTfv
なんか、無理矢理ゲームに例えてる感がひしひしと。
2008/05/28(水) 12:07:15ID:yrY1wCou
日本語も満足に読めないのか
2008/05/28(水) 12:58:54ID:aV/WuK9Y
お、2スレ目立ってたのね。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。
なんだかんだで前スレは良スレだったと思っていたので嬉しいじゃない。
2008/05/28(水) 19:17:39ID:rm2+ecl2
>>22
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ!」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い
そりゃ「デザインパターン使えばこんなにゲーム作りやすいよ!」じゃなくて
「例としてゲーム使ってデザインパターン解説してみた」だからそんなもんだろ
無理に読めとは言わないが、全く関係ないって事は無い
2008/06/01(日) 20:32:11ID:CN3GNXI+
俺のレベルではよくわからんが
ゲーム屋からみれば変な設計なん?
ゲーム屋からみれば変な設計なん?
2008/06/01(日) 20:35:37ID:9GWV5N72
デザインパターンを丸々入れ込むとゲームだと描画とかで
速度でないゴミになりそうな悪寒
速度でないゴミになりそうな悪寒
2008/06/01(日) 22:40:05ID:IjC+ZLNy
関数呼び出しとか仮想関数分のオーバーヘッドってそんなに響くか?
まぁ使い過ぎが良くないってのには同意だけど
まぁ使い過ぎが良くないってのには同意だけど
29名前は開発中のものです。
2008/06/02(月) 00:45:33ID:u3nq1AKu クラスというか、同じ関数名が増えまくるオブジェクト思考言語は、GTAGS使えないので嫌いです。継承構造とかも嫌い。
こんなんじゃ、ゲーム屋って無理?
こんなんじゃ、ゲーム屋って無理?
2008/06/03(火) 13:20:56ID:Up2rlfhT
2008/06/03(火) 13:37:21ID:60nvGBII
2008/06/03(火) 14:28:32ID:FP0Va/Ol
cscopeならglobalと同じような事をC++やjavaのコードに対してもできるぜ
2008/06/03(火) 18:34:30ID:R8vkDVly
CodeWarriorとか、OOPでもばんばんタグジャンプできるから問題ないのでは?
どうしてもGTAGSがいいの?GTAGSってGNU Tags?Google Tags?
どうしてもGTAGSがいいの?GTAGSってGNU Tags?Google Tags?
2008/06/04(水) 03:53:09ID:8a5x1JRq
35名前は開発中のものです。
2008/06/07(土) 05:38:48ID:PKYwPYRJ >>27
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。
デザインパターンはシステムに応じて最適化することを前提としてる。
お前が考えているように、パターンを丸々適用するのは危険。
ただ、デザパタを適用する事による処理コストなんて大したことない。
物理演算や描画周りの重さに比べればメソッド呼び出しがちょっと増えるくらい誤差みたいなもん。
デザインパターンは省メモリプログラミング手法でもなければ、高速化手法でもない。
どのデータに対してどの処理を行うかを、継承と抽象化を使って示しているにすぎない。
皆がパターンやオブジェクト指向をありがたがるのはソースコードが肥大化しても
グダグダになりにくいという利点があるからであって、そこに処理速度の話を持ち込むのは
少々お門違いな気もする。
36名前は開発中のものです。
2008/06/08(日) 20:08:17ID:1W8n4o1x シューティング作っているんだけど
参考になるサイトでもある?
参考になるサイトでもある?
2008/06/08(日) 20:17:15ID:WckjqjCh
積み木ファイターのひととか
2008/06/10(火) 10:07:55ID:nTtkz+dw
ゲーム作るときってどうやってプログラム組んでいく?
全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル
全体構造を決めてから、トップダウンアプローチで作る
その場 その場で決めていき 作っていく スパイラルモデル
2008/06/10(火) 10:18:30ID:XooPHqWt
>>38
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ?
その場その場で決まることを組み合わせて全体構造を決めていく。
都合が悪けりゃさっさと変える。
これじゃ毒にも薬にもならんかも。・・・トップダウンとかスパイラルとか、
アプローチの方向を固定化するのは良くない、って感じ?
2008/06/10(火) 11:31:11ID:K9Q1TpUp
2008/06/10(火) 12:26:21ID:hsBh970A
趣味で1人で作るのか、同人誌即売会狙いで数人で作るのか、会社の業務として作るのかで変わるとは思うけどな。
まあ、最後はありえねーとしてもw
まあ、最後はありえねーとしてもw
2008/06/10(火) 19:02:52ID:ZqBN8Kq4
>>38
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz
どうしても単体テスト完了した部品を繋ぎ合わせる格好でやるので
最初は全体構造は無視
エンジン本体が部品の扱うデータ構造とズれる事はしょっちゅうなんで
ブリッジ用コードやデータの再パーサだらけになるorz
2008/06/12(木) 08:01:35ID:IMyaUQnN
2008/06/14(土) 10:10:24ID:ITcMwq//
まずはトップダウンでモデル作って、作りながら問題があれば
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。
モデルにフィードバック入れてくってやり方以外で
マトモなプログラムを作る方法はないだろ。
2008/06/14(土) 14:13:33ID:GhaLcPKx
それができないから、他に方法が無いかと模索してるんでしょうね。お察しください。
2008/06/14(土) 15:55:22ID:vUcsb6CI
あのgoogleですらボトムアップだという
2008/06/14(土) 21:53:33ID:TLBVclDV
それはプロジェクト的な意味でだろ。
2008/06/23(月) 00:38:10ID:fMSgUVEh
デバイスへのポインタってグローバルにしたほうが明らかに管理しやすいよな
2008/06/23(月) 01:30:28ID:eCdVbunT
>>48 は?なんで?
2008/06/23(月) 01:34:12ID:pTJzzIh1
俺はどっかにまとめるなあ
グローバルとか、デバイス差の吸収とか必要になったとき困らね
グローバルとか、デバイス差の吸収とか必要になったとき困らね
2008/06/23(月) 02:05:44ID:NUHlpJuv
Direct3Dのデバイスの話とまず仮定。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との2択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。
そして、
・デバイスへアクセスする処理(関数)まで引数渡しでデバイスポインタを渡す
・どの処理(関数)からでもグローバルにアクセス出来るように保持する
との2択から、管理しやすさについて語っているのだと推測。
で、俺の意見は>>48と一緒。
理由は、引数で渡していくのは手間が増えるだけだと思うから。
引数で渡すのは、複数のデバイスを使う場合には意味を持つのかなと思うんだけど、
ゲームにおいて複数のデバイスを使う時って無いんじゃないだろうか。
2008/06/23(月) 02:31:28ID:/DBWn/TJ
ヘッダーが重たくなるから一部のソースでデバイス関連のインクルードして、
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。
そのソースだけでインスタンスの管理やアクセスを許して、
他のソースではインスタンスのポインター保持だけできるようにしてる。
2008/06/23(月) 08:22:39ID:mKIom38M
オレはシングルトンクラスに持たせてそこからgetter呼ぶかなあ
2008/06/23(月) 14:04:29ID:/Ozl3kU4
レイヤスーパータイプじゃないの
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど
シングルトンはインスタンス数の制限が目的だし、組み合わせて使うならいいけど
2008/06/23(月) 22:16:08ID:T9NriNFy
デバイスを使うような処理は関数で囲っちゃって、
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな?
普段はデバイスに直接触りすらしないようにしちゃうのは異端かな?
2008/06/23(月) 22:34:15ID:X6Q0hHes
>>55
俺もー
俺もー
5756
2008/06/23(月) 22:37:13ID:X6Q0hHes ↑でも、ビューアとかデバッグ系のプログラムは別だけどね。
2008/07/02(水) 02:46:33ID:Z7PtKJGp
お前らシーンの遷移ってどういう風に管理してる?
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。
俺は最初、各シーンクラス内で次シーンオブジェクトを直接生成してたんだが、遷移の修正がし難くなるから止めた。
そこでより上位で、静的なシーン遷移管理クラスが現在シーンからイベントを受け取って、
現在の色々な状態をチェックして適切なシーン遷移を行うのを考えたんだが、
これでも、一定のまとまりのあるシーン遷移が積層した場合には泥臭いコードが増えると思ったんで止めた。
んで今やってみてるのは、先のシーン遷移管理クラスをオブジェクト化して、それらをスタック状に積み上げておいて、
現在シーンからのイベントを、処理できる奴まで上から順にたらい回しにしていく方法。
遷移管理オブジェクトのポップ忘れに注意が必要だけど、今のところそう悪くない構造だと思ってる。
他にはどういうやり方があるだろう。
2008/07/02(水) 03:01:12ID:US3ampRT
シーンクラスじゃなくて管理クラスの方を積むの?
俺の鳥頭じゃちょっとイメージしにくい・・・
俺の鳥頭じゃちょっとイメージしにくい・・・
2008/07/02(水) 08:11:54ID:1rjp9Xph
シーンなぞ市販のゲームだって両手の指で足りるくらいしかないのに
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの?
なんでそんなものの遷移だけで無駄にコードをいじりまわすのか
現在アクティブな遷移管理オブジェクトを隠蔽してなにか楽しいことがあるの?
2008/07/02(水) 10:15:59ID:25mPqNml
シーンねぇ
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。
なんか適当な名前のグローバルな列挙定数でswitch文で制御しているけど駄目なんかなぁ。
2008/07/02(水) 19:16:17ID:noQk3O5d
それで問題感じなきゃ無問題
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね
設計次第だしね
抽象化次第では面白い構造になりそうかも
抽象化不要なゲームなら別にswitchでよくね
2008/07/02(水) 22:59:17ID:zDJJl2HF
シーンの切替で驚いた事といえば、
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。
RPGとかで、フィールドからダンジョンや町などに入る/出るときにシーンの切替をするって言うのを聞いた時。
何か自分とはシーンというものの大きさが著しく違うのか、それとも自分が思っているRPGとは違うものなのか。
2008/07/02(水) 23:04:11ID:surY1LL8
システムによっては、フィールドと町の中とではまるっきり違うやつもあるから、
そーゆーんじゃないのん?
そーゆーんじゃないのん?
2008/07/02(水) 23:06:33ID:25mPqNml
まぁドラクエ的な物なら自分もフィールド、街、ダンジョンは同列に扱うかな。
2008/07/02(水) 23:19:07ID:Z+lS9RAU
>>58
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う
P of EAA Application Controller
というのがある、設計によっては使えるかもしれない
シーン遷移の追加よりも修正が多いのなら
可読性を重視して分散しないように書いた方が修正は楽になる、と思う
2008/07/02(水) 23:42:43ID:US3ampRT
俺はステータス画面の中の項目や、更に細かい項目もシーン扱いしちゃうなー
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど
そこまで行くとシーンじゃなくてswitchレベルかもとは思うんだけど
2008/07/02(水) 23:53:44ID:noQk3O5d
サブメニュー系は別で作ってhas関係にしてるな
シーン単一保持だと元シーン内のアニメも止める事になるし(※無論それが前提なら無問題だけど)
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな
シーン単一保持だと元シーン内のアニメも止める事になるし(※無論それが前提なら無問題だけど)
俺の手癖だと、シーンを同時に複数駆動できるようにするとこんがらがる。
結局多態やswitch、Cなら関数ポインタの嵐になって弄りにくくなる一方な感じ。
なんか下手なんだろな
2008/07/02(水) 23:58:28ID:surY1LL8
>67
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。
俺の中では、親/子シーンとか、大(メジャー)/小(マイナー)シーンとか呼んでたりする。あくまでも俺の中だけ。
2008/07/03(木) 03:42:52ID:Z+nUDepW
自分はCだけど、シーン毎にゲームループを作る。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。
フィールド移動、戦闘(コマンド入力)、戦闘(実行)とか。
シーンで必要な分だけ触れる形になるので分かりやすい。
ただ、新しくできてきた言語だと構造的に無理かもしれない。
2008/07/03(木) 12:34:48ID:4VgEaFFX
システムデザインに拘ると、抽象化についてこれないメンバーいるからなぁ・・
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。
ゲームは面白さ追及なんで仕方ない。この辺は妥協しないと。
外人はゲームに限らず抽象化は得意だね。まああっちは人が多いから下のレベルが高いんだろうけど。
2008/07/03(木) 12:38:03ID:e4SGKyy/
>>71
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。
それにアマチュア間で情報をやり取りする開発者のフォーラムとか
あってアマチュアも結構あれこれ知ってるからなあ。
日本って情報でも鎖国常態だから、会社にどっぷりでもない限りは
素人同然でしょ。
2008/07/03(木) 12:49:08ID:ysSgecWy
むしろ日本の問題は、会社の枠で情報が閉ざされがちで、
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。
結果ひとりよがりでフレームワークが洗練されないことに
あると思うわけだが。
2008/07/03(木) 13:01:27ID:aUHHO03G
閉ざしたくて閉ざしているわけでもないと思うんだけどね。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。
情報公開については、企業がそうした活動に意味を見いだせれば
積極的に動くようになると思うがなあ。
75名前は開発中のものです。
2008/07/03(木) 15:05:04ID:qaYiJWl1 それは違うな、設計能力を持つ人間が極めて少数しか世界に存在していない
守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか
守秘義務でコードを公開できなくても、設計に関わる議論ぐらいはできるはず
または公開することもできるだろう
実際は理解できる人がいないから話もできない
システムエンジニアがあんな連中ばかりだから設計が軽視されている
軽視されているから積極的に吸収して学ぶ気持ちを持つものが少なくなる
設計が戦略で、実装が戦術なら
ハッカーは戦術家だな
日本は戦術家ばかりで、戦略を低く評価する傾向にある
その結果、優れた戦術家をかき集めて特攻をかけるバカな頭しかない
力技で戦局を変えることしかできない、それしか方法がないと考える
一つの成功体験にすがり、臨機応変に設計を考えて変えようとしない
他人が使っている新しいものばかりを見て、導入して
仲間内だけで、「俺らって凄くね?」って言ってるだけで
自己満足に浸っている限り何も変わりはしない
道は二つだ
戦略を覆すだけの力を身につけ、力づくで戦局をねじ伏せ続けるか
戦略を考え続けるか
2008/07/03(木) 18:39:02ID:9NkLv6DU
>>75
きもい、長い
きもい、長い
2008/07/03(木) 19:12:29ID:aUHHO03G
2008/07/03(木) 20:24:00ID:odWCpgCc
アメリカと日本じゃ、プログラマの流動性も違う品。
業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。
業界内で名を売って自分の値段を上げて転職するのが王道の国と、
あくまで内部で実績積み上げてくのが主流の国では、プログラマが
社外で情報発信するモチベーションが違う。
2008/07/03(木) 21:55:28ID:DTx5b/+j
外国人すげぇ日本人だめ、みたいなステロタイプの意見が多いな
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
>外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
>まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下(兵隊)の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね
日米で比較した場合、これは産業構造が完全に異なるので
人材・才能の産業別分配比率からしてまるで違うよ。だから
日米の情報関連産業を比較したら日本劣勢となるのは仕方ないよ
>外人はゲームに限らず抽象化は得意
国産虹コンテンツの破壊力を目の当たりにしてそれはないよ
>まああっちは人が多いから下のレベルが高いんだろうけど
PCでQ3AとかUTがバカ売れしていた頃はね。そうだったよ。人数少なかったから。
でも今はだいぶ様相が違うよ。開発中期後期での期間工を大量採用しての
労働集約型闘争の比重が増大して、その成否が勝敗を分けるようになった辺りから
国内大手のそれとあんま変わらなくなった。というか下(兵隊)の素養は日本のが上。
言語障壁さえ無ければ日本の兵隊は米国の開発現場では無敵を誇るよ。
勤勉でサビ残も何のその一日12時間以上文句ひとつ言わずに働くんだから
米国の兵隊は駆逐されるよ。言語障壁さえなければね
2008/07/03(木) 22:23:51ID:DTx5b/+j
>アマチュア間で情報をやり取りする開発者のフォーラムとか
>あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンww」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお(#^ω^)」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏=3Dキチガイの巣窟。日本語圏=虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない
>あってアマチュアも結構あれこれ知ってるからなあ
MODとか好きだから今でも国籍隠してチョコチョコ見たり書き込んだりしてるが
日本のアマチュアを劣等とするほど明瞭な差異は感じない
嗜好の差異は凄まじいが素養・素質はどっこいだよ
「CoD4作りたいですどうすればいいですか」「HL2買ってHammerでもいじってろ」「サーセンww」
みたいなやり取りは沢山ある。日本で言えば「FF作りたいです」「ツクールやってろ」「おっおっお(#^ω^)」と等価。
ただ英語圏vs日本語圏では裾野・人口が圧倒的に違うのでキチガイの数では英語圏に軍配があがる。
それと英語圏=3Dキチガイの巣窟。日本語圏=虹キチガイの巣窟。なのでアマチュアが渇望する知識
アマチュアが尊崇するアマチュア作家はだいぶ違う。単純に比較はできない
2008/07/03(木) 22:25:41ID:4YUvzjZW
ゲーム開発に限った話じゃないけど、長引く不況のせいで日本人は
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。
技術やノウハウを外に出し惜しむ癖が付いちゃってるんだと思うな。
2008/07/03(木) 22:33:05ID:odWCpgCc
>>81
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。
不況かどうかに関係なく、米国の IT 企業はノウハウ流出には厳しいけど。
秘密主義で知られる Google とかさ。
情報を出すことで他社のサービスをつぶせる場合には、積極的に公開しちゃうけど。
2008/07/03(木) 22:46:20ID:4YUvzjZW
ノウハウ流出に厳しいってほんとかよ。
Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、80年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ10年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。
Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
海外では古い商用ゲームのソース公開したりする人達が沢山いる
けど、日本でそういうことやった会社はあんま聞いたことないし
プログラミングの本でも、80年代は日本人が書いた本でも面白い本は
沢山あったのに、ここ10年ぐらいの名著は外人が書いた本の
翻訳本ばっかりの現状考えるとにわかに信じられん。
2008/07/03(木) 22:47:22ID:JMOvob5t
単なる欧米コンプレックスだろ
2008/07/03(木) 22:50:43ID:odWCpgCc
>>83
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。
> Googleなんて論文バンバン出して技術発表してるイメージがあるけどなあ。
当たり障りがないところだけな。
Google が出してる論文は、実証論文が多い。分散システムは理論的には
だいぶ前から研究されているんだが、Google が出してる論文は「それを
使って実際にファイルシステムを作って運用したら、このぐらい性能出たよ」
みたいなやつ。
実装の詳細は公開していないし、細かい数値は「これは出せない」とか平気で
書いてある。
もちろん実証論文にも学術的に価値があるんだが、ノウハウを公開しているの
とはだいぶ違う。読んでも真似できないし。
2008/07/03(木) 22:55:44ID:odWCpgCc
Google の論文は、個人的には就職者ホイホイのような気がしてる。
SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよw
SIGOPS とか USENIX の論文読むような質の高い連中に、ウチに
来るとこんな仕事できるぜーとお誘いかけてる。人材仲介業者に
高い金払うより良い宣伝だよw
2008/07/03(木) 23:05:49ID:1g03RBvk
論文の質・量で言うとMicrosoft Researchのほうがすごくない?
2008/07/04(金) 00:30:18ID:lh91Gh1r
専門知識を蓄えてしまうと、ますます話の合う人間がいなくなりそうな予感。
2008/07/04(金) 05:23:01ID:5KkF19ee
2008/07/04(金) 05:32:42ID:fzMGN+kp
2008/07/04(金) 05:48:08ID:dN9x2gJA
それ、英語の普及範囲を評価してるだけだろ
日本人の英会話力の低さは別問題だよもう
日本人の英会話力の低さは別問題だよもう
2008/07/04(金) 05:56:42ID:KBN1fM3d
米コンプレックスとは世界の「知」が集まる「場」「国家」に対するコンプレックス
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ
こういう感情や危機感を抱く対等の存在は「その他の場」「その他の国家」
一個人は素直により良い「場」の恩恵を享受することができるわけで
情報交換にしたって英語圏MODコミュやゲームデベロッパーのコミュを
覗き見ることに何の拘束も受けないよ。このネットの時代にあって
国家の枠組みや物理的距離は、知的欲求や情報交換を阻害する
主要因では既になくなってるよ。特にアマチュアにとってはこんな恵まれた状況は
90年代半ば以前はなかったわけで、この期に及んで、より良い「場」に距離を感じ
コンプレックスをおぼえるならその正体は言語コンプレックスなんだよ
言語障壁にもがき苦しんで乗り越えたもん勝ち。がんばれ
2008/07/04(金) 05:57:56ID:KBN1fM3d
>>91
かぶったスマンコ
かぶったスマンコ
2008/07/04(金) 06:11:54ID:KBN1fM3d
ところで休暇中に発見した格安で愉快な英語おしゃべり上達法
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ
ネトゲでボイチャ。中毒性の低いFPSとかでVoIP対応してるやつがオヌヌメ
2008/07/04(金) 06:28:19ID:KBN1fM3d
米国の現場における労働集約型闘争が生み出した兵隊の質の低下は
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数の変態テクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる
既に数年前から顕在化しているという話をしたが、適当に日本語ソースをググッてきた
http://slashdot.jp/it/article.pl?sid=07/04/02/2312234
「知」が集まる国といえど開発規模の肥大化で苦しんでる様は日本同様
促成教育で動員された兵隊は待遇面でも基礎素養でも決して恵まれては居ない
理系大卒ないし中退程度の知識を持つ少数の変態テクノギークがブイブイ言わせていた
PC-FPS主流時代とは事情が違ってる
2008/07/04(金) 06:32:14ID:ulIK/zsc
くねくねハニィのコラムによると、
日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか?知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。
日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
ってことらしいぞ。
むしろ海外の方が技術的には閉鎖的なんじゃないか?知らんけど。
少なくとも俺はよそのメーカーを手伝う機会が多いから日本が閉鎖的とは思わんな。
2008/07/04(金) 06:58:00ID:KBN1fM3d
切羽詰って偽装請負みたいなことやっちゃってたりするよな
2008/07/04(金) 08:23:31ID:BChTVd/d
>>96
>日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
>海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
>ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。
>日本は会社の枠に縛られず下請けやフリーのプログラマばんばん使って短期決戦、
>海外は外部の人間は使わず自社内で十分な予算を確保してじっくり練り上げていく、
>ってことらしいぞ。
これは言えてる。
日本のホワイトカラーは、最上位の意思決定者と外注の中継地点にしか過ぎない。
地道な作業をしないことに価値を見出す役人根性が、世の中を席捲している。
2008/07/04(金) 08:49:34ID:BChTVd/d
>>80
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○ 絵(とくに3D)がきれい。
○ 音楽も一般受けする質の高いものが標準。
○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。
日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い(よくできたものもあるが)。
グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
以下を見ると、英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける。
ttp://www.gametunnel.com/
○ 絵(とくに3D)がきれい。
○ 音楽も一般受けする質の高いものが標準。
○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまれている。
パーツを生産する能力は、上位企業の即戦力並だ。
ただし、ゲームとして楽しいのはあまりない気がする。
日本のフリーとかシェアは、ゲームとして楽しいのが少ない上、パーツも陳腐なデザインが多い(よくできたものもあるが)。
グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
100名前は開発中のものです。
2008/07/04(金) 10:11:43ID:pYjEAjeh 最近の家庭用の大規模RPGのデータってどう管理されてるのが多いんですか?
RDBですか?それともタダのファイル?
RDBですか?それともタダのファイル?
101名前は開発中のものです。
2008/07/04(金) 12:41:59ID:tMJHCBTq 普通はゲームデータ制作ツールとゲーム実行エンジンを並行して作っていく。
データはファイルが多い。ゲームデータ制作ツールの仕様にもよるけど、バイナリファイルの場合が多い。
C構造体のバイナリダンプは実装が楽だからね。
PCゲーには、ユーザがテキストファイルを弄ってデータや設定を変えられるものもある。
データはファイルが多い。ゲームデータ制作ツールの仕様にもよるけど、バイナリファイルの場合が多い。
C構造体のバイナリダンプは実装が楽だからね。
PCゲーには、ユーザがテキストファイルを弄ってデータや設定を変えられるものもある。
102名前は開発中のものです。
2008/07/04(金) 13:10:11ID:04Qw9LMa 国単位になるとステレオタイプのイメージに支配されちゃう人っているんだねぇ
103名前は開発中のものです。
2008/07/04(金) 15:33:28ID:eL1SAVRC104名前は開発中のものです。
2008/07/04(金) 20:15:06ID:HsoNh4J4 >>87
> 論文の質・量で言うとMicrosoft Researchのほうがすごくない?
同意。世間じゃGoogleを持て囃すのが流行ってるけど、むしろ
コンピュータサイエンスはMSRのほうがすごい研究者を集めてる。
> 論文の質・量で言うとMicrosoft Researchのほうがすごくない?
同意。世間じゃGoogleを持て囃すのが流行ってるけど、むしろ
コンピュータサイエンスはMSRのほうがすごい研究者を集めてる。
105名前は開発中のものです。
2008/07/05(土) 11:31:29ID:rip3o1Gr106名前は開発中のものです。
2008/07/05(土) 11:38:06ID:rip3o1Gr107名前は開発中のものです。
2008/07/05(土) 11:38:38ID:Def2so2E だめだ、全然話についていけないぜ
108名前は開発中のものです。
2008/07/05(土) 11:41:27ID:qX1NKMBA >>99
> ○ 絵(とくに3D)がきれい。
> ○ 音楽も一般受けする質の高いものが標準。
> ○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまnれている。
ちょwwわかってかいてんのかよww
全部、投入できるリソースの違いで解決できるじゃねーかw
> ○ 絵(とくに3D)がきれい。
> ○ 音楽も一般受けする質の高いものが標準。
> ○ ゲーム中以外のシーン(デモ、オプション設定)が作りこまnれている。
ちょwwわかってかいてんのかよww
全部、投入できるリソースの違いで解決できるじゃねーかw
109名前は開発中のものです。
2008/07/05(土) 11:44:02ID:qX1NKMBA 俺は、海外のインディゲームデベロッパーを結構チェックしているが、
絵がきれー、とか音楽すげーとかってなかなかないよ
それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。
たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり(日本かとおもうけど、海外の話だよ)
絵がきれー、とか音楽すげーとかってなかなかないよ
それこそ、日本でたまに同人ですげえグラでバリバリ3Dなのがでてくる頻度並み。
たまにこれすげえ描き込みだ、とか思ったら現役プロの趣味作品だったり(日本かとおもうけど、海外の話だよ)
110名前は開発中のものです。
2008/07/05(土) 11:44:46ID:qX1NKMBA 連投ごめん、音楽すげーはけっこうあるわw まあ俺がテクノ好きなだけかもしれんけど
111名前は開発中のものです。
2008/07/05(土) 13:29:28ID:E9y2cnx1 雑談スレに移動すべきだと思うけど二つだけ。
そもそも一国と世界を比べることに意味があるのかな。
言語障壁はローカルのコミュニティが栄えない理由にならないよね。
そもそも一国と世界を比べることに意味があるのかな。
言語障壁はローカルのコミュニティが栄えない理由にならないよね。
112名前は開発中のものです。
2008/07/05(土) 20:57:12ID:UjEcMe9W113名前は開発中のものです。
2008/07/05(土) 21:01:08ID:rip3o1Gr 日本の職人はゲームじゃなくて、ニコ動に集ってるだけだろ。
114名前は開発中のものです。
2008/07/05(土) 21:23:48ID:hYTfj9Xn 方向性が違う物を比べても何にも成らないのに
115名前は開発中のものです。
2008/07/06(日) 00:07:36ID:Gwo/Ylg2 >>80だが
>>99
繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。
IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは
なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる
>英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける
>ttp://www.gametunnel.com/
ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか?してないだろ
特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる
(下半身産業が絡んで不公平になるので全年齢のみで比較してもいい)
>日本のフリーとかシェアは(中略)
>グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに
「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい?毎日好きでもないものを延々作らされてる
腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために
真剣に取り組んでるよw素人に八つ当たりする前に自分の胸に手を当てて考えろっての。
あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。
他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが
ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない
弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい
>>99
繰り返すが、趣味者の嗜好の差異が凄まじいと言っているだろう。
IGDA日本の新清士に代表される外国すげぇ日本だめ論のステロタイプアジテーターは
なぜ乱暴な単純比較して優劣を競おうとするのか、FPS大好きの俺でも理解に苦しんでいる
>英語圏の方が日本よりも、アマチュアというかインディーズ(同人)市場が発展しているという印象を受ける
>ttp://www.gametunnel.com/
ところでgametunnelはフリゲのダウンロード数、シェアウェアの販売数を公表してるか?してないだろ
特に後者について公表したらおそらくDLSiteの販売数を遥かに下回るんじゃないかと俺は読んでいる
(下半身産業が絡んで不公平になるので全年齢のみで比較してもいい)
>日本のフリーとかシェアは(中略)
>グローバルな金儲けには関心なく、村市場(コミックマーケット)で満足してしまっている奴が多いんだろうな。
だから、嗜好の差異が凄まじいと言っている。エロゲ塗り紙芝居ADVが大好きだから一生懸命作ってるアマチュアに
「グローバルな金儲けに関心もて」「今すぐFPS作れ」なんて言えるかい?毎日好きでもないものを延々作らされてる
腹いせに素人に因縁付けてるようで感心しないな。だいたいプロの何パーセントがグローバルな金儲けのために
真剣に取り組んでるよw素人に八つ当たりする前に自分の胸に手を当てて考えろっての。
あと、素人に即戦力を問う例のあのアジテーターも異常だ。10年以上前から新卒採用の新人に即戦力なんざ期待してない。
他業界同様、研修・実習・OJT、一から大事に大事に育て上げ戦力化している。N-88BASICマスターだろうがファミベの達人だろうが
ツクラーだろうがデザエモナーだろうがボードゲーム狂いだろうが等しくスタートラインから育て上げてる。それができる体力のない
弱小零細が新卒学生の即戦力がないだのと八つ当たりしてベーマガ2.0が要るだの喚いてるだけ。勝手に滅べと言いたい
116名前は開発中のものです。
2008/07/06(日) 00:20:54ID:Gwo/Ylg2 外国すげぇ日本だめ論が好きな連中は日本の文化を否定する傾向にあってあまり好かん。
アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。
趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。
エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。
世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。
あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい
アマチュアゲーム開発者の嗜好が世界のガラパゴスと呼ばれても気にする必要なし。
趣味に独自文化が形成できるのは豊かさの象徴であって決して恥じるものではない。誇っていい。
エロゲ塗り紙芝居ADV作家は大挙してgametunnelに突撃するくらいの自信を持っていい。
世界に比類の無いコミケのような巨大なヲタ祭を村市場などと自虐に走る連中は無視しろ。
あんだけカネと人が動く趣味野郎の祭典が開けるのは豊かさと根暗パワーの象徴だ。誇っていい
117名前は開発中のものです。
2008/07/06(日) 00:32:11ID:ADZbZeYt 日本人はどちらかといえば何か分からんが動いたから良いやって人が多
い気がするね。
昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ
てるって何かの本に書いてた気がしないでもない。
SEやらPGやってる人なら分かると思うけど「なんで?どういうこと?」っていう
のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア
には向かないと思う。
まぁ外人云々じゃなくて正確か??
い気がするね。
昔から日本人は抽象的な概念は強いけど具体的な概念に弱いって言われ
てるって何かの本に書いてた気がしないでもない。
SEやらPGやってる人なら分かると思うけど「なんで?どういうこと?」っていう
のを突き詰めてちゃんと答えが出ないと気が狂いそうになる人じゃないとエンジニア
には向かないと思う。
まぁ外人云々じゃなくて正確か??
118名前は開発中のものです。
2008/07/06(日) 00:33:49ID:Gwo/Ylg2 ただし、技術屋を志向する趣味プログラマは技術的ガラパゴス状態に陥ったら負けだな。
この点だけは外国すげぇ日本だめ論を展開するアジテーター共の意見に一理ある。
お国柄のせいか虹派が多数派の我が国ではアマチュアプログラマに要求される
技術水準はそれほど高くはない。それはそれでいいのだが、その技術ガラパゴスの中で
タスクシステム知ってる俺tuee状態とかになっては格好が悪い。俺tueeする時はもっと
見識を広めたほうが良い
この点だけは外国すげぇ日本だめ論を展開するアジテーター共の意見に一理ある。
お国柄のせいか虹派が多数派の我が国ではアマチュアプログラマに要求される
技術水準はそれほど高くはない。それはそれでいいのだが、その技術ガラパゴスの中で
タスクシステム知ってる俺tuee状態とかになっては格好が悪い。俺tueeする時はもっと
見識を広めたほうが良い
119名前は開発中のものです。
2008/07/06(日) 00:34:25ID:Gwo/Ylg2 >>117
かぶったスマン
かぶったスマン
120名前は開発中のものです。
2008/07/06(日) 00:34:55ID:7QhD5OiR 熱く語ってもらってるとこ悪いけどお前らスレ違いだ
121名前は開発中のものです。
2008/07/06(日) 00:42:02ID:Gwo/Ylg2122名前は開発中のものです。
2008/07/06(日) 00:44:51ID:VtZ5ywY1 >>115
>腹いせに素人に因縁付けてるようで感心しないな。
感じやすいんだな。
一つ俺が言いたいのはさ、スキルがあるんだったら、
小規模ながらもグローバルな金儲け(変な言葉だ)に挑戦すること考えた方が、
面白えんじゃねえのってことだよ。
自身の嗜好に自信がないって?
じゃあ、そいつは一体何をやっているんだ。
>腹いせに素人に因縁付けてるようで感心しないな。
感じやすいんだな。
一つ俺が言いたいのはさ、スキルがあるんだったら、
小規模ながらもグローバルな金儲け(変な言葉だ)に挑戦すること考えた方が、
面白えんじゃねえのってことだよ。
自身の嗜好に自信がないって?
じゃあ、そいつは一体何をやっているんだ。
123名前は開発中のものです。
2008/07/06(日) 00:48:46ID:mek7cAwO スレ違いだボケども
124名前は開発中のものです。
2008/07/06(日) 01:43:19ID:D1fZ4Z3G > SEやらPGやってる人なら分かると思うけど
PG以外がこのスレに居るのかと問い詰める必要があるな
PG以外がこのスレに居るのかと問い詰める必要があるな
125名前は開発中のものです。
2008/07/06(日) 07:26:44ID:XCulGsMF すみません。話を脱線させた一人です。。。
小さな会社でケータイゲー作ってる業界人です。底辺です。分かってます
俺も職場の仲間はみんなゲーム専門学校卒です。
英語とか読めないしGPGの日本語版も難しすぎてわからないので
や○う○おさんの本とかCマガのタスク記事が職場のバイブルです。
某スレでタスクシステムが馬鹿にされて自棄になってて
俺の職場のレベルが低いのはきっと日本の閉鎖性のせいだと
考えるようになってました。
だってPS3とか箱○のゲーム作ってるクライアント(大手です)は
自分たちのノウハウを俺ら底辺には絶対教えてくれないし。。。
発注したケータイゲーをおとなしく作ってろって感じの扱いです。。。
ぜんぜん頭よくなれそうにない知育ゲーとか糞つまんねー
クイズものばっかり作らされて気が狂いそうです。。。
小さな会社でケータイゲー作ってる業界人です。底辺です。分かってます
俺も職場の仲間はみんなゲーム専門学校卒です。
英語とか読めないしGPGの日本語版も難しすぎてわからないので
や○う○おさんの本とかCマガのタスク記事が職場のバイブルです。
某スレでタスクシステムが馬鹿にされて自棄になってて
俺の職場のレベルが低いのはきっと日本の閉鎖性のせいだと
考えるようになってました。
だってPS3とか箱○のゲーム作ってるクライアント(大手です)は
自分たちのノウハウを俺ら底辺には絶対教えてくれないし。。。
発注したケータイゲーをおとなしく作ってろって感じの扱いです。。。
ぜんぜん頭よくなれそうにない知育ゲーとか糞つまんねー
クイズものばっかり作らされて気が狂いそうです。。。
126名前は開発中のものです。
2008/07/06(日) 07:43:01ID:XCulGsMF 日経のサイトのベーマガ2.0の記事も読んでました。
ベーマガがどんなものか実は知らないのですが日本の
アマゲーコミュニティがないから悪いって言ってたので
我が意を射たりって感じでした。
土日スレで投稿してましたがいつも荒らされてました。
PCゲーム板のフリゲ厨とか氏ねと思ってました
俺は今もDirect3Dとかわけわかんないです。そういうのを
教えてくれるベーマガみたいなものに出会えなかったから
ファミ通の特集記事のゲーム専門学校すごいと思って
高校の先生の反対を押し切ってゲーム専門学校に行きました。
でも専門学校の講師も3D苦手でした。
おまえらには3D無理だから2Dで卒業制作作れって言われたので
言う通りにしました。今思えば先生が分からないもの作られると
質問されても答えられないから嫌だったんだと思います。
ゲーム専門学校に行ったことをすごく後悔してます。
ファミ通氏ねと思いました。きっとベーマガがあれば俺の人生
違ってたかもと思いました。やっぱおまえらが悪い
ベーマガがどんなものか実は知らないのですが日本の
アマゲーコミュニティがないから悪いって言ってたので
我が意を射たりって感じでした。
土日スレで投稿してましたがいつも荒らされてました。
PCゲーム板のフリゲ厨とか氏ねと思ってました
俺は今もDirect3Dとかわけわかんないです。そういうのを
教えてくれるベーマガみたいなものに出会えなかったから
ファミ通の特集記事のゲーム専門学校すごいと思って
高校の先生の反対を押し切ってゲーム専門学校に行きました。
でも専門学校の講師も3D苦手でした。
おまえらには3D無理だから2Dで卒業制作作れって言われたので
言う通りにしました。今思えば先生が分からないもの作られると
質問されても答えられないから嫌だったんだと思います。
ゲーム専門学校に行ったことをすごく後悔してます。
ファミ通氏ねと思いました。きっとベーマガがあれば俺の人生
違ってたかもと思いました。やっぱおまえらが悪い
127名前は開発中のものです。
2008/07/06(日) 07:59:00ID:XCulGsMF すみません。ついカッとなってまたスレ違いのこと書いちゃいました
消えます
消えます
128名前は開発中のものです。
2008/07/06(日) 08:43:38ID:S3/2UtrA ネタじゃなかったら真面目に一度精神科に行くべき。
明らかに躁鬱の傾向が見て取れる。
過度のストレスで脳に器質的な損傷が出来てるかもしれん。
明らかに躁鬱の傾向が見て取れる。
過度のストレスで脳に器質的な損傷が出来てるかもしれん。
129名前は開発中のものです。
2008/07/06(日) 09:01:33ID:VtZ5ywY1 >>123
何も語れない馬鹿よりはマシ。
何も語れない馬鹿よりはマシ。
130名前は開発中のものです。
2008/07/06(日) 09:28:24ID:I4JuM713 まあ、消えなくていいからまた、スレ違いじゃなくてよさげな情報あったら教えてくれよ
131名前は開発中のものです。
2008/07/06(日) 10:03:51ID:4WjvpweZ132名前は開発中のものです。
2008/07/06(日) 13:03:17ID:cXpJQpiz tunnelでおすすめのゲームを教えてkれ
133名前は開発中のものです。
2008/07/06(日) 15:04:16ID:ZiAdcqL1 VIPから来ました
ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて
ギャルゲひっさげて殴り込んで欲しいリア充外人サイトがあると聞いて
134名前は開発中のものです。
2008/07/06(日) 16:19:57ID:le8Gr2pO いや、作者じゃないと殴り込めないわけだが
135名前は開発中のものです。
2008/07/06(日) 16:49:47ID:NhLrwJLQ おかしな奴の言い分もわかるぜ
日本の企業は総じて、コミュニケーション能力だのなんだの
わけのわからない能力やノウハウを好んでそれを要求するくせに
それらを他人に教えるようなことはしないからな、ヒントすらも
異常なほど排他的だ
数年前に某大作RPGの下請けの社長様が
「3Dできる奴なんて腐るほどいる死ね、コミュニケーション能力のない奴は死ね」(意訳)
って新聞記事に載せてたの思い出した
笑える、うひゃ
日本の企業は総じて、コミュニケーション能力だのなんだの
わけのわからない能力やノウハウを好んでそれを要求するくせに
それらを他人に教えるようなことはしないからな、ヒントすらも
異常なほど排他的だ
数年前に某大作RPGの下請けの社長様が
「3Dできる奴なんて腐るほどいる死ね、コミュニケーション能力のない奴は死ね」(意訳)
って新聞記事に載せてたの思い出した
笑える、うひゃ
136名前は開発中のものです。
2008/07/06(日) 17:01:01ID:a3zGOuXr マ板でやれっつの
あーあ
あーあ
137名前は開発中のものです。
2008/07/06(日) 17:06:30ID:NhLrwJLQ ほらクソども設計について語れや
レイヤスーパータイプは
class Devicer { static Device device; }
で、スーパークラスとしてDevicerを使うことだ覚えとけ
Application Controllerは
class AP {
View GetView(入力と状態値);
Command GetCommand(入力と状態値);
}
引数に入力情報や状態を判断する値を入力すると
それに適したViewやModelに対するCommandを返すものだ
覚えておけ、クソども
レイヤスーパータイプは
class Devicer { static Device device; }
で、スーパークラスとしてDevicerを使うことだ覚えとけ
Application Controllerは
class AP {
View GetView(入力と状態値);
Command GetCommand(入力と状態値);
}
引数に入力情報や状態を判断する値を入力すると
それに適したViewやModelに対するCommandを返すものだ
覚えておけ、クソども
138名前は開発中のものです。
2008/07/06(日) 17:44:48ID:bleemPMj みんな独自のウィンドウマネージャー(画面管理)クラス作ってるのかなあ
139名前は開発中のものです。
2008/07/06(日) 22:29:37ID:mQf6Jrcq140名前は開発中のものです。
2008/07/06(日) 22:41:15ID:NhLrwJLQ シーン遷移をきれいに実装したいという話なら、俺は否定するぞ
ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる
やるんだったら他の部分に影響を及ぼさない程度にしておけ
無意味に分断しすぎて複雑にするな
ジャンルにもよるが大抵のゲームで使うシーンは、多くてもせいぜい十にも満たない数だ
この規模の小さい状態遷移を、そのまま適当に実装してもとくに肥大しない
後で追加が頻繁に発生するとも思えない、適当に修正しても特に難しくはならない
こういう部分に、色々な知恵を絞ったコードを書くことに意味はない
逆にそのクラスの為に他の部分にしわ寄せが行って、
難しいロジック部分や画面描画部分に関係のないシーン遷移のコードが入り込む
無駄に依存関係が発生し複雑になる、遷移するためのコードが分散して修正が難しくなる
やるんだったら他の部分に影響を及ぼさない程度にしておけ
無意味に分断しすぎて複雑にするな
141名前は開発中のものです。
2008/07/06(日) 23:15:17ID:bOQhFRQW142名前は開発中のものです。
2008/07/06(日) 23:34:33ID:NhLrwJLQ >>141
同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな
同感だ
そういう箇所に擬似コルーチンを使ってる
前はState使ってたが、あれは追加には強いが変更に弱いな、複雑になって死んだ
単純ならそのまま状態変数で適当に書いてもいいが
コルーチンのほうが書いてて楽しいな
143名前は開発中のものです。
2008/07/06(日) 23:47:58ID:bleemPMj 状態が変わる時は自滅させてから、見た目同じで中身は別の敵オブジェクトを生成するとか。
144名前は開発中のものです。
2008/07/07(月) 00:57:38ID:FUQ1BpEu >擬似コルーチン
浅学な俺にコレについて詳しく
浅学な俺にコレについて詳しく
145名前は開発中のものです。
2008/07/07(月) 04:37:03ID:ohkg3t4w >>144
以前けっこう調べた俺がコレについて詳しく
コルーチン
並列実行をさせない(できない)スレッドのこと。外国人はコーディングの際 coro と略すこと多し。
メリットは、排他処理が不要、ネイティブスレッドに比べてコンテキスト切り替えが軽い(もちろん実装次第だが)。
デメリットは、切り替えタイミングをプログラマが指示する必要がある、CPUがデュアルコアでも恩恵が受けられない。
最近ゲーム関係でよく聞くようになったが、アルゴリズム的にはすんごく昔のクヌース本にも載っているらしい。
マイクロスレッド、協調的マルチスレッド、ファイバー(Windowsのみ)、などの言い方があるが、
ゲーム業界ではコルーチンが一般的かな?
ネイティブスレッドではないので擬似的なスレッドと言えるが、「擬似スレッド」という呼び方は
よく混乱を招くようなのでお勧めしない(後述するように、スレッドを擬似的に再現する手法は他にもある)。
Cで実装する場合は、たいてい手動でスタックポインタを切り替えることで実現する。
主な実装:
アセンブリで実装:作成難度高、コンパイラ依存、移植性なし、使い手にもスキルが必要(スタック溢れ対策など)
大域ジャンプで実装:作成難度中、コンパイラ依存、やや制限がある
スクリプトで実装:スクリプトのVM(例えばLuaやSquirrel)に任せる。使うのは簡単で制限も少ない
擬似コルーチン
コルーチンっぽいことを擬似的にやること(を、>>141は言っているのだと思われる)。
主な実装:
マクロで実装:作成難度低、移植性高い、制限多い、読み手には超分かりずらい
感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。
以下は直接関係ないので、混乱するようなら読み飛ばして。
・昔のMacOSやWindowsで言うところの「プリエンプティブでない」マルチタスクの仕組みは、コルーチンの親戚。
・RubyやPythonのスレッドも、一般的な実装ではネイティブスレッドではなく擬似的なスレッドらしいが、
明示的にコンテキスト切り替えを行うわけではないのでコルーチンとは異なる。
Javaではこのような擬似的に実装したスレッドをネイティブスレッドに対してグリーンスレッドと呼ぶ。
以前けっこう調べた俺がコレについて詳しく
コルーチン
並列実行をさせない(できない)スレッドのこと。外国人はコーディングの際 coro と略すこと多し。
メリットは、排他処理が不要、ネイティブスレッドに比べてコンテキスト切り替えが軽い(もちろん実装次第だが)。
デメリットは、切り替えタイミングをプログラマが指示する必要がある、CPUがデュアルコアでも恩恵が受けられない。
最近ゲーム関係でよく聞くようになったが、アルゴリズム的にはすんごく昔のクヌース本にも載っているらしい。
マイクロスレッド、協調的マルチスレッド、ファイバー(Windowsのみ)、などの言い方があるが、
ゲーム業界ではコルーチンが一般的かな?
ネイティブスレッドではないので擬似的なスレッドと言えるが、「擬似スレッド」という呼び方は
よく混乱を招くようなのでお勧めしない(後述するように、スレッドを擬似的に再現する手法は他にもある)。
Cで実装する場合は、たいてい手動でスタックポインタを切り替えることで実現する。
主な実装:
アセンブリで実装:作成難度高、コンパイラ依存、移植性なし、使い手にもスキルが必要(スタック溢れ対策など)
大域ジャンプで実装:作成難度中、コンパイラ依存、やや制限がある
スクリプトで実装:スクリプトのVM(例えばLuaやSquirrel)に任せる。使うのは簡単で制限も少ない
擬似コルーチン
コルーチンっぽいことを擬似的にやること(を、>>141は言っているのだと思われる)。
主な実装:
マクロで実装:作成難度低、移植性高い、制限多い、読み手には超分かりずらい
感じを掴むには、LuaかSquirrelでコルーチンを触ってみるのが一番手っ取り早いと思う。
以下は直接関係ないので、混乱するようなら読み飛ばして。
・昔のMacOSやWindowsで言うところの「プリエンプティブでない」マルチタスクの仕組みは、コルーチンの親戚。
・RubyやPythonのスレッドも、一般的な実装ではネイティブスレッドではなく擬似的なスレッドらしいが、
明示的にコンテキスト切り替えを行うわけではないのでコルーチンとは異なる。
Javaではこのような擬似的に実装したスレッドをネイティブスレッドに対してグリーンスレッドと呼ぶ。
146名前は開発中のものです。
2008/07/07(月) 07:19:25ID: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;
:
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:47ID:1RaeXbIY ミスった orz
for (i = 0; i < 100; i++) {
GoToLeft(); yield;
}
for (i = 0; i < 100; i++) {
GoToRight(); yield;
}
:
for (i = 0; i < 100; i++) {
GoToLeft(); yield;
}
for (i = 0; i < 100; i++) {
GoToRight(); yield;
}
:
148名前は開発中のものです。
2008/07/07(月) 07:24:44ID:1RaeXbIY コルーチンは、タスクシステム総合スレで話題が出てたね
149名前は開発中のものです。
2008/07/07(月) 08:00:36ID:FUQ1BpEu あー、マイクロスレッドのことか!
それなら一応分かるような気がしないでもない
でもC++じゃあ無理だよね・・・
それなら一応分かるような気がしないでもない
でもC++じゃあ無理だよね・・・
150名前は開発中のものです。
2008/07/07(月) 08:00:37ID:0ql4peFo fiber?
151名前は開発中のものです。
2008/07/07(月) 09:17:09ID:1RaeXbIY152名前は開発中のものです。
2008/07/07(月) 10:04:53ID:BeipJAsv コンパイラ依存じゃなくてアーキテクチャ依存だ。
setjmp()でコンテキストを保存したあと、保存したコンテキストの
スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。
C++だけで実装可能だぞっと。
setjmp()でコンテキストを保存したあと、保存したコンテキストの
スタックポインタとリターンアドレスを書き換えてlongjmp()で戻すだけ。
C++だけで実装可能だぞっと。
153名前は開発中のものです。
2008/07/07(月) 13:31:17ID:yE1V62Sc fiberはRubyでも使われてるよ
スレッド(糸)より細いものだからファイバ(繊維)
あとJavaScriptにも1.7から導入されてるぜい
スレッド(糸)より細いものだからファイバ(繊維)
あとJavaScriptにも1.7から導入されてるぜい
154名前は開発中のものです。
2008/07/07(月) 22:11:23ID:oT4ePMXj マイクロスレッドは理想だけどそこまでトリッキーなことやる踏ん切りが付かない
155名前は開発中のものです。
2008/07/07(月) 22:26:27ID:yE1V62Sc やっぱスクリプト以外ではやる気しないな
156名前は開発中のものです。
2008/07/07(月) 22:30:56ID:nV3j1Oo/ タスクシステムはコルーチン実装の一つだね
157名前は開発中のものです。
2008/07/07(月) 23:47:06ID:ZC8HSbxq コルーチンの「コ」って子供の子って意味じゃないよね?
158名前は開発中のものです。
2008/07/08(火) 00:00:56ID:2Ffcfnsn cooperativeと一緒のco-だろ?
159名前は開発中のものです。
2008/07/08(火) 01:20:29ID:DPfKtgJc 俺はオブジェクト指向で、シングルスレッドだな。
常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。
また一方で、オブジェクト発生イベントのリストを持っていて、
順次、メインループにオブジェクトが登録されていく。
この「オブジェクト発生イベントのリスト」はシーンに相当していて、
シーンを切替えたければ、今登録されているオブジェクトを破棄して、
イベントのリストを差し替えるだけでいい。
while (1) {
for i=0...
{
オブジェクト[i]->行動();
オブジェクト[i]->描画();
オブジェクト[i]->当たり判定();
}
イベント発生()
}
常にメインループ内で、オブジェクトの描画、行動、当たり判定が行われてる。
また一方で、オブジェクト発生イベントのリストを持っていて、
順次、メインループにオブジェクトが登録されていく。
この「オブジェクト発生イベントのリスト」はシーンに相当していて、
シーンを切替えたければ、今登録されているオブジェクトを破棄して、
イベントのリストを差し替えるだけでいい。
while (1) {
for i=0...
{
オブジェクト[i]->行動();
オブジェクト[i]->描画();
オブジェクト[i]->当たり判定();
}
イベント発生()
}
160名前は開発中のものです。
2008/07/08(火) 17:13:03ID:8FRUZW5m >>159
PACに似てるが違う、オブジェクトの追加に強そうだが
そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感
ドメインロジックのテストを行うときにビューが関わってくる
逆にビューのテストを行うときにドメインロジックが関わってくるため
テストに多大な労力がかかる事が予想される
常にプログラム全体をテストしなければならないため、試行錯誤すると死ねる
render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き
2Dにしても描画に関する処理が単純でなければうまく動かないだろう
規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め
または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め
私はお勧めしない、追加のメリットが多大である場合は考慮に値するが
ゲームには不向きだと思う、特に3Dの場合は
俺は怖くて使えない
PACに似てるが違う、オブジェクトの追加に強そうだが
そのメリットの恩恵が受けられない場合に死ぬほど複雑になる予感
ドメインロジックのテストを行うときにビューが関わってくる
逆にビューのテストを行うときにドメインロジックが関わってくるため
テストに多大な労力がかかる事が予想される
常にプログラム全体をテストしなければならないため、試行錯誤すると死ねる
render target等の処理が俺にはすぐに思いつかない、よって3Dには不向き
2Dにしても描画に関する処理が単純でなければうまく動かないだろう
規模が小さいプログラムを無駄に複雑にしてすごそうに見せたい人にお勧め
または、意味もなく多機能オブジェクトをリストに突っ込んで管理したい人にお勧め
私はお勧めしない、追加のメリットが多大である場合は考慮に値するが
ゲームには不向きだと思う、特に3Dの場合は
俺は怖くて使えない
161名前は開発中のものです。
2008/07/08(火) 17:19:39ID:8FRUZW5m162名前は開発中のものです。
2008/07/08(火) 22:56:21ID:8FRUZW5m 小規模な状態遷移の実装は
今持ってる手で四つ
1.擬似コルーチン
2.スレッド
3.スクリプトで隠蔽したスレッド
4.通常の状態変数による管理(State含む)
設計が明確でない初期のもの、プロトタイプ
又は小規模な場合の初期のとりあえず書いておくコードに向いているのは
擬似コルーチン又は状態変数だろう
まだ設計方針が明確に決まっていない場合や試行錯誤しなければならない状態で
スレッドやスクリプトの導入を決めるのは早すぎる、リスクが大きい
ある程度、方針が固まってから適切なものを選択するのがいいだろう
状態変数での管理が大手を振っているのも
初期コストが低いという部分が大きい
このため、状態変数やState以外の選択肢は簡単には普及しないだろう
ただし、スレッドの積極的採用が処理速度向上に繋がるのならその限りではない
今持ってる手で四つ
1.擬似コルーチン
2.スレッド
3.スクリプトで隠蔽したスレッド
4.通常の状態変数による管理(State含む)
設計が明確でない初期のもの、プロトタイプ
又は小規模な場合の初期のとりあえず書いておくコードに向いているのは
擬似コルーチン又は状態変数だろう
まだ設計方針が明確に決まっていない場合や試行錯誤しなければならない状態で
スレッドやスクリプトの導入を決めるのは早すぎる、リスクが大きい
ある程度、方針が固まってから適切なものを選択するのがいいだろう
状態変数での管理が大手を振っているのも
初期コストが低いという部分が大きい
このため、状態変数やState以外の選択肢は簡単には普及しないだろう
ただし、スレッドの積極的採用が処理速度向上に繋がるのならその限りではない
163名前は開発中のものです。
2008/07/08(火) 23:04:46ID:gy2iNnCl コルーチンで擬似ってどういうこと?
164名前は開発中のものです。
2008/07/08(火) 23:41:41ID:8FRUZW5m >>163
擬似じゃなくていいのか、訂正
1.コルーチン、又は擬似のそれ
言語仕様に含まれてるときはそのままコルーチンとして呼び出し
c/c++の場合は以下のものが使える、又は自分で作る
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
それ以外なら
ソースコードを変換するプログラムでも作る
gotoやthrowやswitchやラベルなんかが含まれない言語では無理、又は面倒くさい
擬似じゃなくていいのか、訂正
1.コルーチン、又は擬似のそれ
言語仕様に含まれてるときはそのままコルーチンとして呼び出し
c/c++の場合は以下のものが使える、又は自分で作る
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
それ以外なら
ソースコードを変換するプログラムでも作る
gotoやthrowやswitchやラベルなんかが含まれない言語では無理、又は面倒くさい
165名前は開発中のものです。
2008/07/08(火) 23:46:18ID:iq4s5004 まぁいいけど、ライセンスがGPLで良けりゃこっちを使おうぜ。
ttp://www.xmailserver.org/libpcl.html
ttp://www.xmailserver.org/libpcl.html
166名前は開発中のものです。
2008/07/09(水) 01:10:17ID:vZNCPgy9 言語機能として付いてないC++で無理やんこやるのはいろいろ怖い気が
すんごい便利そうなんだけどなぁ・・・
すんごい便利そうなんだけどなぁ・・・
167名前は開発中のものです。
2008/07/09(水) 07:23:21ID:eQNI5n3r そこまでするならスクリプト組み込んだほうが
よっぽど安全で楽だと思うけどな
よっぽど安全で楽だと思うけどな
168名前は開発中のものです。
2008/07/09(水) 09:40:38ID:nYED4jrh >>162
スレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。
>小規模な状態遷移の実装
>>146のような、行動予約の状態遷移を前提にしているのかな。
だとしたら、もっぱら自分は、C++で、
>4.通常の状態変数による管理(State含む)
と動作制御用独自スクリプトだな。
基本は、ゲーム開発で言うところのタスクシステムで処理。
各オブジェクトは、単一クラス中に、状態ごとに処理関数(メンバ関数)を用意する。
フレーム毎に、その時点の状態に該当する処理関数を、1回ずつ呼び出す。
その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。
状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。
動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。
表現くどいけど、悪しからず。
スレッドっていう言葉は聞いたことあるが、実装手法は、全く聞いたことが無いな。
>小規模な状態遷移の実装
>>146のような、行動予約の状態遷移を前提にしているのかな。
だとしたら、もっぱら自分は、C++で、
>4.通常の状態変数による管理(State含む)
と動作制御用独自スクリプトだな。
基本は、ゲーム開発で言うところのタスクシステムで処理。
各オブジェクトは、単一クラス中に、状態ごとに処理関数(メンバ関数)を用意する。
フレーム毎に、その時点の状態に該当する処理関数を、1回ずつ呼び出す。
その関数中で、動作制御用独自スクリプトの解釈処理も行い、適宜、処理関数を切り替える。
状態毎の処理関数は、メンバ関数ポインタ配列を通じて、インターフェースを切り替える。
動作制御用独自スクリプト解釈込みの処理関数を、継承用テンプレート・クラス中に実装。
表現くどいけど、悪しからず。
169名前は開発中のものです。
2008/07/09(水) 17:57:35ID:7MZGZOjk 巣に帰れ
タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50
おまえらタスクシステム信者がクソでカスでゴミクズな理由は
自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ
または、それを考えようとしないところだ
ただ使えばいいと思い込んで、それで完結している
考えることを放棄したおまえらに設計能力を向上する機会はない
戦略のない戦術はただのテロだ
タスクシステム総合スレ part2
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/l50
おまえらタスクシステム信者がクソでカスでゴミクズな理由は
自分が書いてるコードにどんなメリットとデメリットがあるかを理解できてないところだ
または、それを考えようとしないところだ
ただ使えばいいと思い込んで、それで完結している
考えることを放棄したおまえらに設計能力を向上する機会はない
戦略のない戦術はただのテロだ
170名前は開発中のものです。
2008/07/09(水) 18:38:12ID:vZNCPgy9 ひどいな・・・
なんでそんな暴言が吐けるの
なんでそんな暴言が吐けるの
171名前は開発中のものです。
2008/07/09(水) 18:47:18ID:vvjjLorC 良く知らんがタスクシステムって言葉が出ると荒れるようだ
なんかそういうgdgdな経緯でもあったんだろうな
なんかそういうgdgdな経緯でもあったんだろうな
172名前は開発中のものです。
2008/07/09(水) 18:55:55ID:nYED4jrh173名前は開発中のものです。
2008/07/09(水) 18:56:55ID:iC3IHDcB >>171
ゲーム業界の造語みたいなものだからな。
OS屋に言わせると「なにそれ?プ」というものらしい。
まあ一定60FPSとか30FPSといったフレームで常に動いてて
物の動きとか制御してるのがOSがタスクを処理してるのに見えるから
そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人
が言い始めたのそもそもらしい
ゲーム業界の造語みたいなものだからな。
OS屋に言わせると「なにそれ?プ」というものらしい。
まあ一定60FPSとか30FPSといったフレームで常に動いてて
物の動きとか制御してるのがOSがタスクを処理してるのに見えるから
そういう風に業界の人間かゲーム評論家か自称ゲーム評論家の素人
が言い始めたのそもそもらしい
174名前は開発中のものです。
2008/07/09(水) 19:21:37ID:eQNI5n3r やっぱり顔真っ赤にして噛み付くヤツが出ると思ったよ
しょうがないからその辺の単語は誤魔化して話進めてくれ
いつまで経っても話進まねーからな
しょうがないからその辺の単語は誤魔化して話進めてくれ
いつまで経っても話進まねーからな
175名前は開発中のものです。
2008/07/09(水) 19:22:14ID:anjhk7B8 名前負けしてるよね、完全に。
176名前は開発中のものです。
2008/07/09(水) 21:10:22ID:7MZGZOjk 話が進むわけないだろ
言ってる奴が、メリットもデメリットも把握していないんだから
ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない
宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
誰かこれを理解してみろクソが
言ってる奴が、メリットもデメリットも把握していないんだから
ただ難しそうな言葉が並んでいるだけで、それ以上の意味はない
宇宙の力がイオン水に影響を与えてゲーム脳がゲルマニウムパワーに還元されるんだよ
誰かこれを理解してみろクソが
177名前は開発中のものです。
2008/07/09(水) 21:12:45ID:iC3IHDcB 噛み付いてはないけど・・すまんな
まあ俺的にはそんな何とかシステム(自称)はどうでもいいよ。
市販のゲームでも売り出す際は自称xxxシステム採用とかいう
元からそういうの好きな業界だし。
まあ俺的にはそんな何とかシステム(自称)はどうでもいいよ。
市販のゲームでも売り出す際は自称xxxシステム採用とかいう
元からそういうの好きな業界だし。
178名前は開発中のものです。
2008/07/09(水) 21:30:52ID:4OXXlyYN179名前は開発中のものです。
2008/07/09(水) 22:16:56ID:EYwlC03l 「面白いこと書いた」と思ってるんだろうなぁ。
端からはただのバカにしか見えてないけどね。
端からはただのバカにしか見えてないけどね。
180名前は開発中のものです。
2008/07/09(水) 22:19:25ID:SF8ehHxO181名前は開発中のものです。
2008/07/09(水) 22:22:48ID:uQp1o0/n タスクシステムってゲームプログラミング固有のもんじゃなくて
リアルタイムOSとか便利なもんがなかった時代の組み込みシステム開発に
起源があるような気がする。
まあ、C++で真っ当にオブジェクト指向やってれば、こんな古臭いもんを
有難がる必要はないと思う。
リアルタイムOSとか便利なもんがなかった時代の組み込みシステム開発に
起源があるような気がする。
まあ、C++で真っ当にオブジェクト指向やってれば、こんな古臭いもんを
有難がる必要はないと思う。
182名前は開発中のものです。
2008/07/09(水) 22:23:19ID:iC3IHDcB >>180
そりゃ・・・その辺はがんばって勉強して
キューだとかスレッドだとかタスクだとか
タイムスライスだとか
まあ同時に複数のものが動いてる(ように処理してる)風に出来るものかな
乱暴な言い方だけど。
そりゃ・・・その辺はがんばって勉強して
キューだとかスレッドだとかタスクだとか
タイムスライスだとか
まあ同時に複数のものが動いてる(ように処理してる)風に出来るものかな
乱暴な言い方だけど。
183名前は開発中のものです。
2008/07/09(水) 22:24:41ID:7MZGZOjk そろそろ潮時か
君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった
有益だったぜw
また暇なときに挑発に乗ってやる
この完璧な捨て台詞を覚えておけよ
君らのレベルから比較して自分のレベルがどの程度低いのかがよくわかった
有益だったぜw
また暇なときに挑発に乗ってやる
この完璧な捨て台詞を覚えておけよ
184名前は開発中のものです。
2008/07/09(水) 22:48:57ID:XmNOce7Z >>183
巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。
感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。
会社でタスクシステムで組みたいと同僚が言ったとして、
烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。
ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。
巣に帰れとか言うけど、君の方がタスクシステムスレの流れを持ち込んでるようにしか見えない。
感情的にならずに、なぜいけないのか説明すればいいだけだと思うよ。
会社でタスクシステムで組みたいと同僚が言ったとして、
烈火の如く怒っても、自分が不利になるだけじゃなく、なぜ駄目なのかを分からせることも難しいだろ。
ここは、「現代的な設計ではそれは無い。なぜなら・・・」と話を進めるべきじゃないかな。
185名前は開発中のものです。
2008/07/09(水) 23:14:23ID:nYED4jrh >7MZGZOjk
なんというか、要するに、
ただの孤独なレス乞食。
もしくはタスク・スレへの誘導係。
マンネリだな。
効率的な挑発方法については、再考した方がいい。
なんというか、要するに、
ただの孤独なレス乞食。
もしくはタスク・スレへの誘導係。
マンネリだな。
効率的な挑発方法については、再考した方がいい。
186名前は開発中のものです。
2008/07/09(水) 23:17:00ID:md3RJLJr タスクスレに託すか。
187名前は開発中のものです。
2008/07/09(水) 23:26:06ID:30d6bQh7 コードが繁雑になって来たので、大革命を起こしたら
以前より良い設計ができない上に、収集がつかなくなった。
svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。
以前より良い設計ができない上に、収集がつかなくなった。
svnさんにお願いして、前のリビジョンに戻る日が近くないことを祈るばかりだ。
188名前は開発中のものです。
2008/07/09(水) 23:50:08ID:XmNOce7Z189名前は開発中のものです。
2008/07/10(木) 00:33:17ID:rFEYqRAa190名前は開発中のものです。
2008/07/10(木) 00:51:19ID:A+tXgG+V >>180
タスクスレの話題を続けるのはよくなさそうなので情報だけ
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/456
OSだからできることを思いっきり使ってるんで
管理手法以外はあまり参考にならんよ。
OS自体に興味があるならOS板にいくといいよ
タスクスレの話題を続けるのはよくなさそうなので情報だけ
http://pc11.2ch.net/test/read.cgi/gamedev/1196711513/456
OSだからできることを思いっきり使ってるんで
管理手法以外はあまり参考にならんよ。
OS自体に興味があるならOS板にいくといいよ
191名前は開発中のものです。
2008/07/10(木) 00:54:31ID:MjVgJsdw PG系隔離スレの2大巨塔でタスク厨の押し付け合いイクナイ!
192名前は開発中のものです。
2008/07/10(木) 05:56:13ID:nnoBQqoI Google,自社開発のデータ構造化ツール「Protocol Buffers」を公開
ttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/
ttp://itpro.nikkeibp.co.jp/article/NEWS/20080709/310437/
193名前は開発中のものです。
2008/07/10(木) 07:41:02ID:99kxezye >>186
【小さく審議中】
,、_,、 ,、_,、
,、_('・ω)(ω・`)、_,、
('・ω)u゚ ゚uu(ω・`)
゙uu゚( '・) (・` )uu'
゚uu゚ ゚uJ
【小さく審議中】
,、_,、 ,、_,、
,、_('・ω)(ω・`)、_,、
('・ω)u゚ ゚uu(ω・`)
゙uu゚( '・) (・` )uu'
゚uu゚ ゚uJ
194名前は開発中のものです。
2008/07/13(日) 00:51:10ID:eBw+YtUV 素人です
つくりかけのゲームってどうやって動かしてテストするんですか?
つくりかけのゲームってどうやって動かしてテストするんですか?
195名前は開発中のものです。
2008/07/13(日) 01:06:26ID:47vlxomf ワタクシ ハ インクリメンタル ナ カイハツ ホウシキをとっているので
ちまちまと小規模な物を作って、それを拡張していく形になります。
例
第一段階: ウィンドウを表示する
第二段階: キャラクターを一つ表示する
第三段階: キャラクターを動かしてみる
第四段階: 飽きる
ちまちまと小規模な物を作って、それを拡張していく形になります。
例
第一段階: ウィンドウを表示する
第二段階: キャラクターを一つ表示する
第三段階: キャラクターを動かしてみる
第四段階: 飽きる
196名前は開発中のものです。
2008/07/13(日) 01:25:52ID:eBw+YtUV197名前は開発中のものです。
2008/07/13(日) 01:29:50ID:R4nPLnnD そんなことシロウトせんでいいいよ
198名前は開発中のものです。
2008/07/13(日) 02:53:02ID:lqrHuCir 動くところまで作ってからテストする
199名前は開発中のものです。
2008/07/13(日) 03:04:31ID:uUrGa3AK 改めて言われるとあれだな
他にやりようないな
他にやりようないな
200名前は開発中のものです。
2008/07/13(日) 03:23:29ID:eBw+YtUV >>198
他人がつくったクラスがないと動かない場合はテストできないのでしょうか?
他人がつくったクラスがないと動かない場合はテストできないのでしょうか?
201名前は開発中のものです。
2008/07/13(日) 03:29:10ID:uUrGa3AK つ 単体テスト
いや出しゃばった 俺はweb系なので実情は判らん
まあロジック側は業種問わずどうグズったところで、
「何々渡したときに何々返す関数作ってー!」しか分業方法ないと思うけど
いや出しゃばった 俺はweb系なので実情は判らん
まあロジック側は業種問わずどうグズったところで、
「何々渡したときに何々返す関数作ってー!」しか分業方法ないと思うけど
202名前は開発中のものです。
2008/07/13(日) 03:29:54ID:edzJ8FGN たぶん、作りかけってのが何処までか分からんけど
目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす=エラーが出ないで動く なので
目に見えて作りかけとみれるのは殆ど完成間近なのが多いんじゃ。
プログラムの作りかけを動かす=エラーが出ないで動く なので
203名前は開発中のものです。
2008/07/13(日) 03:32:16ID:edzJ8FGN http://wiki.game-develop.com/
wikiのチュートリアル→段階的学習でもやってみては
wikiのチュートリアル→段階的学習でもやってみては
204名前は開発中のものです。
2008/07/13(日) 04:56:24ID:tw1/nxGs >>200
そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな?
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。
そのクラスのインタフェースが分かるならその仮実装を作れば良いでしょ。
プロキシとかスタブって聞いたこと無いかな?
そもそもあなたの言っているテストとは何をどうするテストなのか、
自分でハッキリと認識出来ているのなら人に聞くような問題じゃないと思う。
205名前は開発中のものです。
2008/07/13(日) 09:43:53ID:47vlxomf >>200
もし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。
だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。
早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、
もし私がプログラマなら、担当部分を動かすための
テストプログラム書いてます。
だから、それを見せてもらったら、大体どんなことができてるのか
把握できるんじゃないかと思います。
早い段階でCVSやSVNによるコード共有にも
慣れておくと幸せになれるかもしれません。
統合テストの段階になってからでないと
全体のMakefileが書けない、
リンク作業もできないのではどうにもなりません。
今のうちからコードを共有して、
常に全体がコンパイル/リンクが可能であることを
確認できる環境作りが云々、、、、、、、、
206名前は開発中のものです。
2008/07/13(日) 09:51:14ID:timDAMYM207名前は開発中のものです。
2008/07/13(日) 10:22:09ID:L3kGAfa0 >>194
作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。
RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。
作り掛けでも動くように、ゲーム全体を一枚岩ではなくバラして作る。
RPG だったら戦闘・マップ・店・イベントシーンで完全にバラしておいて、
テスト用のメニューからそれぞれ起動できるようにするとかな。
208名前は開発中のものです。
2008/07/13(日) 10:49:52ID:UM30DsAY 作業分担?
全員が全体を上から下まできっちり把握した上で、
常に連絡を密にし、お互いが何をやってるのか理解しつつ、
各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。
全員が全体を上から下まできっちり把握した上で、
常に連絡を密にし、お互いが何をやってるのか理解しつつ、
各自が必要とみなしたら声かけてどんどん作ったり直したりしていく。
209名前は開発中のものです。
2008/07/13(日) 11:17:51ID:L3kGAfa0210名前は開発中のものです。
2008/07/13(日) 13:47:03ID:DAEU2DrC211名前は開発中のものです。
2008/07/13(日) 13:48:37ID:DAEU2DrC212194
2008/07/13(日) 14:07:22ID:eBw+YtUV213名前は開発中のものです。
2008/07/13(日) 14:19:00ID:sqmPpN2O Cだったらmain()関数書いて実行して、デバッガ等で動き見るかな…
仕事(勿論?非ゲーム)でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったw
個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどw
仕事(勿論?非ゲーム)でやってたときも、自分で単体テスト仕様書書いてたんで、
こんなやり方でもOKだったw
個人開発だったらウィンドウなりポリゴンなり目で見てわかる方から書いて、
中身を作っていくので、単体テストらしい単体テストはしないかな…
とりあえず箱を表示するとこ書いて、テストして、
動かすところを書いて、テストして、…ってのはやるけどw
214名前は開発中のものです。
2008/07/13(日) 14:24:18ID:RINNRPdb215名前は開発中のものです。
2008/07/13(日) 15:08:38ID:eBw+YtUV216名前は開発中のものです。
2008/07/13(日) 15:15:30ID:uaqPI4FP >>215
プログラマの数は?
プログラマの数は?
217名前は開発中のものです。
2008/07/13(日) 15:23:34ID:L3kGAfa0 >>215
まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない(DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。
基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。
まぁ、プロジェクトの種類にもよるわな。勘定系とかだとデータ項目と画面の
I/O 決まってれば、各人の作業は依存が少ない(DB に仕様どおりのテスト
データ作れば良い)から、スケールしやすい。
基本的には、プロジェクト全体をいかに疎結合なパーツに分解できるような
設計をするかにかかってる。DB とかメッセージングシステム使う世界は、
そこで切れてることが多いから分けやすい。
218名前は開発中のものです。
2008/07/13(日) 17:47:09ID:eBw+YtUV >>216
150人はプログラマでした
150人はプログラマでした
219名前は開発中のものです。
2008/07/13(日) 18:56:00ID:UM30DsAY220名前は開発中のものです。
2008/07/13(日) 21:19:15ID:Q/hESmSh 大規模金融システムで、SEの数ってことならありうるが
ゲームのスタッフロールにマが150人も並んでたら壮観だな
ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー
ゲームのスタッフロールにマが150人も並んでたら壮観だな
ちなみにそれなりの規模だと思われるFFXでメインプログラマが2人
サブプログラマが12人で残りは大半がデザイナー
221名前は開発中のものです。
2008/07/13(日) 21:20:02ID:6QYOrVUt ネトゲじゃねーの?
222名前は開発中のものです。
2008/07/13(日) 22:39:48ID:3VGnVE92 マ150人てどんなネトゲだよ。。。
223218
2008/07/13(日) 23:00:22ID:eBw+YtUV ゲームのプロジェクトじゃないです。
詳細は言えませんが。
ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。
詳細は言えませんが。
ゲームのテストってプログラマがCppUnitみたいの使ってできないですよね。
やはり手動でテスターがテストするんでしょうか。
224名前は開発中のものです。
2008/07/13(日) 23:23:02ID:UM30DsAY 俺の知る限り、ゲーム開発では基本的にテストは無いです
単体テスト→結合テスト→受け入れテスト、みたいな流れは無い
昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません
なので大部分がデバッグチーム頼みです
単体テスト→結合テスト→受け入れテスト、みたいな流れは無い
昔ながらの職人的やり方というと聞こえは悪いですが、
衝突判定とか文字列処理部分のような仕様が明確な箇所なら
自動テストは有効だし実際にやっている会社もあるようだけど、
「ここで光がばーっと集まって、このキャラが独白を始めて、そして背景が宇宙に切り替わっていく」
みたいな仕様書があったとして、それをテストする基準がないし自動テストできません
なので大部分がデバッグチーム頼みです
225名前は開発中のものです。
2008/07/14(月) 00:00:22ID:yOzfOKcB 3Dの衝突判定ライブラリを書いていたときは、単体テスト使いまくりだったぞ。
>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う
>224 みたいな場合はどうしようもないけど、表示以前のコアな部分では
単体テストも結構使う
226名前は開発中のものです。
2008/07/14(月) 00:02:24ID:IEzc7ZIH グラフィックやサウンドが絡む部分は自動化は難しいけど
ネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ
ネットワーク部分やスクリプトの読み込み部分なんかは
いくらでも自動化できるっしょ
227名前は開発中のものです。
2008/07/14(月) 00:10:58ID:cIaZ6JxY 一人で作ってる分には単体テストに拘る必要はないと思うな。
逆に(自分含めて)しっかり単体テストできるなら、複数PG開発も悪くないと思う。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁w
テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな!
逆に(自分含めて)しっかり単体テストできるなら、複数PG開発も悪くないと思う。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ようするに他人のコードのデバッグは勘弁w
テンパってる人はバグ処理を後回しにしたり、他に回したがるだろうからな!
228名前は開発中のものです。
2008/07/14(月) 12:30:06ID:Hnt5WQTk (NetBSDをOSに使ってる)リコーのプリンタの開発チームは
PGだけで1500人だそうです
PGだけで1500人だそうです
229名前は開発中のものです。
2008/07/14(月) 15:33:56ID:xdO9+1xM 数万行の同人ソフトしか作ったことないけど、ゲームってプログラムとしては割合小規模じゃね?
乗っかってるリソースの量がとんでもないだけで。
実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム(シーン別)、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の2乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。
あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。
乗っかってるリソースの量がとんでもないだけで。
実際、市販ソフト見てても、絶対に手が出せないというような印象はないなあ。
ゲームシステム(シーン別)、描画系、サウンド系、ツールやエディタ系と分けていけば
それほどカオスな状態にはならないイメージがあるけど。
もちろんプログラマの数の2乗程度の複雑性はあるだろうけど。
見ててもう明らかに絶望的なのは、勘定系とか電子カルテとか。
あと、それなりに腕の立つリードプログラマがいないと今時の3Dゲーム自体作りようがなくて
そいつがほとんどの重要なコード書いてしまってそう。なんとなく。
230名前は開発中のものです。
2008/07/14(月) 15:36:32ID:Hy149M4+231名前は開発中のものです。
2008/07/14(月) 15:40:51ID:0Th48wDt RPGみたいないろんな要素のあるゲームのプログラミングってどこから手をつけていったらいいですか?
232名前は開発中のものです。
2008/07/14(月) 15:47:11ID:wxUymIt7 お好きなところからどうぞ
233名前は開発中のものです。
2008/07/14(月) 16:22:48ID:Hnt5WQTk MSXのドラクエ2も大学生が一人で全部作ったんだよね
234名前は開発中のものです。
2008/07/15(火) 13:15:33ID:IiJYDS4l RPGっていってもいまだといろんなシステムあるからな〜
古典的なドラクエ初期のように2Dオンリー
チョンゲーに代表される3D使ってるクリックゲー
古典的なドラクエ初期のように2Dオンリー
チョンゲーに代表される3D使ってるクリックゲー
235名前は開発中のものです。
2008/07/15(火) 13:29:25ID:Hl1v93zY236名前は開発中のものです。
2008/07/16(水) 17:02:22ID:WbuXgq6y237名前は開発中のものです。
2008/07/16(水) 17:02:59ID:WbuXgq6y >>231
メモリ管理
メモリ管理
238名前は開発中のものです。
2008/07/17(木) 20:17:04ID:uAQ9zE97 >>231
要素の洗い出し
要素の洗い出し
239名前は開発中のものです。
2008/07/20(日) 02:44:36ID:gpI6Slf5 先人のろくにコメントもないコードの解析だけで一ヶ月ぐらいコーディングもしないってことはありますか?
240名前は開発中のものです。
2008/07/20(日) 02:56:31ID:L2XNyVag241名前は開発中のものです。
2008/07/20(日) 03:05:04ID:x+htBSIe ソースがあるだけマシだよ
アーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。
アーケード版のバイナリだけ渡されて
「これをPS2に移植してください。ソースは紛失してしまいました。」
と言った大田区の某大手ゲーム会社があったそうな。
242名前は開発中のものです。
2008/07/20(日) 03:08:22ID:ZbM+kRVz >>241
すみません… それ、たぶんウチだ orz
すみません… それ、たぶんウチだ orz
243名前は開発中のものです。
2008/07/20(日) 03:39:46ID:18o8S9Zj 最悪だなそれ
MAMEでも進呈したほうがいいな
MAMEでも進呈したほうがいいな
244名前は開発中のものです。
2008/07/20(日) 15:36:02ID:gpI6Slf5 オブジェクト指向のくずれてるウンココードに出会ったらどうしますか?
245名前は開発中のものです。
2008/07/20(日) 17:18:51ID:g88tpUo2 見なかったことにする
246名前は開発中のものです。
2008/07/20(日) 17:43:16ID:1Zabkxz6 それ俺だな。
どうやれば良いか分からないから、手探りで書いてる(´・ω・`)
どうやれば良いか分からないから、手探りで書いてる(´・ω・`)
247名前は開発中のものです。
2008/07/20(日) 22:53:25ID:zgBZw03q シングルトンで作ったクラスが2つや3つもインスタンスを生成することになったら破綻しない?
248名前は開発中のものです。
2008/07/20(日) 23:02:17ID:Tcsf7iZJ >>247
各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。
各フィールドやメンバ関数がまるごとstatic宣言されていない限りは、破綻しないと思うよ。
数に制限のあるリソース(or デバイス)を取り扱ってる場合は、セマフォか何かで排他処理とかロックとかが必要になるかもしれないけど。
249名前は開発中のものです。
2008/07/20(日) 23:02:30ID:USb+9tXO どういう意味?
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど?
シングルトンが2つも3つもあるならそれはシングルトンじゃないし
シングルトンのインスタンスがさらにインスタンスを生成するようなメソッド持ってても別に破綻しないけど?
250名前は開発中のものです。
2008/07/21(月) 01:05:54ID:9zclfNbN >>247の文章が破綻
251名前は開発中のものです。
2008/07/21(月) 14:17:23ID:Y7Mzeak+ コメントにシングルトンと書かれてるのに2つも3つもインスタンスが
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn
出来てる、辞めた先輩の残した謎コードって事ですね。わかりませn
252名前は開発中のものです。
2008/07/21(月) 18:53:57ID:9zclfNbN XBOX360, PS3, Wii 売れ行きに関係なく、開発しやすいプラットフォームはどれ?
253名前は開発中のものです。
2008/07/21(月) 18:54:50ID:NGr1sFSW 箱○
254名前は開発中のものです。
2008/07/21(月) 23:51:13ID:yo6BY71C 箱○は個人で十分開発できるからなぁ
255名前は開発中のものです。
2008/07/22(火) 00:00:52ID:grvq6f3A 箱○ 天国
Wii 普通
PS3 言わせるなw
という感じか?
Wii 普通
PS3 言わせるなw
という感じか?
256名前は開発中のものです。
2008/07/22(火) 00:03:34ID:9zclfNbN >>255
詳しく
詳しく
257名前は開発中のものです。
2008/07/22(火) 00:08:34ID:zCVKhHD7 お前ら本当に3機種の開発ツール使ったことあるのかとw
258名前は開発中のものです。
2008/07/22(火) 00:21:20ID:inlA4ozd なんで個人開発限定なんだよ
259名前は開発中のものです。
2008/07/22(火) 00:35:03ID:88jYUtHh XNAのことを言ってると予想
260名前は開発中のものです。
2008/07/22(火) 02:21:06ID:TRIzaodv XNAの市販ゲームが出たってニュースは前に見た気がするけど
実際どんなもんなんだろ
実際どんなもんなんだろ
261名前は開発中のものです。
2008/07/22(火) 02:44:01ID:kfP9Fty3 サターンのSBL,SGLしか使ったこと無い
262名前は開発中のものです。
2008/07/22(火) 02:45:19ID:zCVKhHD7 360(XNA)、Wii(インターネットチャンネル)、PS3(YellowDogLinux)という話?
263名前は開発中のものです。
2008/07/22(火) 16:12:48ID:k5fUsZQo Wiiはインターネットチャンネルどころじゃない
264名前は開発中のものです。
2008/07/22(火) 18:29:14ID:c7QeI/ED ゲーム機はDirectXを使うの?
265名前は開発中のものです。
2008/07/22(火) 18:36:04ID:Jekk8SUv DirectXはMSだけ
あ、Dreamcastという例外があるか
あ、Dreamcastという例外があるか
266名前は開発中のものです。
2008/07/22(火) 20:52:26ID:6od3yLDu ゲーム機ではないが、アーケードの基盤がWindows系というパターンはあるな。
DirectXそのものを使ってるかどうかは知らないが。
DirectXそのものを使ってるかどうかは知らないが。
267名前は開発中のものです。
2008/07/25(金) 15:29:12ID:9vpYBrtF やってみて、無理と判断され、チームを外されることってある?
268名前は開発中のものです。
2008/07/25(金) 20:06:41ID:66T6bhjF269名前は開発中のものです。
2008/07/26(土) 01:19:05ID:+2uolo1R いつしかスレ違いな話題ばかりになってるな。路線復帰しようぜ。
270名前は開発中のものです。
2008/07/26(土) 02:28:02ID:Esaqa0cW アドベンチャーゲームの画面クリックやら動的に変化しまくるコマンドとかはどうやって管理してるんだね?
271名前は開発中のものです。
2008/07/28(月) 18:13:52ID:9GhNVVJ3 前者は状態フラグの配列なり持っておけば十分だろ
後者はなんだ?状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ
後者はなんだ?状態フラグ読んで条件分岐すればコマンド変化はいくらでも管理できるでしょ
それともzorkみたいなやつかな。それだと構文解析が肝だろうなあ
272名前は開発中のものです。
2008/07/29(火) 14:37:45ID:kHD6g876273名前は開発中のものです。
2008/07/31(木) 18:14:30ID:ucHp1Nqp メニューコマンドってみんなクラス化しているもんなのかな?
メニューオブジェクトを生成してどうこうみたいな。
メニューオブジェクトを生成してどうこうみたいな。
274名前は開発中のものです。
2008/07/31(木) 21:20:41ID:Gc2qBZ+R ベタコードで記述したり構造体・配列のままより
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね?
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。
クラスにしたほうがアクセスの統一をはかれる分いいかなぁ。
まーメニュー触るコードが一箇所ならどっちでもいいんでね?
ようはクラスにするしないじゃなくて
複雑さを無くしたり楽するためにどうするかだから。
275名前は開発中のものです。
2008/07/31(木) 21:26:22ID:NXR7vyyv フロントコントローラーパターンとコマンドパターンでやります。
276名前は開発中のものです。
2008/07/31(木) 21:38:09ID:A+bu5iPx メニューによるけど、FF風のメニューは別シーンにして、その中の一つ一つのコマンドは
だいたい同じインターフェースを実装してる。
だいたい同じインターフェースを実装してる。
277名前は開発中のものです。
2008/08/01(金) 00:01:16ID:yD3o9/Uf クラスメンバって全部privateにしてgetterでしか取得できないようにするべき?
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし
privateにしたメンバをもつクラスを保持しているクラスから、そのprivateメンバにアクセスしたいときに
get()で呼び出すのが面倒なんだが・・・・publicならそのまま呼び出せるし
278名前は開発中のものです。
2008/08/01(金) 00:11:49ID:yp70Uz6t279名前は開発中のものです。
2008/08/01(金) 00:14:41ID:GzWnlC6Z280名前は開発中のものです。
2008/08/01(金) 00:22:47ID:z2aBgJTr 全部て
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて
全部にgetter/setter作る意義って、メンバごとに独自処理必要な場合だろ
そういうの不要ならpublicなり言語の提供するアクセサメソッド簡略化機能とうかで構わんて
281名前は開発中のものです。
2008/08/01(金) 00:28:14ID:4UGZmRTZ 排他制御や状態確認が不要ならどうでもいいかもだけど
コード書くのがマンドイだけなんじゃ?
まっしなIDEやプロパティのある言語つかうとかかな。
コード書くのがマンドイだけなんじゃ?
まっしなIDEやプロパティのある言語つかうとかかな。
282名前は開発中のものです。
2008/08/01(金) 00:32:32ID:GzWnlC6Z >>280
例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。
例えば、「すばやさ」と「回避率」と「盾の大きさ」というメンバ変数があったとする。
仕様変更により、これら三つを「守備力」に統合しようとしたとき、
各メンバ変数へのアクセスが全てアクセサメソッド経由なら、
そのクラスの変更だけで終わってしまう(ごまかせる)というメリットがあるよ。
283名前は開発中のものです。
2008/08/01(金) 00:36:38ID:z2aBgJTr まて、そら元々アクセサの設計が統合可能だった場合だろ
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……
守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ?
すばやさにアクセスしても盾の大きさにアクセスしても「守備力」が変わるって設計で良いなら構わんが……
守備力を出すクラスなりが仲介して、他のパラメータを元から束ねてた場合の話って事かな。
ちょっとエスパー疲れるぞ?
284名前は開発中のものです。
2008/08/01(金) 00:47:59ID:GzWnlC6Z >>283
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。
あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。
まあ、そういうこともあるさ(汗)
ここはお茶を濁しながら、オブジェクト間の結合を弱めましょうとか何とか言って、逃げようかな。
あと、全部アクセサメソッドつけたくなる理由は、Java beansに対応させるってのもあるな。
シリアライズしてXMLでデータを吐けるとか特典があったはず(要らない特典かも)。
285名前は開発中のものです。
2008/08/01(金) 00:54:19ID:b/gVwGdZ getterもsetterも持ってるメンバってのは、結局外から値をいじれるわけだから、
publicにした方が使う側は書きやすくでいいんじゃないの?と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・
publicにした方が使う側は書きやすくでいいんじゃないの?と思うわけ。
ああ、でもsetterに値のチェックとか入れれるのか・・・・
286名前は開発中のものです。
2008/08/01(金) 01:01:50ID:b/gVwGdZ しかもget()で取得するのが配列だったりすると、
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。
取得側で配列格納用の変数も用意しないと取得した配列の要素にアクセスできないし、
非常に手間。
287名前は開発中のものです。
2008/08/01(金) 01:02:58ID:tFL87oCT とりあえずpublicで書いていって、
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。
気が向いたらprivateにして、
それまで直接アクセスしたるところを、
大河の流れのように涙を流しながら直せば無問題。
288名前は開発中のものです。
2008/08/01(金) 01:07:26ID:b/gVwGdZ289名前は開発中のものです。
2008/08/01(金) 01:09:03ID:b/gVwGdZ 特にゲームだと毎フレームごとにいろんなものを描画するから、描画要素が多いとそれだけ呼び出しも増えるわけで。
290名前は開発中のものです。
2008/08/01(金) 01:19:38ID:ua9U6ROu c++での話だが速度はインライン展開されるの期待できるから問題ないし
メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。
メソッドが多くて中で使いまくるならclassで隠蔽。メソッド内でもget、set呼ぶ。
データの集合でしかなくメソッドが簡単な処理しかないならstructでpublic化かな。
コンストラクタ、コピーコンストラクタ、代入、比較演算あたりまでならstructで。
291名前は開発中のものです。
2008/08/01(金) 01:32:56ID:b/gVwGdZ >>290
こういうのって、センスが必要ですね・・・・。
ちょっと気になった事があるんですが、
自分のクラスのpublic関数が、内部で自分のクラスのprivateなメンバを使う場合、
わざわざgetterで呼び出して使う必要はないですよね?
class Foo{
private int a;
public int get(){ return a;}
public int calc(){
return get() * 2;
}
このようなcalc()の書き方に利点はあるのでしょうか?
こういうのって、センスが必要ですね・・・・。
ちょっと気になった事があるんですが、
自分のクラスの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:05ID:ua9U6ROu getter,setterがpublicなら外部参照する可能性があるということで
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。
内部だけで使うprivateメンバ変数と意識して区別できるとか
関数内のローカル変数と名前が被ってもメンバ変数を指してるのが一目瞭然とか。
命名規則で見分けられるようにするのが良いんだろうけどなるべくそうしてる。
293名前は開発中のものです。
2008/08/01(金) 03:52:45ID:eorE7C0S getterロボ
294名前は開発中のものです。
2008/08/01(金) 04:12:11ID:gQhqelIh メンバ変数の存在が setter/getter の追加みたいに public 部分に影響するのがおかしいんだよ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。
まず public なインターフェースが決まって、その後で必要なメンバ変数を private で考えるのが筋だろ。
295名前は開発中のものです。
2008/08/01(金) 18:37:49ID:YDkT93Ih >>294
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。
今まで作ってきたゲームの焼き直しなら、現実的なやり方だね。うん。
296名前は開発中のものです。
2008/08/01(金) 19:02:25ID:m4Vy5Xwk 理想と現実はだいぶ違うよな
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする
個人製作なら気に入らなければ壊して作りなおせるからそれでもいいけど
それにこだわって完成させられない場合が多い気がする
297名前は開発中のものです。
2008/08/01(金) 20:43:12ID:mQpnHwPh インターフェース中心の設計でプログラミングするんだったら
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。
プライベートメンバ変数にはアクセッサを用意すべき。
単なるクラスだけでプログラムするんだったら、位置とか角度とか見たいなアクセス頻度の高い
メンバはパブリックのほうが良いかと思う。
298名前は開発中のものです。
2008/08/02(土) 00:14:18ID:n2w2ONnP ぶっちゃけ、片っ端からget/setにしたほうが、悩む時間を削減できて、完成が早まる(トイイナw
299名前は開発中のものです。
2008/08/02(土) 00:25:25ID:MidBaG0Q しかしgetやsetが乱れ飛んで読みづらくなることも
300名前は開発中のものです。
2008/08/02(土) 06:50:04ID:xZ8r6Jdx >>299
プロパティが欲しいと。
プロパティが欲しいと。
301名前は開発中のものです。
2008/08/02(土) 11:52:40ID:eytLWJfu C#はそういう意味ではスマートだなぁ
302名前は開発中のものです。
2008/08/02(土) 23:43:30ID:Pnu26psa ゲームのシーン管理ってどうすりゃいいんだろう
303名前は開発中のものです。
2008/08/03(日) 02:53:56ID:DVblpxWK シーンつったってゲームによって全然違うからな
もう少し具体的に
もう少し具体的に
304名前は開発中のものです。
2008/08/03(日) 16:40:36ID:HN+lqKwd >>301
現行のゲーム機はまだC++なんだよな
現行のゲーム機はまだC++なんだよな
305名前は開発中のものです。
2008/08/03(日) 21:47:19ID:XQeDRsrL >>302
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。
そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、
結局どんな処理が必要などんなゲームなのか?
どれを止めると不味いか、どれは止めても復帰させれば問題ないか?
とかによると思う。
シーンってのが何を指してるのかが微妙すぎ。
VMCに分けろじゃないけど、
Visual面だけでシーンを切り分けるのがいい時もあるし、
Dataの読み込みや各種準備の時が切り分けにてきしてる場合もある。
そうじゃなくて、Loopを二つぐらい回しながら、
片っぽでバックの処理こなしつつリアルタイム進行で、
残りで、Interfaceを回してくタイプとかもあるし、
結局どんな処理が必要などんなゲームなのか?
どれを止めると不味いか、どれは止めても復帰させれば問題ないか?
とかによると思う。
306名前は開発中のものです。
2008/08/03(日) 21:52:25ID:qGD4tU/f シーンて、どのゲームも
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの?
タイトルー本編ーゲームオーバ
てな感じジャンか。細かいところは違えども。
ゲーム全体の状態遷移をどうするか聞いてんじゃないの?
307名前は開発中のものです。
2008/08/03(日) 22:00:54ID:0ZCECk8O おいどんのシーンは一種のタスクシステム(笑)で、
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。
ウィンドウ管理、イベント管理、衝突判定、FPS調整、各オブジェクト行動などがセットになっとるでごわす。
シーンの切替えはこのセットをまるごと取り換える作業なのですたい。
308名前は開発中のものです。
2008/08/03(日) 23:21:42ID:HN+lqKwd FFとかのムービーシーンの管理はどうやればよかですたい?
309名前は開発中のものです。
2008/08/03(日) 23:31:02ID:+gPnPllx プロダクションだとファイルサーバ置いてモデル素材とか徹底管理するみたいだね。
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。
いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と
Digital Anime Artwork(1/2)って本が内情ノウハウ溢れてて参考になった。
ほんとフォルダ分けの徹底とワークフロー統一にどこも頭悩ませてるようだ。
いまどきだとプロジェクションマップとか多用する規模の物も多いしな、美術、撮影、合成と
310名前は開発中のものです。
2008/08/03(日) 23:31:41ID:+gPnPllx あれ? ここCG板じゃねえじゃん。
うわ俺凄く恥ずかしいマジレス?
うわ俺凄く恥ずかしいマジレス?
311名前は開発中のものです。
2008/08/03(日) 23:31:45ID:0ZCECk8O312名前は開発中のものです。
2008/08/04(月) 17:38:42ID:OcXTlg2n うさんくさか博多弁多かたいね。なんかぐらぐらこく
馬鹿にしないでください><
馬鹿にしないでください><
313名前は開発中のものです。
2008/08/04(月) 23:28:56ID:Vp8LYTR0 >>312
こらあげにまっことすまんかったぜよ。
こらあげにまっことすまんかったぜよ。
314302
2008/08/04(月) 23:40:39ID:OTznAvMd >>306
そうそうそんな感じ。
1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。
そうそうそんな感じ。
1シーンの処理は画像やその他のデータの読み込み、メインループ、
次のシーンに移る前の要らないデータの破棄のような感じにするつもり。
前のシーンに戻れるように階層構造を使ったりしたら難しくなりそう。
315名前は開発中のものです。
2008/08/07(木) 02:18:10ID:iFGNdN4xしーん…
316名前は開発中のものです。
2008/08/07(木) 15:44:15ID:J5sJkFaL 【 審議中 】
∴∵
∴∵
317名前は開発中のものです。
2008/08/24(日) 00:35:34ID:kCbI2Ziv (審議が長引いています。今しばらくお待ちください)
318名前は開発中のものです。
2008/08/27(水) 21:03:35ID:pp3RgERm キャラクターの状態って、どうやって実装してますか?
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか?
stateパターンでは無理???
例えばマリオなら、
enum { SMALL, BIG, FIRE };
enum { STAR, NOT_STAR };
のように、直交した状態ごとにenumで列挙して、ifで場合わけするのでしょうか?
stateパターンでは無理???
319名前は開発中のものです。
2008/08/27(水) 21:31:52ID:tgwWcjRq それだけだとモーション中とかが実装できないよね
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う
ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。
マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。
FCマリオならそのenumに加えて、ゲームステータスとして「巨大化アニメ進捗」を示すカウンタ用意すれば十分だと思う
ステータス変化中に他の画面止めていいのか、それとも無敵時間とか起きながら遷移中にも時間は動かすのか前提がもうちょい欲しいかも。
その辺の細部を徹底的に見つめていくと、
適するパターンがあるのか、それとも独自な設計選ぶべきかが見えてくるんじゃないかな。
マリオにしてもSFCのヨッシーとかFC版3での画面奥行き潜りとか、色々
実装したい事を見据えて行くと変数の数やステータスのまとめ方が見えて来るだろうしね。
320318
2008/08/28(木) 00:48:01ID:Z+eKsEJG >>319
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか?
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。
いろいろ考えないといけない事多いですね。
この手のものを実装する方法として、stateパターンとenumとifで場合わけの他に何かあるんでしょうか?
状態の種類と数が複雑になってくると、enumとifを使う方法しかない気がしてきます。
ifで場合分けって、コードが汚く感じてあまり好きじゃないんですよね。
でも、こういうケースでは、これがベストなのかなぁ。
321名前は開発中のものです。
2008/08/28(木) 01:16:45ID:q3w3U78u >コードが汚く感じてあまり好きじゃないんですよね。
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな!」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。
ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねw
好みと言うより仕方がない気も。
よくわからんなら下手に「なんとかパターン使うべきなのかな!」って
考えるより、ベタで汚いながらも「いじりやすい」単純なコードからはじめてさ、
あとはめくらめっぽう試した方がいいよ。
ifでの場合分けさえ、インライン展開される事を知ってるかどうかで汚くても使う訳で。
で、知ってる人にはそういうのやら三項演算多用した分岐の方を「美しい」って言っちゃったりするからねw
322名前は開発中のものです。
2008/08/28(木) 01:34:35ID:O/+Qqs/2 最初ってそういうの考えちゃうよな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな
世間じゃどういうのが正しいんだろうとか考えて自分のコードが全然すすまねぇ
今ではなんだかんだで破綻するギリギリまで「動けばいいや」の精神で書いてる
仕事じゃないからこそだな
323名前は開発中のものです。
2008/08/28(木) 03:20:26ID:tq3ymPlL 関数ポインタで飛ばせば見た目は良くなるね。
可視性に問題が出てきそうで自分では使ってないけど。
可視性に問題が出てきそうで自分では使ってないけど。
324名前は開発中のものです。
2008/08/28(木) 09:12:41ID:y2qhH8VC そこで goto ですよ
325名前は開発中のものです。
2008/08/28(木) 10:11:26ID:MS2hHN8x 某シューティングツクール的にはそもそも「状態」という概念が無くて、
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。
全く別のオブジェクトを「発射」して、自分を「消滅」させることで状態の変化を表現してた。
326名前は開発中のものです。
2008/08/28(木) 11:46:09ID:Qlb2/Pnm javaは関数ポインタ使えないんだ・・・・
327名前は開発中のものです。
2008/08/28(木) 11:57:21ID:MS2hHN8x >>326
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。
Javaの場合は、状態クラスを作って、それを持つようにすればいいんだよ。
328318
2008/08/28(木) 17:59:10ID:Z+eKsEJG329名前は開発中のものです。
2008/08/28(木) 18:35:54ID:CuTVRbF+ 自分ひとりで考えても、本を読んでも出てこない、他人の眼に触れさせなければ見えてこないものもある。
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。
つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる?
それよりも自分の達成感の方を優先したいならそっちを選べば良いさね。
つか、コードの正しさ、綺麗さ、効率の良さ、読みやすさってどういうものだとして使ってる?
330名前は開発中のものです。
2008/08/28(木) 19:03:37ID:Jt4Hw7jN むしろ可能な全ての表記法を試す勢いで!
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。
次のプログラムからは気に入った表記で。
昔の事は忘れましょう。
331名前は開発中のものです。
2008/08/28(木) 19:43:21ID:MS2hHN8x332名前は開発中のものです。
2008/08/28(木) 20:37:26ID:xedxyhWb >状態という概念が無い
敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。
敵が爆発する瞬間とかだとやっちゃうなあ……。効率悪いんだろうか。
333名前は開発中のものです。
2008/08/28(木) 21:28:28ID:MS2hHN8x334318
2008/08/28(木) 21:30:31ID:Z+eKsEJG335名前は開発中のものです。
2008/08/28(木) 21:59:24ID:O/+Qqs/2 保守性も読みやすさもifとenumにしたからと言って損なわれるものでも無いと思うけど何を悩んでるの?
336名前は開発中のものです。
2008/08/28(木) 22:18:17ID:qtCAmqfQ ダライアス継承ってどんな継承?
337名前は開発中のものです。
2008/08/28(木) 22:22:03ID:xedxyhWb >333
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる?
爆発オブジェクトを自身と同じ場所に生成して、自身を削除する
って認識で合ってる?
338318
2008/08/28(木) 23:04:17ID:Z+eKsEJG339名前は開発中のものです。
2008/08/29(金) 00:44:03ID:hcEje8O4 ダライアス継承なんて初めて聞いたなあ
英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス(Darius?)はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな
英語だと Multiple Inheritance あるいは Diamond Inheritance と言うようだが。
あとダライアス(Darius?)はペルシャ人の名前のようだ。
まゆに唾つけて聞いておこうかな
340名前は開発中のものです。
2008/08/29(金) 00:50:36ID:rESH+j3C ダライアス継承でググってみても勘違いで質問してる奴にしか引っかからないな
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える
デザパタへの無駄なこだわりとか、初心者がなんか変な用語がいっぱい並んでる本だけ読んで惑わされてるだけに見える
341名前は開発中のものです。
2008/08/29(金) 02:39:33ID:VLtb7ZED Multiple Inheritance (多重継承) と Diamond Inheritance (ダイヤモンド継承) は
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん
違う概念だが...というかダライアスっていうとシューティングゲームしか思い浮かびませーん
342名前は開発中のものです。
2008/08/29(金) 06:43:42ID:gdp2Jatd343名前は開発中のものです。
2008/08/29(金) 10:26:08ID:ESvglHwU344名前は開発中のものです。
2008/08/29(金) 14:31:33ID:UaA8GGvx345名前は開発中のものです。
2008/08/29(金) 14:34:13ID:nV9hYRuE >だったりしてw
いやだったりしてっつーかそれしかなくね
いやだったりしてっつーかそれしかなくね
346名前は開発中のものです。
2008/08/30(土) 13:56:18ID:vqGqt03L ダイヤモンドが2個も3個もあるような継承のことか。
C3 MRO の解説でしか見たこと無いが。
C3 MRO の解説でしか見たこと無いが。
347名前は開発中のものです。
2008/08/30(土) 14:18:00ID:gGJd0yLw ドラえもん 「ことわざゲーム」
これはいいアニメ。 ... ドラえもん 藤子F不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar
これはいいアニメ。 ... ドラえもん 藤子F不二雄 アニメ
ドラえもん後期 ドラえもん本編 教育アニメ コメント非
表示推奨 緑 ...
http://ex-co-jp.8866.org/gourmet/080803.rar
348名前は開発中のものです。
2008/08/30(土) 14:23:18ID:h7pQaJrI なんかあちこちで見かけるな。これ以上ないってくらい、明らかにヤバいリンク
349名前は開発中のものです。
2008/08/30(土) 14:32:04ID:hoYQeFVI 夏休みも終わりって事さw
350名前は開発中のものです。
2008/08/30(土) 14:40:33ID:vqGqt03L Bot使った宣伝書き込みかなぁ
351名前は開発中のものです。
2008/08/30(土) 15:36:27ID:h7pQaJrI なんかのマルウェアって聞いたが
352名前は開発中のものです。
2008/08/31(日) 15:40:22ID:5jP5dBFC A has B B has C C has Dのようなクラス構成で
Aで作ったEをDで使うために、Aから呼び出したB、Bから呼んだC、Cから呼んだDのそれぞれの関数の引数に
Eを渡していくのはいいのかな?
Aで作ったEをDで使うために、Aから呼び出したB、Bから呼んだC、Cから呼んだDのそれぞれの関数の引数に
Eを渡していくのはいいのかな?
353名前は開発中のものです。
2008/08/31(日) 15:45:26ID:eaWcmeF0 いいんじゃね。
354名前は開発中のものです。
2008/08/31(日) 15:47:56ID:fQJxWw7j 別に悪くはないと思うよ
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない
Eの役割によってはABCD全てからアクセスできる領域に置くのもアリかもね
なんにせよその構成だけじゃいいとも悪いとも言えない
355名前は開発中のものです。
2008/08/31(日) 15:54:48ID:5jP5dBFC356名前は開発中のものです。
2008/09/02(火) 03:29:08ID:m23QvXa7 このスレにUMLで図描いて貼っても、きっと誰かが見る前に流れて消えてしまう罠
357名前は開発中のものです。
2008/09/02(火) 03:31:07ID:m23QvXa7358名前は開発中のものです。
2008/09/02(火) 17:16:20ID:BpB/a+5N CarクラスはTireクラスを4つ持っているとして、
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか?
TireクラスもCarクラスを持っていてCarクラスの関数を使えるという設計はいいんでしょうか?
359名前は開発中のものです。
2008/09/02(火) 17:22:14ID:Kf1ObPTz コールバックしたいならインターフェース化してポインタ渡すとよい
TireクラスでCarクラスを生成するとかなら論外
TireクラスでCarクラスを生成するとかなら論外
360名前は開発中のものです。
2008/09/02(火) 17:30:36ID:BpB/a+5N TireクラスにCarクラスのポインタを持たせて、Tire生成時とかにCarクラスのオブジェクトのポインタを渡せば
いいということでしょうか?
いいということでしょうか?
361名前は開発中のものです。
2008/09/02(火) 17:36:03ID:NydWLubY362名前は開発中のものです。
2008/09/02(火) 17:40:44ID:IXiySr/S タイヤが車に関心があるってどういう状況?
363名前は開発中のものです。
2008/09/02(火) 17:42:28ID:NydWLubY 「パンクしたよ」って知らせてくれるんじゃね?
364名前は開発中のものです。
2008/09/02(火) 17:44:29ID:IXiySr/S なるほど
365名前は開発中のものです。
2008/09/02(火) 19:17:31ID:gmtfIbjx それ車が「パンクしたか?」メソッド持ってるんじゃダメなの?
366名前は開発中のものです。
2008/09/02(火) 19:20:27ID:IXiySr/S 車が、常に「パンクしたか?」ってタイヤに聞くの?
367名前は開発中のものです。
2008/09/02(火) 19:24:40ID:gmtfIbjx うん
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
パンクに限らずあらゆる故障具合をウェルネスシステムが監視しててそいつに聞けば全部OKみたいな
車のメソッドじゃなくなったけど
368名前は開発中のものです。
2008/09/02(火) 19:38:46ID:IXiySr/S メディエーターみたいなの?
369名前は開発中のものです。
2008/09/02(火) 20:44:39ID:F4HrtZLF >>366
実際のTPMS(タイヤ空気圧監視システム)はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();
実際のTPMS(タイヤ空気圧監視システム)はそういうものだよ。
ホイールに取り付けられたセンサーモジュールが車両本体側装置と一定時間毎に無線交信してる
具体的には、本体が一定時間毎に圧力値を問い合わせ。センサーモジュールが圧力値を返してる
ポーリング処理。
float _pressure = m_wheel[n]->GetPressureState();
370名前は開発中のものです。
2008/09/19(金) 19:13:57ID:FmM/zRja ほしゅ
371名前は開発中のものです。
2008/10/05(日) 14:32:14ID:tMuqv+yj このスレはJavaでも大丈夫なの?
372名前は開発中のものです。
2008/10/05(日) 14:52:40ID:v7IsXRIY >>371
質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】スレを立てる前にココで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288
質問内容の分野がよくわからないなら、以下へどうぞ。
【初心者】スレを立てる前にココで質問を【Part17】
http://pc11.2ch.net/test/read.cgi/gamedev/1210443288
373名前は開発中のものです。
2008/10/05(日) 17:40:56ID:6np9SFhP >372がエスパーすぎる
374名前は開発中のものです。
2008/11/01(土) 11:27:07ID:g//jQFBy データ(アイテムとかマップとか)ってどうやって作ってます?
エクセルで打ち込んでcsvで保存?
エクセルで打ち込んでcsvで保存?
375名前は開発中のものです。
2008/11/01(土) 12:46:01ID:YmfIaKZ8 別にそれでいいし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
専用にエディタ作ってもいいし
ありもので済ませてもいいし
俺はPlatinum map editor使ってるし
376名前は開発中のものです。
2008/11/01(土) 12:58:04ID:g//jQFBy377名前は開発中のものです。
2008/11/01(土) 16:47:28ID:NlVHrve1 既存のマップツールは便利なんだが、結局そこから独自形式へのコンバータを作ってる。
378名前は開発中のものです。
2008/11/02(日) 08:08:32ID:JeGt0JB9 海岸線自動生成とかやってくれるエディタあるっけ?
379名前は開発中のものです。
2008/11/02(日) 09:02:07ID:i1X6CLvS >378
エディタでやるの?
エディタでやるの?
380名前は開発中のものです。
2008/11/04(火) 18:29:40ID:CIBt14+U 機能としてはエディタ側じゃね?
381名前は開発中のものです。
2008/11/06(木) 00:16:08ID:46fvhfrF ツクールで海岸線をシフト+右クリックすると分かる
382名前は開発中のものです。
2008/11/11(火) 20:24:09ID:rtOtwyEd 最近Gofのデザインパターンを読んで、目から鱗が落ちまくった。
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される(変数として保持される側の)クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。(関連する側が冗長になるが。)
2、再利用を考えたフレームワークは(初心者は)作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください orz
今までぐだぐだやってたのが全部無駄というか馬鹿だったのに気づいてしまった。
他の初心者がこんなことが起きないように、勝手にメモ。
1、相互参照は可能ならば避ける。どちらかが一方的に知り、メソッドでその都度渡すほうがいい。
→クラス図の関連の矢印の向きは重要。関連が1方向なら、関連される(変数として保持される側の)クラスの再利用が容易。
→相互参照関係にあるクラス同士を、一方的な関連にすることは大抵の場合可能なはず。(関連する側が冗長になるが。)
2、再利用を考えたフレームワークは(初心者は)作らない。
→再利用のための部品を作る程度にとどめるのがいい。フレームワークの設計は正直拡張性を考え出すと難しすぎるらしい。
他に鉄則があったらだれか教えてください orz
383名前は開発中のものです。
2008/11/12(水) 01:30:10ID:LsEQ4TEa 相互参照すると、クラス開放時にお互いが争ってメモリリークすんだよな
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ!」
ピー…
クラスA「Bさん、お先にどうぞどうぞ」
クラスB「いえいえ、ここはAさんがお先に」
クラスA「どうぞどうぞ」
OS「おまえら、どっちもさっさとイケ!」
ピー…
384名前は開発中のものです。
2008/11/12(水) 09:02:45ID: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
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:14ID:hxIHNKys ライブラリを作るとして、名前空間とクラスはどのように配置するのがいいでしょうか。
たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。(HogeLibrary.Composite)
2、小さなクラスをネスト先の名前空間に入れる。(HogeLibrary.SmallComponent)
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか?
たとえば、ある単純な機能のクラスがいくつかあります。
これを集約してより大きな機能のあるクラスがライブラリ内で作られている場合、
1、大きなクラスをネスト先の名前空間に入れる。(HogeLibrary.Composite)
2、小さなクラスをネスト先の名前空間に入れる。(HogeLibrary.SmallComponent)
3、そもそもが間違い。同一名前空間に配置する。
どれが適切でしょうか?
386名前は開発中のものです。
2008/11/13(木) 21:08:31ID:3NMFClPL387名前は開発中のものです。
2008/11/14(金) 01:18:47ID:USS/q0/d >>385
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
名前空間を分けるメリットが見当たらなければ分けないほうがいいでしょ。
388名前は開発中のものです。
2008/11/16(日) 02:04:27ID:OW89wflh ライブラリ利用者の立場にたって、
どうなってると使いやすいかを考えて臨機応変に決める。
どうなってると使いやすいかを考えて臨機応変に決める。
389名前は開発中のものです。
2008/11/19(水) 20:47:58ID:oq/eqnIP >>382-384
まだ読んでいない俺には勉強になったthx
まだ読んでいない俺には勉強になったthx
390名前は開発中のものです。
2008/11/20(木) 09:17:22ID:jP0yKBYe >>384
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
(まああのペースで全部網羅すると、値段とページがすごいことになりそうだがw)
のFirst Head本は、読み物形式で
悪いコードをよいコードに変更していきながら、解説しているようになっているので、
GOF本よりかなり読みやすいよ
ただ、いくつかのパターンが省略されて適当解説になっているので、注意。
適当になってる後半部分も解説されていたらかなり神本だった
(まああのペースで全部網羅すると、値段とページがすごいことになりそうだがw)
391名前は開発中のものです。
2008/11/30(日) 20:02:56ID:GlMxgFAf すいませんというか疑問です。
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします
特定の条件を満たしたら処理(入力の読み取り)を行う、という作業を内部で行う関数を作ろうと思ったのですが、疑問がいろいろ出てきました。
(1回のループの中に複数この関数を配置して、どこかで実際に実行する、というような使い方を想定してます。)
1、この関数を採用する場合、名前の付け方
Polls()、CanPoll()、IsPolling() …主目的が『必要ならば読み取る』なので何かしっくりしない。
2、何かよりよい代替の設計があるだろうか
何か設計が変な気がする、が、なぜそう思うのはわからない。
どなたか導きをお願いします
392名前は開発中のものです。
2008/11/30(日) 20:03:41ID:GlMxgFAf なんかいっぱい改行が入ってるorz
393名前は開発中のものです。
2008/11/30(日) 20:44:16ID:O5396ILY >>391
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。
関数の名前は内部での処理なんて割とどうでもいいので、
とにかくその関数の意味(挙動)がわかる名前にしたらいいんじゃね。
ちなみにJavaの場合、キーボードやマウスからの入力によってイベントが発生し、
そのイベントによって適切なリスナーの関数が起動されます。
プログラムの本流が直接読みに行くことなんてしません。
394名前は開発中のものです。
2008/12/02(火) 23:03:37ID:QPPOGJkH395名前は開発中のものです。
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
コルーチン、マイクロスレッド、ファイバ
>>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: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
このスレがあるので必要ないのでは?という意見があり、新スレを立てるべきかどうか迷っています。
ご意見頂けないでしょうか?
↓ゲーム開発論スレ要望の経緯
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:04ID:foB3PhGt398名前は開発中のものです。
2008/12/14(日) 06:47:43ID:3zIx1sHY 想定通りでワロタ
399名前は開発中のものです。
2008/12/15(月) 01:28:13ID:AODSdSoN >>395
ありがとう助かるよ
ありがとう助かるよ
400名前は開発中のものです。
2008/12/18(木) 23:54:28ID:QLMqRIYY キャラクタのデータはテキストファイルにゆだねて動的にできるけど
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
ふるまいはどうすればいいんだろう。
基本ふるまいをプログラムに実装して(静的)、テキストファイルで
その呼び出しを記述する(動的)とかなのかな。他に思いつかん。
401名前は開発中のものです。
2008/12/19(金) 12:11:03ID:ygbWfkiR 俺はそうしてる。
402名前は開発中のものです。
2008/12/21(日) 09:35:05ID:7nb+zy1b つまりスクリプトですね。
403名前は開発中のものです。
2008/12/25(木) 19:24:07ID:QpPf00tD 知ってるよDIって言うんだよね
404名前は開発中のものです。
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クラスに任せる形になる。
見通しが悪くならずに拡張できる。
今までずっと気づかなかった自分の頭の悪さに笑うしかないぜ。
結論としては基本中の基本で、データと処理は独立させましょ、ってことなんだけど。
ゲーム中ができたけど、ポーズ機能を追加、ポーズメニュー表示関連をクラスで作って実装するには、という感じの想定。
こんな感じに管理してるとして(具体的にはもっと複雑だけど。)
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:36ID:Y8oI6MzT 「勝手にメモ」を書き込んでくれる人(達?)の存在は、正直ありがたい
406名前は開発中のものです。
2008/12/28(日) 17:34:36ID:pzJs6/UU MVCでいうと、
M:StgScene
V,C:Menu,Playing
ってことなのだろうか?
Stateパターンという風にも捉えられる?
M:StgScene
V,C:Menu,Playing
ってことなのだろうか?
Stateパターンという風にも捉えられる?
407名前は開発中のものです。
2008/12/29(月) 00:45:07ID: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();
}
};
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:00ID: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したシーンに子が出来て、自分がフォーカスシーンで無いことを表す。
・原則として、自分の子供と祖先の子供以外には直接遷移できないとする。する必要も考えられないので。
・・・っとここまで書いて、ソースコードがないとどう考えても伝わらんだろと思った。
自分もまだ試作中だけど、かなり自由かつ堅実に作れる。
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:20ID:rBsXmGd8 しかもミスってる。
# unfocusing ・・・『戻り値に次の遷移先シーンかnull返す。』 ←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。
# unfocusing ・・・『戻り値に次の遷移先シーンかnull返す。』 ←×
正しくは、+Updateの行の後ろに『戻り値に次の遷移先シーンかnull返す。』と書くつもりでした。
410名前は開発中のものです。
2009/01/09(金) 00:07:48ID:vYDzTrO8 自作の状態遷移クラスに似てるな。
・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの?
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
・状態に親子関係がある。
・戻り値の意味によって遷移先を決める。
・自分の子、先祖の子以外は直接遷移できない。
ってあたり、ほぼ同じっぽい。
戻り値って具体的に何を返しているの?
自分の場合、STAGE_CLEARとかの定数を返している。
その値をみて、さらに親へ遷移(戻り値を返す)したり、子供へ遷移したりしてる。
411名前は開発中のものです。
2009/01/09(金) 01:05:35ID:2TNYOX7D >>410
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。
このソース、イベントといってるところでわかるように、C#です。Updateの戻り値はSceneインスタンスですね。
C#ではhoge.GetType()でインスタンスの型情報(Typeインスタンス)が取得できるもんで、それを定数代わりに利用します。
で、戻り値に対する処理はこんな感じ。
戻り値がnullなら、フォーカスシーンが孫以下であることを表します。
戻り値sceneのGetType()と、
・ChildのTypeインスタンスと比較すれば遷移が不要かどうかわかります。(等しければ移動していない。)
・定数として保持させたType配列と比較すれば遷移先が子かどうかはわかります。
・自分のTypeインスタンスと比較すれば遷移先が自分かどうかがわかります。自分ならば、focusingで初期化処理を呼び出します。
・それ以外の場合、祖先および祖先の子のいずれかであることがわかります。いずれにしても上位のシーンに処理を仰ぎ、自分は破棄されます。
ってかんじでしょうかね。
412名前は開発中のものです。
2009/01/09(金) 01:28:17ID:vYDzTrO8 インスタンスそのものを返すのかぁ。
確かにそのほうが直接的ですっきりするかもね。
確かにそのほうが直接的ですっきりするかもね。
413名前は開発中のものです。
2009/01/10(土) 23:29:07ID:GXwf3cbn インスタンスを生成するのは作成した瞬間にクラスが2つ分になってメモリが足りなくて死ぬ
危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。
危険があるから1個間にはさみたいな。
生成メソッドはstaticにするとかなんとか。
414名前は開発中のものです。
2009/01/11(日) 00:09:06ID:dWwzUAmX まて、よく意味はわからんが今時のゲームやるようなWindows環境前提なら、最低でも500MB程度はメモリに余裕があるだろう。
どう考えても使いきれるとは思えん
どう考えても使いきれるとは思えん
415名前は開発中のものです。
2009/01/11(日) 02:43:39ID:cWr0moum あれか? NSAppみたいなアプリケーションのインスタンスを丸ごとコピーするとかの話か?
416名前は開発中のものです。
2009/01/12(月) 02:58:31ID:8xCnbJpy417名前は開発中のものです。
2009/01/12(月) 03:30:42ID:mDvqZ10E シーン遷移時に元シーン内で新シーンのインスタンスを生成するのは、
そのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
そのコンストラクタへシーン用引数を指定できるのがメリットかな。
あと、シーンコンストラクタ/デストラクタとは別にシーン初期化/解放メソッドを定義しておいて、
シーンのコンストラクタは必要なシーン用引数のメンバへの保存だけを行うような形にすれば、
メモリが足りないということは殆どなくなると思うけどね。
それから、個人的な意見としては、
シーンが生成される際にはまだ生成元シーンのインスタンスへはアクセス可能でいたい。
このライフサイクルのほうが、現在の実行状態を認識し易くて、様々な仕様変更に柔軟に耐えうると思う。
418名前は開発中のものです。
2009/01/12(月) 03:32:37ID:mDvqZ10E ごめん
×ライフサイクル
○ライフタイム
×ライフサイクル
○ライフタイム
419名前は開発中のものです。
2009/01/12(月) 11:14:49ID:pb2pea9L そのあたりの話は研究しがいがあるな。
420名前は開発中のものです。
2009/01/12(月) 13:32:30ID:YXD0YS+N421名前は開発中のものです。
2009/01/12(月) 14:12:02ID:sqS0O25/ シーンをまたぐデータは、そもそもシーンが管理すべきなのか
検討した方がいいかも。
検討した方がいいかも。
422名前は開発中のものです。
2009/01/13(火) 22:46:08ID:BhFnEm7r シーンを跨ぐデータはスマートポインタみたいなもんで管理するんだが
そのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。
そのポインタを渡すのにシーン生成を先にしたいという感じかな。
オレは管理マネージャ作るけど。
423名前は開発中のものです。
2009/01/13(火) 22:46:54ID:BhFnEm7r 管理マネージャじゃマネージャマネージャだなw
まあC++になって楽になったものよ。
まあC++になって楽になったものよ。
424名前は開発中のものです。
2009/01/14(水) 03:24:31ID:0DnXfUAy425名前は開発中のものです。
2009/01/14(水) 03:32:21ID:0DnXfUAy 親シーン子シーン関係なくデータを引き継ぐ場合として考えられるのは、例えばこんなときか。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
ゲームを普通にプレイしてゲームオーバー表示(プレイ画面に追加表示)。その後ハイスコア画面に行くと考えると、
スコアの点数がまたぐデータになる。
RootScene>GameScene>GamePlaying
から
RootScene>GameScene>GamePlaying>GameOver
となり、その後
RootScene>HighScoreScene
に遷移する。
その際GameOverがHiScoreSceneを生成する際にコンストラクタでスコアデータを渡してやれば無問題。
426名前は開発中のものです。
2009/01/17(土) 14:39:28ID:AWtASysq YAGNI
427名前は開発中のものです。
2009/01/21(水) 22:53:35ID:sHv/LIGj スレが止まってるとさびしいな。
独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
独り言でも言ってるか。
STGを作るときに、解決すべき内容は。
・1/60秒や入力情報など、最も基本的なものの構築。
・シーン遷移等、シーン管理の構築。
ここまでで共通の枠組みは作れる。シーン遷移はこのスレで紹介してたやり方でいくとして。
実際のゲーム中の解決すべき内容は
・自機、敵機などを1オブジェクトとするとして、オブジェクトの構造およびオブジェクト達の管理方法。
・敵出現(=ステージ情報)の作成方法、および管理方法や、それにかかわること。(リプレイとか。)
・あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・オブジェクト同士の衝突判定の記述。衝突判定まで。
・誘導弾など、常に依存先がかわるオブジェクトの記述方法。
で一通りっぽい。この手順でオブジェクトのインタフェースや管理方法を徐々に改良すると考える。
428名前は開発中のものです。
2009/01/21(水) 23:23:50ID:sHv/LIGj オブジェクトの構造とそれらの管理。
前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
(本質的にバリアや耐久力表示と同じ関係なので。)
前提として、管理のことを踏まえスーパークラスで多態性する。
publicにしそうな変数は 位置、速度、耐久力(=生存判定)
publicにしそうな関数は 更新、描画
いまいち不定だけどpublicで必要そうなものは、衝突判定にかかわるもの。
どこまでを1オブジェクトとするか。
・部位破壊が出来るものなど、一方的に依存するオブジェクトは別オブジェクトとして扱う。状況によっては相互参照も許可、を想定。
(本質的にバリアや耐久力表示と同じ関係なので。)
429名前は開発中のものです。
2009/01/22(木) 00:12:28ID:P249I5A7 ステージ情報の管理。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報(背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。
これを管理するクラスを一つ作る。主なデータとしては
敵出現データ情報(背景出現情報)、ランダムシード、ステージ進行速度。ついでに入力情報の蓄積もここがやると見通しがいいかも。
基本的に言語そのままでは出現情報は記述しづらいので適当なスクリプトを自作する。
wait、enemy、background、musicがあれば十分。
ボス戦手前などに掛け合いをはさむなら、event命令もあるといい。
簡単に変更できるようにすることを考えると、命令を分岐、並列に記述できる文法があると便利。
(waitによる相対時間出現なので。現在の出現配置を維持しつつ追加したいときとか。)
この方法は読んだ人は気づいてると思うけど、ある本を参考にしました。
430名前は開発中のものです。
2009/01/22(木) 00:45:44ID:P249I5A7 で、今は
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
あるオブジェクトの変数に依存するオブジェクトの管理、依存方法。(耐久力表示、バリア、レーザーなど。)
・依存オブジェクトの生成は、被依存が関わってくるのでそれの参照を取得する方法は深く考える必要はない。
・完全な対応関係ならば、依存オブジェクトは被依存オブジェクトをその型で参照を保持する。
(スーパークラスで保持する必要性がない。被依存側の、依存側で必要なメンバはpublicにする。)
・逆に、誘導弾やエフェクトなどは被依存をスーパークラスで参照を保持する。
>>428で生存判定がインタフェースにいるので、ここら辺は融通が利く。
431名前は開発中のものです。
2009/01/22(木) 00:57:55ID:P249I5A7 オブジェクト同士の衝突判定の記述。衝突判定まで。
・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。
・複数の矩形で衝突判定を処理するオブジェクトがいることが想定される(ボスなど。)
→バウンディングボックスも実装。
・後々考えると、回転可能な矩形判定が後腐れない。
→バウンディングサークルにしといた方が、記述の割りに回転に対応できる。
衝突判定データを保持するクラスを作って、オブジェクトは衝突判定データのインスタンスをリスト構造(場合によっては木構造)で保持。がいい感じ。
オブジェクトを2つ受け取り、それの衝突判定を走査する、という処理を行う関数をつくればいい。
誘導弾などの実装、は思案中。いい感じが思いつかない。
432名前は開発中のものです。
2009/01/22(木) 04:27:16ID:lwlInfIx433名前は開発中のものです。
2009/01/22(木) 04:40:32ID:P249I5A7 >>432
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
サンクス。こんな考え方があったのか
言われてみれば、作り始めたての頃は○○Managerや○○Dataはかなりいた気がする。
今は1個だけしかいないところを見ると(UpdateManager)、自然とどうやら身についてはいるっぽい。
434名前は開発中のものです。
2009/01/22(木) 15:25:00ID:x7I7tNfu 大抵のクラスは、何か管理してるか、何かのデータを持ってる気がする。
435名前は開発中のものです。
2009/01/29(木) 21:46:47ID:dRfTqeNw そうだけど、それとクラスの名前が〜管理、〜データになることはイコールじゃないよねって話でしょ
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
管理とは何をすることなのか、そのデータは何を表わしているのかが名前で分かった方がいい
436名前は開発中のものです。
2009/01/30(金) 16:55:21ID:O2nIHOeq >>434は別に口答えしてるわけじゃない気がするw
437名前は開発中のものです。
2009/01/31(土) 08:12:45ID:qu7YpnnP アクションゲームとかでキャラの座標って本当にキャラ自身が持つべきなのかな?
とたまに悩む
とたまに悩む
438名前は開発中のものです。
2009/01/31(土) 12:07:33ID:2t9biDkM Gemsにある『コンポーネントベースのオブジェクト管理』とか見てみるとよい
439名前は開発中のものです。
2009/01/31(土) 19:06:11ID:mhj1e1O5 そのへん追求し始めたらキリ無いよねw
最近はもう深く考えるのはやめた
最近はもう深く考えるのはやめた
440名前は開発中のものです。
2009/01/31(土) 19:11:05ID:L0OEs6zN >>437
悩む悩むw
悩む悩むw
441名前は開発中のものです。
2009/02/01(日) 19:03:38ID:tMKL4U61 >>437
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。
1番近い敵キャラが攻撃してくる
って処理を書いたときに同じ疑問を俺も感じた。
int near = CEnemy::returnNearNum();
enemy[near].attack();
↑こんな感じで静的なメンバ変数を返して貰っていたけど
STGみたいに「自機」対「敵機達」ならこれでもいいんだけど
ボンバーマンみたいなバトルロワイヤルとかサッカーやアメフトみたいなボールゲームとか
お互いの位置関係が重要なゲームになるとステージ側が管理すべきかなと。
442名前は開発中のものです。
2009/02/02(月) 20:35:13ID:esDSGZyH ステージ側でやってることが多くなって
どこかに細分化できないかなと悩み出すんですね
わかります
どこかに細分化できないかなと悩み出すんですね
わかります
443名前は開発中のものです。
2009/02/03(火) 03:59:27ID:cOF6NPxT キャラの位置をステージ側で管理する手法も
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか
割と普通だとは思うけど、OOP前提なら避けたいかなあ
近傍キャラの検索スピードを最適化したいということなら
ステージ側に直前のフレームでの位置情報のコピーを作るとか
444名前は開発中のものです。
2009/02/06(金) 21:51:27ID:+KF0MHRv たとえば、石クラスと、マップクラスと、それらを管理するシーンクラスがあったとして、
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
・石に重力を働かせる処理
・石と石の衝突処理
・石とマップの衝突処理
は、それぞれどのクラスが担当すべきだろうか。
445名前は開発中のものです。
2009/02/06(金) 21:56:52ID:jTgjQpbm >>444
物の理を司る GOD class
物の理を司る GOD class
446名前は開発中のものです。
2009/02/06(金) 21:57:18ID:sBGSiXKq 分からないから指向をそのままレスとして出力。
・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。
・ゲームは現実を模倣するものじゃないから、重力が全てに等しく働くとは限らない。
・が、固有の係数との積で出せばいいからやはり個々ではない所に基本重力値を。
・衝突判定方法をあらかじめ限定しておけば、二つの物体を引数にとって判定を返す関数を作ることが可能。
・同上により、マップと石との判定をあらかじめ限定化すれば、独立した関数として定義可能。
ごめん、適当に書いただけ。
447名前は開発中のものです。
2009/02/06(金) 21:58:24ID:y5Y5dk+m 唐突に石とかマップとかいわれても一般性がなさすぎてバックグラウンドがよくわからん
448名前は開発中のものです。
2009/02/07(土) 00:34:27ID://aDzdii > ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス
石クラス
> ・石と石の衝突処理
マップクラスに位置情報を登録して一括処理
> ・石とマップの衝突処理
石クラス
449名前は開発中のものです。
2009/02/07(土) 01:46:53ID:HaVHq232 > ・石に重力を働かせる処理
石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス
石クラス
> ・石と石の衝突処理
衝突判定クラス
> ・石とマップの衝突処理
衝突判定クラス
450名前は開発中のものです。
2009/02/07(土) 13:25:16ID:bH//onUq > ・石に重力を働かせる処理
ゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス
ゲーム管理クラス
> ・石と石の衝突処理
ゲーム管理クラス
> ・石とマップの衝突処理
ゲーム管理クラス
451名前は開発中のものです。
2009/02/07(土) 14:22:20ID:VS035g6S > ・石に重力を働かせる処理
石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス
石に重力クラス
> ・石と石の衝突処理
石と石の衝突処理クラス
> ・石とマップの衝突処理
右とマップの衝突処理クラス
452名前は開発中のものです。
2009/02/07(土) 14:51:09ID:VC/wpjC+453名前は開発中のものです。
2009/02/07(土) 16:19:23ID:Pn1Dl7Zh >>450
CGameManagerですね、わかります
CGameManagerですね、わかります
454447
2009/02/07(土) 16:35:33ID:oHEfOG3S みんな何のことだかわかっていて俺涙目
455名前は開発中のものです。
2009/02/13(金) 17:17:04ID:gamtZzLZ テーマが石なら、
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。
>・石に重力を働かせる処理
シーン管理クラス
>・石と石の衝突処理
シーン管理クラス
>・石とマップの衝突処理
シーン管理クラス
だな。
石なら質量・形(テクスチャ)・位置・速度・加速度など汎用なメンバ変数だけで事足りる。
シーンに乗る子オブジェクトを継承した石クラスを作っておいておくだけ。
石クラスの中身は空で、後々必要になったら拡張できるぐらいにとどめておく。
だから感覚的にはクラスを用いただけの構造体のような使い方で書くかな。
これがもし石でなく、人のような思考の多様性を持たせるのなら、また話は変わってくるかも。
456名前は開発中のものです。
2009/02/13(金) 17:35:30ID:gamtZzLZ 455だけど、修正
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。
やっぱ衝突判定クラス作るわ。
シーン管理は保持オブジェクトと描画などについて司るだけで、
オブジェクト(石やらマップやら)をそれに入れて判定するだけにとどめておくのがいいと思った。
457名前は開発中のものです。
2009/02/14(土) 00:06:30ID:wuF2UeZP 沈静化したネタに対するレスより新たなネタの方がスレが進んでうれしいと思うな、思うな
458名前は開発中のものです。
2009/02/14(土) 00:20:27ID:+0ELSliX459名前は開発中のものです。
2009/02/14(土) 01:01:03ID:1cFYmXpg ああ。誘導されて初めて来たんで、日付もろくに見てなかった。悪い。
新しいネタか……。じゃあ、1つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード&短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。
新しいネタか……。じゃあ、1つだけ。
ゲームって作りながらデバッグや、完成してからももちろんチェックするんだろうけど、
その過程でゲーム特有のデバッグ手法があれば教えてほしい。
リークチェックやAssert使うとかの普遍的な手法の話というよりは、
ゲーム特化で、データ構造・クラス・パターンの観点から、、
いかにしてスクリプト上の変な挙動を見破れる技法だとか、
デバッグメニューとして必要なものは何かだとかそういうのが知りたい。
自分のようなアマチュアではそこまで手が回らないんで、
いつも自分で修正・テストを繰り返して大体動くなと思ったらテストプレイをお願いしている。
そんな中、どのように効率よく(少ないコード&短かい時間で)デバッグできるか教えてほしい。
そもそもデータ構造やクラスを気をつけていればバグは出ないとかいうのは無しで。
460名前は開発中のものです。
2009/02/14(土) 03:08:07ID:qKH3GStO 人にデバッグを頼むのであれば、調べたい場所まですぐにたどり着けるような仕組みを。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はOFFで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利/敗北または成功/失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール(数十倍〜数十分の一まで)。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。
無敵モードとかステージセレクトみたいな。
当然ながら、バランスチェックを含めたテストプレイならこれらの機能はOFFで。
コリジョンの可視化。特定のボタンやデバッグ用のフラグでコリジョン無視。
エネミーやアイテムを自由に配置。デバッグメニューからのパラメータ操作。
ボタン一発で勝利/敗北または成功/失敗。必要に応じて、強制クリティカルとか強制回避なども。
アニメーションやオブジェクトの移動の速度コントロール(数十倍〜数十分の一まで)。
特定の状況下のセーブデータ捏造、隠しやおまけの強制解放。
スクリプトはエラーチェックを厳しくするぐらいしか思いつかないな……。
461名前は開発中のものです。
2009/02/14(土) 10:08:02ID:hPf9zE7f リリース用には付けなくても、デバッグ用にリプレイ機能あるといいよ。
462名前は開発中のものです。
2009/02/15(日) 16:27:42ID:933sIzgh 速度調整機能つけたりログ吐かしたり
そんくらいしかやっていないな。
そんくらいしかやっていないな。
463名前は開発中のものです。
2009/02/18(水) 14:05:52ID:1weRwVko464名前は開発中のものです。
2009/02/18(水) 14:39:48ID:0gTNCSoI 行動力あるね
素晴らしい。見習いたい
素晴らしい。見習いたい
465名前は開発中のものです。
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なので、便利ボタンとパラメータ操作がとても役に立っています。
ありがとうございました。
コリジョン可視化:テクスチャ読み込み後に四隅に沿って緑色で四角線を書くだけ
パラメータ操作:テンキーで実装
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:48ID:3Qcrn5pr 洋ゲーだと、LuaみたいなDSLをスクリプトとして組み込んでるせいか、
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。
ゲーム中でもコンソール出して直接変数いじったりできるのがあるよな。
467名前は開発中のものです。
2009/02/21(土) 12:50:08ID:YLpnm94h468名前は開発中のものです。
2009/02/24(火) 16:03:05ID:xS4ZudQO スマートポインタの使いどころ教えて
469名前は開発中のものです。
2009/02/25(水) 02:46:38ID:1o4GjPkR 使いどころっつーわけじゃないけど
次のC++規格が決まれば、早ければ今年中にも
std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど
次のC++規格が決まれば、早ければ今年中にも
std::shared_ptr
として使えるようになる予定
今でも既に std::tr1::shared_ptr になってるけど
470名前は開発中のものです。
2009/02/25(水) 05:08:14ID:M8Pe/6zZ >>468
まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。
まず一般的に、スマートポインタは動的確保されたヒープに用いるとして。
使いどころは、
・ヒープの解放処理を書くのが面倒であったり忘れてしまいたいとき
・ヒープの被参照期間を別のオブジェクトらの生存期間と一致させたいとき
・ヒープの参照状態を把握したいとき
・これまでのソースが生ポインタで参照しまくり不正参照でメモリ破壊しまくりで発狂しそうなとき
だと思う。
471名前は開発中のものです。
2009/02/25(水) 11:43:26ID:woJXacCs 要約すると、いろんな人・場所で使われるポインタだったら使いどきってことですか
472名前は開発中のものです。
2009/02/25(水) 18:18:12ID:QjeqtKpK Yes
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ
いろんなとこから参照されていて、開放時期が掴めないときは最高に便利
理論的には、参照カウンタが0になったら自動的に消えていってくれるよ
473名前は開発中のものです。
2009/02/25(水) 18:28:42ID:nKINhS/o つまり、いらなくなったらすぐに消されるってことですね
私のように
私のように
474名前は開発中のものです。
2009/02/25(水) 18:31:43ID:Z+e+XbPJ 不況だもんな・・・
475名前は開発中のものです。
2009/02/25(水) 18:55:09ID:1o4GjPkR いや、それは地球の資源不足で君の給料が確保できないだけだ
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・
スマートポインタがあれば使われなくなった人材をどんどん自動破棄して・・・
476名前は開発中のものです。
2009/02/27(金) 15:15:39ID:MDeQuwXl 例えばDirectxのDeviceインスタンスなど、あらゆる所で使われそうなインスタンスは、どう使ってますでしょうか?
Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは
1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他
現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?
Draw、Moveを持つオブジェクトと画面の表示物が1対1で対応してる設計で、
リソース(画像や効果音)などの情報も全てオブジェクトがコンストラクタで受け取り内部で保持してるいかにもoopな設計なのですが、
Deviceインスタンスは
1、Drawの引数に渡す
2、コンストラクタで引数にとり、各オブジェクトがあらかじめ参照を保持。
3、グローバル変数
4、そもそもその設計はまずい
5、その他
現在2です。
1から3に共通する問題としては、Deviceインスタンスをオブジェクト内で操作した内容が間違ってた場合、
発見がかなりめんどくさそうな所でしょうか?
477名前は開発中のものです。
2009/02/27(金) 15:58:46ID:XnWaU4Ou デバイスホルダー的なシングルトン作るとか
478名前は開発中のものです。
2009/02/27(金) 17:33:53ID:lChaxYTz 俺もシングルトンかな。参照回数が0になったらreleaseで。
479名前は開発中のものです。
2009/02/28(土) 00:40:47ID:OR4wkfx2 ハッシュテーブルのキーって文字列じゃなくてもいいのかな?
符号なし整数とか。
どっかにそういう例ないです?
符号なし整数とか。
どっかにそういう例ないです?
480名前は開発中のものです。
2009/02/28(土) 08:42:03ID:Cadu6Xk7 ハッシュが計算できるなら、キーはなんでもいいよ
481名前は開発中のものです。
2009/03/04(水) 04:45:32ID:y6+tTW6F482名前は開発中のものです。
2009/03/06(金) 11:34:39ID:7UNSgj8M C++でシングルトンするのってなんか滑稽じゃね?
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う
Javaじゃないんだし
そこまでクラス原理主義にならんでもいいのにと思う
483名前は開発中のものです。
2009/03/06(金) 13:08:45ID:A313Daxt484名前は開発中のものです。
2009/03/06(金) 14:26:30ID:7UNSgj8M グローバル変数関係ないやろ
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう
普通にstaticで隠してヘッダで関数だけ提供すればいいやんけ
インスタンシエーション必須の言語が苦肉の策でひねり出したのがシングルトン
よーく考えよう
485名前は開発中のものです。
2009/03/06(金) 14:28:31ID:7UNSgj8M あ、ちょっとちがうな。
「クラス定義必須、インスタンシエーション普通」の言語だな。
「クラス定義必須、インスタンシエーション普通」の言語だな。
486名前は開発中のものです。
2009/03/06(金) 15:48:06ID:A313Daxt >>484-485
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー
エンド ユーザーがそのクラスを作成できてしまうじゃないか
作成できないようにしたのがシングルトンだろ
話変わるけどカプセル化って C++ や Java の特長みたいに言われるけど
C言語でも出来るんだよなー
487名前は開発中のものです。
2009/03/06(金) 16:07:52ID:7UNSgj8M >>486
そのクラスのインスタンスが1つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ
そのクラスのインスタンスが1つであることを保証するのがシングルトン
クラス(原因)が無ければインスタンス(問題)も無い
だからシングルトン(解決策)も要らんと言っているんだ
C++でのシングルトンはマッチポンプなんだよ
488名前は開発中のものです。
2009/03/06(金) 16:18:21ID:7UNSgj8M http://www.geocities.jp/ky_webid/design_pattern/009.html
「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね?
// 生成やコピーを禁止する
↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい
「C++ シングルトン」でググったら出てきたページ
この労力を指して滑稽だと笑ってるんだけどな
Javaなら習得必須の概念だし俺も普通に使うが
C++でこんなん無理してやったら馬鹿みたいだと思わね?
// 生成やコピーを禁止する
↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラス原理主義に陥って思考停止しちゃってるんじゃないか
目的と手段の関係について考え直してみるといい
489名前は開発中のものです。
2009/03/06(金) 16:29:34ID:7UNSgj8M まあ、要件に多態性があるならクラス化した方が楽かもしれんけど
それ以外だとやっぱり儀式めいたものを感じるな
それ以外だとやっぱり儀式めいたものを感じるな
490名前は開発中のものです。
2009/03/06(金) 16:29:53ID:oPKUKLY9 先にクラス原理主義という単語を発してしまった時点で
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件
ID:7UNSgj8Mが単なるC++においてのクラスアンチなだけに見える件
491名前は開発中のものです。
2009/03/06(金) 16:34:17ID:7UNSgj8M492名前は開発中のものです。
2009/03/06(金) 16:39:54ID: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++シングルトン症候群と命名しておこう
マジで一度考え直した方がいい
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:37ID:12yJl3As 労力って
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
コンストラクタをprivateにしたり、
コピーコンストラクタを宣言だけ記述したりするだけじゃん
>↑アホじゃね? 最初からクラスにしなきゃいいじゃん
クラスで管理する方が都合が良くて、尚且つインスタンスを一つに制限したいものなんていくらでもあるだろう
じゃあシングルトン使わないでインスタンスを一つだけに制限するもっと楽な方法ってなんだよ
494名前は開発中のものです。
2009/03/06(金) 17:07:43ID:7UNSgj8M495名前は開発中のものです。
2009/03/06(金) 17:20:31ID:12yJl3As496名前は開発中のものです。
2009/03/06(金) 18:55:30ID:Erqh3NJs namespaceでくるんだり全部staticメソッドにしたりもしてみたけど、
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。
素直にシングルトンにしたほうがイディオム的に分かりやすいと思う。
ファクトリメソッドとかで、普通のオブジェクトと同じように生成したい場合も、
シングルトンのほうが便利だよね。
それと、あとから「やっぱシングルトンやめ」ってなったときに、
変更が少なくてすむのも利点かなあ。
497名前は開発中のものです。
2009/03/06(金) 20:00:35ID:z7QigqBL まぁ疑問を持つのは悪い事じゃない
他人に強要しなければね
他人に強要しなければね
498名前は開発中のものです。
2009/03/12(木) 10:42:00ID: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
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:53ID:X7nBBwQA >>498
捕捉:
(わかると思うけど)使う時は、他のユニットから
Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節?でアプリ終了時のFPrinterの開放処理がある。
捕捉:
(わかると思うけど)使う時は、他のユニットから
Printer.HogeMageSimasu;
見たいに使う
あと抜けてるけど、実際には、finalzation節?でアプリ終了時のFPrinterの開放処理がある。
500名前は開発中のものです。
2009/03/16(月) 15:21:22ID:FTtiBwy2 また変なのが沸いてるのか
501名前は開発中のものです。
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, ...);
}
もし既に案の方法でやってる人いたら使い勝手教えて!
今まであちこちに散らばって状態で書いてたんだけどなんか扱いづらい。
下みたいな感じで一箇所にまとめた方がいいのかな。
今:あちこちでデバイスにアクセス
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:27ID:KYbRBn+z 久々に答え甲斐のありそうな相談が来たな
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ!
だが俺はモーションインデックスとベクトルをリストに投げて後で一気に処理する方法だから答えられそうに無い
お前らに任せたぜっ!
503名前は開発中のものです。
2009/03/19(木) 05:21:17ID:XLj1eEa+ 描画能力のあるオブジェクトをリストなりグラフなりに登録しておいて、デバイスハンドルはビジターで渡す、とか。
504名前は開発中のものです。
2009/03/19(木) 19:28:19ID:ALN5WhPj 俺はこの案では無いなぁ…てかどうせなら
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…
lpD3DDEV->draw(draw_data, ...);
は
draw_data.draw(...);
みたいにしてlpD3DDEVに直接アクセスしない方が…
505501
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人では無かったけれど。
>>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:39ID:D2lp0Ec4 まずはMVCを試みてみるのはどうだろうか
507名前は開発中のものです。
2009/03/20(金) 04:52:36ID: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;
};
続く…
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:53ID: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);
}
}
うーむ…。
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);
}
}
うーむ…。
509501
2009/03/21(土) 12:54:05ID: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 の「案」。
だから例えば複数の関数に同一デバイスへのアクセス処理が分散してるのは自分的には問題が解決していないと感じる。
今回の話では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:29ID:O7e3N6nq 描画するにはデバイスに対して様々なパラメータを設定しなけりゃならんわけだが
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。
>>501だとそこをどう処理するのかがよく分からない。
各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
そうじゃないなら、結局デバイスをやりとりしなきゃならなくなるような。
511501
2009/03/23(月) 00:38:25ID:/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()みたいにベタ書きで
どこまでいけるかやってみるかな。
確かに。描画スクリプトかー、どうしよう。
ポリゴンの描画順番の最適化とかやり始めたら必要になりそうな気もするけど
今の自分のプログラムでは大げさすぎるかなぁ。今のところ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:33ID:koP5FPqt hamigaki::coroutines使ってみた。
513名前は開発中のものです。
2009/03/25(水) 12:39:16ID:C50L0uFm yhamigakiさんのexec.jamモジュールにはお世話になっております
514名前は開発中のものです。
2009/04/05(日) 14:24:00ID:a5PaoF6B スレッド1..n 仮想描画コマンドをメモリに積む
デバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い
デバイス用スレッド 仮想描画コマンドを解釈して実際のコマンドを発行
利点 単体テストが容易、移植が容易、マルチコアの恩恵を受けることができる
欠点 仮想描画コマンドバッファの管理にロック、セマフォは必須、上手に使用しないと逆に重い
515名前は開発中のものです。
2009/04/06(月) 03:21:58ID:NgKFyYts 仮想描画コマンドバッファをスレッドごとに持てばいいじゃない。
516名前は開発中のものです。
2009/07/15(水) 22:32:12ID:1c2msACv http://www6.atpages.jp/~autonomydoll/game/RPGClient.zip
クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
| |->Main-->Map -|
| -->Unit--->sprite--|
|--------------------------------------------------------------->GraphicsWarpper
クライアントからサーバーに要求を送って、サーバーから要求を受け取るような機能を付け加えたいんだが、どういう設計にすればいいかわからない。定石みたいなのがあったら教えてほしい。
今のクラス構成
ScreenManger-->ScreenGame-->Title
| |->Main-->Map -|
| -->Unit--->sprite--|
|--------------------------------------------------------------->GraphicsWarpper
517名前は開発中のものです。
2009/07/15(水) 22:40:07ID:h6KyoexM WinAPI使ってるなら、WinSockで送信して、ウィンドーメッセージで受信する。他はシラネ。
518名前は開発中のものです。
2009/07/15(水) 22:41:36ID:3ppQI3l+519516
2009/07/15(水) 22:46:53ID:1c2msACv520名前は開発中のものです。
2009/07/15(水) 22:57:45ID:cL81hhcG こんな面白い難読化もなかなかないな
521名前は開発中のものです。
2009/07/15(水) 23:01:47ID:3ppQI3l+ >>519
> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。
小学校は夏休みなのか・・
せめて中学生になってからにしてくれ
> net frameworkを使ってます。
.NET Framework を勝手に先頭のドットを省略したり、勝手に小文字に変えたりするなよ・・
> ScreenMangerはスクリーンマネージャという意味で、シーン全体を管理してます
それならMangerではなくManagerだろ。
> GraphicsWarpperは単なるラッパーです。
それなら、WarpperではなくWrapperだろ。
小学校は夏休みなのか・・
せめて中学生になってからにしてくれ
522名前は開発中のものです。
2009/07/15(水) 23:14:16ID:1c2msACv >>521
すまん。スペルミスった・・・。
すまん。スペルミスった・・・。
523名前は開発中のものです。
2009/07/16(木) 01:35:23ID:Ac1CnfQd まず日本語と英語を勉強するべきでは?
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは1つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う
そうじゃなくても、変数名などを略すのはやめた方がいい、複雑なコードになると対応できない
自分はdeleteHandCardListみたいな長い名前つけたりするけど、困ることは1つもないね
ちなみに件の話に関しては書籍があるよ
GameDeveloperのオンラインゲームの青本
MMORPGを作る赤本もある
2chで説明すると1スレ使っても無理だと思う
524名前は開発中のものです。
2009/07/16(木) 02:06:03ID:Dq9kBSTx525名前は開発中のものです。
2009/07/16(木) 02:29:30ID:lK28N0n1 質問の内容と関係ない単語にしかつっこめない奴が多くてワラタ
526名前は開発中のものです。
2009/07/16(木) 05:49:13ID:0eDNLm6a 2〜3人で多いのか、寂しい生活してるんだな
527名前は開発中のものです。
2009/07/16(木) 10:25:09ID:irpkCXOF 言われて悔しいならもっと勉強しろよ
528名前は開発中のものです。
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
ネットワーク機能参考図書紹介
>>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:51ID:qfXJNhjS STGのビジュアル関連向上に関するメモ。
・・・あんま設計と関係ないな・・・
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い・・・気がする。
・・・あんま設計と関係ないな・・・
それっぽい弾の作り方
・コマは2コマは以上用意して、画像の色を通常っぽいのと白っぽいのにする。アニメは4コマあればきれい。
・ケイブっぽい弾を作る場合。1コマ作った後、コピーして1ドットぐらい前後ずらし、形を適当に修正。明るい部分はなるべく中心に近づくよう修正。
・円形の回転する弾の工夫。わざと中心から斜めに1ドットずつずらす。
ちょっと光ったエフェクトとか。
・メイン画像と残像(というか残光)画像を用意。後は適当に残像表示の要領で重ね描画。
・センコロのブーストエフェクト。適当な○画像をブースター付近から扇子状に放射するだけ。それっぽいブーストグラフィックが得られる。
弾やエフェクトはポーズ連打して見てみたりすると、プログラムと画像をうまく考えれば誰でも作れるものが多い・・・気がする。
530名前は開発中のものです。
2009/08/14(金) 22:21:56ID:FZUQWr9u531名前は開発中のものです。
2009/10/05(月) 01:40:33ID:mQYy5BRf シミュレーションやRPGで
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが,
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか?
データクラスを作ってアクセッサで操作を許す?
それとも,すべてグローバル変数で持たせる?
経営状況や主人公の内部パラメータと呼ばれる
データ群がごっそりあると思いますが,
そういったものの管理は
実際のゲーム開発でどういった形でなされるものですか?
データクラスを作ってアクセッサで操作を許す?
それとも,すべてグローバル変数で持たせる?
532名前は開発中のものです。
2009/10/05(月) 04:33:25ID:/TvwIsfE シングルトンクラスのオブジェクトをグローバルに定義する
533名前は開発中のものです。
2009/10/05(月) 07:34:29ID:Rel4l/Gg SQLiteとか使って手抜くってのもあり
534名前は開発中のものです。
2009/10/14(水) 22:12:56ID:TwzkU58s グローバル変数はありえない。データクラス。
ただ、データの表示とかはいつも頭を捻らすなぁ。
ただ、データの表示とかはいつも頭を捻らすなぁ。
535名前は開発中のものです。
2009/10/15(木) 07:50:05ID:P3b4xThD アクセッサ書くのめんどいだろ
536名前は開発中のものです。
2009/10/15(木) 08:41:22ID:OtHf9VTl なんでそんな両極端なの?
537名前は開発中のものです。
2009/10/15(木) 15:54:18ID:byjv3si3 0と1しか無いからな
オタクの頭ん中は
オタクの頭ん中は
538名前は開発中のものです。
2009/10/15(木) 20:13:55ID:P3b4xThD 別に両極端で構いません.
意見を頂けるだけで嬉しいです.
むしろ噛み付くほうが迷惑です.
意見を頂けるだけで嬉しいです.
むしろ噛み付くほうが迷惑です.
539名前は開発中のものです。
2009/10/15(木) 22:16:10ID:r8d5RKMA 使う人がデータを把握できてるなら好きにすればいいんだよ。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。
質問は実際のゲーム開発だから、面倒でも形式的にやるしかないんじゃない。
540名前は開発中のものです。
2009/10/15(木) 22:18:05ID:2byzEsEE541名前は開発中のものです。
2009/10/15(木) 23:29:40ID:r8d5RKMA 俺は変数に直接アクセスでも分かりにくいと思わないし。
アクセッサ書くのもめんどくさいとは思わない。
アクセッサ書くのもめんどくさいとは思わない。
542536
2009/10/16(金) 00:35:50ID:L+kS7tAJ >>538
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…
悪い、噛み付くとかそういうつもりは無かった。
普通に設計して、グローバルにアクセスする必要があるデータを持ってるクラスだけ
Facade経由でアクセスできれば良いんじゃないかと思っただけ。
グローバル変数はさすがにあり得ない…
543名前は開発中のものです。
2009/10/16(金) 01:18:33ID:MsmDVyev 2chで素直に謝られると逆に困ります.
参考になりました,ありがとうございます.
参考になりました,ありがとうございます.
544名前は開発中のものです。
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);
て感じで、結局データを引数で取る形になるから、クラスで実装して方がいいんじゃないかと思う。
スタティックグローバルな変数を、何らかのアクセス関数を通して更新/参照するような設計は普通だと思う。
// 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:56ID:UJ9WR3Zt 代入の時などに別の処理を入れるんでなければ
変数を直接弄るんでもいいかな・・・。
変数を直接弄るんでもいいかな・・・。
546名前は開発中のものです。
2009/10/16(金) 11:40:43ID:/PDPq+0/ 入力値の正当性をチェックしたり、同時に変更しなければならないパラメータが1つじゃなかったり、
そういう可能性を考慮すると、関数を経由させたほうが便利。
そういう可能性を考慮すると、関数を経由させたほうが便利。
547名前は開発中のものです。
2009/10/16(金) 20:07:25ID:eJ9LLkd5 アクセッサ経由だとバグっぽい動きも引っ掛けやすいが、
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。
そうでないと大変そうだな。デバッグ一件で1時間とか悩みたくないし。
548名前は開発中のものです。
2009/10/18(日) 12:51:59ID:Yr/zm5ey >546
確かに使い方を間違えるってのはよく起こる
確かに使い方を間違えるってのはよく起こる
549名前は開発中のものです。
2009/10/25(日) 23:29:18ID:tIk7fQwv Compositeをゲームのシーン管理に使うのってどうやるんですか?
次に来るシーンを各クラスに設定しておいたりとか・・?
次に来るシーンを各クラスに設定しておいたりとか・・?
550名前は開発中のものです。
2009/10/25(日) 23:57:46ID:6R6DoQXi 何を聞いてるかがちょいと分からないけど
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。
Gems5巻にいいのが載ってたと思うよ。
とりあえず Google [スタックベースのシーン管理 gems]。
551名前は開発中のものです。
2009/10/26(月) 00:08:52ID:PLlfj58P というか前スレの260あたりか。Compositeかどうかも微妙だな。スマソ
552名前は開発中のものです。
2009/11/16(月) 14:29:49ID:FF5xAAX0553名前は開発中のものです。
2009/12/13(日) 15:40:07ID:Pf4hrG82 よく読んでないけどEmptyProject風に
void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}
void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}
って風にやったら問題あるの?
void Create(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki = new Jiki();
jiki->Create(lpD3DDEV);
}
void Draw(LPDIRECT3DDEVICE9 lpD3DDEV)
{
jiki->Draw(lpD3DDEV);
}
って風にやったら問題あるの?
554名前は開発中のものです。
2009/12/14(月) 01:36:46ID:etpwNEHL deviceの作成は一箇所のクラスでシングルトン
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ
無知なんだけど、デバイスて何個も必要になることあんの?
device呼び出しが長くなるが、面倒なら#define
俺はこんな感じ
無知なんだけど、デバイスて何個も必要になることあんの?
555名前は開発中のものです。
2009/12/14(月) 01:57:52ID:ViaP5WDz デバイスが複数あったら複数必要なんじゃね。
556名前は開発中のものです。
2009/12/14(月) 03:13:37ID:etpwNEHL その複数てのがさ、動的に管理しないといけないものなら複数個保持するクラスにすればいいし
そうでないなら同じようなクラスを用意するかな
便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる
まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな
そうでないなら同じようなクラスを用意するかな
便利だからグローバルにしてるわけだし
仕方ないとおもってる
必要な関数ごとにデバイス渡すとか面倒すぎる
まあ、何十個もデバイスがいるわけじゃないからできる荒い方法ではあるんだけどな
557名前は開発中のものです。
2009/12/14(月) 11:05:57ID:QE4kvqHr ボンバーマンを拡張して繋がれてるコントローラの数だけ
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。
プレイヤーが増えるとかいった仕様にしたいなら
コントローラのデバイスは動的に管理した方がいいと思う。
558名前は開発中のものです。
2009/12/14(月) 14:08:44ID:lLcah1pB プレイヤが一人でも全てのコントローラで操作できるようにしているが
(左右同時に押された場合は後からの入力を優先)
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな
(左右同時に押された場合は後からの入力を優先)
コントローラが壊れて常に右側に入力があるみたいな状態になるとうざったそうだな
559名前は開発中のものです。
2009/12/14(月) 15:35:13ID:ViaP5WDz 壊れたコントローラーはサポートしなくてもいいと思うよw
560名前は開発中のものです。
2009/12/21(月) 22:25:25ID:F5CW/HFF sharedptrみたいなの実装したいのですが、
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか?
boostソース読めってのは無しでお願いします。
それらしいことがのってる
more effective c++と、Accelarated C++
のどちらの本が役立ちそうでしょうか?
boostソース読めってのは無しでお願いします。
561名前は開発中のものです。
2009/12/21(月) 23:10:45ID:yYVJ9W7O >>560
「スマートポインタ」でググれば解説もサンプルも見つかるよ。
「スマートポインタ」でググれば解説もサンプルも見つかるよ。
562名前は開発中のものです。
2009/12/22(火) 01:26:27ID:Q5u6VebD >>560
なんで boost::shared_ptr 使わないの?
なんで boost::shared_ptr 使わないの?
563501
2009/12/30(水) 05:37:23ID:CHdRD74o >>552
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。
簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。
コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列(描画スクリプトみたいの)を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。
デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。
描画スクリプトっぽく進めてる。>>510 の言うとおりの方法。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
描画スクリプトみたいなのを作るほうがプログラム構造は単純になった。
>>511に書いたやり方は結局デバイスアクセス処理が分散していて大して煩雑さは改善されなかった。
簡単な2Dゲームだと描画は大部分が画像描画コマンドだけで構成されてた。思ってたより単純。
あとは少ないながらもカメラ位置変更コマンドと文字列描画コマンドも使った。
コマンド構造体を配列に突っ込んでカウンタを+1とかしてコマンド列(描画スクリプトみたいの)を作ってる。
あと画像描画コマンドでは描画すべき画像は番号で指定してる。番号に対応する画像を用意するのは解釈側の責任。
デバイスデータの引き回しはなるべく避けたかったので。
デバイスを関数間で無闇に引き回さなくても済むようになったので気が楽だし、
メモリデータの変更だけで描画内容が変わるのもおもしろい。
やって良かったと思ってる。
564501
2009/12/30(水) 22:40:42ID:CHdRD74o >>563を読み返したらちょっと違うところがあったので訂正。引用したこの文。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。
つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。
たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。
>各オブジェクトには描画スクリプトみたいのを作らせておいて、draw()がそれを解釈して描画とか?
自分の場合、描画スクリプトを作るのは「各オブジェクト」というより「各シーン管理オブジェクト」になった。
つまり
シーン管理オブジェクトが自身の所有する各オブジェクトの情報をアクセサ経由で読み取って
描画スクリプトみたいなものを組み立てる。
たくさんある細かい各オブジェクトに描画スクリプト的なものを作成させるのは責任というか依存性が散らばりすぎて複雑になる。
だから数の少ない管理オブジェクトがconst修飾済みの読み取り専用オブジェクトから得た情報だけを元に描画スクリプト的なものを組み立ててる。
565名前は開発中のものです。
2009/12/31(木) 08:32:52ID:QBEbvaiT sqliteを組み込んで、画像やモデルを相互変換可能な名前/IDで管理するとか夢が広がるわな
内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし
内部で使うのは番号(ID)だとしても、人間にとっては名前の方が分かりやすいし
566名前は開発中のものです。
2009/12/31(木) 15:10:35ID:wXwu3da7 >>565
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。
Google App Engine+Flash(Flex)でノベルもどき作ってるけど、まさにそれやってるわ。
GaeなんでsqliteじゃなくてGoogle Big Table使ってるけどね。
スクリプトはForthベースの俺々スクリプトだけど、
SilverlightだとPythonやRubyエンジンが使えるので、
次作るときはそっち使おうかなと思ってる。
567名前は開発中のものです。
2010/01/04(月) 06:09:33ID: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スレ行けばいいしな
たしか、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:39ID:JxRYn/a0 x 開発時代
o 開発自体
o 開発自体
569名前は開発中のものです。
2010/04/20(火) 00:42:02ID:pYU4LjYZ 前スレの最後のほうに出てた描画の話題って結局どうなりました?(928ぐらい)
570名前は開発中のものです。
2010/05/11(火) 16:43:34ID:mK0DmPV5571名前は開発中のものです。
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クラスを上手く組み合わせたりが出来ません……
こういう部分はどういう風にデザインするのがいいのでしょうか
どういう風にクラス分けすればいいか悩んでます
MAPクラス
Playerクラス
GameFrameクラスの3つがあって
mainループで
switch(MODE)
{
case TITLE:~~~~;break;
case MENU:~~~~;break;
case STAGE01:~~~~;break;
case STAGE02:~~~~;break;
.
.
.
}
みたいなことをしています。
各Stageに行くたびに、ステージ前処理と、ステージ後処理をしたいです
というとコンストラクタとデストラクタ……つまりはクラスを使えばいいんじゃないか?
という感じなのですが
Playerクラスの持っている情報と、操作関連を上手く融合させたり
Mapクラスの持っている情報と、Playerクラスを上手く組み合わせたりが出来ません……
こういう部分はどういう風にデザインするのがいいのでしょうか
572名前は開発中のものです。
2010/09/21(火) 03:43:33ID:l4LB0P7i STAGE01とSTAGE02を分ける必要は無いだろ。
ファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。
ファミコンの「ドラえもん」みたいな、1面と2面で全く違うゲームになるなら別だけど。
573名前は開発中のものです。
2010/09/23(木) 17:38:03ID:g80tUxgW まずそのswitch文をなんとかしよう。
TitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ?
TitleクラスとMenuクラスとStageクラスを追加するとか。
その上で、StageをPlayerとMapのメディエータとして実装する、というのはどうだ?
574名前は開発中のものです。
2010/12/04(土) 11:15:23ID:bbisnDl0575名前は開発中のものです。
2010/12/04(土) 14:39:29ID:t6Qi73J8576名前は開発中のものです。
2011/02/02(水) 03:54:28ID:uhRk4Rqb 保守
577名前は開発中のものです。
2011/05/20(金) 08:10:28.28ID:PnmAmJ/W 良スレ保守
578名前は開発中のものです。
2011/08/02(火) 05:21:50.11ID:jrRNxlOf Android開発でのパフォーマンスTips
http://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293
オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける
携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな
http://labs.techfirm.co.jp/android/cho/1283
http://labs.techfirm.co.jp/android/cho/1293
オブジェクト生成は避ける
インターフェースは使わない
スタティックメソッドを使う
クラス内部でgetter/setterは使わない
foreachループは気をつける
携帯端末だとオブジェクト指向をある程度捨ててパフォーマンスを稼ぐって形が
求められるみたい
こういう環境のゲームは、どういうデータ構造・クラス設計を採用すべきかってのも
気になるな
579名前は開発中のものです。
2011/08/02(火) 12:43:43.47ID:w6MyIbcF iアプリを思い出すなーw
580名前は開発中のものです。
2011/08/04(木) 13:31:14.84ID:OiYK4POH PS時代のゲーム開発みたいだなw
あの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてw
あの制限ばかりの時代を経験した世代の方が
開発に向いていたりしてw
581名前は開発中のものです。
2011/08/09(火) 01:57:38.36ID:/4Pi5/Qb 処理能力を操作に割かせるためにメモリに読めるだけ読むのかな
582名前は開発中のものです。
2011/08/09(火) 20:19:58.06ID:9GJ5MiVh それやりすぎるとアプリの切り替えをすることが多いスマフォじゃ
面倒が起きやすいんじゃないか
面倒が起きやすいんじゃないか
583名前は開発中のものです。
2011/08/15(月) 07:32:13.82ID:zPArLam8584名前は開発中のものです。
2011/08/21(日) 15:33:02.73ID:IUtyM1fd こないだ色々探したんだけど、糞アフィブログのリンク記事しか見つからなかった
キャッシュとかも見たんだけどさ
キャッシュとかも見たんだけどさ
585名前は開発中のものです。
2011/09/04(日) 02:30:22.85ID:novGGJeq586名前は開発中のものです。
2011/12/29(木) 00:00:54.00ID:hHcZWWbE よさげなスレなのに、あまり話が盛り上がってないな・・・
RPGのクラス設計で、「CharacterがItem(複数)を持っている」
状態を表したい時、
昔の自分は、
class Character {
List<Item> inventory;
}
って書いていたけど、最近の自分は、
class Inventory {
static List<Item> itemList;//全キャラクター分のアイテムを格納
Character character;
public int Count { get { itemListを数えて返す } }
public Item this[int no] { get { itemListのno番目を返す } }
}
class Character {
Inventory inventory;
}
って書くようになった。
どっちの書き方が多数派なのだろう?
RPGのクラス設計で、「CharacterがItem(複数)を持っている」
状態を表したい時、
昔の自分は、
class Character {
List<Item> inventory;
}
って書いていたけど、最近の自分は、
class Inventory {
static List<Item> itemList;//全キャラクター分のアイテムを格納
Character character;
public int Count { get { itemListを数えて返す } }
public Item this[int no] { get { itemListのno番目を返す } }
}
class Character {
Inventory inventory;
}
って書くようになった。
どっちの書き方が多数派なのだろう?
587名前は開発中のものです。
2011/12/29(木) 00:30:31.32ID:8pF0f6jp そこまでいったら、Interface抽出までやるかなー。
588名前は開発中のものです。
2011/12/29(木) 11:43:29.12ID:hHcZWWbE インタフェース抽出・・・
こんな感じ?
interface IGameData<T> {
int Count { get; }
T this[int no] { get; }
void Add(T arg);
void Remove(T arg);
}
(ジェネリックの書き方は適当ですw)
class Inventory : IGameData<Item> {
static List<Item> itemList;//全キャラクター分のアイテムを格納
Character character;
public int Count { get { itemListを数えて返す } }
(ry)
}
こんな感じ?
interface IGameData<T> {
int Count { get; }
T this[int no] { get; }
void Add(T arg);
void Remove(T arg);
}
(ジェネリックの書き方は適当ですw)
class Inventory : IGameData<Item> {
static List<Item> itemList;//全キャラクター分のアイテムを格納
Character character;
public int Count { get { itemListを数えて返す } }
(ry)
}
589名前は開発中のものです。
2011/12/29(木) 15:58:30.64ID:8pF0f6jp たぶんそんな感じー
590名前は開発中のものです。
2012/01/09(月) 19:11:25.37ID:7/HYejXG591名前は開発中のものです。
2012/01/10(火) 01:04:51.32ID:Lc/KjEb7 プログラム自体全くの素人なんで
取り敢えず3D空間上に地面を作ってその上をキャラクタが歩き回れるプログラムを作ったんだけど
地面を生成する際に必ず必要になる地面の各頂点の座標だけで1面につきfloat1つ分で4byte取られるんだよね
そこでふと思ったんだけど
エルダースクロール2ってどうやってそこらへんの情報を扱ってるんだろ
あのゲームのマップの大きさを計算してみたら一辺317Kmもあるみたい
1面を5m四方として扱ってもマップ全体を表すのに16078240000byteも必要
エントロピー圧縮しても1/15位が限界だと思うから約1GB
本当はこれらにさらに木や草の位置、地面のテクスチャの種類なんかが必要なんだよね
それなのにtes2のデータサイズを見ると160MBしかない
何かマップ設計自体が特殊なんだろうか
取り敢えず3D空間上に地面を作ってその上をキャラクタが歩き回れるプログラムを作ったんだけど
地面を生成する際に必ず必要になる地面の各頂点の座標だけで1面につきfloat1つ分で4byte取られるんだよね
そこでふと思ったんだけど
エルダースクロール2ってどうやってそこらへんの情報を扱ってるんだろ
あのゲームのマップの大きさを計算してみたら一辺317Kmもあるみたい
1面を5m四方として扱ってもマップ全体を表すのに16078240000byteも必要
エントロピー圧縮しても1/15位が限界だと思うから約1GB
本当はこれらにさらに木や草の位置、地面のテクスチャの種類なんかが必要なんだよね
それなのにtes2のデータサイズを見ると160MBしかない
何かマップ設計自体が特殊なんだろうか
592名前は開発中のものです。
2012/01/10(火) 01:20:07.70ID:rFVH40vL 常にそのデータをメモリ上に保持しておかなければいかんわけじゃないだろ……
100km先のデータなんて近づいてきたら読めばいいじゃない
100km先のデータなんて近づいてきたら読めばいいじゃない
593名前は開発中のものです。
2012/01/10(火) 02:51:27.11ID:tQJO4ffg floatじゃなくてhalf floatなのかもしれん。これだけで半分になる。
あとは、エントロピー符号化の前に、
曲面補完とか使って圧縮かけてるのかもしれない。
ビットマップで曲線を保持すると解像度分のデータが必要だが、
ベジェ曲線なんかで表せば、上手くいけばハンドル数個分で済む。
FUELなんかはたぶんこういう方法使ってて、川が途中で途切れてたりするところが目立つのはそのためだと思う。
全部俺の勝手な予想だが、いろいろ工夫はしてると思うよ。
あとは、エントロピー符号化の前に、
曲面補完とか使って圧縮かけてるのかもしれない。
ビットマップで曲線を保持すると解像度分のデータが必要だが、
ベジェ曲線なんかで表せば、上手くいけばハンドル数個分で済む。
FUELなんかはたぶんこういう方法使ってて、川が途中で途切れてたりするところが目立つのはそのためだと思う。
全部俺の勝手な予想だが、いろいろ工夫はしてると思うよ。
594名前は開発中のものです。
2012/01/10(火) 20:26:05.97ID:Wi6HPUjx >>590
ん、ごめん。判りにくいな〜と思いつつ手抜きしてしまった。
こんな感じのコーディングを想定していました。
class Inventory : IGameData<Item> {
static List<Item> itemList;
//クラスメンバ
Character character;
//プロパティ
public int Count { get {
int num = 0;
for(int i = 0; i < itemList.Count; i++) num += (itemList[i].Character == this.character)? 1 : 0;
return num;
} }
public Item this[int no] { get {
for(int i = 0; i < itemList.Count; i++) if (itemList[i].Character == this.character) if (--no < 0) return itemList[i];
throw new Exception();//noがオーバーしてたら例外(とかreturn null;とか)
} }
}
class Item { public Character Character; }
class Character { Inventory inventory = new Inventory(this); }
結局、呼び出す側からの見た目は、
class Inventory : List<Item> { }
class Character { Inventory inventory = new Inventory(); }
とあまり変わらないんだけどね・・・
ん、ごめん。判りにくいな〜と思いつつ手抜きしてしまった。
こんな感じのコーディングを想定していました。
class Inventory : IGameData<Item> {
static List<Item> itemList;
//クラスメンバ
Character character;
//プロパティ
public int Count { get {
int num = 0;
for(int i = 0; i < itemList.Count; i++) num += (itemList[i].Character == this.character)? 1 : 0;
return num;
} }
public Item this[int no] { get {
for(int i = 0; i < itemList.Count; i++) if (itemList[i].Character == this.character) if (--no < 0) return itemList[i];
throw new Exception();//noがオーバーしてたら例外(とかreturn null;とか)
} }
}
class Item { public Character Character; }
class Character { Inventory inventory = new Inventory(this); }
結局、呼び出す側からの見た目は、
class Inventory : List<Item> { }
class Character { Inventory inventory = new Inventory(); }
とあまり変わらないんだけどね・・・
595名前は開発中のものです。
2012/01/10(火) 22:24:32.24ID:Lc/KjEb7596名前は開発中のものです。
2012/01/10(火) 23:12:32.40ID:Wi6HPUjx597名前は開発中のものです。
2012/01/10(火) 23:17:34.89ID:Wi6HPUjx 言葉足らずすぎる気がしたので補足w
広い領域を、例えば5キロ平方に区切って、
隣の領域と連続性を保つため外周だけはデータを保持。
その内側の凹凸は動的生成、って意味です。
広い領域を、例えば5キロ平方に区切って、
隣の領域と連続性を保つため外周だけはデータを保持。
その内側の凹凸は動的生成、って意味です。
598名前は開発中のものです。
2012/01/11(水) 01:47:31.95ID:dDo0BLDQ >>596
それ単独では制御が難しいかも。町を作りたいのに平らな地形が得られない、とか。
平らな地形の部分だけ追加データで入れるとかするのかな。
>>595
線→面への拡張は、概念はそんなにフクザツじゃない。
補間方法はベジェじゃなくてもスプラインでもいいけど、単純にXY両方でデータの無いところを補間するだけだと思う。
ただ当然実行時計算量とデータサイズのトレードオフはある。
TES2は分からんけど、TES4と同系統のエンジンのFO3なんかみると、
たまにそういう曲面のエッジが誤差か調整不足かで浮いてるところがマップのところどころにあった気がする。
これは曲面補間かどうかは分からないけども。
SourceEngineなんかも似たような技術が実装されてるし、けっこう昔からある技術なのかな?
Game Programming Gemsとか探したら取り上げられてるかもね。
それ単独では制御が難しいかも。町を作りたいのに平らな地形が得られない、とか。
平らな地形の部分だけ追加データで入れるとかするのかな。
>>595
線→面への拡張は、概念はそんなにフクザツじゃない。
補間方法はベジェじゃなくてもスプラインでもいいけど、単純にXY両方でデータの無いところを補間するだけだと思う。
ただ当然実行時計算量とデータサイズのトレードオフはある。
TES2は分からんけど、TES4と同系統のエンジンのFO3なんかみると、
たまにそういう曲面のエッジが誤差か調整不足かで浮いてるところがマップのところどころにあった気がする。
これは曲面補間かどうかは分からないけども。
SourceEngineなんかも似たような技術が実装されてるし、けっこう昔からある技術なのかな?
Game Programming Gemsとか探したら取り上げられてるかもね。
599名前は開発中のものです。
2012/01/13(金) 08:38:17.24ID:q77afuhx >>598
なるほど、ってことは、
街の地面:整地されてるから、メッシュを大きく平らに
平原とか砂漠とか:メッシュを大きく取って、細かい部分は補間なり動的生成なり
山岳みないな凹凸がある地形:メッシュを細かく
って感じに・・・
(と言っておいてなんですが、メッシュの大きさを変えるのは、プログラムが汚くなりそうw)
なるほど、ってことは、
街の地面:整地されてるから、メッシュを大きく平らに
平原とか砂漠とか:メッシュを大きく取って、細かい部分は補間なり動的生成なり
山岳みないな凹凸がある地形:メッシュを細かく
って感じに・・・
(と言っておいてなんですが、メッシュの大きさを変えるのは、プログラムが汚くなりそうw)
600名前は開発中のものです。
2012/01/13(金) 23:38:29.70ID:sS8+h2Ga >>599
偏った例で恐縮だけど、SourceEngineのディスプレースメントサーフェイスは
分割数は2,4,8とか2の倍数固定でそれほど柔軟ではないし、穴あけれないとか制約はある。
だからその辺はレベルデザイナーのほうで調節する感じ。
ただしスムージングはかけれるから、たぶん補間はしてる。
たぶんゲームエンジンはどれも似たような仕組みは実装してると思うよ。
ディスプレースメントなら頂点4つ(△ポリゴン2つ)+差分テクスチャマップをシェーダーにぶち込んで高速処理、とか
そんなんだと思う。
あくまで予想だけど!
偏った例で恐縮だけど、SourceEngineのディスプレースメントサーフェイスは
分割数は2,4,8とか2の倍数固定でそれほど柔軟ではないし、穴あけれないとか制約はある。
だからその辺はレベルデザイナーのほうで調節する感じ。
ただしスムージングはかけれるから、たぶん補間はしてる。
たぶんゲームエンジンはどれも似たような仕組みは実装してると思うよ。
ディスプレースメントなら頂点4つ(△ポリゴン2つ)+差分テクスチャマップをシェーダーにぶち込んで高速処理、とか
そんなんだと思う。
あくまで予想だけど!
601名前は開発中のものです。
2012/06/10(日) 17:27:25.03ID:m7xNzVPO 特定の条件がなんなのか不明だけど、eventListenerとかgetInputとかで良いんじゃないの
設計としてはおかしくはない
設計としてはおかしくはない
602名前は開発中のものです。
2012/06/10(日) 17:28:33.69ID:m7xNzVPO 誤爆失礼
603名前は開発中のものです。
2012/10/13(土) 15:00:59.36ID:PbMUmxTV 保守
604名前は開発中のものです。
2014/08/05(火) 01:15:42.94ID:6YHbcuwm タイル形式の箱庭データ配置ってどう思う?
メモリーが少なかった頃の遺物?
高速化のために未だに使う事ってある?
メモリーが少なかった頃の遺物?
高速化のために未だに使う事ってある?
605名前は開発中のものです。
2014/08/05(火) 12:28:28.50ID:mp7VEmF3 良くも悪くもゲームが記号的になるね
606名前は開発中のものです。
2014/08/18(月) 17:56:46.58ID:/xfKqDtl Androidでゲームを作ってるんですが、クライアント・サーバー型のゲームのデータを
データベースで管理しようとすると武器の名前とかいらないと思って、端折りまくってたら
武器のIDだけのテーブルになってしまいました。(パラメータはクライアントで持ってます)
ここまでくるとテーブルとして参照するだけcpuの無駄だと思い、
テーブルを消していくと他のテーブルと全く関わり合いのないテーブルが出てきます。
(例えば武器を売った時にいくらお金が手に入るか?とか)
そうすると何か自分の考えてる構造に不安を覚えるのですが、これは正しいのでしょうか?
「データベースの外とリレーション貼ってる」って考えれば自分を納得させられるような気もしないんですが・・
データベースで管理しようとすると武器の名前とかいらないと思って、端折りまくってたら
武器のIDだけのテーブルになってしまいました。(パラメータはクライアントで持ってます)
ここまでくるとテーブルとして参照するだけcpuの無駄だと思い、
テーブルを消していくと他のテーブルと全く関わり合いのないテーブルが出てきます。
(例えば武器を売った時にいくらお金が手に入るか?とか)
そうすると何か自分の考えてる構造に不安を覚えるのですが、これは正しいのでしょうか?
「データベースの外とリレーション貼ってる」って考えれば自分を納得させられるような気もしないんですが・・
607名前は開発中のものです。
2014/08/18(月) 18:09:33.31ID:/xfKqDtl 砂漠とか海の3D空間で遠景を表現するのってどうすればいいですか?
地平線とスカイドーム(スカイボックス?)の切れ目が不自然になって、
ちょっとでもカメラのY座標を高くすると地面の切れ目もはっきり目立ちます。
fogは遠くのオブジェクトも見たいのであまりしたくありません。
http://livedoor.blogimg.jp/terashima999/imgs/1/3/1321e840.jpg
http://yoda.dip.jp/Diary/200707/20070711_AC6_1.jpg
↑こういうの
地平線とスカイドーム(スカイボックス?)の切れ目が不自然になって、
ちょっとでもカメラのY座標を高くすると地面の切れ目もはっきり目立ちます。
fogは遠くのオブジェクトも見たいのであまりしたくありません。
http://livedoor.blogimg.jp/terashima999/imgs/1/3/1321e840.jpg
http://yoda.dip.jp/Diary/200707/20070711_AC6_1.jpg
↑こういうの
608名前は開発中のものです。
2014/08/23(土) 15:13:29.78ID:yctiE/PZ >>607
LOD(level of detail)を使って遠くまで描画すればいいと思う。
ちょっと古い記事だけど下記のサイトが参考になるんじゃね?
3Dゲームファンのための「ワンダと巨像」グラフィックス講座
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm
の「■地形のLODシステムと読み込み」の項目
LOD(level of detail)を使って遠くまで描画すればいいと思う。
ちょっと古い記事だけど下記のサイトが参考になるんじゃね?
3Dゲームファンのための「ワンダと巨像」グラフィックス講座
http://game.watch.impress.co.jp/docs/20051207/3dwa.htm
の「■地形のLODシステムと読み込み」の項目
609名前は開発中のものです。
2014/08/23(土) 18:35:40.53ID:w69tOcJ6 なるべく地平線や水平線の近くまで描画したいんでしょ?
自分の場合は
/ ̄ ̄ ̄\
/: :\
/: .: a .: .:\
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
↑↑
b c
a:視点の位置
b:フォグの開始
c:フォグの終了
空は角錐台状につくってaのxy座標に追従
bを遠くにとれば遠くまで描画できるし、
空の天辺がフォグで霞むこともなくなる。
自分の場合は
/ ̄ ̄ ̄\
/: :\
/: .: a .: .:\
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
↑↑
b c
a:視点の位置
b:フォグの開始
c:フォグの終了
空は角錐台状につくってaのxy座標に追従
bを遠くにとれば遠くまで描画できるし、
空の天辺がフォグで霞むこともなくなる。
610名前は開発中のものです。
2014/08/24(日) 14:20:41.69ID:AJZlAWRG >>609
視点のY座標が高くなると、地平線と空の間に描画されない部分が出てきてしまいます・・
視点のY座標が高くなると、地平線と空の間に描画されない部分が出てきてしまいます・・
611名前は開発中のものです。
2014/08/25(月) 00:41:57.10ID:2KTfo870 あぁXZ座標か。兎に角視点の高度はに角錐台は影響されない方向で。
612名前は開発中のものです。
2014/08/26(火) 13:52:23.48ID:qHUiU/pW いや、角錐台は影響されないんですけど、
aが立ってる地面とかは高度上げれば上げるほど離れていくわけじゃないですか
そうすると地面のポリゴンと角錐台がどんどん離れていって
地面のポリゴンの終端があらわになってしまいます。
街を探検するようなゲームなら全く問題ないんですが
海とか航空機とかで「地平線を表現したい」となった時にfogにも頼れず(霞ませたいわけじゃない)どうしたものかと・・・
LODで全力で軽量化しつつ、XZ座標1000000,1000000とかすごい桁のパラメータで遠くに設置してもいいんですが、
カメラのトリム距離もネックになってて、それだけの距離を1.0~0.0に収めると浮動小数点型の誤差?なのか、
遠景のZバッファによる描画が不自然になります
近景用と遠景用で2回判定してもいいんですが(通常ポリゴンとLODポリゴンで分けられたら一石二鳥かも)
なんだか王道から離れていってるようで、他の人がどう対処してるのかなと
aが立ってる地面とかは高度上げれば上げるほど離れていくわけじゃないですか
そうすると地面のポリゴンと角錐台がどんどん離れていって
地面のポリゴンの終端があらわになってしまいます。
街を探検するようなゲームなら全く問題ないんですが
海とか航空機とかで「地平線を表現したい」となった時にfogにも頼れず(霞ませたいわけじゃない)どうしたものかと・・・
LODで全力で軽量化しつつ、XZ座標1000000,1000000とかすごい桁のパラメータで遠くに設置してもいいんですが、
カメラのトリム距離もネックになってて、それだけの距離を1.0~0.0に収めると浮動小数点型の誤差?なのか、
遠景のZバッファによる描画が不自然になります
近景用と遠景用で2回判定してもいいんですが(通常ポリゴンとLODポリゴンで分けられたら一石二鳥かも)
なんだか王道から離れていってるようで、他の人がどう対処してるのかなと
613名前は開発中のものです。
2014/08/26(火) 21:43:36.70ID:HN5WQ9H7 / ̄ ̄ ̄\
/: a :\
/: .: .: .:\
 ̄ ̄ ̄ ̄ ̄←地面が小さいの?
地面をフォグの終了まで描画すればいいと思うけど…
/: a :\
/: .: .: .:\
 ̄ ̄ ̄ ̄ ̄←地面が小さいの?
地面をフォグの終了まで描画すればいいと思うけど…
614名前は開発中のものです。
2014/08/27(水) 17:08:35.72ID:r0T91QdR ぢめんをちきゅうみたいにまるくするのはどう?
615名前は開発中のものです。
2014/08/28(木) 17:39:54.03ID:bFGeiPpW616名前は開発中のものです。
2014/08/28(木) 21:14:49.09ID:m/S7fPOm 上のは船上だから視点は高くても数十m。水平線は結構近いと思うよ。
下のは数kmとかじゃないかな。建物を縮小というか単純に距離が離れてると思うけど…
それでもフォグを使って描画範囲を制限して、描画対象を削減してる。
下のは数kmとかじゃないかな。建物を縮小というか単純に距離が離れてると思うけど…
それでもフォグを使って描画範囲を制限して、描画対象を削減してる。
617名前は開発中のものです。
2014/08/29(金) 17:47:40.60ID:PQKddMMr >>616
今実際に水平線を描画してみたんですが、遠くの船が空中に浮いてるように見えます
海面の描画外で船を描画するとスカイドームの背景が船底より下に描画されます
海面にかけるフォグ色とスカイドームに貼り付けるテクスチャの水平部分に
同じ色を使っていい感じにごまかせないか試してみたんですが、
海面の上から船底が描画されるのでやっぱり違和感があります
今実際に水平線を描画してみたんですが、遠くの船が空中に浮いてるように見えます
海面の描画外で船を描画するとスカイドームの背景が船底より下に描画されます
海面にかけるフォグ色とスカイドームに貼り付けるテクスチャの水平部分に
同じ色を使っていい感じにごまかせないか試してみたんですが、
海面の上から船底が描画されるのでやっぱり違和感があります
618名前は開発中のものです。
2014/08/29(金) 22:39:55.32ID:Me2CR80H 船を描画するときフォグは無効にしてるの?
船全体がフォグの終了の向こうに出るまでは、フォグを有効にして船を描画。
向こうに出たら描画そのものをスキップしないとダメだと思うよ。
船全体がフォグの終了の向こうに出るまでは、フォグを有効にして船を描画。
向こうに出たら描画そのものをスキップしないとダメだと思うよ。
619名前は開発中のものです。
2014/08/30(土) 08:34:58.97ID:RhmAUk4c >>617
船のモデル側に海面ポリゴン(船底を隠す分だけ)をくっつけとけば、いいんじゃね?
船のモデル側に海面ポリゴン(船底を隠す分だけ)をくっつけとけば、いいんじゃね?
620名前は開発中のものです。
2014/08/30(土) 11:22:17.06ID:5AIFhixX621名前は開発中のものです。
2014/09/01(月) 07:02:26.23ID:raj97bmv 状況が良くわからないけど、こういうこと?
_目____空
__視視__空
____視視空
______海視
______海_視視
______海___視視_________浮船
海海海海海海海海海海海海海海海海海海海海海海海海ー水平な水平線
______________視視
________________視視
__________________\
___________________見た目の水平線
_目____空
__視視__空
____視視空
______海視
______海_視視
______海___視視_________浮船
海海海海海海海海海海海海海海海海海海海海海海海海ー水平な水平線
______________視視
________________視視
__________________\
___________________見た目の水平線
622名前は開発中のものです。
2014/09/01(月) 07:04:40.93ID:raj97bmv ちょっと修正
_目____空
__視視__空
____視視空
______海視
______海_視視
______海___視視_________浮船
海海海海海海海外外外外外視視外外外外外外外外外外外ー水平な水平線
______________視視
________________視視
__________________\
___________________見た目の水平線
_目____空
__視視__空
____視視空
______海視
______海_視視
______海___視視_________浮船
海海海海海海海外外外外外視視外外外外外外外外外外外ー水平な水平線
______________視視
________________視視
__________________\
___________________見た目の水平線
623名前は開発中のものです。
2014/09/06(土) 11:55:58.35ID:khJXlvEe624名前は開発中のものです。
2014/09/20(土) 12:54:30.99ID:aka1I6g9625名前は開発中のものです。
2015/03/16(月) 18:52:45.04ID:ELGRcANR すごい大雑把な質問なんだけど
ゲーム設計において外部ライブラリの扱いってどうやるの?
ひとつだけならそれに従えばいいかもだけど複数になるとどうしても設計が汚くなってしまう
ゲーム設計において外部ライブラリの扱いってどうやるの?
ひとつだけならそれに従えばいいかもだけど複数になるとどうしても設計が汚くなってしまう
626名前は開発中のものです。
2015/12/19(土) 14:31:11.96ID:uNL25Qjh プログラマはMacを使ってるってマジ?
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/
627名前は開発中のものです。
2017/12/31(日) 20:22:02.22ID:/rN76OKL 簡単にお金が稼げる方法興味ある人だけ見てください。
グーグル検索⇒『来島のモノノリウエ』
A8RNONREKQ
グーグル検索⇒『来島のモノノリウエ』
A8RNONREKQ
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【速報】習主席とトランプ大統領が電話会談 台湾問題について [ニョキニョキ★]
- 【東京・足立の車暴走】赤信号無視か 危険運転致死傷疑いも視野に捜査 逮捕された職業不詳の男性(37)は精神疾患で通院歴も ★2 [ぐれ★]
- 人生初黒星の神童、那須川天心がリング上で土下座 [牛丼★]
- 中国人「『日本は危ないから行かないように』と言われたが、日本に来たらとても安全だった」 [お断り★]
- 毛寧(もう・ねい)報道官 「日本は実際の行動で対話への誠意を示すべき」 中国、高市首相に改めて発言撤回を要求 [ぐれ★]
- お布施の75%が葬儀社の手数料に 価格表を入手 僧侶も警鐘 [ぐれ★]
- ネトウヨの本心「ぶっちゃけLGBT推進を取り消すとか自分に関係ないしどうでもいい。そんな事よりJK、JCとヤッてもOKな世の中に戻せ!」 [377482965]
- 「琉球有事は中国有事」 中国のネトウヨが拡散 これには日本のネトウヨ叩きのめされる [241672384]
- 【号外】習近平、米大統領のトランプと首脳会談を行う!日本のの武力による台湾脅しついて共有の追及をする意思統一でおこなう [339712612]
- ミャンマー軍事政権「日本にはアジアで犯した罪に対する反省や責任感がない」高市答弁を批判 [834922174]
- まったりおじゃる丸待機スレ🏡
- 【速報】高市「アタシぜっったい謝らないからッ!!」→中国焦る [308389511]
