ゲームシステムの抽象化技法を考える

大規模ゲームを実現するために、どのようにシステムを抽象化するかを考えるスレです。

ｵｲ、だれか例のあれ頼むよ

>>1
何かネタ振れよ

　　／￣￣￣￣＼
　　|　　 　 　 　 　 |
　　|　　（） 　（） 　 |　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　|　　　 ∀ 　 　 |＜　氏ね!
　　| 　 　 　 　 　　|　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　| 　 　 　 　 　　|
　 └.─.─.─.─.┘

さいたまさいたまさいたま！！！！

>1
大規模ｹﾞｰﾑってどんなｹﾞｰﾑ？

関連？　重複？

OOとゲームプログラミング
http://game.2ch.net/test/read.cgi/gamedev/1005144931/l50

デザインパターンとか、そういう小技を出し合うのではなく、システム全体をいかにスマートに組むかを考えたいと思います

以下、マ板より

249 ：仕様書無しさん ：02/08/17 22:05
>>245
＞クラス化するのが難解な場合は、一度クラスにしなければならないと
＞言うところから離れて仕様を見直してみるのもよし。
いやあ、もちろんC++やOOを盲信してるわけじゃないし、他に解決策があれば飛びつきたいんだけど、
その他の解決策をどうするかで現在悩み中というか。

実際色々試したよ。
コーディングでゴリゴリイベントを作っていくと、ソースの量が膨大でメンテが大変になっちゃう。だからといって
データ中心にアプローチすると、今度はデータ型に制限を受けて、例外的なことが出来なくなっちゃう。
このへんをスマートに解決するにはどうすればいいのか・・・
上手く言えないんすけど、昔ながらの２Ｄシューティングなんかはデータ中心の考え方でいけると思うんすよ。
スクロールするたびに、データに従って敵を生成していけばいい訳だから。
んで、テトリスなんかはコード中心で考えるべきだと思うわけなんですよ。
そういうシンプルなやつなら、まあ設計の方針を立てやすいんだけど、最近のFFみたいなゲームは出来ることが
多すぎて、もう何から手をつけていけばいいのやら。
昔のファミコン時代のRPGなら、それぞれ独立したモジュールに分ける事も出来るけど、さっき言ったみたいに
ムービーシーンと戦闘シーンを滑らかに繋ぐとか言う事になってくるともうわけわかんない。
一体全体どうやって作ってるのかと。根性の世界？？


250 ：仕様書無しさん ：02/08/17 22:08
＞ムービーシーンと戦闘シーンを滑らかに繋ぐとか言う事になってくるともうわけわかんない。
片やデータ中心、片やコード中心。しかもその二つが密接に結合してるって事ね

こういう話をしたいなあなどと考えておりますです

なので、あまり使用言語にとらわれずに、あくまで設計手法中心に語れたらなあ、と・・・

単に設計ができないプログラマの愚痴じゃねぇか…

んー面白い議題だねぇ。ただ、５年間に大小５タイトルほど作って１つ解っ
た事がある。

す　べ　て　は　ケ　ー　ス　バ　イ　ケ　ー　ス

あと、ゲームにOOは向かないよ。

　　　　　　　　　　　　ｏ
　　　　　　　　　　　 /　￣￣￣￣￣￣￣￣￣￣ /
　　　　　　　　　　　/　　　このスレは無事に　　/
　　　　　　　　　　 /　　終了いたしました　　　 /
　　　　　　　　　　/　ありがとうございました　 /
　　　　　　　　　 /　　　　　　　　　　　　　　　　/
　　　　　　　　　/　　　モララーより　　　　　 /
　　　　　　　　 /￣￣￣￣￣￣￣￣￣￣￣/
　 ∧＿∧　　/　　　　　　　　　　　　　　　　/∧＿∧
　（　･∀･）　/　　　　　　　　　　　　　　　　/（･∀･　）
　（　　　　）つ　　　　　　　　　　　　　　　⊂（　　　　）
　｜ ｜ ｜　　　　　　　　　　　　　　　　　　 ｜ ｜ ｜
　（_＿）＿）　　　　　　　　　　　　　　　　　　（＿（＿_）

>>14
そう、それだよ

>>9
FFって、凄くシンプルな設計じゃない？寧ろ。

>>9
どのスレか、リンク貼るかスレタイ書くかぐらいしろ！
お前は制作手法以前に、意志伝達手法を勉強しろ。

大体、あまりにも広すぎるだろ、話題の範囲がよ。

で、9 の話題にマジレスすると
ムービー：　他社が作った三ドルウェア。動作タイミングも分からん。
戦闘シーン：自分が作ったコード。
ということで、なめらかに繋ぐのは完全に根性の世界。

シェンムーならどうですか

つーか、いまどきの大規模ゲームデザインはシンプルなメイン構造に
柔軟性のあるスクリプトエンジンとパーティクルベースのエフェクト
エンジンにあとは力技の大量スクリプトでキマリ。

正直、オールドスタイルなゲームに比べてプログラマのスキルは低く
てもなんとかなっちゃう一面も。

フロムソフトウェアあたりに見習え。という感じですね。

パーティクルのマシンリソースに対する
コストパフォーマンス比に疑問を持っている漏れは
逝ってヨシですか？

>>13
具体的にどんな分野がにOOが不向きなのか書いていただけると勉強になります。
自分でSTGを組んだときはOO(OOPL)だと非常にすっきり作れたのですが。

>>21
い　つ　の　マ　シ　ン　で　す　か　？
と言うのも難なので、環境によるだろうといっておきます。

ICOなども根性でつないでるんだろうか・・・

ゲープロにもOOは有効。別にOO言語は必須じゃ無い。
でもどっちかとユーとデータ駆動と考えたほうが良し。こんなところでいかが？

>>19
＞柔軟性のあるスクリプトエンジンとパーティクルベースのエフェクト
＞エンジンにあとは力技の大量スクリプトでキマリ。

