2014年9月21日日曜日

魔法科LZ 第7回:私のたった一つの望み。可能性の獣、希望の象徴


 魔法科高校の劣等生 LOST ZERO(以降、魔法科LZ)制作ブログ 第7回です。アプリが公開され運営が始まったいろいろと忙しくて、時間が空いてしまいました。今回は、2回目の番外編として開発の時系列からちょっと離れ、魔法科LZ で取り入れている技術の話をしていきたいと思います。

 ウチの会社で作ってきたゲームの構造的な特徴として「スクリプト重視」な開発スタイルがあります。ここでいうスクリプトというのはCPUが直接理解できる形式<ネイティブコード>ではなくて、ゲーム専用の使いやすいプログラム言語くらいにとらえておいてください。これはウチの一番最初のゲームタイトル「どこでもいっしょ」からずっとつづいている伝統とも言っていい位の開発スタイルで、現在の PS Vita 版「みんなといっしょ」でもそのスタイルは変わっていません。一般的なゲーム開発スタイルであっても、ゲーム中のキャラクターのトーク、イベントシーンなどはスクリプト言語で処理されている事は多いと思うのですが、ウチのゲームの場合、もうひといき突っ込んでいて、基本的にネイティブコードで用意するのはゲームの部品であり、それらを制御してゲームを組み立てるのはスクリプトというようにゲーム全体がスクリプトで動かされているというような構造になっているのです。

 この利点は、ゲームの構造が柔軟に変更可能になることです。スクリプト言語で組み立てられる部分はプログラムとは独立して、簡単に変更&調整がしやすいので、プログラマでなくとも全体のフローを変更したり、新しい処理を追加していくことが可能になります。これによってスピーディに新コンテンツを提供していくことが可能になるというわけです。トロ・ステーションなども、このスクリプトの仕組みでなりたっていました。もちろん、ある程度の知識やスキルは必要とされますが、プログラマ並みにゲームエンジンや、SDK について熟知している必要はなく、スクリプト側に提供されているゲーム用のAPI の理解だけですむので敷居はぐっと下がるというわけです。もちろん、いいことばかりではなく、ネイティブコードに比べて処理速度が遅いことや、シンプルな開発環境しか提供されないことなどマイナス面もあります。これまで、ウチのゲームは内容的にシビアな処理速度が要求されるタイプのゲームが事が少なかったということもあり、スクリプト重視の開発スタイルをとりやすく、発達してきたということもあったとおもいます。

 そういうわけで、開発がスタートした段階から魔法科LZでもスクリプトエンジンの導入について検討をはじめたのですがコンシューマーでの開発環境から Unity  に移行したこともあり、これまで利用してきた内制のスクリプトエンジンの利用をやめて、別のスクリプト言語の選定からスタートしました。またウチの大得意な分野であるキャラクターによる演技(通称、キャラ劇)では、これまで以上にキャラクターをしゃべらせたり、演技させたりしたかったので、性能がよく、使いやすいスクリプト言語を採用したかったのです。検討をかさねた結果、スクリプト言語として選定をしたのは JavaScript (以下、JS)です。そしてこのおかげで、それを動かすスクリプトエンジンは実装する必要すらなく、スマフォに既に実装されている Webブラウザの JavaScript エンジンにをそのまま利用する事が可能になりました。

 JSに決定するに至った技術的な理由は多々あるのですが、主な理由だけ書くと

・JS はとても普及している言語なので資料&ツールがネット上に豊富
・非常に性能がいいうえに、エンジンを実装する必要がない
・自分を含め、非常に慣れている言語だった

