明日発売の「閃の軌跡Ⅱ」が届いた！

発売日が明日9/25の「閃の軌跡Ⅱ」が届きました！

なんか、急いで写真撮ったから
ちょっとボケ気味な上、
特典のオリジナルマイクロファイバークロスが
袋から出していないので
光源の関係で光ってしまっています。

ちなみに現在、
前作の２周目（引き継ぎ用データ作成としてプレイ中）は
これからラスボス戦に向かうところです。

ということで、クリアしたらそのままⅡが始められるという
素敵な展開です。

正直、東京から北海道への配送は発送日から１日開いて２日後となるので
発売日の２日前が祝日だったから、金曜日に届くと思っていました。

ファルコム通販で月曜日に発送してもらえていたようで
超ラッキーです。

このため、たぶん、「閃の軌跡Ⅱ」クリアまで、
「初音ミク冒険記」の制作が滞ると思います。

Jenkinsをバージョンアップしたら「おじさんの顔」が・・・

Jenkinsをバージョンアップしたら、
トップのJenkinsの文字のところが変わって
「おじさんの顔」が出てくるようになった。

さすがに、Jenkinsを起動するたびにみたい顔ではないので
画像を差し替えることにした。

変更前後のイメージは、こんな感じ

Jenkinsは、Tracと違って
ロゴの画像を差し替えるのが面倒だったりする。

JavaのWebアプリだからwarで固められていて
そこにある画像を表示することになっているようだ。

なので、warの中の画像を差し替えることでも変更はできる。
が、このやり方だと、次にバージョンアップしてwarを差し替えると
画像が元に戻ってしまう。

このため、Simple Theme Pluginというのを使う。

■インストール
「Jenkinsの管理」－「プラグインの管理」－「利用可能」の順に開いて、
「Simple Theme Plugin」を選択してインストールします。

■設定
「Jenkinsの管理」－「システムの設定」－「Theme」の順にたどって、
CSSとJSのURLを指定します。

自分のJenkins内で完結したい場合は、下記のフォルダーに置くと良いです。
{JENKINS-HOME}\userContent\

かげさんは、TracLightningに入っていたJenkinsを使っている。
このため、JENKINS-HOMEは、
C:\TracLight\projects\hudson\.hudson
となっている。

このフォルダをエクスプローラで開くと
既にuserContentというフォルダが存在する。

なのでここに、theme.jsを作って格納します。

document.addEventListener('DOMContentLoaded', function(){

    // 元々Jenkinsのおじさんの顔画像だった部分

    document.getElementsBySelector('[id="jenkins-head-icon"]')[0].src = 'http://localhost:8010/jenkins/userContent/HatsuneMikuBoukenki.png';

}, false);

URL of theme JSに指定するのは
http://localhost/jenkins/userContent/theme.js

これで
C:\TracLight\projects\hudson\.hudson\userContentフォルダに
HatsuneMikuBoukenki.pngを作れば良い。

なお、Jenkinsのヘッダ部分は、高さが40ピクセルなので
それに合わせておくと画像がはみ出たりせずに済む。

まぁ、CSSも設定してヘッダの40ピクセルってなっている部分の
高さを変更すれば良いのだが、今回は最小限の変更で済ませた。

Jenkinsの再起動中とかプラグインが効いていない段階では
相変わらず、「おじさんの顔」が幅を効かせてるんだが
そこは目をつぶることにした。
（トップ画面と違って、頻繁に見るわけでもないしね）

これで、Jenkinsを起動した時に「おじさんの顔」を見なくて済むぜぃ。

---

ちなみにJenkinsの設定を久々にいじった理由は、
これまでSVNにソースをコミットした時に
ステップ数をカウントしたり、
CppCheckやLuaスクリプトの文法チェックをしていたんだが
ステップ数をカウントする際に
初音ミク冒険記本体とLuaスクリプトしかカウントしていなかったので
C#で作っている開発ツール側もカウントするようにしたためだ。

ツールもいろいろと作ったが
現状、空行とコメント行を除いた実行ステップ数は約7,000で
マップクリエーターが2,100、線マップエディタが1,500と
マップ関連だけで半分を占めている。

次が、デバッグオプション設定ツールの1,100ステップくらいかな。

