Comments
Description
Transcript
Untitled
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月に一般公開 まだ数は少ないが他のサークルさんへの採用例もある エンジンの実体は スクリプトエンジンとしてLua DirectXへのインタフェースは葉迩倭さんの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