＞＞＞　SphereEngineSDKのダウンロード　＜＜＜
SphereScriptのマニュアル

INFORMATION

2015-02-22: 第15回を公開しました。
2015-02-04: 第14回を公開しました。
2015-01-11: 第13回を公開しました。
2014-12-26: 第12回を公開しました。
2014-12-14: 第11回を公開しました。
2014-12-03: 第10回を公開しました。
2014-11-18: 第9回を公開しました。
2014-11-10: 第8回を公開しました。
2014-11-01: 第7回を公開しました。
2014-10-29: 第6回を公開しました。
2014-10-19: 第5回を公開しました。
2014-10-07: 第4回を公開しました。
2014-10-03: 第3回を公開しました。
2014-09-27: 第2回を公開しました。
2014-09-13: 第1回を公開しました。
2014-09-08: このページを新規公開いたしました。

第0回：緊急招集
第1回：実行方法
第2回：建物設置
第3回：ユニット設置
第4回：スクリプト入力
第5回：スクリプト解説
第6回：イベント解説
第7回：複数スクリプトの統合
第8回：プロジェクト企画
第9回：概要設計
第10回：組み立て
第11回：ユニット追加
第12回：大地創造
第13回：デバッグ
第14回：パッケージング
第15回：製造

第0回：緊急招集

姉さん、こんなところに集まって、どうしたの？

2人とも、いきなりで悪いけど、仕事の話よ。

仕事ってなんだ？滑走路は直ったが、格納庫がまだ満足に使えんから、請けられる仕事にも限度があるぞ。ミサイルが載らん。

仕事と言っても、エレアではないわ。頼まれたのは私よ。なんでも、SphereEngineを使って電プロさんがゲームを作るから、その内容の解説をしてほしい、という依頼なのよ。

そんなこと自分でやればいいのに。どうせ書く内容なんて変わんないんだし。

単純に説明を書くよりも、こういう会話形式にしたほうが、読者が取っ付きやすいと考えたそうよ。私はこういうのは冗長で好きではないのだけれど。

俺たちは解説などできんが、帰っていいのか？

それだと私が一人で話をしているだけになってしまうでしょう？私が解説をして、2人がそれを聞く、というやり方で進めてさせてもらうわ。

なるほど。リサが先生役、俺たちが生徒役、そういう芝居をうて、ということだな。

私そういうの一番苦手なんだけど…。細かいところは、ノブ爺お願いね。

それでも構わないわ。でも、肝心の解説するコンテンツがまだ出来てないそうなので、今日は今回の仕事の説明だけよ。来週くらいには次の講義が出来るようになると思うわ。それと、次回の講座の前には、SphereEngineSDKのインストールをしておいてほしいのよ。きっと講義の度に更新すると思うけれど、手間かけさせてごめんなさいね。

オッケ～。このページの一番上からダウンロードしておけばいいんだね。

第1回：実行方法

2人とも、揃ったかしら。それでは始めさせてもらうわ。そうね、まず最初は……。

あー、あれだろ。企画書とか書くんだろ。どういうストーリーにするとか。

私、それ書きたい、書きたい。

ちょっと落ち着いて。最初に企画書、というのは間違いではないのだけど、まずはツールとしての操作方法や、出来ること、出来ないことを確認するほうが先よ。それとノブユキさん、企画書はストーリーを書くものではないんです。

そうなのか？まぁ確かに、道具の使い方を先に確認するのは機械整備と同じだが。

エレア、とりあえず始めたいから、まずはツールを起動して頂戴。SphereEngine起動設定のダイアログでEditSample_edit.rspを選んで起動して欲しいの。

オッケ～。

あ、なんかマス目みたいなのが出てきた。

そのグリッドについては後で説明するわ。これはマップ上のカメラから撮影した映像よ。まだ何も無いから真っ黒ね。まずはこのカメラを動かしてもて欲しいのよ。左ドラッグで平行移動、右ドラッグでカーソル位置を中心にして回転。って、文章で説明するよりも実際に触ってもらったほうが早いと思うわ。マウスのホイールを回転させるとカメラが上下に移動するわ。回転に関しては、カーソルが触れている場所を中心にして回るから、注意してね。

ところでリサ、回転させたい方向と反対方向にカメラが回ってしまうんだが。

そういう場合はメニューバーの「カメラモード」→「上下の回転方向を反転」をONにしてください。

それと、その下の「カメラをリセットする」を使うと最初の状態に戻るので便利よ。ちなみにこの操作なのだけれど、現行のSpE4.exeの不具合でチェックが逆になっているみたいで、この不具合を修正した最新版へバージョンへ更新しておくようにお願いしているんです。事前にこのページの最初のリンクから最新版のSDKを取得しておけば大丈夫のはずよ。

姉さん、この真っ黒い画面を次はどうするの？

そうね、少し見た目に変化をつけましょうか。メニューバーの「ファイル」→「地形ファイルを開く」から"EditSample\Script\Sample.map"というファイルを選んで開いてみて。

あ、なんか緑色。森かな。

カメラを動かしてみたらどうだ。

島だ。工場みたいな建物も見える。あ、これってSDKのサンプルミッションに出てきた島と同じだ。

なんか表示がチラついてないか？

海の画像と、グリッドの画像が重なってしまっているのね。このグリッドについて説明するわね。このグリッド、というか板を「ターゲットレイヤー」と呼ぶのよ。Shiftキーを押しながらマウスのホイールを回すことで、この板を上下させられるのよ。やってみて。

島が沈んでいった。反対に動かすと、海が見えてきたね。

なんとなく水に見えないことも無いけれど、この板はただの操作用の表示に過ぎないわ。実際にはターゲットレイヤーの方が上下に移動しているだけよ。地表や水面を操作するだけならばこのターゲットレイヤーを無理に使う必要は無いのだけれども、今後説明するユニット・建物・パスの編集を空中に対して行う場合、この板を編集したい高さに移動させておく必要があるわ。

え？？？

マウスカーソルだけだと2次元だが、高さ方向の位置を指示するのにこの板が要る、という理解で合ってるか？

その通り、さすがノブユキさんね。いつも使ってるCADで慣れているからかしら、理解が早くて助かるわ。

わー、なんか建物をクリックしたら光りだした。なにこれ？

あーもう、勝手に操作しないで。マップの編集モードが動作してしまったのよ。とりあえずESCキーを押してキャンセルして頂戴。このままマップの編集を進めてもいいのだけれど、このまま先にユニットやスクリプトも読み込んでしまいましょう。先ほどと同様に「ファイル」→「ユニット配置ファイルを開く」から"EditSample\Script\Mission01.plc"というファイルを選んで開いてみて。

ブイだね。確かこれ、サンプルミッションの最初のところだ。

これは戦場の敵や味方のユニットを表しているわ。カメラを回してみたら。ブイのほかにも一つ、空中に何かがあるわよ。

あった。YOUって書いてある。近づいてみよう。R-10だ。

例のサンプルミッションは自機がR-10だったから、これはプレイヤーを表しているのか。

厳密には少し違うけれど、大体そんなところね。

なら、これを動かせば、戦場に現れた時の位置が変わるんだな。エレア、やってみろ。

ノブユキさん、少し待って。まだ移動の手順を説明していないんです。編集の話をする前に、まずはこれを「実行」してみようと思うの。先に目的のものを示してしまったほうが早いと思うから。

実行？いきなり何の話？

ちょっと概念的な話になってしまうのだけれど、SphereEngineの戦闘シーンはマップとユニット、それを動かすためのスクリプト、この組み合わせで出来ているの。そしてこのスクリプトの処理を始めることで、全ての出来事を制御しているのよ。詳しくは後から説明するけれど、スクリプトは「ユニット配置ファイル」に含まれているから、すでに読み込み済みよ。

「プログラムとデータ構造」って話だな。

あら、ノブユキさん、ずいぶん難しい言葉を知っているのですね。

あー、実はな、ちょっと予習してた。

まぁ、何にしても、このスクリプトを「実行」すると、このミッションが始まる、という仕組みよ。エレア、メニューバーの「デバッグ」→「スクリプト実行」を選んで頂戴。今後は何度も何度も使うことになるから、F5キーにショートカットを割り当てておいたから、それを使ってもいいわよ。

なんか、「保存しますか？」みたいなダイアログが出たけど、どうするの？

さっきエレアが建物を選択して、きっと移動しまったからでしょう。とりあえず「いいえ」でいいわ。そして次の「デバッグ実行しますか？」で「はい」を選べば動き始めるわよ。

飛んでるシーンが始まった。

うまく動いたようね。目標を全部破壊するかPauseをするかして、Exitを選べば編集中の画面に戻るわよ。先ほどのファイルとは変えて、今度は「ユニット配置ファイルを開く」から"EditSample\Script\Mission02.plc"を読み込んでみて。

読み込んだよ。今度はR-10が4機いるね。

そうね。そのまま今度はF5キーを押してみて。これでも実行できるわよ。

あ、今度はサンプルの２つめのミッション内容だ。

そう、こうやって、マップやユニットのデータを読み込んで、編集して保存して、動作させる。これを繰り返してSphereEngineでゲームを作っていくのよ。具体的な内容は次回以降に説明することにさせてもらうわね。

第2回：建物設置

今日は地形（マップ）の作り方を説明するわね。前回話したように、SphereEngineのミッションは、地形ファイルと敵配置ファイルの二つの組み合わせで出来ているわ。このうち、地形ファイルでは、地面と建物のモデルの置き方を記録しているの。説明するから、まずはSpE4を起動して、前回同様にEditSample_edit.rspを選びなさい。

前回と同じマス目の画面だね。

「ターゲットレイヤー」だな。

全く何もないこの状態から作ることも出来るけれど、何か基準になるものがあったほうが、作業がやりやすいと思うの。そこで「海だけ」の地形ファイルが用意してあるから、それを使いましょう。メニューバーの「ファイル」→「地形ファイルを開く」から"EditSample\Script\Sea.map"を開いて。それと、こういう風に操作を詳しく説明するのは今だけだから、地形ファイルに限らず、メニューバーの操作内容把握しておきなさい。

今日のは島がないね。海しかないけど、これでいいのね？

ここに島やビルを置いていくんだな。ターゲットレイヤーが重なって少し見づらいから、下に下げてしまえ。Shift＋ホイール回転だ。

本当は、島のモデルを作ってデータ登録する、というところから始めてもいいのだけれど、地形データの仕組みを理解していることが前提になるから、最初は配置するところから始めさせてもらうわ。島はともかく、建物は沢山種類があるから、とりあえず不足することは無いと思うわ。

それならば、まずは島を置こう。

そうね、1種類しかないから簡単よ。エディタを起動したときに、ダイアログがもう一つあったでしょう？そちらを使って作業を進めていくの。順番に手順を説明するわね。まず、このダイアログの上部の「MapEditor」を選んで。

あ、高層オフィスって表示が出てきたよ。

そのリストボックスを一番下まで動かして頂戴。

なんか途中にも色々あるな。VMIの本社ビルとかも使えるのか？

建物を置く前にまずは地面が必要ね。「サンプル島」という項目を選んで、そのままメインウィンドウのほうにカーソルを持っていってみて。

緑色の何かが点滅しとるな。

適当なところで左クリックよ。そのままだと表示がちらついて説明がしにくいから、一旦ESCキーを押してね。

ここに島を置いたってこと？

カメラを動かして見たらどうだ？確か右ドラッグで、見る向きが変わるだろう。

海の上に島が出来たね。次はどうするの？建物を置けばいいの？

山の緑の上に立ててもいいのだけれど、市街地の地面があった方が分かりやすいでしょう？さっきと同じようにして「サンプルフロート」というものを選んでから、好きな場所においてみなさい。そうそう、山の上に置かないように注意してね。マウスカーソルが示している場所を中心にして置くような仕様よ。

出来たよ。なんだか最初に見た島の風景に似てきたね。

そうね。サンプルミッションのマップが化学プラントのようなつくりだったから、今度はオフィス街にしてみようかしら。それほど広い敷地ではないから、「低層オフィス」という名前の建物を選ぶといいわ。

並べてみたよ。

おいおい、向きがずれとるぞ。きちんと道路にあわせないとだめだ。

置いた後の向きを変えることも出来るけれど、置く時に揃えてしまうほうが簡単よ。カメラの向きにあわせて置かれるから、たとえば道路と向きをそろえたいならば、道路と同じ向きにカメラを回転させるといいわよ。ある程度高いところから下を見下ろすようにカメラを回転させておくのがコツよ。

やり直すにはどうするの？

建物は右クリックで消せるわ。このとき、ダイアログで「MapEditor」を選んでいることが条件よ。画面左上に「地形編集モード」と表示されるから参考になるわね。他には、左クリックして建物を選択状態にしてから、DELキーを押しても消えるわよ。他にも、方向キーやドラッグの操作も出来るけれど、まとめるとこうなるわね。

左クリック：建物を選択
Ctrl+左クリック：追加的に建物を選択（「島」などの大地モデルの選択も可能）
Ctrl+左ドラッグ：範囲指定により追加的に建物を選択
右クリック：建物を削除
DELキー：選択中の建物を削除
ESCキー：建物の選択を解除
方向キー：選択中の建物を前後左右に移動
PageUp/PageDownキー：選択中の建物を上下に移動
左ドラッグ：選択中の建物を移動
Shiftキー＋ホイール回転：選択中の建物の方位を回転
Tabキー：選択中の建物を５ｍ単位の位置にそろえる／（非選択時はカメラの角度を5°単位で切りの良い角度にあわせる）
Ctrl+Z：ひとつ前に戻る（Undo）
Ctrl+Y：ひとつ次に進む（Redo）
ダイアログボックスの「適用」ボタン：テキストボックスに入力した内容に従い、選択中の建物の種類・位置・角度を変更

結構色々あるんだな。いきなり全部覚えるのは大変だから、少しずつ試していけばいいな。エレア、続きをやるぞ。建物が1種類だけだと不自然だから、いくつか種類を変えてみたほうがいいんじゃないか？

こうだね。だいぶ街っぽくなった。

ではこれを保存しましょう。Ctrl+Sキーでそのまま上書き保存できるけれども、もともとのファイルはsea.mapという元のデータだったから、これをそのまま上書きしてはいけないわ。メニューバーの「ファイル」→「地形ファイルを保存」を選んで、好きなファイル名を指定してね。後でこの地形ファイルを使うから、わかりやすい名前にしてね。とりあえずここでは"Island.map"としておきましょう。

ところで、こうやって一つ一つ置いていくのか？たとえば第3テラストラクチャだけでも、数え切れないくらい建物があるが、これを全部置いてたら、日が暮れるどころか、正月を迎えてしまうぞ。

良いところに気づいたようね。そのための方法はきちんと用意されているわ。先ほどのダイアログのModelリストボックスから建物を選ぶとき、Ctrlキーを押しながら選ぶことで、複数の建物が同時に選べるようになっているのよ。ためしにやってみてもらえるかしら。

こんな感じ？

そうよ。次にその状態のまま、メインウィンドウに移って、Shiftキーを押しながら地面を左ドラッグするの。今ある敷地だと狭いから、とりあえずは海の上を適当にドラッグしてみて。

青い光みたいなのが表示されとるな。

Shiftキーを離さないで、そのままマウスの左ボタンを離すと、同時に建物が沢山配置されるわよ。このとき、リストボックスの中から選択された建物がランダムで配置されて、方向も90度単位でランダムで配置されるから、道路や区画にあわせてドラッグすれば簡単に市街地が作れるわよ。

なるほど。高層オフィスをいくつか選んでおけば、オフィス街ができるし、マンションをえらべば団地が出来る、という仕組みか。

ダイアログの右のほうに「Coverage 40%」とかいう項目があるのは何？

これはいわゆる「建蔽率」ね。簡単に言うと、どれくらい建物が密集しているかを示す値ね。実際にこのパーセンテージに一致するわけではないけれど、大体の傾向は調整できるわ。高層オフィスやマンションならば30%程度、低層建造物ならば50%、工業団地だと80%くらいに設定すると、自然に見えるようになるわね。ただし、あまり建物を多く置きすぎると、PCの処理能力次第では動作が遅くなってしまうから、広大な市街地を作るときは注意が必要ね。第3テラストラクチャに公園や湖が多いのも、そういうことが理由の一つだそうよ。ConnctionPoitというのは、高速道路を並べるときに、端と端をつなげるかどうかを決める項目ね。通常はONでいいと思うわ。ScaleValiationは建物をまとめて置くときに、高さや幅をある程度ランダムに変形させて置く機能よ。RaidersSphere3rdまでの街ではこの機能を使っていたけど、今回からは建物の種類が増えたから使わなくなった、と聞いているわ。

沢山置いたら、水没都市みたいになった。

確か、AceCombat4でもそういう演出があったわね。まぁ、こんな風にして、建物を置いていけば、いくらでも広い市街地を作れる、という仕組みよ。こうやって先に地形ファイルを作っておいて、あとから、呼び出して使う、と言うのが基本的な仕組みね。市街地の地面のモデルもサンプル一つだけでなくて、RaidersSphere4thで使われているデータを登録してから呼び出す方法もあるし、地形ファイルの名前さえ分かっていれば自分が作ったマップでなくても使えるはずだから、たとえば各テラストラクチャや、グランホールのような地形も全部使えるわよ。このあたりの発展的な使い方はまた別の機会にしましょう。次回はいよいよ敵配置ファイルの編集ね。だんだんゲームっぽくなってくるから期待していてね。

なんか姉さんの「期待していてね☆」って言い方、かえって不安を感じるなぁ……。

確かに……な。俺たち、ついて行けるといいな。

何よ、それ。マウスだけで操作できる今のうちがまだ簡単なほうよ。RaidersSphere3rdまでは本当に大変だったんだから。

第3回：ユニット設置

前回はマップを作ったので、今日はこの上にユニットを置いていきましょう。ここで言うユニットとは、自機や敵機、ターゲットや、その他イベントなどで制御するキャラクター全般のことよ。何も無いところにユニットを置くことは出来ないから、まずは前回作った地形ファイル"Island.map"を読み込んでおきましょう。

読み込んだよ。

ではノブユキさん、ここを防衛するならば、何を置くと良いかしら？

えーっと、それなら……、トーチカ砲かな。あれなら、射程も長いし装甲も硬いから、敵機をけん制するには便利だ。

意味無いよあれ。水面スレスレを飛んで行って、対地ミサイルを2発くらい撃ち込めば壊せちゃうし。

う～ん、それなら、2つのトーチカを前後に並べてやる。前の砲台が障害物になって、後ろの砲台には弾が当たらん。ついでに横には対空ミサイルも配備するぞ。さすがのエレアもこれなら簡単には破壊できんだろ。

うわ、前後に2つって、やだなぁ、それ。

横から攻めれば、障害物にはならないと思うけれど……。まぁとりあえずは今の話で決まりね。では置いていくことにしましょう。前回、マップを作ったときの手順から、ある程度は想像出来ると思うけれど、まずは編集ダイアログの「UnitEditor」を選ぶのよ。

これでいい？

大体のところは前回と同じか。この中から選ぶんだな。トーチカ砲はどれだ？

あれ？無いね。