ちなみに、こないだ作った「サウンド系ソースの自動生成ツール」だと
600ステップくらいと、結構しょぼい。
最初に作った「公開支援ツール」とかは500ステップ未満だった。

このくらいのステップ数で済んでいるのは
やっぱり、500ステップほどの親フォームが良い仕事をしているためだと思う。

あるツールで共通化すると良いと感じた部分を
親フォームに持っていけば、次に別のツールを改造する時に
対象のメソッドとかが使えるので、コーディングの効率も良かったりする。

まぁ、コーディングの効率が上がっても
コーディングする気にならなければ、意味は無いんだが・・・

もっとLuaからゲーム本体の動作を変更できるようにする仕組み

結局、前回の3連休では
VC++ロジックをLuaに持っていくことを具体的に考える
というのが途中までで終わってしまった。

特に3連休の最終日は、
体調が悪くて一日中寝てたんじゃないかというくらい
起き上がれなかった・・・

さすがに今週末のうちには、やっつけてしまいたい。

ということで、具体的に考えるのの続きから。

---

まずは、おさらいとして
現在、VC++側で「マップごとにやっていること」を書き出してみる。

・マップの初期処理
・マップのオープニング
・マップレイヤー１の描画
・マップレイヤー２の描画
・マップレイヤー３の描画
・マップレイヤー４の描画
・マップレイヤー５の描画
・ミクの描画より奥に描画するイベント（★）
・ミクの描画より手前に描画するイベント（★）
・敵の描画
・マップのクリア判定
・マップのエンディング

さらにボスマップでは
・ボスに勝った後のイベント

それからイベントでプレイヤーが操作していないのにミクがに動く時に
・イベントからのキー入力の受け取り（★）

といったことをやっている。

現時点でもLua側で処理しているのが（★）の部分だ。

---

この中には絶対にVC++側でやらないとイケないことってのは存在しない。

強いて挙げるとするなら、処理速度が求められそうな描画系の処理だろう。
マップや敵の描画といったあたりだ。

しかし、マップの作成中は、お試しでマップチップを配置したりしてみたい。
というか、既にマップクリエーターのロジックで
マップチップをLuaから描画する仕組みができている。

次に「敵の描画処理」だが
実際には「敵の描画処理」では、敵の思考ルーチンというか
敵の動きのコーディングもしているのだが
敵の動きってのは、微調整が必要になる部分なので
調整の都度、VC++側をリコンパイルというのは、
コンパイルの待ち時間が発生してしまうので開発の流れとしては良くない。

ということで、マップごとにVC++でやっていることは
全部Luaからもできるようにしたい。

これまでのLuaの呼び出しの流れは
マップごとの関数からLuaの該当処理を行う関数を呼び出す流れだった。

この流れで行くと、既存の２０＋αのマップ数分、これらの対応が必要になる。

力作業として、ゴリ書きしていくという作戦もあるが
基本的に、かげさんは面倒臭いことはイヤだと思う性格である。

労力が少なく、やりたいことをやりたい。

なので、もうちょっと考えてみる。

---

各マップのVC++から呼び出されるLuaの関数名は
mapXX_YYZZ
といった名前になっている。

XX：ステージ番号
YY：ステージ毎のマップ番号
ZZ：Lua関数を呼び出すVC++の各マップソースの関数のイベント名

例えば、
ステージ　　　　　　　：02　ボカロタウン
マップ番号　　　　　　：04　ルネッタ・キーア
VC++側の呼び出し関数　：checkMap02_04EventBehind
Lua で呼び出される関数：Map02_04EventBehind
といった具合だ。

「ステージ番号」と「ステージ毎のマップ番号」は、
VC++側のグローバル変数なので、どこからでも参照できる。

各マップのVC++側の関数は、VC++側で関数ポインタとして設定していて
initMapという関数で、以下のような処理がある。

checkMapEventBehind = checkMap02_04EventBehind;

ちなみに別のマップでも

checkMapEventBehind = checkMap02_05EventBehind;

といったコーディングをしている。

これは、どういうことかというと
checkMapEventBehind();と記載した時に
ステージ　　　　　　　：02　ボカロタウン
マップ番号　　　　　　：04　ルネッタ・キーア
であれば、checkMap02_04EventBehindが呼び出され
ステージ　　　　　　　：02　ボカロタウン
マップ番号　　　　　　：05　食わねーわよ
であれば、checkMap02_05EventBehindが呼び出される
という仕組みである。

