Unityと吉里吉里でSLGとかRPGを作るブログ

すっかり2日に1回のペースに・・・・・・・・・・。

メニューとかセーブロードとか、まだ色々やる事がある気がするけど、取り合えずユニット関係の設計をする。
セーブとロードなんかには、ユニット情報は必須だし。


///ユニットデータ管理の設計
戦闘のあるSLGなら全てにユニットが存在する訳だから、今後も考えてなるべく汎用的な設計にしたい(プログラマの悪い癖)。
そこでユニットを、「ユニットデータ」と「キャラデータ」に分けて設計する。重要なのはゲーム的には2つをあわせた物をユニットとして使用すると言う事(これをキャラユニットとする)。

①ユニットデータ
 キャラユニットの種類を表す。ファンタジー物なら職業(戦士、盗賊など)。ロボット物なら(メカ)。大戦略系なら戦車とかヘリコプタとかになる。

②キャラデータ
 キャラユニットの成長部分などを表す。一番分りやすいのはロボット物のパイロット。

ロボット物だと簡単に説明出来る。ユニットデータがロボで、キャラデータがパイロット。パイロットは成長して能力を高めたり、スキルを習得したりする。
当然、ロボを乗り換えても、キャラのスキルや成長分は変わらんと言う訳。
あと、パイロットが載らないユニットがあるゲームもあるだろう、ギレンの野望なんかは、MSにパイロットを乗せる形だが、パイロットを乗せなくてもユニットとして同様に扱える。
これは、キャラデータにネームキャラフラグを用意すれば簡単に解決出来る。キャラ選択画面にはネームキャラフラグがある物のみ表示すれば良い。パイロットが乗ってないユニットには、一般兵と言うキャラを載せる訳だ。

ファンタジー物だと、戦士Aが転職で騎士Aに変更した場合、騎士という大枠の性能にAの能力が乗る形になる。これならいくら転職してもデータの扱いに困る事はない。



///ユニットのオブジェクト
■オブジェクト概要図
ユニットデータ相関図
取り合えず、HPとスピードだけ能力のあるユニットを設計してみた。

キャラ、ユニットは全種類をテーブルに保持する。
ユーザーがユニットを得た場合、以下の処理でユニットを登録する。
※ここではファンタジー物を例にしてみる。

1.キャラユニットテーブルに戦士データを追加。
2.ユニットシリアルを元にユニットテーブルを参照し、初期キャラクターIDを得る。
3.初期キャラクターIDを元に、キャラテーブルから該当するデータを保有キャラテーブルにコピーする。
4.コピーされたキャラデータのシリアルを、キャラユニットのキャラシリアルにコピーする。

このユニットを使う場合は、シリアルを元に各テーブルを参照する。
例えば、スピードを求める場合、シリアルを元にキャラスピードとユニットスピードを足したものを返す。
転職などの場合も凄く簡単。ユニットシリアルを変更するだけでOKだ。




私はゲームを作った事が無いので、これが一般的かは判断できないが、多少の差異はあってもこんな感じで制御しているはず。
SLGのユニットは将棋の駒みたいな物な訳だから、駒の種類としてのバランスは重要になる。仮に戦士の能力を変えるのに全キャラから戦士を探して変更なんて事はまずない。


スポンサーサイト
2009.01.31 / Top↑
ターン処理も終ったんで、次はウィンドウ処理関連。
ゲームにもよるだろうけど、開いたウィンドウは右クリックで閉じられるのがほぼ常識となっている。
特に大量にウィンドウを表示するゲームの場合、この機能の有無がゲームの良し悪しに直結する。

今回は、開いたウィンドウを右クリックで閉じる制御を作りこんでいく。


///ウィンドウ制御の設計
もし、ウィンドウが1画面に1、2つしか開かないなら、制御と呼べる物は必要ない。
何故なら開いてるウィンドウを閉じてしまえば良いからだ。しかし、別種のウィドウやら子ウィドウやらを複数表示する様になると問題が発生する。
そこで必要な処理は以下になる。

①子ウィンドウ
 子ウィンドウを開いてる時、右クリックした場合、子ウィンドウだけを閉じる。

②閉じる順番
 複数のウィンドウがある場合、開いた順と逆に閉じていく。

③ウィンドウを開いてる時は、クリッカブルマップをロックする。

書き出してみると分るけど、必要な情報は「どのウィンドウが開いているか」と「どの順番で開いたか」。
なんで、それらを持つオブジェクトを作って、ウィンドウを制御する。
あと、このゲームの特性上、クリッカブルマップの上にウィンドウを表示するので、ウィンドウが動いてる場合はクリッカブルマップをロックする。


///オブジェクトの設計
■オブジェクト相関図
右クリック

1.ウィンドウを開いたらクリッカブルマップをロックする。
2.開いたウィンドウのIDをID配列に追加する。
3.右クリックされたら、ID配列の一番したのIDを取得して、そのウィンドウを閉じる。
4.ID配列が全部無くなったら、クリッカブルマップを解除する。

ここで1つ問題が発生する。ウィンドウってのは再表示とかを結構行う。
例えば、このゲームなら土地に建物を建てると、その建物の影響を反映する為、ウィンドウを再表示する。見た目は建物が反映されただけだけど、処理的には再度ウィンドウを表示し直してる。

