はじめに
Webをメインにいろんなところでいろんな言語でプログラマーをやっている琴音ふぁみと申します。
今回は、2017年3月にバージョン1.0、2022年6月にバージョン2.0がリリースされた比較的新しい技術である WebAssembly (Wasm) の概説と、美少女ゲームのコスト削減およびパフォーマンス向上について語らせていただきます。
この記事は性DEC Advent Calendar 2024に参加しています。
対象読者
この記事の対象読者は、以下のような人です。
- 現在同人ゲームを作っている人（特に、Web がベースとなるエンジンを使用している人）
- 新しい技術に興味がある人
- Unity/UE/Godotなどに物足りない感じがする人
- ゲームエンジンから自作している人
- なんとなく美少女ゲームのありうる未来が見たい人
そのため、まったく技術に興味のない人からすると大変つまらない記事になっていることかと思います。ご容赦ください。
余談
「美少女ゲーム」表記
この記事では、あえて「美少女ゲーム」と表記させていただきます。
理由は主に二つあります。
一つは、この記事がエロゲに限った話ではないこと。 エロゲはノベルゲームとエンジンや仕組みが大まかに共通しているため、今回の記事においてはエロシーンがあるかどうかはさほど重要ではありません。 何なら、ノベルゲームでなくともアクションゲームやRPG、さまざまなジャンルに適用できます。「美少女ゲーム」を「ゲーム」と読み替えてもらっても構いません。
もう一つは、この記事は電車内で執筆されていることです。 コメントは控えます。
タイトルについて
また、この記事のタイトルは同人ゲーム制作に励む女子高生たちを描く漫画「ステラのまほう」を元ネタとさせていただきました。
同じように Rust というプログラミング言語と Wasm を使用してゲーム開発を行う記事に「ラストのまほう」というものがあります。 この記事では主に Wasm に焦点を当てていきたいのでこのタイトルとなりましたが、まさか元ネタが被るとは思っていませんでした……
余談の余談で宣伝ですが、私は現在サークルで百合触手えっち同人ゲームを開発中です。 ブランドの名前は「すてらそふと」です。偶然ってすごいですね。
執筆後追記：今見たら12月1日に「Rustのまほう2」ができてました。○○のまほうシリーズ、増えてる……ｗ
プログラミング言語の種類
では、先ほどから挙げている Wasm という技術は何がすごくて、どのあたりが美少女ゲームと関連性があるか解説させていただきます。
……といきたいところですが、まずは Wasm を語る前に既存のプログラミング言語について少し解説します。 「コンパイル方式」「インタプリタ方式」が何なのかわかっている人は、このセクションは適当に飛ばしてください。
コンパイル方式言語
アセンブリの紹介
まず、軽くコンピューターのプログラムが何でできているかをご紹介します。
以下は数値の引数を 2 つ受け取り、その 2 つの数値を足した値を返す単純な関数を、C 言語で実装したものです。
int add(int num1, int num2) {
return num1 + num2;
}
それでは、これに対してコンピューターが解釈できる言語である機械語に翻訳するコンパイルを行います。 結果は以下の通りです。
add(int, int):
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov DWORD PTR [rbp-8], esi
mov edx, DWORD PTR [rbp-4]
mov eax, DWORD PTR [rbp-8]
add eax, edx
pop rbp
ret
なんだかよくわからない（当社比）文字列が出てきました。
これがアセンブリと言い、コンピューターが読み、実際に内部で実行している命令（正確には、掲載しているものはバイナリではなく文字で表したもの）です。
例えば、Windows で使用される exe ファイルや Mac の app ファイル（正確には、その中身のバイナリファイル）などは、機械語で記述されています。
アセンブリにコンパイルできる言語をコンパイル方式言語といい、今使用したC言語やC++、GoやRustなど、様々なものがあります。
使用例
ということは、みなさんがよく実行されている exe ファイルは、何のプログラミング言語で書いてあろうと中身はアセンブリであり、それをコンピューターが解釈して実行しているということです。
みなさんが鑑賞あるいは〝使用〟されている美少女ゲームの大半は exe ファイルでしょうから、したがってこの世の美少女ゲームの大半もアセンブリが少なからず使われているということになります。
インタプリタ方式言語
一方で、インタプリタ方式言語という言語もこの世には存在します。
インタプリタ方式言語として、一番簡単なものとして JavaScript が挙げられます。この例も見てみましょう。
function add(num1, num2) {
return num1 + num2;
}
これは先ほどの add 関数を JavaScript で実装したものです。
インタプリタとは
ではコンパイル方式言語と比べて何が「インタプリタ」なのかというと、これらの言語は実行する際に「インタプリタ」を必要とするからです。
例えば、アセンブリを除くすべてのプログラミング言語で記述されたファイルは機械語ではないため、コンピューターがそのまま実行することはできません。
コンパイル方式言語では事前にコンパイルを行い、機械語に変換する作業を行っていました。 しかしインタプリタ方式言語では、これらのコードを解釈して実行する「インタプリタ」という実行ファイル（つまり、インタプリタ自体はアセンブリで記述されている）があり、その「インタプリタ」がこれらのコードを解釈して実行しているのです。
これにはコンパイル方式言語と異なり、人間が読みやすく書きやすい、即座に修正し実行しやすいなどの利点があります。
欠点1: コンパイルし exe として配布することができない
例えば、あなたが現在見ているこの Web ページでは JavaScript が動作しており、それによって一部の画面表示が行われています。 しかし、先ほど示したようにインタプリタ方式言語はインタプリタが必須となります。 そのため、インタプリタなしには実行することができないのです。
つまり、インタプリタ方式言語でプログラムを書いて配布するだけでは exe ファイルとして実行してもらえないのです。
欠点2: 大量の演算処理が遅い
これがこの記事において最重要な点です。
インタプリタ方式言語は、一度インタプリタを経由しています。 機械語より「読む」「解釈する」といったフェーズが挟まるため、（一般的には）速度が遅いという欠点も同時に存在します。 （例えば JavaScript を使用する Node.js やそこから派生した Deno, Bun など、とても高速なインタプリタも存在します。しかしそれはインタプリタの実装にとてつもない労力と時間と人員がかけられた結果であり、インタプリタ方式言語は基本的にコンパイル方式言語より遅いと言っても間違いではありません。） よって、高速で大量に演算する処理を実装するのにも適していません。
そのため、ゲームでよく使われる3Dの処理などには、インタプリタ方式言語はなかなか採用されにくいのです。
Wasm の登場
そんな中、WebAssembly が登場します。
WebAssembly は、2017年にバージョン 1.0 が発表された新しいアセンブリの表現方法であり、「Web 上で動作するインタプリタ方式言語である JavaScript の実行速度が遅い」という問題を解決するために作成されました。 Wasm は機械語そのものではありません。実行の際にはやはりインタプリタを必要とします。 しかし機械語にとても近い構文を持っているので、他のインタプリタ方式言語より早いコンパイルと高速な命令の実行が可能です。 （ただし、JavaScript に限ってはあまりに高速すぎて、[JavaScript を実行する時間] ≒ [Wasm をコンパイルする時間] + [Wasm を実行する時間] のような現象も起きることがあります。）
特徴
言語非依存
Wasm は新しい機械語のようなものです。
今までコンパイル方式言語のコンパイラは、実行される環境に合わせて機械語を生成していました。 しかし、コンパイラが Wasm に対応する（Wasm を出力できるようになる）と、一つの Wasm プログラムで Windows, macOS, Linux などいろいろな環境で動かせるのです。
また、コンパイラが対応すればその言語から Wasm プログラムは作成できるため、C 以外にも Go や Rust、すでに様々なコンパイル方式言語から Wasm にコンパイルできるようになっています。
実行環境
Wasm は主に Web ブラウザで動作することを目的として作成された規格ですが、Wasm は汎用性が高く、Web の機能や特徴に依存していません。 そのため、Web ブラウザ以外にもさまざまなプラットフォームで動かすことができ、Docker のようなコンテナの代替技術として注目されています。
採用事例
ですが、そもそも Web ブラウザは Web ページを見るためのものですから、Wasm が必要になるほど Web ブラウザで大量の計算が必要な場面は現在あまりないと言えます。 そして Web ブラウザ以外では、まだ WASI 規格（今回の記事では解説しません）も不十分であり実用的ではありません。
では、どんなところで利用されているのでしょうか？ 実は、みなさんおなじみ美少女ゲームにすでに Wasm の技術は取り入れられ、Web 上でもスマホでも、いろんなプラットフォームで動く時代がすでに来ているのです。
Artemis Engine
とくに有名なものには、Artemis Engine が挙げられます。 このエンジン自体が Wasm に対応しており、Artemis Engine で製作されたゲームはすべて Wasm へコンパイルし Web 上で動作させることが可能です。
Artemis Engine を採用しているブランドのひとつとしてまどそふとが挙げられますが、まどそふとが初めて Artemis Engine を採用した「ラズベリーキューブ」から最新作の「セレクトオブリージュ」まで、すべて Web で体験版をプレイすることができます。 この Web 体験版は、使用しているエンジンである Artemis Engine の Wasm 対応によって成り立っています。
Unity
またおなじみの Unity では、Web 上でプレイする際に Wasm が使用されています。
Artemis Engine とは違い、Unity は3Dゲーム制作フレームワークです。 そのような特性上、物理演算などのリソースを多く使用する計算をしたり、3Dオブジェクトをレンダリングするような大量の計算を行います。 ここで Wasm を使用することで、Unity 製ゲームの Web 上での快適なプレイが実現されています。
Unity 6 では、Build Profiles で Web を指定すると、Web で動作する形式でビルドされます。
その他
今回の記事の目玉ではないので紹介はあまりできませんが、美少女ゲーム以外にも取り入れられているアプリケーションはあります。
例えばすでに廃止され使用できなくなっている Flash を実行できる拡張機能「Ruffle」は、Flash エミュレーターを Rust で記述して、Wasm にコンパイルして動作させています。
ほかにも、Google Meet では背景のぼかし処理などの重い作業に利用されています。
また、少々変態的な事例となりますが、Wasm は既存の C 言語などで記述されたコードからコンパイルすることもできるため、Web 上で仮想マシンを動かす WebVM なる試みも存在しています。 個人的にはこれに興味があるんですよね。ゲームに時々ある「操作できるPC」、操作アクションを起こすとLinuxが動いたらあまりにも楽しそうじゃないですか……？
と言われましても……
まあ、ここまで話しても「別に今までの exe ファイル形式でいいのでは？」と言われると個人的に反論できない部分もあります。
しかし、この Wasm の言語非依存・プラットフォーム非依存をフル活用すれば、美少女ゲーム界隈においても exe 形式を大きく上回るメリットが得られるのではないかと考えています。
美少女ゲームと Wasm
ずいぶん長くなりましたが、美少女ゲーム界隈では Wasm を用いて以下のようなことができると考えています。
事例1: 対応プラットフォームの圧倒的な増加
もちろん、先ほど挙げたそのままの理由で、対応プラットフォームを低コストで増やすことができます。
今までのゲームエンジンにも Android や iOS など、モバイル対応アプリケーションをビルドした事例はありますが、言語がネイティブ対応していない等でネイティブアプリの開発知識が多く必要になることがあります。 Wasm なら、この問題を解決できます。Wasm は統一された規格であるため、Wasm インタプリタを導入するだけで、モバイル対応も可能です。
もちろん、当初の目的であった Web で動作させるということも可能です。 いずれにしろ、インタプリタさえあれば動作する機械語のようなものなわけですから、一度のコンパイルで数多くのプラットフォームへの対応が見込めます。
事例2: クラウドプレイのコスト大幅削減
一方でこの技術は、何もゲーム製作者のみに限らず、現在の販売プラットフォーム運営者（DLsiteやFANZA等）などのコストを大幅に削減できるポテンシャルを秘めているのです。
FANZA では現在ベータ版で美少女ゲームを Web でプレイできる「美少女ゲームブラウザ版（β）」という機能が提供されています。 この機能は、ページをご覧になればわかる通り、クラウド上で美少女ゲームを動作させ、その画面を配信することによって成り立っています。
しかし、この配信にはデメリットが数多く存在します。 まず、記載されているように画質を上げるほど、時間単位で通信量が増えていきます。 また、インターネット品質によっては動きが滑らかでなかったり、場合によっては切断されてしまったり、快適なプレイとは言えません。
ここで Wasm を採用すれば、一度ダウンロードすればローカルで動かせるため、画質やフレームレートを気にする必要はありません。 特に美少女ゲームはテキスト・絵・BGMなど、計算量が少ないシステムのみで成り立っていることが多いため、モバイル端末でもダウンロードしてプレイできます。
Wasm 対応は事業者側にメリットだらけ
ここまで、ユーザーのメリットを挙げてきましたが実は事業者側のほうがメリットが多いのです。
まず、クラウド上で Windows マシンを実行させる必要がないのでその分の経費が浮きます。 動画配信システムも不要なので、その分の経費も浮きます。 そして通信費も浮きます。一度ユーザーがダウンロードするだけ、かつ Wasm とゲームのアセットは静的ファイルであるためです。
クラウドプレイの問題の9割は Wasm で解決する（過言）
なおこの話はソシャゲのWeb版でも同じことが言えます。 ソシャゲも同様の動画配信技術を用いたクラウドプレイを実装している場合が多いためです。
同人ゲーム制作において
例えば、最終的な出力形式が exe 形式で動作するものであれば、Wasm を導入してもらうことで恩恵を受けられる可能性があります。 「自分が使用しているエンジンが Wasm に対応していない」といったことのほうが多いと思いますが、そんな方も頭の片隅にでも置いておいてもらい、実装されたと聞いたときに少しでも検討していただければ幸いです。
また今ゲームエンジンを自作している方は、ぜひ Wasm へのコンパイルをご採用いただき、Web 体験版などの幅広いプラットフォーム対応をご検討いただけたらと思います。
Wasm に限らないパフォーマンス向上
今回は Wasm に限った記事でしたが、JavaScript のみで記述されたエンジンであっても、Web 標準の統一につれフレームワーク等様々な選択肢が増えてきたことによって、既存のアプリケーションにもパフォーマンス向上の見込みがあります。 この記事では解説しませんが、Tauri という新しいフレームワークを使用することで、ツクールやティラノビルダー製ゲームのアプリケーションサイズを 150 MB 以上削減できます。 （性DEC Advent Calendar 参加者向けメッセージ：気が向いたかつ記事を書くことができれば、アドベントカレンダーに滑り込み登録する可能性があります）
おわりに
美少女ゲームにおいて Wasm を用いる利点について、ほぼほぼプログラミングの話しかせずずいぶん長く語ってしまいました。
Wasm に限らず、既存のゲームエンジンでも新しい技術の組み込みに興味がない人は多い（当社調べ）ので、この記事で少しでもパフォーマンス向上やコスト削減に興味を持っていただけたら幸いです。
最後に一言、百合エロゲの供給量を増やしてください！！！！！！