オブジェクト指向プログラミングでいうところの
多態性に相当することを
言語仕様的にオブジェクト指向プログラミングが
できないがなかった頃のC言語では、
この関数ポインタを使って行っていたわけだ。

checkMap02_04EventBehindからは、LuaのMap02_04EventBehindが呼び出され
checkMap02_05EventBehindからは、LuaのMap02_05EventBehindが呼び出される。

つまりVC++でマップごとの関数の呼び出す箇所で
同じようにLuaの関数を呼び出せればOKだ。

上の例だと「EventBehind」という部分が分かれば
他はグローバル変数なので文字列操作でLuaの関数名が決定できる。

---

さて、このやり方だと、
「（２０＋α）のマップ数」×「（★）となっていない１１のマップごとの関数」箇所の
Lua関数を呼び出す修正が、「（★）となっていない１１のマップごとの関数」箇所だけで
済むようになるものの、
今度は、呼び出すLua側の関数をが無いと怒られる事になる。

ちなみに「マップの初期処理」と「マップのオープニング」以外は、
ゲームのメインループから呼び出されるので、
60FPSだと１秒間に60回ずつ呼び出される。

つまり、1秒間に11×60回、Lua関数が呼び出せないと怒られることになる。

1度怒られれば、呼び出せないことは分かるので
せめて１つのマップで「呼び出せない！」と怒られるのは11回で済ませたい。

このため、11個の呼び出しチェック用のグローバル変数を用意し、
マップが切り替わるinitMapの処理で、初期化して
呼び出しチェック用変数が初期値の場合、
Lua関数の呼び出しを試みて、呼び出せなかったら、呼び出し不要と値を変更、
呼び出せたら、呼び出し可能の値にする。

メインループでは、呼び出し可能な場合に、Lua関数を呼び出すことにする。
こうすることで、Luaに呼びだそうとしている関数が存在する場合だけ
呼び出されるようになる。

最終的に、必要なときだけLua側で関数を作って、処理を書くことで
初音ミク冒険記の本体側の動きを変更できるようになるって作戦だ。

---

ここまでできたら、各マップのVC++側のソースをLua側に持っていけるようになる。

おそらく、各マップの初期処理の一部と既存のマップ描画処理、
パズルエリアのギミックなど、Luaに持って行きづらい部分を除いて、
大部分がLuaに持っていけると思う。

とりあえず、昼ご飯を食べたら、Lua呼び出しする流れを作ってみよう。

マップを増やす前にやっておく方が良いこと

さて、今回もグダグダ考えていることを
記事にしようと思う。

線マップエディタもサウンド系ソースの自動生成ツールもできたので
そろそろマップを増やしたい。

というか、前回の公開からこれだけ期間が空いているので
マップを増やしてから公開したい、って気持ちはある。

あるんだけど、
マップが増えてから着手すると手戻りが多くなりそうなところを
先にやっつけた方が、結果的に作業が進めやすくなる。

ただ、この作業、実は相当前から構想は練っていたものの
面倒くさくて、ずぅーっと放置していたことだったりする。

やろうとしているのは、「依存性の注入」みたいなこと。

Wikipediaから引用すると

依存性の注入（いそんせいのちゅうにゅう、英: Dependency injection）とは、コンポーネント間の依存関係をプログラムのソースコードから排除し、外部の設定ファイルなどで注入できるようにするソフトウェアパターンである。英語の頭文字からDIと略される。

言葉で書くと難しそうだけど、
要するに依存関係のあるコードを、プログラムから減らして
「外部から与える情報（注入するもの）」で動作を変えるということ。

初音ミク冒険記で例を示すと
マップが切り替わった際に
敵やブレイクオブジェクトを配置するという処理で
この考え方を適用できそうってこと。

現在、VC++のマップ毎のソースにある初期処理には
敵やブレイクオブジェクトを配置する処理がある。

つまり、「マップ毎の初期処理」と
「敵やブレイクオブジェクトを配置する処理」には依存関係がある。

敵やブレイクオブジェクトの配置を変更するには
VC++のソースの変更が必要で
ソースを変更するってことは、動作確認のためにビルドが必要ということ。

これを敵やブレイクオブジェクトの配置を外部から与えるようにすることで
VC++のソースを修正しないで、プログラムの動きを変えちゃおう、って考え。

