WebGL Player(仮称)の事業性メモ
okuoku結論 : 無理
- Electronとかでパッケージするのに比べてアドバンテージが無い
- アトバンテージのある市場はiOS除いて小さすぎる (ゲームの場合 1000〜 本)
ゲーム以外の顧客が必須だけど、POSのような市場もWebアプリで割と廻っている( 宇宙船だってChromiumで飛ぶ時代 )ため、何か圧倒的なものが1つか2つ必要。
最も現実的なのは完パケや移植の受託だろう。クラッシュレポートの統合とかその辺を使いまわせるのは大きい。
okuokuWebGL Player(仮称)
- ローダーの.js
- 本体のWASM -- EmscriptenのファイルI/Oを使う
- アセット
の3点を.zipしたものを受け取り、ネイティブアプリとして動作させる処理系。iOS向けには既に Ejecta がある(ただしEjectaにはWASMは無い)。
完全なWebブラウザではなく 、あくまでWASMアプリを動作させるために必要最低限なWebブラウザAPIのCバインディングを持つ。
EmscriptenのファイルI/Oを使う必要性は、そこをパッチして同期I/Oを実現するため。
何故 ？
- Playdate のようなmicroportableには完全なWebブラウザは荷が重い
- PCではWebブラウザがプラットフォーム抽象化層の役割を果たすので、開発されたアプリは事実上どこでも動く
- TAS(Tool Assisted Speedrun)可能性
- コンテンツオーサリングはUnityやGodotのような既存の開発ツールが流用可能
パフォーマンスプロファイラやデバッガは新規開発が必要で、そこの商品力次第と言える。実際Unity WebGL開発とか超クッソ激烈に辛いものがある(が、そもそもWebブラウザで動く必要があるので、そこに制約されるのは仕方ない)。
okuokuWebGPUなら可能性はある？
常識的な規模のMLアプリをホストできるのは大きい。処理系の安定性(Chromeを更新せず放置する必要がある)やストレージ取り回しの面でWebアプリには限界があるので、真面目に取り組めば売り物になる気がする。
ただHALまで提供することになるので必要な手間も大きく、たぶん非常に有望なdesign winが無い限り開発コストを正当化できない = 方々で作られるであろう内製ソリューションに勝てないだろう。(WebGPUは 最初からCバインディングが提供される ため参入障壁が比較的低い)
また、Webブラウザ単体でのWebGPUの魅力があまり無いので、そこに賭けるリスクが大きい。
okuokuTAS可能性
現代的なゲーム開発環境で、逆実行のようなデバッグ処理が可能なものは無い。このため、TASができるレベルで実行環境の抽象化、つまり再現性の保障ができれば、商品性はかなり高まる。(プレイの機械学習に専用対応が不要になる、テスタから受けとったセーブステートから続きを直接プレイ可能 etc)
ただ現実的には、個々のプロジェクトがあからじめ実現してしまっているケースが多い。このためプラットフォームのサポートがあまり必要とされていない。
例えば GGPOはゲームステートの実現部分を明確に分離することを求めており 、実際にそのように実装されているゲームは かなり存在する 。
okuokuFlash
そういやFlashがあったな。。Flashをオーサリングツールとして、Flash以外で再生するシステムは↑のJS実装以外にも、ゲームUIとして使う Scaleform などがあった。
Scaleformのようなembed方向だと需要があるかもしれない。つまり、移植層をギリギリまで減らし、かつ分離可能にできる。ただ、ScaleformはGTA Vのような非常に大きなdesign winがあるのにAutodeskは買収したあげくディスコンにしてしまった。
(現在は、Coherent GamefaceのようなHTML5ソリューションがいくつかある)
okuoku専用機？
コンシューマは厳しい(タイトル専用機として最小ロットは 10000〜 )。サイネージ系統はフルのHTMLや単なるPDFで良い。
グラフィックスの無い領域は(ネイティブとスクリプティングの間を埋める良いソリューションが無いので)大いに可能性があるが。。
ゲームPF事業者は今後もいくつか参入が予想されるので、ゲームならたぶん"プラットフォームonプラットフォーム"(= プラットフォーム抽象化層として使う)が現実的な線だろう。逆に言えば最初の商売(!= 応用)としてゲームは不適。
ハードウェアとしてのKDJ-ONE( http://www.kdj-one.jp/ )は結局ポシャった状態ではあるが、この手の単価の高いデバイスにUIを提供する方向は悪くない気がする。
okuokuメタGame
ミニゲームやインゲームのコメンタリーをUnityで制作して既存のゲームにオーバーレイしたいという需要がある。実際には今のUnityでも可能だが、シーン間の高速な切り替えは分があるかもしれない。
okuoku余った電力を開発環境に使う ★
これ行けるんじゃないか。通常、モバイルアプリケーションはフル性能で動作しない(電力バジェットギリギリで動かすと性能が安定しない)ので性能余力がある。
ゲーム機の開発機はメモリ倍とか載ってるが、バッテリ駆動しないモバイルデバイスは電力バジェットは倍 ...とは行かないが電力バジェット面では余裕がある(アクティブ冷却とかすれば良いので)。
デバイスは温度が高くなると遅くなる。しかし性能のテストを繰り返し実行するとデバイスは熱くなりがちである。ソフトウェアで CPU のクロックを固定してもこうした発熱による性能低下を完全に防ぐことはできない。
開発環境である程度のパフォーマンスペナルティを見込んでも実用性は損なわないのではないか説。例えば遅延リンクやWASM→JSして10倍とか遅く実行しても、ゲームロジックは数%とかしかCPU食わないので大した影響はなく、それよりも差分更新(アプリ再起動を避ける)とか動的解析のメリットを出せる。
okuokuアーカイブフォーマット ？
WASMとアセットをセットにした.zipでゲームが完結するなら、それをゲームの配布フォーマットにすることは当然考えられる。
... 個人的にはダメに一票: WASMは解析容易でほぼソースコードを配っているようなものになるため。
また、これと逆に WASMビルドはmod friendlyでない ので、ゲーム開発者はWebGL Playerだけを最終出力にすることを敬遠するだろう。
↑ のように、UnityのゲームではIL(.net 中間言語)を直接編集する形のMODが割と多い。
もっとも、mod自体がゲームに対して要求される機能性になってきているため、MOD用のSDK(？)まで登場していて、ゲームのリバースエンジニアリングだけがMODではないという現状もある。元々、Sourceエンジンのように伝統的にMODを意識したゲームエンジンは存在する。
ビルドシステム用アーカイブ
有望なユースケースは、各プラットフォーム向けの出力を得るためのビルドシステムへの入力フォーマットとしての利用。Unity自体は既に様々なプラットフォーム向けのパブリッシング機能を持っているが、これを作り込むのは各PFのレギュレーションの変化に対応しつづける必要があるので、かなりのカロリーが必要になる。