「トーチカ砲」ではなく「対空砲台」という名称で登録されているようね。それを選んだら、一旦その状態で次の説明を聞いて欲しいの。

砲台は……っと、あった。で、この次は？

ユニットを置く前にその属性を決める必要があるわ。ここで言う属性というのは、例えば敵なのか味方なのか、ターゲットか否か、そのユニットの名称や配置に使うグループなど、色々あるのよ。細かい説明は順次していくけれど、まずはこの画像と同じように設定できるかしら？

できたよ。

次に、メインウィンドウに移って、置きたい場所に置いてみなさい。これで設置完了よ。

エレア、さっき話したみたいに、前後に2つ並べてくれ。

こんな感じかな？

あれ？向きが反対だよ。海側に砲塔を向けるにはどうするの？

建物と同じ考え方よ。カメラの正面の向きと同じ向きに配置されるから、カメラを回転させて、海の方向を向いてから、もう一度置くといいわ。そうそう、消したいユニットは右クリックで消せるわよ。建物と同じように、方向キーやドラッグアンドドロップも使えるわよ。まとめると、こうなるわね。

左クリック：ユニットを選択
Ctrl+左クリック：追加的にユニットを選択
Ctrl+左ドラッグ：範囲指定により追加的にユニットを選択
右クリック：ユニットを削除
DELキー：選択中のユニットを削除
ESCキー：ユニットの選択を解除
方向キー：選択中のユニットを前後左右に移動
PageUp/PageDownキー：選択中のユニットを上下に移動
左ドラッグ：選択中のユニットを移動
Shiftキー＋ホイール回転：選択中のユニットの方位を回転
Tabキー：選択中のユニットを５ｍ単位の位置にそろえる
Ctrl+Z：ひとつ前に戻る（Undo）
Ctrl+Y：ひとつ次に進む（Redo）
ダイアログボックスの「適用」ボタン：テキストボックスに入力した内容に従い、選択中のユニットの種類・位置・角度を変更

向きをそろえて並べてみた。

ミサイルも置いておいたよ。確かにこれだと、横方向から攻撃できちゃうね。

難しければいい、という問題でもないからそれくらいが丁度良いと思うわ。次に、攻撃目標を置くつもりだけど、その前に、ダイアログの中身を少し説明しておくわね。

細かい属性が沢山あるけれど、順番に説明するわね。まず「Label」というのは、このユニットに付けられた名前ね、エレアは「人間」だけど「エレア」という名前があるように、このユニットは「地対空ミサイル」だけど「Enemy」という名前がついている、という具合ね。スクリプトで制御するときに必要になるから覚えておいてね。名前と言っても2つ以上のユニットを同じラベル名称にすることも多いし、敵だから「Enemy」というラベルにしないとだめ、ということでもないわ。例えば「Battery」でも「Hogehoge」でも構わないわよ。

ほげほげ？

特に意味は無いわ。つまり「何でもいい」ということよ。複雑なイベントを作りたいときは色々なユニットに対して、様々な異なるラベルをつけるようにするの。スクリプトの話をするときにこのラベルをよく使うから、分からなくなったらまた聞いて頂戴。次に「Group」というのは、スクリプトから設置するときの識別に使う名称よ。例えば難易度Easyでは出現しないけど、Hardでは出現するとか、最初は出てこないけれど、途中から増援が出てくる、という使い方をしたいときに、このグループ名で分けておくのよ。選択肢が少ないけれど、自分で好きなグループ名を決めて入力してもいいわよ。

ラベルと似てるが、何が違うんだ？

グループはあくまでユニットを配置するときだけに使う名称よ。一旦配置された後は「ラベル」に従って動くの。何度も同じ話の流れで申し訳ないけれど、これも「グループ」と「ラベル」とに分けておくことでスクリプトで制御するときに、細かな制御がやりやすくなる、という目的で分かれているのよ。

ところで、何も入力しないとどうなるんだ？

その場合は、ミッションの開始と同時に戦場に出現する仕様よ。スクリプトから何も制御しなくても出現するから、一見すると楽だけれど、イベント処理で複雑な動作を作ろうとしたときに、いろいろと問題が起こりやすいから必ず何かのグループ名を決めたほうが良いと思うわ。

さっき置いた砲台に「GroupEasy」って書いてあったのは、難易度Easyのときに出現する、ってことなんだね。

だとするとNormalはHardのときはどうなるんだ？別々に置かないといけないのか。

実はそのあたりの仕組みは、次回のスクリプトで説明する予定なのよ。実際には「GroupEasy」とグループ名が付けられたユニットは難易度に関わらず出現するけれど、具体的なメカニズムの説明は次回にさせてもらうわ。

そうなのか。スクリプトの話も聞かないと全体が分かりにくいな。

ごめんなさいね。でも、いきなりスクリプトの説明をしてしまうと、ますます意味が分からなくなってしまうから仕方がないの。今はまず、ユニットの「配置」だけの説明をさせて欲しいのよ。

じゃあ、その次の「Team」は何だ？こちらは大体想像がつくが。

次に「Team」はその名の通り、所属する勢力の名称ね。デフォルトの選択肢では「Enemy」と「Friend」があるから、大抵の場面ではその2つで足りるはずよ。プレイヤーと同じチーム名ならば友軍としてレーダーに表示されるわ。普通、プレイヤーを「Friend」とするだろうから、大抵の場合は自機と友軍には「Friend」を、敵軍には「Enemy」を割り当てていけば良いと思うわ。ちなみに、何も入力しないと「無所属」つまり敵でも見方でもない、と解釈されて、レーダーに表示されなくなるわよ。ただしこれは、ウリンバ砂漠の風車のような特殊な例ね。

最後の「Option」ってのは何？「TARGET」とかが選べるから、これを選ぶと赤マークのターゲットになるのかな？

その通りよ。ここにはいろいろな拡張情報を設定するところだけど、普段使うのは「TARGET」と「PLAYER」の2種類くらいね。「TARGET」を指定すると、レーダー上で赤く表示されて、HUDにも「TGT」と表示されるわよ。「PLAYER」というのは少し特殊で、これを指定すると、プレイヤーの操作ユニット、いわゆる「自機」になるわ。プレイヤーユニットについては注意事項がいくつかあるから、もう少し後で説明するわね。まずは最初に説明した「TARGET」を指定して、このミッションの作戦目標を置いてみましょう。何でもいいけれど、とりあえずレーダーでいいかしら。レーダーを選んで、「Option」欄から「TARGET」を指定してみて。あと、「Label」には「Radar」と記入して、他の内容は先ほどの砲台を置いたときと同じね。ラベルの「Radar」というのは選択肢には無いけれど、そのままキーボードで入力すれば大丈夫よ

こうだね。

どこに置くつもりだ？山の上に置くのが普通だが。

ビルの上に置いてみた。

ふむふむ、砲台の間を縫って、街中にあるレーダー基地を攻撃する、って設定か。なかなか良いな。これで出来上がりかな。

最後に、プレイヤーがどこから登場するかを決めておく必要があるわね。プレイヤーの場合、機種が固定されている場合もあるけれど、機種を自由に格納庫で選ぶこともできるわよね。

そうだな。確かに普段は選んだ機体で出撃できるが、定期検査のときは、どの機体を選択していても、必ずR-27になっていたぞ。

あと、スパイの2人を追いかける時にもノブ爺のR-24を借りたよね。しかもミサイル積んでなかったじゃん。いつもの機体が選べていたらどれほど簡単だったか。

そうね。今の話みたいに、機種が決まっている場合は、敵機を置くときと同様に、機種を選んで、そのまま置けばいいの。例えばこのようにね。チーム名を「Friend」にすることに注意して。「Enemy」のままだと、イーストフィッシャーバレーの時のように「全部青マーカー」ということになってしまうわよ。

一方で「プレイヤーが選択している機種」を選ぶときは、「PlayerUnit」という特殊なユニットを使うのよ。これを指定すると、画面ではR-10が表示されているけれど、実際には格納庫で選んだ機体で出現するわよ。

エレア、少し離れたところに置いてみろ。

こうかな？でも、これだと海の上になっちゃうね。

こういうときに「ターゲットレイヤー」が役に立つのよ。Shiftキーを押しながらマウスのホイールを回すと、灰色の板が浮かび上がってくるはずよ。その状態で置いてみて。

こうすればいいの？

あ、置いた砲台の色が変わった。敵のマーカー表示だ。

今置いたプレイヤー機の「Team」に「Friend」と指定しておいたから、先ほど置いた「Enemy」という所属のユニットは「敵軍」ともなされて自動的に表示が変わるのよ。置くときに参考にすると良いわよ。

ところで、高さが分かりにくいが、どこを見ればいい？

マウスカーソルの横に、3次元空間中の座標が表示されているわ。（X,Y,Z）という順序で、高さはY、つまり真ん中の数字を見れば分かるわよ。単位はメートルね。ちなみに、東西方向がX、南北方向がZになっていて、東に進むほどXが増えて、上に上がるほどYが増えて、南に進むほどにZが増える、というルールよ。置いた直後にダイアログを見ると、そのユニットの座標が表示されるから、それを見るのも一つの方法よ。

そういえば確か、キー入力でも動かせたよな。それで高さを変えても良いのか？

PageUp/PageDownで高さを変えられるから、例えば4機編隊の高さを変えて配備したい、という場合は、まず同じ高さで4機置いてから、一つずつ選択して、キーボードで高さや位置を微調整する、というやり方が一番早いわね。

結構、両手が忙しいんだな。

キー入力でユニットや建物を動かす場合、通常は10m単位で移動するけれど、Shiftキーを押しながらだと100ごと、Ctrlキーを押しながらだと1mごとに移動するから、長距離を動かしたいとき、もしくは細かく微調整したいときに重宝するわよ。

ところで姉さん。自分の機体も敵の砲台も置いたわけだから、早く動かしてみようよ。

その前に保存しないとダメだろ。

保存する場合は「ファイル」→「ユニット配置ファイルを保存」と選んで保存できるわよ。ファイル名は、そうね……"Radar.plc"とでもしておきましょう。それと、今はまだユニットの場所を決めただけだから動かせないわよ。次回、いよいよスクリプトの説明をする予定だけれど、そこで初めて飛べるようになるわ。山場だから気を抜かないでね。

第4回：スクリプト入力

今回がSphereEngineの本丸、スクリプトの解説ね。

その「本丸」ってどういう意味なの？ノブ爺も前そんな事言ってたけど。

昔の城の本体の部分だ。今で言うと総司令本部ってことだな。

話の腰を折らないで。とにかく、今まで作ったマップやユニットの配置情報をこのスクリプトで全てまとめて制御する、ということよ。これが出来ればとりあえずは飛べるようになるわ。

じゃあ早くつくろうよ。

そうね。でもその前に準備が必要ね。スクリプトを書く、となるとどうしてもキーボードで書いていく必要があるから、エディタの準備が必要よ。「メモ帳」でもできない事はないけれど、お勧めはしないわね。いわゆる「テキストエディタ」を用意して欲しいのよ。電プロさんはフリーソフトの「サクラエディタ」を使っているそうよ。「秀丸」や「VisualStudio」でも問題なく使えるわよ。他のエディタでも基本的な操作は同じだから心配しないでね。事前に「サクラエディタ」を用意したからエレアはこれを使いなさい。

ありがとう。

で、何を書けばいい？

実はここにいきなり書いていくのではなく、SphereEngineからエディタを呼び出す、という使い方をするのよ。言葉だけの説明だと分かりにくいだろうから、まずは説明の通りに作業してみて。エディタのインストールが確認できたら、次にエディタ側の設定が必要よ。外部からのファイル更新に対応できるように、メニューバーの「設定」→「共通設定」→「ファイル」タブを開いて、次の画像のようにファイルの排他制御をしないように、また外部からの更新に対応できるようにしてほしいの。

サクラエディタの場合はこの通りだけど、他のエディタの場合も同じように設定しておいて。さきほど「メモ帳」をオススメしない、と言ったのはこの設定が無いからなのよ。

設定したよ。次は？

スクリプトが書かれたファイルを開くために、関連付け、が必要ね。"EditSample\Script\subscript"というフォルダに入っているファイルのうち、拡張子が"*.spt"となっているファイルがあるでしょう？このファイルをさきほどのエディタに関連付けしてほしいのよ。やり方はいくつかあるけれど、とりあえずこのファイルをダブルクリックしてしまって、関連付けの設定をしてしまうのがお手軽ね。Windowsのバージョンによっても少し違うから、自分で調べてね。

やり方くらい教えてくれても良いじゃん。

ggrks

え？今何て？

……エレア、俺がやっておいたぞ。

これで準備完了よ。それでは始めましょう。まずは今までと同じように、地形ファイルと敵配置ファイルを読み込んで。ファイル名はそれぞれ"Island.map"と"Radar.plc"だったわね。

これでOK？

そうよ。次にダイアログの「PathEditor」を選んで、こんな風に入力して。内容は正確にね。

入力できたよ。

メインウィンドウに移って、ユニットの置かれていない適当な場所をクリックしなさい。どこでもいいのだけれど、遠くだと後で見失ってしまうから、敵か味方の近くが良いと思うわ。

向きはどうするの？

今回に限ってはどの方向でも良いわ。

置いてみた。なんか四角いのが出てきたけど。

これは「アンカーポイント」と呼ぶものよ。線で結ばれた箱の全体を指して「パス」と呼ぶわ。スクリプトはこのアンカーポイントの中に書いていくの。

中に書く？一体どういう意味だ？

一番手前のアンカーポイントをダブルクリックしてもらえるかしら。意味が分かるはずよ。

エディタが開いた。

次に、今は何も考えずに、この下の内容をコピー＆ペーストして欲しいの。

#link "subscript/gamedata.spt"
#link "subscript/gamecommon.spt" // ゲーム共通処理サブスクリプト
#link "subscript/Jukebox.spt" // BGM再生サブスクリプト
#link "subscript/Weather.spt" // 天候設定サブスクリプト
#include "version.inc" // バージョン名サブスクリプト
#include "mission_name.inc"

init_common("", "", "", __SAVE_NAME__); // "gamecommon.spt"の初期化

//========== 各種リソースの読み込み ==========
load_map("Island.map"); // マップデータ読み込み
set_flight_area({x:-6000, y:-7000, z:-6000}, {x:6000, y:9000, z:6000}, 900); // 飛行エリア12km四方で警戒エリア900m

set_player_unit("R_10"); // プレイヤーの機種を設定
set_player_weapon(MAIN_PYLON, "AAG_308"); // プレイヤーの武装を設定
set_player_weapon(SUB_PYLON, "AAG_308"); // プレイヤーの武装を設定
set_player_weapon(CENTER_PYLON, "AAG_308"); // プレイヤーの武装を設定

weather_box(0, "SUNNY", 45, 11); // 天候プリセット設定

//========== ユニット配置（プレイヤー含む） ==========
put_group("GroupPlayer", ALWAYS_TEXTURE, TRUE);
put_group("GroupEasy", ALWAYS_TEXTURE, TRUE);

//==========ミッション初期化==========
player_handle=get_handle("Player", 0); // プレイヤーのハンドルを取得
set_camera_focus(player_handle, player_handle); // カメラをプレイヤーに向ける
set_camera_mode(CAMERA_VIEW_PLAY);

set_rest_time(600); // 残り時間を600秒（10分）とする

fade_screen(0,1, 0.5); // 画面フェードイン(0.5secでフェードイン)
wait_time(0.3);
juke_box("RS4-034"); // BGM再生

subtitle_window("", "/RS4th/Story/FriendFace.png", "", "ビルの上のレーダーを破壊してください。");
wait_time(3);
subtitle_window("", "", "", "");

//==========メインループはここから==========

while(TRUE) {
system(); // 一旦システムに処理を戻す。これが無いとスクリプトが処理を返さずに暴走してしまう。
}

出来たらCtrl+Sキーで上書き保存よ。そうすると、メインウィンドウに何が出てくるかしら？

あ、なんか出てきた。更新しますか？って聞いてきてる。

なるほど。こうやってその箱を選んで、エディタで書いて記録していくから「中に書く」ってさっきリサが言ったのか。

その通りよ。このダイアログには「はい」を選んでくれるかしら？これで一つ分のスクリプトが完成した事になるわ。

一つ分？と言うことは何個か必要なのか？

今書いた部分は、戦場の環境を整えて、敵を置いて、プレイヤーを置いて、BGMを再生するところまでなのよ。飛べないことは無いけれど、敵を倒しても何も起こらないわ。だからミッション終了のためのスクリプトも必要という意味よ。一番奥の方のアンカーポイントをクリックして、選択状態にしてから、編集ダイアログに次のように入力してもらえるかしら。

入力したら「適用」ボタンを押してね。今ので準備が出来たから、先ほどと同じように、今選択した奥のほうのポイントをダブルクリックして、このスクリプトをコピー＆ペーストして頂戴。

subtitle_window("", "/RS4th/Story/FriendFace.png", "", "全てのターゲットを破壊しました。次へ進みます。");
wait_time(3);
subtitle_window("", "", "", "");
stage_clear(); // ミッションクリア時の処理

こっちは短いね。4行だ。

敵の数を調べてミッションを終了させるだけだから簡単ね。記入が終わったら、上書き保存して、メインウィンドウに戻ってね。

さっきと同じメッセージが出てきた。

「はい」を選べばいいんだね。

その通りよ。さて、これを保存しましょう。Ctrl+Sで保存してしまうのが一番簡単ね。実はスクリプトも敵配置ファイルの中に記録されているから、"Radar.plc"をそのまま上書きしてしまって良いわよ。

これで全部出来上がり。いよいよ飛べるわよ。やってみなさい。

えーっと、どうやるんだっけ？

F5キーだな。押してみろ。

一番最初に見たときと同じだね。

おー、飛んどる飛んどる。これは前回エレアが置いたトーチカ砲とレーダーだな。

できたー。

ところでリサ、一番肝心な、スクリプトの中身の説明を何もしていないよな。

そうね。説明が長くなりそうだから次回にさせてもらうわね。と言っても、スクリプトの文法まで含めて全部全部説明するとあまりにも時間が掛かってしまうから、全体的な処理の流れと考え方だけにするつもりよ。細かな説明を書いたマニュアルを「リファレンスマニュアル」と呼ぶのだけれど、電プロさんが別途作ってくれるそうよ。詳細な言語仕様についてはそれまで待っていて貰えるかしら。

第5回：スクリプト解説

前回、単純にコピー＆ペーストした部分の解説を進めて行くわね。

はーい。

ちょっと待ってくれ。俺たちプログラマでもないのに、そんなこといきなり聞いても何も分からんぞ。

そうね、最初から全部書いてもらう、ということは現時点では期待していなくて、今はまず、スクリプトのうち、どの記述が何を表しているのか理解してもらって、少しずつ書き換える、という方法で覚えて言ってもらおうという計画なのよ。だから、全体のシステムやアルゴリズムの説明はあえて割愛して、数値や文字列の意味を説明していこうと思うのよ。

……うん？

ちょっとエレアに合わせるには無理がありそうね……。私自身、ここを読んでいる人のプログラミングに対する理解度が分からないから、まずは説明してみて、不足する部分があったら、その都度追加するようにするわね。

