1

2

3

1996年からD.N.A.個人のサークルとしてこの名義を使い始め初は富士通のFM TOWNSで、BASICを使ったゲームをちょいちょい制作

2000年にWindowsへ移行2004年頃からは複数人でのサークル活動が基本になるが、全員役割がプログラム寄り

今のところ、絵や音の担当は常駐しておらず、プロジェクト毎に外部の方にご協力をお願いしている

4

過去制作の作品といえば ▼

やはり幻想麻雀あまりにこればかり人気で他のゲームがあまり目立ってないが

5

めぼしいもののロゴだけ並べてみたもえだんは割と有名か 初心者向け弾幕学習STG出落ちっぽい題名やらロゴが多いのも特徴

6

Windows時代の作品を年表にするとこんな感じリストにしただけでも14本あるが、さらに商業のメーカーで制作したソフトや、実験作レベルの小品まで含めると20本はいくと思うだいたい年2本～3本程度の制作ペース

7

8

AIMSとはD.N.A.Softwaresのいわゆる内製エンジンというやつ2006年12月からAIMSという形でのバージョン1が完成2008年9月に一般公開 まだ数は少ないが他のサークルさんへの採用例もあるエンジンの実体はスクリプトエンジンとしてLuaDirectXへのインタフェースは葉迩倭さんのLunaライブラリそれにシーンやオブジェクトなど各種の管理システム・LuaへのインタフェースをかぶせたものでC++で制作している

9

特徴としてはActorと銘打った強力なスプライトシステムシーン管理をエンジン側が受け持つリソースもエンジンが受け持つLunaライブラリの機能をできるだけ使えるように設計してあること

たとえばムービーテクスチャ、画像変形のエフェクト、テクスチャフォントとか、あとは文字入力なんかもできるで、LuaJITというLuaスクリプトを実行時コンパイルするライブラリを搭載していて、そこそこ高速

10

実際に使ってみたい方はウチの本を買ってください メロン、とら、COMIC ZIN、Dステージ、ホワイトキャンバス、あきばおーで扱ってます

11

今回はAIMSを使って云々という話ではなく、AIMS自体の設計についてのお話ゲームプログラマおよびプログラマになりたい人向けの話題かも

12

まずDNAのゲームプログラムに対する考え方というか概念の説明ゲーム＝舞台演劇と考える舞台がいわゆるウィンドウとか画面、キャンバス役者はゲーム中に出てくるキャラクタゲームのタイトル画面とかゲーム画面などを劇の場面ととらえる

13

役者は脚本に従って動く

役者同士ぶつかったり、何かの台詞を言った、舞台のどこかに移動したなどのきっかけで他の役者がその続きの動きをしたりする

これはゲームでも同じ、プログラムに従って、オブジェクトが他のオブジェクトに当たったりしたら何らかの動作が入るこういう作用が積み重なると一つの場面になる場面を繋げば、ゲームのいっちょあがり

14

ウチのゲームは全部この考え方が根底にある

15

再び作品年表、これはさっきのものから今回の講演に関わるものを追加したり整理したりしたもの

16

制作環境で大まかに3分類するとこうなるHot Soup Processorで約3年、C++でAIMSができあがるまでさらに3年かかっている

17

C++の話の前にHSP時代の話をしておきたいHSPで作った作品はSTG2本、プロジェクト・フロンティアと月姫の城。プロジェクト・フロンティアが6面構成月姫の城は短めのステージだが約15，6面くらいあるはず自機によってステージとボスが替わるシステムにしたどっちも制作期間1年超

18

どちらもやりたいことを片っ端から突っ込んだせいでHSPの限界を超えてしまったHSPを知っている方なら納得してもらえると思うが、HSPは本来大規模なプログラムを書くものではない変数がほぼグローバルしかないに等しいとか、関数がないなど特に当時のVer2.6は厳しかった

見通しの悪いコード、他人が見ても全く判らないような状態になったため殆どの作業が自分に降りかかった

これに懲りて、複数人でも開発をスムーズに進められる新しいシステムを作る決心をした

19

HSPに見切りをつけてC++に移ったわけだが、ここからAIMSができるまで東方戦騎譚 SMASHTOUHOU まわるめいどさんをねみぎ の3本を制作している（うち1本は未完成）

先ほど話した役者、場面、舞台、それぞれの管理手法の変化に話を絞りたい

そこで作った図がこれ アクター＝役者のアルゴリズムと、シーン＝場面のアルゴリズム アルゴリズム＝脚本だと思うといいそれぞれ、各作品でどれくらいLuaに頼ってるかを示した図

