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

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

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

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

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

だいたいBMP作成なんて訳の分からないことをしたら、
GetGlyphOutlineで得られるα成分はどうするの？
なんちゃって玄人の>>66よ、素人にも分かるように説明してくれ。

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

なんかBMPを画像（フォーマット）としてのBMPとかと勘違いしてる？

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

>>67
お前ゲーム機用の開発した事ないだろ？

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

>>68
GetGlyphOutlineのイメージをテクスチャに転送する際に、
BMPがDIBや自分で確保したヒープであっても、
余計なものを経由して、わざわざ動作を遅くする理由は？

>>69
DirectX経由の話であって、コンシューマーの話ではないはずだが、
何を言っているのかますます意味不明。

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

>>57
作業がしやすいなら（使いたい機能を感覚的に探せる）どんなタイプでもかまわない。

最低限の改行/改ページ指定の入った文章をスクリプト書式に変換（もしくはデータ化）
でき、可能ならその逆（スクリプトからほとんど文章のみの形にする）もできるようにして欲しい。
校正しやすい形でシナリオを書きたいからね。

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

BMPを経由する理由というのがあるのなら、
その時点で私のよけいなお節介だったというだけの話なんだが。
話が別のところへ行きそうな予感。

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

いやもうウザイんで消えて。なにやるか判ってないのにアドバイスできると
思ってる池沼にはうんざり。

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

>>73
何故BMPなんて余計なものを経由するのか、明確な説明があれば即消えるけど。
なんで理由を書かずに、高圧的な書き込みだけ残していくの？
理由があればそれでよし、無駄な部分なら省けばいいだけの話題なんだが。

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

けんかやめれ

抱きしめてやるよ俺が

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

テクスチャを利用する場合は、アルファで透明色の設定が必要になるから、
例えば、
TextOut>DIB>テクスチャ
なんかの場合は、透明色をテクスチャに設定し直さなければならないので、
GetGlyphOutlineからダイレクトの方が効率がいいのでは？

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

俺も>>68とか意味がわからんので教えて欲しいな。
しかし、このスレはいろんな意味でﾏｽﾞｰだなぁ・・。
いいのかこんなんで、みたいな。

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

>>77
お前プロじゃないだろ？

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

結局なにも説明できず、煽ってごまかすことしかできないとは。
それがプロの仕事なのか？
文句があるのなら技術的に突っ込みを入れればいいだけなのに。

**親父PG** · 04/04/02 15:26

>>76
ダイレクトというのはこういう形ですよね
　　　　　　　文字データ－GetGlyphOutline
　　　　　　　　　V　　　　　
DIB（背景）＞　OR加合　＞　テクスチャ＞ポリゴン貼り付け

（DIB（背景）はなくてもOK）

○TextOutを使う場合
透明色については単にORで演算すると抜けてくれますので大丈夫です。
DIB（BMP）そこに背景の画像も同時に保持する為です。
textoutの為に（内部に）BMPが必用なので作成しております。
ループ開始前にハンドルで保持できるという、運用上のメリットもあります。

○GetGlyphOutline
ループの中で文字データ－を作成するのは、文字列が変更した時意外は極力避けるべきなので
事前に何処かに置いておく必用があります。
TextOutの時にはBMPがありましたので、そこに保持しています。
（メモリと同じ扱いですね）
同じロジック上で動くならその上に置いておけばいいや！という考えなのですけどね...
ところでこの関数は１文字ずつしか機能しないのですが、そのへんの速度って大丈夫なのでしょうか？

まとめ
当初 TextOut命令でFONTデータ－を作成する仕様だったので、当然（内部）BMPを作って
ハンドルを保持する形が生まれた。
しかしそれではアウトラインが汚いので、ユーザーが切り替えられる仕様を追加した。
既にBMP経由のロジックが出来ているので、単にGetGlyphOutlineデータ－を置いておくメモリとしてBMPを使用した。

