これまでのあらすじ §
2010年代初頭、ANGFのモジュールをいくつも作成して一応一つの世界を完成させた自分であったが、そこで「Windowsだけで良いのか」という巨大な疑問が沸いてきた。スマホで動かないとだめではないかと思ったわけだ。
しかし、iPhone開発は金がいくら掛かるか分からないぐらい掛かると分かって、バカヤローと思ってスマホのネイティブ開発はすぐに断念した。
全機種対応はWebでやるしかないと考えた。
その結果、ANGFのWeb版を作らないとダメだろうということで、ANGFWebPlayerを試作した。しかし、これはサーバに過大な負荷を掛けるアーキテクチャ(全プレイヤーの全プレイ過程がサーバに集中する)なので、利用者が増えてもコストが掛かるだけで余り嬉しくなかった。
この流れが変化したのはWebAssemblyとBlazor登場後である。
WebAssemblyとBlazorを使えばC#のコードがWebブラウザ上で動く。
これでいくら利用者が増えてもサーバが破綻しないシステム構築の目処が立った。
それから時間を掛けて全てのANGFモジュールをBlazorで動くように改修した。
これがWANGFである。
これでそれなりに先に進めるはずであった。
だが不満もあった §
Blazorはまだ若い技術で変化が激しかったので、プログラムの本体はRazorライブラリとして作成し、トップのモジュール(ヘッドモジュール)は簡単に差し替え可能とした。
Blazorのデバッグ技術が未熟な時にはBlazor Serverのヘッドモジュールもあったがそれは削除してしまった。
しかし、不満もあった。
- 実行速度が60倍ぐらい遅い
- ネイティブ環境に手が出せないので、ANGFにあったはずの【拡張可能】という特徴がほぼ意味を持っていなかった
- 保存データがブラウザのキャッシュクリアを行うだけで簡単に消えた
- アプリじゃないと遊んでくれないスマホの利用者がいる
それでも、Webブラウザをサポートする全機種対応する技術としてWebAssemblyとBlazorは絶対に必要なものであった。利用者に届かないものはあっても無意味なのだ。
.NET Maui Blazorアプリで変化する情勢 §
.NET Maui Blazorアプリを使うとほとんどの問題が解決してしまうことに気付いた。
- 実行速度が60倍ぐらい遅い→ネイティブで走るので遅くならない
- ネイティブ環境に手が出せないので、ANGFにあったはずの【拡張可能】という特徴がほぼ意味を持っていなかった→ネイティブで走るのでネイティブ環境に手が出せる
- 保存データがブラウザのキャッシュクリアを行うだけで簡単に消えた→一般のファイルに保存できる
- アプリじゃないと遊んでくれないスマホの利用者がいる→スマホのアプリも一緒に生まれちゃう
しかも、手間は僅かだ。ANGFのプログラムの本体はRazorライブラリでしかないので、これを参照して小修正するだけで動作したのだ。
その上である。
構造的にWebブラウザで動作する機能制限版を作るのも凄く簡単なのだ。
Blazor WebAssemblyでそもそも動作しているモジュールなのだ。
.NET Maui Blazorアプリに問題はないのか? §
実はいくつか問題がある。
- ALT+F4でウィンドウが閉じない
- 自分自身を再起動する方法が見当たらない (Webのリロード相当)
1つめはまあそのうちに直るだろう。
2つめは、今後の研究に期待といったところだ。
Mauiにはあまり良い印象を持っていなかったが…… §
正直、Mauiにはあまり良い印象を持っていなかった。
機種ごとに別れたソースが美しくないなあと思っていた。
しかし、よく考えると【ヘッドモジュール】という仕掛けを作って、コアモジュールだけ共通でいろいろな環境向けのバイナリーを別途生成できる仕掛けを使うなら、結局は同じことなのだ。
ならば拒絶することもあるまい。
そうすると、.NET Maui Blazorアプリでも良いことになる。
今後の開発の指針 §
現在検討中の開発の指針はこうなる。
- 従来のANGFに匹敵する機能を持つMaui Blazor版フルWANGF for Windows (かなり開発に時間が掛かるだろう)
- 機能制限が入ってしまうとは思うが、Maui Blazor版WANGF for Android/iPhone
- 機能制限付きのお試し版としてのWeb版WANGF
Mac版とiPhone版はできてしまうので、動くのなら提供するが、こちらに動作確認環境がないので、たぶん無保証になる。
