会社の上司が何やらここ最近面白いものを作っているのでよく仕事中に見せてもらったりしています。
せんちゃです。

いや、仕事は忙しいと言えば忙しいのですけどね。それでも年内は落ち着くのではという算段
よく自販機に向かって歩いてるところを捕まります。
そして2~3時間くらい話します。
気付けば終電ですが、雑談で終電なら辛くはないですよね！

早い話が上司が最近スクリプトエンジンを作っているようで、社員に試験的に使わせているようです。
ゲーム内のオブジェクトの操作は全てスクリプトを通すわけですから、制御は簡単というわけですね。
目の前で例えば。。。とスクリプトを書き換え、makeコマンドを叩くと画面遷移した瞬間には新しいデータです。
毎回アプリを起動したり終了したりする必要がないわけです。
ビルドなんてもちろんなし、あるのはmakeコマンドでスクリプトをデータ化するだけという。


ビルド時間を減らす一番の方法はデータにして追い出す、というのは定説ですが
データを変えただけでいいのだから楽だなこりゃあと。
UnityはゲームオブジェクトをC#スクリプトで制御する仕組みになっているけど
こちらのスクリプトは編集かけると実行中のアプリが止まってやり直しになる。

実際にUnityで開発していても感じましたがUnityはブラックボックスな機能が多い。
例えばWWW通信最中に機内モードや県外になると通信レスポンスもコルーチンの応答もなにも返ってこなくなる、とか
ビルド設定である一つの項目にチェックを入れた途端に特定の端末で落ちるとか
ある特定の端末でのみシェーダーが適応されない、とか
ある特定の（以下略）でのみテクスチャが死ぬとか

そういう話をしていたときに「あれはプランナやデザイナがちょっとしたサンプル品を作るにはいいもんなんじゃないか」
という話になった。
簡単なサンプルを作るにはいいけど商用は結構厳しい気がしています。
何かが起きたときにプログラマは原因が追えなきゃいけないわけですから、Unityのシステムのせいで～なんて言えませんよね。

アプリ開発で一番苦難するであろう部分はまず画像のメモリ。VRAMの使用量なんかは気を付けなければいけない。
そこを考慮して今回見せてもらった自社エンジンは現在のテクスチャメモリの使用量を数値化して見れるようにしたようです。
アプリの段階でもそういったチェックが入るが、その前の段階で特定のサイズ以上の素材は受け付けないようにツール側でエラーを吐くようにしたらしい。
これによってデザイナ側からプログラマに都合の悪い形式の素材は持ってこれない。
「入口で弾く、だけどそれでも漏れたらさらに2重のチェックが待っている」というわけですね。

メモリの使用量もさながら走らせてるコルーチンの数、扱っているオブジェクトの数なんかも見れるようにしたらしい。
コルーチンはマネージャが死ねと言えばどこからでもすべて止めれるのだとか。
視覚的にもゾンビになったタスクはわかるようなのでバグの原因は突き止められる！とのこと。

まぁUnityにもProfilerありますけどね。
プログラマ以外の人がUnityを触るのはちと厳しいかもしれんが。


プログラマの仕事はデータを変換する仕組みを用意する・・・
いやはや本当にそうですよねぇ・・

自分もデータの変換系ツールはもうちょっと頑張って作りたいところです。
ではでは

そこにレリウス=クローバーも入れてくだされ