あーそうだ、リサ宛にこんなものが届いてるぞ。

SphereScriptのマニュアルね、この講座とあわせて読んでおくと何かの参考になるとおもうから、置いておくわね。

今言ったSphereScriptってなに？

SphereEngineで使っているスクリプト言語のことよ。今となってはわざわざ名前を分ける必要もそれほど無いけれど、単にスクリプトの仕組みだけを示す場合は「SphereScript」と呼ぶのよ。

前置きはそれくらいにして、そろそろ始めたらどうだ。

そうね始めましょう。まずはスクリプトの前にダイアログの説明からね。

「Cmd 01:自動的に起動」というのは、文字通り、ファイルが読み込まれたら自動的にスクリプトの処理が始まる、という意味よ。次の「Label:main」は、ユニットのときと似ていて、アンカーポイントの名前を表しているわ。

この名前にはどういう意味があるんだ？

「main」というラベル名にしているだけで、実際は「start」とかでも構わないわよ。単にスクリプトを動かすだけならば、あまりこのラベル名は気にする必要は無いと思うわ。ムービーシーンの処理にこのパスを使うときには意味があるから、とりあえず「アンカーポイントに名前がついている」ということだけ覚えて置いて欲しいのよ。この名前の由来としては、C言語というプログラム言語には「main関数」というものがあって、プログラムは必ずそこから始まることになっているのよ。慣例みたいなものだからあまり深く考えないほうが良いと思うわ。それと「ActiveScript」というチェックボックスは、このスクリプトが「実行可能」であることを表しているわ。複雑な制御を作ろうとすると、「今はまだスクリプトを動かさない」ということをやりたくなってくるけれど、とりあえず今のうちは何も考えずにチェックボックスをONにしておけば大丈夫よ。

その下の枠の中にごちゃごちゃ書いてあるけどこれは何だ？

この前入力したスクリプトね。前回はエディタで入力したけれども、このテキストボックスを直接編集して「適用」ボタンを押しても編集できるのよ。でも、あまり使うことは無いと思うわ。それでは、中身の説明をするわね。そうそう、今日はほとんど私が話しっぱなしになると思うけれど、気を悪くしないでね。

まぁ、いいんじゃないの？どう考えても私の出番はなさそうだし。

では、最初の6行分の説明から。

スクリプトファイルの読み込みを表しているのだけど、初心者向けの説明シーンで「おまじない」とが言うことが多いわね。ファイル名のような記述があるでしょう？このファイルは敵配置ファイルがある場所に実際に存在していて、そのファイルの内容に関係しているのだけれど、今のうちは「よく分からないけど、この6行をコピペするルールがある」という理解で構わないわ。プログラミングを知っている人向けに少し説明しておくと、「#include」はC言語同様に、プリプロセッサによりそのまま挿入されて、「#link」は個別にコンパイルされた後に外部結合でリンクされるわ。あ、別に今の説明の意味が分からなくても構わないわよ。
次がこれ。

init_common("", "", "", __SAVE_NAME__); // "gamecommon.spt"の初期化

スクリプトを使ったゲームシステムの初期化をしているわ。何の話かというと、例えばPauseを押したときにゲームが一時停止したり、墜落したときにウィンドウが出てきて、Retryを選んで最初から再開したり、ということを当たり前のようにやっているわよね。でも実はこれも全部スクリプトで書かれているのよ。このあたりの処理は最初の6行の「おまじない」の中にうまく隠されているのだけれど、最初の設定というのはどうしても必要で、そのためにこの1行が存在するわ。一応、関数の引数の説明もするわね。最初の3つの文字列には実際には、「Retry選択時に動作するファイル、Hanger選択時に動作するファイル、Next選択時に動作するファイル」を表しているけれど、今はただ飛ぶだけのスクリプトを書いているから空っぽよ。この関数については複数ミッションの連携処理を作るときに詳しく説明する予定よ。
次はマップ読み込みよ。だんだん今回作った内容に関係してくるわね。

load_map("Island.map"); // マップデータ読み込み
set_flight_area({x:-6000, y:-7000, z:-6000}, {x:6000, y:9000, z:6000}, 900); // 飛行エリア12km四方で警戒エリア900m

load_mapというのはその名の通り、地形ファイルを読み込む関数よ。その中身は"subscript"フォルダ内の"gamecommon.spt"というスクリプトに書かれているから、中身が知りたい場合は覗いてみるといいわね。次は飛行エリアを設置しているわ。直方体の左下と右上の位置を指定していて、最後の900というのは「OFF COURSE」の警報を出すための領域幅を表すから、例えばここに0を入れてしまうと、警告なしでいきなりコースアウトしてミッション失敗となってしまうから注意してね。。

ここのファイル名を変えれば、別のマップを読み込めるんだな。

その通りよ。ユニット配置ファイルも変えて、ここで指定しているマップも変えてしまえば、いくらでもミッションを作り出せる、という仕組みね。
次がプレイヤーの機体と武器の設定ね。

set_player_unit("R_10"); // プレイヤーの機種を設定
set_player_weapon(MAIN_PYLON, "AAG_308"); // プレイヤーの武装を設定
set_player_weapon(SUB_PYLON, "AAG_308"); // プレイヤーの武装を設定
set_player_weapon(CENTER_PYLON, "AAG_308"); // プレイヤーの武装を設定

例えば"R_10"を"R_21"に書き換えると機種が変わるから、やってみると良いわね。ここでは装備の種類を直接設定しているけれど、普通は武装選択画面で設定したものを読み込むような書き方になるわ。SDKに付属しているサンプルミッションの書き方が参考になると思うわ。
次は天候の設定ね。

weather_box(0, "SUNNY", 45, 11); // 天候プリセット設定

天候情報は本来は光源の方向や色設定など、沢山の項目があるのだけれど、この関数で一括して設定で要るようになっているわ。この書き方だと「晴れ/北緯45度/午前11時」という意味になるわよ。ここまでで、ようやく準備が終わり、いよいよユニットを読み込んでゲームを開始するまでの処理になるわね。
前々回に置いたユニットの読み込みよ。

put_group("GroupPlayer", ALWAYS_TEXTURE, TRUE);
put_group("GroupEasy", ALWAYS_TEXTURE, TRUE);

「グループ名」の話をしたのは覚えているかしら？あのときに設定したグループ名はここで使うことになるわよ。例えば難易度別にグループ名が異なるユニットをいくつか用意しておいて、条件分岐などで読み込み方を変えれば、難易度ごとに敵の数が変わる、ということが実現できるようになるわ。
次はカメラ設定ね。

player_handle=get_handle("Player", 0); // プレイヤーのハンドルを取得
set_camera_focus(player_handle, player_handle); // カメラをプレイヤーに向ける
set_camera_mode(CAMERA_VIEW_PLAY);

カメラをプレイ中のモードに切り替えているわ。何度も似たような事を書いてしまうけれど、SphereEngine4ではゲームの基本的な仕組みもスクリプトで実現しているから、「ミッションを開始したら自分が飛行機に乗っている」という行為も全部スクリプトで書く必要があるわ。とは言っても大抵の場合はここに書いたように決まりきった処理になるはずだから、何も考えずにコピー＆ペーストして、必要な部分だけを最低限書き換える、というやり方で良いわよ。逆に言うと、ここを書き換えれば、ミッション開始時にイベントシーンのカメラ撮影を行ったり、ラジコン飛行機のような遠隔操作をするゲームを作ったり、ということも出来るようになるはずよ。もっとも上級者向けの作り方だから今は考えないほうが良いわね。ちなみにset_camera_mode関数の引数についてだけれど「CAMERA_VIEW_PLAY」というのは定数よ。「"CAMERA_VIEW_PLAY"」と書いてしまうとまったく別の意味になってしまうから注意してね。
次はコメントの通り、ミッションの制限時間を設定しているわよ。秒数で設定してね。

set_rest_time(600); // 残り時間を600秒（10分）とする

ミッションの開始時に、黒い画面からフェードインして画面が表示されるけれど、一見すると当たり前のように見えるこの動作もスクリプトで書いているわよ。フェードインしながらBGMを再生しているわね。

fade_screen(0,1, 0.5); // 画面フェードイン(0.5secでフェードイン)
wait_time(0.3);
juke_box("RS4-034"); // BGM再生

BGM再生の前にwait_time(0.3)という関数で0.3秒待っているけれど、これはちょっとしたエンジン側の都合で、マップやキャラクターの読み込みが終わる前にBGMを再生しようとしてしまうとBGMが音飛びしてしまうから、少し時間が経ってから再生するようにしているのね。fade_screen関数の個々の引数について説明していないけれど、関数ごとの細かな説明は、リファレンスマニュアルで説明したいから、今は待っていて欲しいのよ。ここまでで、ゲームの画面が始まるわね。
ミッションが始まったら、メッセージウィンドウが表示されていたと思うけれど、その次の記述がメッセージウィンドウになるわね。

subtitle_window("", "/RS4th/Story/FriendFace.png", "", "ビルの上のレーダーを破壊してください。");
wait_time(3);
subtitle_window("", "", "", "");

メッセージを表示してから、3秒待って、ウィンドウを消しているわね。音声と共に再生する機能もあるけれど、それも別の機会に説明させてもらうわね。スクリプトについて一度に全部説明しようとすると、いつまで経っても終わらないから、まずは最後まで進めたいのよ。
最後がこれね。

while(TRUE) {
system(); // 一旦システムに処理を戻す。これが無いとスクリプトが処理を返さずに暴走してしまう。
}

初めて制御構文が出てきたけれど、要するに無限ループでsystem関数を呼んでいるだけね。コメントにもあるけれど、system関数というのはスクリプトの処理を一旦終えて、ゲームエンジンに処理を戻す機能で、内部的には1フレーム分ゲームが進むことになるわ。一旦ミッションを開始した後に、スクリプトで何かを監視したり、繰り返しの処理をしたい場合はこのwhileループの中にいろいろ書くことが出来る、という仕組みね。RSE3.5の頃はこの仕組みを多用していたけれど、SphereEngine4では、アンカーポイントごとにスクリプトを書いて起動条件を指定できるようになったから、あまり複雑な処理をここに書くことは無いかもしれないわね。ただし書き方としては従来どおりの方法もあるから、好きなほうを選ぶと良いわよ。RS4thでは、ほとんどの処理を一つのスクリプトに書いていたそうよ。

ふ～、ようやく最後まで進んだ。

いや待て、もう一箇所コピペしたのがあった筈だよな。

そのとおり、本当の最後はこれよ。短いからもう少し我慢してね。

最初のスクリプトが無条件で自動的に起動するようになっていたのに対して、こちらはユニットを破壊したときに起動するようになっているものよ。選択肢を見てもらえれば大体分かるだろうけれど、「Radarというラベルを持ったユニットが1未満になったら起動する」という意味で、要するに、レーダ尾ウィ全部破壊した瞬間に実行されるスクリプト、ということを意味するわ。それで、実行されるスクリプトというのはこの通りね。

最初の3行は既に説明したと思うけれど、メッセージ表示をしているわ。最後の1行は、ミッションクリアするための関数ね。

それにしても、スクリプトを書くのはずいぶん大変なんだな。

慣れないうちは大変だけれど、スクリプトのほとんどが流用できるし、単に敵の位置や種類を変えても全く別のミッションに見えるから、分からないうちは、無理に作ろうとしないで、今回のスクリプトや、SDK付属のサンプルを使うのが良いかもしれないわね。

ところでさ、イベントシーンってあったじゃん？あれってどうやって作るの？

やっぱりアレも、スクリプトで作っているんだろう？

その通りだけれど、カメラワークは今扱っているこの「パス」を使うのよ。パスを置いたときに3つのアンカーポイントが配置されたのも理由があるのよ。次回はそれを説明するつもりだから、準備をしておいてね。操作は少しややこしいけれど、スクリプト自体はそれほど難しくないわよ。

そうなのか、スクリプトが簡単と聞いて少し安心したぞ。

第6回：イベント解説

それでは今回はイベントシーンの解説をするわね。

ミッションの前後で、画面が切り替わって映像が出てくるやつだね。

映像と言っても、実際は単にゲーム中のカメラの位置が変わっているだけなのよ。元々SphereEngineの考え方として、カメラもユニットも自由に動かすことが出来るのよ。たまたま飛行機の中にカメラが固定されて、その飛行機を操作できるという状態を「飛行中」や「ゲーム中」と表現しているに過ぎないわ。

ってことは、例によってスクリプトで制御しろ、ってことか？

その通り。でも実は処理してはプレイヤー機を用意して操作させるほうが複雑で、イベントシーンの方がやることが決まっている分、シンプルなのよ。前回の説明が理解できているならば簡単ね。

まぁ、あんまり理解しているとはいえないが…。

今回もコピー＆ペーストできるように用意するから安心して。それにユニットやカメラを動かすのはパスをマウスで配置していくだけだから、それほど難しくないわよ。

前回言ってた話だね。マウスで置くだけなら私にも出来るよ。

では早速、作っていくことにするわね。まず最初は簡単に、真っ直ぐ飛ぶ自機を真っ直ぐ移動するカメラで追う、というものにしましょう。「PathEditor」を選んで、このように設定して。

次に、マップ状の適当な場所にパスを置いてみて。後で細かく説明するけど、ここは飛行機が飛ぶ場所だから、水面ではなくて、空中に設定しなくてはダメよ。

置いたよ。ここを飛行機が通るの？

そうよ。次はカメラね。置くパスはこう。

これを、そうね、今置いたパスの少し斜め前に置いてみて。かなり接近していて構わないわ。

これぐらいの距離かな。

それぞれ名前が「PlayerPath」と「CameraPath」になっとるが、こうすると自機やカメラになるのか。

今回は最終的にはそうするけれども、この名前もあくまで識別用で、ユニットを結びつけることで、カメラや自機をパスに載せることになるわ。具体的な手順を説明するわね。パスは一旦置いておいて、「UnitEditor」に切り替えて、このように設定して。

そして、先ほど「PlayerPath」として置いたパスの先頭のアンカーポイントをクリックしてみて。自機がパスの上に置かれるはずよ。

お、ダイアログの「Path」の中身が「PlayerPath」に変わったぞ。これでパスとユニットがくっ付いたんだな。よく見るとユニットの向きも変わっとる。

次はカメラね。カメラの場合は専用のユニットがあって、それを使うのが分かりやすいわね。さっきと同じように置いてみて。ラベル名は分かりやすいように「Camera」とすると良いわね。グループ名は先ほどと同じように「GroupEvent1」としてちょうだい。

なんか、カメラって書いてあるのが２種類あるけど。

「Camera(Rot)」というのは移動する軌跡にあわせて飛行機のように回転するカメラ、一方で「Camera(Stand)」というのは移動しても、回転しないカメラを意味しているわ。今回は「Camera(Rot)」を選ぶと良いわね。後から変えてみて、違いを比べると良いわよ。

カメラを置いたけど、何も出てこないよ。

カメラ自体は何も画像を持っていないから、それでいいわ。次にこれを動かして、カメラで撮影するようなスクリプトを書いていくわよ。手数が多いからしっかり付いてきてね。まず、イベントをミッション開始時に動かすようにするから「main」のスクリプトを編集するわね。

えっと、どこに置いたっけ？

もっと離れたところから探してみたらどうだ？

目視で探さなくてもメニューバーの「リスト」→「パスのリスト」から「main」を探して選べばカメラが自動的にその場所に移動するわよ。ダブルクリックするとすぐにスクリプトを編集できることは覚えているかしら。スクリプトの大体20行目くらい、weather_box関数とput_group関数の間に次の表記を追加して。

extern int event_end=0; // イベント終了監視用変数
set_event_mode(TRUE); // イベントモード設定
put_group("GroupEvent1", ALWAYS_TEXTURE, TRUE); // イベント用ユニット読み込み
wait_time(0.3);
juke_box("RS4-034"); // BGM再生
while(event_end==0) system(); // イベント終了まで待つ
set_event_mode(FALSE); // イベントモード設定

これは何をやっているかというと、イベントモードに切り替えてから、イベント用のユニットを置いて、0.3秒後にBGM再生をしているだけよ。イベントモードというのは、ゲームプレイ中とイベント処理の切り替えをするための仕組みね。色々と応用があるけれど、原則としては、イベントの前に「set_event_mode(TRUE);」と書いて、イベント終了の直前に「set_event_mode(FALSE);」と書くのが定番ね。

最後の1行は何だ？whileってことはループで何かやっているようだが、これだと何も仕事をしていないぞ。

event_endという変数が0ではなくなるまで、ずっと待っている、という処理よ。event_end自体は1行目で定義しているわね。後に説明するけど、この変数は別のパスのスクリプトで書き換えるからexternという記述が必要よ。難しい言い方だけど、外部参照識別子と呼ぶわ。あ、よく分からなければ別に覚える必要ないわよ。そうそう、このスクリプトの編集を終える前に、後半にあるjuke_box関数は消してしまって良いわよ。既にBGMは再生されているから、ここでは要らなくなるわ。準備はこれで終わり、次にカメラワークを作っていくわよ。先ほどと同じように、今度は「PlayerPath」のスクリプトを編集するわね。次の内容をコピー＆ペーストして。

set_speed(__unit_handle__, 1.5); // このユニットを324km/hに設定

このアンカーポイントの設定内容をもう一度見て欲しいのだけれど、「Cmd 04:ユニットがこのラベルに到着」となっているわよね。文字通り、このアンカーポイントの場所にユニットが到着したらスクリプトが起動されるわ。「到着」というイメージとは少し違うけれど、put_groupで置かれたユニットでもこのスクリプトは動き出すわよ。ここで使われている「__unit_handle__」という変数は説明が必要ね。これは例えば「Cmd 04:ユニットがこのラベルに到着」という風に、ユニットがスクリプト起動のきっかけになる場合に自動的に作られる変数で、対象のユニットのハンドルがそのまま入るわ。だからこのように書くことで、このアンカーポイントに置かれたユニットの速度を変更する、という動作になるわ。次はカメラのスクリプトね。「CameraPath」には次のスクリプトをコピー＆ペーストして。

set_speed(__unit_handle__, 1.4); // このユニットを305km/hに設定
camera_target=get_handle("Event1Player", 0); // プレイヤー機のハンドルを取得
set_camera_mode(CAMERA_VIEW_UNIT_IN); // カメラモード切り替え
set_camera_focus(__unit_handle__, camera_target); // 撮影対象切り替え

fade_screen(0,1, 0.5); // 画面フェードイン(0.5secでフェードイン)
wait_time(0.3);
subtitle_window("", "/RS4th/Story/FriendFace.png", "", "間もなく演習空域に入ります。");
wait_time(5);

fade_screen(1,0, 0.5); // 画面フェードアウト(0.5secでフェードアウト)
wait_time(0.5); // 0.5秒待つ
release_all_object(); // 全ユニット削除
event_end=1; // イベント終了をmainに通知