ざっとこういう理由でBMPがこの中に残っています。
保持するBMPは１ピクセル８ビット深度フォーマットで作成。これなら両方のデータ－を収めることが可能

こんな感じかな...　俺はなにか間違えているのだろうか　orz.....

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

理由を書かないやつは>>75に抱きしめてもらえ

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

根本的なところに考え方に食い違いがあるようなんだけど、
なぜレンダリング時にハードウェア側で背景とフォントを合成しないの？
＞文字列が変更した時意外
背景と分離しておけば、背景が動的に更新される場合も、
文字列に変更がなければ、文字列用のテクスチャを書き換える必要が無い。
背景は更新されないことが前提？

**親父PG** · 04/04/02 15:58

>>71
校正の容易さについては重要な指針とさせてもらいます。

==============================================================
言語仕様のプラン
1)Cライク
if (fg[24]==25){
　PUTMES(1,1,'メッセージ出力');
}
2)単純化したもの
[24]==25,PUTMES,メッセージ出力；

3)EXCELを前提
PUTMES,'メッセージ出力'(24,=,25);

こういう形よりWEBのツリー型の掲示板のような形のほうがいいのかなぁ...
Parlで組むか！（orz ｽﾐﾏｾﾝ　ｼﾞｮｳﾀﾞﾝﾃﾞｽ

**親父PG** · 04/04/02 16:00

>>82
ごめんなさいorz
データは背景用と文字用と２つ持っています。
レンダリング直前に加算してます。

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

レンダリング直前というのが謎なんだけど、
テクスチャを使っているのなら、なぜレンダリング時に、
ハードウェア側で合成をかけずに、その前過程で合成するのかが疑問。

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

世の中にはいろんな人がいるものさ

**親父PG** · 04/04/02 16:20

>>85
ポリゴンに張り込むテクスチャ１枚目に、データ－を放り込んだらうまくいったからというのが理由です。深い意味はありませぬorz

加合用の２枚目のテクスチャをさらに別途用意して、データ－を他所からもってくるなら（他にいろんな可能性があるとはいえ）
テクスチャは１枚でいいような気もするのですが...

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

ハードウェアとソフトウェアでは合成速度に雲泥の差があるんだけど。
それにゲームの内容にもよるけど、サウンドノベルでもなければ、
普通は背景が一枚絵である場合は少ない。
複数のパーツを結合して背景やキャラクターを合成して、
一つのフレームを生成するわけなんだけど。
もしかして3Dデバイス経由でノベルのシステムを作るという話だったの？
だったらすまなかった、この話は忘れて。

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

>>88
とりあえず目標はＲＰＧらしいぞ
だからフォントなんかで速度がネックになるところはないと思われ

最適化に目がいくのはいいが、さっさとゲーム作り始める方がいいような
ネックになる場所とかもそれではじめてでてくるとかあるかもしれんし

＃そういや親父のわりに真っ昼間から時間あるんだな

77 · 04/04/02 17:01

普通D3Dなら、フォントテーブルはD3DFMT_A8で作って
マルチテクスチャブレンディングで加工・表示するもんだと思っていたが。
確かに俺は素人だが、、、まあいいけどさ。

**親父PG** · 04/04/02 17:05

>>89
今日は非番で休みです。
明日は仕事ですorz...

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

>>91
スマン

非番という言葉使っていることからタイムシフト系か
つらそうだな

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

おやっさん、頑張れ。
密かに応援しているぞ。

**親父PG** · 04/04/03 23:27

>>92 93
どうもありがとう。その言葉を励みに頑張ります。
今仕事から戻ってきました。土曜日は電車が空いてるので、ひざの上でPG組んでました（ｗ
電車には携帯電話禁止と書いてあるが、携帯パソコン禁止とは書いてないからな。

GetGlyphOutline　って結構面倒ですね。まだ動きがおかしいorz

文字列からひとつひとつコードを取り出さないといけないし、
UINTに対応して上位バイトと下位バイトを入れ替えなど...

