[過去ﾛｸﾞ] 親父PGがゲームを作り始めるスレッド (668ﾚｽ)

親父PGがゲームを作り始めるスレッド http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/

上下前次1-新
通常表示 512ﾊﾞｲﾄ分割 ﾚｽ栞
抽出解除 ﾚｽ栞

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

144: 名前は開発中のものです。 [sage] 04/04/07 03:22 ID:BZdMbvQi マップデータとトリガデータ分離するの？ 編集はエディタのみで、単にファイルが分離しているだけならいいけど。 データ間の依存関係は、データ修正の手間が軽いかどうかを重視するのが よいと思うがどうか。 ３Ｄなら特定のオブジェクトをトリガとして扱う（ダミーノードやボーンがあるモデラなら それを使う） ２Ｄなら、どーせマップエディタ作るんだから、編集はエディタのみの１箇所なので 無問題 って感じ？ あと、>>128 > 255種類もあれば大丈夫でしょう ケチらなくてもｗ こんな構造体作るよりは、スクリプトをキックしてスクリプトにフラグ判断させて、 スクリプトからイベント（ここではただの会話もイベントとしよう）をキックさせた方が、 作成も変更も管理もらくだと思うけど。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/144

151: 144 [sage] 04/04/07 08:57 ID:BZdMbvQi >>145 もう１度読んでください。 前半部は、データ作成段階に入ってからの絵描き・プログラマ・スクリプタ・プランナ それぞれの間のワークフローに関わる問題の指摘です。 様々なファイル間に依存関係があります。特に座標値を即値で持った場合には、 マップ変更で様々な影響があります。 不整合を起こさない仕組みをお考えであればまったく問題はありません。 相互に依存関係があるファイルを個別に修正すると（特に別々の人が）、様々な エンバグが発生することでしょう。 マップエディタの例は、とりあえずトリガデータとマップデータの不整合を防ぐ仕組みの 具体例の１つとして出しただけです。 決して最終バイナリの数を問題にしたのではありません。編集時です。 後半部は・・・特に色々問題をはらんでいるのですが・・・。 まず、２つの意味で、 seed を ８ビットとする必要はありません。 ・どーせパッキング単位が４バイトなのでメモリの節約にならない ・余ったビットはフラグにでも使えば良い むしろ seed に名前をつけて文字列を格納し、実行時にアドレス（またはＩＤ）変換するくらい 富豪的でも問題ないと思います（つーか、パディングするって書いてあるけどｗ）。 データキャッシュが荒れるのを気にするならば、宣言を直してメモリを節約するのも良いと思います。 つづく http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/151

152: 144 [sage] 04/04/07 08:58 ID:BZdMbvQi ところで、>>117 の場所ＦＧって、単にフラグ番号？ 場所っていうからマップの座標かと思ってた。 マップデータもただの配列だし、もしかしてまだ、マップアトリビュートテーブル自体が 話題に上ってなかった？ マップの特定の場所に行ったら起動するようなイベントはシステム側からフラグを立てて それをトリガで拾うという仕組みをお考えですか？ なぜ、トリガデータがこんなにもスクリプト的な機能を持っているのか不思議だったのですが、 もしそうなら納得できます。 トリガデータはイベントハンドルテーブルのように扱ったほうがシンプルになると思います。 どちらにせよ、トリガデータの１レコードは豪華すぎるように思います。 んー、なんか、データ構成見てると、ソーサリアンを作れそうに見えない・・・。 アトリビュートテーブルがないせいだとは思うんだけど、マップ -> イベントキック -> シーン の流れが見えないと・・・。 もしかして、MAPBASE::ToDo がイベント起動？ そんなことしたら、同じマップで違うイベント配置の時に管理が破綻しない？ まさかねぇ・・・。 まあ、それこそ編集時はイベント名の文字列で管理すればいいのか、な・・・？ http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/152

153: 親父PG [] 04/04/07 09:11 ID:4mfJMcZS >>144 いろいろな考察ありがとうございます。きちんと整理してご返答したのですが、 あいにくバスの時間がｗ戻ってきてきちんと返答します。 MAP＞イベントキック＞シーン　この方法には２つ方法があると思います。 MAPにイベント番号を入れる方法と MAPにはイベントがあったことのみのデータ−で　管理側でXY座標を引数にイベントトリガー内を検索します。 とちらにも利点欠点　あ時間だ　帰ってきて書き込みます http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/153

