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 で記述できるので、いわゆるゲーム組み込みのスクリプト言語をこえた複雑な処理も書くことが可能になっています。やろうとおもえば、トロ・ステーションだって出来るくらいですヨ(笑)

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

2014年9月4日木曜日

魔法科高校の劣等生 LOST ZERO 、スタートです!!

IMG_1162
 ついに、魔法科高校の劣等生 LOST ZERO、配信開始されました!零からのスタートです(^^)

 iOS/ Android の両端末に対応している無料アプリ(アプリ内課金あり)ですので、よかったら下記のリンクからダウンロードして遊んでみてくださいね( ´ ▽ ` )ノ

 ちなみに今回の写真ですが、以前、友人の会社がやっているのをみてから、ウチでもやってみたいと思っていたピクチャーケーキというものを配信記念にオーダーしてみましたヨ!ちなみに、iPod Touch とのサイズ比較はこんな感じ。結構デカイ!
IMG_1161
 ちょっと甘めでしたが、スタッフみんなでおいしくいただきました。
IMG_1165
 さて、ソーシャルゲームの場合、配信されてからがいよいよ本格スタートという感じですので、たくさんの「お兄様」たちに楽しんでいただけるように、がんばって運営していきたいと思っています!

 どうぞ、よろしくお願いします!!
 下記のリンクから、直接アプリのダウンロードにリンクしておりますのでゼヒ m(_ _)m

Get it on Google Play

2014年9月2日火曜日

魔法科LZ 第6回:果てし無き、流れのはてに…

DSC03406.JPG
 魔法科高校の劣等生 LOST ZERO (以降、魔法科LZ) 制作ブログ第6回です。

 今回はバトルシステムについての話です。魔法科のバトルシステムはこのゲームの中で最もスクラップ&ビルドを繰り返した箇所であり、苦労を重ねた箇所になります。それも当然といえば当然。ここがこのゲームの中核ですので、一切妥協せずに考え抜く必要がありました。

 第5回のブログで書いたように、バトルシーンに2D表現を取り入れることで、操作感は格段よくなっていったのですが、ゲームシステムとしてわかりにくい点が残ったままでした。反省点として、旧バトルシステムは、普通のターン制バトルにしたくなかったという思いもあり、すこしリアルタイム性を入れた様な微妙なターンともいえない、かといってリアルタイムバトルともいえないようなシステムになっていたました。まず、そこから改良すべきだという事になったのです。では、ターン制なのか、リアルタイムにするのか、というバトル全体を左右する大きな選択肢になってきたのですが、ここは検討の結果、やはりリアルタイムバトルシステムを採用してみるべきだろうという結論になりました。そして、リアルタイムだとしても、それをどうプレイヤーわかりやすく伝えるのかという問題がのこります。そして、その解決案として、具体的には各キャラクターには独立した魔法ゲージを表示して、それがたまったら攻撃できる順番が来るというシステムを考案しました。しかし、まだ終わりではありません、次の検討課題は、そのようなシステムだとしても

  1. 自分の順番が来たときに入力を待ってあげる
  2. 入力とは別に、バトルは進んでいく

のかという選択肢が浮上してきたのです。これは大きな違いであって、プレイ感覚が全く異なります。最初、世の中のスマフォのゲームは1)の入力を待ってあげるという選択肢を選択しているゲームがほとんどだったので、1)が良いのではと思っていました。そうして、そのように試作してみたのですが、なんというかバトルに緊迫感が欠けるのです。これはスクエニのプロデューサーさんからも同様の意見が出たので、世の中の実装とは違っても、ここは世の流れに逆らい、バトルの流れの良さを選択すべきだと決断したのです。こうして、魔法科LZのバトルに関しては、キャラクターが個々のスピードを持ち、プレイヤーの入力とは無関係に進んでいく、リアルタイムバトルを選択することになったのです。

 いよいよ仕様もリアルタイムバトルに決まってきた後、プログラマさんの実装も完成にちかづいてきました。ではさっそくと、その段階のプログラムを遊んでみた所、悪くはないのですが、なんだかちょっとイマイチなのです。緊迫感もあるし、まちがいなくよくなっているのですが、なんというかしっくりこないんです。この感覚、スルーして進むこともできたのですが、なんだか重要な気もしたので、この原因に関しては十分検討してみることにしました。その結果、個々のアクションが行儀よく順々に行われすぎているため、リアルタイムとはいえバトルのテンポ感が阻害されてしまっているのでは?という結論にいたったのです。これだではちょっとわかりにくいと思うので、補足すると、この時のバージョンではリアルタイムバトルではあるものの

  1. 自キャラのATBゲージがたまる
  2. 攻撃指示
  3. 攻撃開始

という流れになるのですが、2)から3)に移る際、他のキャラが攻撃中だったりすると3)への遷移にウェイトが発生していたのです。たしかにこれは無理もない話で、攻撃中のキャラクターがいた場合、その攻撃によって死んでしまったりすることも考えられますから、その結果を受けて、次の行動が決定されるというのは合理的でした。しかし、これによって「タッチしてから攻撃が出るまでに存在するラグ」による操作感のずや、間が発生してしまったいたのでした。

 次はこの問題を解決せねばなりません。解決のために、敵が攻撃中であろうと、キャラを操作したらバンバン攻撃が出るように無理矢理プログラムを改造してもらったところ、さらに緊迫感が増し、実にバトル感覚がよくなりました!しかし、いいことばかりではありません。いつでもタッチしたら技が出るようにした弊害として、プログラムの難易度があがり、バグが出やすい構造、言い方を変えるとデバッグが大変な仕様になってしまったのです。しかし、面白さにはかえられないので、これは腹をくくって突き進むしかありません。がんばれプログラマさん、と陰ならエールをおくっておきました…

 で、この問題が解決したと思った次に、問題になったのが、攻撃の種類です。この段階ですでに3種類の攻撃が考案されていました。

  1. 通常攻撃
  2. 連係攻撃
  3. 必殺技

です。それぞれについてバトルのテンポを阻害しないように、しかも気持ちよく操作できるような操作方法を検討する必要があったのです。1)の通常攻撃は通常のタップですでに決定していたのですが、問題は2)と3)でした。特に2)なのですが、「連係攻撃」だけに操作的にもちゃんと連携感を感じられる操作にしたかったのです。当初、連係攻撃の操作案として上がってきたのは、「なぞる」です。魔法ゲージがたまって攻撃可能になっているキャラを指でなぞって繋げていくとラインが引かれ、その順番で攻撃が出るというアイデアでした。発案当初、これはいい!とおもったのを覚えています。指でなぞってつなげていくというのが、タッチUI ならではですし、直感的で良いと思えたのです…が、しかし、採用されてしばらく遊んでみたのですが、遊べば遊ぶほど、なぞっていくのが面倒になってきてしまったのです。頻繁に行う連係攻撃に「なぞる」という行為はちょっとばかりめんどくさすぎたのです。なので、この操作をあきらめ、技を出したい順番に素早くタッチしていくという、さらにシンプルな操作を採用する事になりました。素早い操作を要求するので、慣れないと失敗することもある操作なのですが、そんなに難しくないし、なによりバトルのテンポを阻害しない操作なのが最高でした。最後に、これらをかんがみて、3)必殺技は間違えて出してしまわないようにキャラをフリックするという操作に落ちついたのです。

 こうして、わかりやすい操作、テンポよく進むバトル、それでいて複数の攻撃も選択可能という最終的な魔法科LZ のバトルシステムが完成していきます。

 これらをすべて入れ込んで、こんどこそ!と自信を持って望んだ再プロトタイププレゼンは無事通過!ようやく長い時間をかけて検討してきたバトルシステムも完成が見えてきたのです。そして、いよいよゲーム制作は佳境に突入していくことになります!

つづく