ちょっと多いけれど、やっていることは今までの延長よ。確実に理解しておいて欲しいのがカメラの設定ね。カメラで好きなものを撮影するには、まず「set_camera_mode(CAMERA_VIEW_UNIT_IN);」という設定で、カメラの指定方法をイベント用に変更して、次にset_camera_focus関数で「カメラがどこにあるのか？」と「カメラは何を撮影しようとしているのか？」という2つの情報を設定すればいいわ。要するにこのスクリプトでは、Event1CameraからEvent1Playerを撮影しているわよ。今は1カットしか撮影していないけれど、フェードイン、フェードアウトとこのカメラ設定を組み合わせれば、いろいろなカットを次々と切り替えて、イベントを作ることが出来るようになるわよ。最後の2行についての説明だけれど、release_all_object関数は、今読み込んでいるユニットを全て消す命令よ。イベントモードとそれ以外とで区別していて、イベントモード中にrelease_all_objectを呼べば、イベントモードで置いたユニットだけを消してくれるから、戦闘中にイベントを割り込ませるときでも、気にせずに使えるわよ。イベントシーンの最後にこの関数を使うのはほぼお決まりと思って良いわ。最後にevent_end変数に1を代入することで「main」のスクリプトの処理が再開される、という仕組みね。スクリプトの流れを図解するとこうなるわね。

3つ書かないといけないから、面倒くさいな。

もちろん一つのスクリプトにまとめて書くことも出来るけれど、同時に複数のものを制御するスクリプトを書くのはそれはそれで難しいのよ。最初は今と全く同じ手順でコピー＆ペーストで作ればいいし、ある程度理解してくれば、どちらの書き方でも自由にイベントやミッション作成が出来るようになるから、好きなスタイルを身に付けていけばいいと思うわよ。

ところで、これってもう動かせるの？

動かせるわよ。F5キーを押して動かしてみなさい。

イベントシーンになった。

あれ？途中で動きが止まったぞ。

最初に置いたパスそのままだからよ。200mしかないから、すぐ終点についてしまうわ。パスを伸ばしたり曲げたりすると、その線に沿って飛行機やカメラが移動してくれるわよ。やり方を説明するわね。まずは伸ばし方。「PathEditor」に切り変わっていることを確認してから、「PlayerPath」の反対側のアンカーポイントをクリックしてみて。クリックすると選択状態になるから、それをドラッグしたり方向キーで動かすと、それにあわせてパスの直線も延びていくわよ。

ユニットや建物を動かしたときとおんなじ感じだね。

次に曲げ方ね。直線の中間に少し小さな箱があるのが見えるでしょう？これもアンカーポイントの一つよ。先ほどと同じようにこれを選択してから、ドラッグしてみて。少し小さいから、慎重に狙ってね。

曲がったな。

アンカーポイントとパスの線が離れちゃったど、いいの？

曲線部分だからこれで良いわ。

よく見ると、今引っ張った部分にまたアンカーポイントみたいなマークが表示されているな。

そこを引っ張っていくと、またパスを曲げることが出来るわよ。あくまで飛行機が飛ぶ場所だから、極端に曲げてしまうと不自然になるから気をつけてね。一度曲げた場所でも、もう一度ドラッグすると再度位置できるわよ。そうそう、必要以上にアンカーポイントを増やしてしまって、減らしたいと思ったときには、アンカーポイントを選択してからDELキーを押すと、その部分が消えるわよ。考え方はユニットや建物の設置と同じね。それともう一つ、アンカーポイントの端同士をドラッグ＆ドロップすると端同士で接続されるわよ。便利だけど、パスが密集した場所で間違ってくっつけてしまわないように注意してね。それではエレア、イベントシーンで自機を飛ばしたいように、パスを作ってみて。カメラのパスも同様に、伸ばしたり曲げたりして、イベントシーンに十分な長さにしてね。

こんな感じかな。

動かしてみていい？

いいわよ。

いい感じだ。作戦前の雰囲気が出てきたな。

これでイベントシーンの編集の説明も終わりね。かなり駆け足だったけれど、サンプルミッションやRS4thのスクリプトが参考になるから、見よう見まねで少しずつ編集していけば良いと思うわよ。

第7回：複数スクリプトの統合

今回はスクリプト解説の仕上げ、複数スクリプトの統合方法を説明するわね。タイトル画面から始まって、ブリーフィング→ミッション開始→ミッションクリア→次のブリーフィングへ...という流れを制御するわよ。

おぉ、なんだか途端にゲームソフトっぽくなってくるな。確か、SDKに付属しているサンプルミッションもそんな仕組みだったよな。

どうやって作るの？

スクリプトの最後で、別のスクリプトを呼び出す、という方法よ。リレーのように次々に切り替わっていくイメージね。言うのは簡単だけれど、ミッション失敗と成功とで次のミッションに進むかを決めたり、タイトル画面で「FreeMission」を選んだときの処理を実現したり、というシステムを全部最初から作るというのはさすがに大変でしょう。

「大変でしょう」って、そりゃそうだが、その言い方からすると何か方法があるんだろ？

SDKのサンプル自体が、フレームワークになっているから、それを使えばいいわ。

フレームワーク？

「枠組み」という意味ね。形が既に決まっているから、中身を入れるだけ、ということよ。仕組み自体は今あるものをそのまま使って、画像とテキストだけを用意すれば良いようになっているわ。編集する場所さえ分かっていれば、難しいことを考える必要は無いわよ。

それなら何とかなりそうだね。

サンプルミッションをこれから説明していくけれど、実際に作業して自分のミッションを作ろう、という場合は、まず名前を決める必要があるわよ。SDKのサンプルは文字通り「EditSample」だったけれども、好きな名前を決めなさい。とりあえず今は「hogehoge」でも何でも良いでしょう。

なんか、前に聞いたな、その「ほげほげ」って。

何でもいい、という意味よ。実際は自分が作りたい名前にしてね。フォルダを作ったら一旦サンプルの中身をコピーしてしまうといいわよ。フレームワークを丸ごと持ってくるイメージね。次に、SphereEngine起動設定ダイアログで表示される名前を変えるには、フォルダ名を変えるだけで不十分で、EditSample.rspのファイル名を書き換える必要があるわ。このファイル名を変えることで、起動設定ダイアログで、自分が決めた名前のパッケージを選ぶことが出来るようになるわよ。

「EditSample_edit.rsp」ってファイルはどうするの？「Hogehoge_edit.rsp」に変えればいい？

その通りよ。中身を比較してもらえれば分かると思うけれど、エディタを起動するかどうかの違いね。説明の都合で、はじめからずっと一つのミッションの作り方の説明をしてきたけれど、実際はこの作業を先にやって、自分が作るべきゲームの場所を作ってから、作業に入るのよ。

とりあえず名前を変えただけだが、これを動かしたらどうなるんだ？

中身が何も変わっていないから、今までと同じになるわね。やるべき作業の手順を先に列挙しておくわね。

１．フォルダ名変更に伴うファイルパス指示の書き換え
２．ミッション名称及び構成定義ファイルの変更
３．タイトル画像の用意
４．ブリーフィング画像とブリーフィング解説文章の作成
５．初期武装の変更
６．ミッションの作成

結構色々あるんだな。

そうは言っても今まで説明してきたミッション内容そのものの作成に比べたら、単純作業が多いから、大丈夫よ。最初はファイルパスの書き換えね、スクリプトや画像を読み込むのに、今までずっと「SampleEdit」というフォルダを使っていたから、これを「hogehoge」に書き換える必要があるわ。具体的なものは以下に列挙するわね。

・(自分で決めたフォルダ名)/script/define.inc
・(自分で決めたフォルダ名)/script/version.inc
・(自分で決めたフォルダ名)/sample_map.rsu
・(自分で決めたフォルダ名)/sample_unit.rsu

内容は中身を見れば分かると思うから説明は省かせてもらうわ。

なぁ、リサ。sample_mapとかsample_unitのファイルの中に書かれている内容なんだが、これは多分3Dモデルとテクスチャの設定だと思うんだが……。

あら、そこに気づいたのね。そうよ、その2つのファイルの内容を追加すると、好きな建物やユニットを追加できるようになるわ。どこかで解説しようと思うけれど、今は説明しないで次に進めさせて欲しいのよ。気になる場合はRS4th_map.rsuやRS4th_unit.rsuを参考にして試してみるといいわよ。RS4th_unit.rsuを書き換えるだけでも機体や武器の性能が変わるわよ。

じゃあこれ終わったら私のR-27にだけミサイル1000発、積めるようにしておこう。

あるわけ無いだろう、そんな機体。

次に進んで良いかしら。2番目はミッション名称の変更よ。いきなり最初に全てのミッションの名前が決まっていることは無いと思うけれど、後から変えられるから、とりあえず最初は仮バージョンでも何でも、書いておくということになるわね。編集するファイルはこれよ。

・(自分で決めたフォルダ名)/script/mission_name.inc

サンプルは3ミッションなので3行あるけれど、好きなだけ増やしたり減らしたりできるわ。左から順に説明していくと、最初の「id」はミッションの識別番号。フレームワーク内部ではこの数字で判断しているわよ。とりあえず10刻みにしてあるから、特に理由が無ければこのまま40/50/60...と増やしていけば良いわよ。次がブリーフィングのスクリプトファイル名で、さらにその次が武装選択画面のスクリプトファイル名、ミッション本体のスクリプトファイル名、というように続いているわ。大抵の場合は01/02/03/04/05...というように名前を付けていけば良いと思うけれど、そこは好きにしてもいいわよ。武装選択のスクリプトはサンプルでは1種類しかないけれど、何種類か用意しておいて、途中のミッションから変えると、基地を移り変わっていくような演出が出来るようになるわね。ストーリーの都合でブリーフィングや武装選択画面が無い場合もあると思うけれどその場合は空文字「""」にしておけばスキップされるようになるわ。その次の「name」は文字通りが名前で、ポーズ中や、タイトル画面で「FreeMission」を選んだときに表示される名称よ。最後がヒントで、これもポーズ画面で表示されるわよ。ちなみに、最後にある「{id:-1},」という1行は必要だから消さないでね。

この前作ったミッション1つだけしか場合はどうやって書けばいいの？

1行分だけ書けばきちんと動くわよ。タイトル画面でContinueとかFreeMissionが表示されてしまって少し奇妙だけれど、大きな問題ではないでしょう。さて、3番目はタイトル画面の画像の用意よ。PhotoShopでもGIMPでも何でも良いから画像を用意しておいてね。ファイル名は以下の通りよ。

・(自分で決めたフォルダ名)/img/title_back.jpg
・(自分で決めたフォルダ名)/img/title_caption.png

2つ用意してあるけれど、実際は「title_back.jpgの上にtitle_caption.pngを重ねて表示」しているだけだから、title_back.jpgだけに背景も文字も書いてしまっても構わないわよ。

半透明ファイルは作るのが面倒だから、助かるな。

次がブリーフィングの作成ね。大規模なプロジェクトだと、いきなり最初に全部ブリーフィングだけ作る、ということは無いだろうから、実際はいろいろな場所を少しづつ作っていくだろうけれど一旦全部説明してしまうわね。まず画像はタイトル画像と同じフォルダに用意しておいて。ファイル名は何でも良いけれども「briefing_01.jpg」というように後から見て分かりやすくしておいたほうが良いと思うわよ。

ブリーフィング画像のこの文字とか矢印はどうやって作ってるの？

普通にPhotoShopで描いているけれど、それなりの技術が要るのは確かよね。ブリーフィングに絶対に画像が必要、というわけでもないし、実際過去の「RaidersSphereOtherMissions」の収録作品では文字の説明だけのブリーフィングも沢山あったから、無くても良いと思うわ。画像を用意したら次は文章を書くわよ。さてここで久々にエディタに戻るわよ。ブリーフィングもスクリプトだから、編集や動作確認にはエディタを使うのよ。サンプルミッションの「Briefing01.plc」をそのまま使いましょう。とりあえず「Briefing01.plc」を読みこんでみてもらえるかしら。。

何にも出てこないよ。

サンプルのブリーフィングは文字と画像だけだから何も無くて当然ね。それではパスのリストから「main」を選んで編集するわよ。

story_background(0,"briefing_01.jpg",{x:0,y:0,z:0},FALSE); // 背景読み込み

11行目のstory_background関数でブリーフィング画像を読み込んでいるから、先ほど作った画像はここで指定するわよ。画像を用意しない場合は真っ黒のbmpファイルか何かを用意してそのファイルを指定するようにしてね。

story_message("", "対地攻撃のテストミッションです。島に配置されたブイを全て破壊してください。");
story_wait_key(); // キー入力待ち

この2行で、メッセージを表示して、キー入力を待ち受ける、という処理をやっているわ。だからこの2行をコピー＆ペーストで沢山増やしてから、中身の文字を書き換えればブリーフィングのメッセージが次々に表示されるようになるわよ。必ず2行セットにしてね。

go_to_hanger("Mission01.plc"); // 武装選択画面へ

最後のこの行で、武装選択画面へ進むわよ。武装選択画面のスクリプトファイルを指定するのではなく、その次のミッション自体のファイル名を指定することに注意してね。これでブリーフィングは完成よ。F5キーで実行するとブリーフィングだけが動くから、確認しておいてもいいわね。

タイトル画面とブリーフィングを作ったから、これで全部出来上がりじゃないの？

あともう一つ重要なものがあるわ。ゲームを始めたとき、最初から選択されている武装の設定よ。このファイルを開いて編集するのよ。・(自分で決めたフォルダ名)/script/default_weapon.inc 内容はコメントを読んで判断して欲しいけれど、ここで設定した内容が武装選択画面の選択肢や、ミッション本体のスクリプトのこの記述、

set_player_unit(gamedata.player_unit); // プレイヤーの機種を設定
set_player_weapon(MAIN_PYLON, gamedata.player_weapon[0]); // プレイヤーの武装を設定
set_player_weapon(SUB_PYLON, gamedata.player_weapon[1]); // プレイヤーの武装を設定
set_player_weapon(CENTER_PYLON, gamedata.player_weapon[2]); // プレイヤーの武装を設定

これに繋がっているのよ。フレームワークによって細かい所は全て隠されているけれどね。この講義で以前説明したときには、このようになっていたけれども、

この部分を上の例のように書き換えると、武装選択したとおりの武器に切り替わるから、必要に応じて書き換えておいてね。

でも、そうすると、R-10が出なくなっちゃうんじゃない？

いいえ、大丈夫よ、gamedataというのはゲームの途中経過を保存する変数だけれども、そこに今選択している機体の情報が入っていて、そこにしっかりと"R_10"と記録されているはずよ。気になるならばsavedataフォルダの中に出来たセーブデータを見てみると良いわ。スクリプトの書き換えはもう一箇所あって、ここの部分よ。

init_common("", "", "", __SAVE_NAME__); // "gamecommon.spt"の初期化

だいぶ前に、説明した部分だけど、複数ミッションのときに使う、と言ったわよね。今なら正しく理解してもらえると思うわ。まず最初の引数は、今動かしているスクリプトファイル名、「Retry」を選んだときに同じミッションを最初から再開したり、Pause中のヒント表示の名前を取り出すのに使うから正確にね。よ。2番目が武装選択画面のスクリプトファイル名。ポーズ中に「Return to Hanger」を選択した場合はこのスクリプトが動き出すわよ。3つ目がミッションクリア時に動作するスクリプト。普通は次のミッションのブリーフィングファイルになるはずよ。全部を正しく書くとこうなるわね。

init_common("Mission01.plc", "Select.plc", "Briefing02.plc", __SAVE_NAME__); // "gamecommon.spt"の初期化

サンプルミッションのinit_commonと同じになったな。そういう意味だったんだな。あれ？そういえば最後のミッションはどうするんだろう。「次のミッション」は無いぞ。

そういう場合はこう書くわよ。

init_common("Mission03.plc", "Select.plc", "", __SAVE_NAME__); // "gamecommon.spt"の初期化

次のミッションが無いのだから正直に空文字「""」を指定すれば良いわ。さて、これでようやく全部終わりよ。先にミッション本体を作っておいて、今回の説明の通りに組み込んでもいいし、先にブリーフィングを作っておいてから、それにあわせてミッションを作るのでもどちらでも良いわよ。先ほども言ったけれど、実際に数ミッションあるような大規模プロジェクトの場合は、ブリーフィングとミッション本体を徐々に作りこんでいくようなプロセスになるわね。詳しく解説しようとしても、スクリプトがどういう、という話ではなく、ソフトウェア開発プロセスや管理の話になってくるからあまり踏み込まないでおくわね。

でも実際にこれから冬コミに向けてのゲーム開発を進めていくんだろう？

そうよ。要所要所のポイントや、これまで説明していないエディタの使い方の解説をしながら、進めていくつもりよ。

第8回：プロジェクト企画

基本的なミッションの作成方法は大体説明が終わったから、いよいよゲーム本体を作っていくことにしましょう。最初にノブユキさんが言っていた企画書を書こうと思うのだけれど……

早速書こうよ。でも何書けばいいの？

そんなことも分からないで作るつもりだったのか。まずはストーリーからだな。どういう風にするかな。

最後まで話を聞いてちょうだい。ゲームの企画書と思うと色々誤解を生むからまずは別の話をするわね。それではエレア、あなたはこれから、例えば…そうね、カフェを開店するとします。何を決めないといけないかしら。

え……値段とか？んー、それよりも先に内装だね。南国風の素敵なお店がいいな。

それよりもまずは場所だろう。ウチの入り口に屋台を出すのか、それともターミナルのテナントを借りるのか。まぁどこでも構わないが。

そうね、他には？

お店の名前だ！

はい、場所と店名が決まりました。他には？その店では、食事は食べられるのかしら？

俺は料理が得意じゃないからだめだぞ。シェフを雇っても利益が出るほどお客が来るならいいが。

料理がおいしければ客は来るんじゃないの？

ちょっと待て、それだとカフェじゃなくてレストランになってしまうぞ。そもそも、ウチの飛行場にそんなに大勢は来ないから、いくら旨くても……。いや、中央空港に店を出す話だったっけか？

それくらいでいいでしょう。今話したような、カフェをオープンする前の決め事は、言ってみれば「カフェの企画」とも言えるわよね。それを文書にすれば企画書よ。企画が決まってなければカフェの開店準備は一切出来ないわよね。

なるほどな、リサの言いたいことが分かったぞ。ゲームの企画書は「ゲームを作り始める前の決め事」を書けってことだな。

その通り。

じゃあストーリーはどうするの？

ストーリーを書くのは企画ではなく設計の段階よ。この図を見て。

これはソフトウェア開発モデル、と呼ばれるもので、開発の流れを表しているわ。現実にはこんなシンプルに分けられるものではないけれど、ゲームもソフトウェアの一種だから考え方は同じよ。

えっと、今は一番上なんだね。

一番最初だから、何も決まっていない状態ね。ここでの仕事は「企画書」というアウトプットを出すことよ。自分一人で作るのであれば、文書化する必要は無いけれど、中でやらなければいけないことは同じよ。この図を見ると「企画書」はその次の「概要設計」で必要だ、ということになるわよね。そうすると、必要になる項目が見えてくるわよ。ざっと挙げると以下のようなものね。

・タイトル（もしくはプロジェクト名称）
・プラットフォーム
・ジャンル
・発売日(公開日)
・開発期間
・対象プレイヤー
・想定総プレイ時間
・ゲームのボリューム（ステージ数など）
・価格
・販売方法(公開方法)