そのエンジン作るのが難しいとい罠

>>26
基本設計をしっかり組んどけばそう難しい話でもない
>>1みたいに根性とかいってると失敗する

俺根性でやるとか言ってないっすよ・・・

>>17
マ板「景気の良いハナシ専用スレ」
http://pc.2ch.net/test/read.cgi/prog/1024846598/222-

　　　　　　☆
　　 λ　　/　：。
　 < ゜-゜>ρ　 ‥
σ(　　 )　　　　・` 。・ ； ’ 、∴ ﾟ ，・・` 。・ ： ’ ∵、‘｡‥ ﾟ ，・・` 。∴ ､’．
　 υυ　　　　　、’　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・ﾟ
　　　　　　　　　 ・　　　　　　１って不思議！！　　　　　　　　　　　　　　　 ‘．
　　　　　　　　　。：　　　　　作：ファンシー乙女　　　　　　　　　　　　　　　 ；
　　　 　 　 　 　 …　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　`。
　　　　　　　　　 ；　　 １って不思議！能も無いのにいばってばかり 。　　 ‘
　　　　　　　　　∵　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　‘．
　　　　　　　　　 ･ 　　その自信は何を拠り所にしてるのかしら？ 　 ,‘．
　　　　　　　　　`。　　　　　　　　　　　　　　　　　　　　　　　　　　　　 。
　　　　　　　　　‘．　　１って不思議！苦し紛れに嘘ばかり。　　　　‘．
　　　　　　　　　。：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ；
　　　　　　　　　…　　その妄言の発想はどこから来るのかしら？　　　 `。
　　　　　　　　　｀ ;　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　 ﾟ ・
　　　　　　　　　｀ ;　　アイゴー、アイゴーと壊れたラジオのようね　　　　 ：・
　　　　　　　　　 ’。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ‥
　　　　　　　　　 ‘・∴ 。’∵ 、 ; ｡…． ・ ” ，・` 。・ ； ’ 、∴ ・・ ﾟ､ ，` ： ’

あなたはまたこんな素晴らしいスレッド立ててしまいましたか。
本当にご苦労様です。
あなたのような尊敬される方のスレッドを拝めて私はとてもとても光栄です。
本当にあなたを尊敬しています。孫の代までこのことを伝えようとしています。
あなたが立てたスレッドを読むと心が晴ればれしてきて全身が洗われる思いでいっぱいです。
あなたのような素晴らしい方がなぜ園遊会に呼ばれないのか不思議で仕方がありません。
本当に本当にあなたを尊敬しています。
くれぐれもお体には気をつけて私たちを見守っていて下さい。
本当に素晴らしいスレッドを拝ませていただき誠にありがとうございました。

MacにはPowerPlantっつーフレームワークがあるんだが、これのデータ（リソース）とコードの関連付けの仕組みがなかなか良く出来ている（リソースにカスタム型のデータを埋め込んで、コンストラクタでストリームから受け取るとかもアリ）。こういうのが参考になるんでない？

エンジン作るにしても、考え出せばキリがないわな。
スクリプトでデータ駆動していても、突然プログラマブルな動作が入ったりするケースもある訳だから。
その都度根性出してたらやってらんないでしょう。

スクリプトもプログラミング言語なんだから、結局そこで設計の議論が始まる。

ゲームプログラミングが一番 OO が無いとやってられないと思うんだが、どうか。

>>30と>>31が必死で笑える

