人喰いの大鷲トリコ面白そうですね。ゲームもやりたいですが、私は粛々と自分のゲームを作ります。
Blenderのエクスポートと謎の儀式
Babylon.jsのBlenderエクスポータを使っていると、とくにアニメーション周りでさまざまなバグが発生します。何がきっかけかさっぱりわからないのですが、エクスポートしてゲーム内で表示するとときどきこんな感じになります。
ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ！ゲッダンとして知られる現象です。頭部はほとんどの頂点がひとつのボーンの上に乗っているため、各部のボーン行列がぶっ壊れても頭部だけは壊れないのが逆にホラー。これを回避するためのバッドノウハウを幾つか発見したので、メモしておきます。BlenderとBabylon.jsを使いたい人は覚えておくと役に立つかもしれません。
-
0フレーム目以前の位置にキーを置いてはいけません。モーションが崩れます。キーを置くのは1フレーム目からです。みるからにエクスポータの実装の穴です - すべてのボーンの変換をクリアしたニュートラルなポーズで立ち続けるだけのアクションを用意して、これが最後のアクションになるような名前(たとえば
zzzとか)にしましょう。 - モーションをエクスポートするときは、この
zzzアクションを選択した状態にし、ポーズをニュートラルにしてからエクスポートします。 - なお、このときボーンは必ず表示しておきます。非表示にするとエクスポート時にエラーになります
- 前回も紹介しましたが、頂点のウェイトは４つまでなので気をつけましょう。5つ以上のウェイトを持った頂点があっても警告が出るだけでエクスポートは成功したように見えますが、どう考えてもモーションは崩れます
- すべてのアクションはひとつに連結されて出力されるのですが、アクションを再生しているときに順番で隣り合っている別のアクションが１フレームだけ見えてしまうときがあります。Babylonのエンジン側のバグですが、これを回避するためにダミーのアクションをそれぞれのアクションの間に挟むといいです
もうバッドノウハウの塊です。一応は筆者もエクスポータのスクリプトも追ってみましたが、動的型付けのPythonでは可読性が低すぎて自分でバグフィックスできるとは思えませんでした。この謎儀式でなぜBlender神の怒りが収まるのかはまったくわかりませんが、まあそういうものです。つらい。動的型付けの言語は自分だけが使う書き捨てのスクリプトだけにしましょう。多人数が継続してメンテするアプリケーションはもちろん、エクスポータのような小さめのスクリプトだって動的型付けの言語で書くべきではありません。やっぱり静的型付けがあったほうが便利だということに最近になってPythonユーザも気づいたらしく、Pythonにも型ヒントを取り入れようとする動きはあるようですが、もういろいろだいぶ手遅れだと思います。型システムはプログラミング言語の根本をなすものあって、後付けでどうにかなるものではありません。
こういうことが起こるのは、３Dモデルを扱うためのファイルフォーマットが統一されず、各オーサリングツールやエクスポータ、そしてゲームライブラリのファイル交換の部分の完成度がちっとも高まらないことが一因だと思います。XOF、VRML、X3D、Collada、FBX……。いろいろなフォーマットが現れては消えていき、標準的といえるようなフォーマットは一向に定着しません。３Dグラフィックスに求められるものがあまりに複雑すぎ、膨大すぎ、そして変化が早すぎるのでしょう。そしてこのたびglTFというものが新たに提案されているとか。筆者としても早くこの状況が良くなって欲しいと思います。
キャラクターのモーションを増やしました
いままで『立ち』と『走り』の二種類しかモーションがなかったんですが、新たに『ジャンプ』（というか『空中』）と『着地』のふたつを増やしました。ジャンプのモーションがないと空中で足をジタバタすることになってすごく不自然でしたし、高いところから飛び降りたときにストっと立ったままになるのもあまりに変でした。最低限この４つがあれば、移動はそこそこ自然に見える気がします。
あと階段ブロックを追加した時には階段を駆け登るモーション、はしごを登るモーションなんかも必要かもしれませんね。それにブロックを置いたりブロックを削るアクションですね。このへんはゲームの世界観やキャラクター性に関わってきます。マインクラフトやドラゴンクエストビルダーズは１辺１メートルほどのブロックを軽々持ち上げてポンポンおいてますが、よく考えると変ですからね。「ゲームだから」で押し通すか、なんらかの理由付けをするか……。先にシナリオを書かなくてはならないかもです。最初はSF的な世界観を考えていたんですが、やっぱりゴシックファンタジーはとにかくどんなユーザにも普遍的に人気があるので使いやすいですし、いろんなことを「魔法だから」で辻褄をつけられるので便利です。何千個ものブロックを懐から取り出しても「魔法」のひとことですべて説明がついてしまいますからね。SFだと一応科学っぽい用語を使って理屈をつけなくてはならず、それはそれで楽しいんですけど難しさもあります。エクスポータのバグはつらいですが、今回一番楽しいのはBlenderでの作業かもしれません。
ゲームプログラミングは難しすぎる
ゲーム開発って難しいですよね。とにかく要求される知識の幅が多すぎます。2D/3Dグラフィックスはもちろん、オーディオ、ネットワーク、ユーザインターフェイスと、幅広い分野について知らなくてはなりません。さらには30ミリ秒ほどで処理を終わらせなくてはならないという効率上の制限の厳しさ。オンラインゲームでは不安定なネットワークをなんとかコントロールして接続を続けなければなりません。プログラミング言語ひとつとっても、今回はJavaScript/PureScript/GLSLの三種を使い分け、さらにBabylongJSがTypeScriptで書かれている関係でそれもある程度は理解する必要がありました。そしてHTML/CSSももちろん使いますし(『プログラミング言語』ではありませんが)、さらにBlenderのエクスポータの問題を把握するためにPythonも読む必要が生じました。この時点で7種類の言語の知識が必要になっています。つらい。
プログラミングのほかにもイラストレーションや3DCGモデリングといったグラフィックの作業もあります。モーション付けでは物理学や人体構造をよく理解していなければなりませんし、キャラクターの衣装を考えるようなときにはファッションセンスすら問われます。さらにシナリオライティングまで。整合性を保ちながら盛り上がる物語を作るのってすっごい難しいんですよ。これがまだ『開発』の部分だけの話で、いろんな人に遊んでもらうには更に広報活動なんかも必要になるかもしれないわけで、プロモーション動画制作なんかも……必要なスキルが多すぎます……。
ユーザインターフェイス
あと、最初のスクリーンショットを見るとわかりますが、ユーザインターフェイスももう少しゲームっぽくしてみました。左上にハートを並べましたが、これは単なるダミーです。ゼルダの伝説っぽくしたかったんです。下の部分には『ホットバー』を設置して、置くブロックを切り替えられるようにしました。『時のオカリナ』は３Dアクションゲームのひとつの完成形として参考にしてます。
それで、そろそろゲームシステムもどうするのか考えなくてはなりません。一応ブロックを置くスタイルのサンドボックスゲームであることだけは決まっているのですが、マインクラフトみたいに完全にユーザ任せでフリーダムなシステムもありますし、ドラゴンクエストビルダーズのようにRPGに近いシナリオやステージを用意する形式もあります。緩やかな目的だけを与えて、シナリオを追いたい人はシナリオをやってもいいし、シナリオを放り出して建築に専念してもいいという感じが、開発している側としてはやりやすい感じもします。
ドラゴンクエストビルダーズを見て思ったのは、建築をする上で住人がいるのは雰囲気がいいなと。マインクラフトは基本的に村人の比重が小さいのであまり村人のために街を作るという感じではないですし、出来上がった街は非常に綺麗でも人影がないので閑散としています。住人がいて住人のために街を作っていくという物語があるとプレイしていてすごく盛り上がるんじゃないかと思います。ただ、住人を用意するのがすごく大変なんですよね。たったひとりのキャラクターを用意するだけでもこんなに大変なのに、街をにぎわすほどの住民を用意するとなるとどんなに大変なことになるやら……。実現可能な範囲は意識しなければなりません。
最近絵文字をぜんぜん使ってないですね。このシリーズの第一回では楽しい雰囲気を無理やり演出するために絵文字を多用したんですが、絵文字探すのつらいんですよ。ゲームのインタフェイスでアイコンを探すのは楽しいんですが……。そういえば、ゲームのインターフェイスのアイコンにはFont Awesomeを使っています。効果音とかもいくつか付け加えました。カメラもなるべく壁に入り込まないようにしています。変更点多すぎて書ききれません。