こうなると、IDを複数登録してしまうかもしれない。これを防ぐ為、ID登録の際に自分と同じIDが既に登録されていたらIDを登録しない処理を追加しておく。

これで表示の為のウィンドウ表示は無視され、あくまでもユーザーが開いた順番に応じてウィンドウが閉じる。




テスト結果も乗せようと思ったが、最近画面張るのが多くなり、ちょっと時間を圧迫している。
ほぼ毎日更新なんで、1話は30分程度で出来るのが望ましい、今後も必要がなければ概念だけ載せておく事にした。

次回はいよいよユニット回りだ。

2009.01.29 / Top↑
イベント処理も一段落したので、次はターン更新時の処理を作る。
ターン更新そのものは、基本的にはイベント処理と一緒なので割愛。資金と資源の更新の部分を作りこんでいく。


///SLGの資金と資源
戦略系のSLGでは、ほぼ全て資金とか資源といったリソースを管理している。
これらを消費して、戦車や兵隊なんかを購入してゲームを勧めていくのが一般的。

これらのリソースは、ターン毎に自国のエリアによって得られる量が変わるのが普通。
このゲームでは、エリアに建物があり、その種類によって得られる額が変わる様にしたい。
ただし、資源については、エリアだけでも収入がある様に設定する。
※鉱山とかがある地域などの為。


///オブジェクトの修正
とりあえず、エリア情報テーブルにエリアで得られる資源量を設定。次に土地情報テーブルに建物毎に得られる資金や資源を表示する。

■エリア情報テーブルオブジェクト
エリア情報テーブル


///土地情報ウィンドウの修正
土地情報ウィンドウに資金と資源の収入量を表示する。当然、建物の変更に合わせて更新される必要もある。
エリアオブジェクトに現在の資金と資源収入を算出する機能を追加する。
この時、条件は指定した国が支配しているエリアで且つ、エリアを支配している国と同じ支配国の土地(建物)とする。
■土地情報ウィンドウ
エリア情報テーブル(資金、資源)

■建物立替後
エリア情報テーブル(資金、資源)2
建物の影響で資金収入と資源収入が変化。

■建物支配
エリア情報テーブル(資金、資源)3
エリア支配国と別の国が建物を占領した場合、その建物を収入から減らす。


///ターン更新
上で作った、資金と資源算出用の機能を全マップで実行し合計する。条件である支配国は自国を設定すればOK。
あとは、現在の資金と資源にそれを足してターンに+1すれば終了。




次回はウィンドウの制御を作成する。
これが終ったら、いよいよ戦闘部分の作成を実行しよう。

2009.01.27 / Top↑
このまま、痛快イベント処理まで行きそうな勢いだったけど、イベント処理はどうにか終了。


///イベント処理各種

■隣接イベント
隣接イベント
自国に隣接したエリアで発生するイベント。

■国交関係変化
隣接イベント
国交関係は、エリアの色で表してる。自国、敵、それ以外。それ以外が敵になった場合、当然エリアの色が変わらないといけない。

■交戦中イベント
国交関係
エリア無いで土地を取り合ってる時に発生するイベント。


///国交関係
国交関係は、自国、敵国、その他を、国情報テーブルに追加する。
■国テーブルオブジェクト
国情報テーブルオブジェクト

赤い色は、ゲーム無いで書き換えが発生する項目。



かけた時間の割りに書き出すと大した事ないな。実際は、国交関係の制御とか色々大変だったんだけど。
次回はターンの更新処理を行いたい。

2009.01.26 / Top↑
昨日の続きを作っていく。
イベント系処理は基本的に押さえたツモリ。


///昨日のおさらい
昨日は「会話シーン系」イベントの内、「①画面を切り替える」まで終了している。
■下がリスト
①画面を切り替える
 TJSオブジェクトを非表示に。

②KAGスクリプトによる会話
 特になし。

③MAP画面に戻る
 イベント発生時と同じ画面に戻る。

はKAGスクリプトに過ぎないので問題は無い。
問題は、で戻ってくる際にウィンドウの再表示などが必要。
■MAP画面に戻る
戻る前
この時、各ウィンドウは最新の情報に更新される必要がある。①と違って、非表示した物を表示するだけではだめ。


///イベント各種
このゲームの仕様は完全に煮詰まっていないけど、現状だけでも下のイベントが考えられる。
①エリアの支配国変更
 エリアの支配国が変更されるので、エリアマップと土地支配国の変更が必要。

②土地の支配国変更
 各土地の建物の支配国と、全ての土地を奪った場合、①と同様の処理が必要。

③金額と資金の変更
 まあ、そのまま

イベントだから色々な可能性があるけど、今の所画面に影響でそうなのはこれくらい。画面に影響出ないフラグ系とかなら別になんだって同じ。

①エリアの支配国変更(実行結果)
エリア支配変更

②土地の支配国変更(実行結果)
土地支配変更①

②土地の支配国変更「全土地支配」(実行結果)
土地支配変更②

③金額と資金の変更(実行結果)
金と資源


無駄に画面はっちまった、殆ど意味無いな、この画面。まあ、私のモチベ維持ブログだからいいけど。




次回は隣接エリアや交戦中エリアとかの条件イベントをテスト。


2009.01.24 / Top↑
昨日は会社の新年会で遅くなったので、何もできなかった。

