親父PGがゲームを作り始めるスレッドat GAMEDEV親父PGがゲームを作り始めるスレッド - 暇つぶし2ch■コピペモード□スレを通常表示□オプションモード□このｽﾚｯﾄﾞのURL■項目テキスト174:親父PG 04/04/08 06:14 msAPqSAi.net 続き ・トリガーのActCommandはデータは大きく確保しておいた方が良いのではないでしょうか。 そうですね。引数もふくめるとおっしゃるとうりです。この部分は拡張しましょう。 ＞別のデータ（アイテムデータ等）が持つデータだと思います。 ＞アイテムデータがトリガ情報を所持していて、それが地形データの上にあるとすると、 ＞アイテムデータトリガ呼び出し ＞ 地形データの座標等チェック（トリガへの付加情報） ＞ トリガ処理 ＞という流れが出来るので良いと思っています。 アイテムデータ－にはトリガー情報は含みません。例えば、ある地点でアイテムを拾うというイベントがあったとしましょう。 キャラデータ－が移動、地図配列をチェック、トリガーがある。>トリガーテーブルから該当するトリガーを探し出す。 トリガの１番目のコマンドを調べる （シーン１と書いてある） シーン１ メッセージの表示「アイテムを拾いますか？」 選択メニュ表示 戻り値をリターン トリガの１の価取得終了 トリガの２の価取得開始 （ダイレクトの価１） 比較命令に従って２つの価の比較 条件によりアイテム取得トリガー呼出（引数 任意のアイテム番号） このような流れになります シーン１の情報が変わってもトリガー情報に影響がありません、逆もしかりです。 ＞＞実は個人的には地形データにトリガシリアルを記述する事に賛成ではありません これは１４４氏の指摘にある「地形データが入れ替わった時どうするのですか？」に対する 解決案のひとつ。同座標にトリガー埋め込んだ場合どうする？ という問題ですね。 ＞●シーン := トリガ := アイテムデータ ｜ 地形データ ｜ シナリオ ＞このようなイメージを持っているのですがどうでしょう？ 私のイメージは 地形データ＞＞＞＞トリガー＜＜＜＜シナリオ 独立 アイテムデータ－ このようなイメージを考えています。 トリガーテーブルを中心に他は従属関係にあります。 ＞うちの会社ではiniファイルもpropertiesファイルも全て「マップファイル」と呼びます。 prz.... このスレでは地図データ－は地図データ－もしくは地形データと呼ぶようにしましょう。 次ページ最新レス表示レスジャンプ類似スレ一覧スレッドの検索話題のニュースおまかせリストオプションしおりを挟むスレッドに書込スレッドの一覧暇つぶし2ch