20

アクターについて。現状から。

ゲーム画面に出てくるキャラクタ、横文字で「アクター」と呼んでいる。役者。今のウチのゲームでは原則、画面に出てくるものはすべてアクター

HSP時代にかなり使いやすいDirectXプラグインを見ていたので、それを参考にしたHSPで一々移動処理を書くのは面倒この上ないということで、プラグインがキャラクタの各種アニメーション処理を肩代わりする作りになっていた同様に、こちらでも2Dゲームに頻出の処理を基本クラスでサポートさせることで、派生クラスやら、スクリプトでプログラムする量を減らすことを狙った

21

Luaの関数を割り当てて、Lua側からアクターの役割を定義できるのがポイントAIMSにおいてはすべての物体は「アクター」であるから、どんな物体でも同じ命令系統で操作できる

22

じゃあアクターになる以前はどうだったのか C++第一作 東方戦騎譚をみてみる

23

こんな感じの固定画面STGで、障害物に隠れて弾幕をやり過ごしたりしながら敵を倒して出口に行くゲーム

24

アクターという概念ができたのはまだ後のこと、オブジェクト指向らしく基本クラスのスプライトがあって、そこからゲーム内の要素毎に派生クラスがあったつまりアクターの役割をC++側で規定していたということ

移動とか当たり判定はハードコーディングで、一部のキャラクタの挙動だけLuaで書いた

25

どうしてスクリプトを使おうとしたか

ちょっとワルい言い方だが、自分以外のスタッフにもステージ実装を押しつけたかった。みんなで等しく苦労しようぜさっき言った通り、HSPでは人にステージデータを触らせるのが非常に困難な状態となったC++に移って解決ではない。他のスタッフ全員にC++の環境を作れと言うのはちょっと効率が悪すぎ

スクリプト言語を導入することで、実行ファイルに手をつけずにアルゴリズムの調整ができるようになる実行ファイルと適当なテキストエディタで開発環境が揃う。手がかからない

26

スクリプト自体は使うとして、数あるスクリプトの中からLuaを選んだ理由速度が速いとされていたそれと日本語訳されたリファレンスやら参考資料やらが少ないながらもあった既にバージョン5.0とそれなりに枯れた設計になっていた

実際コードを書く際に役に立つと思ったのがテーブル 当時は便利な配列程度の意識だったが、今では非常に重要でAIMSで高度なゲームが作れるのはテーブルのおかげと思う

27

アクターに対して場面の方、シーンの方の話に移る

シーンすなわち場面だが、AIMSのシーンは場面と同時に舞台の機能を持っていると思って欲しい

アクターだけでは画面に出す順番がわからない、アクターの並び順を管理するのがまずシーンの役割

28

AIMSにおいてはシーンの振る舞いもまたLuaスクリプトで規定する

担当するのはアクターがカバーできないところ、つまり、アクターを作る前の処理、シーンが始まるときの初期設定とかアクターと無関係、並列に動作して欲しい処理それと、後片付けつまりシーンを終わるときの処理

29

戰騎譚の時はシーンはもっぱらハードコーディングだったどうしてかといえば、何を作るかがはっきりしていたから、汎用化する理由がない

シーン毎に、今から作る場面のために必要な処理だけをゴリゴリ書けばそれでよかったLuaで書くべきことは「決まったゲーム」の「ステージの設定」だけでいいし、それ以上を移す必要もない

30

C++にべったりの設計が通用しなくなるのが「まわるめいどさんをねみぎ」なぜかといえば、画面写真を見てもらうと判るとおり、これはミニゲーム集で全部のゲームについて一々派生クラスを云々……といっていたら時間がいくらあっても足りない

31

ということは、どんなジャンルにも対応できる設計というのが求められる

自分が全部のゲームの実装を一人でやるなんてのはあり得ないので、誰にでもミニゲームを書いてもらえる設計というのが必要になった

これまでのようなC++の派生クラスのやり方はそもそもジャンルが不確定では使い物にならない代わりに、Luaで全部のアルゴリズムを流し込むことで「なんにでもなれる」 「アクター」に至る

32

シーンシステムも「何にでもなれる」設計が求められたが、アクターという単一の概念にまとめられたことでこちらは自然とまとまった

以前は種類毎のクラスがあってそれぞれに専用のリストがある、という設計でハードコーディングされてた

ねみぎからは「アクター」のリストが複数個準備されており、その役割を決めるのは全てスクリプト次第という風に持っていったリスト一つ一つを「レイヤー」(フォトショップとかのアレ)と呼称し、レイヤーに対しての操作をする関数とかを準備して、

