ゲーム開発の最近のブログ記事

西川善司さんのMantle記事。 http://www.4gamer.net/games/234/G023477/20130927061/

後藤さんも記事を出していますが、 http://pc.watch.impress.co.jp/docs/column/kaigai/20130927_617112.html

西川さんの記事の方はより「政治的」な背景も説明されており、面白いです。 PS3でのGCMみたいな？　ハードウェア特化APIですね。GCMよりは洗練されている印象を受けますが。 もうコンソールゲーム機業界からは離れてしまったので、PS4時代のAPIは良く知らないですが。

私みたいなマルチプラットフォームに対応させるのに余計な努力したくない系の人にはOpenGL一択だったりするのですが、たしかにドローコールのオーバーヘッド９分の１はすごい。 描画命令をとにかく減らすために、今まで色々と面倒なことになっていましたが、 ここまでオーバーヘッドが減ると、開発・実装アプローチも少し変わることになるのかしら？

「ローリスクハイリターン」というのはたしかに。今まで、CUDAやらCgFXやら、開発者への訴求面ではNVIDIAがリードしていた感が強かったのですが、ここにきて逆転するかもしれません。

とはいえ、通常、開発者はNVIDIAやらIntelやらにも対応しなくちゃいけないので、そういうのを考慮すると、どうなんだろ。 各デベロッパ、自社抽象化ライブラリみたいなものを使っていると思いますが、そういうので吸収しちゃうと、効果が薄れる気がする。 ジオメトリ・バッチのまとめ方その他、実装のアプローチを、Mantle版、その他版とでちゃんと分けないと性能差が出ないですよね。

もっとも、アンリアルエンジンなどの各種エンジン・ミドルウェアの場合は、もしかしたら、 そうした描画処理に落とし込む部分の最適化を、プリプロセス（開発ツール側）で面倒みてくれるようになるかもしれません。 ツール利用者側は、あまり最適化を意識せずにジオメトリアセットを登録すれば、あとは良きに計らってくれるみたいな。 アンリアルエンジンもUnityもあまり触ってないので、想像でしかありませんが。

（前回の記事の続きです）

さて、自作のWebGLのゲームをenchant.jsベースで作り直そう、とした場合にですね。
問題となってくることがあると書きました。

それはなにかというと、enchant.jsのWebGLプラグインである「gl.enchant.js」を使うべきか否かという問題です。
gl.enchant.jsはenchant.jsのお作法ベースで簡単にWebGLの機能が使えますよ。という、いわばシーングラフベースに近い3Dライブラリなんですが、
これがまた自由度が低い低い、非常に割り切った設計になっています。

（以下はgl.enchant.jsのバージョン0.3.7の仕様）
・プリミティブの形式はgl.trianglesのみ（ストリップとかファンとかは使えない）
・デプステストやカリングの有無を切り替えられない（有効で決めうちされている）
・自前のシェーダーが使えない（gl.enchan.js内部で独自のシェーダーが使われている）
・ライティングが標準で有効（オフにできない）
・シェーダーを切り替えられないので、マルチテクスチャとか当然できない。

ほんとに、「ボク３D初めて！」な人向けのライブラリですね。
glコンテキストを取得すれば、色々できるのでしょうが、glコンテキストを引き渡してくれるメソッドも無い模様。

一応、任意形状のポリゴンを描画する機能はあるようですが、いかんともしがたい作りです。

とはいえ、改造してしまえばそれなりに便利そうなんじゃないかというのも事実。
というか開発した人が「そういうことやりたかったらぜひ改造してください」的なノリみたいなw

gl.enchant.jsの補助プラグインで、MMDプラグインとかCOLLADAプラグインとかあるしなー。これらの中身まだちょろとしか見ていないんですが、
これらがちゃんと動いているのは、gl.enchant.jsのドノーマルの機能を使っているのではなく、
実際、gl.enchant.jsのメソッドを上書きして、シェーダーをプラグイン独自のものに切り替えたりとかして、色々やっているわけです。