181: 144 [sage] 04/04/08 16:49 ID:kikONY5O トリガテーブルは固定長じゃないほうがいいと思うよ。 で、番号じゃなくて名前の文字列にしよう。 で、std::map< std::string, TriggerAndProcess > みたいなのに突っ込もう。 ハッシュでもいいけど。 マップの方では、トリガ番号をセルに埋め込むのはよろしくないと思う。 ３Ｄにしたときにどうしようもなくなる。 その代わりに、アトリビュートファイルを作ろう。 アトリビュート範囲とトリガの名前が書いてある。 （もちろん、マップファイルの固定長地形データ配列の次にくっ付けても 構わないが、実行の問題じゃなくて構造の問題ね） トリガの条件判断は、やはりスクリプトに譲ったほうがよいと思う。 寄り道できない一本道のシナリオなら今のトリガテーブルの条件記述 で構わないと思うが、ちょっと複雑になったら、結局素人の手には 終えなくなると思う。 当面は今のトリガ記述方法で良いと思うけど、早いうちからスクリプト への変換をしておくと、トランスレータだけいじればよくなるので、 トリガデータ構造はもっと柔軟なもの（できればスクリプト）にしておいた ほうが良いだろう。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/181

183: 親父PG [] 04/04/08 17:53 ID:msAPqSAi >>144 ご意見ありがとう。いろいろとご意見を私なりに整理しました、話をすすめていく上で確認すべき点があると思います。 私が提起しているデータ−形式は、そのまま「メモリの上に展開して動かせる最終形態」の話です。 プログラムの中でSTLを使うにしても、バイナリデータ−の並びを解釈してCPUを動かさなければなりません。 前にも述べましたが、スクリプト（テキスト）を動的に解釈するメリットはないので、 中間言語およびスクリプトで書かれたコードは全てコンパイルが済んだ形（バイナリ）にします。 そのバイナリ形式が提案している形になります。 ただし、その前工程でどのような形でデータ−を扱ってもかまいません。 例えばコンパイラはテキストで書かれた命令文を最終的にCPU命令に置き換えます。（MOV　AX、CX） といった単純な命令群に置き換わります。今回のゲームデータ−についてはここまで単純化してはいない（必要が無い）ですが、 その一歩手前にある（構造を単純化して高速化）といえます。 std::map< std::string, TriggerAndProcess >を使用する場合、 プログラム内で「このデータ−をMAP（STL）にPUSHしてくれ」という、コードを入れなければなりません。 そういったレベルでスクリプトを組めるのはPGレベルの人だと思いますorz... http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/183

195: 144 [sage] 04/04/09 04:52 ID:d03K47Nx >>183 > 私が提起しているデータ−形式は、そのまま「メモリの上に展開して動かせる最終形態」の話です。 （略） > ただし、その前工程でどのような形でデータ−を扱ってもかまいません。 もちろん。 ただ、現在の形が、固定長のＣＩＳＣのような命令セットであり、柔軟性に乏しい。 以下のような例を考えよう。 　台座に青い宝石があり、ソーサリアン的には台座の下で<<上>>を入力すると調べるのような反応になる。 　最初に調べると、「台座に青い宝石が置かれている」とメッセージウィンドウに表示される。 　次に調べると、「青い宝石からは高い音が発せられている」とメッセージウィンドウに表示される。 　さらに調べると、「青い宝石を手に入れた。どこかで音がした」メッセージウィンドウに表示され、 　（このシナリオ限りの）アイテムがアイテム欄に追加される。 　という場合、青い宝石のある座標にトリガ番号 777 が設定されているとしよう 　[トリガファイル] 　777 FG BlueJewelCounter eq imm 0 Scene 1 * 　778 FG BlueJewelCounter eq imm 1 Scene 2 * 　779 FG BlueJewelCounter eq imm 2 Scene 3 　　780 always StoreFG BlueJewelCounter 1 　　781 always StoreFG BlueJewelCounter 2 　　782 always StoreFG BlueJewelCounter 3 * 　　783 always GetItem BlueJewel 　[シーンファイル] 　　scene 1 「台座に青い宝石が置かれている」 goto 780 　　scene 2 「青い宝石からは高い音が発せられている」 goto 781 　　scene 3 「青い宝石を手に入れた。どこかで音がした」 goto 782 つづく http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/195