ここで言う「ジャンル」とは格闘ゲームとか、JRPGとか、シューティングとか、そういうものよ。市販ゲームで見る「なんとかかんとか騎士道ファンタジーアクションゲーム」という宣伝文句みたいなものは「ジャンル」ではなく正しくは「キャッチコピー」だから「実装」において考えるもので、今は考えてはダメよ。

意外に、少ないんだね。

一人で同人ゲームもしくはフリーソフトを作ることを想定しているから、決めることはゲームそのものに関することだけだから、これだけね。同人ゲームでも多人数で開発したり外注が発生するものでは、役割分担や外注費用など、人員の采配に関わる項目が必要だし、さらにはゲーム会社のようにビジネスとして進める場合は、予算計画、販売計画、IP（知的財産）管理なども全部必要ね。さらに全ての要素において「競合他社にどのようにして勝つか（もしくは戦いを避けるか）」という戦略の説明が一番重要よ。要するに『その企画が組織として実行に値するか否か』を判断するために必要な情報全てが書かれている、それが企画書よ。

だんだん中間管理職みたいな話になってきたな。

そうね、ゲームだからと言って特別なことは何も無くて一般的なビジネスやものづくりと何も変わらないわよ。電プロさんの話なんだけど、ゲーム会社の入社志望者が書いたという企画書をいくつか見たことがあって、そのほとんどがそれはそれは酷いものだったそうよ。説明は1/3ページだけで後はずっとイラストだとか、対象顧客層もゲームのルールも何も書かずにひたすら登場キャラクターの紹介が続くとか……。そんな資料で上司や社長や投資家に何を説明するつもりかしらね。

手厳しいな。

ゲームのティザーサイトのようなイメージが先行してしまっているのね。「企画書の書き方」とでもネットで調べて見ると良いと思うわよ。ゲームと全く無関係に思える営業資料のようなものが沢山出てくるけれど、実際のゲームの企画書はこういうものに非常に近いわよ。説明はこれくらいにして、それでは実際にこれから作るゲームの企画を作っていきましょう。

まずはタイトルだね。

ここで言うタイトルとは商品名称であることもあるけど、最初から名前が決まっているのは続編モノくらいだから、今は単にプロジェクトの名称を表すものでいいわ。実際、初代RaidersSphereも企画時は単に「フライトシューティング」と呼んでいたわ。実はプロジェクト名称は既に冬コミのサークルカットに書いてあるわよ。

ほらね。

えっ、まさかこの「SphereEngine4で4ヶ月で完成させたフライトSTGの新作」がタイトルだって言うの。

そうよ。ちょっと長いけれど、これだとプラットフォームも開発期間も分かるわね。実際は2ヶ月しかないし、プラットフォームと開発期間は別の項目に書くからプロジェクト名称は「C87新作のフライトSTG」と書き換えてしまってもいいわね。ここまで決まったわね。

・プロジェクト名称：C87新作のフライトSTG
・プラットフォーム：SphereEngine4（WindowsPC）
・ジャンル　　　　：フライトSTG
・発売日　　　　　：2014/12/30
・開発期間　　　　：2ヶ月

「対象プレイヤー」って何？

ゲームを無料でダウンロードしてもらうにしても、コミケで売るにしても、どういう人たちに向けて作るか、ということよ。「顧客層」という言葉のほうが分かりやすいかもしれないわね。

コミケで売るんだから、顧客って言ったらコミケの来場者じゃないのか？

確かにそうなんだけれど、コミケの来場者60万人全員が買うわけでもないでしょうから、細分化が必要ね。普通は顧客層というと「小学生男子」だとか「成人女性」だとか、もしくは本格的な例では「貧血気味の専業主婦」だとか、趣味嗜好や必要品が想像できそうなカテゴリー分けをするのよ。

ゲーム買うのに貧血とか関係あるのかな。

あくまで一般商品の例よ。でもNintendoの「WiiFit」などは、一見するとゲームとは思えない非常識な顧客層を定めて、それにあわせて製品開発をした好例ね。企画の勝利と言ってもいいわよ。ただ、これから作るゲームはRS4thの追加ミッションのような扱いにするつもりだから、あまり難しいことを考えずに「RS4thをプレイした人で、もっと難易度の高いミッションを遊びたいと思う人」で構わないと思うわ。ここの内容次第でゲームデザイン全体が変わってくるからきちんと考えてね。

次は「想定総プレイ時間」か。何時間にすればいい？あんまり長いゲームだと、作るのも大変そうだが。

次の項目であるボリュームとも関係があるから同時に決めるけれど、1回で全部遊べる程度のボリュームにしようと思うから、3時間ほどかしらね。ミッション数については大きなイベントやギミックを仕込まないで作ることを考えると1ミッションそれほど時間が掛からないと思うから、とりあえず10ミッションにしておきましょう。ちなみにRS4thでは30ミッションで総プレイ時間20時間、という企画だったわよ。クリアまで1ミッションあたり平均30分、それ以外のストーリー部分に5時間、という計算ね。速くクリアしてしまう上手なプレイヤーは武装コンプリートのために2週目をプレイするだろうからその場合でもやはり20時間、という想定もしていたそうよ。ここは同人誌で言うと「ページ数」に該当するようなものだから、値段設定にも関係してくる重要な項目ね。

ここまで決めたものをまとめてみたぞ。

ありがとう。残りの決定事項は売り方に関係する内容ね。これから作るのは家電や食品ではないから、相場というものは無くて、自由に決めるしかないのだけれど、目安としてはプレイ時間やステージ数、CG枚数、声優の有無、テーマボーカル曲の有無、などを基準に、他のゲームと見比べると良いと思うわよ。コミケ会場に関しては体験版の無料配布や100円頒布というパターンを除いて、完成品だと大体500円～2000円くらいが多いわね。卵や牛肉と違って、安くすれば喜ばれて沢山売れるかというと、そうでもないから難しいところね。

じゃあ中間を取って1000円くらい。

おいおい、いい加減すぎるぞ。500と2000の平均だと1250円だ。でも、2ヶ月の短期間で作って売る、って公言してるゲームで1000円って高くないか？500円でも良いと思うぞ。

そうね、実験品だし私も500円が良い思うわ。最後が販売方法ね。「コミックマーケット87で頒布する」というのは当初の企画の存在意義から決まっているけれど、後はどうしようかしら。

お店では、売るのか？

そんなことできるの？！

出来るわよ。もちろん一般の店舗ではなくて、同人ソフトの取扱店だけどね。元々同人誌の委託販売をしていたお店が同人ソフトを扱い始めた、という経緯もあって、「書店委託」や「委託販売」という呼び方をするわね。

ところで、お店で売ってもらう場合は結構お金もかかってくるよな。

場合による、としか言いようが無いわね。今回は在庫を多めに作って、それを卸すだけにするわよ。逆に製造をCD工場に発注するような規模になると、企画の段階で販売店を想定して、想定販売数とその販売手数料、製造原価及び流通経費、販促経費を全部計算して企画書としてまとめるけれど、今回はそこまで沢山売るつもりは無いから、今は考えなくてもいいでしょう。ちなみにRaidersSphereシリーズは初代の頃から必要な費用が100万円を超えていたから、毎回資金繰りまで含めてきちんと計算して、企画書に記載していたそうよ。さて、これで全部決まったわね。

できたー。

でもなぁ、これ。どういうゲームかさっぱり分からんぞ。

それは当然よ。まだ何も作っていないのだから。現実にはこれに「添付資料」としてストーリーの草案や操作方法、ゲームのルール、イメージイラストなど、必要に応じて追加されるわよ。注意しなければいけないのが、これらはあくまで企画の妥当性を判断するための参考資料として用意されているのであって、企画書そのものではない、ということ。つまり途中で変わることがある。言い換えると、決定した事項ではない、ということね。

確か最初に、企画は事前の決め事だ、ってことを言ってたな。

そうよ。だから概要設計に相当する物語の詳細や操作方法の説明は、現時点で決まっていないはずだから、これを企画書の本体に入れることは出来ないし、もし仮にストーリーやルールに「決定事項」があるのならばもっと簡潔に書けるはずよ。具体例を挙げれば、「忠臣蔵」という題材のゲームを仮に作ろうとするならば、史実どおりに元禄15年の殺傷事件を舞台にするのか、それともこのお話をモチーフにしたファンタジー作品にするのか、というのは対象プレイヤーにも関わる重大な事項だから、ストーリーに関わる事項だとは言え、企画書にきちんと書くべきね。添付資料としてではなく。

おお、何だ。ストーリーを書くこともあるのか。

いえ、ストーリー、というよりは特徴を簡潔に1行でまとめるだけよ。本来「企画書」というのは企画を誰かに説明するものだから、企画書におけるストーリーの説明が何行も、ましてや何ページにもなることは無いわよね。ちなみに今作っている企画書においては、ストーリーをどうするかはゲーム開発における重大な事柄ではないから何も書かないわよ。あえて言うならば、題材について開発日記で言及していたから参考情報に加えましょう。そうそう、忘れていたけれど電プロさんがこのプロジェクトにおいて「イラストを描かない・モデルを作らない・声を付けない・世界観を作らない」と宣言していたわね。これはゲームを作る前の決め事に他ならないから、企画書に書き加えるべきね。最終的にこうして完成よ。

・プロジェクト名称：C87新作のフライトSTG
・プラットフォーム：SphereEngine4（WindowsPC）
・ジャンル　　　　：フライトSTG
・発売日　　　　　：2014/12/30
・開発期間　　　　：2ヶ月
・対象プレイヤー　：RS4thをプレイした人で、もっと難易度の高いミッションを遊びたいと思う人
・想定総プレイ時間：3時間
・ステージ数　　　：10ミッション
・価格　　　　　　：500円（委託価格は未定）
・販売方法　　　　：C87及び委託販売
・ローコスト＆短納期化について：イラストを描かない・モデルを作らない・声を付けない・世界観を作らない
＜参考情報＞
ストーリーについては、第5テラストラクチャの訓練兵およびその訓練内容、という筋書きで検討中。

今度こそできたー。

次回は概要設計に入っていきましょう。ストーリーを決めたり、ミッションの内容を決めたりする一番楽しみな部分よ。

第9回：概要設計

今回は、ゲーム全体のデザイン、つまり設計を進めていくわよ。「ゲームデザイン」と言うと誤解を受けがちだから、これからもあえて「ゲームの設計」を言わせて貰うわね。だから設計書もしくは仕様書を作ることが今回の仕事よ。繰り返しになるけれど、「デザイン」とは日本語で「設計」のことよ。

何を今更、当たり前なことを。

え？そうなの？「ゲームデザイン」と「ゲームの設計」だと、なんかイメージが全然違うなー。

そうね、世間一般のイメージだと、「ゲームデザイン」という仕事は、キャラクターの登場シーンを考えたり、必殺技の強さを決める仕事のように思われがちだけれど、実際はそのような作業は全体の1％もなくて、ゲーム内の全ての振る舞い、例えば、ポーズボタンを押したときに表示されるメニューの表示文字が英語なのか日本語なのか、キャラクターが武器を持ち替えたときに動作パラメータをリセットするのかしないのか、戦闘シーンが終わったときのフェードインは黒なのか白なのか、こういう細かな動作全てを決めて、それを仕様書に落とし込む、という仕事よ。「映画監督」や「建築士」と同じくらい誤解されがちな仕事よね。それぞれ「映画の製作工程を指揮命令する人」「建築物の工事に必要な図面や行政への提出資料を作る人」といえば実態が分かりやすいでしょう。

結構地味なんだね。

ははーん、言いたいことが分かってきたぞ。ゲームデザイン、ゲームの設計というのは、ゲームの製作を指揮命令したり、画やプログラムを書くための指示書を作るということだ、ってことだろう。

そうよ。まぁ、指揮命令については一般的には「ディレクター」と呼ばれる人がやる仕事だから厳密には違うけれど、同人ゲームの規模の場合、ディレクターとゲームデザイナーは兼任することが多いみたいだから、あまり細かく考えずに、監督や建築士と同じような役割だと思えばいいわよ。それでは具体的に始めましょう。建築の例をまた出すけれど、土地と建物の大きさと簡単な間取り、それと全体予算だけを書いた、設計の前段階のものを「プラン」とか「企画」というそうよ。建築士の先生はこのプランをもとに、設計を進めていくそうよ。さて、私たちにもこの「プラン」に似たようなものがあったわよね。

前回の作った企画書だ。これだね。

企画書をもとにして設計を進めていくんだな。

今回は「概要設計」だから、細かな内部の振る舞いではなく、全体の要素のつながりを決めるまで、が仕事ね。

具体的にはどんなものだ？

普通ならば、ゲームのルールを設計する、というのが一番大きいけれど、SphereEngineを使ってフライトシューティングを作る以上、ここは既に決まっているのよね。だから、さっそくゲーム全体の流れを決めていくわよ。具体的にはストーリーの流れとミッションの内容ね。それに加えて、ストーリー分岐や2週目があるならばその条件や結果も全てここで決めてしまうわ。

ストーリーを書くんだな。でも、全部で10ミッションにしないといけないんだよな。

その通り。企画書に書かれている内容に合わせていくけれど、いきなり最初から順番に細かく書いていっても大抵の場合破綻するわよ。よくあるでしょう？同人マンガやWeb小説で、「全10話」と最初に謳っておきながら、「最終話その2」「～その3」「～その4」というようにいつまでも続いていくパターンが。これらは商業誌のような「人気があるから続けていく」という事情ではないと思うのよね。

計画性が必要だな。

あー私、そういうのダメダメ。

いいえ、計画を作る必要はあるけれど、本人に計画性が必要だとは限らないわよ。

どういう意味？

概要部分から少しずつ作って、だんだん細かくしていけば、大きな間違いはなくなるわよ。まず、10ミッションということは一旦忘れて、最も『ざっくり』したストーリーを考えてしまいましょう。今回からは、検討のプロセスの解説は省いてしまうけれど、最初のたたき台はこうよ。

＜物語の舞台＞
場所：RS4thと同じ21世紀末の金星。
時間：VMIと治安軍が戦争を始めるより少し前、何年何月という特定はしない。
＜登場人物＞
主人公：今日から第3課程に入る訓練生。名前なし。特別な才能、境遇、人物ではない。一般人として扱う。
教官：第3課程専属の教官。鬼軍曹風。ただしハートマン軍曹ではない。
＜ストーリー＞
・第5テラストラクチャ付近で基本的な訓練ミッションを行う。R-44固定。
・実弾演習を行う場所へ移動し、各種武装を使った訓練ミッション。
・要塞のような別の地形へ移動し、戦術訓練を行う。
・試験中に敵襲があるが、これを全滅させる。卒業試験終了としてエンディングへ。

抜け漏れがないように、「いつ、どこで、だれが、どのように、なにを、どうした」という5W1Hを意識してね。

えぇ？いきなりネタバレ！？

今まさにこの場でゲームを作っているのだから、当たり前でしょう。このようにストーリーを最初から最後まで決めてしまうのよ。これならば破綻のしようがないでしょう。10ミッションは忘れて、とは言ったけれど、全体の容量をある程度考えながら決めていってね。この時点で、自分の作るゲームの構成要素が過不足なく盛り込めるか、きちんとチェックしてね。登場人物が多すぎるとか、お話の前後関係がおかしいとかいう問題は、この時点で全て潰せるはずよ。

なるほど。機械図面の設計と同じだな。あれだって、最初に大まかに書いて、全体のシステムに問題ないか検討してから、細かな部品ごとの図面にバラすからな。

次にもう少し細かくしていくわよ。

＜ストーリーの流れ＞
【Mission01】
第3課程の教官として自己紹介。そのままミッション1の内容説明へ。
↓
操縦訓練のミッション。
↓
【Mission02～??】ミッション数は後で再検討
肩慣らし終了、として実弾演習場へ移動。サンプルミッションの地形を使う。
↓
低空爆撃、急降下爆撃、投下型爆弾、ロケット砲、機銃などの実弾訓練をこなす。
↓
【Mission??～09】ミッション数は後で再検討
いよいよ実践訓練を行う。すり鉢要塞状の地形のある島へ移動。
↓
要塞攻略や敵機に囲まれる状況などの訓練。
↓
【Misison10】
「試験」のミッション中に突如正体不明の勢力に襲撃される。
↓
試験は中断するが、この敵を撃破したことで、試験は合格扱いにしてもらう。
↓
おしまい

こうやってトップダウンで細かく決めていくことで、過不足も矛盾もないストーリーを作ることができるのよ。物語の大きな転換点をまずは全て抑えるのがコツね。今回作るゲームの場合はあまり大きな変化はないけれど、RS4thにおいては、ノースサイトが破壊されたり、途中でVMIが降伏したり、ソールを見つけたり、というストーリーの根幹に関わるイベントが多かったから、こういう場合はミッションの具体的な中身を決める前にそれらの繋がりを先に明らかにしておくことが必要ね。

「【Mission02～??】」って書いてあるけど、数はここでは決めないの？

ミッションの内容も平行して考えないといけないから、先にストーリー側を固めてしまわないようにしているのよ。どういうストーリーで進んでいくか、ということと、その中にどのようなゲーム性を入れるか、ということを摺り合わせしながらまとめていくのよ。一旦ストーリー上の割り振りは考えないで、ミッション内容だけを列挙して検討するわね。

・教官機についていく
・着艦訓練
・低空爆撃
・垂直急降下爆撃
・ロケット砲練習
・無誘導爆弾練習
・敵機に囲まれた状態への対処
・火砲が並んだ要塞の対処
・対地連続攻撃（タイムアタック）
・対地、対空混合戦

このような内容の実現可否や工数を判断しながら、ストーリーに上手く入れていくのよ。ストーリーの進行上、必要不可欠なミッションもあるし、逆に特定のギミックを仕込むためにストーリーを変更したりすることもあるわよ。図にするとこのような関係性になるわね。

ストーリー同様に、前後関係も重要よ。例えば対地攻撃ミッションが連続したりしないような配慮が必要ね。ここの作り込みが甘いとプレイヤーに「単調」とか「作業」とか「お使いゲーム」という印象を与えてしまうわよ。

ミッション内容が10個あるから、このストーリーにちょうど当てはめていけばいいんだな。

その通り。途中の検討工程を全て省略してしまうけれど、最終的にストーリー概要及びミッション概要はこうなったわ。システムについても言及しておくわね。

＜物語の舞台＞
場所：RS4thと同じ21世紀末の金星。
時間：VMIと治安軍が戦争を始めるより少し前、何年何月という特定はしない。

＜登場人物＞
主人公：今日から第3課程に入る訓練生。名前なし。特別な才能、境遇、人物ではない。一般人として扱う。
教官：第3課程専属の教官。鬼軍曹風。ただしハートマン軍曹ではない。

＜場所について＞
・第5テラストラクチャはそのまま流用する
・サンプルミッションの地形を実弾演習場として使う
・模擬戦場は新規作成。4kmほどのカルデラ火山の島。
　外周部は完全なすり鉢状ではなく、一部が下がっている。

