calendar

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< October 2019 >>

categories

archives

進化の早い3Dライブラリと上手く付き合っていく

0
    JUGEMテーマ:コンピュータ


    3D対戦ブラウザゲーを作ってて、最近思った事をまとめてみます。
    同じような事をやろうとしている方の参考になれば幸い。

    仕事で作るプログラムなんかですと、規模が大きいものはフロントエンド・アプリ・ビジネス・DBと、ロジック毎にレイヤー分けしますが、個人製作でも3Dライブラリを使ってなんかを作る時もレイヤー化した方がいいんじゃない?っていうお話です。

    まずは、その理由から。

    最近は、ブラウザで3D表示させる手法も多様化してきていて、どれを選択すれば良いのか迷ったりします。
    自分はFlashでAway3Dを使っていますが、Away3Dも年一回(以上?)のペースでメジャーバージョンアップされ、その度にライブラリ内の細かい部分が変わってしまうので、プログラム内でちょっと凝ったことをしていると、バージョンアップしたら動かなくなった、という事が毎回発生します。

    このように進化が早いにもかかわらず、3Dライブラリは複雑化していきますので、学習コスト(習得時間)及び製作時間は反比例して増えていきます。自分の場合、Flashでゲームを作るとしたら、昔は一か月もあれば大作(?)ができたものでしたが、3Dゲームとなると、ちょっとしたモノを作ろうと思ったら、最低でも3カ月。それなりのものを作ろうと思ったら半年や1年はかかるでしょう。苦労して作って完成したころには、型遅れになっています。

    常に最新のバージョンを使い続けるという選択肢もありますが、バージョンアップの度にライブラリ内を必死で解読したり、英語フォーラムに質問したりで、それなりに苦労します。

    一方、ウェブでコンテンツを公開する上で、気にしていなくてはいけないのが、閲覧者のPCスペックです。
    自分はネット対戦ゲームを作っている為、対戦相手の動作状況をある程度トレースしています。負荷をかけないように5000ポリゴン位で作っていますが、それでも1/60フレーム近くで動作しいてる人は半分もいません。ソフトウェアレンダリングの人に至っては、全体の1/3以上います。しかしながらユーザ環境は、PC買い替え等によって、ゆっくりと改善されていきます。こういった変化にも注意しながら、どの程度の負荷が妥当なレベルかを見極めていく必要があります。

    コンテンツを作るのに時間をかければ、長い間遊べるものにしたいと思うのは当然ですが、一方で進化が激しい3Dライブラリや変化していくユーザ環境と、どう付き合っていくか、が一つの課題となります。

    というわけで、これらの対策として3Dライブラリとやりとりする部分を、外に出したらいいんじゃねって事です。


    ゲームロジック内から、3Dライブラリをそのまま利用すると、3Dライブラリを変えたりバージョンアップする度にゲームロジック全体を見直さなくてはいけない。ゲームロジックは複雑煩雑化しがちな為、結構大変。


    そこで、3Dライブラリを呼び出す部分は、別クラスに切り出してまとめておく。こうすることで、3Dライブラリを変更する場合は、この中間部分のみを見直せばよくなるので、比較的ライブラリの変化に対応しやすい。 尚、このインターフェイス部分は、できるだけ汎用的に作っておき、どんなゲームでも利用できるように考えて作ると尚良い。


    こうすると、更に分かりやすくなるかも。



    コメント
    コメントする








       
    この記事のトラックバックURL
    トラックバック