前回、イベントの発生を制御するプログラムを作成したので、続いて実際にイベントを発生させて見たい。
ここでイベントと行っているのは、キャラクター色のあるSLGで良くあるキャラの会話シーンとか。


///イベントの仕組みを考える
前回作ったイベントの発生を制御するkag.process(※1)を使用して指定したスクリプトに飛ぶだけの処理に過ぎない。
イベントが「エリアの制圧」だろうが、「会話シーン」だろうが、「お金を得る」だろうが、飛んだ先で制御する事にする。図にすると下の様な感じ。
■イベントの仕組み概要図
イベント処理の仕組み
こうする事であらゆるイベントに対応出来る。
イベント処理で一番問題となるのは、「会話シーンの様なイベント」になる。
このイベントは、「画面を切り替える」→「KAGスクリプトによる会話」→「MAP画面に戻る」となる訳だけど、ここで問題となるのが、今表示されているTJSオブジェクト。
各処理間で、以下の処理が必要になる。

①画面を切り替える
 TJSオブジェクトを非表示に。

②KAGスクリプトによる会話
 特になし。

③MAP画面に戻る
 イベント発生時と同じ画面に戻る。

最も困難なのは③である。ただ表示を戻すだけでも結構大変そうだけど、イベントが終了する時に何かしらデータの書き換えとか(イベントが発生した後にキャラが増えたり金が減ったり)したら、一気に困難さは増すはず。

※1:KAGスクリプトで言う「jumpタグ」


///とりあえずやってみる
正直、吉里吉里の画面切り替えなどは、完全に独自仕様のせいもあって、良く分からない。
ちゃんと出来てるかを試す為にも色々実行しながら進めてみる。行き当たりばったりだがゲームの作成経験が全くない私には今一先が見通せない。

まずは、イベントを起こして見よう、イベントボタンを押下したらトランジションしてみる。
■イベント発生前
イベント発生前

■イベント発生後(トランジション)
イベント発生後
※この画像はこのサイトからお借りしています

まあ、当然、ウィンドウ画面なんかは出っ放しになる。
これは、MAPに表示しているオブジェクトを全部非表示にする機能をつければ良さそう。
■イベント発生(トランジション):非表示機能
イベント発生後(オブジェ非表示)
表示非表示は、表画面と裏画面を別々に出来る様に設定している。トランジションする場合は、裏画面を非表示にすればOK。
これで「①画面を切り替える」については問題なし。




今日は酒が残っていて、仕事が遅くなってしまった。次はイベントから復帰する所を作りたい。


2009.01.23 / Top↑
前回整理した、イベント処理からオブジェクトの設計をしてみる。
これが完成すれば、とりあえずイベントが起こせる様になるので、頑張りたい。


///オブジェクトの設計
作成するオブジェクトは2つ。1つはイベント用のテーブルオブジェクト、もう1つは、イベント&コマンドを表示するウィンドウオブジェクト。
■オブジェクトの設計
イベントオブジェクト
イベントテーブルには、更に実行フラグを用意して、実行したらこれをONにする様にする。
これで1度行ったイベントが再実行されない様に出来る。何度も起こるイベントには、オフ無効フラグで差別化する。


///実行画面
■画面
イベントウィンドウ

エリア1のイベントだけ作成している。ここで重要なのは表示されたボタンは、現在のエリア1の状態を元にイベントテーブルから検索した内容になっている事。
当然、クリックした場合に実行される処理も、イベントテーブルから検索された物になる。
※イベントウィンドウをどうやって表示するかについては、保留にしている。ゲームの操作性に結構影響するし、じっくり考えたい。



次回は、イベント発生イベント画面MAP画面に戻る処理を実行する。
今回のイベント処理はコレがやりたくて作った様な物。戦闘画面に行くのもイベントでおねーちゃんが喋るのも、全部画面が切り替わる。この切り替わった画面からの復帰が正常に行われるかは微妙に心配。
2009.01.20 / Top↑
今回はコマンドとイベントの処理を作成する。
この手のゲームで一番分りやすいコマンドは「進軍」になると思う。
敵の陣地をクリックして、「進軍」コマンドを入れれば、部隊選択画面とかになって・・って感じになるんだけど、これ1つとっても結構めんどくさい処理が発生する。
とりあえず、その当たりの設計からやっていく。


///コマンド&イベントの整理
コマンドとイベントを処理する場合、どんな情報が必要かまとめてみる。
①どのエリアか
  日本地図なら、千葉でしか発生しないイベントとかコマンドとかに必須。

②自国の土地と隣接したエリアか
  凄い遠方のエリアまで「進軍」したらおかしいので、エリア間の連結情報は必須の情報。
  処理的には下の図の様に処理する。

  ■エリアの隣接判定概要図
  隣接
  エリア③にエリア②、④、⑤が繋がっている情報だけ与えておけば、繋がっているエ
  リアを全て調べて1つでも自国があれば、そのエリアは自国と繋がっている事が分る。
  自国と隣接した事をフラグで管理するよりも、スマートに管理できるはず。(オンオフの
  処理が必要ない)
  これは、エリアデータテーブルに追加すればOK。

③支配国が自国かそれ以外か
  先の「進軍」なんかは、自国内では発生しない。あと、自国のみ発生するイベントやコ
  マンドにも必須の情報。

④支配国とは交戦状態か
  交戦前の場合、「宣戦布告」とかのコマンドが必要なゲームも多い。あと、同盟国の場
  合のみ出るコマンドとか。

