04/04/01 04:30 CzMeYUkg
既に環境依存してますって（汗）
HG系はリコーの商用フォント。Windows標準では使用不可能
MS-Officeについてくるから勘違いされることが多いけどね
フォントを複数種類使いたいならEnumFontFamiliesEx使ってフォントを列挙し、
ユーザーに選ばせるのが一番安全
50:名前は開発中のものです。
04/04/01 19:33 ZC0PnnRp
ちょっと低レイヤー過ぎるような。
3Dっしょ？フォントとかそんなとこから作ってたら平成が終わっちゃうよ。
D3Dサーフェイスに乗せられるテキストボックスとかがいいんじゃね？
51:親父PG
04/04/01 23:04 M2APFMNg
>>49
>HG系はリコーの商用フォント。Windows標準では使用不可能
>MS-Officeについてくるから勘違いされることが多いけどね
そうでしたが....Windows2000にも入っていたので標準かと思ってましたよorzﾀﾞﾒｽｷﾞﾙ
少し改造すれば（最終的な）ユーザー選択可能にもできますので^^ そこはなんとかいたします
>>50
この部分は（表示まで含む）以前に作った事があるのですが、のべで５日ぐらいでしたので大丈夫ですorzﾀﾌﾞﾝ
それよりTextOutでビットマップに出力するとアンチシェアリングかかってないんですよね。
そのぶん速度も速いですが。
GetGlyphOutline を使うべきなのか....
URLﾘﾝｸ(www.mikenekoworks.com)
このあたりは要求仕様によって変わりそうではありますが
52:名前は開発中のものです。
04/04/01 23:34 snPiYnSW
つかフォント(´д｀)ｲﾗﾈ
ＢＭＰで用意してｹﾛ。
１２ｘ２４、１６ｘ３２の二つあれば十分でｹﾞｽ。
53:親父PG
04/04/02 01:02 5nHc263h
>>52
（理論文字数65535文字） *12*24bit*8/8 18874080byte
1ピクセル深度８bitで計算 1.8Mですな（６５５３５の部分はうそ臭い）
まぁ１Mぐらいかな。昨今の環境では無問題かもね（汗
ということはプログラム開始時に作ってしまうのがいいのかな。
全フォントピクセルBMP(横に糞長いBMP)
全フォントBMPで管理する時、面倒なのはカーニングですねぇ。どうしましょ（W
コードから半角を割り出すか（W 昔やったねコード判別で半角or全角判断
いっそカーニングデータ－にも対応して！（やばい泥沼だ
昔PC98のころはフォント用のLSIをからフォントデータ－を取得して表示してましたね。（サイズ固定）
というかテキスト専用のVRAM（空間）があって、そこに２バイト書き込めば文字が出るというレイヤー構成だった。（グラフィックVRAMは別）
グラフィックVRAMは微妙にメモリアドレス空間ズレテルシorz
DOSVで文字データ－をメモリに載せるｼｽﾃﾑを見た時！メモリ大丈夫か！と関心したものです。（当時の互換機はメモリ１６Mが標準）
僕らより先輩の時代には、[コンピューター漢字不要論]なんてのもありましたorz.......
54:親父PG
04/04/02 01:43 5nHc263h
現時点でのFONT周りの基本動作
PG開始時
テキストBMP用作成 tbitmap以外で取得したリソースは全て破棄
論理フォント作成
指定フォントでBMPにtextoutで書き込み
文字貼り付け用ポリゴン作成 ポリゴンに書き込み
初期化終了/ループ開始
文字列に変更がない場合、BMPはそのまま 変更があった場合 BMP書き換え
ポリゴンとテクスチャの貼り付け レンダリング
表示
ループエンド
追加機能 文字の後ろにはグラフィックが置ける 現在、OR加合処理
利点
（ｼｽﾃﾑにあれば）どのようなFONTにも対応できる
動的に文字列を変化できる
比較的高速
カーニングはシステム任せ
イタリック、太字なども関数へのパラメーターのみで対応できる
文字色も自由に変更できる（１文字ずつも可能）
文字データ－＞テクスチャデータ－の時にエフェクトなどが付けられる（グラデーションとか）
欠点
アンチシェアリングがかかっていない為、３Dでポリゴンが視点に対して垂直でないと文字が崩れる。（これは考慮しないと他でも当てはまる）
テキストっぽい（ｗ （テキストだけどね）
システムの環境に依存する
文字列の変化する時に、ループ内でGDI操作が発生する（BMPだけの書き換えで対応できるかな？？ 後から長い文字列がきた場合の対応...）
でかい文字はNG
列挙すると、現在の仕様での不備点は基本的に品質への問題が大きいみたいですね。なんだかテキストエディタ用のライブラリ作ってるみたいだ。
結局文字用のBMP用意から以降は、同じにできそうなので、文字用のBMP書き込みの部分を「文字の品質対する要求」パラメーターを追加して
textOutかGetGlyphOutlineで用意するか切り分けると良いかな。
あとエリア書き込みには対応しないとね（汗 文字列にCRLFがあったら書き込み位置の移動。これは大丈夫だね。
55:名前は開発中のものです。
04/04/02 05:15 nXT82zKM
プログラムは良いけど、まず企画が無いと設計できないんじゃ…
56:名前は開発中のものです。
04/04/02 05:55 XRR6zDrg
>>55
まぁいいんじゃないの。自分の得意な所から切り込んで行くのは
モチベーションを保つのに有効だと思う。
57:親父PG
04/04/02 07:24 5nHc263h
>>55
密かに「企画」はありますが、ここで公開するにはまだ未整理な部分があるので
また公開していません。現在作っているところはどのような形態のゲームでも、
取り合えずは利用する汎用部分だと思っています。
ところで、スクリプトエンジンについては、これから設計を始めるのですが、
どのようか形がやり易いのでしょうかね？
ターゲット＞ゲームの企画（シナリオ）担当（if文の意味ぐらいは知っている人）
サポート予定の機能
スクリプトで（ゲームから見た）下レイヤーに対するオブジェクト命令が可能
（このフォーマットで作成しているので実装済み
WINDOWダイアログ、ボタンサイズ、ビューポートの数とサイズなどを
予めリソースエディタで編集可能（作成済み
ボタンに割り当てるグラフィックを複数パターンの割り当てができる。
マウスMOVEでアニメーション マウスHITでアニメーション 常にアニメーション
等のボタンの実装（作成済み
マウスクリック時の反応に、INDEX番号が割り付けることができる（実装済み
○問題はシナリオライター側の表現方法の実装方法
本体とは別のエディタを用意//Delphiで作成予定
１）ポインタがないC言語のような言語を書かせるタイプ
２）プリセット式してプルダウンメニューで一行ずつ書いていくタイプ
３）シーンごとに必用なデータ－を埋めていくタイプ
どういうのがいいんだろうね？
それこそゲームの企画ありきな話かもしれませんが^^
ご意見お待ちしています。
58:名前は開発中のものです。
04/04/02 10:05 WZRWRsbY
>>57
作るゲームが決まってなきゃスクリプトエンジンなど書けません。
何か最初の方は３Ｄゲー目指してる感じだったけど、スクリプトエンジンの
内容はノベルゲームを目指してるようにも聞こえるのだが…
フォントとかってアクションゲームなら使わないし、イマイチ最終的に
何を作りたいのかが分からないのだが。
59:名前は開発中のものです。
04/04/02 10:17 17ySoK39
>>58
どんなゲームだろうとフォントを全く使わないって事はないだろう。
今までどんなゲームやってたのか知らんが、
お前さんのいうアクションゲームって
たとえばどんなのよ？
60:名前は開発中のものです。
04/04/02 10:48 d2sSL+xq
>>59
ここでは厳密なフォント周りが必要ないといってるだけでは？
たとえばＳＴＧなんかもスコアとかは表示するけどあれは
厳密なフォントのライブラリ使うようなもんじゃないだろってことかと
数字１０種と「score」と表示するビットマップでいい
そしてＲＰＧやＡＶＧのぞくとフォント周り意識するものはほとんどない
最初は遅くてもＯＳ標準の描画でなんの問題もない
やはり何作るか決まってないってのが一番の原因
61:今現在この名前は使われておりません
04/04/02 10:51 DFmUogFA
403 ：心得をよく読みましょう ：04/04/01 03:32 ID:1xz8AXwW
よろしくお願いします
【板名*】ゲ製作技術
【スレ名*】親父PGがゲームを作り始めるスレッド
【スレのURL*】ｽﾚﾘﾝｸ(gamedev板)
【名前欄】
【メール欄】sage
【本文*】↓
既に環境依存してますって（汗）
HG系はリコーの商用フォント。Windows標準では使用不可能
MS-Officeについてくるから勘違いされることが多いけどね
フォントを複数種類使いたいならEnumFontFamiliesEx使ってフォントを列挙し、
ユーザーに選ばせるのが一番安全
62:親父PG
04/04/02 11:20 5nHc263h
>>58 59 60
議論有難う。
ゲーム(種類)によって必用か不要であるかという議論は、確かにあると思います。
特に納期に追われている職業PGではなおさらでです。
その辺の議論は置いといて、「作ってしまえ！」のノリで８割型完成しましたorz
フォントの種類については、ユーザーが後からいくらでも追加できるようにして
静的配列＞STL（動的配列）に変更（フォント属性をまとめて記録）
構造体のコンペアをかけて同じフォント属性を登録しないチェック
呼出回数の記録をとって、使用頻度の低い論理フォントは破棄する。
（破棄しても次回呼出の時に、自動的に再登録される）
※ご指摘いただいた問題点がとても役に立ちました
しかし、このへんはプログラマの趣味の世界に突入していますねぇ。
ゲームによってはまったく使わないかもしれなけどorz...
実は何を作りたいというのは漠然とはあるのです。
目標の物を作成する為には、FONT周りをきちんと整理しておかねばなりません。
ちょっと過去を話すとDTPの仕事（デザイナー）も経験がありまして
文字が汚いのはいやなのですorz また趣味の世界に突入してる....
>>遅くてもＯＳ標準の描画
DirectXの描画ループでそれをやると、ちょっと問題が起こります。
いずれのゲームでも以下の処理は必要かと思われます。
テクスチャ作成＞BMP作成＞文字描画＞ポリゴン貼り
63:名前は開発中のものです。
04/04/02 11:50 koF3jQIY
内に秘めたり、趣味に走るのは全然問題無いのですが、
目的が分からないとアドバイスしようがないよ、という話だと思います。
64:親父PG
04/04/02 12:08 5nHc263h
>>63
なるほど、では今、思案中で是非アドバイスして欲しいことがあります
>>57
にも書きましたが、ゲーム用のスクリプトの仕様決定の為の指針についてです。
ゲームは取り合えずRPG用と仮定してください。（カードゲームや其の他にも応用化）
画面形態はドラクエと仮定します。（画面形態は固定しない仕様を考えています）
この場合、シナリオを作成する側はどのような機能が欲しいか？
どのようなレベルまでPG的な事を理解できるか？ ということです。
フラグ管理機能なども必要でしょうし；
文字列を解析してデータ－を作成するというのは、自作でコンパイラを作るようなものですねぇ。
数値計算とかポーランド記法。。。
いろいろ待っていそうですね(汗 そういえば昔、電卓作ったなｗ
それとも今ではフリーのMASMのマクロで組むかな....
65:名前は開発中のものです。
04/04/02 12:12 hbuLfTYl
テキスト出力なら、
フォントサイズを計算 -> テクスチャの生成 -> GetGlyphOutlineのイメージをテクスチャ -> レンダリング
出力先の大きさを固定するのならサイズの計算はいらないけど。
BMP作成というのが意味不明。
66:名前は開発中のものです。
04/04/02 12:27 2mBUdLBh
>>65
素人は引っ込んでろよ。
>>64
文字主体のゲームだとしても漢字全部を入れる必要はないかと。
使用している文字吐き出して必要な分だけ抽出する仕組みを用意すれば効率いいよ。
67:名前は開発中のものです。
04/04/02 12:48 hbuLfTYl
だいたいBMP作成なんて訳の分からないことをしたら、
GetGlyphOutlineで得られるα成分はどうするの？
なんちゃって玄人の>>66よ、素人にも分かるように説明してくれ。
68:名前は開発中のものです。
04/04/02 12:55 CnIYY+bY
なんかBMPを画像（フォーマット）としてのBMPとかと勘違いしてる？
69:名前は開発中のものです。
04/04/02 12:58 WZRWRsbY
>>67
お前ゲーム機用の開発した事ないだろ？
70:名前は開発中のものです。
04/04/02 13:03 hbuLfTYl
>>68
GetGlyphOutlineのイメージをテクスチャ に転送する際に、
BMPがDIBや自分で確保したヒープであっても、
余計なものを経由して、わざわざ動作を遅くする理由は？
>>69
DirectX経由の話であって、コンシューマーの話ではないはずだが、
何を言っているのかますます意味不明。
71:名前は開発中のものです。
04/04/02 13:05 sbRQNnGs
>>57
作業がしやすいなら（使いたい機能を感覚的に探せる）どんなタイプでもかまわない。
最低限の改行/改ページ指定の入った文章をスクリプト書式に変換（もしくはデータ化）
でき、可能ならその逆（スクリプトからほとんど文章のみの形にする）もできるようにして欲しい。
校正しやすい形でシナリオを書きたいからね。
72:名前は開発中のものです。
04/04/02 13:08 hbuLfTYl
BMPを経由する理由というのがあるのなら、
その時点で私のよけいなお節介だったというだけの話なんだが。
話が別のところへ行きそうな予感。
73:名前は開発中のものです。
04/04/02 13:53 2mBUdLBh
いやもうウザイんで消えて。なにやるか判ってないのにアドバイスできると
思ってる池沼にはうんざり。
74:名前は開発中のものです。
04/04/02 14:09 2oL9ZmmW
>>73
何故BMPなんて余計なものを経由するのか、明確な説明があれば即消えるけど。
なんで理由を書かずに、高圧的な書き込みだけ残していくの？
理由があればそれでよし、無駄な部分なら省けばいいだけの話題なんだが。
75:名前は開発中のものです。
04/04/02 14:12 MlWn9c9H
けんかやめれ
抱きしめてやるよ俺が
76:名前は開発中のものです。
04/04/02 14:20 J12mvrUf
テクスチャを利用する場合は、アルファで透明色の設定が必要になるから、
例えば、
TextOut>DIB>テクスチャ
なんかの場合は、透明色をテクスチャに設定し直さなければならないので、
GetGlyphOutlineからダイレクトの方が効率がいいのでは？
77:名前は開発中のものです。
04/04/02 15:04 UR9wlBoP
俺も>>68とか意味がわからんので教えて欲しいな。
しかし、このスレはいろんな意味でﾏｽﾞｰだなぁ・・。
いいのかこんなんで、みたいな。
78:名前は開発中のものです。
04/04/02 15:16 WZRWRsbY
>>77
お前プロじゃないだろ？
79:名前は開発中のものです。
04/04/02 15:24 2oL9ZmmW
結局なにも説明できず、煽ってごまかすことしかできないとは。
それがプロの仕事なのか？
文句があるのなら技術的に突っ込みを入れればいいだけなのに。
80:親父PG
04/04/02 15:26 5nHc263h
>>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.....
81:名前は開発中のものです。
04/04/02 15:28 koF3jQIY
理由を書かないやつは>>75に抱きしめてもらえ
82:名前は開発中のものです。
04/04/02 15:40 2oL9ZmmW
根本的なところに考え方に食い違いがあるようなんだけど、
なぜレンダリング時にハードウェア側で背景とフォントを合成しないの？
＞文字列が変更した時意外
背景と分離しておけば、背景が動的に更新される場合も、
文字列に変更がなければ、文字列用のテクスチャを書き換える必要が無い。
背景は更新されないことが前提？
83:親父PG
04/04/02 15:58 5nHc263h
>>71
校正の容易さについては重要な指針とさせてもらいます。
==============================================================
言語仕様のプラン
1)Cライク
if (fg[24]==25){
PUTMES(1,1,'メッセージ出力');
}
2)単純化したもの
[24]==25,PUTMES,メッセージ出力；
3)EXCELを前提
PUTMES,'メッセージ出力'(24,=,25);
こういう形よりWEBのツリー型の掲示板のような形のほうがいいのかなぁ...
Parlで組むか！（orz ｽﾐﾏｾﾝ ｼﾞｮｳﾀﾞﾝﾃﾞｽ
84:親父PG
04/04/02 16:00 5nHc263h
>>82
ごめんなさいorz
データは背景用と文字用と２つ持っています。
レンダリング直前に加算してます。
85:名前は開発中のものです。
04/04/02 16:05 2oL9ZmmW
レンダリング直前というのが謎なんだけど、
テクスチャを使っているのなら、なぜレンダリング時に、
ハードウェア側で合成をかけずに、その前過程で合成するのかが疑問。
86:名前は開発中のものです。
04/04/02 16:18 MlWn9c9H
世の中にはいろんな人がいるものさ
87:親父PG
04/04/02 16:20 5nHc263h
>>85
ポリゴンに張り込むテクスチャ１枚目に、データ－を放り込んだらうまくいったからというのが理由です。深い意味はありませぬorz
加合用の２枚目のテクスチャをさらに別途用意して、データ－を他所からもってくるなら（他にいろんな可能性があるとはいえ）
テクスチャは１枚でいいような気もするのですが...
88:名前は開発中のものです。
04/04/02 16:34 2oL9ZmmW
ハードウェアとソフトウェアでは合成速度に雲泥の差があるんだけど。
それにゲームの内容にもよるけど、サウンドノベルでもなければ、
普通は背景が一枚絵である場合は少ない。
複数のパーツを結合して背景やキャラクターを合成して、
一つのフレームを生成するわけなんだけど。
もしかして3Dデバイス経由でノベルのシステムを作るという話だったの？
だったらすまなかった、この話は忘れて。
89:名前は開発中のものです。
04/04/02 16:55 d2sSL+xq
>>88
とりあえず目標はＲＰＧらしいぞ
だからフォントなんかで速度がネックになるところはないと思われ
最適化に目がいくのはいいが、さっさとゲーム作り始める方がいいような
ネックになる場所とかもそれではじめてでてくるとかあるかもしれんし
＃そういや親父のわりに真っ昼間から時間あるんだな
90:77
04/04/02 17:01 UR9wlBoP
普通D3Dなら、フォントテーブルはD3DFMT_A8で作って
マルチテクスチャブレンディングで加工・表示するもんだと思っていたが。
確かに俺は素人だが、、、まあいいけどさ。
91:親父PG
04/04/02 17:05 5nHc263h
>>89
今日は非番で休みです。
明日は仕事ですorz...
92:名前は開発中のものです。
04/04/02 17:34 d2sSL+xq
>>91
スマン
非番という言葉使っていることからタイムシフト系か
つらそうだな
93:名前は開発中のものです。
04/04/03 22:06 od+9QL8M
おやっさん、頑張れ。
密かに応援しているぞ。
94:親父PG
04/04/03 23:27 0WOw9AyH
>>92 93
どうもありがとう。その言葉を励みに頑張ります。
今仕事から戻ってきました。土曜日は電車が空いてるので、ひざの上でPG組んでました（ｗ
電車には携帯電話禁止と書いてあるが、携帯パソコン禁止とは書いてないからな。
GetGlyphOutline って結構面倒ですね。まだ動きがおかしいorz
文字列からひとつひとつコードを取り出さないといけないし、
UINTに対応して上位バイトと下位バイトを入れ替えなど...
ほんとにこんな処理をループ中にして大丈夫なのかな。
毎フレームやることじゃないな。この処理
95:名前は開発中のものです。
04/04/04 01:15 jA6y2hbu
ライブラリとかフレームワーク作るだけで力尽きないように
SDLとか使うのもいいのではないかと。
96:親父PG
04/04/04 09:51 6UsE36R6
DIBについてトリビアを発見しました。
BITMAPINFOHEDERのbiHeight メンバを－にしてDIBを作成すると
左上原点のボトムダウンDIBになる。
既に概出かもしれませんが.....orz
97:名前は開発中のものです。
04/04/04 11:59 KpeQdK+f
それって１０年前からやってたんだが
そのまま書き出しても一部対応してないビューアとかあるけど
内部で使うだけなら問題ない
98:新人PG
04/04/04 12:24 yroz7+Kx
面白そうなので参加したいな。
当方C,C++,C#,VB,Java,Perl,ASM何でもOK。DirectX触った事なしです。
親父PG様の進行を妨げない、便利屋PGとして徹しますので。
99:親父PG
04/04/04 13:51 6UsE36R6
>>97
1994年から？
win3.1の頃からそうだっけ？
orzｵﾚﾊ10ﾈﾝﾄﾃﾂﾓﾅｸﾑﾀﾞﾅｺﾄｦｼﾃﾀﾉｶ....
>>98
おお！参加表明有難う。
もし、やってもらえるなら、前にも書きましたが
シナリオエディタとデータ－規格の設計をお願いしたいです。
フラグ管理も「履歴」機能を追加して「過去４回きてれば」というようなものも欲しいですね。
データの規格が煮詰まれば、こちらでもツールを作ります。
ここでデータの設計を進めましょう。
現在動いている下位レイヤーでは、引数として
「対象ビューポート」、「対象オブジェクト」、「呼出タグ」などが設定できます。
※ピューポート画面分割だと思ってください。
現在、プログラム起動時にビューポート数とその大きさ、「ボタン１２８個（反応レクト領域数）」、テクスチャファイル名
が入ったファイルを読み込んで画面が変化するようにしています。
またこのプロファイルは何度でも読み直しができます。（画面デザイン切替可能）
（※以上は稼働中）
作成する（予定）の物は
昔、（今もか）ソーサリアンというゲームがありましたが、そのシステムを拡大.拡張する予定です。
（シナリオはヨコスクロールに限定しない）
あと、DirectX SDK落としてきてサンプル覗いてみてください。
経験のある方なら動かすぐらいは簡単にできると思います。^^)|~
アイテムデータの作成は本体PGに持たずに、外部にDLLとして実装して、
他のアプリケーションからも使用可能にします。
うーむ勢いで...公言してしまった。orz ﾀﾞｲｼﾞｮｳﾌﾞｶﾅ...
100:名前は開発中のものです。
04/04/04 14:08 ppxkrtRX
ソーサリアンの拡張版！？
それは楽しみ。
絵とか音楽とか必要な段階になったら、
状況が許せばお手伝いします。
101:新人PG
04/04/04 14:53 yroz7+Kx
>>親父PG
快い回答ありがとうございます。
いきなりそんな重要な部分の設計を任せてもらって感謝とｶﾞｸﾌﾞﾙが半々ぐらですｗ
勝手ながら、まとめページを作ってしまいました・・・いらなかったら消します(^^;
URLﾘﾝｸ(www.geocities.jp)
うｐローダとか考えたのですが、ちょっと様子見ということで個人サイト形式です。
シナリオエディタとデータ規格ですね？
先にデータ規格の方の設計を考えておきます。でわ。
102:名前は開発中のものです。
04/04/04 15:15 KpeQdK+f
最初からソーサリアンみたいなの作りたいとかいっとけば
流れ分かりやすくてよかったかも
ソーサリアンシステムの概要はしっとるかな？
まぁ、今なら参考にすることはあんまり無いと思うけどね
winはwinでもNT3.1、3.5あたりのお話
win32apiは「new」とかついてたような
新人ＰＧさんのほうがシステムの設計か
なんか逆のような気がしないでもないがｗ
こういうのはシステムとプラグイン部分の分離が最重要だから
そのへんどうにでもなるようにUTF8でXMLで書き出せておけばいいようなツール類を
量産すべし・・・かな
知っている言語にjava、C#があるのでそのへんは楽っしょ
103:新人PG
04/04/04 15:32 yroz7+Kx
>>102
実はソーサリアンって知りません・・・ｗ
とりあえず、親父PGの意向のままに～と思っています。
最初同じくXMLでの規格設計を考えていたんだけど、結局はパーサ介してC++で
実装すると思うと、ちょっと躊躇してしまうんすけどね。
いや、C#やJavaでXML処理なんて全然大した事じゃないんですけど、C++だとちょっと
敷居が高いじゃないですか。データ処理をするのにパーサー理解などの学習コストが
あるんですが、そこん所どうなんでしょ？
こちらは一応、Xerces-C++使った経験多少あり。日本語処理とかって今どうなっているんだろう･･･？
ICUとか使うのかな？規格よりも実装に目が行ってしまう、典型的プログラマですなｗ
104:名前は開発中のものです。
04/04/04 15:41 PaXg2AQi
ソーサリアンか。懐かしいの選ぶねぇ。
105:親父PG
04/04/04 16:27 6UsE36R6
>>101
こちらこそよろしくお願いします。 というか教わることが多いかも^^;
HP有難う立派なもの作って頂いて! 感動ですよつ∇;）
>>102
データ－をUTF8ですか...メリットとデメリットを考えていきましょう。
ツール類に関してですが、私はdelphi使おうかと思ってます。
なにかと文字操作するのは「言語的に得意」なので...
でもCビルダーもいいかもしれませんね。
ちなみに私はVC++（2002）NETとThinkPad（セレ２G）Windows2000で開発してます。
よってこのマシンで動くように作ります（W
GPUはintel82855です。この石でサポートしない機能は使わない。
自分中心でハード仕様決定です。
ノートで動くならサポートする環境も増えると思うので
106:親父PG
04/04/04 16:45 6UsE36R6
文字のアウトラインを取得する為のコード取得ルーチン
○文字は２バイトと１バイトコードが混じる可能性あり
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....ｺﾝﾅｼｮﾘ ﾋﾞｮｳｶﾞﾙｰﾌﾟにｲﾚﾗﾚﾙﾉｶ????
107:新人PG
04/04/04 16:58 yroz7+Kx
>>105
とりあえず、データ規格の概要の構想を提案します。
１）基本的に、データと実装部の分離は出来る限り行う。
２）スクリプトは簡易インタプリタ言語
３）実装部とスクリプトはイベントドリブンの関係
１）はゲーム進行そのものをスクリプトに持たせようってな設計構想です。
しかし、汎用的なものを考えてはいません。あくまで現ゲームに必要最小限の規格を考えています。
２）は企画者やシナリオライターにプログラムを覚えてもらうものです・・・てのは嘘で、
ツールによる作成が出来る程度の簡易インタプリタを考えています。
変数をハッシュ化させて管理する機能などで、フラグ管理などを考えています。
３）は、まだ頭の中でモワモワしています。そのうち図などで詳しく書きますｗ
データ形式ですけど、XMLでも独自形式でもいいような気がします。（ダメ？）
ここは、自分の裁量で決めかねるので親父PGさんが決めちゃってください。
ツール作りはDephiでつか・・・。
C#.NETとかだと、ツール作りに参加できそうなのですけど・・・。
108:新人PG
04/04/04 17:21 yroz7+Kx
>>106
ぜんっぜん試してないので、嘘こいているかもしれないですけど･･･。
一度、GetGlyphOutlineをコールしてバッファサイズを取得してから、実際のバッファを
いれてやれば良いような話がありました。
URLﾘﾝｸ(www.twin-tail.jp)
こういうのではないでしょうか･･･？
109:名前は開発中のものです。
04/04/04 17:34 D8QJdaIr
1バイトでなければ2バイトってのはどうかと。
110:親父PG
04/04/04 17:50 6UsE36R6
>>108
どもどもお気ずかいありがとう。
それはバッファサイズの話ですね。
先ほどのコードはその前の「文字コード」を切り取る部分です。
あの関数（GetGlyphOutline）は１文字ずつしか処理できませんので、
LOOP
文字列＞１文字切り取り＞バッファサイズ取得（GetGlyphOutline）＞バッファ作成＞
アウトライン取得（GetGlyphOutline）＞バッファから目標へコピー
バッファ開放
文字列ポインタインクリメント
目標のポインタを文字幅分加算
LOOPEND
このような流れになりますです。orzﾅﾝｶｸﾛｳﾉﾜﾘﾆ....
データ形式についてはもう少し、デメリットとメリットを合わせて決めましょう
でツールですが、データ－の形式さえ決まっていれば、データ－互換で各自つくればいいかなぁと。
あんまり色々ケチって悩むより、作ったほうが早いというのが持論なのでorz..ｿﾚﾃﾞｲﾀｲﾒﾆｱｯﾃﾙｹﾄﾞ
シナリオ作成については実績のある「ツクール」等を参考にしたほうがいいのかもしれませんが
実は見たこと無いので今度買ってきますかね^^;orz見てｲﾔﾆﾅﾙｶﾓｼﾚﾅｲｹﾄﾞ
私が大昔にゲームのシナリオ作成方法を聞いた時には、担当のＰＧの方は
TASM（ターボアセンブラ）のマクロで作成していました。
ライターの方は制御文を含めてシナリオを書いていたようです。
ライターにはＢＡＳＩＣ作成能力ぐらいは求めていたようです。
昨今どうなのでしょうかね？ 私もこのあたりが知りたいです。
111:親父PG
04/04/04 17:56 6UsE36R6
>>109
よく見ていただけでは解りますが、ます１バイトでチェック
次に２バイトでチェック チェックの結果がTRUEの場合のみ実際に２バイトコードとして扱っています
(is関数）
第一水準第２水準 基本 かな かたかなの全てチェックしておりますです。
うにこーどとマルチバイト文字はサポートしてません。
チェックを入れることは可能ですが、それは別のところで一括変換されるべきでしょう。
112:名前は開発中のものです。
04/04/04 18:17 KpeQdK+f
Xerces-Cでいいんじゃないの？最近のはしらんけど
本システムはＶＣでもツール類はちょこちょこつくって軽くテスト、
軽く改良って感じなので作りやすいのがいいと思うよ
そうなるとGUIが容易でとなるのでBCB、Delphi、java、c#くらいが
まず選択肢になると思う
あ、Delphiで気軽に使えるXMLパーサってあったかな
UTF8って選択はXML扱うならどの環境でも必須条件なので扱いやすい
たとえばmacユーザーにマップツール使ってもらうとか考えるとjavaも悪くない
複数の人に使ってもらうという前提が必要ならね
ソーサリアン知らないとなるとどう説明していいのやら
こんなあたりが参考になるのかな
URLﾘﾝｸ(www.ipc-tokai.or.jp)
113:新人PG
04/04/04 18:45 yroz7+Kx
>>110
全然違う話だったのね・・・鬱だ（ry
とりあえず、規格設計だけは作っておきます。
それからXMLか独自で組むかは、決めたほうが良いかなと思いますんで。
>>112
日本語処理が多いとUTF16という選択もあるんだけど、ゲームの概要が見えてないのでダメポ。
とりあえず、今はWindowsで動くものをｗ
機会あればやってみますわ＜ソーサリアン
デモもありましたし。
114:親父PG
04/04/04 19:14 6UsE36R6
>>112
あらためて偉大さを感じますね。紹介のＨＰをしみじみと読ませて頂きました。
メモリが足らなくなったら、メモリの内容をそのままＤＩＳＫに保存。
プログラムをスワップするとかやってましたなぁ。
>>113
全然違う話ではないのですけどね＾＾
そうそう実際にコード切り取る時どうします？
あの関数についてぐぐって見たけどコードを切り取る部分は、書いてないのが多いので....
ＸＭＬについては「ＸＭＬのフォーマットがゲームデータ－の表すのに適しているか？」
の一点で評価しましょう。
現状ではＸＭＬ形式に保存（できる）というスタンスで良いと思います。
そもそも「何をどのように保存するか？」が煮詰まらないと、決められないと思いますので。
これから夜勤です。orz
115:名前は開発中のものです。
04/04/04 19:24 KpeQdK+f
XMLは慣れると内部データにも使いやすいよ
domツリーそのままというよりはElementを多用するというか
MapとListを自由に組み合わせれるコレクション型と考えればいいかな
CPUが1GHz超えているのなら
メインループでDOMツリーガリガリ操作していても余裕で60fpsくらいでますぜ
116:名前は開発中のものです。
04/04/04 22:15 PaXg2AQi
というかXMLで表せないデータなんかあるのかねぇ。
今は猫も杓子もXML使っとけという流れだけど。
117:親父PG
04/04/04 22:17 3txQVYNu
ゲームのデータ-について 草案を書きます。●トリガーテーブル ●シーンデーター という２つのデータ形式から構成される
●トリガーテーブル
トリガーテーブルには（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は有り余る金で城建てたり、ダンジョン掘ったり、タワー建てたり、いろいろできるんだよね。テキストレベルでいいからそういうのもエミュレーションしたいねぇ。
118:親父PG
04/04/04 22:28 3txQVYNu
>>100
ああ すみません読み飛ばしていましたorz
画像班もいてくれると大助かりです。宜しくお願いします
119:ﾐVﾐlPG
04/04/04 22:36 yroz7+Kx
URLﾘﾝｸ(www.geocities.jp)
URLﾘﾝｸ(www.geocities.jp)
以上適当に雛型っぽいのを作ってみました･･･。
が･･･草案を見る限り、XMLではないのでしょうか･･･。
120:新人PG
04/04/04 22:42 yroz7+Kx
>>119
うご、文字化けてる。
一応XML互換と言う事で、>>117の草案を元に練り直します。
121:親父PG
04/04/04 23:07 3txQVYNu
>>120
ご苦労おかけします。orz
122:新人PG
04/04/04 23:42 yroz7+Kx
>>121
ちょっとトリガーテーブルの記述が判りにくかったので解説求む。
123:名前は開発中のものです。
04/04/04 23:48 D8QJdaIr
>>119
プロパティ多用なんかキモイ
124:新人PG
04/04/04 23:58 yroz7+Kx
寝ます。
平日の書き込みペース＆進捗はかなり落ちますので、そこんとこよろしくお願いします。
>>123
もうちょっと踏み込んで設計していたらもっとキモイフォーマットが出来ていたかと思います。
XmlSchemeなんてこんな物では？
125:名前は開発中のものです。
04/04/05 00:15 C13/cZA5
俺も>>123のいうことがわからん
126:名前は開発中のものです。
04/04/05 00:16 C13/cZA5
ま、ゲームで扱うものならdtd程度でいいとは思うけどね
127:名前は開発中のものです。
04/04/05 02:34 aEWGS1EG
URLﾘﾝｸ(www.atmarkit.co.jp)
128:親父PG
04/04/05 03:55 OF5lxvl4
>>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ﾜｶﾘﾆｸｸﾃｽﾏﾝ...
129:親父PG
04/04/05 04:03 OF5lxvl4
>>119
画像のほうのリンクで「モビットの広告画像」が出てきて、ツボニはまりました
>>127
興味深いお話ですね。フラグチェックループのことを考えると、XMLの生データーを
本体では直接は持たないと思います。（翻訳エンジンで先ほどの形に落とし込みます）
130:親父PG
04/04/05 06:49 OF5lxvl4
先日から行っていた文字ライブラリの速度計測
セレ2.0G 1024*768 WINDWモード の平均fps105に置いて
高精度アウトライン文字使用 マウス座標を表示 文字数1-4 フォントサイズ40程度
において
3-4fps消費しました。 少し重いねorz
131:名前は開発中のものです。
04/04/05 10:35 tRuvkc6W
親父PGって何歳なん？
132:名前は開発中のものです。
04/04/05 11:46 C13/cZA5
1024*768のウインドウモードでその程度ならなんの問題ないと思うんだが
133:親父PG
04/04/05 11:49 6z0RwfU5
>>131
現在のＬＶではそれは使用できません。orz嘘ですｺﾞﾒﾝﾅｻｲ
取り合えず、妻子持ちという事で^^
あと２～３週間を目処にいったんあぷします。
134:名前は開発中のものです。
04/04/05 12:26 tRuvkc6W
親父PGたんのスペックおしえて。
身長、体重、血液型など。
135:名前は開発中のものです。
04/04/05 14:01 405E+F+V
>>130
どこが重いの？
同じ大きさのビットマップを同じ数
AlphaBlendとかTransparentBltしてみると
それに近い数値で減ると思うけど。
136:新人PG
04/04/05 21:20 1nSnHjPt
ただいま帰りました。
>>126
勉強も兼ねてXmlSchemeで･･･(^^;
>>128
Excel編集可能な規格はちょっと考えつかないっす。
CSV形式(独自フォーマット)でよければ作れますが･･･。
(XMLデータ)⇔ツール編集 → コンバータ → バイナリ
上記みたいな構成でいいのでしょうか？
バイナリを直接Excelで編集する事を考えています？
#DirectXの本を買っちゃいました。(DirectX9実践プログラム 工学社)
#あんまりMSのサンプルやリファレンスと変わらないのでちょっと損した感じ･･･。
137:親父PG
04/04/06 01:40 40Qsawby
>>134
むむ、個人スペックですかい。
身長178.8 体重85ぐらい 血はAです。肝機能障害ありですorz....
>>135
表示している内容に対して重いと思います。orz...
>>136
お疲れさま。資料本買ったのですね^^; 有難う。
データ-の形式については、作り込んで貰う前にいろいろと検討しましょう。
そうでないと作ってもらってから仕様変更になりかねません。orzｼﾉﾋﾞﾅｲ...
これは私の考えなのですが、ひとつ議題のたたき台につかってください。
●シナリオデータ-は本体のプログラムが読み込む前に、一旦最適化されたバイナリ形式に落とし込む。
（本体にXML関連のLIBは持たない）
●各ツールの互換性はこのバイナリデータ-互換でおこなう
EXCELでの編集は一旦バイナリ＜＞CSVツールを作ってトリガーテーブル部分のみを編集できる。というスタイルになります
●必要なデータ-群
トリガーテーブル （トリガーが書かれている 固定長）
シーンデータ- （処理が書かれている 可変長）
ストリングテーブル （名前などストリング系のテーブル）
ファイルネームテーブル （ファイルネームを収めます）
マップデータ- （地形を表すデータ-）
アイテムデータ- （魔法とかキャラデータ-など....）
ゲーム管理用データ-（画面分割数 ボタン大きさや処理等）＜こちらで作りました
ざっとこんな感じです。まとめたほうが良いデータ-もありますね
また単独であったほうが良いファイルもあります。
コレ全部の仕様決めるのは大変ですが、一つ一つ詰めていきましょう。
138:名前は開発中のものです。
04/04/06 11:23 7yXcmumh
作る課程を楽しむのならいいけど
ゲームを完成させるのが最終目的ならば富豪的プログラミングでいいとおもうけどなぁ
空中分解するスレ何度も見てきているので完成後の最適化とかバランス調整とか
そっちに時間かけて欲しいと思ったり
139:親父PG
04/04/06 14:03 QeLHJL6C
>>138
お気つかい有難う。
過程を楽しんでいるのはもちろんですが。
今はゲームを作る為の環境を整えているところです。
まったくの０からなので、時間はかかってしまいますが^^;
文字周りが一息ついたところで、WINDOWSシステムを作ります。
リソースデータ（構築データ－）より作成されるシステムとなり
データ－＞翻訳＞内部ルーチン呼出 という流れを
本格的にサポートする為の、雛型になると考えています。
140:名前は開発中のものです。
04/04/06 14:57 ZvDa+4W9
親父PGたん、むちむち体型なの？
背は高いね。きっとダンディーなんだろうな。
ｵﾔｼﾞPGﾀﾝ（´Д｀）ﾊｧﾊｧﾊｧ
141:名前は開発中のものです。
04/04/06 18:32 LJa+6Bu1
もしフリーソフトの
RPGツクール出来たら
凄い需要があると思う
この板の神になるかも
142:名前は開発中のものです。
04/04/06 19:36 oZfK2l07
いきなりコードを書き始めるプロジェクトの顛末。
まあ期待しないでROMってるよ。がんばってね。
143:新人PG
04/04/06 21:52 4g++6UBP
ただいま帰りました･･･。てか、親父PGﾀﾝ書き込み夜遅すぎ。一日ループしてしまいますね。
ちょっとまとめです。
１）トリガーデータ（フラグ管理やシーン遷移を定義）
２）シーンデータ（シーン管理。シナリオ、トリガーデータや画面管理用データと関連する？）
３）シナリオデータ（シーンデータと同義？）
４）ストリングテーブル（プレイヤーに表示するシステムメッセージ等？）
５）ファイルネームテーブル（ファイルを管理）
６）マップデータ（マップフィールド定義）
７）アイテムデータ（魔法やら道具やら敵やら・・・？）
８）画面管理用データ（システムデータ）
・・・等の定義ファイルがあるって事ですね。
僕からは１，２，３の草案より規格案を出していきます。(ひょっとしてもう頭の中では纏ってます？)
しかし、このファイルの感じですとシーンデータの負荷は大きいですね。
もうちょっとヒントをお願いします･･･ｗ
他４，５は最初はMAP形式のファイルで良いような気がします。
６はどうするんでしょう。俯瞰型かフロントビューの視点のRPGを想像していたのですが親父PG様はどう考えられてます？
７はまだまだ判りませんね･･･ｗヒントお願いします。
８は完成されていると言う事なので期待プラス参考させていただきマス。（８に１，２，３のデータとの絡みは無いですか？）
144:名前は開発中のものです。
04/04/07 03:22 BZdMbvQi
マップデータとトリガデータ分離するの？
編集はエディタのみで、単にファイルが分離しているだけならいいけど。
データ間の依存関係は、データ修正の手間が軽いかどうかを重視するのが
よいと思うがどうか。
３Ｄなら特定のオブジェクトをトリガとして扱う（ダミーノードやボーンがあるモデラなら
それを使う）
２Ｄなら、どーせマップエディタ作るんだから、編集はエディタのみの１箇所なので
無問題
って感じ？
あと、>>128
> 255種類もあれば大丈夫でしょう
ケチらなくてもｗ
こんな構造体作るよりは、スクリプトをキックしてスクリプトにフラグ判断させて、
スクリプトからイベント（ここではただの会話もイベントとしよう）をキックさせた方が、
作成も変更も管理もらくだと思うけど。
145:親父PG
04/04/07 05:27 4mfJMcZS
>>140 ﾊｧﾊｧキター（W
>>141 ツクールとは視点が違うのですが、データ－互換ゲーム環境を考えています。
その上でデータフォーマットを公開しますので、いろんなシナリオやサブセットプラグイン等を
募集いたしますorz ｱｲﾃﾆｻﾚﾅｲｶﾓ....
>>142 半年前からコツコツやってました。これからも生暖かく見守ってお守りくださいまし...
>>143
どうもお疲れ様
＞てか、親父PGﾀﾝ書き込み夜遅すぎ。一日ループしてしまいますね
それは夜勤の時、コッソリ（Ry まぁまったりいきましょう。１日考えるぐらいがちょうどいいやも
草案で出した案は最終的なバイナリのイメージです。トリガテーブルはそれれ自体が
フラグを拡張したものだと考えることができます。
１４４氏の発言＞スクリプトをキックしてスクリプトにフラグ判断
トリガーテーブル自体が他のトリガーやシーンを呼び出して、その結果を判断できます。
おっしゃることは実現可能かと思います。
シーンデータ－には、５W１H（のようなもの）が定義されます
ビューポート１番に定義されたウィンドをこの場所に開き、メッセージを表示しろ
以下「メッセージデータ」：戻り値
このようなデータになると思われます。
本体側インターフェースを提示しないと作りにくいとは思いますが、暫定で進めてください
ある程度はこちらも合わせます。
※私の申してる話は、データ－の最終形態なので、実際のツール類はそれぞれ最適化されたデータ－で
ソースを持つのがよろしいかと。しかし、最後はコンパイルされて、一定のバイナリに落とし込みます。
146:親父PG
04/04/07 05:29 4mfJMcZS
４ ストリングテーブルには「固有名詞」や「ユーザー定義」の文字を収納します
st1 "ぴたごらすいっち"と定義
メッセージデータ #1はNHKのTV番組 ＞ぴたごらすいっちはNHKのTV番組
６ struct MAPBASE{byte Maptype,MoveCost,ToDo,Maptype2}:
こんなのを配列で持つのはどうですか？
７ この部分はを考えるのは一番楽しい部分かなぁ（ｗ
属性追加タイプを考えています。熱く寒く丈夫で黒光りする腐った剣 とかorz結局ﾂｶｴﾙﾉｶ?ｺﾉｹﾝ...
８ バイナリデータ－で固定長データ－です。
それとは別にテクスチャテーブルもあり、セットで運用しています。
ちょっとずつ変わっていますが、この後出しますね。
147:親父PG
04/04/07 06:09 4mfJMcZS
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;/ ここで呼び出す関数番号を指定する
略
※シナリオからみるべきはボタンの処理番号になるのかな？
場面切替の場合はビューポート周りも見る必要があるかもね
148:親父PG
04/04/07 06:10 4mfJMcZS
閑話休題
戦闘システムですが、場にキャラクタが使うアイテム（魔法エッセンス）を宣言（スロット配置）して
その置かれたアイテムによって、使用できるコマンドが追加されていくというものを考えています。
またアイテムには持続ターンの設定がされていて、持続ターンを消化するとスロットから除外されます。
剣を主に使う場合（サンプル
剣を使用宣言＞「切りかかる」が使用可能
盾を宣言＞防御力UP 「受ける」が使用可能
魔法の場合
マナと秘薬宣言＞魔法○○使用可能
剣を中心とするユーザー
利点・持続ターンが長い
欠点・単体攻撃
魔法ユーザーの
利点・幅広いコマンド
欠点・アイテムの持続ターン
アイテムの使用と宣言は同時にはできないので「使用タイミング」を考慮しなければならない。
まぁこのへんはアイデア段階ですのでいろいろ変わると思います。
149:名前は開発中のものです。
04/04/07 07:13 MvpBLMAM
test
150:親父PG
04/04/07 08:38 4mfJMcZS
テクスチャのブレンドに関するパラメーター多いね 多すぎて何がなんだか＠＠＠
ひとつひとつ検証しますかのう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 );
これから息子と嫁さん連れてバス旅行（隣の駅まで）行ってきます。
151:144
04/04/07 08:57 BZdMbvQi
>>145
もう１度読んでください。
前半部は、データ作成段階に入ってからの絵描き・プログラマ・スクリプタ・プランナ
それぞれの間のワークフローに関わる問題の指摘です。
様々なファイル間に依存関係があります。特に座標値を即値で持った場合には、
マップ変更で様々な影響があります。
不整合を起こさない仕組みをお考えであればまったく問題はありません。
相互に依存関係があるファイルを個別に修正すると（特に別々の人が）、様々な
エンバグが発生することでしょう。
マップエディタの例は、とりあえずトリガデータとマップデータの不整合を防ぐ仕組みの
具体例の１つとして出しただけです。
決して最終バイナリの数を問題にしたのではありません。編集時です。
後半部は・・・特に色々問題をはらんでいるのですが・・・。
まず、２つの意味で、 seed を ８ビットとする必要はありません。
・どーせパッキング単位が４バイトなのでメモリの節約にならない
・余ったビットはフラグにでも使えば良い
むしろ seed に名前をつけて文字列を格納し、実行時にアドレス（またはＩＤ）変換するくらい
富豪的でも問題ないと思います（つーか、パディングするって書いてあるけどｗ）。
データキャッシュが荒れるのを気にするならば、宣言を直してメモリを節約するのも良いと思います。
つづく
152:144
04/04/07 08:58 BZdMbvQi
ところで、>>117 の場所ＦＧって、単にフラグ番号？
場所っていうからマップの座標かと思ってた。
マップデータもただの配列だし、もしかしてまだ、マップアトリビュートテーブル自体が
話題に上ってなかった？
マップの特定の場所に行ったら起動するようなイベントはシステム側からフラグを立てて
それをトリガで拾うという仕組みをお考えですか？
なぜ、トリガデータがこんなにもスクリプト的な機能を持っているのか不思議だったのですが、
もしそうなら納得できます。
トリガデータはイベントハンドルテーブルのように扱ったほうがシンプルになると思います。
どちらにせよ、トリガデータの１レコードは豪華すぎるように思います。
んー、なんか、データ構成見てると、ソーサリアンを作れそうに見えない・・・。
アトリビュートテーブルがないせいだとは思うんだけど、マップ -> イベントキック -> シーン
の流れが見えないと・・・。
もしかして、MAPBASE::ToDo がイベント起動？
そんなことしたら、同じマップで違うイベント配置の時に管理が破綻しない？
まさかねぇ・・・。
まあ、それこそ編集時はイベント名の文字列で管理すればいいのか、な・・・？
153:親父PG
04/04/07 09:11 4mfJMcZS
>>144
いろいろな考察ありがとうございます。きちんと整理してご返答したのですが、
あいにくバスの時間がｗ戻ってきてきちんと返答します。
MAP＞イベントキック＞シーン この方法には２つ方法があると思います。
MAPにイベント番号を入れる方法と
MAPにはイベントがあったことのみのデータ－で 管理側でXY座標を引数にイベントトリガー内を検索します。
とちらにも利点欠点 あ時間だ 帰ってきて書き込みます
154:（´Д｀）ﾊｧﾊｧ
04/04/07 12:02 yREiaToq
親父PGﾀﾝはブリーフ派？トランクス派？
155:名前は開発中のものです。
04/04/07 12:26 TuGWnynl
ふんどしに決まっているだろ。
156:名前は開発中のものです。
04/04/07 12:56 CnFCUIgg
ぱ ん つ は い て な い
157:名前は開発中のものです。
04/04/07 14:22 waAm3+2+
>>親父PGさん
玄米食え、玄米。
158:親父PG
04/04/07 14:26 4mfJMcZS
>>154 155 156
orz.....
>>155
川口にいって桜を見物してきました。今日はいい天気で子供達ものびのびと羽を伸ばしてきたようです。
トリガーテーブルはそれ自身に起動条件を備えています。
またトリガー自身がトリガーを呼ぶことが出来ますし、他のトリガーからも呼ばれます。
さて地形MAPについてですが、これにはシステムに対してトリガーをチャックしろというトリガーを引きます。
プログラムに流れは以下のようになります。
キャラ移動＞該当MAPの配列調査、トリガテーブル起動命令がある。
トリガーテーブル検索、トリガーテーブルの演算＞シーン起動
さて編集時の問題についてここで解決策を述べておきます。
MAP編集ツールはトリガーテーブルに追記することができます。
MAPツールで編集するのはX座標aY座標bでトリガーがあるということだけです。
あとでシーンデーターで、その追記された部分を補完すればよいのです。
トリガーテーブルは固定長なので扱い易く、いろんなツールで追記することができます
複数人数での作業もトリガーテーブルを、マージしながら作業を進めることになります。
○トリガーの設定
とある座標にトリガーを埋め込む。MAPの配列該当部に任意の価を入れる。
同時にトリガーテーブルに座標を引数とするトリガーテーブルを追記する
（何をするかはここで編集しない ※できるようにしても良いとは思いますが）
○座標の書き換え
とある座標でトリガーを設定していたが、座標移動することになった。この場合MAPデータ－は
自身のトリガーテーブルの該当座標が記録された部分を書き換えます。
（※この作業の為にシリアル管理しても良いかもしれないね。）
○複数人数の作業
トリガーテーブルをマージします。「違うMAPの場合どうするのだ？」というご指摘がありました
その場合トリガーテーブルごとに入れ替えるか、もしくはMAP番号も引数に加えれることで解決します。
○トリガーテーブルはCSV化してEXCELで簡単に一覧化できる。簡易マクロでエラーチェックもおこなう
トリガーテーブルは計算式 IF文を処理する機構なのです。 FG（フラグ）は変数置き場です。
159:名前は開発中のものです。
04/04/07 19:19 kfqaFPaa
子供は娘さんですか？
160:名前は開発中のものです。
04/04/07 20:11 OoCqvErc
子供は娘さんですか！？？
161:名前は開発中のものです。
04/04/07 21:05 mi1SbU81
娘さんは私が責任を持って育てさせていただきますので
どうぞプログラムに専念していただきたい！！！！！！
なんの心配も要りません！！！！！！！！！！！！！！
162:名前は開発中のものです。
04/04/07 21:29 Acbfz39E
以後、親父PGの娘さんを奪い合うスレッドになります。
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
163:名前は開発中のものです。
04/04/07 21:46 du+oinrP
ありがとうございます。
では娘さんをお迎えに
行かせていただきます！！！！！！
164:名前は開発中のものです。
04/04/07 21:50 WornAub7
ジャイコちゃん、お迎えが来るから早く準備して。
165:新人PG
04/04/07 21:50 7aasUls1
URLﾘﾝｸ(www.geocities.jp)
ちょっとトリガーと地形の事についてまとめてみました。
思った事を書きます。
・トリガーのCmpOP（比較方法）は要らないんじゃないかと思っています。
プログラムの実装でカバーできるんじゃないでしょうか？
・トリガーのActCommandはデータは大きく確保しておいた方が良いのではないでしょうか。
私は複数の処理を羅列して書けたら良いと思っているので可変長配列がいいと思いますが。
実は個人的には地形データにトリガシリアルを記述する事に賛成ではありません。
別のデータ（アイテムデータ等）が持つデータだと思います。
アイテムデータがトリガ情報を所持していて、それが地形データの上にあるとすると、
アイテムデータトリガ呼び出し ＞ 地形データの座標等チェック（トリガへの付加情報） ＞ トリガ処理
という流れが出来るので良いと思っています。
抱合関係はファイルデータを参照して
●シーン := トリガ := アイテムデータ ｜ 地形データ ｜ シナリオ
このようなイメージを持っているのですがどうでしょう？
166:新人PG
04/04/07 22:10 7aasUls1
あ、あと細かい事かも知れないけど、MAPって聞くとデータ構造の方を思い浮かべてしまって混乱してますｗ
呼称「地形」で良いスか？ｗ （ごめんなさい、ほんとに判らないんです）
167:名前は開発中のものです。
04/04/07 22:16 NGXP1J9S
俺的にはマップとmapでわけてるというか
会話になると混乱するかもしれん
つーか、普段の会話でmapってでてこないしなー
hashmapとか実装込みで離すだろうし
168:新人PG
04/04/07 22:35 7aasUls1
>>167
マップが地形の方でmapがデータ構造の方？ｗ
うちの会社ではiniファイルもpropertiesファイルも全て「マップファイル」と呼びます。（ｶﾞｸﾌﾞﾙ
しかし、データ構造やシステム面から詰めていってゲームって作れるんでしょうか。
本当に行き着く先がRPGツクールな気がしてきましたｗ
ラフ絵等が出てくると雰囲気出て良いかも。
169:名前は開発中のものです。
04/04/07 22:44 iAt21LPE
そしてそういったゲームには欠かせない
絵とか音楽とかシステムまわりがこのプロジェクトにはまったく無い
技術ありきだとプログラマ本人以外ついていけんしな
170:名前は開発中のものです。
04/04/07 23:16 SEG+EKoN
ああ。。僕の真鈴たん（仮名）早く逢いたいよ。。
171:新人PG
04/04/07 23:55 7aasUls1
寝ます。
親父PGﾀﾝ夜勤ご苦労様です。
絵柄は洋ゲーっぽく、渋くクドイのが良いなぁ･･･。
硬派さを出したいｗ
172:名前は開発中のものです。
04/04/08 04:23 rdLQdFbl
なんだか凄そうなので、3Dだったらぜひ一枚かませて欲しいです。
激渋グラフィック大好きなので。必要になったら声かけてくだちい。
ひっそりのぞいてます。
173:親父PG
04/04/08 05:31 msAPqSAi
>>165
お疲れ様！
Gif画像がモビットになってるorz HPに上げてくれると助かるです
まとめ画像を見てない状態ですが、いくつか私の意見も書いておきます。
＞・トリガーのCmpOP（比較方法）は要らないんじゃないかと思っています。
＞プログラムの実装でカバーできるんじゃないでしょうか
トリガーテーブルは仮想CPUに対する命令です。この部分にゲームの「分岐」に対する情報が書き込まれます。
これらの情報は「シナリオ作成者」が担当するものなのですが、シナリオ作成者に「Cを書け」と言っても無理な注文です。
そこで、それを解決する方法として考えたのが分離方式です。
煩わしい制御コードに悩むことなく、文章部分に集中してもらいます。
トリガーテーブルは以下のようなインターフェイスで、編集を考えています。
▼はプルダウン []は価入力
条件NO００２３「▼FGの価」[34]と「▼トリガーの結果」が「▼等しいなら」「▼シーンの」[２３４]を処理
可変長にしないのはデータ－作成者のレベルを配慮（IF文より難しいことを避ける）
メインPGが使用するときの検索の高速化
いろんなツールが読み込んで作業する為のデータの単純化 など
トリガーテーブル部分だけ準PGがやることによって、ゲームスクリプトの矛盾発生を押さえ込む。
いくつかの理由があります。
174:親父PG
04/04/08 06:14 msAPqSAi
続き
・トリガーのActCommandはデータは大きく確保しておいた方が良いのではないでしょうか。
そうですね。引数もふくめるとおっしゃるとうりです。この部分は拡張しましょう。
＞別のデータ（アイテムデータ等）が持つデータだと思います。
＞アイテムデータがトリガ情報を所持していて、それが地形データの上にあるとすると、
＞アイテムデータトリガ呼び出し ＞ 地形データの座標等チェック（トリガへの付加情報） ＞ トリガ処理
＞という流れが出来るので良いと思っています。
アイテムデータ－にはトリガー情報は含みません。例えば、ある地点でアイテムを拾うというイベントがあったとしましょう。
キャラデータ－が移動、地図配列をチェック、トリガーがある。>トリガーテーブルから該当するトリガーを探し出す。
トリガの１番目のコマンドを調べる （シーン１と書いてある）
シーン１ メッセージの表示「アイテムを拾いますか？」
選択メニュ表示 戻り値をリターン
トリガの１の価取得終了 トリガの２の価取得開始 （ダイレクトの価１）
比較命令に従って２つの価の比較 条件によりアイテム取得トリガー呼出（引数 任意のアイテム番号）
このような流れになります
シーン１の情報が変わってもトリガー情報に影響がありません、逆もしかりです。
＞＞実は個人的には地形データにトリガシリアルを記述する事に賛成ではありません
これは１４４氏の指摘にある「地形データが入れ替わった時どうするのですか？」に対する
解決案のひとつ。同座標にトリガー埋め込んだ場合どうする？ という問題ですね。
＞●シーン := トリガ := アイテムデータ ｜ 地形データ ｜ シナリオ
＞このようなイメージを持っているのですがどうでしょう？
私のイメージは
地形データ＞＞＞＞トリガー＜＜＜＜シナリオ
独立 アイテムデータ－
このようなイメージを考えています。 トリガーテーブルを中心に他は従属関係にあります。
＞うちの会社ではiniファイルもpropertiesファイルも全て「マップファイル」と呼びます。
prz.... このスレでは地図データ－は地図データ－もしくは地形データと呼ぶようにしましょう。
175:親父PG
04/04/08 06:38 msAPqSAi
続き
＞しかし、データ構造やシステム面から詰めていってゲームって作れるんでしょうか。
＞本当に行き着く先がRPGツクールな気がしてきましたｗ
＞ラフ絵等が出てくると雰囲気出て良いかも。
メインPGの最初のステップは、ステージを作ることですので最初は仕方の無いことでしょう。
画面イメージなどは今ちょこちょこ作ってます。お友達にキャラ絵も数点お願いしました。
（決定原稿ではないですけどね）元少女漫画家（出産の為引退）された方です。
ゲームの雰囲気ですが、私の隣には数年前に上野の博物館であった「ケルト神話」の展覧会の本が置いてあります（W
そこから察してください。^^;
>>172 >>169
最初はライブラリの構築からマッタリという考えだったので、イメージとかの資料を提示できずにいます。
申し訳ない。劇渋３D大歓迎です。そうだ！１点お願いしてもいいでしょうか。
１２８＊１２８で武器（種類問わず）を１点お願いしてもいいでしょうか？
デザイン背景はケルト神話で基調カラーは青に緑が加わった色。
アクリル絵の具でいうところの「Compose Blue」でお願いします。
と勝手にお願いしていいのか俺orz
劇渋路線が人気あるようですね。私もラリーエルモア大好きです。
背景テクスチャポリゴンと前面テクスチャポリゴンがうまく半透明にならないと
いろいろ苦慮していましたが、原因は「背景データ－を先に描画していないから」
という結論でしたorz.....ｱﾎｽｷﾞﾙ
各テクスチャ事にレンダリングステート登録する機能作ったのに...全然別の理由だった（鬱だ
この機能は現時点ではいらないことが発覚（ｼｮﾎﾞｰﾝ orzﾅﾆｶﾆﾂｶｴﾙｶﾅ....
閑話休題
子供はまだ３歳と５歳だよｗ
176:名前は開発中のものです。
04/04/08 08:54 qS569gdt
子供ください
177:名前は開発中のものです。
04/04/08 15:10 EIdbWV3j
いきなりマニアックな内容でさらりと語るのはやめてくれ。
せめて参考になりそうなURL用意するとかして欲しいぞ。
コンポーズブルー
URLﾘﾝｸ(www.fairy-land.to)
エルモア
URLﾘﾝｸ(www.larryelmore.com)
178:名前は開発中のものです。
04/04/08 15:26 Hg7sDvxp
エルモアってなにか遠い昔に聞いた名だなと思ったが
D&Dのパッケ描いた人か…。
179:親父PG
04/04/08 15:40 msAPqSAi
>>176 orz...
>>177
調べてくれて有難う。こんなHPあったんだねorz
僕が中学生の頃、D&Dのイラストを見て、激しく感動したイラストレータです
RPGの話をするならこの人は避けて通れません。
Windowのパーツを作り始めました。仕様もこれから固めていきます。
イメージのたたき台になりますかね？
180:名前は開発中のものです。
04/04/08 16:06 PQfhS+Yw
| ああ～ やっぱ３歳は ／
| シマリがいいな～！！ ／
. ＿＿__
| |・∀・| ／⌒⌒ヽ
| |＼ |`ｲ ノハぃ） ｶｸ
. (( |_|＿ｨ⌒`｣ ∥' ､ ｿ|
ノ と､_入`_,つ λ う
ｶｸ
181:144
04/04/08 16:49 kikONY5O
トリガテーブルは固定長じゃないほうがいいと思うよ。
で、番号じゃなくて名前の文字列にしよう。
で、std::map< std::string, TriggerAndProcess > みたいなのに突っ込もう。
ハッシュでもいいけど。
マップの方では、トリガ番号をセルに埋め込むのはよろしくないと思う。
３Ｄにしたときにどうしようもなくなる。
その代わりに、アトリビュートファイルを作ろう。
アトリビュート範囲とトリガの名前が書いてある。
（もちろん、マップファイルの固定長地形データ配列の次にくっ付けても
構わないが、実行の問題じゃなくて構造の問題ね）
トリガの条件判断は、やはりスクリプトに譲ったほうがよいと思う。
寄り道できない一本道のシナリオなら今のトリガテーブルの条件記述
で構わないと思うが、ちょっと複雑になったら、結局素人の手には
終えなくなると思う。
当面は今のトリガ記述方法で良いと思うけど、早いうちからスクリプト
への変換をしておくと、トランスレータだけいじればよくなるので、
トリガデータ構造はもっと柔軟なもの（できればスクリプト）にしておいた
ほうが良いだろう。
182:名前は開発中のものです。
04/04/08 17:15 Hg7sDvxp
親父PG氏、ソーサリアンとかD&Dとか言ってる時点で
俺と同世代っぽいなー。
183:親父PG
04/04/08 17:53 msAPqSAi
>>144
ご意見ありがとう。いろいろとご意見を私なりに整理しました、話をすすめていく上で確認すべき点があると思います。
私が提起しているデータ－形式は、そのまま「メモリの上に展開して動かせる最終形態」の話です。
プログラムの中でSTLを使うにしても、バイナリデータ－の並びを解釈してCPUを動かさなければなりません。
前にも述べましたが、スクリプト（テキスト）を動的に解釈するメリットはないので、
中間言語およびスクリプトで書かれたコードは全てコンパイルが済んだ形（バイナリ）にします。
そのバイナリ形式が提案している形になります。
ただし、その前工程でどのような形でデータ－を扱ってもかまいません。
例えばコンパイラはテキストで書かれた命令文を最終的にCPU命令に置き換えます。（MOV AX、CX）
といった単純な命令群に置き換わります。今回のゲームデータ－についてはここまで単純化してはいない（必要が無い）ですが、
その一歩手前にある（構造を単純化して高速化）といえます。
std::map< std::string, TriggerAndProcess >を使用する場合、
プログラム内で「このデータ－をMAP（STL）にPUSHしてくれ」という、コードを入れなければなりません。
そういったレベルでスクリプトを組めるのはPGレベルの人だと思いますorz...
184:親父PG
04/04/08 17:53 msAPqSAi
続き
＞std::map< std::string, TriggerAndProcess > みたいなのに突っ込もう
実際問題としてトリガーがトリガーを呼ぶ構造なので、スタックという形で動的配列は使用します。
それはデータ－を解釈するPG側の話なので、そのあたりについてはお任せください。
>>トリガテーブルは固定長じゃないほうがいいと思うよ。
可変長が必用な場合、トリガーテーブルを２個（以上）使って表現すればよいのです。
トリガーがトリガーの結果を呼び出せるという構造で、柔軟な動きに対応できるはずです。
＞当面は今のトリガ記述方法で良いと思うけど、早いうちからスクリプト
＞への変換をしておくと、トランスレータだけいじればよくなるので、
逆にいえば、RPGのデータ－ツールに複雑な構造を単純化しうる機能が必要になるのです。
最終データ－を扱う段階で、英文翻訳ソフトのようなプロセスを行うことは致しませんよ。
３DについてはZ座標を別途持つことでは対応できないのかなぁorz
誤差範囲とかも必用だけど基本はBOX判定だろうし........
※どのアイテム、動作、動きにていて基底データ－のようなものを定義するのは有用かもね。C++でいう基底クラス
185:名前は開発中のものです。
04/04/08 18:02 TfluK8Bw
スクリプトをＣＰＵバイナリにするメリットなんてあるの？
解釈しやすいバイナリにするのなら当たり前だけど
移植性や可読性を考えると命令セットに依存する部分って必要ないような
ＣＰＵやモードが替わったりすると確保するバッファサイズが様々になるので
メリットないと思うんだが
ついでにいうとテキストレベルのスクリプトを動的解釈しても５００ＭＨｚ
超えているマシンなら問題になりにくい
デバッグの課程を考えるといわゆるインタプリタレベルのデバッグモード
という位置づけも必要になるんじゃないの？
３Ｄについてどうのこうのってのは再ショアから作るものが決まってないからそういったことになる
ソーサリアンを目指すというのならたとえばサイドビューとか
作るものが決まってないのならそのへんの最適な解は見つからんよ
186:親父PG
04/04/08 18:05 msAPqSAi
>>178
思い出しましたか？^^;
>>180 orz....
>>182 ﾆﾔﾘ -）
WINDOWの構造体造ったはいいがツール作るのが面倒で鬱ぬ。
187:親父PG
04/04/08 18:18 msAPqSAi
>>185
CPUはたとえでありまして、実際にCPUバイナリにはしません。
動的スクリプト解釈についてはメリットがないと思うのです。
同じ処理を事前に済ましてしまえばいいのですから。
「物理できなデータ－の塊を解釈して動作させる」という動きの比喩でCPUを上げました。
さて今回必用な話に戻すと、データ－の塊を逐次解釈して動作させます。
その基本形が提唱している固定データ－（トリガーテーブル）（中間コード）になります。
動的スクリプト解釈をするにしても起動時に一旦コンパイルして中間コードに、並べてから動作させます。
１ラインごとに解釈するはずはありません。特に今回のケースではメリットがありません。
188:親父PG
04/04/08 18:36 msAPqSAi
新人PGさん＜この呼び方なんかすごく恐縮なので,
せめてベテランPGさんとかにしてほしいなぁqrz
閑話休題
まとめていただいた図 造って頂いて有難う
URLﾘﾝｸ(www.geocities.jp)
ずばりです。各トリガーの必用な引数などは追加する可能性がありますが、
おおよそこのようなつくりです。
トリガーテーブルと呼んでいますが、これって（中間コード）ですよね。
MAPからの引数はZ値も入れましょう。
ゲームの種類のよっては使わないかもしれませんが...
189:名前は開発中のものです。
04/04/08 18:54 TfluK8Bw
トリガーからトリガー呼ぶのはいいがそのへんはシステムがインテリジェントにやってくれて
スクリプトを書く人は意識しないでいいんですよね？
たとえばjava風だとadd～listenerみたいな感じでイベントリスナ追加で
一度発生したイベントが次に発生しなくなるならremove～Listenerとか
あくまでもトリガテーブルに処理は書いちゃいかんと思うのですよ
190:親父PG
04/04/08 19:33 msAPqSAi
>>189
たくさんのご意見ありがとう。
トリガーテーブルはそれ自身がスクリプトともいえます。
自身を管理する処理は最低限行えます。
もちろん、メッセージを出すといった「処理」はかかれません
そういう場合は処理が書かれた「シーン」を呼び出す事になります。
トリガー自体を有効無効については、そういうFGが入ってもいいかもしれませんね。
Enable
Enableの価によってリムーブをコントロールしましょう。
ADDについては、フラグテーブルの後ろに物理的に加算することで表現できます。
＞トリガーからトリガー呼ぶのはいいがそのへんはシステムがインテリジェント
内部的にはそうなります。
命令の組み合わせを作り出すのはツール側になります。
例えばCのswitch-case文などをif文の羅列に並び替えるような処理は、ツール側の仕事になります。
191:新人PG
04/04/08 23:33 nyCaSSwW
ただいま帰りました･･･。
>>親父PGﾀﾝ
ようやくデータ構造が見えてきました。順にまとめていきたいと思います。
↑日曜日以降になりそうです。週末予定が入ってしまいました･･･orz
今年入社なんで「新人PG」ですｗ 社会人歴１週間です。
モビットってなんだろーとか思っていたら、2chから直リンするとモビットが出ますねｗ URL直接指定してください（汗
あと元少女漫画家の友人に注文しても良いですかね？
男だろうが女だろうが 筋 肉 モ リ モ リ で
よろしくお願いしますｗ
192:172
04/04/08 23:47 rdLQdFbl
>>親父PG
いまんとこ2Dゲーになるのか3Dゲーになるのかわかんないので、
もし今後このシステムで3Dゲーを作ろう！となって
3Dモデルとかモーションとか作る肉体労働者がたりねー
みたいな事態になったら声かけてくだちい。
（イラスト描いたりデザインしたりはデキネ。）
プログラムにも興味あるのでずっとタシロってると思いますので。。。
193:親父PG
04/04/08 23:59 msAPqSAi
>>191
お帰りなさい。
＞ようやくデータ構造が見えてきました。順にまとめていきたいと思います。
それは良かった。スクリプト作成側にも最適化等の処理を求めますので、データ構造の意味が理解していただけないと
なかなか説明が難しいと思っていたところだったので、安心しました。
＞モビットってなんだろーとか思っていたら、2chから直リンするとモビットが出ますねｗ URL直接指定してください（汗
あれ、かなりつぼにはまって笑いましたよｗ
＞あと元少女漫画家の友人に注文しても良いですかね？
＞男だろうが女だろうが 筋 肉 モ リ モ リ で
なるほろ、間に合えば連絡しておきます。
>>192
そうですか、では３Dになったら即お願いします。^^;
194:名前は開発中のものです。
04/04/09 02:52 d03K47Nx
>>184
> ３DについてはZ座標を別途持つことでは対応できないのかなぁorz
> 誤差範囲とかも必用だけど基本はBOX判定だろうし........
ナナメ
195:144
04/04/09 04:52 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
つづく
196:144
04/04/09 04:54 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 を書き換えることも考慮したが、余計わかりにくくなった
（セーブするのに、シナリオで使う前マップも保存しなきゃならなくなるし）。
197:144
04/04/09 04:56 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 も俺。
198:親父PG
04/04/09 07:10 Ihr7T82R
>>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)
199:親父PG
04/04/09 07:10 Ihr7T82R
シーン側も以下のようにコンパイルされます
(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
"宝石が..."
"宝石を拾った..."
あとで説明文書きます
200:親父PG
04/04/09 08:07 Ihr7T82R
続き
シーンデータについて考察してみました。シーンデータ－は以下の要求を満たす為に定義されます。
○ゲーム内の処理命令を表す ○可変長をサポート ○ストリングが入る ○また、ここに１つだけ判断文を定義する事ができます。
定義できる判断文
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を切り替えた時に、同時座標のトリガーを判断するためにあります。
201:親父PG
04/04/09 09:26 Ihr7T82R
すこし拡張しました
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;
//リザーブ
};
202:名前は開発中のものです。
04/04/09 16:26 HmpNauZs
もう何がなにやら・・・
203:名前は開発中のものです。
04/04/09 16:48 Ws2ssbno
ﾁﾁｷﾉﾄﾞｸ ｽｸﾞｶｴﾚ
204:名前は開発中のものです。
04/04/09 19:40 9dUWl+kl
俺はスレ主には特に何も言わんが
けっこう可愛そうな奴らがいるみたいだなぁ この板には
205:名前は開発中のものです。
04/04/10 03:46 yG5v3On8
がんがれ
206:名前は開発中のものです。
04/04/10 06:51 ZruuXOcF
おおよそ固まるまでsageで行ってみてわ？ ＞ｵﾔｼﾞさん
207:親父PG
04/04/10 09:25 Sr13ZjT1
>>202
PG以外はなんだがわけわからないですね。反省orz...
前の書き込みに「戦闘システム」の計画を書いたので何かご意見をいただければ幸いです
>>203
何処へ帰ればorz
>>204
まぁマッタリいきましょう
>>205
OK!
>>206
了解。 今日も仕事ですorz こっそり書き込みです。
現在ツール側を作成しておりまして、本体側の進行はSTOPしています。
そのツールが完成して、本体のPGに反映された頃に一回公開します。
といってもボタンとウインドとテキストのコントロール部分だけですけどねorz
208:144
04/04/10 13:01 1EUDp4ba
>>198-200
トリガから別のトリガを呼び出せるというのは書いてあったけど、return まで逐次実行ってのはどこにも書いてなかったよ。
後出しだしズルいよｗ。
ま、それはいいとして、オヤジﾀﾝ の記述例では、トリガもシーンも、オヤジﾀﾝ のいうＰＧ以外が対応できるレベルにみえないけど。
それと、トリガテーブルって、同時にいくつも存在するの？
同時ってのは、実行時の話なんだけど、仮に１つだとすると、エクセルとどのように整合性を保つのかな、と思って。
シーンファイルに、トリガサブルーチンがあるのはいいと思うけどね。
なんかもう、普通のスクリプトのバイトコードと話が変わらないように見えるよ。
単にバイトコードのフォーマットが見たことないほどリッチなだけで。
そして、エクセルで入力すると言い張ってるのは、アセンブリ言語での記述を要求しているのと等価にしか思えない。
> ＞シリアルナンバを使用するのは、配列のアドレッシングのためでしょ？
> これは少し違います。地形MAPを切り替えた時に、同時座標のトリガーを判断するためにあります。
地形マップを切り替えるというのは、
・どこかのマップでスイッチを入れる
・別のマップで跳ね橋が下りる
のようなときに、マップチップテーブルだけの入れ替えをするような話だよね？
それをシリアルナンバで判定するということは結局 std::map< int/*シリアル*/, int/*トリガ配列の添え字*/ >
のような形で判定するんでしょ？
俺は、エクセル上でもシリアルナンバの入力を強要してるのかと思ったんだけど、トリガコンパイラが文字列で
解決してくれるならそれでいいと思うよ。
ところで、>>189 で MAPposition で比較してるけど、本当は MAPBASE::ToDO に 777 が入ってるんだよね？
そうじゃなければ、エクセルで入力するときはコンマ付で入力？ マップの大きさは最大２５６ｘ２５６？
自信あるみたいだから、思うとおりにやってみるといいでしょう。
使い物になりそうなことは分かったし。
209:名前は開発中のものです。
04/04/10 16:08 ZruuXOcF
後出しって・・・・なんかの勝負でもしてるのか？
210:親父PG
04/04/10 20:09 Sr13ZjT1
>>144
いろいろと検証ありがとう。いろんな角度から見てもらえてるので、実に助かってます。
対策として具体的な仕様も決まっていくしｗ
まず書き方の例ですが、ここでの話を判りやすくするためであって実際の文法はもっと判りやすくなるはずです
このへんは「新人ニューウェーブPG」氏に期待します^^。
メイン担当としては、「最終バイナリはこういうイメージにしてね」と伝えなければなりません。
データの意味（解釈方法）を伝えるためにCで書いてみたわけです。
１４４氏の指摘の多くは私の作業より、一つ上のレイヤーの話と思える部分があります。
トリガーテーブルは（エクセル「でも」編集できる）ここが味噌でエクセルの機能を使って
レコードの操作をいたします。（エクセルと同じ機能のツール作るのは大変だｗ）
多重ソートとかマクロ機能とかね...別途作ってもいいけど。
エクセルコンポーネント使うなら一緒だ（orz...ｺﾚﾀﾞｹﾃﾞﾓｴﾂｷﾙﾖ
利用理由は主にチェックです。デバックですね。これってありがたいんですよ。ええ（独り言モード
トリガーテーブルは基本は一つですが、動的に後ろに追加しても仕様上動きます。
地形MAP配列にはトリガーを引くことしか指示しません。引数は座標XYZ（65535）＋MAPシリアル（65535）になります。何をするかはMAP側ではなくトリガー側が判断します。
作業予想
地形MAPツールは地形データ-とトリガーテーブルを読み込む。
イベントを行いたい場所へマウスでマークしていく。
このときトリガーテーブルにもトリガー情報のみのデータ-が追記される。
保存...
再度開いた時はトリガーテーブルのMAPシリアルを見て以前のマーク場所を再配置する
STEP２
イベントツールはMAP作成ツールによって作られたトリガーテーブルに、必要な情報を追加していく。
このような感じになる予定です。
>>209
勝負はしてないけどね^^ いろいろ言ってくれると助かるよ。
211:親父PG
04/04/10 20:23 Sr13ZjT1
都築
＞地形マップを切り替えるというのは、
これは「地形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のフラグもイネーブルにするべ
こんな流れかな
212:親父PG
04/04/10 20:39 Sr13ZjT1
誤>トリガー親父 ウィ～ス 橋をおろせセニョール ついでに MAP A 1、1のフラグもイネーブルにするべ
生 トリガー親父 ウィ～ス 橋をおろせセニョール ついでに MAP A 1、1のフラグもディスネーブルにするべ
間違えた（汗
間違えたついでに
このシステムの目指すところを書いてもいいのではないかと。勝手に思ったので妄想を書き込みます
このシステムでは「キャラクターデータ-」が中心となり世界を広げていきます。
大昔、D&DというTRPGがありました。あのシステムも最初は赤本から始まりました。
ダンジョンにもぐり宝物を集め、経験値を上げていく。
たくさんのエキスパンション（シナリオ）が生まれてキャラクターは成長していきました。
本システムもこのような流れで大きくしていきたいと思っています。
エキスパンションを通じてのキャラクター成長。
そして、シナリオの作成についてはツールを公開して、誰でもDMになれるようなものを考えています。
シナリオをそれぞれ交換などする事もできるようにしたいと思っています。
またキャラクターに関わる事柄。お店だとか交換所なども一種のシナリオによって構築されます。
全ての完成にはまだまだかかりますが、そこは（追加型 という仕様がなんとかしてくれるはずです（W
213:名前は開発中のものです。
04/04/11 00:46 tw9ZgcmP
>>212
でもあんまりシナリオとか簡単に作れるようにすると
あんまり知識の無い人でも簡単にズルができるようになるような。
まぁ、その人がつまらなくなるだけですけど。
214:名前は開発中のものです。
04/04/11 01:02 osyo1R4q
>>213
その話は次元が違うものと思われ
本気で解読にかかられたらいくらプロテクトかけてもだめなのと一緒
215:親父PG
04/04/11 10:09 uZkaW7mz
>>214 213
バイナリエディタ程度では改変できない仕組みは考えていますが、
214氏のご指摘どうり本気で解析されればプロテクトは無理でしょう。
ローカルで作られたシナリオの経験はキャラシートに反映されないとか、対策はありますけどね。
あとはシナリオに適正レベルを設ける。
システム側でおかしなシナリオを最初から「エラーにより排除」するなど
いろいろと対策はありますけどね。
複合的なエラーチェックでめんどくさくするぐらいしかないのかなorz...
216:新人PG
04/04/13 23:45 w0VogWFU
ただいま帰りました。仕事忙しすぎ。
だんだんまとめ辛くなってきましたが、ばんがります。
トリガーデータ案：草案を元にしたもの
[シリアルID]:数値５桁
[基本命令系]:わからん
[値種類１]:英数字５桁以内
[比較対象値１]:数値５桁
[値種類２]:英数字５桁以内
[比較対象値２]:数値５桁
[比較方法]:英数字？
[真処理]:英字？桁
[偽処理]:英字？桁
[パラメータ]:？？？
記述例）
00001,?????,Int,0,Scene,00020,Equal,ACTSCENE,00030,00002,MOVETRIGGER,00003
IDは00001、比較値１は数値型定数0、比較値２はシーン00020の戻値、比較方法は値等価判断
真の場合シーン00030を読み込みトリガ00002を起動、偽の場合トリガ00003に移動。
とりあえず、Excelで編集と言う事でXML云々は考えない方向で行きます。
このようなCSVを作成していく感じでいいんでしょうか？
217:新人PG
04/04/13 23:49 w0VogWFU
なんか殆ど、親父PGﾀﾝの頭の中でできあがってるようですね（汗
俺、要るのかな・・・？
218:名前は開発中のものです。
04/04/14 01:26 fCb1f0Lh
Excel前提ってのがまず汎用性で問題あるような
最近のマシンオフィス標準搭載かなり減ったし
その辺の自動化もツール担当の仕事かと
219:親父PG
04/04/14 05:14 EE4mRz9N
>>217
お疲れさまー、ご無沙汰しています。
＞このようなCSVを作成していく感じでいいんでしょうか？
違いますorz...SUMAN
エクセルの話ですが、あくまで「エクセルでも」データ－が見れるというものでありまして、
それはコンパイルされたデータ－を、バイナリ＜＞CSVツールで編集（デバック）できるように
するというものです。 よってスクリプト記章ツールは別に必要です。
>>217
ここ数日の書き込みでそう思われたのですねorz...
でも、決まったのはメインPGが受け取るバイナリの形でありまして、スクリプト記章ツールがいらなくなったわけではありません。
メインPG側の受け取りバイナリの形と解釈方法を提示しましたので、スクリプト側のツールはスクリプトの文法を（設計）設定して
予定のバイナリを出力するものを、設計してくれることを期待しています。
スクリプトの文法はXMLでも、オリジナルでもOKです。
ここで必用なことはシナリオライターが必要とする機能の調査と設計、機能の単純化などです。
バイナリからの逆復元（バイナリからのソース復元機能）は必用ありません。（ソースコード保存）
メインPG＜バイナリ＜スクリプトツール
↑↓
CSV
エクセル
スクリプトの文法、設計はまったくの白紙状態です。新人PGさん、大変期待しています。
220:親父PG
04/04/14 05:35 EE4mRz9N
>>218
おつかれさま EXCELは補助ツールなのでスクリプトツールは別途作成予定です。
メインPG側のバイナリの形さえ決まっていれば、スクリプトツールは自由に選べます。Excelもそのうちのひとつだと考えてください。
（もっともExcelの場合,スクリプトではなくバイナリエディタっぽい使い方だけどね。）
私の作業の報告
WINDOWの設定ツールがひとまず完成しました。１２種類のスタイルを定義できます。
メイン側は使用するときにこれらのスタイル定義にしたがって、先につくったボタン定義用のデータ－構造体より必要なデータ－をコピーして、
画面に作成します。現在、メイン画面にWINDOW本体と上部バーとクローズボタンを表示するところまでです。（WINDOWSの上にWINDOWS作ってるよorz...）
今日は久しぶりの休みです。ぼちぼち作業を始めます。
221:名前は開発中のものです。
04/04/14 10:42 fCb1f0Lh
Excelでcsv扱うと文字列の先頭のゼロが数値として読み込むために消えたり
全角数値が半角になったりしてくれるんであんまり便利な物ではないですよ
ダブルクォーテーションでくくった項目は強制的に文字列として読み込んでくれるとよかったのですがね
222:親父PG
04/04/14 10:50 EE4mRz9N
>>221
それは拡張子をtxtで読みこめば回避できます。読み込み時にセルの属性指定可能。
このシステムに関してなら、トリガーテーブルに文字列はありませんので大丈夫です。
223:名前は開発中のものです。
04/04/14 17:33 bV4eSf3V
ひげぽんOSは飽きたのか？
224:親父PG
04/04/14 17:50 EE4mRz9N
>>223
こんなプロジェクトがあったんですね。知りませんでした。orz...
OSを作る気はありまえん（W そんな能力はありませぬorz...
新人PGさんへ 既にご存知かもしれませんがこういうサイトがあります
URLﾘﾝｸ(www.ultrasync.net)
私が仮想マシン側の設計ですね。
この板見てるとツクール派と、それ以外を使ってみたいという方がけっこういらっしゃるようですね。
自作であればスクリプトエンジンが必用ですが、そのへんはみなさんどうしているのかな？
225:名前は開発中のものです。
04/04/14 23:06 FAI9201/
>>223
何コイツ？
226:名前は開発中のものです。
04/04/14 23:26 7S1uDrPs
ここの親父はまだまだ若い方だろう。
・・・もっと親父になるとマジではかどらなくなるから
今のうちにやりたい事やっときなされ。
227:WinMEMEME!fuckme!
04/04/15 00:25 WvzZ497j
ｕｎｎｋｏｂｕｒｉｂｕｒｉ？
228:新人PG
04/04/15 01:04 XWJTPtW1
ただいま帰りました。研修も無しにいきなり出向させられる会社ってどうよ（泣）
>>親父PGﾀﾝ
なんとなくわかりました。スクリプト言語（みたいなもの）を設計するって事ですね。
それならいっそのこと、トリガーだけではなくてシーン等も記述するできるようにしたいですよね？
あまり汎用的なものは考えていないのですが、現ゲームの作成に特化したものを目指すようにします。
#余談ですが、卒論のテーマと似ていますｗ
#流用しながら作る予定なので、早く作れるかも？
229:親父PG
04/04/15 07:18 lFmywgB/
>>226
^^;ｶﾞﾝﾊﾞﾘﾏｽ
>>227
orz...
>>228
おつかれさま。お仕事大変ですね。
＞スクリプト言語（みたいなもの）を設計するって事ですね。
そうです。よろしくお願いします。
＞トリガーだけではなくてシーン等も記述するできるようにしたいですよね？
そうです。そして出力ファイルは分離して行われます。
トリガーとシーンは分離します。
＞あまり汎用的なものは考えていないのですが、現ゲームの作成に特化したものを目指すようにします
スクリプト言語内で一旦中間コードにして、そこから出力フォーマット用に変換するように設計すると良いですよ。
出力フォーマットを切り替えると、別の用途用に使えるように切り替える事も出来ます^^;（仕様変更にも強くなりますorz...）
#余談ですが、卒論のテーマと似ていますｗ
#流用しながら作る予定なので、早く作れるかも？
おお！ 期待してますよ♪