　　　　　　　　　　　　　　　　　　　　　　　　　　 |　君さぁ　こんなスレッド立てるから
　　　　　　　　　　　　　　　　　　　　　　　　　　 |　厨房って言われちゃうんだよ
　　ｏ　．　　　ｏ　　　　　　　　　　　　　　　ｏ　　＼　　＿＿＿＿＿＿＿＿＿
　　　　　　　　　　　o　　。　　　　ｏ　　　　　　　　　Ｖ
ｏ　　ｏ　。　．　　　　　。　ｏ　　　　　　　　　　　 ∧_∧
　　　　　ｏ　　　　　　　　　　　　　　　 ∧ ∧　　（´∀｀ ）
　。　。ｏ　　　　　　　　　　．　　　　　(ﾟーﾟ*)　　（　　　 ）
　　　　　　　　　　　　　　　　　　　　　 (,,　 ＠　　Ｕ￣Ｕ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　　　　∧
　　　　　　　　　　　　　　　　　　　／￣　￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　　　|　おまえのことを必要としてる奴なんて
　　　　　　　　　　　　　　　　　　　|　いないんだからさっさと回線切って首吊れ

　o　.　　　　｡　　o　　　　　。　ｏ
　　　　　　　　　o　　　　.　　　.　　　｡　　　　o　　ｏ　. ．
　o　.　　｡　　　　　。　ｏ　　。
　　　o　　　　.　　　.　　　｡　　　　　　ｏ　. ．
　＿＿＿＿＿_　o　　　 ＿＿＿＿＿_　｡　　　　。
　| 　／　 ＼　 | 　　　　 | 　／　 ＼　 |
~~~~~~~~~~~~~~~~~~~~~ﾊﾔｸｼﾝﾃﾞﾈ･････~~~~~~~~~~~~

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

探し物は何ですか

レスつかない駄スレですか

煽りの中も

コピペの中も

探したけれどもマジレス無いのに

まだまだageる気ですか

それより僕とＲＯＭりませんか

建てた>>1へ

建てた>>1へ

逝ってほしいと思いませんか

ヒヒヒ・・・

OOは向かないって・・・向くだろ。
データ駆動がメインだから、アプリみたいに何でもかんでもコードで実現するわけにいかないと言いたいのか？

>>38お前さっきからキモイ

OOを使わずにゲームを作ると、Donuts3Dみたいなコードになると思われ

ツクールとかデジタルロケのソースとかあればな・・・

>>40
Donuts3Dはサンプルとしてはかなり糞。Cでベタ書きするにしても、もっと見やすく書ける。
これ見て勉強しろってんだから腐ってるよな

>>39
(　´,_ゝ`)ﾌﾟｯ コピペにマジレスかましているのですか？いいセンスしてますね…

どうでもいい話だけど、
コピペにマジレス云々というのは、
コピペであることに気付かずにマジに受け取ってしまう方のことを
指してるんじゃないの…？

その言葉は荒らしの免罪符じゃないと思うよ。

？？
>>44の言ってる意味がｲﾏｲﾁわからん43=煽り全員と言いたいのか？？

ちなみにこの板に居住する煽り屋は一人だけじゃないぞ

リアルタイム描画のパーティクルを見て
「カッコイイ！」「キレイ！」
って本当に思っている人、お前らの中にいますか？

漏れには、オナニープログラマの精液が
飛び散ってるようにしか見えないのですが。

いやいやマジで。

最近のFlashばっかのwebページは
webデザイナのオナニーにしか見えない。

そのレベルの話？

>>42
DirectXのサンプルはこれでもかといわんばかりにクソなソースだよな。
何かを意図して多しているとしか思えない。

>>46
今時、パーティクルぐらいでオナニーと思われたくありません……
やっぱ、あれですか。3Dエンジン自作しても同じこと言われますか

public class Geimu {
　public static void main(String[] args) {
　　Hontai h = new Hontai();

　　h.initialize();
　　h.start();
　　h.finalize();
　}
}

クラスHontaiは各人の実装にまかせる。

3Dエンジン自作はさすがにｵﾅﾆｰだと思う・・・パーティクルは許そう

class Hentai{
　void initialize(){
　　printf( ">>50ｻﾝ..." );
　}
　void start(){
　　printf( "ﾊｧﾊｧ." );
　}
　void finalize(){
　　printf( "ｳｯ!" );
　}
}

>> 52
Geimu.java:3: シンボルを解釈処理できません。
シンボル: クラス Hontai
位置 : Geimu の クラス
　 Hontai h = new Hontai();

Geimu.java:3: シンボルを解釈処理できません。
シンボル: クラス Hontai
位置 : Geimu の クラス
　 Hontai h = new Hontai();

Geimu.java:13: シンボルを解釈処理できません。
シンボル: メソッド printf (java.lang.String)
位置 : Hentai の クラス
　 printf( ">>50ｻﾝ..." );

Geimu.java:16: シンボルを解釈処理できません。
シンボル: メソッド printf (java.lang.String)
位置 : Hentai の クラス
　 printf( "ﾊｧﾊｧ." );

Geimu.java:18: Hentai の finalize() は java.lang.Object の finalize() をオーバーライドできません。スーパークラスでの定義より弱いアクセス特権 (protected) を割り当てようとしました。
　void finalize(){

Geimu.java:19: シンボルを解釈処理できません。
シンボル: メソッド printf (java.lang.String)
位置 : Hentai の クラス
　 printf( "ｳｯ!" );

エラー 6 個

やっぱりコンパイラ通さないとダメですか？

>>54
いいんじゃない？漏れは暇だったからコンパイラ通しただけ。

>>46 を誤解した奴が多そうなので言い方を変えます。

漏れには、酔っ払いのゲロにしか見えません、と。
お前ら、汚いモン客の目にさらすんじゃありませんよ、と。

これで伝わりますか？

つかなぁ、今時のパテクルなんかエミッタパラメータ弄るだけでほとんど
が実現出来るように作るのがフツーだからなぁ。プログラマのナニオーとも
言い切れんよ。

　あとね、ゲームにＯＯが向かないというのは、ゲームシステムのとある局所的
な１部分に置いて。それがどこを指すのかは失敗から学ぶ事なのでここでは書かない。
ＯＯ信者はメインプログラマ経験の無い万年下っ端ＰＧに多いのよねぇ。

>>57
知らないくせに。いいから教えてください。

>>52
実装するのはHontaiでHentaiじゃねーよ（ｗ

>>57
オレはどっちかというと信者よりだけど(だから？)、
はっきりどういう点が向かないかいってもらわないと
「設計が悪い」とか「自分の能力のなさをOOのせいにしている」としか思えないよ。
「言語仕様(環境)上OOで実現しにくい」ならまだわからんでもないが。

>>57
今日はよく釣れますか？

企画「仕様変更したから。細かいところは上手くやってよ」
　　↓
メインプログラマ「・・・（こんなん想定してねーよ！）」
　　↓
リファクタリング
　　↓
OO信者万年下っ端ＰＧ「・・・（糞上司め余計な仕事させやがって。
おまえの設計がわりーんだよ）」


メインプログラマやればこの流れにうんざりするほど直面する。

それは下っ端もうんざりしてる

>>61
それはOOが向かないというか、それに対応できる開発手法は存在しないと思われ。

コミュニケーションの問題だ

企画「仕様変更したから。細かいところは上手くやってよ」
　　↓
OO知らないメインプログラマ「・・・（こんなん想定してねーよ！）」
　　↓
ウォーターフォールモデル１から作り直し
　　↓
OO信者新人ＰＧ「・・・（糞上司め余計な仕事させやがって。
おまえの設計がわりーんだよ）」


メインプログラマが馬鹿だとこの流れにうんざりするほど直面する。

OO信者とかいう問題じゃなくて、もうOO使うのは常識と思われ。
信者がどうこう言うてるヤシは、「この電子メール信者め！郵便ハガキの方が確実に決まってるだろ！」みたいなレベル

>>57
局所的な１部分のためだけにOO使わないのはどうかと思うぞ。
OOがダメならそこだけベタで書いてラッパリングすりゃいいじゃん

>>67
>>57読んだが、OO使わんって言ってる？

>>68
OOが向かないって言ってるジャン
ラッパリングはOOのテクニックでそ？

剥かない != 使わない

ゲームって一本作ったらそれでおしまいだし
プロジェクト変わるとコードの再利用できるかどうかあやしいし

OO的開発手法のひとつとして、コードの再利用によるライブラリ群の
発展的な構築というのがあると思うんだけど、現状のゲーム開発では
政治的な理由でこれ(継続による組織としてのコード資産の蓄積)が
できないことがあるんだそうだ。アホくさ。

某大手が以前そうだったっつう話を聞いた。
もしかしたら今でもそうかも。

>>69 はラップしたら中身まで OO に変わると思っているみたいね

>>71
「政治的な理由」を具体的に述べよ
もちろん問題の起こらない範囲で

>>72
少なくとも外から見たらオブジェクトだけどね。
そういうのも含めて「オブジェクト指向プログラミング」と言っていいんじゃないの。
少なくともOOのテクの一つっていうのは当たってるんだし

どっちにしても、「局所的な１部分が向かない」のなら、大半は向いてるわけだ

>>71
再利用もOOに限った話じゃ無いしね。
単一プロジェクト内でもOOの恩恵は十分に受けられると思うよ。

しかしライブラリを持たない会社？　信じられんな。

>>75
単一プロジェクトでの効果を否定するわけじゃないけど、
そのためにはメンバがある程度習熟しているという前提があると思うよ

数プロジェクトに跨ってヒトやモノ(コード)が引き継がれて
初めて実りあるものになると思うんだが...

ゲーム屋の実態はどうなんだろうね

>>73
使う分にはもちろんOOってことでいい。
でも、作る分にはOOじゃない。

この程度の場合分けぐらいは頭の中でできるようにしないと
IBM が Linux 採用 → IBM が自社 OS を捨てた
なんて言い出す犬厨みたいなバカになるから気をつけよう。

>>76
ドキュメントもろくに無ければ
作った本人がまともに説明することも嫌がるような
そんなライブラリなら、ないのと同じなんだよね。

むしろ、そんなコンディションのものを会社が強制的に
使えと押し付けてきたら、逃げるよ俺は。
というか、もう２度と嫌です、そんなことは。

もちろん、まともなライブラリなら喜んで使いますとも。

>>74
手法なんだから、向いてるところを使えばいいだけの話なんだよね。

むしろ使うことによるプラスとマイナスの面を(短期・長期の視点から)
きちんと調べないのがまずい。つうかそれをしないなら、
どんなものを導入したとしても、たまたまうまく行くかもしれんが、
つまんないことでヘタったりする。

どっちにしろメンバの教育は必要なんだけどね。

FFXを作るにはどんなスクリプターを作ればいいと思いますか。
詳細は抜きにして、まずは大まかな構造から・・・

ミニゲームとかはスクリプターで直接サポートしないで、ミニゲームプログラムへ切り口を作れればいいんじゃないでしょうか。

>>79

まずスクリプトという考え方を捨てたほうがいいと思う。
最低限 OOP するための最低限の機能をスクリプトに盛り込まなきゃいけないし、
そんなメンドクサイすることするくらいなら、最初からやらないほうがいい。

個別にコードで組むべきところと、データ構造とコードとの連携してゲームシーンを
作るところで、しっかりわけてやるほうがいい。

あげ

てめぇらみたいなガキはどせヒマだろ？だったらこっちゃ来い (

夢を見ている人たち
夢を見れない人たち
夢破れた人たち
夢を叶えた人たち
夢を追いかけてる人たち
夢を諦めた人たち
そして
全ての馬鹿たちに送ります

『一炊の夢』

http://www.geocities.co.jp/Hollywood-Screen/9038/

質問ー。
クラス間のデータのやりとりを抽象化。とかっていうの、
実装してる？

>>83
やってますぇ〜ん
実装するとしたらどういうのが良い？メッセージID+void*でいいのかな

政治的な理由ってプログラム構造の特許のことか？
辞めたプログラマからサブマリンで数年後に
ガツンと金を要求されるのは確かに嫌だが。

>>85
(ﾟдﾟ)ﾎﾟｶｰﾝ
ｷﾐﾊ ﾑﾘﾆ ｷﾉｷｲﾀｺﾄｦ ｲｵｳﾄｼﾅｲ ﾎｳｶﾞﾖｶﾛｳ

ｽﾏｿ、よく読んでなかった

>>83
データ受け渡し用のインターフェースを作る・・・ってことかな？
今のところ必要を感じてないので実装してないけど。

>>88
普通のアプリ作るなら必須だけど、ゲームなら時と場合によるかもね
複数のキャラにファイルから読んだデータを送って挙動を変えさせたい時（データをを受けてどういう振る舞いをするかはキャラによって変わる）とかに有用なのかな？？
ああ、ようわからん

データのやりとりは高度に抽象化する必要ってないんじゃない？
オブジェクト間のデータ受け渡しってかなり状況を限定できると思うんだけど。

>>90
だから、>>89が言うみたいにあらかじめメソッドの名前を特定できない場合に有効ね

>>91

というよりも、メソッド名は同じでも実行内容は違うっていうものが見つかれば、
それは大抵、抽象クラスにしとくといい設計になるわけことが多いんで、
そういうものを沢山見つけてやろうくらいの気概を持って作るといいんじゃないか。

>>92
Macの話ですまないが、PPというﾌﾚｰﾑﾜｰｸにはデータ（リソース）からオブジェクトを自動生成する機構がある。仮に自動生成する元になるデータファイルはこんな感じだとする。
"window"
rect 20 20 150 100

これを読んだ自動生成機構は、"window"のキーワードから対応表を参照し、CWindowを作成するべきなのだなと判断する。
そしてCWindowを作成する際、コンストラクタに次の行のバイナリデータを渡す。
CWindowは、どういうデータが渡されるのか分かっているので、バイナリデータを解析してRECT型に置き換え、自分の大きさを決定する。ここまではいいね。

じゃあ次に、こういうデータがあったとする

"colorwindow"
rect 20 20 150 100
number 255
number 0
number 0

自動生成機構は"colorwindow"を見て、CColorWindow（CWindowの派生）を作成する。
まずCWindowが前回と同じ要領でコンストラクトされ、残りのデータをCColorWindowのコンストラクタが受け取る。CWindowは、下の三行の意味がわからないが、CColorWindowは色のデータが含まれているという事を知っているので、RGB値に置き換えて、自分の色を決定する。
「オブジェクト間のデータ受け渡し」とはちょっと違うけど、データを抽象的に扱うと、こういう事ができるようになるわけよ。

それって至って普通なんでは...

俺初めて見た。MFCにはこういうの無いね

マリオとルイージがＡボタン押したらジャンプするけど、軌道のアルゴリズムは違うなら
マリオクラスとルイージクラスの doJump メソッドを書き換えればよい。

そうすれば if 文でマリオとルイージとを分岐する必要は無いし、プラグイン的に（中枢の
プログラムを触らずとも）ドンキーコングも追加することができる。


または、

interface JumpOrbit {
..public void jump( int frame)
}

というのを作って

mario.setJumpOrbit( otherJumpOrbitObject);

とすれば、ゲーム中に動的に、なおかつシンプルにジャンプの軌道を変えることができる。

★超オススメサイト★

ここをクリック！！！
↓↓

http://www.bea.hi-ho.ne.jp/paisen/

>>96
例として簡単なものを挙げたと思うが、
その程度ならキャラクタの挙動を表す構造体でも用意しておいて、
その中の変数の値を変化させればよいだけでは？
ファイルを用意すれば、プラグイン的に（まったくプログラムを触らずとも）
ドンキーコングも追加することができるでしょ。

クラスとして扱うなら、根本的にシステムが変わってしまうレベルでないと
逆に複雑になると思う。たとえば・・・
長靴を履いたマリオとかえるになったマリオの変化とか。

>>93
へえ〜〜〜　いいねそれ
シューティングゲームの敵キャラ生成のアルゴリズムに使えそう。

　んー>>96っていわゆるストラテジパターンだよ。何のことは無い、教科書に
のっているような基本事項。
　アセンブリ時代にもジャンプテーブルとかで実現している非常に古く
て古典的なテクだとおもうよ。

　

タスクシステムってマンマそれだと思うんだが・・・
俺が勘違いしてるだけか？

あ、>>99ね

>>96
それじゃ全然普通じゃん。
ゲームでそれやると、爆発的にコードが太っていくから却下

ストラテジパターンってそんなんだっけ？

つうか９６の方向に拘るならファクトリでさらに抽象化して変更時弄る場所を
もっと減らすべきな気が。

>>101
俺がさっき書いたのは、初期化データを抽象的に扱う事で、派生クラスを新しく作る時に生成元のデータをダイナミックに変更できるって話。>>1が言う「データ型に制限されてしまう」というのを回避するテクニックね。
なんていうパターンかは知らん。

>>104
ストラテジパターンはアルゴリズムをカプセル化する方法。
身近な例では、CListクラスの派生を書かずにソートするアルゴリズムを動的に変更出来るようにしたい時などに使うと吉。

ほほう。

>>93
その辺を強力にしたのが、Delphiの 2　way tools ですな。
時には、GUIでコンポーネントを配置したり、それをテキスト形式に変換して直接編集したりできる。

マイノリティが自慢するスレだったのか

ゲーム作るならCでOO風味プログラミング、これ最強。

>>108
さっきは分かりやすいようにテキストデータみたいに説明したけど、実はこれはリソースエディタ使ってマウスで設定出来る。アイテムのプロパティを設定するダイアログに「NUMBERデータを追加」「Stringを追加」みたな事が可能。
ゲームで使うなら、ビットマップやサウンドを埋め込めるようにしたりしてもいいんでないだろうか
どっちにしてもデータ駆動メインのゲームなら、こういうリソースエディタを作ると便利だぞと

データ駆動にするのって当たり前のような・・・
なぜいまさら・・・

>>112

データ取り出すってのも、ポリモーフィズムと言えなくもないかもしれない。
データを取り出す、というのは同じだけど、帰ってくるデータは違うわけだ。


データだけでなく振る舞いもそれできたら便利だし、
その呼び出し方を変数に格納できると楽だ。

（OO の技術的な利点の肝はポリモーフィズムのみといってもいいくらい。カプセル化とかはオマケみたいなものだな）

>>113
オマケというよりはＯＯ以前からある概念だから
もはや前提みたいなものかと

>>46
パーティクルってなんですか？

そういう意味じゃポリモーフィズムもOO以前からある概念

>>115
髪の毛つやつや

そりゃｷｭｰﾃｨｸﾙでんがな

Σ（´д｀；）

>>112
よく読めよ

>>111
＞こういうリソースエディタ
Delphiそのまんまのような気が

Del厨は帰れ

そもそもゲームシステムっつったら、
ゲーム内容に関する用語だろ。

こんなスレタイつける時点でマジ終了。

そう思う奴は来なくてよろしい。

そんな冷たいこと言うなや。

関西人とDel厨は帰れ

ageとこう

で、大規模とは何が大規模なんだ？

あのな、いい事教えてやる。
システム組んでスクリプトに当たる部分はＬＩＳＰ使え。
実装も楽だし。開発効率が３倍は違う。
解らん奴には解らんだろうが。

そらええ事聞いた

スクリプトにLISPなんて使ったらスクリプタがとんずらするぜ

LISP使いは1000人に1人しかいない優秀な種族です

かーかっここんすかっこかーかっこくだーかっこえっくすこっかこっかこっかこっかこっか

ジャック＆ダグスタはLISPベースのインハウススクリプト
を使って開発したんだが、正に諸刃の剣になってたぞ。

プログラマの手が足りないから、まだ素人でもなんとかなる
スクリプトを使う、という場合もある。
LISP なんか使ったら、これができなくなる。

>>101
自分も、タスクシステムに使う目的で質問しました。
Commandパターンてのになるのかな？
クラス（親タスク、子供等）間のメッセージ（データ）のやり取りで
何クラスから来たとかいう情報（依存関係）をなくしたいな。と。

>>136
　compositeパターンのがそれっぽいかな？ゲームタスクってデザパタ
の総合芸術みたいなところもあるからねー。

>クラス（親タスク、子供等）間のメッセージ（データ）のやり取りで
>何クラスから来たとかいう情報（依存関係）をなくしたいな。と。
自分が使っているタスクシステムというかオブジェシステムには
「どのクラスからの通知か？」という情報は特にシステム側で持っ
てなかったりする。本当にそれが必要なら、後続のパラメータスキーマで
「どこから来たか？」をアプリ的に定義している。

けど、このアプリ的定義も禁じ手と痛感せざるをえない、
効率悪い具体的な場面に何度も出くわした。

作り手が十分注意深い人だけのチームなら void * でもいける。

言語や処理系のお世話にならないとバグだらけになる人には
お勧めできない諸刃の剣。

>>139
そんな人でも大丈夫なように、と型安全にしようとして、
インターフェースクラスを使ったら、使い方をわかってもらえなかったり・・・。

＞作り手が十分注意深い人だけのチームなら void * でもいける。
むー。確かに void* でいけないこともないが、
人間の注意力には限界あるよ。

べつにｲｲﾝｼﾞｬﾈｰﾉvoid*で。
アプリ用のフレームワークでもvoid*多いぜ

GTKは少しだけマシだと思った。
まあ共通のベースクラスがあるし単一継承だからその分簡単なんだろうけど。

>>133
かっこが足りないYO!
かっこ悪!

GTKなんぞさっぱりわからん

G（グレート）
T（ティーチャー）
K（キンタマ）

G（ごっつい）
T（ちんこ）
K（かゆい）

>>138
>けど、このアプリ的定義も禁じ手と痛感せざるをえない、
>効率悪い具体的な場面に何度も出くわした。

後学のために具体例キボンヌ
内部向けインターフェースと外部向けインターフェースを分けてないとか
そういう感じ？

メッセージがどこから送られたかをアプリ側で判断するのは
好ましくないだろう。折角多態性で減らしたswitch文の爆発
を復活させることになる。メッセージを受け取ったオブジェク
トがもう一度メッセージを送り返す、いわゆるダブルディスパ
ッチが定石なんだろうが、GOFの実装(Visitorね)ははっきり言
って保守や理解がし易いものとは到底言えないし、もっと動的
な振る舞いをさせようとしてstrategyなんかを組み合わせると
もう何がなんだか分からなくなってきたりする。で、漏れ的結
論はSMC/yacc/lecのような状態遷移の管理を補助してくれるツ
ールを使わずにこの問題に立ち向かってはいけないってこと。

>>149
どこを縦読みするんですか？

さあもっと語ろう

あっ、意外なところで役に立つヒントが。
でもたぶん私以外の人にはあんまり役に立たないと思うけど…。
ありがと。>>149

ただしyaccがゲーム（ていうかゲーム用のスクリプト解釈）に
使えるかどうかは経験上疑問符つきで伺っておきます。

>>152
無理に盛り上げようとしなくていいよ。
中途半端だよ。

UMLは素晴らしい

げっageちまった　死のう

>>153
ちょっとお礼を書いときたかっただけだし、
別に盛り上げるつもりも無いです。
でもつまらない嫌味を言われるくらいなら
これからは黙って搾取するから別にいいです。

>>156
２度と出てくるな。
一生ひきこもってろ。

悪循環の縮図だｗ

>>154
お前、UMLって言いたいだけちゃうんかと。

>>159
よくシラネ−よ、まだ勉強したばっかりなんだから。実践で使ったこと無い。
つーか、俺は>>1だﾁｸｼｮｳ文句あるか掛かって来い

1登場age

ゲームを真剣に抽象化するなら複雑になるからねぇ・・・
趣味で作るにしてもUMLは必須かもね

そうかあ？
まあ、自分の考えをまとめたものを人に見せられる
という点ではいいけど、それ以上の価値はあまり
感じないかな。

本当に複雑だと、UMLで書いても複雑だよ。

>>163

そりゃそうだ。
UML でクラス図書くときは、どんなに多くても、書くクラスは 6 コ までにするのがいいと思う。

そうでないと、多分誰にも伝わらない。（UML書く意味が無い）

でも脳内だけで設計してると忘れてくる
特にUMLである必要はないけど、絵に描いてまとめるのは必要かと

あげ

はげ

やっぱUML良いわ。慣れると今までよく脳内だけで処理してたなと思う（できてなかったんだろうが・・・）。
みんなも使おう。イラネーとか言う香具師はその代替案求む。

イラネーヨ

代替案求む。

たまにはageさせてくれてもいいんじゃないだろうか

>>168 UMLたしかに便利だね〜。
でも、UMLのエディタがまだいまいち整備されきってない感じがするYO。
ワープロや表計算ほど需要がないから整備が遅れるのもしょうがないけど。
もーちょいだよね。

　　│　 .┌┐
　　│　.／ /
　　 |／　/ i
　　 |　 ｉ ●i
　　 |●i　　|
　　 |　 i　　i──────────
　 ／＼_ヽ＿,ゝ∧∧
／　　　　　 　(　ﾟДﾟ) ∬ ＜そんなﾊﾞﾅﾅやる気も失せたよ　終了するぞｺﾞﾙｧ
　　　　　　 　/　　⊃旦
　 　　　　 　（＿＿）
　　　　　　　　　　　　　　　　　　　　　∈このｽﾚは終了いたしました∋

>>172
SWINGで書かれたような奴ってべらぼうに高いから、洩れはとりあえずVISIO使ってるよ。
VISIOでもエラー表示してくれたりするから、（一人で使うなら）それなりに良い感じ

DynamicDraw使ってるけど、今一操作法が独自……

いや、慣れるとめっさ便利だぞ。
とりあえずショートカット
・S,Z ： パーツ配置
・T,V ： 多角線(矢印付き)
・T,W ： テキスト編集
と、「部品間リンク」の概念おぼえれ。

部品間リンクは面倒だったら、リンク編集ツール(T,G)で
選択した時に現れる点線を全部消しとけ。

なんつーか、メニューのアクセラレータを利用した
2ストローク以上のショートカットに慣れられない。
# emacs系とか駄目
普通のショートカットみたいに、
Ctrl+?とかCtrl+Shift+?に、機能を割り当てられればいいのに…。

どうしても嫌だったら dyna_104.keytxt の中身を替えれば良いかと。
でも Ctrl+? って集中して使ってると指がつりそう…

Ctrlキーは小指の付け根で押すモンだ。
指の腹で押しやすいようにキートップが丸くなっとるだろ。

↑バカ？

あぼーん

CtrlはCapsを入れ替えて使ってるので、大丈夫

ほな、どの指でctrlキー押すねん

付け根で押すのか？

>>182
ワークステーションのキーボードのキー配置がそれだった気がする。

俺はPC-98の配置に慣れてただけだけどな。

抽象化＝デフォルメ＝モデル化も重要だけど、
リアルにできるところはしないと、と思いつつ技術がついていかない。

あぼーん

>>187　意味が良く分からない

ある程度熟成した分野のゲームは、ISOとかJISとかの企画として抽象化されないのかな？


：
ってのはネタだけど、異種ゲーム間の通信、連携プロトコルとかあってもいいような気がする。
具体的な例が思いつかんけど…。

TCP/IPじゃ不満なのか

>>190
ISO、JIS規格になるわけないじゃん。
抽象化と統一化をごっちゃにしてないか。

ゲームに限らず、でかいアプリの構造を図式化する時どうやってます？
フレームワークの開発者とかどうやってんだろ

それはム板の領分かも。UMLとか使うんでない？
でも、ゲームのプログラムは基本的にかなり小規模な部類だと思うけど。

あぼーん

まずはスプライトをキー操作する程度の小さなプログラムの設計・製作から始めて、
リファクタリングを重ねて大きくして逝く。

どうしても構造化して表記することになるであろう。見通しは悪くなるが。
これさえ見ればバッチリ一目瞭然、てな図はあり得ないような気がする。

あぼーん

>>194
FF11とかは十分大規模だと思うが・・・・

　　　　　　　/　　　／ー-,　　　 ー────-,
　　　　　　/　/　／ヽ、／　　　　　　　　＿_／
　　　　　　`y'　　　　／ヽ、　　　　　　　|
　　　　　 ∠＿､　／　　　ヽ　　 　 　 　 |
　　　　　　　|　　　　`ヽ、　　　　　　　　 |
　　　　　,/　|　ヽ　　　　　　　　　　　 　 |
　　　　　　　|　　　　`ヽ、　　　　　　　 ､|

ゴチャゴチャ理論を先行させるよりも、実はだらだら作った方が完成する確率が高い

理論より実践、理論より経験。
これらは正しいが、理論が必要ないという意味は含まれていないことにも注意せよ。

まあ、両方とも大切ってことでんな。

停滞してるみたいなので、質問！
シュミュレーション等のコンピューター側の思考プログラムをOO的にクラスにするには
どのような象徴化がいいのでしょう？　どこかにサンプルなどはありますか?

http://ai-depot.com/
http://www.gameai.com/
とか？
俺は読んでないけどなー

というか、>>204はどういう方法を取ってるの？

>>205　ありがとう、でも英語はちょい語学力が少なくて。
>>206 サンプル聞くぐらいだから、今から考えるところです。
大まかには。
１．現状の分析クラス。　　　　（全体に共通な基準の分析データーを出す）
　　　このクラスが一般的な最良手検索に近い部分だと考えている。
２．分析結果の評価クラス。　（評価は状況や目的、人によって変化する、継承で変化かな・・）
　　１の参照を持つ。
３．目標クラス。　　　　　　　　　（具体的な目標の処理を継承で作成）
４、この２，３をインスタンスに持つ、人物クラス。
ただしこれからなので、脳内妄想程度。
最適解を求めるのではなくて、コンピューター側に多種の性格を持ちたい。

>>204
> シュミュレーション
> シュミュレーション
> シュミュレーション

シュミュレューシュン

>>190
米陸軍のコンバットシム用のなら DIS って言う標準はあるよ。
DCE の RPC ベースだったような記憶。

ageてみるか

俺はシュミだろうと
そんなことどうでもいいんだが
間違えると必ず突っ込む奴がいるので
絶対間違えるもんか

age

Cでゲーム組む場合、いまだに古典タスクを使ってほにゃららして・・・
みたいな奴が多い気がするんだけど、OOPな人だとどうするのが定石なのかなぁ。
いわゆる古典タスク＝クラス＋状態遷移なので、Stateパターンでメインループ作っておしまい？

ここで議論されてる抽象化ってやっぱり描画周りをどうするかって部分に比重が置かれてるわけか？

>214
俺は、
Templateパターンで共通処理の隠蔽。
Compositeパターンによるタスクのツリー化。
Stateパターンによるシーンの表現。（シーン内にタスクツリーがぶら下がる）
てなかんじで、汎用のゲームフレームワークを作ろうとした。

そしてage

>Templateパターンで共通処理の隠蔽。
Templateパターンでタスクの共通処理の隠蔽。
に修正。

ごめんください。ちょっとステフ３９が再利用させていただきます

■　まずははじめまして
まとめＷＥＢサイトはまだありません、早めに作りたいと思います。
今、決まっていること（暫定ですが）は次のレスに書いています。

■　何をするのか
ＡＤＶゲームを作ります

■　募集している人材
シナリオ担当さんです

■　いま考えている事
※　ＡＶＧを作るのならばシナリオが完成している、もしくはシナリオの実務作業に移った時の作業規模が把握出来る状態のブツ
コレがないとNo17氏も私も動けなくなり止まります。シナリオについてはゲーム製作するうえで後回しにしてはいけない話題ですよね。

まずはシナリオ担当さんを募る、この週末まではその考えでいきます。

でもシナリオ担当さんやシナリオは、良い子にして待っていたら突然空から降って来るようなものでもないし、
今いる人たちでもシナリオ（案）をどんどん考えてひねり出して備えておいたほうが良いかもしれないな、と考えてます。

その他にも当企画のゲーム製作についてのアイデア待ってます。

■　募集するメンバーについて
　【担当する仕事】 製作指揮＆シナリオライターさん　１名
　【人数】 １名さま
　【要求スキル】 同人ゲームを完成まで持っていった経験のある方が理想です
ステフ３９が素人なのでバランサー役とも、なって頂ける方。ポートピア連続殺人事件をプレイしたことがある方
　【作業期間/時間】 ２００６年１２月上旬完成を目指す。９月１１日（月）〜１２月１０日（日）までの１３週の製作期間
　【対価】 すごく暇つぶしになります！
　【成果物に対して与えられる権利】 少年愛者であると勘違いされるようになること請合いです
■作成するゲームについて
　【動作環境（PCスペックやライブラリ等）】 よくわかりません！
　【公開の仕方】 ＷＥＢでFLASHにて、ストリームでもＤＬしても出来るようにして公開
希望としてはFLASHで環境を選ばずプレイできるのが理想。次いで圧縮ファイルをＤＬして公開という方法
クオリティなどよりも、なにより第一に優先されるべきなのは期日までに、「まずは完成させる」という事
■連絡先について
　【Webサイト】 探索中ですっ！
　【メールアドレス】 2chのスレだけで進行したいので基本的にはメールのやり取りはしたくありません
ＰＣ＆携帯などで、朝6昼12夕18夜24と少なくとも４回はスレをチェックして随時反応するようにしたい

と、忘れるところでしたすみません。

【初心者】ステフと一緒にゲーム制作 Part5【歓迎】
http://pc8.2ch.net/test/read.cgi/gamedev/1149170703/

こちらから移動してまいりました。
ゲーム製作を実際にするなかで、同時に副産物として、
製作作業の能率化に役立つものに気が付く事が出来ればと思います。

では、とりあえずはこのあたりで。また夕方以降に

もひとつ忘れてましたｱｾｱｾ
このようにあまりシッカリしてないうっかり者なので困ります、だれか助けてくださーい

■　ゲーム内容について
　【概要（ジャンル等）】 ＡＶＧ　学園事件モノでＢＬゲーム。ポートピア連続殺人事件リスペクトな作品予定。セーブ機能なし。
ショタ要素が強いが非１８禁で微エロ
FLASHで公開したいです。ストリーム
★☆★☆★　FLASHにこだわって募集継続してみようと思ってます
でも同時に、それが駄目な時はLiveMakerを使ってみてもいいかなとか調べてるとこでした。
日程とにらめっこしなきゃいけませんが作業的に余裕があったら立ち絵はアニメさせてみたいです。

　【規模】　作業期間に準ずる
　【売り】 ２ｃｈ製作でショタゲーは珍しい部類にある事が売りになると思います
登場人物を皆ことごとく半ズボン白ハイソックス姿にします（年寄りの校長や体育教師も被害者になります
犯人はヤス

★☆★　ポートピア連続殺人事件をプレイ、クリアしたことがなくても以下３つをご存知なら大丈夫。
・　犯人がヤスというのを知っている
・　だいたいの画面構成とコマンド選択でどんなものがあるのかだいたいアバウトでもいいので知っている。
　　（コマンドで「たたく」とか「でんわ　かけろ」とか個人的に印象に残ってる）
・「なにか　とれ」「ふく」で事件解決に結びつくのが非常にＢＬ的でおいしい事【コレが重要】
　山川邸地下迷路についてはリスペクトするつもりは無いです。これはスルー。

出て行け。もっと他に再利用すべき糞スレがあるだろ。

ありゃまいったな、これは失礼しました。

ttp://pc8.2ch.net/test/read.cgi/gamedev/1106171478/l50　1がすべて他人まかせでゲームを作るスレ
えーと、それではココあたりなら良いのでしょうか、ふさわしくないようなら他にももう少し探してみますが

いやはや、しかし糞と言われても糞がどういうものなのか自分にはあまりよくわからんです。ヨワッタヨワッタ。

ステフ３９ は何ができる人なの？

2005年末から書き込まれてない
それ以前は2004年、2003年という過疎も過疎スレだからここがいいんじゃない？
ttp://pc8.2ch.net/test/read.cgi/gamedev/1006006991/

思うのだけど今はやる気に満ちてる時だから
その勢いで簡易でいいからHP、掲示板も製作してはどう？

えーと、結局ここと>>225氏の言ったスレとどっちでいきましょう？

>>225氏ありがとうーＨＰももうじき帰宅後しますのですぐに作りたいと思います

>>226ステフ17氏
こんばんわっ２２５氏が薦めて下さったスレに移動しようと思います
移動先を決めるだけで難産してしまって申し訳ないですﾍﾍﾍ

>>224さん
はじめまして、自分はゲームに使う事になる絵を描きます。
もしよかったら様子を覗きに来てあげてくださいねー

そういう説明も含め、移動先のスレでもＨＰでも書いていかなきゃいけませんね（大変だぁ