初音ミク冒険記だと、ミクとマップの当たり判定で使う線は、
mapフォルダのmapXX_YY.datというファイルに外出しされていて
このファイルを作るツールが、前に作ってた線マップエディタ。

敵の座標とかブレイクオブジェクトの座標は、
マップの難易度を上げるために敵を増やしたり、
逆に難易度を下げるために敵を減らす、
マップが単調になるのを防ぐためにブレイクオブジェクトを配置するなど
最終的には、いろいろと調整が必要になると思っている。

調整のたびにVC++でビルドするのは、面倒なので
外部のファイルから配置するようにしたい。

この仕組みができると、Astlibraの敵配置ツールみたいに
敵の配置をマップエディタから行えるようになる。

なので、マップ毎に
敵やブレイクオブジェクトを配置するデータを作る必要がある。

実は、VC++のマップ毎のソースには、別の依存関係もある。
それがLuaスクリプトで
VC++のマップソース１つにつき、必ず対応するLuaスクリプトが存在する。

現時点でも初音ミク冒険記の宝箱の配置は、
Luaからできるようになっていて
map00_1.luaには、以下の記述がある。

local iRet = openTakaraBako(460, 200, 0, DIRECTION_RIGHT, "クッション・ブーツ", 2, 3);

460, 200, 0というのがそれぞれX座標、Y座標、Z座標となっている。
（初音ミク冒険記は２Dゲームだけど、
　ゲーム内のオブジェクトは内部的には３Ｄ座標で管理している）

試しにクッションブーツの宝箱の近くでセーブして
map00_1.luaの上記の箇所の200の値を250とか150とかにしてから
セーブしたデータをロードすると、宝箱の位置が変わることを確認できるし
DIRECTION_RIGHTをDIRECTION_LEFTにすると宝箱の向きが変わる。

”クッション・ブーツ”の文字を変えると宝箱を開けた時に
”○○を手に入れた”の○○の部分の文字が変わる。
最後の2は、宝箱を開けたことを示すイベントフラグで、
3は、宝箱を開けた後に続けて行う次のイベントフラグの番号だったりする。
（イベントフラグの番号の意味は、公開しているExcelのドキュメントで確認できる）

Luaスクリプトは、当たり判定で使う線マップと同じく
マップを切り替える、もしくは、
セーブデータをロードすると再読込するので
ビルドの作業もいらず、初音ミク冒険記を起動したまま
調整ができるので、お手軽なのだ。

敵やブレイクオブジェクトも、宝箱に合わせて
Luaから配置できるようにした方が
無駄にファイルも増えずに済むだろう。

さらに、各マップの切り替わりとか、
マップ切り替わり直後のBGMの切り替えもVC++でやっているので
本当は、これらの変更時もLuaから行った方が、
VC++のビルド回数を減らすことができるって寸法だ。

ここで、現時点のマップ数を確認してみよう。
・プロローグ：2マップ
・試練の洞窟：9マップ
・ボカロタウン（第2章）：7マップ
・ウータウの森（公開しているもの）：2マップ
ということで、4つのステージで既に20マップある。

実際にはウータウの森で未公開のマップも既にいくつかあるので
もう少し多いんだけどね。

ここで線マップエディタができたから、
ってことで、ガンガンとマップを増やしていき
その後、VC++からLuaに外出しすると
単純に作業の物量が増えてしまう・・・

つまり、20＋α程度の数のうちにやってしまった方が
将来的には楽ができるってこと。

これから作るマップだけでイイじゃん！

と思うかもしれないけど、マップごとに作りが異なると
何かメンテナンスする時にも
複数パターン分の作業をすることになるので
できれば同じ作りにして1パターンだけ考えれば済むようにしておきたい。

じゃあ、なんで宝箱の配置はLuaで、
敵やブレイクオブジェクトはVC++なんだという話もある。

もともとは、宝箱の配置もC側だった。
それが、宝箱の位置、向き、イベントフラグの調整とかやってて
イベントフラグは、シナリオ進行に関わるからシナリオじゃん！
となり、ここだけ先にLuaに行ってしまったという経緯がある。

今考えると敵はともかく、ブレイクオブジェクトについては
最初からLuaに持って行っても良かったかもしれない。