「このレイヤーは弾」「あのレイヤーは自機」などというように、スクリプトで好きに使い分けてもらうようにした

33

ここでもう一度さっきの表

初はハードコーディングが多くを占めてたのが、100%Luaを達成するまでには段階的にハードコードを減らす過程が挟まっている

34

一足飛びにAIMSのような100%Luaを達成できなかったのには一つ現実的な問題があった

35

先に結論から言ってしまうと、汎用化を目指していたら▼速度の問題にぶちあたったということ

36

初期の実験

・試しに弾幕を張ってみようと、自機も敵もいない状態でただ画面真ん中あたりから弾を延々ばらまくだけのプログラムを作ってみた・その弾全部にLuaスクリプトを割り当てて加速減速とかさせてみたところ、画面内に100発くらいでたところでもう処理落ち・原因を詳しく調べた結果、割り当てたLuaの関数を呼び出すところ、これがどうも重いようだという結論に

いくら速いといわれてるスクリプト言語でも使い方を間違えれば台無し

呼び出し回数を減らすため、Luaに頼らないスプライトの軌道制御法を作ったこれを「Mover」という

どれぐらい簡易かといえば内部での格納は単なる数値だけの構造体、分岐も変数もない単純に「いつから、どれだけの時間、どんな動きをさせるか」という要素だけ意外にもこれで大半の弾幕の動きは表現できる上、Luaとは比較にならないほど高速

もちろん、このMoverというのを設定する手段としてLuaは必要だが、一々全てのアクターでLua関数を動かさなくて済むようになった分速度は上がったこれでとりあえず戰騎譚のときは問題は無くなったLuaの利用シーンの大半が弾幕の制御だったので、そこで 適化できたのが大きい

37

で、色気を出してLuaでいろいろしたかったのがこの「SMASH TOUHOU」

38

ご覧の通り、カットインの演出がいろいろあったり、エフェクトでがんばろうとしたが、レベルデザインの限界にぶち当たったことで頓挫してしまった

余談だがこれの失敗のあとステージデザインとかで新しいヒントを得たことで作ったのが「神魔討綺伝」。さらに余談だが懲りずに次の例大祭でもう一回全方位STGにチャレンジする

39

申し上げた通り、エフェクトを強化したいということで、戰騎譚でハードコーディングしていたエフェクトとカットインをLuaで実装してみようとした

動きはしたが、画面写真の通りけっこうな量の敵が出る上にエフェクトてんこ盛りとなると、また当然のようにスクリプトの呼び出しがかさんで処理落ち

で、さらに問題になったのが、エフェクトはパーティクルを出したりなんだりしようとすると、Moverでできる作業の範囲を超えてしまったことつまりMoverで高速化という手は使えない

40

結局、エフェクトはLuaで書いていたらゲームにならん、ということになりまして、ハードコーディングに、画面に一つしか出てこない、カットインみたいなものであれば、負担も少ないのでLuaにという設計に落ち着いたカットインだけはどうしても凝った見せ方をしたい部分だった

そのあと、小規模な、あまりキャラクタの出てこないゲーム、ミニゲーム程度なら全部Luaで処理しても大丈夫という見込みになり「まわるめいどさんをねみぎ」で100%Luaの設計を達成

41

100％何でもLuaというのは条件があるということ

ゲームデザインや演出上の妥協とか、あるいはユーザーのマシンパワーが上がるのを待つとかそういうことをやっていたのがこの3作品の間ということ

プレイヤーさんの環境がよくなればそれだけできることの幅は広がるわけで、特に 近JITを入れて以降はかなり自由にやれている

42

まとめ

とりあえずゲームエンジンを作ったらゲームを作ろう 作る過程でそのエンジンの問題点が浮上する問題点や課題を洗い出すのに手っ取り早い

モチベーションにも関わるので、特に複数人で開発するなら一人で全部背負い込むようなことはしない常に他人に作業を分担させやすいような設計とか、実装とかを意識したい

スクリプト言語も万能ではない。ハードコーディングで良いところはハードコーディングでやってしまうのも手

部品の使い回し、AIMSで使っているアクタークラスの基礎部分は戰騎譚から少しずつ改修しつつも大枠では昔のまま使っている使い回しによって制作スパンが短くできる。使い回せるものはがんがん使い回そう

使い回しやすい作りにしておく ソースを分ける、変な依存関係を残さず整理しておく、あとはインタフェースやドキュメント類の整理

43

44

45

46