⑤支配国はどこか
  戦略ゲームでは、一度占領した土地を奪い返される事は良くある事。例えば、A国の土
  地を奪ったけど、B国にその土地を取られた場合、A国のイベントがそこで発生するのは
  不味い。
  この手のバグはSLG好きな人は1回くらい見た事あるんじゃないだろうか、滅んだはず
  の国のイベントとか発生するやつ。

⑥そのコマンド&イベントの条件はそろっているか
  特定キャラが居る場合のみ発生するコマンドとかイベントとかに必須。条件はフラグで判
  定して、フラグが立ってる場合のみコマンドやイベントが使える様にすればよい。


///イベント管理の設計
こうやってみるとコマンドもイベントの一部と考えられる。そしてイベントは、使用条件と発生条件に分けて考えると良さそう。

■使用条件
 ①エリアの情報(隣接とか自国とか交戦中)
 ②発生場所(マップ、ターン頭(エンドとか)
 ③使用可能フラグが立ってるか

①は「進軍」コマンドの様にマップ上で使用するイベントの場合に必要な情報。
②は発生場所、上のマップ上や、ターンの頭に自動的に発生するなど。
③は発生条件を満たしているかを表す。

■発生条件
 ①条件(特定キャラがいるとか何ターン目とか資金いくらとか)
 ②使用可能フラグ

発生条件で、イベントの発生を管理し、使用条件で発生場所を管理するイメージ。図にすると下の様な感じ。
■イベント管理図
イベント相関
ターン頭とか特定の条件で自動的に発生するイベントも全く一緒。トリガーが自動かユーザーによるマウスクリックかの違いでしかない。

例えば、3ターン後に東京エリアが自国エリアの時に東京タワーを見に行くイベントが発生する様な場合、「3ターン後」が発生条件、「東京エリア」で「自国エリアの場合」が使用条件となる。

3ターン後になった時点で、使用可能フラグがONになり、イベントは発生する条件を満たすが、東京エリアが自国エリアで無い場合は、イベントボタンが使用出来ないって形になる。




次回はこれを元にオブジェクトの設計を行う予定。



2009.01.19 / Top↑
建物を建てる際に、資金と資源を消費する様に変更する。
それにはまず、資金と資源を表示しないといけない。後は資金か資源が足らない場合の処理も必要だな。


///資金と資源を表示する
まずはお馴染みのオブジェクトの設計。
これはテーブル系のプログラムを改修する事にする。
CSVで初期資金と資源を読み込み、グローバルオブジェクトに設定してどのプログラムからも参照更新が可能にした方が色々いいだろう。

■資源と資金を表示
資金の表示

非常にやっつけだが、分かればOK。並んでる数字は上から、ターン、資金、資源の順。



///建物の購入
全ての建物は、値段が100、必要資源が110に設定している。
■購入前
購入前


■購入後
購入後


続いて、資金と資源が足りない場合のボタンを使用不能に設定する。

■購入不可建物
ボタン使用不能
居住区(ビルっぽい絵の奴)だけ、値段を2000に設定している。



///自国以外の土地
今まで、自国支配も敵国支配の土地も同じ様に扱っていたので、そろそろ修正。
敵国の場合は、建物のボタンをクリックしても、建物の説明が出るだけに変更。

■敵国時の建物ボタン
敵エリア
最初は、ボタンすら押せない様にしようと思ったが、敵の土地に建ってる建物とか判断したい時もあるだろうと思い、説明文のみ出る様にしてみた。





まだ出来てない画像もあるけど、プログラムに飽きた頃に作る事にする。
早く戦闘部分を作りたいんだけど、そこを先に作ると後で力尽きそうなんで、面倒なマップ周りを完成させてからにしよう。
次はイベント部分を作成していく。
2009.01.19 / Top↑
また、1日あけてしまった。画像作ってる時はアップ内容が無いから仕方ないけど。

前回作った仮の画面を修正する。問題があったボタンクラスも修正。画像については、ドット絵と持ってるゲームの切り張りで作成。


///ボタンクラスの修正
前回作ったボタンクラスは、ボタン制御クラスを個別に作って制御していた。
これだと、ウィンドウのボタンを押したら次のウィンドウが出るってパターンで凄く面倒。

■旧ボタン関連クラス
旧ボタン関連クラス

ボタンを押したりマウスが上に乗った時の処理を、ボタン制御クラスで行う必要があり、ボタン毎にボタン制御クラスが必要。
さらにボタンを押したらウィンドウが開くとなると、ボタン制御にそのウィンドウで必要な情報も渡さなければならない。

■新ボタン関連クラス
新ボタン関連クラス

そこで、ボタン制御は完全な汎用クラスになって貰うべく、ボタンが押された時マウスが乗った時マウスが離れた時様のメソッドを引数に渡す形に変更した。
ウィンドウクラスがボタン制御クラスにメソッドを渡して、ボタン制御クラスはそのメソッドを作成したボタンに渡すだけ。
これで各ボタンの処理はウィンドウクラスで実行出来る。

追加機能として、クリックした際にクリックされた状態を残す事が出来る様にもした。
■クリック時
マウスクリック新

これで次のウィンドウが出ても、どこがクリックされてるか明確に解る。


///土地変更ウィンドウの修正
■土地情報ウィンドウ
土地情報ウィンドウ②

完全にやっつけだった土地情報ウィンドウを、やややっつけまで改修。
隠れて見えなかった、土地の説明文も見える様になった。

画像作成は、なるべく控えた方がいいな。今回はボタン周りの製造だったから画像の作成は一定の意味があったけど、コアシステムも出来て無いのに見栄えを気にしても仕方ない。
次回は建物を建てる時に消費する、金と資材の制御。
2009.01.16 / Top↑
サクサク(笑)とか言いつつ、4話くらい使ってる。まじめにブリーチに並の展開速度だな。
とりあえずの原型は完成したので、そいつをアップ。


//土地選択ボタンを付ける
まずは、土地を選択するボタンを付ける。
ボタンについては、下のサイトのシステムボタンを改造して作成した。
■TJSに挑戦!

普通のリンクボタンのサンプルもあったけど、ウィンドウ上から制御するならシステムボタンの方が改修しやすかったのでこっちを改修。
※作っていくと色々問題がある事が判明。次回以降の修正で直す予定

■ボタンの上にカーソルをのせる
かーそるおん
カーソルがあった位置が光ってる。


//建物選択ウィンドウ
土地情報ウィンドウをそのままコピって、建物選択ウィンドウを作成。
上の画像で、ボタンをクリックすると、建物選択ウィンドウが出る。
■建物選択ウィンドウ
土地変更ウィンドウ1
いや、建物の画像すらないので、あれだけど画像周りを明日以降作り直すので、今はこれでかんべん。

適当にボタンを選択してクリックすると、選択した建物が建て替る。
■立替後
立替後
赤い矢印のところが建て替わった。


//建物解説
建物選択ウィンドウでチラッと出ていたが、ボタンにウィンドウを合わせると、その建物の説明やらが出る仕様にしている。(重なって見えないけどねw)
これは、土地情報テーブルから読み込んでいる。
■オブジェクト相関図
オブジェクト相関図④
赤線で囲まれているデータを表示。




作ってみると不味い所が多い。
まず、ボタン関係。押した場所が残らないから、立替用のウィンドウが出ても、どれが建て替わるか解り難い。
それと、システムボタンを元にしたクラスも今一。ウィンドウクラス→ボタン制御クラス→ボタンクラスとなるので、各ボタンで制御クラスを作成しなければならない。制御クラスにも色々情報を渡さないといけないので、引数も膨大になる。

次回からその当たりの修正と、画像の作成を行う。
・・・・ここまで見て頂いた通り、画像は苦手。でも、適当な画像ばかりだと、後で悲惨なインターフェースになりそうなんで、頑張ってみる。
2009.01.14 / Top↑
今まで作って来た物は、全てTJSで出来ている。KAGスクリプトは、トランジションとクリッカブルマップしか使っていない。
実際、KAGプラグインを使用すれば、KAGで出来る事は全てTJSで制御出来る。
しかし、ノベルやADVである様なキャラクターの会話シーンなどは、断然KAGスクリプトを使用した方が楽である。今回は、KAGスクリプトの設計を行う。



//ファイルの相関図
まず、通常のノベルゲームと違って、各イベントはMAP画面から起動される。
連続したイベント処理が無い上、かなりの数のフラグによって起こる(起こせる)イベントを制御する必要がある。

■ファイル相関図
KAGスクリプト相関図

first.ksで、TJSプラグインを全て読み込む。これによってゲーム中のロードが高速で処理出来る。
起動時に若干遅くなるかも知れないが、前回のテストで見た限り、影響は無いに等しい。

ターン製ゲームの予定なので、strategy.ksでは主にターンから戻った時の処理を実行する。
そして、クリッカブルマップにて、エリア番号に合ったareaXXX.ksに飛び、各種のフラグをTJSより取得して、イベント用の選択肢を出す。



///オブジェクトとファイルの相関図
TJSオブジェクトとそれが記載されたファイルとの相関図も作っておく、これはファイル数が多くなると非常に助かるので、前にフリーツールを作った時も良く作成したもの。

■TJSオブジェクトとファイルの相関図
オブジェクトとファイル相関図




考えてみれば、日曜日は必ず予定があるんだった。正直、平日の方が進む気配。これはテスト前の部屋掃除現象と同じだな。

次回こそは、建物を建て替えれる様にする。
2009.01.13 / Top↑
私は、吉里吉里に触ってまだ半月も立って居ませんが、いくつかのゲームやその体験版を落として見ましたが、どれも速度に問題は感じませんでした。
恐らく、一般的なノベルゲームを作成するに当たっては、吉里吉里の速度に問題は無いと感じます。
それでも、吉里吉里を扱った掲示板では、レイヤ数による重さを懸念する書き込みが良くあります。
ここでは、地域征服型ゲームを作成するにあたり、吉里吉里の速度検証をして見ました。


///吉里吉里は重いのか?
同様の記事を扱っているサイトがあります。
●四方山話 - 吉里吉里2/KAG3は「重い」のか?

これらの記事は2003年~2006年に書かれており、現在とは異なる可能性がありますが、PCの性能もこの当時より上がっており、ノベルやADVと言ったゲームについて、吉里吉里の速度を気にする必要は無さそうです。
ただ、具体的な判例が無く、正直判断に苦しみます。


///実験目的
ここでは、吉里吉里で地域征服型ゲームを作るに当たっての速度に的を絞って検証して見ました。
地域征服型ゲームとは、信長の野望や三国志などの形態をもったゲームです。地図によるマップがあり、敵の領土に兵を進軍して領土を奪っていくスタイルになります。
これらのゲームには、通常のノベルやADVとは異なる点があります。それはリアルタイムでのレイヤ更新や多数のウィンドウによるレイヤの表示です。
今回は、全体マップにおける動作速度に絞ってテストを実施しました。



///テスト機
OS:WinXP SP2
CPU:CELERON 3.2GHz
RAM:500MB



///マップ表示の実験
まず、マップ表示で問題なのは、地図にあるエリア分の画像レイヤが必要だと言う事でしょう。
例えば、都道府県なら47。(ですよね?)世界地図なら150を越えるエリア数があるのですから膨大です。
一般的なノベルでは、一画面で100を越えるなんて事はめったに無いでしょう。
ここでは、エリア1つに対して、マップを表示するレイヤと支配国を表示するレイヤを作成して見ました。

■テスト結果①(エリア数40「レイヤ80」)
エリア数40

■テスト結果②(エリア数99「レイヤ198」)
レイヤ数99


まあ、画像を見せても意味はないのですけど、一応どうやったかについて分かり易くする為です。
このテストでは以下2つの点に気をつけました。
1.MAPの画像は全て別ファイルにしてあります。
  これは、同じ画像を使用するとキャッシュが効いてしまう可能性がある為です。

2.画像ファイルは無理やり重くしてある。
MAP及び支配国(上の■)共に見た目はシンプルですが、実際には大きい画像の一部を切り出す形にしてます。

この状態で、トランジション、全マップ画像の変更。支配国の変更など、色々試してみましたが、速度には全く差が有りませんでした。
レイヤ数が200近くあっても、静止画であれば正直差は無いに等しい様です。
実際のゲームでは、MAP画像は全て表示する必要はない筈です。戦闘状態に無い国は色を変えずにレイヤを非表示にする事が出来ます。
そこを考えると、世界マップですら、MAP表示は問題ないと考えられます。



///ウィンドウ表示の実験
SLGでは、ウィンドウが兎に角多くなりがちです。国や兵の情報を表示し、さらに変更した内容を即座に反映する必要があるからです。
ここでは、今まで作ってきた土地情報ウィンドウを無理やり3つほど並べてみました。

■テスト結果(ウィンドウ3つ「レイヤ30」)
ウィンドウ表示


MAP表示テスト同様に、トランジション、マップ画像の変更などを行っていましたが、全て一瞬で実行出来ました。
どの位遅くなるのか?を検証したかったのですが、実質差がありません。体感速度差は完全に0です。



///総評
速度差などをまとめる記事にしたかったのですが、あまりに速度差が無い為、拍子抜けしてしまいました。
テストPCも、5年前の機体であり、しかもゲームマシンなどの描画速度に特化した作りにはなっていません。

実際に戦闘部分を作りこんだ場合には、もう少し動的な処理や画像が必要になると思いますが、全体マップ部分の作りこみにおいては、速度を気にする必要は無い様です。

戦闘部分が完成したら、もう一度テストしてみたいと思います。

2009.01.12 / Top↑
とうとう1日空けてしまった。駄文でも毎日更新する予定だっただけに残念。
前回の続き、ウィンドウ用の簡単な画像を用意して、小さなバグを直して完成。


///土地情報ウィンドウの表示テスト

■エリアにカーソルを合わせる
7話カーソルあわせ
カーソルが乗ったエリアの情報を表示。
エリア名や、建造されている建物と、それを支配している国が表示されている。

■エリアをクリック
7話エリアをクリック
クリックした場合、土地情報ウィンドウが固定され、イベント選択肢が出る。
イベント選択肢ってのは、そのエリアで発生するイベントへの選択肢ね、千葉エリアをクリックすると、「東京ディ○ニーランドに遊びに行く」って選択肢が出るみたいな物。

■左クリック
7話カーソルあわせ
土地情報ウインドウの固定を解除、イベント選択肢を消す。(画像使いまわしましたすみません)

■敵軍側も表示
敵側
建物の支配勢力が敵軍になってることを確認。

次は建物の建替えが出来る様にする。
でも、その前に吉里吉里で地域征服型のSLGを作るにあたって、若干不安である速度の問題をテストしてみたい。
結構テストしたので明日にはまとめられるはず。
2009.01.10 / Top↑

///マップの設計
カーソルが当たったら、土地情報ウィンドウを出す部分を作り込む。
といっても、吉里吉里にはクリッカブルマップと言うありがたい代物が既に用意されており、更にそれらの解説やらサンプルやらが一杯紹介されている。
私が参考にしたのは下のサイト。このサイトで紹介されているカーソルが当たったら、ターゲットマークを表示する部分を、ウィンドウを表示する機能に変更すれば、そのまま使用可能。
■参考サイト
http://homepage1.nifty.com/gutchie/kirikiri_kag3/dev_clickablemap001.html


///土地情報ウィンドウの設計
土地情報ウィンドウに何を表示するかを洗い出し。といってもこれは前に作ったから、そのままコピペ。
・エリア名
・支配国名
・建設物1
・建設物1の支配国
・建設物1のランク
    ・
    ・
    ・
    ・
    ・
・建設物5
・建設物5の支配国
・建設物5のランク
・ウィンドウの外枠
・ウィンドウの中枠

ここで問題になるのは、テキストとウィンドウの枠表示。エリアマップの表示で使った奴を改造し、指定された画像を表示するだけの奴を作る。
問題は、テキスト表示だが、これもエリアマップの表示の奴を改造する。ただし、テキスト表示の引数は多いので、「囲み文字」、「影付き」、「何もなし」を指定すると既存の設定になる様に作る。



///オブジェクトの設計
土地情報ウィンドウは、個別のクラスとして、マップデータクラスで保持する形にする。マップデータクラスは、エリアデータクラスから情報を得て、土地情報ウィンドウクラス(land_Win)に渡す事で、土地情報を表示する。
もう1個作らないといけない物がある、それは「支配国名」を表示するにあたり、国の情報が必要って事。今の所、各エリアの支配者は番号で管理している。これに個別の名前を付けられる様に国データテーブルを作成する。

■オブジェクト相関図
オブジェクト相関図③
もうお馴染みの酷い資料。どれがどれの配下か分りやすいから、今後絶対役に立つはず。


ウィンドウを表示するには画像を用意しないといけないから、今日はここまで。次回、画像を用意して、ウィンドウ表示のテストをしてみる。

仕事が忙しいとは言え全くすすまん。さくさく(笑)が洒落にならない。明日頑張れば連休なので、頑張って進めたい。
2009.01.09 / Top↑
土地情報と言うなぞの造語で語ってきたけど、実際なんなのか洗い出し。
簡単に言うと、日本地図があって、東京都にカーソルを合わせると、東京タワーや都庁が表示される機能。
表示する項目は以下になる。

・エリア名
・支配国名
・建物1
・建物1の支配国
・建物1のランク
    ・
    ・
    ・
    ・
・建物5
・建物5の支配国
・建物5のランク

ここでやっと建物の情報が出る訳だけど、建物とは一体なにかをここで書き出しておく。
例えば、東京都を侵略するとして、「都庁」、「東京タワー」、「雷門」の建物があった場合、
最初の侵略で勝利しても、「雷門」を手に入れて終了する。
つまり、東京都を敵から奪う場合、3回の侵略が最低条件で、侵略される側も2回までは敗北しても東京都を取られない。これは元としている「戦○ランス」にある機能で、これによって被害の大きな戦いを避ける事が重要な戦術になる。

これから作るゲームでは、2つの機能を追加したい。
・建物は自由に建て替えれる(金や材料などがかかるけど)
・建物によって収入やらが変わる
・建物にはランクがあり、ランクが高いほど効果がよい。

これを追加する理由としては、元としてる「戦○ランス」は18禁ゲームで、国力やユニットの強化について、その部分に大きく依存している(18禁の部分がゲーム性に大きく貢献している)。これは18禁ゲームとしては当然すばらしい事なんだけど、18禁を作る気はないので、この部分を埋める「ゲーム性」が必要と考えた。

建物の情報を管理するオブジェクトを作成する。
まずはオブジェクト相関図から、エリア同様に建物の名前とか性能とかの普遍的データについては、CSVデータをテーブルにロードして参照する。
■オブジェクト相関図
オブジェクト相関図②


ランドデータクラスは、建物の種類とランクのみを持ち、それ以外の情報はテーブルクラスから参照する。レイヤに関しては、エリアの様に常に表示する物がないので必要ない。
建物の名前や値段を聞かれた時に、テーブルオブジェクトを参照して返す機能を作る。

大きく弄るのはエリアデータクラスの方になる、エリアデータを生成する際に、設定されてる情報を元に、ランドデータクラスを生成する機能の追加。そして、設定されている建物の情報をランドデータクラスから取得する機能を追加する。
つまり、エリアクラスに1個目の建物の名前を聞くと、エリアクラスが1個目のランドデータクラスから名前を聞くという形になる。

今日は仕事も忙しかったのでここまで、全くサクサクだな。
2009.01.07 / Top↑
いや、読み返してみたらサクサク作るとか書いてて2話も使ってた。
ブリーチみたいだな。

まあ、でも、大切ですよ。仕事やりながら作ると、脳内設計だけだと大変だから。
こんなメモ書きでも作っておくと思い出すのに凄く便利。
前にツール作って配布した時は結構便利だったんだよ?。

言い訳も終った所で、作り始める。
まずは、各エリアの色を表示するレイヤを作成する。KAGプラグインを使ってレイヤを使うと表と裏画面の制御が問題になる、これは下のサイトにある日付や金額を表示するレイヤを改造すればOK。
■TJSに挑戦!
http://www.geocities.jp/tjschallenger/index.html

まず、数字を表示する機能以外は、onCopyLayerとonExchangeForeBack以外は要らないので削除。
更に表示桁数と画像数、あとは重ね順と描画方法(半透明)などの設定を後から出来る様に改造すればOK。この辺はsetOptionsを弄るだけなので楽勝。
表示は「自分の土地」、「敵の土地」、「その他」なので、これを数字と入れ替えればいい。
■エリアの色画像
エリアカラーイメージ
「その他」、「自分の土地」「敵の土地」の順。
これなら「自分の土地」の色にしたい場合は、このレイヤに1を渡せばよいわけだ。


次に支配国旗の表示になるけど、これも同じ物を使用する。つまり、1番が自分の国で2番が敵の国とかね。
これだと10種類しか国を持てないのが難点だけど、国の数と考えれば十分だろう。
■支配国旗表示画像
支配国旗イメージ


上記2つのクラス(エリア色と支配国旗レイヤ)を内包する「エリアデータクラス」を更に上位の「マップデータクラス」でエリア数分作成すれば完成。
前回のオブジェクト相関図にある通り、表示位置などの基本情報はCSVファイルを読み込んだ「テーブルクラス」から参照する。当然、「エリアデータクラス」にはCSVを参照して位置や表示画像をレイヤに設定する機能も追加する。
■CSVデータ(エクセル)
CSVデータイメージ
ちと分かりにくいけど、今回使うのは「支配国」のみ、エリア01(左上)を自国(1)に、あとは全部敵国(2)に設定してる。


さあ、いよいよマップの表示。CSVデータでは、マップの初期色は全部「その他」に設定してある。
んで、下が元マップ画像。
■マップ画像
テストマップイメージ
相変わらず酷い絵だけど、茶色い所が地図で言う所の土地の部分ね。各マスが千葉県とかの都道府県を表してる。つまり、エリア数は20個だ。
この上に各エリアの色が出れば成功。(つまり全部真っ黒)

■実行結果①
実行結果1
おお、見事に真っ黒だ。
左上を自国に設定してるので、その色を自国色(みどり)に、さらにそれ以外を全部敵国(赤)に設定。

■実行結果②
実行結果2
よし、完璧。


今の所、初期設定以外では画像を変更出来ないけど、これは後回し。
次回からは土地情報をサクサク(笑)作っていく。

2009.01.06 / Top↑
9連休なんてしちまったから社会復帰できない、マジでだるいw。
だけど1日休むときっと永遠に完成しないので、サクサク作ってみる。

取り合えず、マップを表示するプログラムを作ってみようと思う。
それにはマップがどういう物か洗い出さないといけない。
①各地形(以降:エリア)にカーソルを合わせると建ってる建物の情報(以降:土地情報)
 が表示される。
②各エリアをクリックすると土地情報とそのエリアで選択できるイベントが表示される。
③各エリアは、プレイヤー国、敵対国、その他で色分けされる。
④各エリアには支配国旗が表示される。

■マップイメージ②
マップイメージ②


この内、①と②の制御はクリッカブルマップを使えば良いっぽいけど、表示する内容と、各
エリアの制御と色分けはTJSでプラグインを作る事になる。

吉里吉里では、TJSプラグインをKAGに登録して使用する、どんなプラグインが必要か
考えてみた。

■オブジェクト相関図
エリアオブジェクト相関図①
同業者が見たら、こいつ底辺だなと直感される資料だなw


まず、直接KAGスクリプトから呼ぶ、GameDataプラグイン、マップ関係を制御するMapData
クラス、各土地(エリア)を制御するエリアクラス、んで立ってる土地を管理するランドクラス
って形で作成。
その上で、初期設定とエリア名や表示位置なんかを参照する為のエリアテーブルプラグイン。

んで、エリアクラスはどんな物かと言うと、マップの色と支配国旗を表示するレイヤ、エリア
テーブルから情報を取得する機能と、その情報を元にレイヤに画像を表示する機能があれば
いける筈。

これを元に明日から作って行くか、果しえ何時完成するやら。
2009.01.06 / Top↑
前回はオブジェクト指向に驚いたが、まあ、その、なんだ。
仕事でも1回しか使ってないのよね。
一日かけて、吉里吉里とTJSのリファレンス読んで、いくつかの簡単なプログラムを作ったりして
実験してみた。下のサイトを参考にすれば何とかなりそう。うーん、前途多難。

■TJSに挑戦!
http://www.geocities.jp/tjschallenger/index.html

まずはどんなゲームを作るのかって事を決めようと思う。
作るゲームは戦略SLG。個人的には神ゲーと思ってる「戦●ランス」を元にしてみたい。
とりあえず、画面イメージから作成。

■画面イメージ
マップイメージ1


はっはっはっ、酷い絵だw

各土地にカーソルを合わせると土地情報が表示され、クリックすると土地のイベントが表示される。
んで、イベントをクリックして兵のパワーアップやら敵への進軍やらを行う。

・各土地には建物が建てられる。
・建物にはランク(レベル)がある。
・各建物に応じて収入やら国力が変わる。
・土地の色は、「自分の土地」、「敵の土地」、「その他」の3色に決定。

戦闘部分以外から作りこんでいく予定なんで、ここまでの決まりでサクサク作ってみる。
2009.01.05 / Top↑
同人ゲームを作ってみようと吉里吉里を始めました。
吉里吉里ってのは、ADV作成ツールっぽいソフトで、しかもプログラムを組んでゲームを
作る事も出来るらしい。
戦略SLGとかは少ない様なんで、ここらで試しに作ってみよう。

まあ、プログラムで飯食ってる訳だし、インタプリタ系のスクリプト言語なら楽勝でしょ。

そんな甘い考えで、吉里吉里をダウンロード、吉里吉里とTJSのリファレンスを読んでみた。

・・・・オブジェクト指向・・だと?!

■吉里吉里(きりきり)公式サイト
http://krkr.edolfzoku.com/link/official.html

2009.01.01 / Top↑