正直、enchant.jsベースにしつつも3D描画についてはglコンテキストを抜き出してgl直打ちした方が自由度は高いんでしょうけども、
gl.enchant.jsベースにすれば、コーディングの作法がenchant.jsベースの作法に統一できるし、シーングラフベースのAPIはいろいろ楽なことも確かです。

問題はパフォーマンスと細かい制御なんですが、
・前者については、作ろうとしているゲームが、FPSやアクションみたいに、べらぼうにシビアな描画パフォーマンスを要求するようなゲームではない。
・後者については、gl.enchant.jsを改造すればいいんじゃね？　もしくは機能を上書きするプラグインを開発すればいいんじゃね？

ということで、検討を重ねた結果、gl.enchant.jsベースでやってみようかという方向に傾き中です。

しかしなー。どうなんだろうなー。エフェクトツールの「BISHAMON」がそのうちWebGLランタイムをリリースするらしいし、
そうしたら多分、絶対glを直接いじらないと使えないようなランタイムだろうから、
gl.enchant.jsと併用するには、BISHAMON.gl.enchant.jsみたいなプラグインを自作しないとダメだろうなw

うーん。色々大変になりそうだ……。この判断が吉と出るか凶と出るか……w

っと、その前にまだこのことをbeiさんと相談していないんだった（汗）
こういうことはちゃんと話し合った上で決めないとダメだよな^^;

前回の記事で、WebGLによる３D描画と、enchant.jsによる2D描画を組み合わせることを検討しているという話をしましたが、一つ問題があります。

ゲームループの問題です。

現在、私のWebGLゲームプログラムはrequestAnimationFrameによる自前のループを持っています。まぁゲームなんだから当然ですよね。

で、2D描画をenchant.jsにやらせようと、enchant.jsを軌道（game.start()）すると、そう、enchant.jsのゲームループ（requestAnimationFrame）も回るのです。

つまり、ゲームループが２重に発生してしまう。

以下の清水氏による記事では、
http://d.hatena.ne.jp/shi3z/20130521/1369101883

< 引用ここから>

enchant.jsはフレームワークとライブラリの間にあるギリギリの線を狙っている。
　enchant.jsはしかし厳密にはライブラリである。

　なぜかというと、

enchant();

window.onload=function(){
core = new Core(320,320); //ここでコアを初期化する
}

　このように、ライブラリの導入からコアの起動までをユーザが記述する必要があるからだ。
　純粋なフレームワークなら、window.onloadの処理は隠蔽する。

< /引用ここまで>

厳密にはライブラリ、とのことで、その思想含め、「なるほどなぁ」と思いましたが、
やはりenchant.js自身でゲームループを管理している以上、「やはりフレームワークなんじゃないか」という気もするわけです（笑）

で、解決方法ですが、考えられるのは以下の二つですね。

A) enchant.jsを改造して、自前のゲームループを使わせるようにする。
B) 思い切って、ゲームループはenchant.jsに任せてしまう。

いろいろ考えたんですが、A)の改造をした場合、enchant.jsのバージョンアップのたびに改造しなきゃなりません。（いっそゲームループ関連をカスタマイズできるようにしたものをPull Requestしてしまうという手もありますが……多分絶対はねられると思う）

B)の場合、それならもう全部enchant.jsベースでゲームを作り直した方がいいんじゃね？　という話にもなります。

実際、enchant.jsはプラグイン含め、日を追うごとにどんどん高機能化・多機能化しており、乗っかってしまった方が、ゲームに求められるもろもろの諸機能を自作するより開発効率は間違いなく上がるでしょう。（パフォーマンス面はちょっと気になるんですけどね）

なので、今のところ、ゲーム全体をenchant.jsベースに作り直してしまおうという方向に傾きつつあります。

ただ、これはこれでまた別の気になる問題があります。それについてはまた後ほど……。

Webノベルツールでキャラクター「白鳥のラナ」が使えるようになりました。
また、「バックベアード」の表情（ダメージ）を追加しました。

キャラも確実に増えてきて、どんどんお話が作りやすくなってきています。皆様もぜひWebノベルツール、使ってみてください♪