＜ストーリーとミッション内容＞
【Mission01】マニューバ訓練
説明：第3課程の教官として自己紹介。そのまま訓練の内容説明へ。
場所：第5テラストラクチャ周辺
内容：教官機についていく、一定の距離を離れてしまうと失敗。
技術的課題：教官機との距離と「視界に入っているか」をポイント化し、積算する。
↓
【Mission02】低空爆撃訓練
説明：肩慣らし終了、として実弾演習場へ移動。低空爆撃の説明。
場所：実弾演習場
内容：一定の高度以下を維持して地上目標を破壊する。
技術的課題：高さを常時監視し「一定以上の高度を一定時間以上維持する」という失敗判定が必要。
↓
【Mission03】着艦訓練
説明：着艦の練習の説明。
場所：実弾演習場
内容：非常に小さい板状の海上滑走路に着陸する。難易度ごとに位置や大きさが異なる。
技術的課題：とくになし
↓
【Mission04】垂直急降下爆撃訓練
説明：急降下爆撃の説明
場所：実弾演習場
内容：海上及び施設間の目標を破壊する。一定の高度以上に上昇させることで、急降下爆撃をしないとクリアできないようにする。制限時間も相当に厳しくする。
技術的課題：「急降下」であるかどうかを機体ピッチでも検知できる仕組みが必要。
↓
【Mission05】ロケット砲訓練
説明：ロケット砲のコツについて説明
場所：実弾演習場
内容：海上及び施設間の目標を破壊する。武装はロケット砲固定。機銃も使えなくする。
技術的課題：とくになし
↓
【Mission06】無誘導爆弾訓練
説明：爆弾の使い方について説明。
場所：実弾演習場
内容：海上及び施設間の目標を破壊する。武装は小型無誘導爆弾固定。機銃も使えなくする。
技術的課題：とくになし
↓
【Mission07】回避訓練
説明：最終段階として、模擬戦場へ移動する。敵に囲まれた際の回避方法を説明。R-21を選べるようになった旨を解説。
場所：模擬戦場
内容：いきなり多数の敵機に囲まれた状態でのスタート。単に全滅させればよい。時間はたっぷりと。
技術的課題：とくになし
↓
【Mission08】連続爆撃
説明：敵に反撃のタイミングを与えずに攻撃する重要性を説く。実際の操作方法の説明。
場所：模擬戦場
内容：カルデラ外周部に並んだレーダーを破壊する。制限時間を非常に短くする。
技術的課題：最終攻撃判定から一定時間以上破壊していなかったら失敗、という判定処理が必要。
↓
【Mission09】要塞攻撃訓練
説明：火砲が並んだ敵要塞の攻略について説明。地形が開いている箇所を攻めること。
場所：模擬戦場
内容：カルデラ内部に対空砲をずらずら並べる。全て破壊すればクリア。制限時間も短め。
技術的課題：とくになし
↓
【Mission10】総合訓練
説明：最終試験の前段階として、陸海空の総合戦闘訓練を行う、という説明。
場所：模擬戦場
内容：実際はミッション開始後に、所属不明の勢力が現れ、混戦状態に。全て撃破すると、「それだけの実力があるなら問題ない」として課程修了としてしまう。
技術的課題：とくになし

＜システムについて＞
・SDKのサンプルのフレームワークを全面的に採用する
・特に変わったギミックは新規開発しない
・ブリーフィングは解説画像を1枚もしくは2枚、紙芝居的に表示する
・武装の購入システムは使用しない
・Mission06以前は武器固定なので武装選択画面を使用しない
・Mission07以降は武装選択画面を表示する

これで出来上がりよ。今はまるでサクッと書いてしまったように思えるけれど、ここまでまとめるだけでも何時間も掛かっているし、RS4thではこの工程だけで2ヶ月費やしていたそうよ。

そんなにかかって何をやるの？

登場人物の絞り込みや地形の使い回しを徹底的に考えて省力化を目指したり、何より技術的な検討事項があまりにも多かったから、ミッション内容の実現可否を全て判断する必要もあったのよ。例えばスーパースカイスピアーの砲撃や雲海も、先に台本に書いてから、いざとなって「やっぱり出来ませんでした」というわけにはいかないでしょう？キャラクターの人数にしたって、実質的に5人で全てのお話を終わらせるのに相当苦労したそうよ。だからこの工程を省略していきなり作り始めると、大抵の場合はまとめきれなくなって中断、そのままフェードアウト、という結果を迎えてしまうわよ。

いわゆる「エターナる」ってやつだな。

なにそれ？

ちょっと昔の言葉だよ。途中で放り投げちまうって意味だ。

企画や技術面に何らかの問題がある場合はこの時点で表面化するはずね。単純に技術力、経験量が足りなくてまとめ切れない場合が多いと思うけれど、そういう場合は素直に規模を縮小して企画から練り直すのが得策ね。逆に言えばここまで工程が進めば、完成までの道筋は出来上がったも同然だから、あとは完成まではリソースの問題だけ、ということになるわよ。ゲーム会社が開発する場合は、経営状態によって実際にこのリソースの問題が表面化して開発中断、というパターンが少なくないけれど、個人開発ならばまずそういうことは無いでしょう。地道に作っていけば必ず完成するはずよ。

経営状態ってまた……切実だな。

第10回：組み立て

今回は、詳細設計と実装の話をしていくわよ。この図を使ってもう一度説明するわね。

前回概要設計まで進めたから、今回も詳細設計だけを最初から最後まで全部やる、ということもできるけれど、あまりお勧めしないわね。概要設計まではプロジェクト全体に影響があるから、途中で中断して次の工程に進むことは出来なかったけれど、概要設計で一つ一つのミッションの内容と繋がりを決めてしまったから、その中身を順番に作っていくことが出来るのよ。

それだと『体験版』とかが作れるな。

そうね。実際に遊べるようになるから、モチベーションも上がって来るわよ。

早速作ろうよ。今回はエディタを使うんでしょ？

まだちょっと早いわね。エディタを使うのは「実装」の工程になるから、少なくともその部分の「詳細設計」は先に仕上げておく必要があるわ。内容は多岐に渡るけれど、主な具体例を上げると以下のようなものを作る必要があるわよ。

・ストーリーテキスト（台本）
・用意すべき画像などの素材のラフ
・天候、BGM、その他環境条件の決定
・敵の配置状況の決定
・イベント発生条件の処理フロー
・ギミックの実現方法のアルゴリズム

ここで、いよいよ台本が出てくるわね。どのようなテキストが表示されて、どのようなユニットを置いて、どのようなスクリプトを書けばよいのかを最初に全て決めてしまうのよ。ここまで作ってしまえばあとはひたすら打ち込むだけだから、慣れれば1日で1ミッション作れるようになるわよ。

最後の方の2つ、「イベント発生条件の処理フロー」「ギミックの実現方法のアルゴリズム」、これって何？

これから書くスクリプトを図や言葉で表したものよ。イベントとギミックとで2つに分けて説明したけれど、本質的には「スクリプト」であって、違いは無いわ。フローチャート、という言葉を聞いたことがあるかしら？

定期検査の申請か何かに、そんな言葉が書いてあった気がする。

「あれをして」→「これをして」→「もし○○だったら××して」という説明の図だったでしょう？

あー、リサが言いたいのはプログラムのフローチャートのことか？

その通り。例えばこういうものよ。

慣れてくれば、このような「図」にしないでも書けてしまうけれど、最初は人に説明できるようにきちんと書くようにすることが、上達の近道よ。

こんなの書くソフトなんて持ってないけど。

手書きで良いと思うわ。人に見せるのでなければ、なおさらね。プロのソフトウェア技術者でもホワイトボードに手書きしながら、設計をレビューするくらいだから、全く間違っていないわよ。

しかし、手書きとはずいぶん乱暴だなぁ。

手書きだとラフにならざるを得ないけれど、かえって余計な装飾に気を取られない分、効率が良いのよ。人に見せるわけではないし、あくまで「事前に考える」という行為が重要よ。繰り返しになるけれど、設計とスクリプトに慣れてくれば、かなり省略して実装の工程に進めるようになるから、最初だけの辛抱ね。実際、電プロさんも3年目くらいから「フローチャート」は描かなくなったそうよ。その代わり、複雑な制御が必要なプログラムやスクリプトを書くときはこんなものを書いているそうなの。

・mainスクリプト（最初から起動）
※定型処理
開始時イベント
教官機はロックオンできない敵機として登録
見失いポイントと追跡ポイント初期化
traceスクリプトを動かし始める
while(1) {
　　※定型処理
　　if (教官機がゴールまで到達) {
　　　　if(追跡ポイントが一定値以上){
　　　　　　合格メッセージ（ほめる）
　　　　} else {
　　　　　　合格メッセージ（ほめない）
　　　　}
　　　　ミッション成功
　　}
}

・traceスクリプト（他のスクリプトから起動される）
プレイヤー機と教官機のハンドルを取得
while(1) {
　　if(イベント中) continue;
　　距離X = プレイヤー機と教官機の距離計測;
　　if (距離X > 一定値Y) {
　　　　見失いポイント++
　　　　if(見失いポイント>5秒分) {
　　　　　　不合格メッセージ
　　　　　　ミッション失敗
　　　　}
　　}
　　if (距離X < 一定値Z) {
　　　　追跡ポイント++
　　}
}

これがMission1のマニューバ訓練のスクリプトの設計よ。whileとかifとか、スクリプトの制御構文みたいなものが見えるわね。

こんな普通に日本語で書いて動くのか？

いいえ、これはあくまで設計書だから、スクリプトとして動作するわけではないわよ。

じゃあ、こんなの書いてどうするの？

こういったものを事前に書いておけば、実際にエディタでスクリプトを書くときに一切迷わずにどんどん書いていけるでしょう？台本も別途かいておけば、メッセージウィンドウの内容もそちらからコピー＆ペーストするだけね。「詳細設計」とはもともと「考える」ことと「コードを書く」ことを分割することを目的としているのよ。

考えないでも書けるようになる、ってことか？

「考えないでも書ける」というのは少し言いすぎだけれど、スクリプトの全体像を先に理解しているから、途中で処理の流れを見失ってしまうことが無くなるのよ。言葉で説明するのは難しいけれど、いきなりスクリプトを書こうとして陥りがちなのが、「自分は何を作るんだったけか？」と手が固まってしまうことね。そのような時は、詳細設計が甘いもしくは設計できたものを自分自身で理解し切れていない、という証拠だから、一旦エディタを閉じて設計の工程に戻ったほうがいいわよ。

なんか、面倒くさそうだね。最初から書いたほうが早くない？自分が何を作ろうとしているのかわからなくなる、なんてこと本当にあるの？

う～ん、言葉で説明するのは難しい、といったけれど、やってみればわかるわよ。そうね、では分かりやすい別の話題をするけれど、教官機はフィールドのどこからスタートするのかしら？そしてどのようなルートを通って、訓練自体は何分掛かるのかしら？

え？まだ作ってないけど。

じゃあエディタを開いて今すぐ入力してみて。以前説明した「パス」を使うのよ。

え～っと……。どこにしようかな。

なるほどな。エレア、そういうことだよ。今お前、手が止まってるだろ。考えてる最中だから何も作れない。

これで分かったでしょう？先ほどまではスクリプトの話をしていたけれど、ユニットの配置位置やブリーフィングの画像の内容なども同じよ。いきなり作るのではなくて、まず紙やテキストファイルなどで考えをまとめてからでないと、かえって時間が掛かるから、全てに対して事前の設計が必要よ。「考えないでも書ける」という程度まで細かくまとめることが必要ね。慣れればなれるほど、考えながら作っても手が止まることが無くなるから、ラフなものでも構わなくなってくるわよ。ラフとは言っても、かなりの量が必要で、電プロさんがRS4thを作る課程ではその場ですぐ破棄するものを含めると数百枚は書いたそうよ。例えば、第3テラストラクチャの高速道路だけでも4枚描いているわね。

数百枚だと？気が遠くなるな。

全部をいっぺんに書くわけではないから安心して。少し書いて、作って、少し書いて、作って、という順序よ。1日の作業で3枚のメモを書いたとして1年で1000枚に達してしまうでしょう？内容も本当に自分しか見ないような走り書きレベルのものだから、この程度のものでいいわよ。これは今エレアが作ろうとした教官機のルートの詳細設計の一部ね。

何が書いてるかさっぱり分からないんだけど。

今回は一人で作っているから他人が理解できるように書く必要は無いわ。そう考えると少しは気楽でしょう。RS4thのプロジェクトの規模で、こういうものの積み重ねならばあっという間に数百枚になってしまうのよ。

塵も積もれば、というやつか。

詳細設計の説明としてはこれでおしまいなのだけれど、実装において今まで説明していなかった要素が多いから追加で説明しておくわね。まず、スクリプトを順次起動する方法。具体的には上に書いた設計の「traceスクリプト」の起動方法ね。ミッション開始直後はイベントが入るから、すぐにカウント開始してはいけないから、途中から起動する必要があるわ。一つはcreate_thread関数を使う方法。もう一つはアンカーポイントをアクティブにする方法。プログラムがわかっている人には前者の方が手っ取り早いだろうけど、ここでは後者の説明をするわね。アンカーポイントの設定をこのようにするの。今までとどう違うか分かる？

あ、チェックボックスがOFFになってる。

「Active Script」のチェックボックスね。スクリプトが有効かどうかを意味しているわよ。ここがOFFだと、条件が満たされていたとしてもスクリプトは起動しない。言い換えれば、条件が満たされた状態であれば、有効になった瞬間に動作を開始するわよ。そして有効にするにはこのように書くのよ。

active_path_label("trace", true);

これをmainスクリプトの「traceスクリプトを動かし始める」という部分に書いておくと、イベントが終わった直後からtraceスクリプトが動作を始めるわよ。

ドミノ倒しみたいにどんどん動いていく感じだな。

そうね「ドミノ倒し」というのは良い例えかもしれないわね。もう一つ、これもドミノ倒しに似ているかもしれないけれど、パス上を通る教官機が一定の地点に到達したらメッセージウィンドウを表示する、ということを実現したいときにも、アンカーポイントの設定で出来るわよ。具体的にはこうね。

なんかこんなの、前に見たぞ。

イベントシーンでの自機とカメラの速度を設定するスクリプトね。あの時はパスの端、ユニットを登録するまさにその場所でスクリプトを書いたけれど、今回は途中に追加するわよ。こうすると、ユニットがその場所に到達した瞬間にスクリプトが動作するようになるわよ。

場所を条件にするのはだめなのか？「Label[OP1]がこのパスよりX+方向」みたいなのでも条件は満たすよな。

その通りだけれど、パスの上を飛んでいるユニットなのだから、素直に「ユニットがこのパスに到着」で良いと思うわ。ノブユキさんが言った今の条件は、どちらかというと、自由に飛行する自機や敵機に対して使うものなのよ。例えば防空識別県内に敵機が侵入したとか、一定高度以上に時期が高度を上げたとか、そういう条件よ。

そう言えば、高度を上げちゃダメ、ってミッションがいくつかあったよね。

あのミッションは実際にはアンカーポイントの条件を使うのではなく、全ての条件をスクリプトのアルゴリズムで書いているけれど、今説明しているような作り方でも実現できるわね。そうそう、勘違いしないで欲しいのは「ユニットがこのパスに到着」という条件は自機を上手に操縦してアンカーポイントに突撃しても、スクリプトは動作しないわよ。この条件はあくまで、パスに沿って自動的に動作しているユニットに対してのみ効果がある、というものだから注意して。「Cmd」欄で設定する条件と、active_path関数での有効/無効を色々組み合わせていくと、自由にミッションを組み立てられると思うわよ。

具体的なイメージが難しいな。

コツとしては、最初はあまり複雑なものを作ろうとしないことかしらね。サンプルミッションにも実装されているけれど、例えばこのスクリプトのように敵が半分に減ったときのイベントのように、単一条件で動作するものから始めるといいわよ。

何より重要なことは、とにかく１つでも完成させることね。この詳細設計の工程からは、一度に全部作るのではなく五月雨式に作っても、工程が破綻することは無いから少しでも動くようにしていくのが、モチベーション維持の意味でも完成の近道よ。実際に目で見ないと見えてこない部分というのも多いしね。ここまで出来るようになったら、あとは本当にひたすら作りこんでいくだけよ。もちろんバランス調整のような重要な仕事はあるけれど、とにかく「完成するか/しないか」という意味では今回までに説明した内容でほとんど全てよ。

努力と根性だな。

うわ～。地味だ。

精神論はあまり持ち出したくないのだけれど、正直に言うと否定は出来ないわよね。プロセス化していて、なおかつフルタイムで開発に専念できる状況ならば別なのだろうけど、そうなるとそれは『仕事』ということになってしまうし、世間ではそういう人をゲームクリエイターではなく起業家と呼ぶわよね。そのレベルまで目指してみる？

いや～、やめとく。

第11回：ユニット追加

ここ何回か難しい話が続いてしまったけれど、今回は簡単よ。ユニットの追加方法の説明をするわね。

あれ？だいぶ前に聞かなかったか、それ。

レーダーとか置いたよね。

配置ではなく、定義そのものの追加方法よ。例えば今回のミッションで標準の何倍も硬いトーチカ砲を追加したいのよ。スクリプトで装甲値を増やす方法も出来ないことはないけれど、装甲値だけでなく、他にも色々なパラメータが変えられるから、覚えておきましょう。

形や大きさも変えられるのか？

グラフィックのファイルも好きに指定できるから、3Dのモデルやテクスチャが作れるならばもちろん自分で作ったキャラクターも追加できるわよ。触りの部分の説明は第7回にしているけれど、「*.rsu」というファイルを編集するのよ。具体的な中身を見たほうが説明しやすいわね。rs4_unit.rsuというファイルを開いて見て。

なんかすごい、ごちゃごちゃって書いてある。

よく見ると「R-24」とか「地対空ミサイル」とか書いてあるな。この設定ファイルを読み込む仕組みなのか。

最初見るとあまりの量に圧倒されてしまうかもしれないけれど、RS4thに登場するあらゆるユニットを全部書いてあるからこれくらいの量になってしまうのよ。JSONという形式で記述されているけれど、基本的にはこういう構造よ。

定義名:{
"パラメータ名" : 内容,
"パラメータ名" : 内容,
"パラメータ名" : 内容,
"パラメータ名" : 内容,
},
...

例えば今ノブユキさんが見つけた「R-24」の項目を見てもらえるかしら。STABILITYのパラメータが3.0になっているわね。これは他の機種に比較して多いから、R-24の安定性の高さに繋がっているわ。一方でR-44の同じ項目を見ると3.8になっていて、もっと大きな値よね。

確かに乗ってみて分かるけど、R-44の方が機体の安定性が高かったね。

ここを書き換えると性能が変わるのか？他にも旋回速度や装甲の強さを表すパラメータが結構あるな。

その通り。R-10の項目を探して、例えばPOWERの値を2倍にしてみなさい。サンプルミッションの動かすと、速度が2倍になるはずよ。

おおー、速い速い！

ところで勝手に書き換えてしまっていいのか？RS4の方とのバランスとか色々あるだろう。

