after C87
C87、スペースに立ち寄ってくださった方々、ありがとうございました。
exception reboot 体験版ですが、Visual Studio 2013 ランタイムが入ってないとパーティクルや背景が出ないというミスをやらかしてしまいました…。同現象に見舞われている方はこちらをインストールしてお試しください。
http://www.microsoft.com/ja-JP/download/details.aspx?id=40784 (vcredist_x86.exe の方)
また、ビデオカードによってはエフェクトが正常に出ないようです。今後調査して直していきます。
今回 1 ステージだけなので意識的に難しめにしています、が、ちょっとやりすぎたかもしれません…。コントローラ対応が中途半端だったり、自機を見失いやすいなどのプレイアビリティに関しては追々改善していきます。
最終的に売り物にしつつもソースは公開、Unity インストールして自力でビルドすれば無料で遊べて、自分でステージ作って他のプレイヤーと共有することもできる、みたいな形を目指しています。2015 年中の完成が目標です。
あとソースに関して、readme に書き忘れたんですが、ビルドには Unity 4.6.1 p1 以降が必要になります。これ未満 (現時点の public release 含む) だとコンパイルエラーが出てしまうと思います。
Assets/Scenes/Title.unity を開くと Unity のエディタ上で今作がプレイできるはずです。
以下、冬コミ版の後書きとか Unity 使ってみた雑感とか。
今回の冬コミ版、パーティクルエンジンとレンダリングエンジン以外の純粋なゲーム部分は、大体 10 日くらいで作っています。ボス作るのが楽しく大部分の時間リソースをそっちに割いてしまい、ステージ道中はかなりお粗末になってしまいました…。メニュー類やシーンの遷移についてはコミケ前日の 1 日で仕上げました。Unity なしでは成り立たない無茶な進行だったと思います。
当初はもうちょっと余裕がある進行にする予定だったんですが、パーティクルとレンダリングの方に時間を取られすぎてしまいました。
自分的今作のハイライト
この半年くらい Unity 絡みの仕事したり、Unity 上で動くデモプログラムを作ったりはしてきましたが、ゲームらしいゲームを作るのは今回が初めてでした。やってみた感じ、やはりこれまでより大分楽で、ステージ作る能率は無印 exception の時より 3 倍以上上がったと思います。
自分で意外だったのが、Unity を使い始めてから、逆に独自のレンダリングエンジンにこだわるようになりました。
Unity を使いはじめる以前は、レンダリングエンジンとか最も既存のゲームエンジンに任せたい部分、と思っていたんですが、いざ実際にゲームエンジンを使ってみると、プログラマー兼アーティストの自分の場合それなりの独自性と最低限のクオリティを両立した絵を出そうと思ったらレンダリングエンジン独自に書くのが一番早い、という結論に至りました。
Unity だとシェーダとレンダリングに絡むコードの変更をゲームに反映させるサイクルが速く、以前よりシェーダ書くのが楽しくなったというのも要因としてあります。
なんか会場で 5 人くらいに「これ Unity 上で動いてはいるけど Unity の機能使ってないですよね？」的なことを言われて意外だったんですが、シェーダとパーティクルが独自なだけで他はちゃんと Unity です。
今どきレンダリングエンジンはゲームエンジンのほんの 1 機能に過ぎないので、自力でやるモチベーションがある部分はフルコントロールして、そうでない部分はゲームエンジンに委ねる、というやり方でいいんじゃないかと思います。自分の場合、パーティクルとレンダリングはそれなりにこだわりがあるものの、エディタ類とかには極力労力を割きたくないのでこういう作り方にしました。自分的にゲームエンジンはレベルエディタとして優秀であればそれで十分です。
今回は Rigidbody、Animation、uGUI あたりを大いに活用しています。
Collider と Rigidbody コンポーネントを追加すれば物理挙動を実現できるお手軽さは素晴らしくて、物理を活用したギミックは今後も増やしていきたいところです。
Animation はステージのスクロールやボスの砲台の制御なんかに使っています。タイムラインエディタはもちろん、任意のタイミングで任意の関数を呼ぶ機能 (Animation Event) が重宝しています。ボスのビームの発射の機能や、ステージのセクションの切り替えは Animation Event による制御です。
uGUI。4.6 から入った UI システムですが、趣味と仕事で過去 3 回くらいインゲーム UI システム書いた身としては、こんな使いやすいのが標準にあることに感動です。UI システムは最低限の機能が揃えばあとは比較的 誰が作っても最終的な見た目にそこまで差は出ない 部分だと思うので、デファクトスタンダードとなりうるものが出てくることには大きな意義あるんじゃないかと思います。
逆に今回 Unity 使ってて不満だった点も挙げると、
C#。Unity というか mono が原因ですが。去年この blog に何度も書いてきましたが、C# で巨大な配列を巡回して処理を行うのは死ぬほど遅くて、この手の処理についてはプラグインか ComputeShader 書く他ありません。pure C# で 10 万パーティクル相互衝突とかたぶん 10 年未来のマシンでも 60 FPS 出すのは無理でしょう。
裏を返すと、プログラマーがゲームデザインをする際最もアドバンテージがあるのがこの領域、とも言えると思います。
スクリプトの実行時編集。スクリプトが編集されるとオブジェクトをシリアライズして、アセンブリをリロードして、オブジェクトをデシリアライズする、という手順を踏みますが、このへんそれなりにちゃんと理解していないと、ちょっとプロジェクトが複雑になると破綻するんじゃないかと思います。static オブジェクトの扱い、Action などのシリアライズ非対応型など、色々罠があります。ComputeBuffer など UnityEngine のオブジェクトなのにシリアライズ非対応な連中も存在していてなかなか厄介です。
ちゃんと対処するのはめんどくさそうだったので、今回は途中から実行時編集は諦めました。代わりにエディタ上でステージの途中から開始することでイテレーション速度を保つようにしています。
過去に頑張って C++ で同等機能を実装してた身からすると、なんというか予想外に親しみが湧くリアルワールドな世界でした。
今回の冬コミ版の制作を通して、自分のようなオールドタイププログラマーでも Unity とはよろしくやっていけそう、Unity で自分の作りたいゲームは十分作れそう、という確固とした実感を得られました。