196: 144 [sage] 04/04/09 04:54 ID:d03K47Nx って感じ？ ソーサリアンでは、反応する場所では、とりあえず反応がなくなるまで上連打が基本だったと思うけど。 これより簡単にしようとすると、 ・条件が一致したら、自動的にフラグをインクリメントする比較命令を作る ・複合命令を（例：CountupAndGetItem）どんどん増やす ・フラグのインクリメントやアイテムの取得はシーンファイルに記述する って感じじゃないの？ いーの？ 充分素人の手に負えないと思うけど。always とか * とか。 上記トリガは最適化版。最適化前は、シーンファイルに goto が無く、トリガファイルは９行だった。 　　777 FG BlueJewelCounter ne imm 0 goto 780 * 　　778 always StoreFG BlueJewelCounter 1 * 　　779 always scene 1 　　780 FG BlueJewelCounter ne imm 1 goto 783 * 　　781 always StoreFG BlueJewelCounter 2 * 　　782 always scene 2 　　783 FG BlueJewelCounter eq imm 2 goto 784 　　784 always StoreFG BlueJewelCounter 3 　　785 always scene 3 ちなみに、* なしで複数の処理を一度に行うことは俺にはできなかったよ。 上記トリガを記述するのに、親父ＰＧﾀﾝ の発言に無かった仕様は * だけ。 マップの ToDo を書き換えることも考慮したが、余計わかりにくくなった （セーブするのに、シナリオで使う前マップも保存しなきゃならなくなるし）。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/196

197: 144 [sage] 04/04/09 04:56 ID:d03K47Nx トランスレータを書く前提で、スクリプトで上記を書き直してみよう。 　青い宝石のある位置に、イベント名 BlueJewl の文字列が定義されている（もちろん識別番号でも良い）としよう。 　[シーンファイル] 　　<event BlueJewel> 　　　[CounterCheck BlueJewelCounter] 　　　　0 「台座に青い宝石が置かれている」 　　　　1 「青い宝石からは高い音が発せられている」 　　　　2 「青い宝石を手に入れた。どこかで音がした」 　　　　 　*get BlueJewel 　ただし、[ ] 内の CounterCheck は、スイッチのようなものだが、カウンタを参照して、一致したらイベントを起動して、 　カウンターをカウントアップする。Ｃの switch でいう default は別に考える。 　* は、システムコマンドを呼び出す。 　もちろん、シーンファイルは事前に仮想マシン用のバイトコードにコンバートしておいて構わない。 例に最適化した文法を作ったわけで、かなりズルしてるけど、トランスレータを前提にすれば、こういうズルも必要なときにできる。 親父ＰＧﾀﾝ のトリガファイルの文法へのトランスレータも問題なく書ける。 しかし、これに多少の工夫をしても、まだ分かりにくいし、人為的ミスの混入も減らないかもしれない。 すると、結局シナリオ編集サポートツールを作ることになるわけで、ならば最初からスクリプトに任せてしまえ、ということですよ。 で、スクリプトをアセンブラライクなバイトコードに変換すると（逐次解釈でもいいけど）。 だから、スクリプトライクなトリガテーブルには疑問を抱くのですよ。 > std::map< std::string, TriggerAndProcess >を使用する場合、 > プログラム内で「このデータ−をMAP（STL）にPUSHしてくれ」という、コードを入れなければなりません。 > そういったレベルでスクリプトを組めるのはPGレベルの人だと思いますorz... 違う違う。 シリアルナンバを使用するのは、配列のアドレッシングのためでしょ？ 文字列で連想配列をアドレッシングすることを勧めてるの。 編集時や使い回しの柔軟性のために。 ID みればわかるけど、>>194 も俺。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/197