現状のソースの行数は、トータルで78,595行
内訳が
VC++（ヘッダファイル含む）：58,770行
Luaスクリプト：19,825行
なので、既に25％くらいがLuaになっている計算だ。

といってもトータルの行数の内、8500行近くは、何も書いていない空行で
コメントだけの行も27,000行くらいあるんで
実際に動く行数は、43,000行くらいになる。
C#のツールは、ステップカウンタを導入していないから分からないけど
トータルすると、結構な行数を書いているのかもしれない。

話がそれた。
元に戻そう。

将来的には、敵のAI部分もLuaに持って行く構想もあるんで、
早めに手を打っておきたい。

つーことで、この３連休で
VC++ロジックをLuaに持っていくことを具体的に考えて
試しにいくつかのマップに導入しようと思う。

そして今月中にこの辺りをやっつける方針としよう。

多分、この作業に専念すれば、今回の３連休でこなせるレベル。

ただ、閃の軌跡Ⅱに向けて引き継ぎデータを用意するって
ミッションがあるんで、これだけに専念もできないので
一応、必達目標で今月いっぱいとしておこうって話です。

サウンド系ソースを自動生成するツール３

サウンド系のソースを自動生成するツールが
Luaのグローバル変数定義も含めて完成！

BGMの設定画面

ＳＥ（効果音）の設定画面

どちらの画面もmp3とwavのファイルをドラッグ＆ドロップで指定可能。

必要事項を入力して右下の「サウンド関連ソース一括生成」ボタンを押下すると
ＢＧＭリストやＳＥリストの内容に従い、
初音ミク冒険記のサウンド関連のVC++ソース一式を自動生成してくれる。

その後に初音ミク冒険記本体側をビルドすれば
Luaスクリプトからも、BGMリストやSEリストにある
BGM定数名やSE定数名が使えるようになる。

このツールを作るに当たり
VC++側のソースの構成も若干変わった。
（ソースが増えた）

ソース出力後の自動ビルドも考えたんだけど
SVNへのソースのコミットも必要になりそうなので
今回は見送った。

自動ビルドはJenkinsでやらせても良いかもしれない。

さて、次はどうしたものかな？

今回のソース生成の動作確認で
久々に初音ミク冒険記の通しプレイをして
BGMやSEでおかしなところがないか確認したんだけど
このところ、閃の軌跡の２周目をやっているせいか
ゲーム内のちょっとした表現方法などで
気になるところが出てきた。

それをやるか、今回のサウンド関連みたいに
ゲーム全体に影響が及びそうなところを
マップが増える前に着手するのも良いかな？

サウンド系ソースを自動生成するツール２

一応、予定していた部分が大体できたと思う。

ちょっとLua関連のソース周りの整理が必要そうなので
その辺りの調整は、週末に行う予定。

ちなみにサウンド系の開発ツールのくせに
登録した音楽ファイルを再生する機能は存在しない

これは、初音ミク冒険記のソースの中で
音楽ファイルのファイル名に拡張子を含んでいないためだ。

なんで、そうなっているのかというと
PSP版を作っていた時に、
DXライブラリPortableがmp3にしか対応していなかったので
音楽ファイルならmp3と拡張子が確定していたことに起因する。

その後、DadrfyさんがDXPを改造してWavにも対応してくれたので
初音ミク冒険記では、ファイル名にmp3かwavを付与して
ファイル存在チェックをした後、再生する仕組みになっている。

実は、関係でmp3のファイルがなかったらwavファイルを探す
という２段構えになっていて、拡張子指定で音楽ファイルを指定する
関数を内部で作っていたりする。

この影響は、Luaスクリプト側で音楽ファイルを鳴らすときにも影響があるので
将来的には、音楽ファイルは拡張子付きで持つようにして
この辺りの処理をシンプル化したいんだよねぇ・・・

音周りでは、他にもBGMのクロスフェードとか
バックグラウンドサウンド・エフェクトとかも入れたいと考えていて
ウータウの森で鳥の鳴き声が聞こえるとか、
川が近いと水音が近づいてくるといったこともやってみたい。

という感じで、やりたいことはいっぱいあるし
制作を諦める気は全くないんだが
既に半年近く新しい公開が滞っているわけで・・・

主に開発ツールを作っていることもあって
ゲーム本編の制作は、足踏み状態だ。

うーむ。