Google

2014年1月18日土曜日

HTML5で3Dゲーム:CSS3Dの限界

今回はCSS3Dでプロトを作った後の話です。

前回開示した初回プロトですが、その後手を加え障害物・床・壁付きにしたバージョンをお客様にお見せし、そこそこうまくいってる感が出せたのは幸いでした。
この時、ターゲット最古機種でのfpsは57前後だった記憶があります。

が、ぬか喜びもつかの間、さらにプロトを細かく組んだ結果様々な問題がでてきたのです。

当時出てきた問題から大きかったものをざっと列挙してみます。
  • 当たり判定
  • カメラ
  • z-order
まず当たり判定です。
RayCast方式で当たり判定を検出する方法は知られていましたが、このゲームでは主人公と物体との当たり判定になるため、そもそも概念が違います。
さらにポリゴンがロクに出せない関係上、ペラペラの1枚同士が当たるという構成なので、自分で位置を測って独自の判定をしなければならない事になってしまいます。

次にカメラ。
Three.jsを散々調べてもカメラのスコープ範囲に関する処理が見当たりませんでした。
つまり、発生した瞬間の壁やアイテムがちらちら見えてしまう事になります。
遠ければごまかしが効くだろうと安易に考えていましたが、遠いということはそれだけ同時に表示する物体の数が増えやすい(重くなりやすい)という事です。
壁等で隠す手もありますが、それでもDOM制御が劇的に軽くなるわけではありません。
DOM制御は書き方によって劇的に軽くなるのですが、ステージ開始時にゴールまでの全ての障害物を表示するような構造はそもそもダメです。

この時のゲーム構造案はこんな感じでした。

  • 1ステージ:256マス分(非エンドレスモードの場合)
  • 障害物、アイテム配置:1マスにつき2x2の最大4個表示

エンドレスもあるため、開始時に全部出すという構造が元々不可能でした。

そして床や障害物等のz-order。
当初、画面最上位に出るべきGUI、エフェクト、そして後ろから追いかける敵は、別途作業を分けてCanvasかCSSで制御することを考えていました。
、、、と思って床とGUI等を暫定でマージしてみた処、困った問題が発生しました。
最も手前に接近した壁や床、そして障害物等が、z-order設定を突き抜けてGUI等よりも前に表示されてしまったのです。
どうやらiOSのCSS3Dで接近した物体はz-order実装にて実現していた模様です。
当然かも知れませんが、カメラの傾斜角度をちょっと変えるだけでさらにz-orderの最前面が変化してしまうため、常に最前面が同じz-order値でも無いことも解りました。



、、、となると、GUIやエフェクト等のz-orderについてどういった値にすればよいか解りません。
床の傾斜、つまりカメラの角度はゲーム性や見栄え、そして負荷にも結構な影響を与えてしまうため、この時点ではまだ厳密な角度も決まっていなかったのです。
最前面に来た出っ張っている壁はカメラの外という扱いで消してしまえばいいかとも考えたのですが、斜めになっているタイルは、どの位置で消すがが問題になります。
また、床や壁のタイルのサイズを大きくすればするほど、手前ギリギリで消すことはできなくなりますし、小さくすれば制御命令が増加するだけです。
OSや機種別の画面サイズ変化にも対応させる必要もあって、その調整も面倒くさいというレベルでは済まない程になってきました。

また、最も手前の領域はゲーム的にも結構重要で、プレイヤーが避けた後も画像が残るかどうかというのは直感性や難易度にも直結します。
具体的に言えば、画面から消えた瞬間に当たり判定もなくなるという方法がより直感的だという事になるでしょうか。
当たり前ですが、画面上にギリギリ残っている敵や弾にわざわざ近づく人はいませんし。

この最前面のド○に当たれば当然死にます。
消えれば判定も無くなったというのが自然かと。
DOM制御の重さは書き方如何で解消可能ですが、
他にも細かい問題は多々あり、時期尚早な感じは拭えないまま時間が進む日々が

この辺りから全てCSS3Dで処理する方法に限界を感じてしまい、また検証期間のタイムリミットもどんどん迫ってきていました。
(もっと良い方法でやる人は多々居るでしょうが、、、)
夢のフルCSS3Dゲームを目指していたのに、泣く泣く諦める事になってしまった訳です(泣)


しかし泣いてる暇もなく、続けて自前スペハ○のプロト実装が開始しました。
続きます。

0 件のコメント:

コメントを投稿