208: 144 [sage] 04/04/10 13:01 ID:1EUDp4ba >>198-200 トリガから別のトリガを呼び出せるというのは書いてあったけど、return まで逐次実行ってのはどこにも書いてなかったよ。 後出しだしズルいよｗ。 ま、それはいいとして、オヤジﾀﾝ の記述例では、トリガもシーンも、オヤジﾀﾝ のいうＰＧ以外が対応できるレベルにみえないけど。 それと、トリガテーブルって、同時にいくつも存在するの？ 同時ってのは、実行時の話なんだけど、仮に１つだとすると、エクセルとどのように整合性を保つのかな、と思って。 シーンファイルに、トリガサブルーチンがあるのはいいと思うけどね。 なんかもう、普通のスクリプトのバイトコードと話が変わらないように見えるよ。 単にバイトコードのフォーマットが見たことないほどリッチなだけで。 そして、エクセルで入力すると言い張ってるのは、アセンブリ言語での記述を要求しているのと等価にしか思えない。 > ＞シリアルナンバを使用するのは、配列のアドレッシングのためでしょ？ > これは少し違います。地形MAPを切り替えた時に、同時座標のトリガーを判断するためにあります。 地形マップを切り替えるというのは、 ・どこかのマップでスイッチを入れる ・別のマップで跳ね橋が下りる のようなときに、マップチップテーブルだけの入れ替えをするような話だよね？ それをシリアルナンバで判定するということは結局 std::map< int/*シリアル*/, int/*トリガ配列の添え字*/ > のような形で判定するんでしょ？ 俺は、エクセル上でもシリアルナンバの入力を強要してるのかと思ったんだけど、トリガコンパイラが文字列で 解決してくれるならそれでいいと思うよ。 ところで、>>189 で MAPposition で比較してるけど、本当は MAPBASE::ToDO に 777 が入ってるんだよね？ そうじゃなければ、エクセルで入力するときはコンマ付で入力？ マップの大きさは最大２５６ｘ２５６？ 自信あるみたいだから、思うとおりにやってみるといいでしょう。 使い物になりそうなことは分かったし。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/208

210: 親父PG [sage] 04/04/10 20:09 ID:Sr13ZjT1 >>144 いろいろと検証ありがとう。いろんな角度から見てもらえてるので、実に助かってます。 対策として具体的な仕様も決まっていくしｗ まず書き方の例ですが、ここでの話を判りやすくするためであって実際の文法はもっと判りやすくなるはずです このへんは「新人ニューウェーブPG」氏に期待します^^。 メイン担当としては、「最終バイナリはこういうイメージにしてね」と伝えなければなりません。 データの意味（解釈方法）を伝えるためにCで書いてみたわけです。 １４４氏の指摘の多くは私の作業より、一つ上のレイヤーの話と思える部分があります。 トリガーテーブルは（エクセル「でも」編集できる）ここが味噌でエクセルの機能を使って レコードの操作をいたします。（エクセルと同じ機能のツール作るのは大変だｗ） 多重ソートとかマクロ機能とかね...別途作ってもいいけど。 エクセルコンポーネント使うなら一緒だ（orz...ｺﾚﾀﾞｹﾃﾞﾓｴﾂｷﾙﾖ 利用理由は主にチェックです。デバックですね。これってありがたいんですよ。ええ（独り言モード トリガーテーブルは基本は一つですが、動的に後ろに追加しても仕様上動きます。 地形MAP配列にはトリガーを引くことしか指示しません。引数は座標XYZ（65535）＋MAPシリアル（65535）になります。何をするかはMAP側ではなくトリガー側が判断します。 作業予想 地形MAPツールは地形データ-とトリガーテーブルを読み込む。 イベントを行いたい場所へマウスでマークしていく。 このときトリガーテーブルにもトリガー情報のみのデータ-が追記される。 保存... 再度開いた時はトリガーテーブルのMAPシリアルを見て以前のマーク場所を再配置する STEP２ イベントツールはMAP作成ツールによって作られたトリガーテーブルに、必要な情報を追加していく。 このような感じになる予定です。 >>209 勝負はしてないけどね^^　いろいろ言ってくれると助かるよ。 http://mevius.5ch.net/test/read.cgi/gamedev/1080582036/210

---

ﾒﾓ帳

(0/65535文字)

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

Google検索

Wikipedia

---

ぬこの手 ぬこTOP 0.020s