そこは心配ないわよ。RS4th本編とは別々でデータを持っているから、ここを書き換えても影響は無いわよ。注意が必要とするならば、敵機として出現するR-10も高速になってしまうことね。これを避けるためには、既存のユニットの書き換えではなく、新規ユニットとして追加する方法があるわよ。具体的には"sample_unit.rsu"というファイルに追加するのよ。29行目と30行目の間に追加するのが分かりやすいわね。ここに"RS4_unit.rsu"の129行目から241行目の内容をコピーしてちょうだい。そうそう、先ほど書き換えてしまった"RS4_unit.rsu"の部分は元に戻しておいてね。そうしないと敵機の速度が倍になったままよ。

コピーするのは、ちょうど中括弧で囲われているところだな。

そう。カンマも忘れないようにしてね。その次に、このままだと同じユニット定義が重複してしまうから、名前を変えましょう。30行目のこうなっているところを

R_10 {

こういう風に変えてみて

R_10_SPEED {

この部分をIDと呼ぶのだけれど、これで別のIDを持つユニットを登録したことになるから、自由に編集できるわよ。まずは名前ね。

"ALIAS"　　:　　"R-10",　　　　　//別名

この"ALIAS"というのは、エディタで表示するときの名前よ。だからこういう風に変えてみましょう。

"ALIAS"　　:　　"R-10(高速版)",　//別名

この状態で保存して、エディタを開いてみて。ユニット編集のダイアログに追加されているはずよ。最後のほうに追加しているからリストボックスの一番下ね。

「高速版」ってのが増えてる。

これを使えば、先ほど書き換えて作ったR-10を敵機または寮機として登場させられるわよ。自機として使う場合は、スクリプトの中で"R_10"となっているところを新しい名称の"R_10_SPEED"に変えればいいわよ。具体的には

set_player_unit("R_10"); // プレイヤーの機種を設定
ここを
set_player_unit("R_10_SPEED"); // プレイヤーの機種を設定

こうね。

速度だけじゃなくて、他にも全部変えても大丈夫？

大丈夫よ。名前もグラフィックスも全部変えれば、「新機体」が追加できるわよ。ちょっと大変かもしれないけれど、個々のパラメータ内容の説明はこの講座を一通り書き終わったら用意するそうよ。基本的には既存のユニットを探して、コピーして、必要に応じて書き換える、というやり方になるわね。さて、最初に話したトーチカ砲のパラメータを変えましょう。やり方は今までと全く同じね。"RS4_unit.rsu"からトーチカ砲を探してみて。

検索しても出てこないけど。

確か、名前が違うんじゃなかったっけか？

システム上の名称は「対空砲台」よ。英語の「BATTERY」で検索してもいいけれど。

あった。これを"sample_unit.rsu"にコピーするのね。

そうよ。ただしここで注意して欲しいのが、ユニットの親子関係ね。地対空砲や対空ミサイルの類は、砲身やランチャーをこちらに向けてから撃ってくるわよね。これは、それぞれパーツごとに分かれて制御されているのよ。具体的にはこの図のような構成よ。

土台があって、その上に回転する砲塔、さらにその砲塔の中には仰角をとるための砲身が入っているわ。だから基本的には3つ丸ごとコピーした方がいいわ。コピーするときは括弧とカンマも忘れないようにしてね。その後にIDと名前を編集すると別ユニットになるわよ。

どういう名前にすればいいんだ？

分かりやすい好きな名前に決めていいわよ。単に硬くしただけだからIDはそれぞれ「AA_HARD_BATTERY」「AA_HARD_BATTERY_TURRET」「AA_HARD_BATTERY_BARREL」とでもしておけばいいかしら。親子関係があるから、"CHILD"というパラメータの中のIDも全て書き換えておく必要があるわね。装甲値は土台で制御されているから、「AA_HARD_BATTERY_TURRET」の"DEFENSE"の項目を書き換えればいいわよ。これを保存して、エディタで確認するときちんと追加されているでしょう。

これでOKだね。

第12回：大地創造

前回はユニットを追加したから、今回は地形の追加よ。地形と言っても、マップを作るのではなく、地面の形そのものの構成よ。港湾や盆地、洞窟を追加する方法ね。あと、ビルなどの建造物を追加する方法も同じよ。

またファイルを編集するのか？

その通り。今回は「sample_map.rsu」を編集するわよ。

なんか2つ書いてある。

元々ここにはサンプルミッションの島と地面の3Dモデルを定義しているのよ。マップ編集のときに「サンプル島」というものを置いたのを覚えているかしら。あの地形もこのファイルで定義されているわ。ユニット同様に、このファイルに追記していけばいいわよ。

ところで、地形の3Dデータ自体はどうするんだ？

そうね。ちょっとここで地形の作り方に2種類ある、という話をしておこうと思うの。まずは正攻法というか、一番単純な方法。「3Dモデリングソフトで作る」という方法。Shadeやメタセコイアのようなモデリングソフトで「Xファイル」というものを作って、それを「*.rsu」に登録して追加しているやり方ね。この方法が一番汎用性があるし、地形のほかに、建造物や、またユニットの追加にも使える方法よ。当然の欠点としては、モデリングソフトが必要だし、それを使いこなせるようになる必要があるわ。

かなりマッチョだな。大体、3Dのソフトってすごく高いんじゃなかったっけか？

ウチにそんなソフト無いよ。姉さんは持ってるの？

無いわよ。無料のソフトも探せばあるけれど、使い方を覚えるのが大変だから、よほど本格的に作ろうという人でもない限り、手を出そうとは考えないほうが良いと思うわ。

じゃあ、もう一つの方法ってのは、何だ？

これから手順を説明するけれど、「XViewer」の機能を使って、3Dモデルファイルを生成する方法よ。SDKの中に「XViewer.exe」というソフトを追加したから、最新のSDKをダウンロードして用意しておいて。さて、具体的な方法だけれど、最初にざっくり言うとこのような手順よ。

１．グレースケール画像で高さ情報を用意する。
２．「大地創造」機能でモデルファイルを自動生成する。
３．テンプレートを使って"sample_map.rsu"ファイルを編集し、モデルを追加する。
４．テンプレートを使ってマップを編集する。

「大地創造」とか「テンプレート」って何のこと？

リサが順番に説明するだろ。ちょっと待っていろ。

まずは地形の元になる情報を用意するわよ。グレースケールのビットマップファイル（24bit）でサイズは500x500よ。1ピクセルあたり40mで、500x500だとちょうど20km四方ね。色については、白が高くて黒が低い場所を意味するわ。言葉で説明するより実物を見せたほうが早いわね。これはシェンリン山脈の高さデータ。

こっちはこれから新しく作るカルデラ状の島のデータよ。

こういうデータの作り方だけれど、「グレースケール地形高さ」で検索すると色々分かるわよ。完全にオリジナルで作る場合は、PhotoShopやGIMPなどの画像編集ソフトを使って作る必要があるわね。何もスキルが無いところからいきなり、というのはさすがに厳しいだろうけれど、それでも3Dのデータを作るよりはまだ良いと思うのよ。それに3Dデータを直接作る場合、ポリゴン数の調整なども必要だからかなり高度なノウハウが必要になるわよ。

なんだか似たようなパターンが続いているな。

あら、良い所に気づいたわね。このような基本パターンを事前に作っておいて「比較（明）」などでレイヤーを重ねると、簡単に作れるわよ。

そうやって画像を作って、次には何をする？

groundというフォルダがあるでしょう。その中に今回のマップ名称である「caldera」というフォルダを作って、その中に今の画像を保存して。形式はビットマップファイルよ。次に「XViewer.exe」を開いてみて。

真っ黒だ。

本来このソフトは3Dモデルの「*.x」というファイルを見るためのものだけれど、ここに地形データを作成する機能があるのよ。メニューバーの「拡張」→「大地創造」を選んで、先ほどのファイルを選ぶと、どんどん3Dモデルファイルが出来上がってくるわよ。今回は「caldera_.bmp」というファイル名にしたから「caldera_24.x」「caldera_25.x」...というファイルが出来上がるわよ。ビットマップのファイル名の後に2桁の数字が付与されるルールね。

ちょっと待ってくれ、一つじゃないのか？

巨大な一つのモデルにしてしまうと、ポリゴン数が多すぎてゲームが処理落ちしてしまうから、2kmごとに分割するようになっているのよ。

それと、真っ黒(R=0,G=0,B=0)のピクセルは海面と見なされてポリゴンが削除されてしまうから、盆地のモデルなどを作るときは注意してね。
次は、今作ったモデルをマップとして取り込む設定をするわよ。「template_map.rsu」というファイルを開いて、今作ったモデルに合致するように書き換えていくわよ。今作ったのは「caldera」という名前だったから、「template」となっている部分を全部「caldera」に書き換えて。それと、「EditSample」という表記も自分の作っているゲームのフォルダにあわせて書き換えてね。

えー、どれだけあるの、これ。

テキストエディタの「置き換え」を使えばいいでしょう。最後に全体をコピーし、「sample_map.rsu」のこの部分にペーストして。

ユニットを足すときと同じやり方ね。これでSphereEngineに取り込む手順が終わりよ。最後はマップを組み立てていくのだけれど、これもテンプレートを用意してあるからそれを使うといいわよ。「template.map」というファイルがあるから、これをコピーして「caldera.map」に変更して、内容も先ほどと同じように「template」という部分を「caldera」に置き換え変換すればそれで終わりよ。20km四方の海の上に、先ほど作って登録したモデルが配置されたマップファイルが出来上がるわよ。エディタで開いてみなさい。

なんかずっと緑だね。

一応島になっているけれど、建物も何にも建ってないよ。なんだか殺風景。

そりゃそうだろ。地形しか作ってないんだから。

実際はここに、設備を置いたり、市街地のテクスチャを張ったりして、自由に地形を作っていくのよ。少々複雑だから、ここで再度グレースケールの画像と、モデルの関係性を整理しておくわね。

高さ方向については、"template_map.rsu"を編集するときに、

SCALE :{x:1000, y:1000, z:1000 },

という記述のyの部分を書き換えると変わるわよ。上記のままだと真っ白のときの最大高さが1000m、という意味よ。例えばここを

SCALE :{x:1000, y:3000, z:1000 },

というように書き換えるとアルプス山脈のような地形が作れるわよ。テクスチャ画像についても他の繰り返しパターンに置き換えれば、岩場や雪原、溶岩地帯などが作れるわ。RS4thで使用しているテクスチャを呼び出す方法は、別途どこかで紹介するわね。高度な使い方になるけれど、rsuファイルのモデル個別にテクスチャを指定すると、第2テラストラクチャのロアータウンやイーストフィッシャーバレーのように地形の中にそのまま市街地を埋めるようなことも出来るわよ。
さて、一応ここまでで、ゲームを作るの必要な要素技術は紹介したことになるわね。断片的な話が多かったかもしれないけれど、実際に手を動かしてみないと分からないことも多いから、頑張ってみてほしいのよ。次回以降は一通り出来上がった後の話をさせてもらうわね。

第13回：デバッグ

さて、全てのスクリプトが書きあがったら次はデバッグと調整よ。出来上がったデータはここに用意してあるわよ。

なんだか料理番組みたいな展開だな。

もう出来上がっちゃったの？

これからデバッグをするわけだから、まだ「出来上がった」とは言えないわ。書いただけですぐに動くとは限らないでしょう。

え？書いても動かないなんて事があるの？

もちろんあるわよ。というより1回で動くことはほとんど無いわね。記述の間違いであったり設計の間違いであったり、大抵の場合は意図した動作をしないから、それを少しずつ修正していくのがこの工程の仕事よ。たびたび載せているこの図で言うと、「検証」の部分になるわね。

実際は実装と検証を分けて実施するより、作りながらデバッグしていくほうが多いわよ。まぁ、とり合えず動かしてみましょう。F5キーで実行ね。

あれ？なんか真っ黒。

メッセージが表示されているな、なんて書いてある？

コンパイルエラーのメッセージね。スクリプトは動作開始時に一旦全部を解釈してから、実行するという仕組みだけれど、このエラーはスクリプトを解釈するときに出たエラーね。これをコンパイルエラーと呼ぶのだけれど、mainのスクリプトの8行目の書き方がおかしいそうよ。問題の場所を開いてみて。この画面でF12キーを押すと、エディタの画面に戻るわよ。

ここで「はい」を選ぶとエラーが発見されたパスに移動できるから、そのままダブルクリックして編集できるわね。8行目はこうなっていたわよ。

int player_handle-1; // プレイヤーハンドル

「カンマが無い」って書いてあったよな。どこに足すんだ？

ここが少し難しいところなのだけれど、「カンマが無い」と言われたからと言って、単純にカンマを足せばいいかというと少し違うのよ。問題なのは「int player_handle-1」という表現で、カンマを足せば確かに解釈は出来るけれど、本来意図したような動きはしないわよ。この行は本来はプレイヤーハンドルを定義しつつ、-1に初期化する、という処理だからこう書き直すのが正解よ。

int player_handle=-1; // プレイヤーハンドル

「=」を足すのね。

なんだか難しいね。

そうね。SphereScriptは「構造化言語」と呼ばれる種類のものだけれど、1行にいろいろまとめて書ける反面、書き間違えたときに、どのような意図を持って書こうとしたのかを自分で判断する必要があるのよね。ただしこのあたりはほとんど慣れの問題で、そのうちにエラーの内容をほとんど見ずに、「○行目」という表示だけを頼りにすぐに直せるようになるわよ。

あと、あれだな。F12キーを押す前にエラーの表示内容を覚えてないといけないぞ。

その点の心配は不要よ。SpE4.exeがあるフォルダに「CompileError.txt」というファイルがあるから、これを開くと先ほど表示されたエラー内容がそのまま記録されているわよ。

さっきのところ直し終わったよ。動かしてみるね。

よし、動いたな。そのままミッションクリアまでやってみろ。

あれ？また黒い画面になった。また何かのエラーなの？

今度はランタイムエラーね。正しい文法に修正されたことでスクリプトの解釈には成功して、実行を始めたのだけど、実際に動作させようとしたら動作できないようなエラーが発生した、ということよ。これをランタイムエラーと呼ぶわよ。先ほどと同様に、F12キーを押してスクリプトを開いてみて。

9行目だな。こうなってるぞ。

tage_clear(); // ミッションクリア時の処理

で、確かエラー内容は何だったっけか？すまん、よく見てなかった。

先ほどと同様に「RuntimeError.txt」というファイルに残されているわよ。

「tage_clear」が定義されていない、ってどういうこと？

その関数がどこにも無かった、ということよ。クリア処理を行う関数は「stage_clear」という名前だから、ここが間違いね。正しくはこう。

stage_clear(); // ミッションクリア時の処理

これで正しく動くはずよ。F5キーを押して試してみなさい。

うん、確かにクリアできるようになった。

おめでとう、このミッションは完成よ。実際も、このように、スクリプトを書きながら、F5キーで動作チェックして、エラーが出たらF12キーで修正して、という手順を繰り返して作りこんでいくのよ。そうしてゲームに必要な全てのデータを組み立てれば、ついに完成、ということになるわよ。以前説明した方法でタイトル画面やブリーフィングも作っていけば、通しで遊べるようになるわね。

そうすれば完成だな。

そうね。実際にはそこから難易度の確認だとか、誤植チェックだとか、本当の意味での「検証」という作業はあるけれど、この段階まで進めば、堂々と人様に見せられるものには仕上がったことになるわね。次回はこれを実際にインストールできるようなファイルにまとめる方法を説明しましょう。作業のほとんどは既に終えてしまったから、あとは簡単よ。

第14回：パッケージング

さて、とりあえずゲーム本体は出来上がったわけだけれど、まだ作業が残っているわよね。

え？出来たからもう終わりじゃないの？

「あなたのPCの中では」ね。これをどうやって他の人に渡したり、ネットで公開したり、CDにしたりするのかしら。

あーなるほど、インストーラを作る必要があるってことか。

インストーラというほど大層なものではないけれど、必要なデータを独立したファイル群にする必要があるわ。その点、SphereEngineでは最初に作ったフォルダに必要なデータが全て揃っているから、それが必要なデータの全て、ということになるわよ。今回電プロさんが作ったゲームでは「3rdcurriculum」というフォルダが必要なデータ全てね。

フォルダごとまとめて圧縮してしまえばいいんだろ？

SphereEngineとRS4thを丸ごとを配るわけにも行かないから、今回作ったゲームのフォルダだけを圧縮してね。その状態で人に渡して、SphereEngine4のフォルダ内に解凍すれば、受け取った人はそのゲームが遊べるわよ。セーブデータは別のフォルダに保存するように作ってあるから、特に気にする必要は無いわよ。それと、今はフォルダをそのまま圧縮したし、「3rdcurriculum」でもその方法を取っているけれど、RS4thは別の仕組みになっているわよね。

フォルダが無いね。

RS4th.pacって名前のやたら大きなファイルがあるが、これか？

そうよ、拡張子がpacのファイル、これを「パッケージファイル」と呼ぶわよ。この中身は実はゲームのデータが入ったフォルダと同じで、専用のツールでまとめると、フォルダではなく、1つのファイルになるのよ。中身を見られたくない、もしくは1つのファイルでシンプルに配布したい、という場合はこちらの方が良いと思うわ。ただし暗号化している訳ではないから、中を見ようと思えば見えてしまうから、その点は忘れないでね。

今言った専用のツールってどこにあるの？

最新のSphereEngineSDKにMakeFilePackage.rspというファイルがあるでしょう。SphereEngine4の起動ダイアログでこれを実行すると、対象のフォルダを選択するダイアログが表示されるから、この中から選べばそれでOKよ。

簡単だな。

このファイル1つに今回作ったゲームのデータ全てが入っているから、このファイルだけを配布してSphereEngine4のフォルダにコピーすれば、遊べるようになるわよ。SphereEngineから見ると、フォルダの中を見ていることと全く同じように処理されるような仕組みだから、スクリプト側で特別な配慮は不要よ。

よし。完成。

喜ぶのはまだちょっと早いわね。これでゲーム本体の準備は出来たけれど、説明書きも必要よ。いわゆるReadmeと呼ばれているものね。

りーどみ？

Read me.「私を読んで」という意味よ。「最初にお読みください」ということとほとんど意味だけれど、PCの世界では伝統的にこのような名前になっているわ。もちろん「最初にお読みください.txt」という名前でもいいし、この方が親切かもしれないわね。中身は、一般的には製作者の情報や、インストールの注意、マニュアルの場所などが書かれているけれど、今回の場合は別途のマニュアルを用意するほどのものではないから、このファイルの中に必要な説明を全て書いてしまいましょう。

どうやって書くんだ？

このファイルは実際にユーザーが画面で読むためだけのものだから、特にルールは無くて、テキストエディタでそのまま書けばいいわ。参考までに構成例を挙げておくわね。

１．はじめに
（ソフトウェアの説明、製作者に関する事項など）
２．インストール方法
（インストール方法を説明）
３．アンインストール方法
（アンインストール方法を説明）
４．操作方法
（キーボードやゲームパッドのボタン割り振りの説明）
５．ゲームプレイ方法
（ゲーム進行の説明）
６．攻略のヒント
（詰まり易い箇所などがあればその説明など）
７．その他
（その他必要に応じて）

別に難しいところは無いわね。書き終わったらどこか適当な場所に保存しておいてね。先ほど作ったパッケージファイルと今のテキストファイルをあわせて、Webにアップロードするなり、CD-Rにコピーするなりすれば、本当に完成よ。

出来たー。

そう言えば冬コミで頒布したCDの中を見ると他にもファイルが入っていたよな。あれは何だ？

BGMだけが入ったパッケージファイルね。パッケージファイルは必ず一つにしないといけない、という制限は無くて、いくつかに分けておいて、後からスクリプトで追加的に読み込むという使い方もできるのよ。第3課程のCDは、買った人が中を見られるようにあえてパッケージファイル化はしていないから、ファイル名で検索してみるといいわね。再生はjukebox.sptで実行しているわよ。

何でそんなまどろっこしい事をしたんだ？

SphereEngine4をRS4の体験版とセットにして、無料配布する計画があるのよ。その中に過去のシリーズのBGMを全部いれて、必要に応じてゲーム製作者が読み込んで使えるようにしたいそうよ。合計すると100曲以上から選べるようになるわね。

へぇ、すごいね。

第15回：製造

さて、今まではゲームを「作る」、つまりデータとして完成させるところまでは説明したけれど、イベントで売るにはまだやることがあるわよね。

CDにする。

そう。何らかの物理媒体が必要よ。つまりゲームの製造ね。

前回のデータをそのままCD-Rで焼けばいいんだろう？何か特別なことがあるのか？

単に友達に1枚だけコピーして渡すような作り方なら何も考えることは無いけれど、在庫を抱えて会場に持ち込んで沢山売るとなると、考えることは結構あるわよ。大きく分けて、「何を作るか」と「どう作るか」の2点ね。何を作るか、というのは要するにパッケージの体裁のことで、次のようなものね。
・メディア種類
・ケースの形状
・盤面仕様
・ジャケット仕様

メディアの種類ってどういうこと？あと盤面って何？

メディアの種類というのは、CD-Rか、DVD-Rか、もしくはプレスで作るのか、という話よ。盤面というのはCD上面の画が描いてあるところのことね。ちなみに今言った『プレス』というのは工場で作る銀色のディスクの事よ。見た目は市販品と全く同じになるわね。全てを詳しく説明しようとすると、これだけで本一冊になってしまうから、今回作成するものに焦点を当てて説明するけれど、メディア種類は実質的に容量で決まってくるわね。今回はCD1枚に十分入る量だからCD-Rにするわよ。当然だけど、プレスにはしないわよ。

なんでプレスにはしないの？そっちのほうがカッコ良くない？

値段が高いんだろう。

そうよ。詳しくは後で説明するけれど、ある程度の数が必要なのと、納期も掛かるわよ。何より、経験も無いのにいきなりプレス工場に発注するのは無謀よ。「断ち代3mmCMYKの版下原稿」と言って意味が分かるかしら？

ん？今の呪文みたいなの何？

プレス工場に発注するときの印刷物の仕上げ方の話よ。まずは手作りで出来るところまでやって、ノウハウを得てから次のステップに進むほうが確実よ。

「小さな事からコツコツと」ってことだな。

ディスクの仕様を決めたら、次の何のケースに入れるのか決めないといけないわ。昔は音楽CDと同じような10mm厚の透明CDケースに入れることが多かったけれど、最近はDVDケースに入れるサークルさんが多くなったわね。

容量がCDに収まらなくなったから？

いいえ、中身は相変わらずCDだけれど、DVDケースには2つ利点があるのよ。1つは見た目が大きくて豪華に見えることと、もう一つはジャケットを1枚に出来て作るのが楽なのよ。この違いは、いわゆる「CDケース」に入れる印刷物を想像してみると分かるわよ。

なるほど、CDケースだと、ケースの下側に入れる紙と、上側に入れる紙の2種類が必要なのか。

DVDケースは体積がCDケースの2倍あって、在庫がかさばる、というデメリットもあるけれど、厚みが半分のスリムケースもあるし、CDケースよりオススメね。

ところで、冬コミで売ってた物は、ケースに入ってなかったよな？アレでもいいのか？

なっか安っぽくない？

ケースの体裁を整える時間が無かったことと、材料費を値段に反映させるくらいなら、安い値段で売ったほうがいい、と判断したからだそうよ。この企画自体、ゲーム内容にもそこまで工数をかけていなかったから、バランスを取ったようなイメージかしらね。

どうやって決めればいいの？

別にこうしなければいけない、というルールは無いから、自由な発想で作って構わないわよ。電プロさんは以前、秋葉原で見つけた四角いCD-Rにゲームをコピーして、そのままイベントで売ったこともあるくらいだから。手作りだと手を抜くにしても手をかけるにしても、柔軟に対応できるのがいいわね。

面白いパッケージにしたいな。

さて、次は盤面とジャケットの仕様ね、いずれも印刷に関わる内容よ。CD-Rの場合も、ゲームを売るときは大抵は印刷できる真っ白のCD-Rを使うから、そこに印刷する内容も考えないといけないわね。「何も印刷しない」というのも一つの選択肢だし、実際そういう仕様の作品も多いわね。

真っ白だと何のゲームか分からなくなっちまうだろ。

確かにそうなのだけれど、ケースにはジャケットが入っているし、外からだとCDは見えないから、問題になることは少ないわね。逆の考え方で、ジャケットをなくして、CD盤面の印刷そのものを正面から見えるようにする方法もあるわよ。どうしても安っぽさが出てしまうから、体験版や追加ディスクなどでしか使えないけれど、これが一番簡単に作れる方法よ。

ケースに入れるだけだから楽チンだな。

今言ったのは少し特殊な例だけど、もちろん盤面印刷をした上で、ジャケットの入ったケースに入れる、というパターンも多いわよ。プレスの場合は、もれなく印刷まで付いてくるから、必ず盤面印刷になるわよ。この印刷だけれど、今ではCDの上にプリンターでフルカラーで印刷できるから、手作りにしても、プレスで頼むにしても、特に難しいことを考えずに紙と同じような原稿を作ればいいわよ。昔は『2色刷り』という特殊な印刷方法があったけれど、今はフルカラー印刷が安くなってしまったから見かけることはなくなったわね。

ところでさ、この印刷データはどこから持ってきたの？

もちろん自分で作ったものよ。

スクリーンショットを撮って加工したのか。

大体合っているけれど、解像度に注意が必要よ。スクリーンショットを撮って、印刷して、ケースに入れてみればみれば分かるわよ。やってみなさい。

なんか、画像がもや～っとしてる。

どうやってシャープな画像を作るんだ？CGで作るのは大変だぞ。いや、スクリーンショットだとリサが言ったよな。

答えはシンプルで、とてつもなく解像度の大きいゲーム画面を作って、スクリーンショットを撮っているのよ。何も工夫しないでそれをやろうとしても、使っているディスプレイの最大解像度しか作れないけれど、SphereEngineには印刷物レベルの解像度の画像を取る機能が搭載されているわよ。適当にゲームを動かしてから「Ctrl＋P」キーを押してみなさい。数秒画面が固まってしまうけれど正常な動作よ。

何が起こるんだ？

SphereEngineのフォルダに画像ファイルがあるかしら。開いてみて。

おぉ～、なんか大きい。

（クリックで大きな画像表示）

動作中のゲーム画面解像度の4倍のサイズ、面積で言うと16倍の大きさの画像が作られるわよ。あとは、PhotoShopやGIMPなどのソフトでこの高解像度画像を背景に使えば、お手軽にジャケット画像や盤面画像が作れるわよ。高解像度画像を作るときに元のウィンドウサイズが大きすぎると、PCの処理能力を超えてしまって真っ黒の画像しか作れないことがあるから、元のウィンドウのサイズに気をつけて使ってね。

ジャケットのサイズとスクリーンショットのサイズが違うようだが、どうやって調整する？

画像編集ソフトには、データとしてのサイズのほかに、紙に印刷したときの大きさの情報もあるはずだから、それで調整するといいわよ。このときに今言ったデータとしてのサイズを小さくしてしまわないように注意してね。dpiで言うと大体300～350くらいになるわ。300dpiと言うと「1インチが300ピクセル」という意味だから、画面で見るときの解像度と比較するとかなりきめ細かい画像になるわね。でも実際に綺麗に印刷しようとするとこれくらいの密度は必要になってくるのよ。あと、このときに縦と横の比率が違うことで、はみ出した部分は消してしまっていいわよ。解像度をあわせたら、ロゴや文字を重ねて出来上がりね。ちなみにジャケットはそのまま四角い画像を作ればいいけれど、CD盤面データも同様に、四角い画像を用意する必要があるわよ。

CDは丸いのに、画像は四角いの？

「丸い画像のデータ」という形式が無い、という理由もあるけれど、丸い部分を取り出す処理は、印刷ソフトや機材に任せたほうが綺麗に仕上がるから、というのが主な理由よ。実際、RS4thのサウンドトラックはこのようなデータを作っていいるわね。

なんか、隅っこのほうが切れてないか？

隅のほうは決して印刷されないからこれでいいのよ。だからといって、最初から丸い部分だけの画像を作ってしまうと、もとの画像の丸い部分と、印刷ソフトが円形に切り取る処理とがずれてしまった場合に、端のほうだけ白くなってしまうことが起こり得るのよ。端っこのほうに「ある」か「ない」かの違いだから、例え1mm以下であっても、かなり目立つわよ。実は似たようなことが、ジャケット印刷にも起こりがちで、印刷した外側を正確に切ることは意外に難しいのよ。だから、完成後のサイズより少し大きめにデータを作っておいて、最後に印刷境界の少しだけ内側を完成後のサイズどおりに切る、ということをすると綺麗に仕上がるわよ。工場にお願いするときにはこのあたりのノウハウが必須になってくるから、いずれはプレスにしたいと考えているならば、覚えておきなさい。

う～ん、丁寧に切ろうとすると時間が掛かるから、少し大きめの画像を作っておいたほうがよさそうだな。

データの作り方の話になってしまったから最初の話に戻るけれど、製品の仕様をまとめるとこんな感じね。

メディア種類	CD-R
ケースの形状	CDスリーブ（CDを入れる袋）
盤面仕様	何も印刷しない
ジャケット仕様	片面フルカラー印刷を1枚、スリーブの中に挿入する（委託用は裏面にモノクロの説明書き有り）

結局はシンプルな形にするんだね。

簡単なところから慣れていけばいいさ。

製品の仕様が決まったら、次は「どう作るか」を決めないといけないわね。
・生産数
・原価
・仕入
・生産機材
・生産スケジュール
これはゲームに限らず、音楽CDやCG集にも当てはまることだから、応用が利くわね。

なんだか工場みたい。

ここまで本格的に取り掛かる必要はあるのか？とりあえず1枚1枚焼いてケースに入れればいいんだろう。

ショップに委託するような規模になると簡単に1000枚くらいの生産量に跳ね上がるわよ。「とりあえず」で1000枚も作れるわけないでしょう。無計画に進めると大体200枚くらいで破綻するわね。1つ作るのに15分かかるとして、200枚作るのにどれほどの時間がかかるかしら。

えっと、1時間で4枚だから、50時間だね。大体2日間くらい？

『不眠不休』でね。

おいおい、15年前ならともかく今なら焼くのに5分もかからんだろう。

そうよ。でも5分でコピーした後、売り物にするならば品質確認として同じ時間ベリファイが必要ね。その後にジャケットとインレイを印刷して、それぞれカッターナイフで切って、ケースを解体して、インレイを入れてケースを組み立てジャケットを入れて、CDRをケースに入れて、ダンボールに詰めたら15分よ。1回やってみるといいわ。これが15分で終われば相当の熟練者よ。今言った中に盤面印刷は入っていないから、それもやろうとするとプラス3分ね。

うわぁ…。

1000枚作ってるサークルとかはどうしてるんだ？…そうか、だからプレス会社に頼んでるのか。

大体は正解ね。ここで問題になるのは何枚作るか？ということよ。例えば1000枚、と決めてしまえばその数をそのまま注文すればいいのだけれど、1000枚未満でも総額が変わらないところがほとんどだから、300枚だけ頼むとか、もしくは1000枚で足りなくなったから後から500枚だけ追加するとか、そういう注文方法は出来ないわよ。いえ、正確には、出来るけれど、とても高額になってしまうのよ。

多めに作っておけば良いんじゃない？

多く作るだけお金が余分に掛かるだろ、だいたい売れ残りはどうするんだ。

売れ残った在庫を置いておくのにも場所をとるし、最後に捨てるのも大変よね。初めて作るゲームがいきなり1000枚以上売れるというのも考えにくいし、プレスを選択肢に入れる必要は無いと思うわよ。手作りならば、作った分の材料費しか掛からないから難しいことを考える必要がなくなるし、それに、納期も明らかに短いしね。

納期？

「作ろう」と思ってから実際に「出来た」となるまでの時間のことよ。プレスの場合、配送まで含めるとおよそ3週間かかるけれど、ゲーム完成間際の3週間は本当に貴重よ。CD-Rならば極端な話、イベントの前日徹夜して作ることも出来るわよね。

ぎりぎりまで開発に専念できるということだな。

その通り。だから、委託販売をしているサークルさんでも、イベントではCD-Rで売って、その後プレスしてショップ委託、というパターンもよく見るわよ。イベントで売れ行きを見てから決められるから、どんなに自信のある大作を作ったとしても、まずはCD-Rで作るのが良いわね。あと、意外かもしれないけれど、工場で大量生産するより、一枚一枚手作業でCD-Rにコピーするほうが1個あたりの費用も安上がりよ。

そうなの？ふつう、手作りって値段が高いと思うんだけど。

計算してみましょう。CDのプレス工場は安売り競争になって徐々に値段が下がっているけれど、品質と納期より価格を最優先しても1000枚で7万5千円は掛かるわよ。つまり1セット75円ね。

■プレス
1,000枚＝74,800円
1枚当たり75円

ちょっと待ってくれ。これよりも安く出来るのか？昔、割ってしまったCDケースを交換したくて電気屋で買ったら5個で400円とかしたぞ、確か。一個80円だ。

最後まで話を聞いてちょうだい。次に手作業で作った場合。ここではまとめて200セット作るつもりで計算するわね。

■CD-R（手作業）
CDR：200枚＝4,000円
紙：200枚＝800円
インク：200枚分＝1,000円
ケース：200個＝5,000円
総額：10,800円
1枚当たり54円

21円分安いね。でも、たった10円20円の違いなんてどうでもいいんじゃないの？

いいや、たくさん作ろうとしたときに、かなりの金額の差になるぞ。ちりも積もれば…ってやつだよ。でもリサ、こんなに安く買えるのか？ケースなんか、10個250円ってことになるぞ。そんなのあるのか？

バラバラに買うからそうなってしまうのよ。200個、400個、という規模で考えると、ケースは問屋から直接買えるわよ。CDRも、100枚もしくは300枚といった数だと、ダンボール1箱分のバルク買いができるわね。国内ブランド品でもこの値段だから、海外ブランドだともっと安くなるわよ。ただし、あまり安いものだと品質に心配があるから、バランスを考えてね。

この値段ならばプレスする必要なくなるな。

今の計算は自分の人件費を考えに入れていないから、単純に単価だけを比較するのは実は適切ではないけれど、少なくとも「大量生産する場合はプレスのほうが安い」とは限らないことを覚えておいてね。さて、次は作る手順を考えないといけないわ。先ほど言ったように、何も考えずに順番に作業すると丸々2日掛かってしまうわよ。

3人で手分けするか。

まぁ、それも一つの方法だけど、もう少し考えて欲しいのよ。1セット作るのに15分掛かるとして、そのうちの殆どの時間が「待ち時間」だということに気づくわよね。しかも大半がCD-Rドライブが稼動している時間よ。つまり……。

つまり？

ドライブを増やす。ボトルネックを解消するんだな。

正解！ノブユキさんが今言った「ボトルネック」というのは、ビンの口のように、ものが流れる障害になっている一番細い部分の事よ。今回の場合はCD-Rドライブがボトルネックになっているから、ここを対処すれば、全体の作業効率が一気に改善するわよ。古いパソコンでも何でもいいからCDをコピーできる装置を用意して、仕事をさせるのよ。電プロさんはCDコピー機を買う前までは、イベント前日に3台のPCをフル稼働させて作っていたそうよ。これで同じ待ち時間で3枚のCDが作れるようになったわね。

時間が1/3になるね。

ジャケットを切ったり封入したりという作業は変わらないから、そういう単純な計算ではないのよ。ここは図に書いたほうがいいわね。上の図は最初に言ったように何も考えないで順番に作業して行くやり方。下の図は、3台のCD-Rドライブを使いながら、手が空いている時間に他の作業を詰め込むやり方の例よ。

3台で同時にコピーをしながら、1台を使ってジャケットの紙をどんどん印刷していくのよ。CD-Rのコピーよりも先に印刷が終わるから、終わり次第カッターで重ねて切っていき、CD-Rがコピーし終わったら次のCD-Rを投入してすぐに封入に取り掛かる、その間ずっと印刷は継続中……という手順よ。上のやり方だと30分間で2つしか作れないけれど、下のやり方だと同じ30分間でも6つ作りながら、さらに次の3枚のCD-Rコピーとジャケットの用意まで終わっているわね。最後まで計算すると４．５倍の速度で作業が進むわよ。このペースならば、丸1日馬車馬のように働けば終わるわね。

死ぬほど忙しいな。

手作業に関わる機材に工夫をすると、時々休憩を挟む余裕はあるわね。電プロさんの前回の冬コミ直前の作業風景はこのような感じよ。

ガイド付きのカッターを使って同時に5枚切りして、カット時間を大幅に削減しているわね。CDも同時に14枚焼ける機材構成になっているから、パッケージが簡易なこともあって3.5時間で300セット作ることが出来たそうよ。

まるで工場だな。

CD-Rドライブの1時間あたりの処理量、これをスループットと呼ぶのだけれど、CD-Rをコピーするスループットと、ジャケットや封入の手作業のスループットとのバランスを取るようにすると、全体の作業効率が上がるわよ。今回の電プロさんの作業ではジャケットと封入の仕様を簡素化したから、手作業の速度が速い分、CDコピー機を導入してコピー速度を手作業の速度に合わせたのね。

なんか、すごく複雑なんだね。

これ、あれだろ。生産工学の話だろ。

そうね。今話したような内容のことを「生産工学」というのだけれど、今回の話はその初歩の初歩みたいな内容ね。ゲームの開発と販売に比較してこの製造に関しては軽視しがちだけれども、本来はアマチュアであるがゆえに一番工夫の余地があるところなのよ。手作業が基本の形だから、アイディア次第で仕様もコストも納期も自在にコントロールできるわよ。

なるほどね～。

今回の講座で、全ての内容が終わりになるわよ。いきなりゼロから大作を仕上げるのは、誰がやってもうまくいかないから、最初に説明したように、単純なものから一つずつ完成させて経験を積んで行けば、いずれは思い通りのものが出来るようになるわよ。困ったときは電プロさんに聞けばいろいろ教えてくれるそうだから、がんばってやってみてね。

ページのトップへ戻る

SphereEngine4開発講座