親父PGがゲームを作り始めるスレッド

**親父PG** · 04/03/30 02:40

C++やC、アセンブラは昔こなしたし、プログラムの事なら自信はあるけど
ゲームは作った事が無い方。現場からも引退したし（ｗ。
ここは一つ趣味でDirectXでも勉強して、ゲームでも作ってみようかなぁと思った、
オジサンPGのスレッドです。

一緒にマターリライブラリから作りませんか？

**新人PG** · 04/04/05 21:20

ただいま帰りました。

>>126
勉強も兼ねてXmlSchemeで･･･(^^;

>>128
Excel編集可能な規格はちょっと考えつかないっす。
CSV形式(独自フォーマット)でよければ作れますが･･･。
(XMLデータ)⇔ツール編集　→　コンバータ　→　バイナリ
上記みたいな構成でいいのでしょうか？
バイナリを直接Excelで編集する事を考えています？

#DirectXの本を買っちゃいました。(DirectX9実践プログラム　工学社)
#あんまりMSのサンプルやリファレンスと変わらないのでちょっと損した感じ･･･。

**親父PG** · 04/04/06 01:40

>>134
むむ、個人スペックですかい。
身長178.8　体重85ぐらい血はAです。肝機能障害ありですorz....
>>135
表示している内容に対して重いと思います。orz...

>>136
お疲れさま。資料本買ったのですね^^;　有難う。

データ-の形式については、作り込んで貰う前にいろいろと検討しましょう。
そうでないと作ってもらってから仕様変更になりかねません。orzｼﾉﾋﾞﾅｲ...
これは私の考えなのですが、ひとつ議題のたたき台につかってください。

●シナリオデータ-は本体のプログラムが読み込む前に、一旦最適化されたバイナリ形式に落とし込む。
（本体にXML関連のLIBは持たない）
●各ツールの互換性はこのバイナリデータ-互換でおこなう
EXCELでの編集は一旦バイナリ＜＞CSVツールを作ってトリガーテーブル部分のみを編集できる。というスタイルになります

●必要なデータ-群
トリガーテーブル　（トリガーが書かれている　固定長）
シーンデータ-　（処理が書かれている　可変長）
ストリングテーブル　（名前などストリング系のテーブル）
ファイルネームテーブル　（ファイルネームを収めます）
マップデータ-　（地形を表すデータ-）
アイテムデータ-　（魔法とかキャラデータ-など....）

ゲーム管理用データ-（画面分割数　ボタン大きさや処理等）＜こちらで作りました

ざっとこんな感じです。まとめたほうが良いデータ-もありますね
また単独であったほうが良いファイルもあります。

コレ全部の仕様決めるのは大変ですが、一つ一つ詰めていきましょう。

**名前は開発中のものです。** · 04/04/06 11:23

作る課程を楽しむのならいいけど
ゲームを完成させるのが最終目的ならば富豪的プログラミングでいいとおもうけどなぁ

空中分解するスレ何度も見てきているので完成後の最適化とかバランス調整とか
そっちに時間かけて欲しいと思ったり

**親父PG** · 04/04/06 14:03

>>138
お気つかい有難う。
過程を楽しんでいるのはもちろんですが。
今はゲームを作る為の環境を整えているところです。
まったくの０からなので、時間はかかってしまいますが^^;

文字周りが一息ついたところで、WINDOWSシステムを作ります。
リソースデータ（構築データ－）より作成されるシステムとなり
データ－＞翻訳＞内部ルーチン呼出　という流れを
本格的にサポートする為の、雛型になると考えています。

**名前は開発中のものです。** · 04/04/06 14:57

親父PGたん、むちむち体型なの？
背は高いね。きっとダンディーなんだろうな。

ｵﾔｼﾞPGﾀﾝ（´Д｀）ﾊｧﾊｧﾊｧ

**名前は開発中のものです。** · 04/04/06 18:32

もしフリーソフトの
RPGツクール出来たら
凄い需要があると思う
この板の神になるかも

**名前は開発中のものです。** · 04/04/06 19:36

いきなりコードを書き始めるプロジェクトの顛末。
まあ期待しないでROMってるよ。がんばってね。

**新人PG** · 04/04/06 21:52

ただいま帰りました･･･。てか、親父PGﾀﾝ書き込み夜遅すぎ。一日ループしてしまいますね。
ちょっとまとめです。
１）トリガーデータ（フラグ管理やシーン遷移を定義）
２）シーンデータ（シーン管理。シナリオ、トリガーデータや画面管理用データと関連する？）
３）シナリオデータ（シーンデータと同義？）
４）ストリングテーブル（プレイヤーに表示するシステムメッセージ等？）
５）ファイルネームテーブル（ファイルを管理）
６）マップデータ（マップフィールド定義）
７）アイテムデータ（魔法やら道具やら敵やら・・・？）
８）画面管理用データ（システムデータ）
・・・等の定義ファイルがあるって事ですね。
僕からは１，２，３の草案より規格案を出していきます。(ひょっとしてもう頭の中では纏ってます？)
しかし、このファイルの感じですとシーンデータの負荷は大きいですね。
もうちょっとヒントをお願いします･･･ｗ
他４，５は最初はMAP形式のファイルで良いような気がします。
６はどうするんでしょう。俯瞰型かフロントビューの視点のRPGを想像していたのですが親父PG様はどう考えられてます？
７はまだまだ判りませんね･･･ｗヒントお願いします。
８は完成されていると言う事なので期待プラス参考させていただきマス。（８に１，２，３のデータとの絡みは無いですか？）

**名前は開発中のものです。** · 04/04/07 03:22

マップデータとトリガデータ分離するの？
編集はエディタのみで、単にファイルが分離しているだけならいいけど。
データ間の依存関係は、データ修正の手間が軽いかどうかを重視するのが
よいと思うがどうか。
３Ｄなら特定のオブジェクトをトリガとして扱う（ダミーノードやボーンがあるモデラなら
それを使う）
２Ｄなら、どーせマップエディタ作るんだから、編集はエディタのみの１箇所なので
無問題
って感じ？

あと、>>128
> 255種類もあれば大丈夫でしょう
ケチらなくてもｗ
こんな構造体作るよりは、スクリプトをキックしてスクリプトにフラグ判断させて、
スクリプトからイベント（ここではただの会話もイベントとしよう）をキックさせた方が、
作成も変更も管理もらくだと思うけど。

**親父PG** · 04/04/07 05:27

>>140 ﾊｧﾊｧキター（W
>>141 ツクールとは視点が違うのですが、データ－互換ゲーム環境を考えています。
その上でデータフォーマットを公開しますので、いろんなシナリオやサブセットプラグイン等を
募集いたしますorz　ｱｲﾃﾆｻﾚﾅｲｶﾓ....
>>142　半年前からコツコツやってました。これからも生暖かく見守ってお守りくださいまし...

>>143
どうもお疲れ様
＞てか、親父PGﾀﾝ書き込み夜遅すぎ。一日ループしてしまいますね
それは夜勤の時、コッソリ（Ry　まぁまったりいきましょう。１日考えるぐらいがちょうどいいやも

草案で出した案は最終的なバイナリのイメージです。トリガテーブルはそれれ自体が
フラグを拡張したものだと考えることができます。
１４４氏の発言＞スクリプトをキックしてスクリプトにフラグ判断
トリガーテーブル自体が他のトリガーやシーンを呼び出して、その結果を判断できます。
おっしゃることは実現可能かと思います。
シーンデータ－には、５W１H（のようなもの）が定義されます
ビューポート１番に定義されたウィンドをこの場所に開き、メッセージを表示しろ
以下「メッセージデータ」：戻り値
このようなデータになると思われます。
本体側インターフェースを提示しないと作りにくいとは思いますが、暫定で進めてください
ある程度はこちらも合わせます。
※私の申してる話は、データ－の最終形態なので、実際のツール類はそれぞれ最適化されたデータ－で
ソースを持つのがよろしいかと。しかし、最後はコンパイルされて、一定のバイナリに落とし込みます。

**親父PG** · 04/04/07 05:29

４ストリングテーブルには「固有名詞」や「ユーザー定義」の文字を収納します
st1 "ぴたごらすいっち"と定義　
メッセージデータ　#1はNHKのTV番組　＞ぴたごらすいっちはNHKのTV番組

６　struct MAPBASE{byte Maptype,MoveCost,ToDo,Maptype2}:
こんなのを配列で持つのはどうですか？

７　この部分はを考えるのは一番楽しい部分かなぁ（ｗ
　　属性追加タイプを考えています。熱く寒く丈夫で黒光りする腐った剣　とかorz結局ﾂｶｴﾙﾉｶ?ｺﾉｹﾝ...

８　バイナリデータ－で固定長データ－です。
それとは別にテクスチャテーブルもあり、セットで運用しています。
ちょっとずつ変わっていますが、この後出しますね。

**親父PG** · 04/04/07 06:09

struct ViewPortSetting{
　unsigned int　ClientSizeX,ClientSizeY,ViewPortSize;
　dRECT　　RECTS[MAXPANEL];
　dOption　OPTIONS[MAXPANEL];
};
struct dOption{
short int TextureNum ;//テクスチャー論理番号
short int TextureNum2;//テクスチャー論理番号２枚目
short int D3D ;//基本座標系　1 混在　2 2D 3 3D
unsigned char Z1; //1枚目Zの価
unsigned char Z2;　//2枚目Zの価
unsigned int hTexture2;
unsigned int hTexture;//上に貼り付けるテクスチャのハンドル　システム側でセット
unsigned int hTextureBox;//ポリゴンのハンドルシステム側でセットされる
};
２枚目のテクスチャは上に重ね合わせるためにあります。（抜き処理か半透明使用）

ボタンの設定一部略
struct dBOption{
short int Parent;//親のView番号
unsigned int SelfID;//自分自身の番号
short int BaseTexture;//テクスチャのＢＡＳＥ番号
short int CoTexture;//テクスチャ内の子ＩＮＤＥＸ番号
short　int BTOption;//動作　０なし 1以上の価でボタンアクションの種類を指定
unsigned int ON_LDownMouse;// アクション番号　０はなし
unsigned int ON_RDownMouse;/　ここで呼び出す関数番号を指定する
略
※シナリオからみるべきはボタンの処理番号になるのかな？
場面切替の場合はビューポート周りも見る必要があるかもね

**親父PG** · 04/04/07 06:10

閑話休題
戦闘システムですが、場にキャラクタが使うアイテム（魔法エッセンス）を宣言（スロット配置）して
その置かれたアイテムによって、使用できるコマンドが追加されていくというものを考えています。
またアイテムには持続ターンの設定がされていて、持続ターンを消化するとスロットから除外されます。

剣を主に使う場合（サンプル
剣を使用宣言＞「切りかかる」が使用可能
盾を宣言＞防御力UP　「受ける」が使用可能

魔法の場合
マナと秘薬宣言＞魔法○○使用可能

剣を中心とするユーザー
利点・持続ターンが長い
欠点・単体攻撃

魔法ユーザーの
利点・幅広いコマンド
欠点・アイテムの持続ターン

アイテムの使用と宣言は同時にはできないので「使用タイミング」を考慮しなければならない。
まぁこのへんはアイデア段階ですのでいろいろ変わると思います。
　

**名前は開発中のものです。** · 04/04/07 07:13

test

**親父PG** · 04/04/07 08:38

テクスチャのブレンドに関するパラメーター多いね　多すぎて何がなんだか＠＠＠
ひとつひとつ検証しますかのうorz...

「テクスチャ（４４４４）前面
　頂点色付ポリゴン」
　　　　　＋
「テクスチャ５６５」（背景）
　頂点色付ポリゴン」
+
「サーフェースカラー」

前面のポリゴンの頂点のアルファ値のコントロールでいければ良いのだけど
今、なんとなくやった設定では背景のサーフェーイスカラーに対してブレンドしてるね。
それはそれで必用な設定なんだけどね。
後ろの背景が消えて（無視）されて合成されているorz
設定できる（可能性）の幅が広すぎてトホホホです。

pD3DApp->m_pd3dDevice->SetTextureStageState( 0, D3DTSS_ALPHAOP, D3DTOP_MODULATE );
pD3DApp->m_pd3dDevice->SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
pD3DApp->m_pd3dDevice->SetTextureStageState( 0, D3DTSS_COLORARG2, D3DTA_DIFFUSE );

// アルファ合成の設定
pD3DApp->m_pd3dDevice->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
pD3DApp->m_pd3dDevice->SetRenderState( D3DRS_SRCBLEND, D3DBLEND_SRCALPHA);
pD3DApp->m_pd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, TRUE );

これから息子と嫁さん連れてバス旅行（隣の駅まで）行ってきます。

**144** · 04/04/07 08:57

>>145
もう１度読んでください。

前半部は、データ作成段階に入ってからの絵描き・プログラマ・スクリプタ・プランナ
それぞれの間のワークフローに関わる問題の指摘です。
様々なファイル間に依存関係があります。特に座標値を即値で持った場合には、
マップ変更で様々な影響があります。
不整合を起こさない仕組みをお考えであればまったく問題はありません。
相互に依存関係があるファイルを個別に修正すると（特に別々の人が）、様々な
エンバグが発生することでしょう。
マップエディタの例は、とりあえずトリガデータとマップデータの不整合を防ぐ仕組みの
具体例の１つとして出しただけです。
決して最終バイナリの数を問題にしたのではありません。編集時です。

後半部は・・・特に色々問題をはらんでいるのですが・・・。

まず、２つの意味で、 seed を８ビットとする必要はありません。
・どーせパッキング単位が４バイトなのでメモリの節約にならない
・余ったビットはフラグにでも使えば良い
むしろ seed に名前をつけて文字列を格納し、実行時にアドレス（またはＩＤ）変換するくらい
富豪的でも問題ないと思います（つーか、パディングするって書いてあるけどｗ）。
データキャッシュが荒れるのを気にするならば、宣言を直してメモリを節約するのも良いと思います。

つづく

**144** · 04/04/07 08:58

ところで、>>117 の場所ＦＧって、単にフラグ番号？
場所っていうからマップの座標かと思ってた。
マップデータもただの配列だし、もしかしてまだ、マップアトリビュートテーブル自体が
話題に上ってなかった？
マップの特定の場所に行ったら起動するようなイベントはシステム側からフラグを立てて
それをトリガで拾うという仕組みをお考えですか？
なぜ、トリガデータがこんなにもスクリプト的な機能を持っているのか不思議だったのですが、
もしそうなら納得できます。
トリガデータはイベントハンドルテーブルのように扱ったほうがシンプルになると思います。

どちらにせよ、トリガデータの１レコードは豪華すぎるように思います。

んー、なんか、データ構成見てると、ソーサリアンを作れそうに見えない・・・。
アトリビュートテーブルがないせいだとは思うんだけど、マップ -> イベントキック -> シーン
の流れが見えないと・・・。
もしかして、MAPBASE::ToDo がイベント起動？
そんなことしたら、同じマップで違うイベント配置の時に管理が破綻しない？
まさかねぇ・・・。
まあ、それこそ編集時はイベント名の文字列で管理すればいいのか、な・・・？

**親父PG** · 04/04/07 09:11

>>144
いろいろな考察ありがとうございます。きちんと整理してご返答したのですが、
あいにくバスの時間がｗ戻ってきてきちんと返答します。

MAP＞イベントキック＞シーン　この方法には２つ方法があると思います。
MAPにイベント番号を入れる方法と
MAPにはイベントがあったことのみのデータ－で　管理側でXY座標を引数にイベントトリガー内を検索します。
とちらにも利点欠点　あ時間だ　帰ってきて書き込みます

**（´Д｀）ﾊｧﾊｧ** · 04/04/07 12:02

親父PGﾀﾝはブリーフ派？トランクス派？

**名前は開発中のものです。** · 04/04/07 12:26

ふんどしに決まっているだろ。

**名前は開発中のものです。** · 04/04/07 12:56

ぱんつはいてない

**名前は開発中のものです。** · 04/04/07 14:22

>>親父PGさん
玄米食え、玄米。

**親父PG** · 04/04/07 14:26

>>154 155 156
orz.....
>>155
川口にいって桜を見物してきました。今日はいい天気で子供達ものびのびと羽を伸ばしてきたようです。
トリガーテーブルはそれ自身に起動条件を備えています。
またトリガー自身がトリガーを呼ぶことが出来ますし、他のトリガーからも呼ばれます。
さて地形MAPについてですが、これにはシステムに対してトリガーをチャックしろというトリガーを引きます。
プログラムに流れは以下のようになります。
キャラ移動＞該当MAPの配列調査、トリガテーブル起動命令がある。
トリガーテーブル検索、トリガーテーブルの演算＞シーン起動

さて編集時の問題についてここで解決策を述べておきます。
MAP編集ツールはトリガーテーブルに追記することができます。
MAPツールで編集するのはX座標aY座標bでトリガーがあるということだけです。

あとでシーンデーターで、その追記された部分を補完すればよいのです。
トリガーテーブルは固定長なので扱い易く、いろんなツールで追記することができます
複数人数での作業もトリガーテーブルを、マージしながら作業を進めることになります。

○トリガーの設定
とある座標にトリガーを埋め込む。MAPの配列該当部に任意の価を入れる。
同時にトリガーテーブルに座標を引数とするトリガーテーブルを追記する
（何をするかはここで編集しない　※できるようにしても良いとは思いますが）
○座標の書き換え
とある座標でトリガーを設定していたが、座標移動することになった。この場合MAPデータ－は
自身のトリガーテーブルの該当座標が記録された部分を書き換えます。
（※この作業の為にシリアル管理しても良いかもしれないね。）
○複数人数の作業
トリガーテーブルをマージします。「違うMAPの場合どうするのだ？」というご指摘がありました
その場合トリガーテーブルごとに入れ替えるか、もしくはMAP番号も引数に加えれることで解決します。
○トリガーテーブルはCSV化してEXCELで簡単に一覧化できる。簡易マクロでエラーチェックもおこなう
トリガーテーブルは計算式　IF文を処理する機構なのです。 FG（フラグ）は変数置き場です。

**名前は開発中のものです。** · 04/04/07 19:19

子供は娘さんですか？

**名前は開発中のものです。** · 04/04/07 20:11

子供は娘さんですか！？？

**名前は開発中のものです。** · 04/04/07 21:05

娘さんは私が責任を持って育てさせていただきますので
どうぞプログラムに専念していただきたい！！！！！！
なんの心配も要りません！！！！！！！！！！！！！！

**名前は開発中のものです。** · 04/04/07 21:29

以後、親父PGの娘さんを奪い合うスレッドになります。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

**名前は開発中のものです。** · 04/04/07 21:46

ありがとうございます。
では娘さんをお迎えに
行かせていただきます！！！！！！

**名前は開発中のものです。** · 04/04/07 21:50

ジャイコちゃん、お迎えが来るから早く準備して。

**新人PG** · 04/04/07 21:50

http://www.geocities.jp/oyajipg/up/relational_01.gif
ちょっとトリガーと地形の事についてまとめてみました。
思った事を書きます。
・トリガーのCmpOP（比較方法）は要らないんじゃないかと思っています。
プログラムの実装でカバーできるんじゃないでしょうか？
・トリガーのActCommandはデータは大きく確保しておいた方が良いのではないでしょうか。
私は複数の処理を羅列して書けたら良いと思っているので可変長配列がいいと思いますが。

実は個人的には地形データにトリガシリアルを記述する事に賛成ではありません。
別のデータ（アイテムデータ等）が持つデータだと思います。
アイテムデータがトリガ情報を所持していて、それが地形データの上にあるとすると、
アイテムデータトリガ呼び出し　＞　地形データの座標等チェック（トリガへの付加情報）　＞　トリガ処理
という流れが出来るので良いと思っています。
抱合関係はファイルデータを参照して
●シーン　:=　トリガ　:=　アイテムデータ｜　地形データ　｜　シナリオ
このようなイメージを持っているのですがどうでしょう？

**新人PG** · 04/04/07 22:10

あ、あと細かい事かも知れないけど、MAPって聞くとデータ構造の方を思い浮かべてしまって混乱してますｗ
呼称「地形」で良いスか？ｗ　（ごめんなさい、ほんとに判らないんです）

**名前は開発中のものです。** · 04/04/07 22:16

俺的にはマップとmapでわけてるというか
会話になると混乱するかもしれん

つーか、普段の会話でmapってでてこないしなー
hashmapとか実装込みで離すだろうし

**新人PG** · 04/04/07 22:35

>>167
マップが地形の方でmapがデータ構造の方？ｗ
うちの会社ではiniファイルもpropertiesファイルも全て「マップファイル」と呼びます。（ｶﾞｸﾌﾞﾙ

しかし、データ構造やシステム面から詰めていってゲームって作れるんでしょうか。
本当に行き着く先がRPGツクールな気がしてきましたｗ
ラフ絵等が出てくると雰囲気出て良いかも。

**名前は開発中のものです。** · 04/04/07 22:44

そしてそういったゲームには欠かせない
絵とか音楽とかシステムまわりがこのプロジェクトにはまったく無い
技術ありきだとプログラマ本人以外ついていけんしな

**名前は開発中のものです。** · 04/04/07 23:16

ああ。。僕の真鈴たん（仮名）早く逢いたいよ。。

**新人PG** · 04/04/07 23:55

寝ます。
親父PGﾀﾝ夜勤ご苦労様です。

絵柄は洋ゲーっぽく、渋くクドイのが良いなぁ･･･。
硬派さを出したいｗ

**名前は開発中のものです。** · 04/04/08 04:23

なんだか凄そうなので、3Dだったらぜひ一枚かませて欲しいです。
激渋グラフィック大好きなので。必要になったら声かけてくだちい。
ひっそりのぞいてます。

**親父PG** · 04/04/08 05:31

>>165
お疲れ様！
Gif画像がモビットになってるorz HPに上げてくれると助かるです
まとめ画像を見てない状態ですが、いくつか私の意見も書いておきます。
＞・トリガーのCmpOP（比較方法）は要らないんじゃないかと思っています。
＞プログラムの実装でカバーできるんじゃないでしょうか

トリガーテーブルは仮想CPUに対する命令です。この部分にゲームの「分岐」に対する情報が書き込まれます。
これらの情報は「シナリオ作成者」が担当するものなのですが、シナリオ作成者に「Cを書け」と言っても無理な注文です。
そこで、それを解決する方法として考えたのが分離方式です。
煩わしい制御コードに悩むことなく、文章部分に集中してもらいます。

トリガーテーブルは以下のようなインターフェイスで、編集を考えています。
▼はプルダウン　[]は価入力
条件NO００２３「▼FGの価」[34]と「▼トリガーの結果」が「▼等しいなら」「▼シーンの」[２３４]を処理

可変長にしないのはデータ－作成者のレベルを配慮（IF文より難しいことを避ける）
メインPGが使用するときの検索の高速化
いろんなツールが読み込んで作業する為のデータの単純化　など
トリガーテーブル部分だけ準PGがやることによって、ゲームスクリプトの矛盾発生を押さえ込む。
いくつかの理由があります。

**親父PG** · 04/04/08 06:14

続き
・トリガーのActCommandはデータは大きく確保しておいた方が良いのではないでしょうか。
そうですね。引数もふくめるとおっしゃるとうりです。この部分は拡張しましょう。

＞別のデータ（アイテムデータ等）が持つデータだと思います。
＞アイテムデータがトリガ情報を所持していて、それが地形データの上にあるとすると、
＞アイテムデータトリガ呼び出し　＞　地形データの座標等チェック（トリガへの付加情報）　＞　トリガ処理
＞という流れが出来るので良いと思っています。

アイテムデータ－にはトリガー情報は含みません。例えば、ある地点でアイテムを拾うというイベントがあったとしましょう。
キャラデータ－が移動、地図配列をチェック、トリガーがある。>トリガーテーブルから該当するトリガーを探し出す。
トリガの１番目のコマンドを調べる　（シーン１と書いてある）
　シーン１　メッセージの表示「アイテムを拾いますか？」
　選択メニュ表示　戻り値をリターン
トリガの１の価取得終了　トリガの２の価取得開始　（ダイレクトの価１）
比較命令に従って２つの価の比較　条件によりアイテム取得トリガー呼出（引数　任意のアイテム番号）
このような流れになります
シーン１の情報が変わってもトリガー情報に影響がありません、逆もしかりです。

＞＞実は個人的には地形データにトリガシリアルを記述する事に賛成ではありません
これは１４４氏の指摘にある「地形データが入れ替わった時どうするのですか？」に対する
解決案のひとつ。同座標にトリガー埋め込んだ場合どうする？　という問題ですね。

＞●シーン　:=　トリガ　:=　アイテムデータ｜　地形データ　｜　シナリオ
＞このようなイメージを持っているのですがどうでしょう？
私のイメージは

地形データ＞＞＞＞トリガー＜＜＜＜シナリオ
独立アイテムデータ－
このようなイメージを考えています。　トリガーテーブルを中心に他は従属関係にあります。
＞うちの会社ではiniファイルもpropertiesファイルも全て「マップファイル」と呼びます。
prz.... このスレでは地図データ－は地図データ－もしくは地形データと呼ぶようにしましょう。

**親父PG** · 04/04/08 06:38

続き
＞しかし、データ構造やシステム面から詰めていってゲームって作れるんでしょうか。
＞本当に行き着く先がRPGツクールな気がしてきましたｗ
＞ラフ絵等が出てくると雰囲気出て良いかも。
メインPGの最初のステップは、ステージを作ることですので最初は仕方の無いことでしょう。

画面イメージなどは今ちょこちょこ作ってます。お友達にキャラ絵も数点お願いしました。
（決定原稿ではないですけどね）元少女漫画家（出産の為引退）された方です。

ゲームの雰囲気ですが、私の隣には数年前に上野の博物館であった「ケルト神話」の展覧会の本が置いてあります（W
そこから察してください。^^;

>>172 >>169
最初はライブラリの構築からマッタリという考えだったので、イメージとかの資料を提示できずにいます。
申し訳ない。劇渋３D大歓迎です。そうだ！１点お願いしてもいいでしょうか。
１２８＊１２８で武器（種類問わず）を１点お願いしてもいいでしょうか？
デザイン背景はケルト神話で基調カラーは青に緑が加わった色。
アクリル絵の具でいうところの「Compose Blue」でお願いします。

と勝手にお願いしていいのか俺orz

劇渋路線が人気あるようですね。私もラリーエルモア大好きです。

背景テクスチャポリゴンと前面テクスチャポリゴンがうまく半透明にならないと
いろいろ苦慮していましたが、原因は「背景データ－を先に描画していないから」
という結論でしたorz.....ｱﾎｽｷﾞﾙ
各テクスチャ事にレンダリングステート登録する機能作ったのに...全然別の理由だった（鬱だ
この機能は現時点ではいらないことが発覚（ｼｮﾎﾞｰﾝ　orzﾅﾆｶﾆﾂｶｴﾙｶﾅ....

閑話休題
子供はまだ３歳と５歳だよｗ

**名前は開発中のものです。** · 04/04/08 08:54

子供ください

**名前は開発中のものです。** · 04/04/08 15:10

いきなりマニアックな内容でさらりと語るのはやめてくれ。
せめて参考になりそうなURL用意するとかして欲しいぞ。

コンポーズブルー
ttp://www.fairy-land.to/shop/moji/c-sample.html

エルモア
ttp://www.larryelmore.com/

**名前は開発中のものです。** · 04/04/08 15:26

エルモアってなにか遠い昔に聞いた名だなと思ったが
D&Dのパッケ描いた人か…。

**親父PG** · 04/04/08 15:40

>>176 orz...
>>177
調べてくれて有難う。こんなHPあったんだねorz
僕が中学生の頃、D&Dのイラストを見て、激しく感動したイラストレータです

RPGの話をするならこの人は避けて通れません。

Windowのパーツを作り始めました。仕様もこれから固めていきます。

イメージのたたき台になりますかね？

**名前は開発中のものです。** · 04/04/08 16:06

　|　ああ～　やっぱ３歳は　　　　／
　|　　　　シマリがいいな～！！　／
.　　　＿＿__
　　　| |・∀・|　／⌒⌒ヽ
　　　| |＼　|`ｲ　ノハぃ）　ｶｸ
.　 (( |_|＿ｨ⌒`｣ ∥' ､ｿ|
　　　ノと､_入`_,つ λ う
　ｶｸ

**144** · 04/04/08 16:49

トリガテーブルは固定長じゃないほうがいいと思うよ。
で、番号じゃなくて名前の文字列にしよう。
で、std::map< std::string, TriggerAndProcess > みたいなのに突っ込もう。
ハッシュでもいいけど。

マップの方では、トリガ番号をセルに埋め込むのはよろしくないと思う。
３Ｄにしたときにどうしようもなくなる。
その代わりに、アトリビュートファイルを作ろう。
アトリビュート範囲とトリガの名前が書いてある。
（もちろん、マップファイルの固定長地形データ配列の次にくっ付けても
構わないが、実行の問題じゃなくて構造の問題ね）

トリガの条件判断は、やはりスクリプトに譲ったほうがよいと思う。
寄り道できない一本道のシナリオなら今のトリガテーブルの条件記述
で構わないと思うが、ちょっと複雑になったら、結局素人の手には
終えなくなると思う。
当面は今のトリガ記述方法で良いと思うけど、早いうちからスクリプト
への変換をしておくと、トランスレータだけいじればよくなるので、
トリガデータ構造はもっと柔軟なもの（できればスクリプト）にしておいた
ほうが良いだろう。

**名前は開発中のものです。** · 04/04/08 17:15

親父PG氏、ソーサリアンとかD&Dとか言ってる時点で
俺と同世代っぽいなー。

**親父PG** · 04/04/08 17:53

>>144
ご意見ありがとう。いろいろとご意見を私なりに整理しました、話をすすめていく上で確認すべき点があると思います。

私が提起しているデータ－形式は、そのまま「メモリの上に展開して動かせる最終形態」の話です。
プログラムの中でSTLを使うにしても、バイナリデータ－の並びを解釈してCPUを動かさなければなりません。
前にも述べましたが、スクリプト（テキスト）を動的に解釈するメリットはないので、
中間言語およびスクリプトで書かれたコードは全てコンパイルが済んだ形（バイナリ）にします。
そのバイナリ形式が提案している形になります。
ただし、その前工程でどのような形でデータ－を扱ってもかまいません。

例えばコンパイラはテキストで書かれた命令文を最終的にCPU命令に置き換えます。（MOV　AX、CX）
といった単純な命令群に置き換わります。今回のゲームデータ－についてはここまで単純化してはいない（必要が無い）ですが、
その一歩手前にある（構造を単純化して高速化）といえます。
std::map< std::string, TriggerAndProcess >を使用する場合、
プログラム内で「このデータ－をMAP（STL）にPUSHしてくれ」という、コードを入れなければなりません。
そういったレベルでスクリプトを組めるのはPGレベルの人だと思いますorz...

**親父PG** · 04/04/08 17:53

続き
＞std::map< std::string, TriggerAndProcess > みたいなのに突っ込もう
実際問題としてトリガーがトリガーを呼ぶ構造なので、スタックという形で動的配列は使用します。
それはデータ－を解釈するPG側の話なので、そのあたりについてはお任せください。
>>トリガテーブルは固定長じゃないほうがいいと思うよ。
可変長が必用な場合、トリガーテーブルを２個（以上）使って表現すればよいのです。
トリガーがトリガーの結果を呼び出せるという構造で、柔軟な動きに対応できるはずです。

＞当面は今のトリガ記述方法で良いと思うけど、早いうちからスクリプト
＞への変換をしておくと、トランスレータだけいじればよくなるので、

逆にいえば、RPGのデータ－ツールに複雑な構造を単純化しうる機能が必要になるのです。
最終データ－を扱う段階で、英文翻訳ソフトのようなプロセスを行うことは致しませんよ。

３DについてはZ座標を別途持つことでは対応できないのかなぁorz
誤差範囲とかも必用だけど基本はBOX判定だろうし........

※どのアイテム、動作、動きにていて基底データ－のようなものを定義するのは有用かもね。C++でいう基底クラス

**名前は開発中のものです。** · 04/04/08 18:02

スクリプトをＣＰＵバイナリにするメリットなんてあるの？

解釈しやすいバイナリにするのなら当たり前だけど
移植性や可読性を考えると命令セットに依存する部分って必要ないような
ＣＰＵやモードが替わったりすると確保するバッファサイズが様々になるので
メリットないと思うんだが

ついでにいうとテキストレベルのスクリプトを動的解釈しても５００ＭＨｚ
超えているマシンなら問題になりにくい
デバッグの課程を考えるといわゆるインタプリタレベルのデバッグモード
という位置づけも必要になるんじゃないの？

３Ｄについてどうのこうのってのは再ショアから作るものが決まってないからそういったことになる
ソーサリアンを目指すというのならたとえばサイドビューとか
作るものが決まってないのならそのへんの最適な解は見つからんよ

**親父PG** · 04/04/08 18:05

>>178
思い出しましたか？^^;
>>180 orz....
>>182 ﾆﾔﾘ　-）

WINDOWの構造体造ったはいいがツール作るのが面倒で鬱ぬ。

**親父PG** · 04/04/08 18:18

>>185
CPUはたとえでありまして、実際にCPUバイナリにはしません。
動的スクリプト解釈についてはメリットがないと思うのです。
同じ処理を事前に済ましてしまえばいいのですから。

「物理できなデータ－の塊を解釈して動作させる」という動きの比喩でCPUを上げました。
さて今回必用な話に戻すと、データ－の塊を逐次解釈して動作させます。
その基本形が提唱している固定データ－（トリガーテーブル）（中間コード）になります。

動的スクリプト解釈をするにしても起動時に一旦コンパイルして中間コードに、並べてから動作させます。

１ラインごとに解釈するはずはありません。特に今回のケースではメリットがありません。

**親父PG** · 04/04/08 18:36

新人PGさん＜この呼び方なんかすごく恐縮なので,
せめてベテランPGさんとかにしてほしいなぁqrz

閑話休題
まとめていただいた図　造って頂いて有難う
http://www.geocities.jp/oyajipg/up/relational_01.gif

ずばりです。各トリガーの必用な引数などは追加する可能性がありますが、
おおよそこのようなつくりです。
トリガーテーブルと呼んでいますが、これって（中間コード）ですよね。

MAPからの引数はZ値も入れましょう。
ゲームの種類のよっては使わないかもしれませんが...

**名前は開発中のものです。** · 04/04/08 18:54

トリガーからトリガー呼ぶのはいいがそのへんはシステムがインテリジェントにやってくれて
スクリプトを書く人は意識しないでいいんですよね？

たとえばjava風だとadd～listenerみたいな感じでイベントリスナ追加で
一度発生したイベントが次に発生しなくなるならremove～Listenerとか

あくまでもトリガテーブルに処理は書いちゃいかんと思うのですよ

**親父PG** · 04/04/08 19:33

>>189
たくさんのご意見ありがとう。

トリガーテーブルはそれ自身がスクリプトともいえます。
自身を管理する処理は最低限行えます。
もちろん、メッセージを出すといった「処理」はかかれません
そういう場合は処理が書かれた「シーン」を呼び出す事になります。
トリガー自体を有効無効については、そういうFGが入ってもいいかもしれませんね。
Enable
Enableの価によってリムーブをコントロールしましょう。
ADDについては、フラグテーブルの後ろに物理的に加算することで表現できます。

＞トリガーからトリガー呼ぶのはいいがそのへんはシステムがインテリジェント
内部的にはそうなります。
命令の組み合わせを作り出すのはツール側になります。

例えばCのswitch-case文などをif文の羅列に並び替えるような処理は、ツール側の仕事になります。

**新人PG** · 04/04/08 23:33

ただいま帰りました･･･。

>>親父PGﾀﾝ
ようやくデータ構造が見えてきました。順にまとめていきたいと思います。
↑日曜日以降になりそうです。週末予定が入ってしまいました･･･orz
今年入社なんで「新人PG」ですｗ　社会人歴１週間です。

モビットってなんだろーとか思っていたら、2chから直リンするとモビットが出ますねｗ　URL直接指定してください（汗
あと元少女漫画家の友人に注文しても良いですかね？　

男だろうが女だろうが　筋　肉　モ　リ　モ　リ　で

よろしくお願いしますｗ

**172** · 04/04/08 23:47

>>親父PG
いまんとこ2Dゲーになるのか3Dゲーになるのかわかんないので、
もし今後このシステムで3Dゲーを作ろう！となって
3Dモデルとかモーションとか作る肉体労働者がたりねー
みたいな事態になったら声かけてくだちい。
（イラスト描いたりデザインしたりはデキネ。）
プログラムにも興味あるのでずっとタシロってると思いますので。。。

**親父PG** · 04/04/08 23:59

>>191
お帰りなさい。
＞ようやくデータ構造が見えてきました。順にまとめていきたいと思います。
それは良かった。スクリプト作成側にも最適化等の処理を求めますので、データ構造の意味が理解していただけないと
なかなか説明が難しいと思っていたところだったので、安心しました。

＞モビットってなんだろーとか思っていたら、2chから直リンするとモビットが出ますねｗ　URL直接指定してください（汗

あれ、かなりつぼにはまって笑いましたよｗ

＞あと元少女漫画家の友人に注文しても良いですかね？　
＞男だろうが女だろうが　筋　肉　モ　リ　モ　リ　で

なるほろ、間に合えば連絡しておきます。

>>192
そうですか、では３Dになったら即お願いします。^^;

**名前は開発中のものです。** · 04/04/09 02:52

>>184
> ３DについてはZ座標を別途持つことでは対応できないのかなぁorz
> 誤差範囲とかも必用だけど基本はBOX判定だろうし........

ナナメ

**144** · 04/04/09 04:52

>>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

つづく

**144** · 04/04/09 04:54

って感じ？
ソーサリアンでは、反応する場所では、とりあえず反応がなくなるまで上連打が基本だったと思うけど。
これより簡単にしようとすると、
・条件が一致したら、自動的にフラグをインクリメントする比較命令を作る
・複合命令を（例：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 を書き換えることも考慮したが、余計わかりにくくなった
（セーブするのに、シナリオで使う前マップも保存しなきゃならなくなるし）。

**144** · 04/04/09 04:56

トランスレータを書く前提で、スクリプトで上記を書き直してみよう。
　青い宝石のある位置に、イベント名 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 も俺。

**親父PG** · 04/04/09 07:10

>>194-197
144氏さん　考察ありがとうございます。今回のケースはswitch文の構文が適していますね。

switch (fg){
　case 0:{seen1;++fg;break;}
　case 1:{seen2;++fg;break;}
　case 2:{seen3;++fg;break;}
default:{NonOp}
}
Cで書くとこうなります。これを置き換えます。
777 （MAPposition） X,Y EQ （価）a ,b start switch 4
778 （fg）A eq 0 CALL シーン1（fg　A）
779 （fg）A eq 1 CALL シーン2（fg　A）
780 （fg）A eq 2 CALL シーン3（fg　A）
781 CALL シーン4（fgA）
782 return(0)

シーン0
deviceWait()
KEYUP：メッセージ出力１、++FG
KETLEFT:メッセージ出力２、FG=0
return (next)

**親父PG** · 04/04/09 07:10

シーン側も以下のようにコンパイルされます
(Keydevice) a start switch　2
a EQ KEYUP goto localindex 1
a EQ KEYLEFT goto localindex 4
PUTMES 1(文字列INDEX)
FGOP　+1
return
PUTMES 2(文字列INDEX)
FGOP　0
return

データ－のお尻に追加
文字列
array index of string
max　...
0,24
"宝石が..."
"宝石を拾った..."

あとで説明文書きます

**親父PG** · 04/04/09 08:07

続き
シーンデータについて考察してみました。シーンデータ－は以下の要求を満たす為に定義されます。
○ゲーム内の処理命令を表す　○可変長をサポート　○ストリングが入る　○また、ここに１つだけ判断文を定義する事ができます。
定義できる判断文
DeviceWait系　ButtonPush系　設定なし　FGに対する操作　他のトリガーの呼出

DeviceWait系、ButtonPush系
この２つは内部的にはトリガーテーブルを呼んでいるのと同じなのですが、シナリオの文法上煩雑になるので１文で定義できるようにします。
戻り値に対して処理のスタート部分を分岐できます。
・スクリプト上の文法
deviceWait()
KEYUP：メッセージ出力１、++FG
KETLEFT:メッセージ出力２、FG=0
・展開された形
(Keydevice) a start switch　2
a EQ KEYUP goto localindex 1
a EQ KEYLEFT goto localindex 4

・実際の処理はこのあと１行ずつ定義されます
PUTMES 1(文字列INDEX)
FGOP　+1
return

これらの１行１行もあのトリガーテーブルと同じフォーマットで表すことができます。
文字列は別の場所に一括してまとめられて、内部ではインデックス扱い　char*[a]　に置き換わります。
シナリオを書く時の文法とコンパイル後の文法やデータ－の配置は異なります。
シナリオを各段階では「可変長」で表記できます。

＞シリアルナンバを使用するのは、配列のアドレッシングのためでしょ？
これは少し違います。地形MAPを切り替えた時に、同時座標のトリガーを判断するためにあります。

**親父PG** · 04/04/09 09:26

すこし拡張しました
struct {
int SelfID; //シリアル番号
int CommandID;//基本命令系　
byte CmpSeed1;　　//int CmpTarget1が何を示すかの種類　FGテーブル　デバイス　関数戻り値　値
int CmpTarget1;　//値
int CmpTarget1_2;　//値(予備)
byte CmpSeed2;　　//int2 CmpTarget1が何を示すかの種類　FGテーブル　デバイス　関数戻り値　値
int CmpTarget2;　//値
int CmpTarget2_2;//予備
byte CmpOP;　//上の値の比較方法
byte CmpOP; //真/偽どちらを使うか？ (追加
short int ActCommand ; //何をするか？　MOVE　FG値操作　次処理　シーン呼び出し
int ActValue1;　//値　ActCommandによって扱いが異なる
int ActValue2;　
int ActValue3;
int ActValue4;
//リザーブ　
};

**名前は開発中のものです。** · 04/04/09 16:26

もう何がなにやら・・・

**名前は開発中のものです。** · 04/04/09 16:48

ﾁﾁｷﾉﾄﾞｸｽｸﾞｶｴﾚ

**名前は開発中のものです。** · 04/04/09 19:40

俺はスレ主には特に何も言わんが

けっこう可愛そうな奴らがいるみたいだなぁ　この板には

**名前は開発中のものです。** · 04/04/10 03:46

がんがれ

**名前は開発中のものです。** · 04/04/10 06:51

おおよそ固まるまでsageで行ってみてわ？　＞ｵﾔｼﾞさん

**親父PG** · 04/04/10 09:25

>>202
PG以外はなんだがわけわからないですね。反省orz...
前の書き込みに「戦闘システム」の計画を書いたので何かご意見をいただければ幸いです
>>203
何処へ帰ればorz
>>204
まぁマッタリいきましょう
>>205
OK!

>>206
了解。　今日も仕事ですorz こっそり書き込みです。
現在ツール側を作成しておりまして、本体側の進行はSTOPしています。
そのツールが完成して、本体のPGに反映された頃に一回公開します。
といってもボタンとウインドとテキストのコントロール部分だけですけどねorz

**144** · 04/04/10 13:01

>>198-200
トリガから別のトリガを呼び出せるというのは書いてあったけど、return まで逐次実行ってのはどこにも書いてなかったよ。
後出しだしズルいよｗ。
ま、それはいいとして、オヤジﾀﾝの記述例では、トリガもシーンも、オヤジﾀﾝのいうＰＧ以外が対応できるレベルにみえないけど。

それと、トリガテーブルって、同時にいくつも存在するの？
同時ってのは、実行時の話なんだけど、仮に１つだとすると、エクセルとどのように整合性を保つのかな、と思って。
シーンファイルに、トリガサブルーチンがあるのはいいと思うけどね。

なんかもう、普通のスクリプトのバイトコードと話が変わらないように見えるよ。
単にバイトコードのフォーマットが見たことないほどリッチなだけで。
そして、エクセルで入力すると言い張ってるのは、アセンブリ言語での記述を要求しているのと等価にしか思えない。

> ＞シリアルナンバを使用するのは、配列のアドレッシングのためでしょ？
> これは少し違います。地形MAPを切り替えた時に、同時座標のトリガーを判断するためにあります。
地形マップを切り替えるというのは、
・どこかのマップでスイッチを入れる
・別のマップで跳ね橋が下りる
のようなときに、マップチップテーブルだけの入れ替えをするような話だよね？
それをシリアルナンバで判定するということは結局 std::map< int/*シリアル*/, int/*トリガ配列の添え字*/ >
のような形で判定するんでしょ？
俺は、エクセル上でもシリアルナンバの入力を強要してるのかと思ったんだけど、トリガコンパイラが文字列で
解決してくれるならそれでいいと思うよ。

ところで、>>189 で MAPposition で比較してるけど、本当は MAPBASE::ToDO に 777 が入ってるんだよね？
そうじゃなければ、エクセルで入力するときはコンマ付で入力？マップの大きさは最大２５６ｘ２５６？

自信あるみたいだから、思うとおりにやってみるといいでしょう。
使い物になりそうなことは分かったし。

**名前は開発中のものです。** · 04/04/10 16:08

後出しって・・・・なんかの勝負でもしてるのか？

**親父PG** · 04/04/10 20:09

>>144
いろいろと検証ありがとう。いろんな角度から見てもらえてるので、実に助かってます。
対策として具体的な仕様も決まっていくしｗ
まず書き方の例ですが、ここでの話を判りやすくするためであって実際の文法はもっと判りやすくなるはずです
このへんは「新人ニューウェーブPG」氏に期待します^^。
メイン担当としては、「最終バイナリはこういうイメージにしてね」と伝えなければなりません。
データの意味（解釈方法）を伝えるためにCで書いてみたわけです。

１４４氏の指摘の多くは私の作業より、一つ上のレイヤーの話と思える部分があります。

トリガーテーブルは（エクセル「でも」編集できる）ここが味噌でエクセルの機能を使って
レコードの操作をいたします。（エクセルと同じ機能のツール作るのは大変だｗ）
多重ソートとかマクロ機能とかね...別途作ってもいいけど。
エクセルコンポーネント使うなら一緒だ（orz...ｺﾚﾀﾞｹﾃﾞﾓｴﾂｷﾙﾖ
利用理由は主にチェックです。デバックですね。これってありがたいんですよ。ええ（独り言モード

トリガーテーブルは基本は一つですが、動的に後ろに追加しても仕様上動きます。

地形MAP配列にはトリガーを引くことしか指示しません。引数は座標XYZ（65535）＋MAPシリアル（65535）になります。何をするかはMAP側ではなくトリガー側が判断します。

作業予想
地形MAPツールは地形データ-とトリガーテーブルを読み込む。
イベントを行いたい場所へマウスでマークしていく。
このときトリガーテーブルにもトリガー情報のみのデータ-が追記される。
保存...
再度開いた時はトリガーテーブルのMAPシリアルを見て以前のマーク場所を再配置する
STEP２
イベントツールはMAP作成ツールによって作られたトリガーテーブルに、必要な情報を追加していく。
このような感じになる予定です。

>>209
勝負はしてないけどね^^　いろいろ言ってくれると助かるよ。

**親父PG** · 04/04/10 20:23

都築
＞地形マップを切り替えるというのは、

これは「地形MAP配列にはトリガーを引くことしか指示しません。」
この設定が前提にあります。地形データ-を入れ替えた時に同じ座標にイベントがあった場合
受け取った側が判断できません。そのためのMAPシリアルになります。

＞・どこかのマップでスイッチを入れる
＞・別のマップで跳ね橋が下りる

これはトリガーテーブルのイネーブルをONにすれば良しでしょう。

CAll MAP（B 3,3)//橋　　
トリガー親父　そのMAPのその座標のトリガーは「なし」だ。交信終了

Call (MAP　A　1,1)//スイッチON
トリガー親父　ウィ～ス　トリガ３番（橋のトリガ）イネーブルON
再び
CAll MAP（B 3,3)//橋　　
トリガー親父　ウィ～ス　橋をおろせセニョール　ついでに　MAP　A　1、1のフラグもイネーブルにするべ

こんな流れかな

**親父PG** · 04/04/10 20:39

誤>トリガー親父　ウィ～ス　橋をおろせセニョール　ついでに　MAP　A　1、1のフラグもイネーブルにするべ
生トリガー親父　ウィ～ス　橋をおろせセニョール　ついでに　MAP　A　1、1のフラグもディスネーブルにするべ

間違えた（汗

間違えたついでに
このシステムの目指すところを書いてもいいのではないかと。勝手に思ったので妄想を書き込みます

このシステムでは「キャラクターデータ-」が中心となり世界を広げていきます。
大昔、D&DというTRPGがありました。あのシステムも最初は赤本から始まりました。
ダンジョンにもぐり宝物を集め、経験値を上げていく。
たくさんのエキスパンション（シナリオ）が生まれてキャラクターは成長していきました。

本システムもこのような流れで大きくしていきたいと思っています。
エキスパンションを通じてのキャラクター成長。
そして、シナリオの作成についてはツールを公開して、誰でもDMになれるようなものを考えています。
シナリオをそれぞれ交換などする事もできるようにしたいと思っています。

またキャラクターに関わる事柄。お店だとか交換所なども一種のシナリオによって構築されます。

全ての完成にはまだまだかかりますが、そこは（追加型　という仕様がなんとかしてくれるはずです（W

**名前は開発中のものです。** · 04/04/11 00:46

>>212
でもあんまりシナリオとか簡単に作れるようにすると
あんまり知識の無い人でも簡単にズルができるようになるような。
まぁ、その人がつまらなくなるだけですけど。

**名前は開発中のものです。** · 04/04/11 01:02

>>213
その話は次元が違うものと思われ
本気で解読にかかられたらいくらプロテクトかけてもだめなのと一緒

**親父PG** · 04/04/11 10:09

>>214 213
バイナリエディタ程度では改変できない仕組みは考えていますが、
214氏のご指摘どうり本気で解析されればプロテクトは無理でしょう。

ローカルで作られたシナリオの経験はキャラシートに反映されないとか、対策はありますけどね。
あとはシナリオに適正レベルを設ける。

システム側でおかしなシナリオを最初から「エラーにより排除」するなど
いろいろと対策はありますけどね。
複合的なエラーチェックでめんどくさくするぐらいしかないのかなorz...

**新人PG** · 04/04/13 23:45

ただいま帰りました。仕事忙しすぎ。
だんだんまとめ辛くなってきましたが、ばんがります。

トリガーデータ案：草案を元にしたもの
[シリアルID]:数値５桁
[基本命令系]:わからん
[値種類１]:英数字５桁以内
[比較対象値１]:数値５桁
[値種類２]:英数字５桁以内
[比較対象値２]:数値５桁
[比較方法]:英数字？
[真処理]:英字？桁
[偽処理]:英字？桁
[パラメータ]:？？？
記述例）
00001,?????,Int,0,Scene,00020,Equal,ACTSCENE,00030,00002,MOVETRIGGER,00003

IDは00001、比較値１は数値型定数0、比較値２はシーン00020の戻値、比較方法は値等価判断
真の場合シーン00030を読み込みトリガ00002を起動、偽の場合トリガ00003に移動。

とりあえず、Excelで編集と言う事でXML云々は考えない方向で行きます。
このようなCSVを作成していく感じでいいんでしょうか？

**新人PG** · 04/04/13 23:49

なんか殆ど、親父PGﾀﾝの頭の中でできあがってるようですね（汗

俺、要るのかな・・・？

**名前は開発中のものです。** · 04/04/14 01:26

Excel前提ってのがまず汎用性で問題あるような
最近のマシンオフィス標準搭載かなり減ったし

その辺の自動化もツール担当の仕事かと

**親父PG** · 04/04/14 05:14

>>217
お疲れさまー、ご無沙汰しています。
＞このようなCSVを作成していく感じでいいんでしょうか？
違いますorz...SUMAN

エクセルの話ですが、あくまで「エクセルでも」データ－が見れるというものでありまして、
それはコンパイルされたデータ－を、バイナリ＜＞CSVツールで編集（デバック）できるように
するというものです。　よってスクリプト記章ツールは別に必要です。

>>217
ここ数日の書き込みでそう思われたのですねorz...

でも、決まったのはメインPGが受け取るバイナリの形でありまして、スクリプト記章ツールがいらなくなったわけではありません。
メインPG側の受け取りバイナリの形と解釈方法を提示しましたので、スクリプト側のツールはスクリプトの文法を（設計）設定して
予定のバイナリを出力するものを、設計してくれることを期待しています。
スクリプトの文法はXMLでも、オリジナルでもOKです。
ここで必用なことはシナリオライターが必要とする機能の調査と設計、機能の単純化などです。
バイナリからの逆復元（バイナリからのソース復元機能）は必用ありません。（ソースコード保存）

メインPG＜バイナリ＜スクリプトツール
　　　　　　↑↓
　　　　　　CSV
　　　　　エクセル

スクリプトの文法、設計はまったくの白紙状態です。新人PGさん、大変期待しています。

**親父PG** · 04/04/14 05:35

>>218
おつかれさま　EXCELは補助ツールなのでスクリプトツールは別途作成予定です。
メインPG側のバイナリの形さえ決まっていれば、スクリプトツールは自由に選べます。Excelもそのうちのひとつだと考えてください。
（もっともExcelの場合,スクリプトではなくバイナリエディタっぽい使い方だけどね。）

私の作業の報告
WINDOWの設定ツールがひとまず完成しました。１２種類のスタイルを定義できます。
メイン側は使用するときにこれらのスタイル定義にしたがって、先につくったボタン定義用のデータ－構造体より必要なデータ－をコピーして、
画面に作成します。現在、メイン画面にWINDOW本体と上部バーとクローズボタンを表示するところまでです。（WINDOWSの上にWINDOWS作ってるよorz...）

今日は久しぶりの休みです。ぼちぼち作業を始めます。

**名前は開発中のものです。** · 04/04/14 10:42

Excelでcsv扱うと文字列の先頭のゼロが数値として読み込むために消えたり
全角数値が半角になったりしてくれるんであんまり便利な物ではないですよ

ダブルクォーテーションでくくった項目は強制的に文字列として読み込んでくれるとよかったのですがね

**親父PG** · 04/04/14 10:50

>>221
それは拡張子をtxtで読みこめば回避できます。読み込み時にセルの属性指定可能。
このシステムに関してなら、トリガーテーブルに文字列はありませんので大丈夫です。

**名前は開発中のものです。** · 04/04/14 17:33

ひげぽんOSは飽きたのか？

**親父PG** · 04/04/14 17:50

>>223
こんなプロジェクトがあったんですね。知りませんでした。orz...
OSを作る気はありまえん（W　そんな能力はありませぬorz...

新人PGさんへ　既にご存知かもしれませんがこういうサイトがあります
http://www.ultrasync.net/dee/kr2helps/tjs2doc/contents/

私が仮想マシン側の設計ですね。

この板見てるとツクール派と、それ以外を使ってみたいという方がけっこういらっしゃるようですね。
自作であればスクリプトエンジンが必用ですが、そのへんはみなさんどうしているのかな？

**名前は開発中のものです。** · 04/04/14 23:06

>>223
何コイツ？

**名前は開発中のものです。** · 04/04/14 23:26

ここの親父はまだまだ若い方だろう。
・・・もっと親父になるとマジではかどらなくなるから
今のうちにやりたい事やっときなされ。

**WinMEMEME!fuckme!** · 04/04/15 00:25

ｕｎｎｋｏｂｕｒｉｂｕｒｉ？

**新人PG** · 04/04/15 01:04

ただいま帰りました。研修も無しにいきなり出向させられる会社ってどうよ（泣）

>>親父PGﾀﾝ
なんとなくわかりました。スクリプト言語（みたいなもの）を設計するって事ですね。
それならいっそのこと、トリガーだけではなくてシーン等も記述するできるようにしたいですよね？
あまり汎用的なものは考えていないのですが、現ゲームの作成に特化したものを目指すようにします。

#余談ですが、卒論のテーマと似ていますｗ
#流用しながら作る予定なので、早く作れるかも？

**親父PG** · 04/04/15 07:18

>>226
^^;ｶﾞﾝﾊﾞﾘﾏｽ
>>227
orz...
>>228
おつかれさま。お仕事大変ですね。
＞スクリプト言語（みたいなもの）を設計するって事ですね。
そうです。よろしくお願いします。
＞トリガーだけではなくてシーン等も記述するできるようにしたいですよね？
そうです。そして出力ファイルは分離して行われます。
トリガーとシーンは分離します。

＞あまり汎用的なものは考えていないのですが、現ゲームの作成に特化したものを目指すようにします
スクリプト言語内で一旦中間コードにして、そこから出力フォーマット用に変換するように設計すると良いですよ。
出力フォーマットを切り替えると、別の用途用に使えるように切り替える事も出来ます^^;（仕様変更にも強くなりますorz...）

#余談ですが、卒論のテーマと似ていますｗ
#流用しながら作る予定なので、早く作れるかも？

おお！　期待してますよ♪

**親父PG** · 04/04/18 17:10

しばらく書き込みがなくてさびしいので書き込みますorz...

日々少しずつ進んでいますが、なかなか進展しません。今調整いている部分が大掛かりな部分なので仕方ないのですがorz...
親父プロジェクトの構造

　　　　LIFE=trueであればACTトリガーvietualFunction
「基底クラススケジュール」→インプリメント部
　　↑　　　　　　　　　　　　　　↓各オブジェクト（ポリゴンなどをオブジェクト配列のデータより作成）
　　↑一定周期　　描画ループ
Windowloop　→→→　　　　　　　描画
　　　　　　　　　　　　　　　　　　　　　　　　　　↑
　　　　　　　　　　　　　　　　　　　　　　　　　　↑　　　　　　　　　　　　　　　　　　　　　
WindowMessage（OSトリガー）→範囲チェック→オブジェクトデータ－の操作

各オブジェクトデータ－配列（STL）
○WINDOWSクラス＜－現在作成中　登録済みのWINDOWのスタイルから複製を作って、ポリゴンーテクスチャーボタンなどを画面に配置する。
○ボタンクラス　テクスチャとボタンの振る舞い（トリガー）や描画をコントロール
○テクスチャクラス　テクスチャのファイルの読み込み部分切り出しなどをコントロール
○ポリゴンクラス　主に四角形を作りテクスチャが張り込まれる。線や点にも対応
○ポリゴンクラス３D　上の機能に３D用に派生したクラス
○ライトクラス　ライトを定義するポリゴンと同じように移動させることができる
○フォントクラス　フォント表示
○範囲クラス　範囲を定義する（３D対応）
○オブジェクトIDマネージャー　オブジェクトを作成した時にユニークなID番号を発行する。各オブジェクトの配列のINDEX値も格納してハンドルからアクセスしたいオブジェクトを識別できる
○プロファイルクラス　定義ファイルの読み込み
○コマンドクラス　下位コマンド全般を定義コントロールする為の関数群

さて、作業にもどりますorz.... パコに入っていたCDが出てきたので押し込んだらCIV３の画面が...激しく誘惑に駆られるｗ

**名前は開発中のものです。** · 04/04/19 18:50

今始めてきたけど、親父さんすごいなぁ。
全くわからん。
ＨＰでも立ててみたら?

**親父PG** · 04/04/19 20:15

>>231
どうも^^;
HPですが「新人PG」さんのご好意で以下のものがあります。
http://www.geocities.jp/oyajipg/index.html

さてWINDOWですが、複数面サポート。
クリックにより背面と前面入れ替わる動き。
タイトルバーの表示
キャプションの表示
クローズボタンの表示、MOUSEOVERで反応、クリックでウインド閉じる
タイトルバーをクリックして動かす
Windowのレクト領域の頂点に色を設定できる機能
Windowの半透明表示

こんな所までできました。
改めてWINDOWSのコントールオブジェクトを１から造るの面倒だなぁとorz...

しかも、スクロール機能、拡大縮小機能がありませんね。ﾏﾝﾄﾞｸｻｲorz.....

まぁWINDOWSを造っているわけではないので、ボタンとメニューとテキストを載せて、
動かせるようになったら、一旦収束してスクリプトに移ります。

バイナリを解読して仮想スクリプト用エンジンを造る事になります。
バイナリコードと命令表を作らないといけません。
ほんとコツコツだなぁ（笑

**231** · 04/04/19 21:14

おお、早速反応が来た。なんだかうれしい。
VisualC買うべきですかね。一応高校生なんでアカデミックで買えるから買ったほうがいいんですかね。
いや、Cのかけらもわかってないんですけど。
金がないからDev-Cという安易な考えは捨てちまったほうがいいですね。
紹介していただいたページにも書いてあるし。
んじゃ、がんばってください

**親父PG** · 04/04/19 21:46

>>233
アカデミックですとC++.net１００００円しないんですよね。
フルで買っても２万５千円ぐらいかな？

ちなみにC++.net単体でCの学習は辛いかもしれない。
言語の解説は入っておらず、クラス構成が書かれたポスターのような表が何枚か入ってるだけ。
最初の事初めでしたらC#のほうがマネージドコードやコンポ－ネントなどが使い易くてよいかもしれませんね。
(C++.netでも使えるけど、ディホルトの設定では使えなかったりするしorz...)
フリーのCビルダーも良いかもしれません。なにより結果に最短なものがベストです。

それでしばらく学習した後に、DirectXが良いと思われます。
C++.netはここの板的にはDirectX以外の用途には使えません（ｗ　怒られるかな＠rz

**名前は開発中のものです。** · 04/04/19 22:33

Ｃ自体が全く分からないというけどほかの言語はどうなのかな
いまだと無料でつかえる言語たくさんあるので言語自体が不慣れならそちらからはいるといい

そしてゲーム作るのにC++じゃないということはない