などなど大きなメリットがたくさんあったというわけです。(ちなみに NDA 的にブログには書けないもう一つの大きな技術的な理由もあるのですが、それは推測にお任せします)

 そして、JSについて、推測ではありますがおそらく現在、人類のリソースが最も投下されているプログラム言語なのではと思います。Apple や Google 、Microsoft など世界屈指の IT企業がブラウザの JS の高速化や開発環境にしのぎを削っていますし、インストールベースでもすべてのスマフォにインストールされていることになりますので圧倒的です。たくさん使われているということはそれだけ動作実績ありバグも少なくなっているいえます。言語仕様は特に最新機能等はあないものの、実行環境と開発環境を考えるとスクリプト言語という範疇では JS に並ぶものはないのではないでしょうか。

 さて、この万能とも思えた JS ですが、じつは Unity との組み合わせがあまり良くなかったのです。スマフォでは内蔵のブラウザの機能を利用して JS を実行すればいいのですが、Mac や Windows の開発環境ではそれぞれ問題がありました。

・Mac
 スマフォと同様に動作するが、プログラム内部のブラウザで動作している JS の情報を一切見ることが出来ません。これでは開発環境としては使えません・・・

・Windows
 そもそもスマフォのようなブラウザ機能がサポートされておらず、動作すらしない orz

 なんということでしょう!なまじスマフォでは一般的なブラウザのサポートなどが、開発側の OS ではそれほど充実しておらず、このような問題が出てきてしまったのです。しかし、先のような大きなメリットは捨てがたかったので、ここは開発環境を工夫することで乗り切る方向で検討を進めました。

 Mac にも Windows にも当然独立したプログラムのブラウザ(Firefoxとか Chrome とか Safri など)は存在するので、基本的にスクリプトはそこで動かせればよく、問題はそのスクリプトと Unity 側のプログラムをどうやってリアルタイム通信で繋げるのか?という事になります。ここで、白羽の矢が立ったのが  node.js でした。node.js は Chrome に採用されている JS のエンジン部分だけをとりだしたツールで、JS で書いたプログラムをコマンドラインで簡単に動かすことが出来ます。しかも、各種ライブラリが npm というパッケージシステムで提供されていたりしてとても便利です。これまでも別のプロジェクトや開発ツールとしてたまに使っていたりしたので、実績もあります。今回は開発環境用に各自のパソコンで node.js で WebSocket 通信をおおなうサーバを動作させ、それに Unity 側のプログラムと中継をさせることにしたのです。WebSocket であれば、ブラウザ側の JS とも親和性が高く、簡単にリアルタイム通信を行うプログラムが楽に書けるという大きなメリットがありました。

 図で書くとこのような感じですね↓

 これによって、じつはさらに大きなメリットが生まれました。PC 側のブラウザに搭載されている非常に高機能なデバッグ機能をまるまるスクリプト開発に活用できるようになったのです!一般的にはあまりしられてないかもしれないのですが、このデバッグ機能の便利さは圧倒的で、一度使ったら他のスクリプト言語を使いたくなくなるくらい、すごいものです。一説では、Chrome の開発の大部分がこのデバッグ機能の開発に当てられいるという噂があるくらい。

 さて node.js での中継システムによって、Unity による開発環境でも快適な JS の開発環境の構築ができ、それはすなわち、開発効率向上にもつながりました。スクリプト言語の開発環境は先にもかいたように、非常にシンプルな開発環境しか提供されないことが多く、開発効率を損なっていましたから、その改善も今回の課題の一つだったのでこの結果には大満足です(^^)

 だた、残念ながらいくつかの別の問題もあり、以前のウチのゲームほどゲーム全体をスクリプトでコントロールするというところまでは持って行けませんでした。現在、スクリプトの出番はキャラクターたちのキャラ劇の演出&制御にとどまっています。とはいえ、そこは JS で記述できるので、いわゆるゲーム組み込みのスクリプト言語をこえた複雑な処理も書くことが可能になっています。やろうとおもえば、トロ・ステーションだって出来るくらいですヨ(笑)

 では、長くなりましたが、この辺で。
 次回は本編に戻って、もうちょっとだけつづきます。
コメントを投稿