ほんとにこんな処理をループ中にして大丈夫なのかな。
毎フレームやることじゃないな。この処理

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

ライブラリとかフレームワーク作るだけで力尽きないように
SDLとか使うのもいいのではないかと。

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

DIBについてトリビアを発見しました。

BITMAPINFOHEDERのbiHeight メンバを－にしてDIBを作成すると
左上原点のボトムダウンDIBになる。

既に概出かもしれませんが.....orz

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

それって１０年前からやってたんだが

そのまま書き出しても一部対応してないビューアとかあるけど
内部で使うだけなら問題ない

**新人PG** · 04/04/04 12:24

面白そうなので参加したいな。
当方C,C++,C#,VB,Java,Perl,ASM何でもOK。DirectX触った事なしです。
親父PG様の進行を妨げない、便利屋PGとして徹しますので。

**親父PG** · 04/04/04 13:51

>>97
1994年から？
win3.1の頃からそうだっけ？
orzｵﾚﾊ10ﾈﾝﾄﾃﾂﾓﾅｸﾑﾀﾞﾅｺﾄｦｼﾃﾀﾉｶ....

>>98
おお！参加表明有難う。
もし、やってもらえるなら、前にも書きましたが
シナリオエディタとデータ－規格の設計をお願いしたいです。
フラグ管理も「履歴」機能を追加して「過去４回きてれば」というようなものも欲しいですね。
データの規格が煮詰まれば、こちらでもツールを作ります。
ここでデータの設計を進めましょう。

現在動いている下位レイヤーでは、引数として
「対象ビューポート」、「対象オブジェクト」、「呼出タグ」などが設定できます。
※ピューポート画面分割だと思ってください。

現在、プログラム起動時にビューポート数とその大きさ、「ボタン１２８個（反応レクト領域数）」、テクスチャファイル名
が入ったファイルを読み込んで画面が変化するようにしています。
またこのプロファイルは何度でも読み直しができます。（画面デザイン切替可能）
（※以上は稼働中）

作成する（予定）の物は
昔、（今もか）ソーサリアンというゲームがありましたが、そのシステムを拡大.拡張する予定です。
（シナリオはヨコスクロールに限定しない）
あと、DirectX　SDK落としてきてサンプル覗いてみてください。
経験のある方なら動かすぐらいは簡単にできると思います。^^)|~
アイテムデータの作成は本体PGに持たずに、外部にDLLとして実装して、
他のアプリケーションからも使用可能にします。

うーむ勢いで...公言してしまった。orz　ﾀﾞｲｼﾞｮｳﾌﾞｶﾅ...

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

ソーサリアンの拡張版！？
それは楽しみ。

絵とか音楽とか必要な段階になったら、
状況が許せばお手伝いします。

**新人PG** · 04/04/04 14:53