（この記事でいう「CG技術」とは「CG制作ソフトの使い方・ノウハウ」ではなく、「CG理論・プログラミング技術」を指します）

こないだ、ある人から、「ゲーム作りとかに興味があって、CG技術を効率的に学んでいきたいんですけど、どう手を付けたらいいですかね」と聞かれました。
「他にやることもあるんで、できるだけ無駄なくいきたいんですけど」と。

学問に王道なしとはいうけれど、たしかに社会人で勉強となると、できるだけ無駄なく効率的にやりたい、という要件は切実だと思います。
なので、私なりの考えを助言してみました。

Webノベルツールで、カメのアユミ、カのみゆう、ドクガのゆうき、妖怪バックベアードが使えるようになりました。
いやー、一気にキャラが増えましたねぇ♪

え？　妖怪バックベアードってなんだって？

まぁ、使ってみてくださいw

■お願い
諸般の事情で、またWebノベルツールのURLが少し変わりました。その関係で、またプレイ画面が真っ白だったりエラーが出たりする現象が出るかもしれません。
対策として、ブラウザのキャッシュをまたクリアしてみてください。
お手数をおかけし申し訳ありません。

諸般の事情で、WebノベルツールのURLを変更しました。

その影響で、プレイしようとしても、「画面が真っ白で何も映らない」または「エラーが表示される」現象が出ている人がいるかもしれません。
その場合は、ブラウザのキャッシュをクリアして、もう一度試してみてください。
ブラウザのキャッシュをクリアする方法についてはこちらをご覧ください。

ご不便をおかけし申し訳ありませんが、よろしくお願いします。

追記：URL変更と同時に、最初のストーリーリスト画面のテーブルデザインを若干リッチにしてみました。少しは見やすくなったかな？

Webノベルツールですが、今日より、
ストーリー編集画面で文の順序をドラッグ＆ドロップで入れ替え可能になりました。

これ、先端的なWebサービスではすでによく実現されているので、ぜひ私も早くやってみたかったのですが、
なかなか情報が少なく、実現まで時間がかかってしまいました^^;

でも、これで大分使いやすくなったと思います。

使い方は簡単、以下の画像で赤丸で囲んであるアイコンがありますよね。そこをマウスで掴んで上下にドラッグ＆ドロップするだけです。

まだWebノベルツール触ったことない、という方は、実際にドラッグ＆ドロップしているこちらの動画をご覧ください。
（キャプチャソフトの仕様で動きがカクカクしてますが、実際はもっと滑らかです）
　
　
Webノベルツール、皆様もぜひお試しください♪

Webノベルツールですが、若干更新しました。

・これまでは、作成中のストーリーを非公開設定にしていても、ゲームデータ作成ツールの方で、不特定多数の人がストーリーを閲覧することができていたのですが、これをできないようにしました。
・また、同様に、非公開設定にしていても、埋め込み用URLなどが誰でも取得できるようになっていたのですが、こちらも、非公開設定にした場合は取得できないようにしました。
・ストーリー編集画面の表示速度を最大で約2.8倍まで高速化しました。

表示速度については、本当にかなり速くなりました。というか、今までが重すぎたという見方も……。すみません、色々手を抜いてましたorz

他にも、「こうした方がええんでないの？」というご意見ありましたら、どしどしお寄せください^^

Webノベルツールですが、最初にタイトル画面を表示するように仕様変更しました。

これまではいきなりメッセージボックスだけがでてきて、「何をすればいいのかわからない」という方も少なくなかったかと思いますが、これで大分分かりやすくなったと思います。

（「あれ？以前と変わんないよ？」という方はブラウザのキャッシュをクリアしてみてください。）

↓こんな感じ。

　
しかし、このサキミちゃん。すごい豹変ぶりだなw
　
　
　
追記：Internet Explorerをお使いの方だと、タイトル画面で右側だけ灰色の枠が表示されないという現象が起きているかと思います。これはIEのバグです。最新のIE10では直っていますので、これからはIE10をお使いください（爆）