>>親父PG
快い回答ありがとうございます。
いきなりそんな重要な部分の設計を任せてもらって感謝とｶﾞｸﾌﾞﾙが半々ぐらですｗ
勝手ながら、まとめページを作ってしまいました・・・いらなかったら消します(^^;
http://www.geocities.jp/oyajipg/index.html
うｐローダとか考えたのですが、ちょっと様子見ということで個人サイト形式です。

シナリオエディタとデータ規格ですね？
先にデータ規格の方の設計を考えておきます。でわ。

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

最初からソーサリアンみたいなの作りたいとかいっとけば
流れ分かりやすくてよかったかも
ソーサリアンシステムの概要はしっとるかな？
まぁ、今なら参考にすることはあんまり無いと思うけどね

winはwinでもNT3.1、3.5あたりのお話
win32apiは「new」とかついてたような

新人ＰＧさんのほうがシステムの設計か
なんか逆のような気がしないでもないがｗ

こういうのはシステムとプラグイン部分の分離が最重要だから
そのへんどうにでもなるようにUTF8でXMLで書き出せておけばいいようなツール類を
量産すべし・・・かな
知っている言語にjava、C#があるのでそのへんは楽っしょ

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

>>102
実はソーサリアンって知りません・・・ｗ
とりあえず、親父PGの意向のままに～と思っています。

最初同じくXMLでの規格設計を考えていたんだけど、結局はパーサ介してC++で
実装すると思うと、ちょっと躊躇してしまうんすけどね。
いや、C#やJavaでXML処理なんて全然大した事じゃないんですけど、C++だとちょっと
敷居が高いじゃないですか。データ処理をするのにパーサー理解などの学習コストが
あるんですが、そこん所どうなんでしょ？
こちらは一応、Xerces-C++使った経験多少あり。日本語処理とかって今どうなっているんだろう･･･？
ICUとか使うのかな？規格よりも実装に目が行ってしまう、典型的プログラマですなｗ

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

ソーサリアンか。懐かしいの選ぶねぇ。

**親父PG** · 04/04/04 16:27

>>101
こちらこそよろしくお願いします。　というか教わることが多いかも^^;

HP有難う立派なもの作って頂いて! 感動ですよつ∇;）
>>102
データ－をUTF8ですか...メリットとデメリットを考えていきましょう。

ツール類に関してですが、私はdelphi使おうかと思ってます。
なにかと文字操作するのは「言語的に得意」なので...
でもCビルダーもいいかもしれませんね。

ちなみに私はVC++（2002）NETとThinkPad（セレ２G）Windows2000で開発してます。
よってこのマシンで動くように作ります（W
GPUはintel82855です。この石でサポートしない機能は使わない。

自分中心でハード仕様決定です。　
ノートで動くならサポートする環境も増えると思うので

**親父PG** · 04/04/04 16:45

文字のアウトラインを取得する為のコード取得ルーチン
○文字は２バイトと１バイトコードが混じる可能性あり

UINT string_code;
char c1;
unsigned short int c2;
char Moji[48];
for ( int iC=0; iC < lstrlen(Moji);++iC ){
　c1= Moji[iC];//１バイトコード取得
　c2= ( (Moji[iC]<<8 ) + unsigned char (Moji[iC+1]) ) ;
　if ( 0<c1 && c1<128 ){//-の価をチェックルーチンに回すとランタイムエラー
　　if ( __iscsym(int(c1))!=0 ){
　　　string_code=c1;
　　}
　}else {1byteではないなら２バイトコード
　　int cc0=_ismbcl0(c2),cc1=_ismbcl1(c2),cc2=_ismbcl2(c2),cn=_ismbchira(c2),ck=_ismbckata(c2);
　　if ( (( cc0 =! 0)||( cc1 =! 0)||( cc2 =! 0)||( cn != 0)||( ck != 0)) ){
　　//２バイトコード　if ( _ismbcl0(c2)!=0 )こういう書き方できない為
　　　iC++;
　　　string_code=c2;
　　　}else{
　　　　string_code=c1;//BPt置いて監視　上から漏れてくるコードあるかな？
　　　}
　}
fsize=::GetGlyphOutline( hDC, string_code, GGO_GRAY4_BITMAP, &stGlyphmtrics, 0, NULL, &mat );
...
}//end of for
もっといい方法ありますかね? orz....ｺﾝﾅｼｮﾘﾋﾞｮｳｶﾞﾙｰﾌﾟにｲﾚﾗﾚﾙﾉｶ????

**新人PG** · 04/04/04 16:58

>>105
とりあえず、データ規格の概要の構想を提案します。
１）基本的に、データと実装部の分離は出来る限り行う。
２）スクリプトは簡易インタプリタ言語
３）実装部とスクリプトはイベントドリブンの関係

１）はゲーム進行そのものをスクリプトに持たせようってな設計構想です。
しかし、汎用的なものを考えてはいません。あくまで現ゲームに必要最小限の規格を考えています。
２）は企画者やシナリオライターにプログラムを覚えてもらうものです・・・てのは嘘で、
ツールによる作成が出来る程度の簡易インタプリタを考えています。
変数をハッシュ化させて管理する機能などで、フラグ管理などを考えています。
３）は、まだ頭の中でモワモワしています。そのうち図などで詳しく書きますｗ

データ形式ですけど、XMLでも独自形式でもいいような気がします。（ダメ？）
ここは、自分の裁量で決めかねるので親父PGさんが決めちゃってください。

ツール作りはDephiでつか・・・。
C#.NETとかだと、ツール作りに参加できそうなのですけど・・・。

**新人PG** · 04/04/04 17:21

>>106
ぜんっぜん試してないので、嘘こいているかもしれないですけど･･･。
一度、GetGlyphOutlineをコールしてバッファサイズを取得してから、実際のバッファを
いれてやれば良いような話がありました。
ttp://www.twin-tail.jp/contents/pg_tips/tips000.htm

こういうのではないでしょうか･･･？

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

1バイトでなければ2バイトってのはどうかと。

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

>>108
どもどもお気ずかいありがとう。
それはバッファサイズの話ですね。
先ほどのコードはその前の「文字コード」を切り取る部分です。
あの関数（GetGlyphOutline）は１文字ずつしか処理できませんので、

LOOP
文字列＞１文字切り取り＞バッファサイズ取得（GetGlyphOutline）＞バッファ作成＞
アウトライン取得（GetGlyphOutline）＞バッファから目標へコピー

バッファ開放
文字列ポインタインクリメント
目標のポインタを文字幅分加算
LOOPEND
このような流れになりますです。orzﾅﾝｶｸﾛｳﾉﾜﾘﾆ....

データ形式についてはもう少し、デメリットとメリットを合わせて決めましょう
でツールですが、データ－の形式さえ決まっていれば、データ－互換で各自つくればいいかなぁと。
あんまり色々ケチって悩むより、作ったほうが早いというのが持論なのでorz..ｿﾚﾃﾞｲﾀｲﾒﾆｱｯﾃﾙｹﾄﾞ

シナリオ作成については実績のある「ツクール」等を参考にしたほうがいいのかもしれませんが
実は見たこと無いので今度買ってきますかね^^;orz見てｲﾔﾆﾅﾙｶﾓｼﾚﾅｲｹﾄﾞ

私が大昔にゲームのシナリオ作成方法を聞いた時には、担当のＰＧの方は
TASM（ターボアセンブラ）のマクロで作成していました。
ライターの方は制御文を含めてシナリオを書いていたようです。

ライターにはＢＡＳＩＣ作成能力ぐらいは求めていたようです。
昨今どうなのでしょうかね？　私もこのあたりが知りたいです。

**親父PG** · 04/04/04 17:56

>>109
よく見ていただけでは解りますが、ます１バイトでチェック
次に２バイトでチェック　チェックの結果がTRUEの場合のみ実際に２バイトコードとして扱っています
(is関数）
第一水準第２水準　基本　かな　かたかなの全てチェックしておりますです。

うにこーどとマルチバイト文字はサポートしてません。
チェックを入れることは可能ですが、それは別のところで一括変換されるべきでしょう。

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

Xerces-Cでいいんじゃないの？最近のはしらんけど

本システムはＶＣでもツール類はちょこちょこつくって軽くテスト、
軽く改良って感じなので作りやすいのがいいと思うよ

そうなるとGUIが容易でとなるのでBCB、Delphi、java、c#くらいが
まず選択肢になると思う
あ、Delphiで気軽に使えるXMLパーサってあったかな

UTF8って選択はXML扱うならどの環境でも必須条件なので扱いやすい
たとえばmacユーザーにマップツール使ってもらうとか考えるとjavaも悪くない
複数の人に使ってもらうという前提が必要ならね

ソーサリアン知らないとなるとどう説明していいのやら
こんなあたりが参考になるのかな
ttp://www.ipc-tokai.or.jp/~ytanaka/pc88/sorc_pi.shtml

**新人PG** · 04/04/04 18:45

>>110
全然違う話だったのね・・・鬱だ（ry

とりあえず、規格設計だけは作っておきます。
それからXMLか独自で組むかは、決めたほうが良いかなと思いますんで。

>>112
日本語処理が多いとUTF16という選択もあるんだけど、ゲームの概要が見えてないのでダメポ。
とりあえず、今はWindowsで動くものをｗ
機会あればやってみますわ＜ソーサリアン
デモもありましたし。

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

>>112
あらためて偉大さを感じますね。紹介のＨＰをしみじみと読ませて頂きました。
メモリが足らなくなったら、メモリの内容をそのままＤＩＳＫに保存。
プログラムをスワップするとかやってましたなぁ。

>>113
全然違う話ではないのですけどね＾＾
そうそう実際にコード切り取る時どうします？
あの関数についてぐぐって見たけどコードを切り取る部分は、書いてないのが多いので....

ＸＭＬについては「ＸＭＬのフォーマットがゲームデータ－の表すのに適しているか？」
の一点で評価しましょう。
現状ではＸＭＬ形式に保存（できる）というスタンスで良いと思います。
そもそも「何をどのように保存するか？」が煮詰まらないと、決められないと思いますので。

これから夜勤です。orz

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

XMLは慣れると内部データにも使いやすいよ
domツリーそのままというよりはElementを多用するというか

MapとListを自由に組み合わせれるコレクション型と考えればいいかな

CPUが1GHz超えているのなら
メインループでDOMツリーガリガリ操作していても余裕で60fpsくらいでますぜ

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

というかXMLで表せないデータなんかあるのかねぇ。
今は猫も杓子もXML使っとけという流れだけど。

**親父PG** · 04/04/04 22:17

ゲームのデータ-について　草案を書きます。●トリガーテーブル　●シーンデーター　という２つのデータ形式から構成される
●トリガーテーブル
トリガーテーブルには（selfNO）トリガー条件とトリガー番号が固定長で収納する
編集時はエクセルでの編集を可能にする。
最終的に数値セルをバイナリに落す（要コンバーター）
NO　INT
比較先場所FG　BYTE　
比較先FGNO　INT　(直接値の場合もあり)
比較先場所FG　BYTE　
比較先FGNO　INT (直接値の場合もあり)
比較条件　BYTE == != > < >= <= !

トリガー種類FG BYTE （MOVE　FG値操作　次処理　シーン呼び出し）
トリガ用パラメーター1（処理先NO）INT
トリガ用パラメーター2（処理先NO）INT
トリガ用パラメーター3（処理先NO）INT
　リザーブ（24か32Byte境界）　

●シーンデータ-
シーンデータ-にはメッセージやウインドの処理などが書かれる。
またシーン終了時にどのトリガー条件に戻すかが書かれている。

※トリガーテーブルデータ-は、純粋に条件の表現だけに特化しゲーム特有の処理を含ませない。
シーンデータ-は実際に行いたい具体的な処理を書くようにする。
------------------------------------------------------
一定周期、ないしはアクションが会った後、トリガーテーブルを参照する。

●その他のデーター
・キャラクターデーター　本企画はキャラクターデータ-を中心に考えている（ソーサリアン的）
・アイテムデータ-　DLLで供給　・魔法？のデータ-
・プレイヤーのデータ-
TRPGのD&Dは有り余る金で城建てたり、ダンジョン掘ったり、タワー建てたり、いろいろできるんだよね。テキストレベルでいいからそういうのもエミュレーションしたいねぇ。

**親父PG** · 04/04/04 22:28

>>100
ああ　すみません読み飛ばしていましたorz

画像班もいてくれると大助かりです。宜しくお願いします

**ﾐVﾐlPG** · 04/04/04 22:36

http://www.geocities.jp/oyajipg/up/format.GIF
http://www.geocities.jp/oyajipg/up/data.xml
以上適当に雛型っぽいのを作ってみました･･･。

が･･･草案を見る限り、XMLではないのでしょうか･･･。

**新人PG** · 04/04/04 22:42

>>119
うご、文字化けてる。
一応XML互換と言う事で、>>117の草案を元に練り直します。

**親父PG** · 04/04/04 23:07

>>120
ご苦労おかけします。orz

**新人PG** · 04/04/04 23:42

>>121
ちょっとトリガーテーブルの記述が判りにくかったので解説求む。

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

>>119
プロパティ多用なんかキモイ

**新人PG** · 04/04/04 23:58

寝ます。
平日の書き込みペース＆進捗はかなり落ちますので、そこんとこよろしくお願いします。

>>123
もうちょっと踏み込んで設計していたらもっとキモイフォーマットが出来ていたかと思います。
XmlSchemeなんてこんな物では？

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

俺も>>123のいうことがわからん

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

ま、ゲームで扱うものならdtd程度でいいとは思うけどね

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

http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=9818&forum=9&13

**親父PG** · 04/04/05 03:55

>>124
●トリガーテーブル
トリガーテーブルには（selfNO）トリガー条件とトリガー番号が固定長で収納する
固定長にするメリットは内部で高速に動作させる事と、EXCELで簡単に編集できるなどを
考慮してです。

struct {
int SelfID; //シリアル番号
byte CmpSeed1;　　//int CmpTarget1が何を示すかの種類　FGテーブル　デバイス　関数戻り値　値
int CmpTarget1;　//値
byte CmpSeed2;　　//int2 CmpTarget1が何を示すかの種類　FGテーブル　デバイス　関数戻り値　値
int CmpTarget2;　//値
byte CmpOP;　//上の値の比較方法
byte CmpOP; //真/偽どちらを使うか？ (追加
short int ActCommand ; //何をするか？　MOVE　FG値操作　次処理　シーン呼び出し
int ActValue1;　//値　ActCommandによって扱いが異なる
int ActValue2;　
int ActValue3;
//リザーブ（24か32Byte境界）　
};

値を比較するときに、「何処の値」を示すのが　CmpSeed1

このように値の前に「何処の」というフラグをつけて対応します。
255種類もあれば大丈夫でしょう

何かご意見があればドシドシ募集中です。まだこれは草案なので
こんなものも追加したほうがよい！　などまだあるはずです。
トイレで考えたのを書いただけだから^^；..

こんな説明でよろしいでしょうか？orzﾜｶﾘﾆｸｸﾃｽﾏﾝ...

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

>>119
画像のほうのリンクで「モビットの広告画像」が出てきて、ツボニはまりました
>>127
興味深いお話ですね。フラグチェックループのことを考えると、XMLの生データーを
本体では直接は持たないと思います。（翻訳エンジンで先ほどの形に落とし込みます）

**親父PG** · 04/04/05 06:49

先日から行っていた文字ライブラリの速度計測
セレ2.0G　1024*768　WINDWモード　の平均fps105に置いて
高精度アウトライン文字使用　マウス座標を表示　文字数1-4　フォントサイズ40程度
において

3-4fps消費しました。少し重いねorz

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

親父PGって何歳なん？

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

1024*768のウインドウモードでその程度ならなんの問題ないと思うんだが

**親父PG** · 04/04/05 11:49

>>131
現在のＬＶではそれは使用できません。orz嘘ですｺﾞﾒﾝﾅｻｲ

取り合えず、妻子持ちという事で^^

あと２～３週間を目処にいったんあぷします。

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

親父PGたんのスペックおしえて。
身長、体重、血液型など。

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

>>130
どこが重いの？
同じ大きさのビットマップを同じ数
AlphaBlendとかTransparentBltしてみると
それに近い数値で減ると思うけど。

**新人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って聞くとデータ構造の方を思い浮かべてしまって混乱してますｗ
呼称「地形」で良いスか？ｗ　（ごめんなさい、ほんとに判らないんです）