自分がやってる仕事って実は”Unityエンジニア“じゃないかもしれないという話。

クリーンアーキテクチャはゲーム開発に不向き説

以前から、界隈では「UnityでDIコンテナを使おう！クリーンアーキテクチャをやろう！」みたいな話がたびたび盛り上がっている。

私も、「そんなに素晴らしいなら使ってみたい」と思って勉強しようとするたびに、そもそものメリットがサッパリ理解できずに終わるのを繰り返してしまう。

本当にUnityでクリーンアーキテクチャをやるのは優れた方法なのだろうか？じゃあUnity公式のサンプルとかがベッタベタにUnityの普通の作り方になっててクリーンな設計が全然されてないのはなんでなん？

最近はこういう記事も見かけた。

ゲーム開発 に所謂なアプリケーション設計パターンをおいそれと適用するのは難しい

クリーンアーキテクチャというものはUIフレームワークとかWebのアーキテクチャから輸入されてきたもので、ゲーム開発の文脈とは本来無関係なものらしい。

こういう話を聞いてて思ったのは、どうやらクリーンアーキテクチャとか推してる人達と自分のようなタイプのUnityエンジニアでは、想定している仕事の前提条件がまったく異なるんじゃないか？という事だ。

同じUnityエンジニアでも、彼らと私では、全然違う事をやってるのかもしれない。

クリーンアーキテクチャ勢は、おそらく、仕事はこういう風に進むものだと思っているはずだ。
・まず、誰かが事前に”完全”で”フィックス”された仕様書とか、要件定義を用意してくれている
・Unityエンジニアはその要件を見て、最初から完全な設計が行える
・クリーンな設計を考えて、あとはそれを実装すれば、仕事は終わり

シンプルでクリーンな世界観だ。よく知らないがWebとか業務アプリケーションの世界ではこういう感じなのかもしれない。

しかし、私が今までずっとUnityエンジニアとしてやってきた仕事ではまったく状況が異なる。

そもそも、仕様書やら要件定義といったものは存在しない。クライアント（文字通りのクライアントや、あるいは会社の偉い人、上司）の願望（なんとなくこういう風にしたい的な雰囲気）だけが存在する。

別にクライアントに問題があるとか責めているわけでは無い。と言うのも、Unityを使って作るようなゲームやインタラクティブアプリは、事前に全ての要件を洗い出してください。なんて言ったところでそれは不可能である。実際にモックなりを作ってみて、アイデアに具体的な形を持たせて、クライアントにプレイさせてみて、そこで初めて「やっぱもっとこうして欲しい」という新しい要件が生まれ、次の日はそれを実装する。それの繰り返し。私が今までやって来たのはそういう仕事だった。

つまりそこにアプリの設計なんてものは存在しない。単にモックベースでのアイデアの実装を積み上げていくだけだ。

魔法のランプから出てくるランプの魔人のような存在だ。クライアントが願いを言えば、それを叶えてあげる。ひたすらそれの繰り返し。デザイナーの仕事にも似ているかもしれない。デザイナーは絵が描けないクライアントの代わりに要望をくみ取って手早く具体的な形に落とし込む仕事だ。（そして何度も繰り返される修正依頼と向き合う）

何となく良さげな話に聞こえるかもしれないが、実際は地獄に近い。

昨日まではクライアントは”原神”みたいなゲーム（マルチプレイのアクションRPG）を作るって言ってたのに、今日になるとやっぱ”バトルロイヤル”にしたいとか言われてしまうのが私の仕事だ。

どこかの特定の会社とかを問題にしているわけでは無い。今までずっとあちこちでUnityエンジニアの仕事をしてきてどこでもそんな感じだった。だから、私はUnityエンジニアの仕事ってのはこういうもんだと思い込んでたわけだが、そうでもないという事なんだろうか。

もしかするとクリーン勢の方が一般的なエンジニア像なのかもしれない。

それなら、私は自分のようなタイプの仕事をクリーンなUnityエンジニアと区別して別の呼称で呼ぶことを提案したい。

Unityソルジャーというのはどうだろうか。地獄っぽさが出ていると思う。

ダーティな世界のUnityソルジャー

クリーン勢は「クリーンアーキテクチャを使うと機能追加や仕様変更に強くなる」と言う。だったら、毎日クライアントの言う事がころころ変わるUnityソルジャーにとってもクリーンはありがたいのか？

とりすーぷさんのこちらのスライドを引用させてもらう。

こちらで例に出されているオニオンアーキテクチャで言うと、”変更に強い”と言っているのが何を指すかと言うと、”インフラストラクチャ層を差し替えるだけで機能を変更できる”という意味である。

スライドの実装例で言えば、ゲームデータのセーブ、ロードを行う時に、PlayerPrefsに保存してたのをJsonに保存するように差し替えができる。

これはあくまで例なので、そこにツッコんでもしょうがないけど、PlayerPrefsかJsonか、最終的にはどっちかに決まるだろうから、別に決め打ちでベタ書きでもいいんじゃね？とは思ってしまうけど。（だとしてもテストとかが書きやすいというメリットはまだある）

つまり、クリーンアーキテクチャが言う所の「変更に強い」というのは、とは言え”想定された範囲の想定された機能に限って”変更に強いという意味だと思う。設計自体が変更されない場合のみ。

しかし、昨日まで原神を作っていたのに今日からフォトナを作るみたいな、Unityソルジャーが日々落とされる地獄みたいな壮大なちゃぶ台返しの変更には耐えられるはずが無いのである。

オニオンアーキテクチャはドメイン層については”事前に十分設計されていて絶対に変更が無い”事が前提になっている。もしドメイン層までも変更するとなれば、アプリケーション層、ドメイン層、インフラストラクチャ層の全てをゴミ箱にぶん投げて全部書き直すハメになる。しかもインフラストラクチャ層で差し替えが効くように色々用意したバリエーションを全部書き直すハメになるだけ、ベタ書きで書くより悲惨な事になる。

よって、Unityソルジャーから見るとクリーンアーキテクチャの旨味はまったく理解できない。無駄に面倒なだけである。

そもそもクリーン勢がUnityにクリーンアーキテクチャを持ち込もうなんて言い出したのは、Unityが余りにもダーティな作りに寛容すぎる仕組みだからだろう。

（まあその気持ちは分かる。私も他人が作ったUnityプロジェクトのシーンを開いてなんちゃらマネージャがズラッと並んでるのを見たら吐き気がしてくるから。自分が作ったとしてもそんな感じだけど、他人のだとオブジェクトの依存関係がまったく分からない。全てのオブジェクトが全てのオブジェクトから参照されてる可能性（N:N関係問題）があり、どれを消しても大丈夫なのかサッパリ分からない。だからシーン上のオブジェクトが増えるほど吐き気が増す。）

しかし、そもそもどうしてUnityがこういうダーティな作りになってるのか考えてみて欲しい。ハッキリ言って毎日仕様がコロコロ変わる（それ自体はしゃーない）ような中でゲーム開発を進めていくには、Unityソルジャーにはクリーンの真逆、ダーティアーキテクチャが求められるのだ。ダーティの果てに進捗が生まれると言っていい。

UnityはUnityソルジャーに寄り添った作りになっているという事。何でそうなってるのかって、多分、ゲーム業界ではソルジャー的な作り方が一般的なんだろうと思う。ゲーム業界からクリーン的な発想が生まれなかったのはそこだろう。

クリーンに向いているアプリとソルジャーに向いているアプリ

一概にUnityでクリーンアーキテクチャは全部無意味！なんて言うつもりは全然ない。Unityでもクリーンが刺さる場合はあると思う。

Unityを使っていても、ゲーム寄りのアプリじゃなくて、もっと業務用ツールとか普通のスマホアプリに近いアプリを作る場合がある。

Unityで作られたツールっぽいアプリと言うと、例えばバーチャルキャストとかバーチャルモーションキャプチャとか、ああいう感じのものが思いつく。

ゲームじゃ無くてツールなら、事前に完全な要件定義を行えるかもしれない。

この場合、オニオンアーキテクチャ的な作りも刺さると思う。例えばバーチャルモーションキャプチャでoscで通信する部分をudp通信に置き換えられたりできたら便利そうだよね。

逆にゲームであらかじめ完全な要件定義ができるなんて思ってるとしたら、それは無い。ゲームはイテレーション回数が面白さに直結すると言われている。イテレーションと言うのはビルドして実際に動かしてまた変更して…と言うのを繰り返すことだ。ゲームは開発中に毎日調整されている。常に仕様が変わってるという事だ。

あらかじめ完全に要件定義されているとしたら、イテレーション回数がゼロのゲームと言う事であり、それは間違いなくクソゲーになる（オリジナルゲームじゃ無くて既存のトランプとか麻雀をゲーム化する場合には事前に完全な要件定義が可能かも）

採用のミスマッチ問題

就職市場では、クリーン勢もソルジャー勢も、みんなひっくるめて”Unityエンジニア”と呼ばれている。（というかソルジャーというのは私が今勝手に作った用語だが）

企業がUnityエンジニアの募集を出すとき、クリーン勢を求めているのか、ソルジャー勢を求めているのかはハッキリ意識しておく必要があると思う。

例えばソルジャーを雇ったつもりでクリーン勢を雇ったとしよう。
そしてクライアントが雇った彼にお願いする「なんかキャラが１６人くらいマルチ？できて、フォールガイズみたいな感じで試合する感じで。でもVRでフルボディトラッキングできちゃうみたいな」

こんなふわっとした要望でもソルジャーならダーティに対応してくれるかもしれないが、クリーン勢は「じゃあ設計するので要件定義をください」と言うかもしれない。たしかに要件は大事だ。マルチプレイって言っても16人上限でいいのか？もしフォールガイズみたいに60人まで参加できる事が必要ならPhotonCloudは選定できなくなったりするし。

でもクライアントは困ってしまう「要件…って言われても、実際モックみたいなので動いてるのを作って見せてもらわないと分かんないんだよね…」クリーン勢は言う「”そんなふわっとしたお願いだけで設計できるわけないじゃないですか！設計できなきゃ実装もできませんよ！”何言ってんですか！」

採用のミスマッチが生んだ悲劇だ。

まあ逆にクリーン勢を雇ったつもりでソルジャーを雇ってしまってもそれはそれで困ると思う。

Unityソルジャーの受難

Unityソルジャーは毎日クライアントに進捗を見せて、「う～ん、せっかく作ってもらったけど、こうして実際見ると微妙だったからやっぱこうして欲しい」とか言われて作り直す日々を送ってる。穴を掘らされては埋めさせられる拷問に似ている。

大抵の場合、スケジュールぎりぎりまで「ああでもない、こうでもない」みたいな段階から進まないで時間を費やす。そして残り時間が完全になくなってから、「じゃあもうこれでいいや」みたいな感じでようやく仕様がフィックスするのだ。

その時点でコードはグチャグチャの超ダーティ状態になっている。Unityソルジャーがいくらその時点でアプリを綺麗に作り直したいと言ったところで、そんな時間は与えられない。グチャグチャのプロトの叩き台がそのまま使われてリリースまで持っていくケースが多い（シーン名とかプロジェクト名が”test”とかだったりするけど結局そのまま使われる）Unityソルジャーは「こんな状態でリリースしちゃって後でどうなっても責任取れませんよ」と言うより他ない。

そしてリリース後は、アプリは運用チームに引き渡される。
そこで自分が作ったクソ過ぎるコードで悪評が立つ。Unityソルジャーは悲惨なコードの戦犯に仕立て上げられがちだ。何しろ開発中の地獄みたいな経緯を彼らは知らないから、書いたヤツだけがアホに見える。

歴史で例えると、義経が平家討伐ですごく活躍したけど、国を統治する段階になると英雄の存在が邪魔になって抹殺されてしまうような感じだろうか。

運用チームのクリーン勢が「俺ならもっとクリーンに作れるぜ！」とか言い出して作り直しを提案する。完成したアプリをクリーンアーキテクチャで作り直すのは容易な事だろう。なぜならリリースされたアプリ自体がそのまま完全な要件定義だからだ。

えてして、Unityエンジニアはエンジニアの枠の中で評価されがちだ。私が思うに、Unityソルジャーはエンジニアとは似てるようで全く異なる仕事であり、評価の軸も違ってしかるべきだと思うけど。

そういうわけで、アプリを焼き直しただけのクリーン勢が高い評価を獲得し、死ぬほど苦労してリリースまで持って行ったソルジャーの功績は貶められる。

まあこれは実話とかじゃなくて、そういう風になったらイヤだなという単なるストーリーだけど。

Unityエンジニアというのは実際には仕事内容が多彩過ぎて、正当に評価する事が結構難しいと思われる。

Unity開発でシェーダのスキルは必須だと思うが、会社で自分を評価する上司がゲーム畑じゃなかったりしてシェーダに理解が無ければ、「シェーダ？よく分からんがエンジニアっぽく無い事してて怪しいから評価下げとこ」くらいに思ってしまうかもしれない。

Unityは何でも簡単にビジュアライゼーションできるところが注目されて、ゲームと関係ない他業種でも採用が広がってるが、他業種の会社だとますますちゃんと評価されるか分からない。（逆に不当に高く評価されちゃったりして）

私が何となく思う事だが、ゲームの自主開発とかの経験があるほどUnityソルジャーの素養があるような気がする。根性で試行錯誤してゼロからイチを生み出す力と言ったところだろうか。

そして、どうも会社が大きくなって安定してくるとソルジャーの存在は疎まれがちになるような気がする。
ソルジャーは究極的には会社でエンジニアをやるより自分自身のプロダクトを自主開発してくのが一番向いてるのかもしれない。

最後に念押ししておくが、私自身はUnityソルジャーの仕事が好きだ。クライアントの要望を聞きながらゼロベースで対話的にアプリを作り上げていく作業は苦しくもあるがそれなりに楽しい。それに加えて、できれば自分のソルジャーの仕事の正当な評価が得られる事を願うばかりだ。

[追記 21/01/20]　twitterの反応

昨日書いたこの記事ですが、twitterで色々反応がありました。

一通り見ましたが、おもしろいなあ…と思ったのと、ためになるなあ…と思ったのと、あとUnityソルジャー多すぎだろ…と思いました。

色んな人の反応ツイートをまとめてみます。

先日、寝起きに書き殴った記事だけど、誰も読まないかもと思ってたけどありがたい事に結構反響があった。

それはいいんだけど、ある意味で反響がありすぎたので、ちょっと収拾を付けた方がいいかもなと思った。

まず、「記事を書いた人がクリーンアーキテクチャに対して無理解すぎる」みたいな反応が一部にあった。
たしかに、今思えば、あの”憂鬱”の記事を書いた時点で私の理解が足りてなかった面があるかもしれない。

しかし、当然だろう。分かってなかったから勉強していたのだ。

が、なんともありがたい事に、”憂鬱”の記事へのみんなの反応を追っかけてる内に、設計に対する世間のコンセンサスがどんな温度感なのかを結構把握させていただいた。クリーンアーキテクチャへの理解も深まった気がする。つまり、記事を書く前より今の方が理解がクリアになっているはずだ。

私はそもそも、”Unityでクリーンアーキテクチャを学ぶ”的なシリーズのブログ記事を書こうかな！と思って勉強を始めたのだ。

そのモチベーションは、Unityのプロジェクトがシーンが取っ散らかったりしてカオスになりがちなのを何とかしたいと思ったからだ。

まず私の理解が浅かったのは、”クリーンアーキテクチャって言うくらいだから使えばシーンとかがクリーンになるんだろ”程度に思っていたことだ。だが、「クリーンアーキテクチャ」ってのは単にそういう名前なだけで、これを使ってれば全部がクリーンで、使ってなければ全部がダーティというようなもんではないと知った。

これも理解が浅かったが、クリーンアーキテクチャってのはアプリ全般に適用しなければならず、もしインターフェース切らずに参照したらぶっ殺す！（プルリクを）みたいな過激派宗教か何かと思い込んでいた。実際のところは、そんな押し付けるものじゃなくて、別に無理して使わなくていいよ。使えそうなところに使ってね。みたいな優しいアレらしい。そうだよね？

とにかく、そんなわけで当時の私は「クリーンアーキテクチャなんてもんが蔓延したらUnityのプロジェクトはまったく進捗出なくなるぞコレ！」みたく思い込んで、クリーンアーキテクチャを学ぶ記事を書くのをキャンセルして、”憂鬱”の記事をでっち上げた。

”憂鬱”の記事の中でとりすーぷさんのスライドを引用させていただいたので、とりすーぷさんにご迷惑をおかけしないように、「まあバーチャルキャストはゲームじゃ無いしクリーンアーキテクチャが刺さるかも」というようなフォローを入れて極力配慮したつもりだったが、それでもご本人に何らかの動揺を与えてしまったとしたら、

すいませんでした。

また、「主語がデカすぎる」という反応もいくつかあった。何のことかハッキリしないが、多分、「Unityでゲーム開発するのにクリーンアーキテクチャが向いてない」という主張の事だろう。

当時はUnityでのインゲーム的な部分の事ばっかり考えていたが、たしかに、ソシャゲのアウトゲームの通信部分とかは”固く”作るし、別のプロジェクトでも使い回す都合、オニオンアーキテクチャを使った方が便利な部分もあるだろう。

もしも「自分は普通にUnityでのゲーム開発でクリーンアーキテクチャ使ってるが？」という人のお気持ちを傷つけたとしたら、

すいませんでした。

使い回しの話で言うと、Unityで複数プロジェクトで使い回すライブラリに、DIコンテナを使うみたいな事も、それはどうかな？と思っていたけど、結局アウトゲームの話と同じで”固く”、”差し替えが効く”ようにするためにDIコンテナ＆クリーンアーキテクチャを使うのはアリなんだろうなと今は思う。ただ、Zenjectとか特定のDIコンテナに依存してしまうと、vContainer使いたいプロジェクトではどうすんだ？って事になりそうだから、DI使う前提で作るのはともかく、依存はしない方がいいのかもなと思う。

逆に、敵キャラやらのオブジェクトが動的に生成、消滅を繰り返す、MonoBehaviourが跋扈してるインゲームの世界ではクリーンアーキテクチャ使う必要は無い。そういうコンセンサスでいいよね？

”憂鬱”の記事を書きやすくするために、”クリーン勢”という想像上の存在を作ってシャドウボクシングしたわけだが、無理やりUnityのマッチしない箇所にまでクリーンアーキテクチャを教条的に強制する”クリーン勢”なんて現実には存在しなかったわけだ。そうだよね？

毎日仕様変更を言ってくるくせに「コードをちゃんと設計しろ！クリーンに書け」とか無茶なダブルバインドしてくるクライアントも存在しない。

クリーンアーキテクチャについてよく分かってないけど、とにかくこれ使ってなかったら評価下げてくるような上司も存在しない。

仮に、もしそんな連中が存在するとしたら、それは邪悪って事だ。そうではありませんか？

だから、全てをクリーンアーキテクチャで無理やり書かされて、ちゃぶ台返しされる度に全てぶん投げて設計し直すハメになってるような賽の河原の住人も、そんな気の毒な人は存在しないんだよね？

はい。

インゲームに無理にクリーンアーキテクチャ使うメリット無いというコンセンサスが取れたっぽいだけでも記事を書いて良かったと思う。

自分自身の狭い範囲の見識だけで考えていたので、色んな人の意見のおかげで視野が広く持てた。

「Unity以外でもどこでもこんな感じ（ちゃぶ台返しと仕様変更が日常茶飯事）だよ」みたいな反応もあった。それは大変そう。

「どこかのタイミングでクリーンに作り直さないと保守できなくなる」という反応もあった。そうかもしれないけど、ちょっと疑問がある。”憂鬱”の記事で、クリーンアーキテクチャを使うと”変更”には強くなるけど”設計の変更”には脆くなるという話をした。だからクリーンアーキテクチャで全面的に作り直したらもうその後は大きな変更が効かなくなるんじゃないかな。どうなんでしょうか。

「そもそも開発以前に仕事の進め方がおかしい」という反応もあった。まあマトモなエンジニアが拾わないような仕事を拾うUnityソルジャーもいるって事かもな。

ちょっと話変わるけど、今の時代ってアプリを設計して作って終わり。って感じでもない気がする。Paypayとか毎日機能増えてるような勢いだけど。いわゆるマイクロサービス的な話？

”憂鬱”の記事では、Unityでクリーンアーキテクチャが万能に使えるわけでは無いと分かって絶望して、クリーンがダメならもうダーティになるしかねえんだ。みたいな極端な結論を書いてしまっているが、これをクソコードを書く免罪符みたいに使われるのは困る。

私は別にクソコードを書いてるつもりはない。Unity的に普通のコードを書いてるつもり。
マジモンのクソコードはそもそも他人に引き継げない。（普通に難しいアルゴリズムを書いてるから引き継げない場合もある）

さて、そもそも最初のモチベーションだった、Unityプロジェクトを綺麗にする事についてはまだ何も達成できてない。

今は、クリーンアーキテクチャじゃなくても別の方法でUnityプロジェクトを綺麗にできないか考えている。

例えば、vContainerの作者のhadashiAさんが講演で発表した資料がある。

Unity専用最速DIコンテナVContainer と、UnityにおけるDIの勘所

vContainerというのは、ZenjectみたいなUnity用DIコンテナの一種である。

この資料では、UnityでのDIコンテナの使い方として、クリーンアーキテクチャ的な事は特に推してない。

ゲームにシンプルなDI を持ち込んで嬉しいポイント
制御フローをシンプルにすることの補助に使える
オブジェクト間の複雑すぎる関連を抑止する制約をつけることができる

との事。

まだよく分かってないので勉強中だが、ピュアなC#クラスに対してシーン上のMonobehaviourをDIでインジェクトすることで、依存関係をシンプルにしよう。みたいな話らしい。

Monobehaviourにする必要のない物はピュアC#のままにして、なるべくシーン上のゲームオブジェクトを減らす。みたいな事もできそうだ。なにしろシーン上のゲームオブジェクトの数が増えるとそれだけでカオスな感じになるから。

この辺りを勉強して、Unityプロジェクトをクリーンにする便利な方法が見つかったら、また記事を書きたい。

「UnityソルジャーでもMVPパターンくらいはやっとけ」みたいな世間の風潮を感じるので、「別にそれくらいできるが？」というとこを見せつけてやりましょう。

話を分かりやすくするために、Unityソルジャーのタケル君という想像上のキャラクターを登場させましょう。

タケル「俺はタケル。Unityソルジャー 1st。俺が引き受けた仕事に失敗はあり得ない」

今回タケル君に作ってもらうのはこちら。

なんかこういう、プレイヤーのHP表示があって、ダメージボタンを押すとHPが減る感じの戦闘画面的なやつ。

タケル「引き受けよう。報酬は10万。翌月末までに振り込んでくれ」

ステップ１　なんも考えずに作る

タケル君が書いてきたスクリプトはこちら。

//プレイヤー
public class Player : MonoBehaviour
{
    [SerializeField]Text textHp; //HP表示Text
    public int hp = 100; //プレイヤーのHP

    void Update()
    {
        //HPの表示更新
        textHp.text = hp.ToString();
    }
}

これがPlayerのスクリプト。

//ダメージボタン
public class ButtonDamage : MonoBehaviour
{
    [SerializeField] Player player; //Playerを参照

    //インスペクタでButtonのOnClickにセット
    public void SetDamage()
    {
        //プレイヤーのHPを減らす
        player.hp = player.hp - Random.Range(1, 11);
    }
}

こっちがダメージボタンのスクリプト。

実行してみると、ちゃんとダメージボタン押すたびにダメージ受けてHPが減りますね。

たしかに、別にこれでも何の文句も無いけど、ちょっと修正してもらえるともっと良くなるかも。

タケル「要件は満たしてるが？」

うん。そうですね。別に問題ないっちゃないんだけど、Updateの中でHPの変更を毎フレーム監視する作りは、変えてもらえると嬉しいかも。

タケル「まあ、多少のサポートはあらかじめ料金に含まれるから修正に応じよう」

ステップ２　Update()を無くす

修正されたPlayerスクリプトがこちら。

//プレイヤー
public class Player : MonoBehaviour
{
    [SerializeField]Text textHp; //HP表示Text

    int hp = 100; //プレイヤーのHP
    public int Hp {
        get { return hp; }
        set {
            if (hp != value)//変更があった時だけ
            {
                hp = value;
                textHp.text = hp.ToString(); //HP表示を更新
            }
        } 
    }
}

HPのプロパティを用意して、SetterでHPが変更された時だけtextに反映されるようになりました。これでUpdate()が消せたので負荷が減ります。

でも、欲を言えばMVPパターンでModelとViewを分割してくれた方がありがたいかも…。

タケル「MVPパターンって何だよ」

うん…MVPっていうのはUIに使われるアーキテクチャパターンの一種で、これを意識してコード書くと”比較的簡単にいい感じになって嬉しい”って感じだね。

MVPパターンではView（UI）をModel（アプリの状態）から分離して、Presenterで繋ぐっていう形になります。

タケル「何が言いたい？」

まあUnityで言えば、UIに関係ないクラスからUIを切り離すって事かな。現状だとModel(Playerクラス)がView(textHp)を持ってしまってるので。

タケル「元々繋がってたものをわざわざ切り離して繋ぎ直すなんて事をして何が嬉しいんだ？」

まず、UI部品単位で”View”として作っておけば、使い回しが効くから便利だよね。上の図の例で言えば、”バーゲージ”のViewをプレハブとして作っとけば、HPバーとMPバー両方で使えるから便利。これは分かりやすい。

逆に、モデル（上の例だとPlayerクラス）も一か所でしか使われないとは限らないんだよね。戦闘画面のHP表示だけならいいけど、メニュー画面のHP表示は場所も形も違うかもしれないし。戦闘画面は戦闘画面のビュー、メニュー画面はメニュー画面のビューがあるから、モデルはビューと分離しないと厄介な事になると分かる。

タケル「あらかじめ何が必要で何が不要になるか分からないから、実際にそういう複数画面が必要になってから、その時はじめてモデルとビューを分離とか考えればいいんじゃないのか？」

おっしゃる通り。なんだけど、まあ手間がかからない範囲で先読みして柔軟に作る分にはその方がいいんじゃないかって話なんですね。

ゲーム開発の終盤になって、ビューを分割しないとマズいって事に気付いてから初めて分割しようとしても、すでに大量の箇所で参照されちゃってて今さらリファクタリング不可能で後悔するかもしれないよね。

だから常にMVP的に作る習慣をつけといた方が、最終的にはトクする事が多いって事なんだよね。

タケル「なるほど。そこまで言うならMVP的に改修してみよう」

お願いします！

ステップ３　MVP的に作る

MVP的に改修されたスクリプトがこちら。

//プレイヤーモデル
public class PlayerModel : MonoBehaviour
{
    public UnityAction<int> OnChangeHp; //HP変更時のアクション

    int hp = 100; //プレイヤーのHP
    public int Hp
    {
        get { return hp; }
        set
        {
            if (hp != value)//変更があった時だけ
            {
                hp = value;
                if (OnChangeHp != null)
                {
                    OnChangeHp.Invoke(hp); //アクションを呼ぶ
                }
            }
        }
    }
}

PlayerのModelです。

//戦闘画面のプレイヤーモデルのプレゼンター
public class BattlePlayerPresenter : MonoBehaviour
{
    public PlayerModel playerModel; //プレイヤーモデルを参照
    [SerializeField]Text textHp; //HP表示テキスト
    [SerializeField]Button buttonDamage; //ダメージボタン

    void Start()
    {
        //HP表示テキスト
        playerModel.OnChangeHp = ( (hp) => { textHp.text = hp.ToString(); } );

        //ダメージボタン
        buttonDamage.onClick.AddListener( () => { playerModel.Hp = playerModel.Hp - Random.Range(1, 11); });
    }

}

Presenterです。戦闘画面でのPlayerModelに対するPresenterというイメージです。Presenterの粒度をどれくらいにするかは色々意見があるようですが、まあ画面ごとのModelごとくらいの粒度でもいいんじゃないでしょうか。

Viewについては、今回は単にUGUIのTextとかButtonをそのまま使うだけなので、クラスは作りませんでした。UGUIを組み合わせて自作のUI部品を作った時とかはそれがViewのクラスになるイメージ。

この改修で、PlayerModelが直接View(UI)を持たなくて済むようになりましたね。

こういう作りにしておけば、PlayerModelは全てのシーンで共通で持っておきつつ、戦闘画面ではBattlePlayerPresenter、メニュー画面に入ったらMenuPlayerPresenterがいい感じにModelをViewに接続してくれそうですね。

逆に、Viewを操作するとPresenterを介してModelが変更されるようにもなってます。ダメージボタンのやつです。（別にAddListenerじゃなくても普通にメソッド作ってButtonのインスペクタで参照する普通のUnityのやり方でも構わんと思う）

厳密なMVPになってるかどうか分かりませんが、まあ厳密なところは人によって解釈が異なるらしい（Viewひとつ毎にPresenter作れと言う人もいるらしい）ですし、適当でいいでしょう。

タケル「仕事は完了した。後で請求書を送る」

タケル君、ありがとうございました。

ステップ４　UniRxのReactivePropertyを使う

こういう作り方もあるよと言う話で。

私はReactというjavascriptのフレームワークを少し触ったことがありますが、Reactでは状態（state）が変更されると、それに応じて必要なUIが”自動的に反応して”反映されます。

自動的に反応（リアクション）するからReactというわけです。

こういう風に、状態が勝手にUIに反映される作りってカッコいいよね。という文化があるんですね。

で、UniRxというライブラリのReactivePropertyという機能を使うと、そんな感じで状態（変数）の変化に応じて自動的にUIとかに反映する的な作りが簡単に実現できます。

UniRxは機能が多彩過ぎて中々使いこなすのが難しいですが、とりあえずReactivePropertyだけを使うのもアリかもしれません。この機能はSubscribeするだけだから簡単。

ReactivePropertyを使うと先ほどのコードはこうなります。

//プレイヤーモデル
public class PlayerModel : MonoBehaviour
{
    //プレイヤーのHP
    public IntReactiveProperty Hp = new IntReactiveProperty(100);
}

//戦闘画面のプレイヤーモデルのプレゼンター
public class BattlePlayerPresenter : MonoBehaviour
{
    public PlayerModel playerModel; //プレイヤーモデル
    [SerializeField]Text textHp; //HP表示テキスト
    [SerializeField]Button buttonDamage; //ダメージボタン

    void Start()
    {
        //HP表示テキスト
        playerModel.Hp.Subscribe( (hp) => { textHp.text = hp.ToString(); } );

        //ダメージボタン
        buttonDamage.onClick.AddListener( () => { playerModel.Hp.Value = playerModel.Hp.Value - Random.Range(1, 11); });
    }

}

うわ…PlayerModelのコード量がえげつないくらい減りました。

さしものUnityソルジャーでもこれなら嬉しいですね。

“憂鬱”の記事への反応として、「アウトゲームはクリーンに作った方がいいし、インゲームはダーティでもしゃーない」という意見がいくつかありました。

私にとって、この”Unityゲームをインゲームとアウトゲームに分けて考えよう”という発想は、目からウロコで、大きな気付きを与えてもらいました。

ぶっちゃけた話、インゲーム、アウトゲームという用語自体、これまでほとんど聞いたことがありませんでした。
みなさんは知ってましたか？
Unityで作るのは全部ゲームだろ。そのゲームの中にさらにイン（内側）とアウト（外側）があるって何のこっちゃ？とか思いませんか？

ググったら用語の意味が分かりました。

インゲームとアウトゲームの用語を知らなかったので調べた【ゲーム開発】

インゲーム、アウトゲームと言うのは、いわゆるソシャゲ的なゲームアプリ業界で使われる用語だそうです。

私はスマホゲーム会社にいた事もありますが、その時は聞いた事ありませんでした。

インゲームとは、そのアプリ固有の、遊びの部分です。まあハッキリ言ってしまうと、戦闘パートの部分ですね。FGOとかパズドラとかアークナイツとか、戦闘パートでそれぞれのアプリの個性がでます。

で、アウトゲームと言うのはそれ以外の部分です。どんなアプリでも見た目がちょっと異なるだけで大体同じです。なによりもまずガチャがあって、編成画面とか、お知らせ、プレゼント、デイリーミッション、などなど。

インゲームはそれぞれのアプリに固有であり、他のアプリで使い回しは（ほとんど）しません。
最近はスマホゲームでも家庭用ゲームと同等の、凝った３Dゲームが遊べます。
メチャクチャ複雑な構成になっていて、常にオブジェクト生成、消滅が入り乱れて、非常にカオスな状態になってます。（例えば原神とかを想像してください）
インゲームでは、プレイヤーをたのしませるための”体験”を作る必要があります。開発中は、毎日イテレーションが行われ、常に仕様は流動的です。
イテレーションを高速に回して試行錯誤できる環境を維持するのが最優先されますので、いちいちコードを固く設計しても、ちゃぶ台返しなどですぐに崩壊する気がします。

それに対して、アウトゲームはどのアプリでも大体共通であり、他のアプリでも使い回す必要があります。
ですから、バグが無い事、固く作る事が優先されます。
バグが出ないようにするためには、テストを書く事も重要視されます。
アウトゲームでは、UIを操作する事でユーザーのデータに対して変更を行います。
ゲームと言うより業務アプリケーションに近い作りになります。
ですので、クリーンアーキテクチャのようなものも持ち出されてきます。
また、アウトゲームのコードがビュー（UI）と紐づいてると、使い回しが効かなくなるので、コードとビューが分離されてる必要があります。
アウトゲームの仕様は最初からほとんど分かりきっており、あらかじめ完全に設計して仕様を決める事が可能です。
アウトゲームでは、ゲームに必要な”機能”を作る必要があります。
”固く”、”使い回せる”ように作るために、きちんとした設計が求められ始めています。

私はこのまったく正反対といっていいインゲームとアウトゲームをゴッチャに考えていたため、大きな矛盾に悩まされ、どうにかなっちゃいそうでした。

インゲームの考え方でアウトゲームを作ろうとしてもダメだし、アウトゲームの考え方でインゲームを作ろうとしても上手くいかないでしょう。

Unityの作法を無視してUnityでゲーム作ろうとしても、それは船に乗って山を登ろうとするようなもんです。

Unityにだって”コンポーネント指向”という立派な設計指針があります。これを尊重して開発しないとうまく行きません。

ですので、インゲーム（Unity的）とアウトゲーム（クリーン的）はまったくの別物、別の世界として分けて考える方が上手く行きそうです。

すなわち、アウトゲームはカッチリとクリーンに作る。インゲームは普通のUnityの作り方で自由に作る。という事です。

どっちが偉いとか、そういう事ではありません。
インゲームがダメでもアウトゲームがダメでもアプリは上手く行きません。

Unityでソシャゲを作る需要が巨大すぎる

ここまで読んで、「な～んだ、ソシャゲの話だったのか」と思った方もいるかもしれません。

そもそも論として、Unityはソシャゲツクールではありません。

Unityには特にソシャゲ向けの機能はありません。強いて言えばUGUIができて、UIを作るのはラクになりました。

普通はUnityでゲームを作ると言えば、家庭用ゲームとかのインゲームしか存在しないゲームを指すはずです。

ですから、普通にUnityを学んだ人は、私もそうですがインゲーム的な使い方しか知りません。

そりゃそうです。Unityには元々インゲームの機能しか無いですし、インゲーム的な作法しか用意されてません。

アウトゲーム的な考え方と言うのは、悪く言えば何だか知らない内にいつの間にかUnity本来の用法に対してどんどん侵食してきている新たな概念およびツール類だと思います。

特に、こと日本においては、ソシャゲ開発のエンジニア需要があまりにもメチャクチャでかいです。

多分ですが、日本のUnityエンジニアの５割くらいはソシャゲ作ってるんじゃないかな…適当ですが。

そんなんですから、アウトゲーム部分をいい感じに作る技術は大いに求められています。

…という、ここまでの話を前提として押さえておかないと、なんで巷でZenjectがもてはやされてるのかとかの文脈が掴めないと思います。

UnityのC#って醜くないか？

UnityはC#でコードを書きます。

いや…コードってか、UnityのC#って元々単なるスクリプトって扱いなんですよね。

昔はC#以外にも、javascript風のunityscriptとか、Boo言語とかのワケ分らん言語も使えました。

そういう有象無象の言語でゲームのスクリプトが書けますよって選択肢の中の一つにたまたまC#があっただけです。

大体、UnityのC#ってどうかしてると思いませんか？

MonoBehaviourを継承しないと（普通は）使用できない。MonoBehaviourを継承したらnewできないって。変じゃないですか。

昔はnamespaceさえ使えませんでした！

だからそんなキッチリしたプログラムのコードと言うより単なる書き捨てのスクリプトという扱いです。

昔はVisualStudioも使えなくて、Monodevelopとかいう訳分らんIDEを使うハメになってたし。

そんなスクリプト風情を、いちいちコードレビューしますか？

例えばカメラがプレイヤーキャラをフォローするスクリプトを書いたとして、それをコードだけ見て何をどうレビューするんでしょうか。（まあ変数名がコード規約に沿ってるかとか…？）

たとえばたまごっちみたいなゲームを作るにあたって、キャラがうんこするスクリプトを書いたとしますよね？

うんこするスクリプト、コードレビューしますか？

うんこするスクリプト、テストしますか？

うんこするスクリプト、別のアプリで使い回しますか？

必ずしもインゲームのスクリプトにテストとかレビューが必要とも限らないんじゃないかしら…。

まあ、最近はUnityのC#もnamespace使えるようになって、新しいC#機能にも対応して、モダンでマトモなC#みたいな空気を匂わせ始めました。

それがまた事態をややこしくしてるとも言えます。

UE4だとスクリプトは基本、ノードベースのブループリントで作るんですが、インゲームスクリプトもレビューが必要と言う人は、だったらブループリントもレビューするんでしょうか。

UnityのBoltを使った場合はどうなんでしょうか。

まあそこまでインゲームにレビュー、テスト不要説をムキになって主張するでも無いですが、ちょっと思っただけです。

インゲームに設計なんてものがあるのか？

インゲームに設計なんてもんがあるんでしょうか？

まああるような気もしますが、あるとしても、それはクリーンアーキテクチャとかではない気がします。

クリーンアーキテクチャについてはこちらのページを見てちょっと勉強しました。

世界一わかりやすいClean Architecture

これによると、クリーンアーキテクチャは、「フレームワークなんかと結婚するな！」などと言っており、つまり、フレームワークとかはころころ変更されちゃう部分で本質的な所ではないので、ロジックの外側に追い出して依存しないようにしようって事です。

Unityもフレームワークだと思いますが、インゲームのコードをUnityに依存しないように書く事になんか意味あるんでしょうか。

Unity以外へコード使い回したりしますか？

↓こちらのページでは、質問者が「Unityでクリーンアーキテクチャって使えますか？」的な質問を投げており、それに対して「UnityでUnityに依存しないコードは書けない」みたいな回答がされています。FPSゲームでカメラをコントロールするスクリプトなどはUnityの機能にべったり依存してるので、抽象化しようがありません。

https://answers.unity.com/questions/1520540/clean-architecture-or-ecs-or-both-ecs-architecture.html

また、↓こちらのRedditのスレでも、「クリーンアーキテクチャはゲーム開発に適しているのか？」という話題で色々と興味深い議論がされてます。

「クリーンアーキテクチャはどんなソフトウェアにも適用可能なアーキテクチャである」との事ですが、果たしてそのソフトウェアの範疇にインゲームも含まれてんでしょうか？

クリーンアーキテクチャはさておくとして、インゲームではそもそも全体から作り始めるとは限らないという話があります。

例えばスーパーマリオブラザーズは、とりあえずジャンプするゲームだ！っていうコンセプトで始まったそうです。

ゲームは体験を作るものですから、まず先にジャンプの気持ちよさを作りこんだのでしょう。

そこから色々ギミックを生み出して広げていったってところではないでしょうか。

いくらエンジニアが全体から設計したいと思ったところで、ゲームクリエイター、あるいはプランナーのゲームの生み出し方は、そういう細部から全体を作る流れだったり、割と行き当たりばったりだったりするでしょう。

本質的にカオスだと言えるかもしれません。

ちなみに、Unityのインゲームの設計の話で言うと、例えばAdventure Creatorというアセットが売ってます。

https://assetstore.unity.com/packages/tools/game-toolkits/adventure-creator-11896?locale=ja-JP

このアセットを導入すると、まるでUnityがアドベンチャーゲームツクールと化したがごとく、簡単にアドベンチャーゲームが作れます。

また、宴というアセットを使えば簡単にノベルゲームが作れるらしいです。

https://assetstore.unity.com/packages/tools/game-toolkits/utage3-unity-text-adventure-game-engine-version3-80727

インゲームで設計と言ったらつまりこういう物なのかもしれません。

インゲームにクリーンなコードを要求する人は、プロジェクトにUnityアセットをいくつか導入したら、アセット作者がそれぞれ好き勝手な思想で書いたコードがプロジェクトやシーンを汚染しまくっちゃう件についてはどのように考えてるんでしょうか。

もう少しインゲームについて物申しますが、インゲームは最悪チートされる事が前提になってます。

と言うのも、インゲームはクライアント側でゲームが進行するので、不正にクエストクリアAPIとかを叩かれたら、チートかどうか完全に判定できる方法はありません。

ですので、ぶっちゃけ最悪チートされても諦める（どっちみちスタミナが無くなればそれ以上クエスト遊べないから言うほどチートプレイヤーが有利にならない）ようなゲームの作りにしてるはずです。

ですので、いくらテストでバグをどうにかしようとしても、それ以前のガバガバさを内包してるやるせない気分みたいなものがある気がします。

アウトゲームの設計スキルも身に付けた方がオトク！？

インゲームとアウトゲームを完全に分けるという発想のおかげで考え方がクリアになり、むしろアウトゲームの設計も学んでみようかなと言う意欲も湧いてきた気がします。

と言うのも、Unityソルジャーと言えども、インゲームもアウトゲームも両方一人で書け！みたいな仕事を今後請けないとも限らないですし。

なんとなく、アウトゲーム書けるエンジニアの方が給料高そうなイメージです。

と言うのも、ソシャゲアプリで実際に金を生み出すのは、インゲームではありません（もちろんインゲームは重要ですが）。直接金を生み出すのはガチャです。ガチャはアウトゲームです。

ですから、アウトゲームをキッチリ書ける人は、「金を生み出すコード」を書けるエンジニアって感じで、評価が高まりそうです。

金を生み出すエンジニアには金が多く払われるでしょう。

今では個人開発のゲームでもアウトゲームのノウハウはあると便利かもしれません。

例えばPlayfabをバックエンドに採用したら、やる事はまんまソシャゲと同じになりますから。

さて、アウトゲームの設計って、それこそクリーンアーキテクチャだの何だのと、何だか難しそうなイメージがありますね。

しかし、実際にはインゲームと比べて全然難しくないかもしれません。

何故ならアウトゲームはどのアプリでもほとんど同じで、使い回せるものだからです。

そもそも、アウトゲームでやる事って、プレゼントをインベントリに入れるとか、編成データを保存するとか、UIを操作した通りに処理するだけで、大して難しい処理の実装は無さそうですから。

例えば、こちらのページでは、サイバーエージェントの「ボーイフレンド（仮）きらめき☆ノート」というゲームアプリのアウトゲームの設計について詳しく書かれています。

Web出身のUnityエンジニアによる大規模ゲームの基盤設計

やってる事は、この前このブログでも記事を書いた、MVPパターンの応用にすぎません。

しつこく言ってますが、アウトゲームは”どのアプリで大体同じ”で”使い回せます”。

つまり、こちらの記事の内容をありがたく真似させてもらって、一度だけシステムを作れば、あとは今のソシャゲの作りが今後廃れない限り、ずっとこれで食ってけるという事になるハズです。

簡単！

他にも、こちらでは、ミクシィで実際の開発事例を紹介した記事が載ってる、XFLAG Tech NoteがPDFとして公開されてます。

これもやはり、MVPパターンの応用です。ModelがEntityとRepositoryとUseCaseとFactoryの４つに分解されてるのがポイントみたいです。

さらにそのXFLAG Tech Noteの内容を噛み砕いた記事もこちらにあります。

ありがたいですね。

インゲームは常に新しい事を覚え続けないといけません。Unityも常にあれこれ新機能が追加されてます。

それに比べてアウトゲームは一度覚えれば当分食えそうな感じで、学習のコスパがいいかもしれません。

私も勉強して色々分かったらまたブログ記事にしたいです。

ちなみに、「アウトゲームはしっかりテストを書こう！」という風潮があるっぽいです。だからそのためにアウトゲームはピュアC#クラスで書く必要があるとかないとか。

私なんかからすると、どうせロジック自体はサーバーサイドにあって、クライアントはそれを叩くだけなんだから、そこまでキッチリやんなくてもいいんじゃないの？という気がしないでもないですが、よく考えると、例えば”購入”ボタンと”売却”ボタンに逆のメソッドを紐づけちゃったらえらい事になるから、たしかにカッチリテストした方がいいのかも。

おわり

インゲームとアウトゲームの世界を完全に分けるという考え方について書いてみました。

この記事ではまるで全部自分の意見だったかのようにアレコレと書きましたが、実際は”憂鬱”の記事への色々な反応を見て、いいとこ取りして折衷したような考えをまとめた感じです。

色々な人の意見がもらえたのはつくづくありがたかったですね。

その分、この記事もなにか読んだ人の参考になれば幸いです。

ここまでのあらすじ

”憂鬱”の記事から話が続いているこのシリーズですが、ここまでの文脈のあらすじとしては、

１．”憂鬱”の記事で、Unityのゲームにクリーンアーキテクチャなどを適用するのは難しいのではないか？という話をした。

２．（ソーシャルゲームの場合）インゲームはダーティでも仕方ないけど、アウトゲームにはクリーンアーキテクチャなど適用可能であるという意見を見かけた。

３．インゲームとアウトゲームを完全に分けるという発想についての話をした。

４．アウトゲーム的な考え方の第一歩として、基本的なMVPパターンについての話をした。

この記事のシリーズは、ここから”Unityソルジャーが頑張って綺麗なアウトゲーム（インゲームのUIにも適用可能）の作り方を学ぶ”みたいな方向に話を広げる予定です。

そのモチベーションとしては、世間のUnityエンジニアの５割くらいがソシャゲ開発に従事してると思われる現状のニーズを鑑みて、大規模な商業ソシャゲアプリ開発に耐えうるアウトゲーム設計ができるようになれば、それは強みになるだろうからです。

また、アウトゲームの考え方を学ぶ過程で、ソシャゲじゃなくても普通のUnityゲームのシーンとかを綺麗に作るヒントも学べそうだなと考えていますので、ソシャゲを開発する予定が無い人にも役に立つ話になるかもしれません。

普通のUnityのゲーム開発の考え方とは文化が違う面があり、戸惑うかもしれませんが、一歩ずつ順を追って学べばそんなに難しい話にはならないと思います。

単に、インゲーム（普通のUnity）とアウトゲーム（クリーン）で完全に別の話をしてると分けて考えれば大丈夫でしょう。

Unityソルジャーも、エンジニアっぽいスキルを身に付けて、魔法戦士的な両刀使いにクラスチェンジを目指しましょう！

というわけで、今回の記事は、Unity世界と普通のC#世界を繋ぐ架け橋となる重要な存在であるところの”DIコンテナ“の話です。

前回の話で、”インゲームとアウトゲームを分ける”という考え方を書きましたが、「具体的にどうやるの？」という話がまだでした。DIコンテナがそのカギを握ってます。

アウトゲーム？DIコンテナ？興味な～いって人でも、ここから結構話が面白くなってくるはずなので、是非試しに読んでください！

DIコンテナとは一体何なのか？

そもそもDIって何なの？って話ですが、DIとはDependency Injectionの略で、日本語では依存性注入と呼ばれてます。

依存性注入？何やら難しそうな用語が出てきましたね。

しかし、実際は何も難しくないです。

DIとは、クラスのインスタンスの初期化時に、そのクラスが必要としてる他のインスタンスの参照をブチ込んであげる事です。

何のこっちゃ？Unityユーザーでも分かるように説明します。

Unityユーザーは誰でもDIを使ってる！？

例えば、あるGameObjectのコンポーネントに、別のコンポーネントを参照させたい時は、publicのフィールドを定義してから、

こんな風に、インスペクタで参照を突っ込んであげますよね？（画像の例だとButtonコンポーネントを突っ込んでる）

こうする事で、ゲームの開始時に、クラスのフィールドに指定したコンポーネントが実際に突っ込まれて、使用可能になります。

当たり前ですね。

こういう方法は、Unityの初心者でも上級者でも誰でも知ってる方法です。

要するに、これもDIの一種です。初期化時に、インスペクタで指定しておいた通りに勝手に参照を解決してくれてますからね。

複数のコンポーネントがあったり、色んなサブクラスがある時も、一体どの参照をブチ込めばいいのかを、マウスでドラッグするだけで簡単に指定したり差し替えたりできるんですから、つくづく便利なシステムだと思います。

つまり、Unityユーザーなら誰だってDIをバリバリ使いこなしてるという事になります。Unityのシステム自体に便利にDIをやってくれる仕組みが内蔵されてるという事です。

「じゃあ何でDIコンテナなんてもんが必要なの？」と思われるかもしれません。

普通のC#でのDI

ここで一旦、Unityから離れて普通のC#について考えてみましょう。

Unityならエディタのシーンとインスペクタがあるおかげで、自由自在に依存関係を指定して、解決する事が可能でした。

しかし、普通のC#にはそういうエディタはありません。ぜ～んぶコードから自前で依存関係を解決してやる必要があります。コンストラクタから参照を渡してあげる、いわゆる手動DIって事ですね。

でもそれって面倒くさいですよね。

そこんとこを何とかしたいと思って考案されたのがDIコンテナです（多分）。

DIコンテナとは、読んで字のごとく、”DIしてくれるコンテナ”です。

コンテナというからには、何かを格納するんでしょうけど、何を格納するかといえば、クラスのインスタンスです。

つまるところ、DIコンテナの中には、他で使いたいクラスのインスタンスが一杯詰まっており、新しいインスタンス生成時に、必要な参照をコンテナの中身から自動的にブチ込んでくれます。（どのインターフェースに対してどの実体をブチ込むのか、あらかじめコードでルールを記述しておく必要があります）

これによって、Unityエディタが無い普通のC#でも、簡単に依存関係を解決できます。

UnityでのDIコンテナの役割

ここまでで、Unityには元々DIの仕組みがある事と、普通のC#ではDIコンテナを使うという話をしました。

しかし、ZenjectやVContainerは、Unity向けのDIコンテナです。

どうして元々インスペクタで参照を解決できるUnity上でDIコンテナを使う必要なんてあるんですか？

それはつまり、Unity世界と普通のC#世界を繋げるためです。

Unity向けのDIコンテナは、普通のDIコンテナと同様、普通のC#を扱う事ができる事に加えて、Monobehaviourのサポートが追加されてます。
普通のC#クラスにMonobehaviourの参照をブチ込むみたいな事ができるわけです。

ある意味で、前回の記事で書いた、インゲームの世界とアウトゲームの世界を繋げるという話でもあります。

Unityの世界をView的な世界と見なせば、View世界とModel世界を繋げるという見方もできるかもしれません。

相当大雑把に分けると、この表みたいなイメージになります。

この分断された二つの世界を繋げるのがDIコンテナです。

ここからはMVPパターンで言うModelとかViewの用語が出てくるので、まだ読んでない人は前に書いたMVPの記事を読んでおくと理解がはかどります。

ModelをUnity世界から普通のC#世界に引っ越させる！？

二つの世界といっても、Unityユーザーには、まだあんまりピンと来ないかもしれません。

Unityを使ってると、Model的なデータでも、とにかく何でもかんでもMonobehaviourにして、シーンに置くなりプレハブにするなりが当たり前だからです。

Unityのシーンに3Dモデルを置いて、コンポーネントを貼ってシーンに配置するという方法は分かりやすくていいですよね。

が、しかし、例えば単なるゲームのコンフィグデータみたいなものまでMonobehaviourにしてシーン上に配置する必要ってあるんでしたっけ？

Monobehaviourのデメリット

まあ別に、それが悪いという事では全然無いのですが、コンフィグデータみたいなものをシーンに置いちゃうと、別のシーンのロードをしたら消えちゃいますよね。もちろんDontDestroyOnLoadにしとけばいいんですけど、それでも誰かが間違って勝手にDestroyしてしまうリスクはあるわけです。

また、コンフィグデータだの3Dキャラだのが一緒くたになってシーンに置かれてると、シーンが取っ散らかって他人から見るとワケ分らなくなりがちです。

ついでに言うと、Monobehaviourはnewで生成できないので、普通のC#と比べてテストが書きにくいという問題もあります。

この辺が、Monobehaviourである事のデメリットと言えます。

クリーン的なモノの見方で言えば、Unityのシーンなんて、色んなオブジェクトが動的に生成、消滅してて、シーン上にいる限り、どこから誰がいつどんな操作を受けるか分からない、不確定要素が多すぎるダーティでView的な世界だと言えます。
そんな危険な世界にModel的なデータなどを置いておくのは気が気じゃない！

そういった理由から、”必要が無ければMonobehaviourじゃなくて普通のC#で書こうぜ！”というモチベーションが出てきます。

ここんとこは、いつも何でもとりあえずMonobehaviourで書いちゃうUnityユーザーとしては文化の違いを感じるところです。
まあ、DIコンテナが登場する以前はUnity上で普通のC#なんて扱いにくくてあんま使わなかったわけですが。

VContainerの話

もう少し具体的に、VContainterの場合の話をしましょう。

前に書いたMVPの話では、ModelもPresenterもViewも、全部Monobehaviourとして書きました。

でもこれだと、新しいシーンを読み込んだ時に、どうやって新しいPresenterにModelの参照を渡せばいいでしょうか？

まあ、Presenterの初期化時にGameObject.Findとかで参照を取って来るのがUnityの作法ですよね。

でも、もしシーンの読み込み順の問題とかで必要なModelが存在しなければ、null参照エラーが起きますし、確実性が低いっちゃ低い方法ですよね。

ですから、ModelをMonobehaviourから普通のC#に置き換えて、DIコンテナに格納する形にすれば、諸々の懸念は解決します。

さらに、VContainerでは、普通のC#でありながら、MonobehaviourみたいにStartやUpdate関数を書けるようにする機能があるので、Presenterさえも普通のC#に置き換える事が可能になります。

詳しい話はまた別の記事に書くとして、VContainerのマニュアルのページだけ貼っておきます。こちらのページの”6. Inversion of Control (IoC)”の項目でMVPのMとPを普通のC#で書くヤツをやってます。

https://vcontainer.hadashikick.jp/getting-started/hello-world

普通のC#のデメリット

さて、これでシーンとして置く必要が無さそうなクラス、つまりModel的なクラスをUnity世界から普通のC#世界に追い出すことができましたね。

GameObjectの不安定な寿命問題から解放されました。

参照解決のトラブルも減りましたし、シーンもスッキリしましたし、Modelを安全に管理できるようになりましたし、テストも書きやすくなりました。

が、しかし、Monobehaviourでなくなった事は、メリットばかりではなく、デメリットもそれはそれで存在します。

何と言っても、インスペクタで簡単に値を設定できるのがUnityの便利な所だったのに、普通のC#だとそれができなくなります。これがつらい。
エディタのプレイモード時に、値を変更する事もできなくなります。

また、全てがMonobehaviourだった頃は、シーンだけ見てればゲームの全体の動きが追えたのに、普通のC#世界が入り込んでくると追えない部分も出てきてしまいます。

つまりMonobehaviourも普通のC#も一長一短という事で、使い分けが大事になって来るでしょう。

とは言え、シーンを追ってデバッグしないといけないような入り組んだ問題が起きるのは大抵インゲームでしょうから、単にインゲームにはDIコンテナ使わない（インゲームは全部Viewだ！と考える）。みたいなスタンスでもいいのかもしれません。

ScriptableObjectもあるよ

ちなみに、「Unityのシーン上には置きたくないけど、インスペクタで簡単に値を編集できる恩恵は受けたい…」みたいな時は、ScriptableObjectが使えます。

ソシャゲでサーバーから取ってこなきゃいけないようなデータはともかく、最初からアプリ内に埋め込んでても構わない設定値とかは、ScriptableObjectで持っててもいいんじゃないでしょうか。

ScriptableObjectもnewできないからテストしずらいという点に注意です。

VContainerでScriptableObjectを使う方法はこちら。

https://vcontainer.hadashikick.jp/registering/register-scriptable-object

まとめ

今回の記事では、UnityでのDIコンテナについて書きました。

UnityにはそもそもDI機能が備わってますが、それでもUnity用のDIコンテナを用いる理由は、Unity世界と普通のC#世界を繋ぐためだという事。

Unity世界から普通のC#世界に移行する事のメリットとデメリットも書きました。

DIコンテナの役割について、今回の記事の文脈以外の用途について書くのは省きましたが、たとえばUnityのインスペクタで手動で参照設定するのがダルいから自動で割り当てたいとかにも使えるようです。

今回の記事を読めば、前回紹介したXFLAG Tech Noteの内容も分かりやすくなるんじゃないかなと思います。

お詫び

前回の記事で、「アウトゲームの設計は簡単そう！」みたいな事を書いたのに対して、「簡単とは何だ！」とお気持ちを傷つけられた人がいるそうです。

すみませんでした。

私の文章能力の問題で誤解を与えてしまったようですが、私があの文章で実際に云わんとした事を、もっと順を追って説明すると、

まず、アウトゲームの設計の基盤を考える人がいるわけです。この基盤自体を設計するのは、非常に高度なソフトウェアアーキテクチャなどへの知識が求められ、簡単ではありません。これは大変難易度が高い。

それで、そのような高度なアウトゲームの設計を記事に書いてくれた偉大な方々がいたわけです。これは大変にありがたい事ですね。

そのおかげで、それらを真似すれば、我々がアウトゲームを作る時の敷居が下がったというわけで、簡単になったと言ったのはここの所であったわけです。

つまり、そのような記事でアウトゲームの作り方を学べるぞ！というウキウキとした気分と、記事を書いてくださった方々への圧倒的感謝の気持ちだけがあったのがあの文章だと弁明させていただきたい。

さて、私が今自分で書いたあの文章を読み返した時に、一番マナー違反くさいな～と感じたのは、金の話を持ち出してる所ですね。

twitterで「金を生み出すコードを書くのが一番大事！」みたいな事を言ってる人を見かけたので、そういう視点も取り入れてみようかなと思って書きました。

というのも、あの記事の「インゲームとアウトゲームを分けて考えよう」という話からの、「だからアウトゲームの設計について学ぼう」という結論に繋げるのは、ちょっとストーリーの繋がりが弱いと思ったので、金という分かりやすいモチベーションを語っておこうかなという事ですね。

実際に私が金に目がくらんでるとしたら、こんなブログ記事を書いてわざわざ情報を垂れ流すハズ無いですよね。

私が記事を書いているのは、それが妥当なアイデアだと感じたからです。

もしも間違ったアイデアに基づいて、生産性を浪費している人がいるとしたら、もったいない事ですからね。

前置き

前回までの記事で、MVPパターンとDIコンテナの役割について分かりました。

もう必要な知識は全部揃ってますので、あとは、実際にアウトゲームの設計をするだけです。

簡単です！

（前回のお詫びでも書きましたが、簡単というのは、自分自身と読者にそう言い聞かせて簡単だと思い込んでもらうために連呼してるだけで、何かをナメくさった発言とかでは無い事をあらかじめ断っておきます）

”設計をする”というと何やら難しそうですが、今回は実際には自分で設計はしません。既存の公開されている設計をそのまま真似させていただきます。

もんりぃさんがオープンソースで公開されてる”Clean Architecture For Unity”、略してCAFUというUnityアプリのテンプレートがあります。

https://github.com/umm/cafu_core

こちらは実際にキッズスターという会社のゲームアプリで実用されている設計であり、相当”固い”作りだと思われます。

ですので素人が下手にゼロベースで設計を考えるより、とりあえずこちらのCAFUをそのまま使ってみる方が安牌だと思います。

CAFUの設計についてはこちらのスライドなどで語られてます。

今回の記事では、このCAFUの設計をほぼそのまま利用させていただきつつ、自分なりに噛み砕いて解説してみます。

さらに、以前から紹介しているXFLAG Tech Noteですが、そちらで書かれているアイデアからも所々比較しつつ拝借させて頂こうかなと思ってます。

前提としてのクリーンな目線

前回の記事でも少し触れましたが、Unityソルジャーとクリーンなエンジニアの間には文化の違いがあるので、Unityソルジャーもアウトゲームでは割り切って一旦クリーンな目線を頭に入れてください。

まずクリーンな信条として、

「どこに何の処理が書いてるかすぐ分かるようにしろ！」

というものがあります。

どういう処理をするかによって、クラスの命名ルールを決めておくとか、処理毎にクラスを分けるとか、クラス名を見ただけで中身が想像できるようにするとかです。

まあ単に、整理整頓してねって事ですね。

何でそうする必要があるかって、チーム開発では、みんながてんでバラバラに好きな場所に好きな処理を書いて好きなクラス名を付けてたらマジにプロジェクトが意味不明になって取り返しがつかなくなるからです。

ルールが明確なら、コードレビューで何を見ればいいかもハッキリしてるので、時間のロスが減ります。

また、「なるべくテストを書け」という信条もあります。

何でテストを書くのか？っていうのは、想像してもらえばわかりますが、大規模開発でクラスが1000個とかある状況で、その全てがまったくテストされてなくて、何もかもがちゃんと動くか動かないかハッキリしない状態で置いとかれるって逆に怖くないですか？

あるいは、このクラスを修正したいけど、そうしたら他の1000個のクラスに影響出ちゃうなあ…って場合に、テスト書いてなくて修正の影響が確認できない場合、怖くて修正する気が失せませんか？

怖い話を聞いて、段々テストを書きたくなってきたかと思います。

というわけで、クラスを分けまくっとけば、それぞれのクラスのテストも書きやすくなります。

この辺の前提を頭に入れておく必要があります。

まあ、こんな風に一概にルール化できるのも、アウトゲームでやる事がほとんどが定型処理だからだと思います。

アウトゲームでやる事は、
・データの読み込み
・データの書き込み
・データをModelに変換してPresenterに提供
・WebRequestでAPIを叩く

こんな感じの処理に収まるでしょう。

個人的にはインゲームは定型処理に収まらないし、こうは行かないよな～とはやっぱ思いますが、インゲームとアウトゲームで、ソルジャー脳とエンジニア脳を切り替えて考えてください。

今回作る想定の画面

抽象的な設計の話をしていくわけですが、一応具体的な例もあった方が分かりやすいと思うので、このような”キャラクター詳細”画面（CharacterDetailScene）を作るイメージで話を進めていきます。

ステータス表示と、名前変更ボタンやキャラ強化ボタンがある感じです。

CAFU的な設計を考える

まず、特に何も考えずに作ったUnityゲームはこんな感じになりがちです。

全てがダーティなUnity世界に配置されており、カオスな状態です。

いや、ソルジャー的な作りをディスってる訳じゃないですよ。単にクリーン目線だとこういう風に見えているという事です。

アウトゲームについて、今まで記事に書いたMVPとDIコンテナの知識を踏まえると、こんな風に綺麗な感じにできます。ModelをUnity世界からクリーンな普通のC#世界に逃がせましたね。

ちなみにキャラクター詳細画面のModelはこんな感じになると思います。

public class CharacterDetailModel
{
    public string name; //名前
    public int hp; //HP
    public int mp; //MP
    public int atk; //ATK
    public int def; //DEF
}

ただし、ソシャゲを作る事を考えると、これだけだと不十分です。

今のままだと、要するに全部のロジックをPresenterに書くハメになりますよね？ほとんど何でもかんでもPresenterに書いちゃうのは、まだまだカオスすぎると言えます。

というわけで、”UseCase“というクラスを用意しました。Presenterに直接処理を書くのをやめて、Presenterが何かしたいと思ったらUseCaseを叩くようにします。

”キャラクター詳細画面”では、３つのUseCaseが必要になるでしょう。
・GetCharacterDetailModelUseCase→キャラクター詳細画面用のModelを取得する
・ChangeCharacterNameUseCase→キャラクターの名前を変更する
・CharacterPowerUpUseCase→キャラクターを強化する
（このように完全に一つの処理毎にUseCaseを用意するのは、XFLAGでのやり方で、これだとUseCaseのクラス数が膨れ上がる問題があります。CAFUではもう少し粒度が荒くなってて、一つのUseCaseが複数の処理を持ってる形になってます。ケースバイケースです）

いい感じになってきましたが、まだ分からない事があります。上の例の中の、GetCharacterDetailModelUseCaseですが、一体どこからModelのデータを持ってくればいいんでしょうか？

つまり、データの取り扱いについても考える必要があります。

データ層の構造はこんな感じです。

まず”Entity“ですが、これはデータが定義されてます。Modelと似てますが、Entityはサーバーから返ってきたJsonデータとか、マスターデータとかの、大元のデータが定義されてます。

例えばキャラクターデータのEntityはこんな感じでしょうか。

public class CharacterDataEntity
{
    public string name; //名前
    public int hp; //HP
    public int mp; //MP
    public int atk; //ATK
    public int def; //DEF
    public string likeFood; //好きな食べ物
    public string dislikeFood; //嫌いな食べ物
}

↑キャラクター詳細画面のModelとほとんど同じですが、好きな食べ物とかの、キャラクター詳細画面では必要ないデータも含まれてます。

“Model“というのは、それぞれの画面で必要なデータだけを、画面(View)ごとにEntityから抜粋して加工したものになります。

“Repository“は、Entityデータを持っています。という事は、Entityデータ毎にRepositoryが対になって存在する形になるかと思います。UseCaseからEntityデータくれと言われたら渡してあげます。EntityデータはDataStoreから持ってきます。

”DataStore”はデータの読み込み、書き込み先です。ScriptableObjectだったり、PlayerPrefsだったり、はたまたAPI叩いてサーバー上からデータをもらう、書き込むとかするパターンがあるかと思います。

RepositoryがEntityをScriptableObjectから持ってきたい時は、ScriptableObjectDataStoreを、PlayerPrefsから持ってきたい時はPlayerPrefsDataStoreを叩く形になります。

CAFUではさらに”Translator”というのも用意されています。EntityとModelを相互に変換するものだそうですが、すいませんがまだよく分かってないので今回は省きます。

ここまでで全体をまとめるとこうなります。

こうして図で見るとややこしそうに見えますが、ここまで説明した通り、MVPに加えてデータの取り扱い方を決めた程度で、そんなに難しい事はしてません。

この図で重要なのは、例えばUseCaseがRepositoryを通り越して直接DataStoreを触ったり、PresenterがUseCaseを通り越して直接Repositoryを触ったりしないようにする事です。

どうしてそれぞれのクラスの触れる範囲を制限するか？というと、もしPresenterが何でもかんでも触ってＯＫだったら、この設計を無視してPresenterに全てを書いてしまう輩が出てくるかもしれなくて、設計が崩壊するからです。

そもそも何でこういう設計になったのか？という説明をこの記事ではだいぶ省いていますが、クリーンアーキテクチャによる合理的な設計になってます。詳細はもんりぃさんのスライドなど参照してください。

それぞれのクラスが疎結合になってるので、例えば画面の見た目の仕様が途中で完全にひっくり返ったとしても、見た目の変更だけならドメイン層やデータ層にはダメージは及びません。

あるいは、あるEntityの保存先がローカルからサーバーに変更されたとしても、単にRepositoryが参照するDataStoreを差し替えれば済むので、ほぼノーダメージで済みます。
もしこれが決め打ちでUseCaseから直接PlayerPrefsとかを読み書きする作りだったらダメージがでかかったハズですよね。

でも、ちょっと疑問なのが、この設計だとEntityが変更されたら相当ダメージの影響範囲が大きい気がしますね。Entityは割とどこからでも触りますから。
結構サーバのAPIに仕様変更が入ってEntityの持ち方が変わる事ってありそうな気がしますが、どうなんでしょうか。

以前に”憂鬱”の記事では「ゲームにクリーンアーキテクチャを使うのは難しい」と書いたのに、今回の記事では使っとるやんけと思う人がいるかもしれません。
念押ししておきますが、私の今の考えでは、”アウトゲームは定型的な処理だから、仕様変更があっても設計自体が変わる事は起きないので、クリーンアーキテクチャが適用可能”と思われます。インゲームは無理そうという考えは変わってません。

キャラクター詳細画面表示の流れ

設計の全体像が掴めたので、キャラクター詳細画面表示の時の処理の流れを考えてみます。

ModelをViewに反映するまでの流れを図にするとこんな感じです。

まず、Viewは上に貼った画面の通りです。

Modelも上述したCharacterDetailModelとなります。

①Presenterは、まず画面に表示するModelを取得したいので、GetCharacterDetailModelUseCase.Runを叩いてModelを要求します。

②GetCharacterDetailModelUseCaseはCharacterDataRepositoryを叩いてCharacterDataEntityを要求します。

③CharacterDataRepositoryは、例えば今回はPlayerPrefsからデータを持って来るとして、PlayerPrefsDataStoreを叩いて、④⑤CharacterDataのEntityを取得して⑥⑦UseCaseに返します。

GetCharacterDetailModelUseCaseに戻ってきましたが、もらったEntityから必要なデータだけを抜粋して、⑧⑨CharacterDetailModelというModelに変換して、⑩Presenterに返します。

⑪Presenterは、もらったModelデータをViewに反映させます。

そしてPresenterは、”名前変更ボタン”が押されたらChangeCharacterNameUseCaseが叩かれ、”強化ボタン”が押されたらCharacterPowerUpUseCaseが叩かれるようにボタンのOnClickにAddListenerしておきます。

また、”強化”されたらキャラのパラメータが変化するはずで、これはModelの変化なので、Modelの変化にトリガーされて、Viewの表示が更新される処理もReactivePropertyにSubscribeされて仕込まれてるでしょう。”名前変更”も同様です。

まあ今回のキャラクター詳細表示画面の例で行くと処理の流れはこんな感じでしょう。

ローカルにキャッシュされたデータを取得するだけじゃなく、通信などを挟んでデータを取得する場合は、取得するまでに時間がかかりますから、画面遷移時にローディング表示などを挟んでデータ取得を待つ必要がありそうですね。

XFLAGとの違い

XFLAG Tech Noteでも、おおむねCAFUと同じような設計になってますが、ちょっとだけ違います。

XFLAGではRepositoryはDataStoreを叩きません。
その理由はPDFの32ページあたりから詳しく書かれているのですが、かいつまんで説明します。

もしもCAFUみたいにRepositoryが毎回DataStore（サーバーのAPIを叩く）を参照する作りの場合、画面を開くたびにAPIを叩いて通信が発生してデータを取り直してしまいます。

Webページならそういう作りでしょうが、ゲームの場合はイチイチ通信して毎回データを取り直すまでも無いです。

ですのでXFLAGの設計では、アプリの起動時に必要なデータを全てサーバから取得して、Repositoryにキャッシュしておきます。
そして、例えばキャラの名前の変更をした時は、UseCaseがAPIを叩いてサーバ側のデータを更新して、さらにその後RepositoryのEntityキャッシュも更新する。という流れで処理をします。

つまり、XFLAGではScriptableObjectとかPlayerPrefsのようなローカルデータは一切使用しない想定という事です。（多分）
まあアプリにデータを埋め込んでしまうと、もしそのデータを変更したくなった時はストアのアプリを更新するしかなくなるので、一切アプリにデータを埋め込まない作りもアリだと思います。
ですから、XFLAGではDataStoreは存在せず、UseCaseが直接APIClientを叩くという作りになります。

CAFUにはDataStoreがありますが、CAFUはガチなソシャゲだけでなく、もっとカジュアルなゲーム（例えばサーバと通信しないローカルだけのゲーム）での使用も想定しているという事だと思います。

ユニットテスト

クラスの役割を分けて、ルールを決めたので、すでにテストは書きやすくなってます。

実際にテストを書くには、テストしたいクラスがアクセスする周りのクラスにインターフェース切っておく必要があります。

例えばCharacterDetailUseCaseをテストしたければ、CharacterDataRepositoryを直接触らないで、ICharacterDataRepositoryみたいなインターフェースを切ってワンクッション置いておく必要があります。

つまりCharacterDetailUseCaseにMockCharacterDataRepositoryとMockApiClientを注入してテストするという感じです。

いちいちインターフェース切ってMock版のクラスを実装するのは面倒くさそうですが、品質のためにも是非やってください。（クリーン目線）

EntityやModelは変数しか置いてないのでテストは要りません。

ちなみに本番アプリではDIコンテナでインターフェースに対して本番クラスをぶち込むように指定します。

どのクラスで何をテストすればいいのかとか、詳しい事は上でリンク張ったもんりぃさんのスライドを見れば書いてあります。

今回の設計だとUseCaseのクラスの数が相当膨れ上がりそうな気がするのですが、Presenterのテストを書くとなると全てのUseCaseにインターフェース切ってMockを作る作業量がヤバそうです。
XFLAGでは”Model層以下は基本的にユニットテストを書くようにしています”との事で、という事は逆に言えば、Presenterとかのプレゼンテーション層はテスト書いて無さげで直接UseCaseの実体を触ってるようです。
それでもいいんじゃないかな。
もんりぃさんのスライドでも”Presenterレイヤーはテスト書く価値低め”と書かれてます。

まあ、どこまでインターフェース切るのか？どこまでテストするのか？とかは、アプリの種類、目的、規模感によっても判断が変わってくるでしょう。

まとめ

CAFUとXFLAG Tech Noteを参考にして、クリーンなアウトゲーム設計について話をしました。

CAFUはオープンソースですし、サンプルゲームのリポジトリもあるので、実際に自分でアウトゲームを作る時は参考になるのではないでしょうか。

ただ、個人的な感想ですが、CAFUのサンプルゲームのソースを流し見しても、UniRxが多用されてたりしてて正直よく分かりませんでした。

XFLAGはプロジェクトが公開されてるわけではないですが、記事に書かれてるソースコードは分かりやすいです。

もし私がアウトゲームを作るなら、CAFUの設計とXFLAGのソースを参考にしながらとりあえず自分なりにゼロから書いてみる感じかなと思います。

しかし、こうしてしっかり調べてみても、やっぱりこのようなアウトゲーム的な考え方でインゲーム作るのって難しいよな…という気がします。

CAFUのサンプルゲームのインゲーム（もぐら叩き）は実際にこの設計に従って作られてるので、「実際にやれてる例がここにありますが？」と言われるとまあそうなんですが、例えばFPSを開発するとして、このアーキテクチャのどこがどうゲームプレイに当てはまるのか、想像できないですよね。

ただし、インゲームでもUIについては普通にアウトゲームと同じように作れるかと思います。

さて、今回の記事では単なるデータを扱う場合の話でしたが、実際のゲームでは、画像をＤＬしてキャッシュしたい時はどうするの？とか、AssetBundleはどうするの？みたいな話も出てくるかと思われます。

私もアウトゲーム設計は理論としては分かってきまものの、実戦経験はまだまだなので、ハッキリした事は言えませんが、今回の設計のRepositoryとかEntityの中に納まるかもしれませんし、そうでなくても応用してアレンジしていただく形になるかと思います。

今回の記事では割と抽象的な設計の話に留まって、イマイチ具体的な話に踏み込めませんでしたが、その内に実際に設計に従ってサンプルプロジェクト的な物を作ってみたいと思います。

参考リンク

私は大体毎日鶏むね肉を100g食べてます。

その理由は、疲れを軽減してパフォーマンスを上げるためです。

なんのこっちゃ？

疲労と回復のメカニズム

以前に、「すべての疲労は脳が原因」という本を読みました。

ぶっちゃけ今回の記事は、単にこの本の内容を紹介するような感じになると思います。

みなさんは、「疲れた～」と思った時に、実際は体で何が起こってるのか知ってますか？

「疲れるのは身体を酷使したから疲れるんでしょ？」と思うかもしれませんが、確かに運動したら疲れますが、ずっとデスクワークしててまったく身体を動かしてなくてもやっぱり疲れますよね？

変じゃないですか？

この本では、「疲れてるのは体じゃなくて脳なんです！」と書かれています。

つまり、運動したから疲れた～。と思っても、実は筋肉はまだ全然余力があるんだけど、脳が先に疲れちゃってるという事です。

ロボットで例えると、各関節のモーターはまだ全然余裕なんだけど、制御コンピュータが先にオーバーヒートしちゃってるような感じでしょうか。

たとえば走っている時ですが、脳は常に全身のバランスを取ったり、呼吸を整えたり、汗をコントロールしたりして、自分では何も意識しない所で物凄く忙しく働いてます。

デスクワークでも、キーボードを打ち込む指は動かし続けてますから、指の操作を担当する神経は疲れてしまいます。

脳が疲れるって何を意味するのか？というと、脳を働かせすぎると、脳内に活性酸素が発生します。
活性酸素は神経を傷つけてしまいます。
それが疲労感の原因です。

そして、脳の疲労を回復する唯一の方法は、睡眠を取る事です。

寝ている間は、ある種のたんぱく質が働いて、脳の疲労を取ってくれます。

問題は、加齢で歳を取るほど、自律神経の機能が低下する事です。
50代では、10代の1/3にまで落ち込むらしいです。

脳の疲労にはかなり気を付ける必要があります。
疲労が蓄積するのを放置してると、自律神経が壊れて”がん”の原因になったり、脳梗塞の原因になったりします。

まあとにかく、疲労を回復しようと思ったら、腕とか足をどうこうするよりも、脳の疲労を取り去らなけれればならない事が分かりました。

疲労を軽減する方法が分かった！

本の著者の梶本さんは、産官学連携の疲労研究プロジェクトに携わっていました。

もはやすでに日本人の慢性的な疲労は、国家的問題に達していたという事です。

梶本さんは「脳の酸化が疲労の原因なら、抗酸化物質を食べれば、疲れを軽減できるんじゃないの？」と考えました。

という訳で、色んな抗酸化物質を食べさせて運動させたりして実験しましたが、どれもこれも大して疲労には効き目が無い事が分かりました。

というのも、たしかに抗酸化物質は効果はあるんですが、全身の細胞に満遍なく働いてしまうので、効果が分散してしまって、脳の疲労への効き目は貧弱だったのです。

ちなみにカフェインとかも試しましたが、カフェインは疲労軽減じゃなくて、疲労のマスキング効果があるだけでした。
つまり、疲れを感じられなくしてしまうだけで、カフェインで元気になった気になっても、後でツケを払うハメになるので、トータルのパフォーマンスとしては無意味で、疲れが分からなくなる分、危険でさえあります。

あと栄養ドリンクとかも無意味だそうです。栄養ドリンクは栄養失調の人に効果があるもので、健常者が飲んでも意味無いようです。

そんな中、ひとつだけ、ガチで疲労軽減の効果を示した物質がありました。

それが、イミダゾールペプチドです。

イミダゾールペプチドのパワー

イミダゾールペプチドは、鶏むね肉とかに豊富に含まれている抗酸化物質です。

このイミダゾールペプチドが他と違って凄い所は、脳にピンポイントで作用する事です。

脳内の活性酸素を確実に除去してくれるので、疲労にバリバリ効くという事です。

実験結果のグラフを見ても、被験者の疲労感も２割くらい軽減されてますし、尿中の疲労マーカーも２割くらい減ってました。

もしも疲労が２割軽減できて、自分が日々発揮できるパフォーマンスが２割増えたら…どうですか？

これは神的にありがたい事だと思います。

イミダゾールペプチドの発見の功績はどれだけ言っても足りないくらいです。

だって、今まではせいぜい、疲れにはウナギを食べると効く～とか、ほとんど迷信みたいなレベルの話しかできてませんでした。

それが一気に、唯一科学的にエビデンスを持った疲労軽減の方法がでてきたわけです。

イミダゾールペプチドを摂取するだけ！それだけで確実に疲労を軽減できます。

こんなうまい話があるなら、注目せざるを得ません。

ちなみに、イミダゾールペプチドが持ってるのは、あくまで疲労を軽減する効果です。
脳を酷使すると発生する活性酸素を消去してくれるので、活性酸素が神経を傷つけるのを阻止してくれます。

すでに神経が傷ついて、疲れてしまった状態から回復するには、あくまで睡眠しかありません。

よくtwitterで、ゲームで言うＨＰ（ヒットポイント）の例え話が出ますが、歳を食うと、寝てもＨＰの回復量が落ちるとよく言われますね。

イミダゾールペプチドは、防御力を上げてＨＰのダメージを抑える感じになると思います。

疲労の軽減でパフォーマンスアップ

もしもイミダゾールペプチドの摂取で疲労が２割軽減されて、自分が仕事や趣味に発揮できるパフォーマンスが２割向上したら、どうですか？

２割なんて大したことない。と思いますか？

例えば現在一日に発揮できるパフォーマンスを100ポイントとしましょう。

しかし、この全てが仕事や趣味に使えるわけではありませんよね。

自炊する時間とか、ご飯を食べる時間、お風呂に入る時間、トイレに行く時間とかがありますから、そういう固定で消費されるパフォーマンスが毎日40ポイントあるとしましょう。

そして、仕事に使うパフォーマンスも40ポイントで、趣味のパフォーマンスが20ポイントとしましょうか。

そんな状態だったのが、イミダゾールペプチドの摂取する事で使えるパフォーマンス総量が２割増えて、100→120ポイントに増えたとします。

そしたら趣味に使えるパフォーマンスが20→40で２倍に増えました！

２倍ですよ！この差は大きくないですか？

雑な計算でしたが、ちょっとした総パフォーマンスの向上が、大きな結果の違いを生む可能性があるという事が言いたかったのです。

「身体が資本」とはよく言われますが、結局のところ自分自身が発揮できるパフォーマンスを増やすことが、人生で大きな結果を得るために一番手っ取り早い方法です。

１日が30時間あればいいのに…なんて思ったことがある人もいるかもしれませんが、パフォーマンスを上げるというのは要するに実質そういう事を可能にする事です。

鶏むね肉を毎日100g食べる？

さて、イミダゾールペプチドによる疲労軽減効果を発揮するには、１日200mgの摂取が必要だそうです。

これは、鶏むね肉で22gに相当します。

しかし、吸収率の問題を考えると、１日100gの鶏むね肉を摂取した方がいいそうです。100gの鶏むね肉にイミダペプチド1200mgが含有されてます。

鶏むね肉じゃなくて鶏もも肉で同じ量のイミダペプチドを摂取しようとすると、300gのもも肉を食べるハメになります。

豚ロース肉なら130gです。豚もも肉なら150g。

私はこの本を読んで、「早速むね肉を食べてみよう！」と思い立ちました。

鶏むね肉はイミダペプチドもタンパク質も摂れて一石二鳥

鶏むね肉には、100gあたり20gのタンパク質が含まれてます。

皮を含めると結構脂質が多いですが、皮を取り外すとほとんどタンパク質の塊みたいな食べ物になります。（私はもったいないので皮も一緒に食べてます）

あまりにもタンパク質摂取の効率が良いため、筋トレしてるアスリートなんかも鶏むね肉を常食してたりします。

しかも、毎日普通に食べるとしんどくなってくるから、茹でた鶏むね肉をミキサーにかけて、ジュースにしちゃってゴクゴク飲んじゃう人もいるらしく、Youtubeとかに動画が上がってます。

まあ鶏むね肉ってパサパサしてて、それくらいしないと毎日は食べにくいって事ですね。

ちなみに鶏むね肉を茹でてしまうと、イミダペプチドが半分以上、お湯の方に流出してしまうらしく、むしろお湯の方のエキスを飲まないと勿体ないです。

まあ私はそもそも筋トレアスリートとかでは無いですが、普通の人でも、例えば体重が60kgなら１日当たり48gのタンパク質が必要になります。

結構意識してタンパク質を摂らないと、地味に毎日達成が難しい量です。

私は朝にパン１枚、昼と夜にご飯を一杯ずつ食べたりしますが、これでタンパク質12gほどです。

納豆を毎日１パック食べてるので、これがタンパク質9gです。

それから仮に卵を２個食べるとすると、それで13g。

ここまでで合計34gしかありません。これだけだとタンパク質欠乏人間になってしまいます。

しかし、これに加えて鶏むね肉を毎日100g食べれば、１日の摂取タンパク質は54gに達して、必要な量を安定して確保できます。

そういえばこの記事では色々と基本をすっ飛ばしてますが、タンパク質の確保は基本中の基本なので、イミダペプチド以前にタンパク質をちゃんと摂れてない人はそっちをまず優先してください。

タンパク質が不足すると、肉体的にも精神的にもネガティブな影響が出ます。

簡単に言うと、タンパク質が足りないと不幸な気分になるらしいです。足りてるとハッピーになります。

だから筋トレアスリートの人達ってあんまネガティブなメンタルしてなさそうですよね。

まあとにかく、鶏むね肉を食べるとタンパク質もイミダペプチドも両方摂取出来て一石二鳥で嬉しいという事です。

実際に食べてみた

「むね肉が食べにくいって言っても、言うほどじゃ無いんじゃないの？」

ためしにスーパーでむね肉を１枚買ってきて、フライパンで焼いて食べてみました。

「うーわ、パッサパサでおいしくない…」

むね肉ってこんなに…食べにくいんですね。
一度きりならともかく、これから毎日これを食べろと言われても、無理です。

塩と砂糖を溶かした水に肉を一晩漬けると肉が柔らかくなるという、ブライニングというテクニックも試してみました。
たしかに肉が柔らかくジューシーになりましたが、肉に塩がしみ込んでしょっぱくなりすぎて無理でした。

色々と試行錯誤した結果、フードプロセッサーにかけてミンチ肉にすれば、パサパサ感がかなり軽減されて食べやすくなることがわかりました。

さらに、ミンチにする際に舞茸を混ぜると、舞茸の強力過ぎるタンパク質分解酵素が肉を溶かす勢いでやわらか～くしてくれます。
（この方法は、当たり前ですが肉が思いっ切り舞茸風味になっちゃいます。私は舞茸が好きなので全然ＯＫですが、苦手な人は使えない方法です）

別に鶏むね肉のひき肉ならスーパーに売ってるでしょ？と思うかもしれませんが、少なくともウチの近所ではあんまりむね肉のひき肉売ってないんですよね。あと割高だったりします。

ハナマサなら国産鶏むね肉の2kgの巨大なパックが800円くらいで安定的に売ってます。他のスーパーでも大体売ってます。
100gあたり40円なので、肉としてはかなり安い部類です。

ともかく、こういった工夫のおかげで毎日むね肉を100g食べられる目途が付きました。

現在の鶏むね肉摂取事情

上述した通り、鶏むね肉は、茹でるとイミダペプチドがお湯の方に流出してしまいます。ですから、スープにして茹で汁も飲んじゃう形が一番オススメされています。

というわけで、私は鶏むね肉のスープを作って、おかずという扱いで昼食に食べています。

しかし、毎日このスープを食べてると、流石に飽きてくるので、今はむね肉でパスタを作ったり、チャーハンを作ったりする日を混ぜて、ローテーションを組んでます。

スープ→パスタ→スープ→チャーハン→スープ→パスタ　みたいな感じです。

ハナマサとかで鶏むね肉の2kgを買ってきたら、まずこれを全部フードプロセッサーにかけてミンチにしちゃいます。

それから、1100gのむね肉で11食分のスープを一気に作ってしまい、ジップロックみたいな袋に一食ずつ小分けにして冷凍保存します。

食べる時は冷凍した袋を電子レンジで半解凍して、皿に乗せ換えて、もう一度レンチンすれば簡単に美味しく食べられます。

ジップロックは結構高いので、使い捨てがもったいなくて洗って再利用してましたが、段々面倒くさくなってきて、今は使い捨てにしてます。オーケーで売ってるこのフリーザーバッグだと一袋4円程度なので、安いので許容してます。

残りの900gの胸肉は、100gずつ小分けにしてラップに包んで冷凍してます。

チャーハンとかパスタを作る時はレンジで解凍して使います。

20日ごとに鶏むね肉2kgを買って、この作業をやってます。

何だか面倒くさそうに聞こえるかもですが、たしかにフードプロセッサで2kgのむね肉をミンチにして、スープを作る作業は結構時間かかって大変です。
しかし、一気に11食分の昼食が作れてしまいますから、実は毎回昼ご飯を作る手間が省けてむしろラクです。

実際の効果のほどは？

さて、私はかれこれ１年半くらい、ほぼ毎日鶏むね肉を食べてる生活をしてます。

実際どれくらい疲労軽減、パフォーマンスの向上の効果があったのか？

実は、自分では効果の実感は特にありません。

強いて言えばジムで筋トレ後のしんどさが減ってるような…。

あと、何日かむね肉を抜くと一気に疲れやすくなるような気がたしかにしますね。

まあ、実際に効いてるかどうかを実感する必要はありません。

何しろエビデンスが付いてるんだから、確実に効果が出てるわけですからね。

サプリで摂取と言う手も？

私は毎日鶏むね肉食べてますが、一人暮らしだから好き勝手な物が食えてるわけで、家族と暮らしてる人は、難しいかもしれませんね。

それに、毎日鶏むね肉を食べるという事は、人生の中で他にもっと色々美味しい物を食べるチャンスがあったのを、みすみす投げ捨てているという見方もできます。
まあ私の場合は、むね肉よりもっと美味しい物を食べるアテと言われても特に無いんですが。

クソ真面目に毎日鶏むね肉を食べなくても、イミダゾールペプチドをサプリで手軽に摂取するという手もあります。

例えば、DHCのイミダペプチドのサプリは、１日分で225mgのイミダペプチドが摂取できます。30日分で2,500円くらいでAmazonで売ってます。
１日あたり100円弱です…これを高いとみるか安いとみるかは人それぞれでしょう。
私も試しに飲んでみてます。

「えっ？鶏むね肉食ってるのに何でサプリも飲んでんの？」と思われるかもしれませんが、実は今、鶏むね肉にプラスして追いサプリもやってます。

イミダペプチドは過剰に摂取する分には特に問題ないみたいな実験結果も出てた気がします。

まあ、筋トレアスリートの人には毎日大量のむね肉を食べてる人もいますから、彼らに問題が起きてないなら差し当たって大丈夫だろうと考えました。

「サプリじゃなくて毎日食う鶏むね肉200gに増やせばいーじゃん！」と思われるかもしれませんが、無理なく毎日むね肉を食べるのは１日100gが限界に近いです。

第一、毎日200gもむね肉を食べてたら、プリン体の摂り過ぎで痛風のリスクがでてくる領域に突入します。

かと言ってサプリだけだとタンパク質が摂れないし、まあむね肉とサプリの組み合わせが無難かなって感じですね。

そういえば、イミダペプチドのサプリって、大体一日分で200mgのイミダペプチドが含有されてます。

たしかに１日に必要な摂取量は200mgなのですが、吸収率を考えると1200mgくらい食べなきゃいけないんじゃなかったでしたっけ？

ググってもこの点を指摘してる人は誰もいません。

もしかしてサプリ会社に騙されてるかも…？

リスクについて

毎日鶏むね肉食べるなんてのは、ちょっと偏った食生活になりますし、本当に安全かどうかは私も保証しかねます。

ちょっと自分自身で人体実験してるようなもんです。

エビデンス的には、イミダペプチドは「まあ概ね安全そう」みたいな感じですが、実際に長期的に毎日摂取した実験とかは行われてないみたいですし、確実に安全かは何とも言えません。

抗酸化作用はたしかに素晴らしいものですが、必ずしもメリットだけかどうかは分からないもんです。

例えばビタミンＥにも抗酸化作用がありますが、ビタミンＥを過剰摂取すると骨粗鬆症になるリスクがある事が分かってます。

まあ、イミダペプチドは注目され始めたばかりなので、これから色々な実験が行われて色々なエビデンスが増えてくるはずです。

常に最新のエビデンスの動向を確認しておいた方がいいでしょう。

ちなみに先ほども書きましたが、鶏むね肉は結構プリン体が多い食べ物です。鶏むね肉100gあたり、141mgのプリン体が含まれてます。

鶏ささみは154mg、鶏モモ肉は123mgです。

豚ロースは91mg、牛ロースは90mgです。

レバーはプリン体的には危険な食べ物で、鶏レバーが250mg、牛レバーが176mg、豚レバーが228mgです。

１日当たりのプリン体摂取量は、400mg以下に抑えろと言われています。

１日３食ご飯を食べると、それだけで100mgのプリン体を摂取してしまいます。
さらに私は納豆も食べるので、50mgのプリン体が追加されます。そこに鶏むね肉の141mgが足されると、それだけで291mgもプリン体を取ってしまい、残り109mgでやり繰りするハメになります。

若干厳しいですね。

卵や牛乳はプリン体がゼロなので、プリン体フリーでたんぱく質を稼ぎたい時には便利です。

もしこの記事を見て、毎日鶏むね肉食おうと思った方は、健康診断などの際に、尿酸値が上がりすぎてないかチェックしてください。

よくお酒を飲んだり、サウナによく行って脱水気味になりがちな人は、血中尿酸値が高まりがちなので、より注意する必要があります。

痛風になってしまったら、パフォーマンス向上もへったくれもありません。

尿酸値を上げないようにするには、水分を摂りまくって尿として排出しまくると良いです。

毎日水分を摂りまくるというのも基本中の基本テクです。１日２リットルは取るといいと私も医者に言われたことがあり、それからはなるべく水分を摂るようにしてます。

家では手元に１リットルの給水ボトルを置いて、ペットボトルのウーロン茶とかを水で割って飲んでます。

まとめ

毎日イミダペプチドを摂取すると疲労が軽減されてパフォーマンスが向上するという話をしました。

私はイミダペプチドを摂るために、毎日100gの鶏むね肉を食べてる話もしました。

さらにサプリで追いイミダペプチドをしているという話もしました。

この記事を書くために色々とデータを洗ってて初めて気付きましたが、別に鶏むね肉じゃなくても豚肉にも十分イミダペプチドが沢山含まれてますね。（↓こちらの記事を参照）

ハッキリ言って豚肉なら普通に美味しいので鶏むね肉よりよっぽど食べやすいですよ。

しかも、豚肉の方がプリン体の含有量も大分少ないですからね。

これからは、豚肉もローテーションに組み込もうかなと思いました。

サプリのイミダペプチドが含有量200mgでいいんだっけ問題については、私は素人なのでよく分かりません。
まあサプリじゃなくて肉で摂る方が無難な気がしますね。

あと、今回の記事の内容について、梶本さんの本を読んだのは結構前なので、若干うろ覚えな部分もあるかもしれません。
間違った記載などあったらすみません。

オマケ１　鶏むね肉のスープのレシピ

いつも作ってる鶏むね肉スープのレシピを書きます。

何しろいつも食ってるので、微妙に改良を加え続けていますが、とりあえず現在のレシピという事で。

材料（１１食分）

鶏むね肉のミンチ　1.1kg
トマトのホール缶　１缶
水　250cc
日本酒　50cc
コンソメ　３個
おろしにんにく　好きなだけ（大さじ４）
しょうがチューブ　好きなだけ（大さじ１くらい？）
一味唐辛子　ぼちぼち
すりおろしゴマ　ぼちぼち
魚粉（けずり粉）　ぼちぼち
タイムの粉　ぼちぼち
野菜くず　ありったけ
玉ねぎ　２個
キャベツ　1/6個くらい
しいたけ　１個
人参　1/2本くらい
ピーマン　１個
ネギの青いところ　１本分
もやし　３袋（750g）

作る前に

基本的に、材料を全部フードプロセッサで粉々にして煮込むだけです。

肉が100gも入ってるスープって、肉が多すぎて結構エグい感じになります。

ですから材料は、ほとんどが肉の臭みを抑えるためのものです。玉ねぎ、人参、ネギ、ゴマ、タイム、にんにく、しょうがなどですね。

残りのキャベツ、しいたけ、ピーマンとかはいつも冷蔵庫に常備してるから何となく入れてるだけです。

もやし３袋というのは、なるべく低コストで野菜のカサを増して、肉のくどさを抑えようという事です。

野菜くずというのは、このスープはどうせ全部材料を粉々にするんだから、野菜の捨てる所かも全部これに入れちゃえという事です。
具体的にはいつもは大根の葉と皮、人参の皮、キャベツの芯、ピーマンの種やら、大体この辺を冷凍して取っておいてスープに使います。
とにかく低コストで野菜のカサを増したい感じです。

私は家にデカい圧力鍋があるので、これで作ってますが、まあ圧力鍋じゃなくても普通の鍋でも煮込めるなら何でもいいと思います。
ただし、かなりデカい鍋じゃないと一度に１１食分は作れません。

毎日食べるという事を考えて、塩分は控えめにしてますが、お好みで味を調整してください。

レシピ

①圧力鍋にむね肉を全部入れます。

②トマト缶、野菜くず、玉ねぎ、キャベツ、しいたけ、人参、ピーマン、ネギを全部フードプロセッサで粉々にして鍋に入れます。

③コンソメ、にんにく、しょうが、一味唐辛子、すりおろしゴマ、魚粉、タイムを入れます。

④日本酒と水を入れます。

⑤もやしを３袋入れます。もやしはフードプロセッサにはかけません。鍋に入りきらなかったら後から入れて煮込んでも構いません。

⑥火にかけて、圧力鍋で30分くらい圧力をかけます。

⑦蓋を開けたら、多分むね肉が塊になっちゃってると思うので、むね肉を取り出してもう一回フードプロセッサにかけて、粉々にしてから鍋に戻します。

⑧ちょっとだけ煮込んで完成。

⑨食べる時はお皿に盛って、私はフライドオニオンとあらびきコショウをかけて食べてます。

オマケ２　むね肉のパスタのレシピ

材料（１食分）

むね肉のミンチ 100g
パスタ　150g
にんにく　３片（お好みで）
キャベツ　100gくらい
しいたけ　１個
オリーブオイル　ちょっと
シーフードミックス（あれば）　ちょっと
もやし（あれば）　50gくらい
豆苗（あれば）　ぼちぼち
一味唐辛子
魚粉（けずり粉）
粉末コンソメ

レシピ

①レンチンでパスタが茹でられるヤツでパスタを茹でます

②茹でてる間に、ニンニクをスライスしてフライパンにオリーブオイルを入れてニンニクを炒めます。

③ニンニクがぼちぼち炒まったら、スライスしたしいたけとむね肉を入れて炒めます。むね肉はバラけるようにします。

④シーフードミックス、キャベツ、もやしも炒めます。一味唐辛子も入れます。粉末コンソメもちょっと入れます。

⑤パスタが茹で終わったらフライパンに入れます。塩コショウを振ります。魚粉も入れます。

⑥豆苗があればハサミで刻んで入れます。

オマケ３　むね肉のチャーハンのレシピ

材料（１食分）

むね肉のミンチ　100g
ご飯　軽く１杯分
玉ねぎ 1/2個
ピーマン　１個
人参　ちょっと
しいたけ　１個
卵　１個
もやし（あれば）　50gくらい
（黒酢あんの材料）
黒酢　小さじ１
砂糖　小さじ１
片栗粉　ちょっと
ウェイパーか創味シャンタン　ちょっと
しょうゆ　ちょっと
水　150cc

レシピ

①フライパンに油を引いて、火にかけて、卵を割り入れる。
卵をかき混ぜて、バラけたスクランブルエッグみたくする。

②ピーマン、人参、しいたけ、玉ねぎをみじん切りにして入れる。

③炒まってきたら、むね肉を入れて、バラけるようにほぐす。

④ご飯を投入して、水を30ccくらい加え、マヨネーズをちょっと、塩コショウを入れる。

⑤あればモヤシも入れる。ネギを入れるのもアリ。最後にゴマ油をちょっとだけ入れて、香りをつけてどんぶりとか皿に盛る。

⑥引き続きフライパンで黒酢あんを作る。
黒酢あんの材料を全部フライパンに入れて火をかけて、ふつふつしてとろみが出てきたらチャーハンに黒酢あんをかけて完成。

はじめに

今回は、タイトルの通り、データを見ながら漫画家という商売について考えてみる記事です。

漫画家になりたい人向け？の記事になると思います。

が、あらかじめ断っておきますが、私自身は漫画家でもないですし、一切漫画ビジネスとの関わりはありません。

つまり、部外者が推測で適当な事を書いてしまうという面が少なからずあるでしょう。
そういうのはけしからんという意見もあるかもしれません。

しかし、それならば実際の漫画編集担当の人が、専門的見地から、こういう情報を出してくれてもいいハズなのに、実際には私はこの記事で書くような内容の情報をあんまり見かけません。

結局、本業で漫画編集をやっているような方は、守秘義務との兼ね合いなどもありますから、迂闊にこういう話は書けないという事かもしれません。

であれば、私のような門外漢が推測交じりで書くような記事でも、何も無いよりはマシだろうと思い、書いてみる事にしました。
つまり、実情を何にも知らない部外者だからこそ書ける話もあるだろうという事です。

そのようなスタンスで書かれた記事であるという事を、初めにご了承ください。

子供の頃の私の将来の夢としての漫画家

子供の頃、将来は漫画家になりたいという夢を持っていた人は結構多いのではないでしょうか。

私が子供の頃（1990年～2000年くらい）は、暇つぶしと言ったらテレビを観るか、ゲームで遊ぶか、漫画を読むかくらいしかありませんでした。
基本的にヒマな時は書店とかゲオとかブックオフに入り浸ってひたすら立ち読みしていた記憶があります。（なにしろまだネットが無かった時代でした）

高校生になってパソコンを入手する前は、自分でゲームを作るなんて選択肢は想像ができませんでしたし、ラクガキくらいなら自分でもやってましたから、子供の私も漠然と「漫画家になりたいなあ」と憧れていたように思います。

大抵の人は、大人になるにつれて、子供じみた夢を捨ててしまうタイミングがあると思いますが、私は社会人になってからも微妙に夢がくすぶってました。
それで、試しにオリジナルのマンガを描いてコミティアに出展してみたりした事もあります。
そこで出張編集部に持ち込みしてみたら、色々とダメ出しを受けて、なんとなく挫けてフェードアウトしてしまい、色々と流れに身を任せてる内に、今ではUnityエンジニアをやっているという事になります。

高校球児とかは青春を野球にぶつけて、甲子園出場で完全燃焼して、そうしたら憑き物が取れたかのようにサッパリと夢を諦めて社会人になるという流れがあります。
が、私の場合は何となくやってみて、何となく挫折したという中途半端さゆえに、なんとなく心の片隅で漫画家の夢がくすぶっているようなそうでもないような気がしています。

「夢は呪いだ」みたいな台詞を何かの漫画で読んだ気がします。

ビジネスマンの考え方と漫画家の考え方

今の仕事をやっていると、当然ですが色々な人と関わります。

漫画家と同じようにクリエイター目線で仕事をしている人もいますし、漫画編集者のようにビジネス目線で経営を考えている人もいます。

面白いな～と思うのは、ビジネス目線でモノを考える人は、”数字がメッチャ好き”という特徴があります。

例えばビジネスで新規事業を起こすとします。例なので何でもいいですが、新しく掃除機の製造・販売業を始めるとしましょうか。
そうしますと、真っ先に調べるのは掃除機の市場規模がナンボか？という数字です。日本の掃除機の市場規模が年間100億円だとしたら、どれだけ頑張ってシェア100%取っても年間の売り上げは100億円が天井になると分かります。
それから、競合他社の掃除機のスペックや売り上げを調査します。
まあそうやって、あれやこれや色々な数字を検討すると、新規事業を始める前から大体の売り上げ見込みが立てられるので、儲かりそうかどうか分かります。

ビジネスは数字、データが基本という事ですね。
だからビジネスマンは数字が好きです。

ちなみにスタートアップとかだとそもそもまだ市場が存在してないビジネスをやろうとしたりしますが、その場合も、自分たちのプロダクトの”潜在的な”ニーズはどれくらいだろう？みたいな感じでターゲットになりうるお客の数を計算したりします。取らぬ狸の皮算用かもしれませんが、ある程度当てずっぽうでも数字を出していかないと事業計画を建てて話を進める事ができません。

↑このツイートのなるがみさんは先日、個人で興したSkebの事業を10億円で譲渡されています。

ところで、商品に使うイラストを誰に描いてもらおうか？みたいな話を検討する時に、イラストレーターのtwitterフォロワー数とかが問題にされがちらしいです。
「Ａさんはフォロワー数が１万しかいないから、フォロワー数３万のＢさんに頼んだ方がいいんじゃないの？」みたいな。

私はこういうフォロワー数で判断しちゃうのってどうかと思いますが。
と言うのも、フォロワー数は一律で数字だけ出てきますが、どういう文脈で獲得したフォロワーなのかは分かりません。Ｂさんはフォロワー数は３万ですが、そのほとんどはイラストのファンというよりＢさんのオモシロ発言に惹かれてフォローしたのかもしれません。
極端な話だと、例えば前澤さんはお金を配る事でフォロワーを獲得しています。

それに、ぶっちゃけフォロワー数は操作できます。フォロワー数を増やす業者がいるので、そこにお金を払って依頼すればフォロワーは何万でも増やせます。同様にRT数やライク数も操作できるでしょう。

まあ、イラストの実力を見たいなら、少なくともtwitterのフォロワー数よりはpixivのフォロワー数を見た方がマシだと思います。twitterは色んな文脈でフォローされますが、pixivはイラストサイトなのでフォロワーも確実にイラストが気に入ったという理由でフォローしてくれてるはずだからです。

話を戻しますが、ビジネスマンは数字が大好きですから、イラストレーターを選ぶ時もフォロワー数という数字を気にするという話でした。
会社のお金を使ってイラストを依頼する事になりますから、単に自分の好みのイラストレーターさんに依頼するって訳には行きません。上司に「何でこの人にしたの？」と訊かれた時に、何か根拠を示す必要があるわけで、ついつい分かりやすい数字としてフォロワー数を持ち出してしまうという構造があります。

twitterでたまに”担当編集から「最低でもフォロワー１万はいないと話になんないよ」って言われた！”みたいな話題が上がってたりします。

まあ出版社もビジネスで漫画を出版してるので、漫画の担当編集もビジネスマンですから、つまり数字が大好きなわけで、やっぱりフォロワー数とかを持ち出したくなるわけです。

こういう話を聞くと、「担当編集なんかに何が分かるってんだ？数字なんかクソくらえだ！」と、むしろ数字を否定してしまう気分になる人もいるかもしれません。

漫画やイラストというのはクリエイティブな仕事ですから、なんでも数字ありきのビジネスマン的な考え方とは相容れないと思われるかもしれません。

仮に先ほどの掃除機ビジネスの考え方を漫画に適用してみると、漫画で今一番売れてるのは鬼滅ですから、そこに市場があるわけで、鬼滅をパクれ！と言う話にしかならない気がします。
ビジネスというのは基本的にすでに売れてて市場が立ち上がってるものの再現を狙いますから、ビジネスの考え方をクリエイティブな事業に持ち込んでも、何をパクるかという話しかできず、全然クリエイティブな事ができなくなります。
あれをパクれ！これをパクれ！と言われても漫画家としては自分の描きたいものがあるから漫画になったわけで、うっせえわ！って感じでしょう。

さて、困った事に、筆が滑って私が書きたかった結論とは真逆の方向に話が進みつつありますが、私が言いたいのは、「それはそれとして漫画家側も数字について考えてみるとおもろいかもよ？」という話です。

私がそのようなアイデアを抱いたきっかけは、例によってヒロユキ先生の「マンガで分かる　本気で売れるためのヒロユキ流マンガ術」です。

この本のコラムでヒロユキ先生は、「漫画家になりたい人の多くは全然漫画を読んでない。もっと漫画を読んで！ジャンプだけ読んでるとかじゃ足りない。単刊５万部以上売れてる漫画は全部読んで。それくらい売れてる漫画は明確な売りや魅力を持ってるから、そういう漫画を一杯読めば自分のマンガと比べてどうか？みたいな判断力が付いてくるよ。僕は漫画を読んだらその漫画の売り上げを調べるよ」みたいな話をされてます。

これを読んで、なるほど！早速実践してみよう！と思った私は漫画の出版部数のデータを調べてみる事にしました。

漫画の部数データはどこにある？

私は、書籍の売り上げデータとか出版部数データはどっかにまとまっていて、ググればすぐ分かるものだと思い込んでいました。

しかし、ちょっとググっただけでは中々情報が出てこない事に気付きました。

鬼滅が1億5千万部出た！みたいな、超メジャー漫画についてはむしろ積極的に宣伝されていますが、もう少しマイナーな漫画とかだと出てきません。

どうやら、基本的に出版社は漫画の部数を公表してないようです。

これは意外な事実でした。
アニメなんかだと、各作品ごとにブルーレイの売り上げデータがまとめられて、５ちゃんとかでワイワイ盛り上がってる印象があるのに。

漫画の出版部数は作者のプライバシーに関わるという話みたいです。
部数を公開してしまうと、部外者が部数で作者を格付けして優劣を付けたりし始める可能性があって、迷惑だからとの事。

たしかに、ブルーレイ売り上げ論争で、売り上げ枚数という分かりやすい数字に飛び付いて優劣を競い合っているのは醜く見えるかもしれません。

そもそもですが、そういうブルーレイの売り上げデータはどこから取ってきているのでしょうか？調べたところ、ソースはオリコンだそうです。

https://www.oricon.co.jp/rank/

↑というわけでこちらがオリコンのサイトですが、たしかにアニメDVDや漫画のデイリー、週間、月間のランキングが見れます。

しかし、ランキングは見れますが、具体的な売り上げ数は書いてませんね？
さらに調べたところ、You大樹というサイトで有料会員登録すると、オリコンサイトよりもっと詳しいデータが見れるとの事。

https://ranking.oricon.co.jp/

ためしに会員登録してみました。
たしかに、ＣＤやＤＶＤ、漫画の売り上げ推定データが具体的に表示されます！５ちゃんのブルーレイ売り上げ情報のソースはこれでしょうね。

ちなみにオリコンの仕組みは、色々なショップに協力してもらって、それぞれのお店の売り上げを集計しているそうです。なので、例え出版社が部数を公開してなくても、何冊売上げたかが大体分かってしまいます。

それはいいのですが、私はYou大樹で網羅的な漫画の売り上げデータが見れる（例えば作品名で検索したらその作品の売り上げ数が分かるとか）かと思ったのですが、実は週間Top50（過去6週分）、月間Top20（過去6カ月分）、年間Top30（2009年以降）のデータしか見れません。

最近のTop50なんて、ほとんどがワンピース、鬼滅、呪術廻戦で埋め尽くされてるので、ほとんど役に立ちません。

もっと網羅的なデータが見れるサイトは無いのでしょうか？

例えば、紀伊国屋書店は、POSデータの売り上げが網羅的に調べられる「PubLine」というサイトを用意しています。
しかし、これを利用できるのは出版社だけで、一般人は使えないとの事。さらに、月額料金10万円もするそうです。

月額10万…書籍の売り上げデータって、そんなにお金を払う価値がある感じなんですね。
しかし、漫画の出版部数のデータも売り上げのデータも一般人からはアクセスできないとなると、手詰まりですね。

ヒロユキ先生は、「単刊５万部以上出てる漫画は読んでみよう」と仰ってましたが、そもそもどの漫画がどれくらい出ているかなんて分からないんじゃないですか。漫画家だけの情報網みたいなものがあるんでしょうか？

データが手に入らないんじゃしょうがない…諦めかけたその時、こんなサイトを見つけました。

https://book-rank.net/index.cgi

「書籍ランキングデータベース」というサイトです。

なんと、2014年～2019年の各年の漫画年間ランキングTOP500とそれぞれの売り上げが見れます！
おかげで、You大樹より過去の、幅広い漫画の売り上げデータを手に入れる事が出来ます！
このデータのソースは何だろう？というと、どうやら毎週のYou大樹の週間ランキングの部数を集計して公開してくれてるみたいです。
これはありがたい！

さらにググってると、別のデータも発見しました。

https://kannbunn.github.io/MangaSales/

このページでは、2016年までの全て？の漫画について、単刊ベースでランキングされているようで、なんと1645位まで見れます。
ただ、このデータはちょっと出所が分からない感じがあります。今まで紹介したサイトはPOSデータからの売り上げベースでしたが、このデータは出版社が公開してないはずの出版部数ベースです。

しかし、これだけのデータを捏造するのも大変ですから、まあ参考にするだけしてしまっていいのかもしれません。
大抵の有名漫画は載ってますね。このデータのおかげで過去の人気漫画の部数が分かるようになりました。

さらにまた別のサイトも見つけました。

http://shosekiranking.blog.fc2.com/

「漫画・マンガ・コミック 売上ランキングBEST500」というブログサイトです。
このサイトではなんと、毎日の漫画売り上げTOP500位までが掲載されてます。さらに週間、月間、年間ランキングも見れますし、週間、月間、年間については、それぞれの作品毎ではないものの、100位、200位などの区切りで売り上げ推定数が掲載されてますので、各作品のおおよその売り上げは見当が付きます。過去のデータは2013年くらいまで遡れます。
このサイトのデータも出所がちょっと分かりませんが、サイトの説明によれば、色々な書店の売り上げデータを集計したものらしいです。
この非常に充実したデータのおかげで、結構マイナーな漫画でもバッチリ売り上げが推測できるようになりました。

ちなみに、このサイトのデータは、Amazonとかの売り上げが含まれてない事に注意してください。
また、電子書籍の売り上げも含まれてません。
そうなると、データと実際の売り上げは食い違ってくるという事です。

実のところ、今は電子書籍の売り上げは紙の漫画とほぼ同じ、むしろやや上回ってさえいます。

2019年 ついに紙コミックと電子コミックの販売金額が逆転！出版月報（2月号）より

という事は、平均的に言って、電子書籍分を含めると、POSデータが示す紙の売り上げの２倍くらい売れてそう、という事になるでしょう。

もちろん、作品によって紙と電子の売れ行きの配分は異なるでしょう。
例えば、こちらの記事ではヒロユキ先生の場合は電子よりも紙で売れるジャンルだそうで、紙が１０売れた時に電子が５売れるくらいの割合だそうです。

「今のマンガ家って売れても儲からないんですか？」　『アホガール』のヒロユキ先生に聞く、マンガの現状

また、POSデータにAmazonの売り上げデータが含まれないので、マイナーな漫画は売り上げ推定値が実態と乖離する可能性があります。
何故か？

漫画の売上ランキングだけどコミック専門店やネット書店と電子書籍の売上は含まれない話

↑こちらのまとめで言及されてますが、どうやら書店の方でもPOSの売り上げデータを参考にしているようです。そうすると何が起こるかと言うと、書店は売れそうな本ばっかり仕入れてマイナーな漫画を入荷しないという状態になっていきます。

私は漫画の発売日に、今すぐ読みたかったので近所の書店を回ってみたものの、どこにも売ってなくて結局Amazonでポチった経験が何度もあります。
書店がマイナー漫画を仕入れないと、我々はAmazonで紙書籍か電子書籍をポチるしかなくなりますので、それでますますPOSデータ上でのマイナー漫画の売り上げが下がって、ますます書店がマイナー漫画を仕入れなくなるという悪循環が起きている可能性があります。

これが、マイナー漫画についてはPOSデータと実情が乖離しかねない理由です。
ですので、データについて検討する時は、それらの事情を考慮に入れる必要があります。

さて、これまで紹介したサイトのデータを組み合わせる事で、ほとんどの漫画の売り上げデータが分かるようになりましたね。

ビジネスとしての漫画家について考えてみる

データが集まった所で、ここでちょっと漫画家というビジネスについて考えてみたいと思います。

先ほど書いた通り、私は漫画家という夢からやんわりフェードアウトして、漫画と関係ないビジネスについて色々考える時期がありました。

ビジネスと言っても、結構大変なものです。
例えば、スタートアップは未知の市場を開拓しますが、やってみるまで分からなかったけど、実は実際にはそこには市場なんて無かった（お客さんがいなかった）と判明して失敗したりします。
逆に、すでに有望だと分かりきっている市場だと、沢山の競合他社が出現しますから、熾烈な争いに巻き込まれます。

しかも、個人でひっそりやっていくという訳には行きません。スタートアップは短期間で、数十倍、数百倍の勢いでガンガン成長する事が求められます。（起業家がしたくなくても投資家やベンチャーキャピタルからせっつかれます）無茶をするわけですから、色々と疲れます。

そういう風にムチャクチャ頑張って、起業家の資産を一気に数十億、数百億に増やしちゃおうというのがベンチャーなやり方です。ちなみに大抵は失敗します。

正直に言って、そもそも私はそんな数百億の大儲けは求めてません。
ただ、死ぬまで問題なく暮らしていけるつつましい額さえあれば十分です。

では、死ぬまで暮らせる金額っていくらなんだっけ？というと、

まあ３億円も売り上げれば死ぬまで暮らせるでしょう。

３億円売り上げると、所得税などで半分くらい引かれますから、1億5千万円ほどになります。
そこから念のため3千万ほど手元に残し、残りの1億2千万を世界インデックスファンドとかに投資します。
世界の資本主義がマトモに機能している限り、世界経済は成長し続けますから、少なく見積もっても3%くらいの利回りが期待できます。

1億2千万の3%は360万円で、ここから税金が2割引かれて288万円の不労所得が毎年得られる事になります。

年間288万円あれば、まあ一人なら暮らせるんじゃないでしょうか。足りなければ多少なら元本に手を付けても問題ありません。

という訳で、目標は３億円です。
３億円…成功したベンチャーとかの話からするとつつましい金額ですが、とは言え簡単に稼げる金額でもなさそうですね。

ビジネスに目を向けていると、まったく儲からないか、あるいはうんざりするような競争に巻き込まれるかの２択に段々疲れてきました。

そんななか、ふと漫画家について考えてみると、漫画家というビジネスは何か変だなという事に気付きました。

漫画ビジネスと言うのは結構市場規模が大きいですが、あまり熾烈な競争や拡大合戦が起きてないですよね。
だって、漫画家って大抵個人事業でやってますよね。
でも漫画が有望な市場を持ってるんだったら、例えば漫画制作会社みたいなのが現れて、沢山の社員を雇って漫画制作をスケールさせて、既存の個人漫画家を駆逐したりしてもおかしくないじゃないですか。巨大なイオンが地元の商店街の店を駆逐するような感じで。

でも、現実にはそうなってません。
何故なのか考えてみると、そもそも漫画を描けるような人はごくごく一部に限られるからでしょう。
イオンで働ける人はいくらでも集められるでしょうが、漫画を描ける人はそう簡単に集められませんし、例えば人を１００人集めれば鬼滅の漫画の生産スピードが１００倍になるなんてワケありません。

つまり、漫画家業は”スケールしないビジネス”という事です。まあ、アシスタントを雇えば背景とかは描いてもらえますが、基本的に人物は一人の漫画家が全部自分で描かないといけないですし、お話を沢山考えるのも限界があります。
スケールしないからこそ、熾烈な競争が発生しません。いや、熾烈な競争はあるっちゃありますが、ベンチャー企業が巻き込まれるようなビジネス的なムチャクチャな競争までにはなってません。

ここまで考えてみると、個人の力で３億円と言うボチボチの金額を狙うのに、漫画家というのはビジネスとして考えても結構面白いかもしれないなという考えに至りました。

漫画家を夢にしていた頃は「数字なんてクソくらえ」みたいなクリエイター的な気持ちを持っていた気がしますが、一旦フェードアウトして冷めた目線で考え直してみると、ビジネス的な目線で漫画家ビジネスを考えられるようになりました。

担当編集とかから「数字について考えろ！」と言われると、それは反発してしまいそうですが、自主的に考えてみるのはやはり気の持ちようが違ってきます。

さてさて、では早速、漫画で３億円稼ぐというのはどういう話になるのか考えていきましょう。

基本的に、漫画家が得る収入源は、漫画雑誌に掲載した時の原稿料と、単行本が売れた時の印税収入の２つです。

原稿料がいくらか？というと、漫画雑誌の連載だとページ当たり8000円～で、Web連載だと5000円～くらいだそうです。

商業漫画の1ページの原稿料っていくら？

という事は、漫画雑誌で週刊連載16ページを月４回描く場合は、一か月の原稿料は51万2千円～となります。月刊連載40ページなら、32万円です。

しかし、漫画家は自腹でアシスタントさんを雇って原稿を手伝ってもらう必要があります。

漫画家がアシスタントを雇うお金は基本自腹だというお話

週刊連載だとアシスタントの人数は大体3～5人で、大体毎週３～５日勤務だそうです。日給は一人1万円くらいだそうです。

まあ、仮にアシスタント人数が4人で週4日勤務で、一人日給一万円だとすると、一週間で16万円かかります。
１週間の原稿料は16ページ×8000円で12万8千円…。
あれ…この時点で毎週3万2千円の赤字ですね…。

しかもこれに加えて、自分の生活費も必要ですし、アシスタント4人分の机が置ける広い家か事務所の家賃もかかります。アシスタントさんの食事や交通費、寝床も必要になります。

漫画家は原稿料だけだと大赤字になる事が分かりました！

【漫画】『新世界より』コミカライズ担当「描けば描くほど赤字。原稿料上げて」の声届かず…　ほとんどが単行本収入がないと赤字!?

いや、必ずしもそうだとは限りません。ちょっとソースが見つからないのですが、どこかでアシスタント無しで月刊連載されている漫画家さんの話を見た事があります。

アシスタントを雇わずに全部自分で描けば、まあ自分の生活費くらいは稼げそうです。
アシスタント無しで漫画描くとか可能なのか？というと、今はデジタル作画で結構効率化できますし、なんなら背景も素材画像で済ませられる場合もありますから、不可能ではないかもしれません。

まあ、諸々を鑑みて、とりあえず原稿料は諸々の経費に消えてしまうという事にしましょう。

となると、印税収入だけで３億円稼がないと行けないという事になりますね。

さて、漫画家の印税収入は、一般的にコミックスの値段の8～10%と言われてます。そして、コミックスの値段は400～800円くらいですね。

とりあえずここでは1冊辺り50円の印税がもらえるとしましょう。
という事は、3億円稼ぐには、一生の内に600万部の単行本を売る必要があります！

600万部！

どうですか？可能だと思いますか？

ちなみに鬼滅は単行本１巻あたり652万部売れてます。単行本出すたびに３億円の印税が入ってる事になりますね…。

そう考えると600万部ってハードル低いかもと思うかもしれませんが、鬼滅は日本のてっぺん取ってる漫画の話なんで…私には鬼滅は描けません。

現実について話をしますが、今だと下手すると単行本１巻あたり１万部でヒットと言われかねない時代なのが実情のようです。

３万部で大大ヒット、５万部でスーパーヒット、１０万部で超ヒット、それ以上は神の領域？

データを見ていると、大半の漫画は１万部行ってないっぽいです…。
「ウソでしょ！？」と思う方は、先ほど紹介した漫画・マンガ・コミック 売上ランキングBEST500のサイトの週刊漫画ランキングを見てみてください。大体500位で3000部くらいです。これより下の漫画もいっぱいあるハズです。
上位の漫画はそりゃ売れてますが、ほとんどが超メジャーなジャンプ漫画とかです。というかぶっちゃけると鬼滅と呪術廻戦と約束のネバーランド辺りが上位を占めてます。

さて、仮に私が描いた漫画が単刊（単行本あたり）１万部売れるとしましょう。
すると私は一生で単行本600冊描くハメになります！
ちなみに手塚治虫全集が400巻です。

無理に決まってんだろ…。

では、もう少し楽観的な見通しとして、単刊３万部売れるとすれば、一生で200冊描く必要があります。
毎週16ページ描いて単行本200冊にするには、2500週間、50年かかりますね…これでも無理じゃん…。

じゃあ、単刊１０万部売れればどうだ！？
これなら一生で単行本60冊描けば済みます。毎週16ページ描けば15年で終わります。
まあ…かろうじて可能なレベルでしょうか。

つまり、漫画家と言うビジネスは、単刊1万部や3万部では商売として難しく、単刊10万部くらいコンスタントに売り上げを出せればまあなんとか割に合うものになると言えるでしょう。

漫画家ビジネスが成立するのはどういうレベルの漫画？

さて、単刊10万部を目指すとして、単刊10万部ってどれくらいのレベルの漫画を描けば達成できるんでしたっけ？

いざ、データを見ながら検討してみましょうか。

あらかじめ断っておきますが、ここからは実際の漫画の部数に触れていきますが、部数を持ち出して作家や作品の優劣を競うような意図はありません。作品の良さと売り上げには何の関係も無い事は重々承知しておりますし、この記事を読む皆さんにもその辺ご承知おきしていただけるとありがたいです。

先ほども書きましたが、鬼滅は単刊652万部、これは神を超えた界王神レベルです。

ワンピースは単刊490万、ドラゴンボールは単刊619万、NARUTOは単刊347万、スラムダンクは単刊387万部、進撃の巨人は単刊303万部、この辺も伝説の界王神レベルです。

死ぬほど売れた漫画はこの辺にして、普通に売れたレベルの漫画を見てみます。

寄生獣は130万、ケロロ軍曹は45万、魔法陣グルグルは75万、よつばとは119万、ゴールデンカムイ62.5万。ダンジョン飯50万部くらい。この辺も神レベルですね。

まあ、この辺くらいまでの漫画なら、公表されてる部数から簡単に計算できますが、単刊10万部くらいの漫画だとなかなか公表されないので、さきほどのデータサイトとかを見る必要があります。

公表されてない部数についてブログであげつらうのは申し訳ないですが、単刊10万部のイメージを掴むのにどうしても必要なので、ご了承いただきたいところです。

単刊10万部クラスの漫画というと、キルミーベイベー（単刊15万）、のんのんびより（単刊13万）、はたらく細胞BLACK（10万）、ハチワンダイバー、巴マミの平凡な日常、琴浦さん、モブサイコ100、ぼくらの、東方鈴奈庵、超ヒット漫画の数々…。

単刊10万部を目指すには、このレベルの漫画を描かなければならないという事です。
メチャメチャ大変だよ…。

ちなみに単刊３万部や５万部の漫画も列挙しようとしてみましたが、なかなか今あるデータだけではハッキリした数字が分からなくなってくるので諦めました。

あらためて、自分が漫画家としてやっていけそうか考えてみる

さて、どういう漫画がどれくらい売れてるのか、具体的に作品を挙げていった事で大体感じが掴めたでしょうか。
もっと調べたい方はデータサイトを見てください。

では次に、じゃあ自分の漫画ってどれくらい売れそうなんだっけ？というのをシミュレーションしてみましょう。

方法は簡単です。今まで挙げてきた有名作品と、自分が描いた漫画を隣に並べてみて、どっちがいい漫画か脳内でバトルさせてみましょう。

鬼滅の横に自分の漫画を置いてみて、どうですか？勝てませんね。

スラムダンク…ドラゴンボール…ワンピース…勝てませんね。
まあ、この辺は界王神なんで、そもそも勝とうとも思いません。

寄生獣、よつばと、魔法陣グルグル、ゴールデンカムイ、ダンジョン飯…う～ん、面白さでも画力でも勝てる気がしねえ…。
まあ、この辺も神レベルだから…。

キルミーベイベー、のんのんびより、ハチワンダイバー、モブサイコ100…。

この辺になってくると、一部の天才の人なら、「この作品なら私の方が絵が上手いな」とか、「絵は勝てないけど面白さなら勝ってるな」と思える作品が出てくるかもしれません。（失礼な事言ってすいませんが、自分の中でそう思えるかどうかってだけです）

それなら、あなたは単刊10万部を目指せるかもしれないという事です！

「ダメだ…一つも勝てねえ…画力でも勝てないし、面白さでも全敗や…」と言う人もいるかもしれません。（私やぞ）

それでも、諦める必要はありません。己を知る事こそが大事なのです。

画力も面白さも、何も勝てない、何も持っていない自分に気付き、直視する事ができれば、それなら工夫して、戦略を練ろう！という気持ちがきっと生まれるはずです。

生き残るために戦略を練る

自分の身の程を知った事で、「自分には描きたいモノがあるんだから、売れてる漫画をパクるとか嫌だし、数字なんて知ったこっちゃないよ！」なんて甘ったれた考えを捨て去る覚悟ができた方もいるかもしれません。

甘えを捨てて、ガチンコ全力で一冊でも多く売れる漫画を本気で考えないと到達できないのが10万部という数字です。

大抵の人は、10万部売ってる漫画作品に、画力でも面白さでも、何もかも勝てない。自分の武器が無い人がほとんどだと思います。

武器が無いなら無いで、その弱点を補うための戦略を人一倍必死こいて練る必要があります。

まあ、戦略といってもそんなに難しい事ではありません。

要するに売れてる漫画をパクるという事です。

パクると言うと語弊があるかもしれませんが、例えば最近だとメシ漫画が流行ってますよね。もはやジャンルと化してるレベルで沢山のメシ漫画が生まれています。

それから、まんがタイムきららの日常系漫画も、もはや一つのフォーマットと化してます。

で、あれば、例えば日常系メシ漫画を描いたら売れるんじゃね？みたいな話です。

いや、分かります。クリエイター目線で考えると、あまりに浅はかでしょーもないアイデアに見える事でしょう。

まあこれはあくまで例ですし、それに、才能が無いなら無いで売れるためにはそれくらい必死こかないといけないのかもしれないというモノの例えです。

描きたいものがあるなら売れてから自由に描けばいいという考え方もあるかもしれません。

メシ漫画とかって、もちろん描きたくて描いてる人もいるでしょうが、どちらかというとビジネスとして売れないと行けないから流行ってるメシ要素入れたって作品が多いんじゃないでしょうか。
普通にファンタジー要素だけで充分面白い、”ダンジョン飯”でさえ、メシ要素が入ってるわけです。ダンジョン飯みたいな天才でさえそうしてビジネス目線で戦略を練って努力しているというのに、ダンジョン飯に画力も面白さも勝てない凡人はもっとメチャメチャ戦略を練りに練りまくらないと生き残れない事は明白です。

私は完全に実情を知らない人間なので推測ですが、最近は昔よりも、編集部主導で漫画家に売れそうな漫画を描かせる、”企画モノ漫画”とでもいうような漫画が増えているような気がします。

描きたいものを描ききって、次回作のアイデアが浮かばないみたいな漫画家さんに、例えばメシ漫画とか、最近はスピンオフ漫画とか流行ってますが、それとか、コミカライズとかを描かせたりしてる…ような気がします。

また、メチャクチャ天才なんだけど、絵の部分ををもっと一般受けしそうな人に変えたらさらに爆発するかもしれない。あるいは同時連載数を増やしたいけどもう一本漫画描くのは限界があるし、みたいな感じで、漫画家に原作を書かせて、作画担当を付けるというケースもありますね。
たとえば天原先生という天才がいますが、天原先生の「33歳独身女騎士隊長。」は結構ヒットしてるみたいですが、さらに天原先生が原作、masha先生が作画担当した、「異種族レビュアーズ」は単刊15万部の超ヒットでアニメ化もされました。
また、岡本健太郎先生は「狩猟ダイアリー」で単刊10万部の大ヒットを出しましたが、さらに岡本先生が原作、さがら梨々先生が作画担当した、「ソウナンですか？」もやはり単刊10万部の大ヒットで、こちらもアニメ化されました。
搾精研究所さんはDLSiteで搾精病棟をメガヒットさせました。

搾精病棟での作者の利益は5千万円だそうです。すごいですね。DLSiteはたしか作者の取り分が販売額の50%だったと思います。売れた数が同じでも、商業漫画の５倍儲かる事になりますね。
しかし、その分誰でも販売できるので、競争は熾烈になっていると思います。

そんな搾精研究所さんが原作、丈山雄為先生が作画担当で、「淫獄団地」という作品をニコニコ静画で連載してます。
これはまだ単行本が出てませんので部数は分かりませんが、すでにtwitterではこれ実質ライダーじゃん！みたいなネタで大バズりしてますし、下手すると5万部…いや10万部出てしまう可能性も無きにしも非ずです。

ただし、こんな風に原作と作画担当に分かれてしまうと、印税の取り分も山分けになってしまいますね。

ちなみにワンパンマンの場合は編集部主導とかでなくて、村田先生がワンパンマンを描きたくてしょうがなくなって、ONE先生に描かせてくださいとお願いしたみたいな経緯らしいです。（ワンパンマンは単刊100万部です！）

という訳で、編集部主導というか、ビジネス主導な雰囲気のする戦略的な漫画が最近増えてるという話でした。

というのも、近年は出版不況と言われて久しく、実は漫画の平均的な売り上げと言うのは90年代をピークに段々落ちてきているようです。
全体のパイが減っているのに、逆に漫画雑誌はどんどん増えて、漫画の作品数が爆増してるような気がします。

そうなれば、個々の作品の売り上げはガンガン下がる事になりますよね。
最近はみんなが同じものを持て囃すよりも、それぞれの人が自分の好きなものを求める風潮で、嗜好が細分化してるので、漫画も細分化しているという事かもしれません。

出版社だってビジネスとして漫画を出版してるわけですから、出版が不況な現状では危機感を抱いて、もっと漫画家にビジネス主導でコンスタントに売れる漫画を描かせなければ…！と思うのも当然の事です。

ですから今後は、ますますビジネス的に企画された感じの漫画が増える事が予想されます。

これからは、漫画家が自分の描きたいものを好き勝手に描いていく事はますます難しくなっていく…可能性もあります。

個人的な印象ですが、ビジネス主導の企画モノ漫画は、単刊100万部みたいなウルトラヒットは狙えませんが、単刊10万部くらいの超ヒットくらいならちゃんと戦略を練ればワンチャンありそうな気がします。

漫画を沢山読んで部数勘を鍛えよう

ヒロユキ先生の「単刊５万部超えてる漫画は全部読もう！」という話を読むまで、私は漫画の部数なんてまったく気にしてませんでした。

上で書いたように、かなり頑張って探さないと漫画の部数データなんて見つかりませんしね。

今まで私は、漫画について、自分が好きかどうか、という基準しか持ってませんでした。
まあ、ピュアと言えばピュアかもしれません。

しかし、こうしてデータを洗ってみて分かったのは、”自分が好きだった漫画は大抵売れてない”という事実です。（たまに、自分が思ってたよりメチャメチャ売れてたケースもあるけど）
自分が大好きなあの漫画やこの漫画が（具体的な作品名を出すのは避けました）、データを見る限り、まったく商売として成立していない…っぽい…。

これはつまり、仮に私は自分の”好き”に基づいて好き勝手に漫画を描いたとしても、ビジネス的には失敗する可能性が高いという事を示しています。

しかし、私はそれなりに漫画を見る眼はあるつもりです。
自分の好きな漫画が売れてないからといって、自分が駄作マニアという事ではないでしょう。
数字と言うのは便利ですが、数字に洗脳されてはいけません。フォロワー数に洗脳されてる人達の二の舞になってしまいます。
”漫画の部数≠その漫画の良さ”です。いい漫画だからと言って売れるとは限らないという事でしょう。

ヒロユキ先生は、「単刊５万部出てる漫画は明確な魅力、売りを持っている」と仰ってます。

つまり、売れている漫画は、”良さ”というよりは、”売り”を持ってます。
”売り”というのは、私が思うに、漫画を読んだことが無いド素人でも一目で分かるような魅力の事だと思います。
「漫画リテラシーの高い一部の”分かってる”読者にだけ売れればいい…”良さ”だけがあればいい…」といくら作者が思っても、そういうマニアと言うか高リテラシー読者は、ほんのごくわずかの人数しかいません。そんな超ニッチに訴求しても、売り上げが１万部超えるのは難しいかもしれません。５万部みたいなヒットを出すには、漫画読んだことない人（例えば自分の両親とか親戚を想像してみよう）でも分かるような分かりやすい”売り”がとにかく必要になってきます。

これがアートの絵画だったら、ごく一部の高リテラシーなお金持ちの顧客や批評家だけターゲットにすれば済むかもしれませんが、商業漫画は絵画と違って大衆に向けて売るものですから、そういう訳には行きません。

優秀な漫画は、素人でも分かる明確な”売り”と、モノの分かってるマニアだけが分かる”良さ”の両方を備えています。

メシ漫画のメシ要素は分かりやすい”売り”になります。食欲というのは人間の三大欲求の一つですから、誰にでも理解できます。

ダンジョン飯は、メシ要素と言う分かりやすい”売り”を備えつつ、メチャクチャ設定が練り込まれたファンタジーという”良さ”の両方を持ってます。どっちが刺さっても読者は作品が好きになれます。

アニメの話になってしまいますが、例えば「エヴァンゲリオン」なんかは、マニアは難解な設定やら世界観やらを考察して”良さ”を堪能してますが、素人だってメチャクチャかっこいいアクションシーンや萌えるヒロインキャラという”売り”で楽しめます。

「けものフレンズ」のアニメも、マニアはポストアポカリプスっぽい雰囲気を考察してアレコレ言ってましたが、素人はサーバルちゃんの「すっご～い」とかのミーム要素だけでもたのしめてました。

まあそんなわけで、ヒロユキ先生が仰るように、売れている漫画を読みまくって”良さ”と”売り”を一通り頭に入れれば、あなたの漫画戦略のスキルは向上していくでしょう。

さらに、ヒロユキ先生は、「漫画を読んだらその漫画の部数も調べる」と書かれてます。漫画とその部数はセットで突き合わせて考える事が重要だという事です。

私はtwitterでかなり色んな人のイラストを見ます。
ツイートにはRT数やライク数が表示されてますので、イラストの内容とRT数がセットで脳にインプットされていきます。
すると、イラストを見ただけで「このイラストだと大体何RTくらいされてそうだな」というのが知らず知らずの内に見当が付くようになってきます。

ですから私はなんとなくtwitterに入り浸ってただけで、特に狙ったわけでも無いのに、自分がtwitterに投稿した漫画が数万RTを叩きだした事が何度もあります。
色々見てるだけで、なんとなく”感じ”が掴めてくるという事です。

ヒロユキ先生が言うのは、漫画でもそうしろって事です。
漫画の内容と部数を紐付けて頭にインプットしていく事で、漫画を読んだだけでそれが何部くらい売れてそうか見当が付くようになっていきます。そしてゆくゆくは無意識的に”感じ”が掴めるようになってきて、自分が描く漫画の内容も自然と売れるものになっていく…かも知れないという事です。

私も今までは漫画家という商売について、子供の夢みたいなふんわりとした印象しか持ってなかったのが、上で挙げたようなデータサイトの売り上げを眺めてるだけで、いきなり解像度が上がったというか、漫画家と言う仕事が夢でなく現実のビジネスとして冷静に見れるようになった気がします。

「漫画家やめたい」という匿名はてなダイアリーについて

先ほどリンク貼ったねとらぼのインタビュー記事で、最近twitterで漫画家についてのネガティブな情報が拡散されてて、漫画家は儲からないというイメージが付き始めてる問題をヒロユキ先生が憂慮されていました。

そういうネットの漫画家儲からない説の有名な記事の一つに、「漫画家やめたい」というタイトルの匿名はてなダイアリーの記事があります。

漫画家やめたい

これは匿名記事なので、内容の真偽はハッキリしませんが、結構迫真な内容なので、ホントかもしれません。
仮に真実だと仮定して内容を検討してみましょう。

これによると、ジャンプだと新人の単行本は3万部刷られるようです。
正直言って3万部は凄い数字だと思います。データ的に言って、ヒット作の部数です。さすがジャンプですね。
しかし、20年前だったら同じ条件でも10万部刷られたそうです。10万って今だと超ヒット作のレベルですね。恐るべし。それと同時に、ピークから7割も部数が減ってしまうという、現在の出版不況の深刻さも物語ってます。

さらに、とある月刊誌では初版の部数は6000部という情報も出ています。
6000部…少なっ！と思うかもしれませんが、正直言ってデータサイトの情報を眺めてると、大抵の漫画はそんくらいだろうなという印象があります。その印象を裏付けるような情報です。

この漫画家さんは、たった３万部で３巻までで打ち切られたら、印税は360万円しかもらえないし、今までの苦労がまったく割に合わないと嘆かれています。

上の方で書いた通り、漫画家を商売として考えると、10万部は出ないと割に合いません。5万部でまあ一応食えはするレベル、3万部だとまあ今は辛抱してここから当てに行かないと厳しいレベル、1万部だと食うのが不可能になってくるレベル、まして6千部となると…。
そして大半の漫画が6千部以下だと推測される現実…。

現実は厳しいと言わざるを得ないでしょう。

ちなみにヒロユキ先生はインタビューで、「単行本が5万部なら余裕のある生活ができる、3万部だと物足りないけど打ち切りの心配はないレベル、1万部だと出版社は赤字」という情報を語られています。

連載打ち切りと言うと、漫画家からは恨まれるでしょうが、部外者がこんな事を書くと角が立つかもしれませんが、売れない漫画を打ち切るのは、ある程度は”お互いのため”かもしれません。

単行本が数千部では、事実上、食っていけません。
ある程度若い内に見切りをつけて、転職を考えるのも、作家のためでもあるかもしれません。
こんな事を書くのもつらいですが、漫画家をビジネスとして冷めた目で見れば、そう結論付けざるを得ません。

しかし、この匿名ダイアリーでは「今まで漫画の事しか考えてこなかった職歴の無い35歳の社会不適合者が、どうしていけばいいってんだ？」というような痛切な訴えが書かれてます。

非常に難しい問題と言わざるを得ません。
とは言え、漫画家ならアシスタントに転向するというパターンがありますから、食いっぱぐれるという事は無いのかもしれません。（門外漢なので詳しい実情は知りませんが）
というか、よく聞く話だと、まずアシスタントとして弟子入りして、そこから漫画家を目指すというパターンですよね。

副業、あるいは趣味としての漫画家

大抵の人が数千部しか出ないのが普通の漫画家と言う商売、これ一本でやっていくのはリスクが高いと思わざるを得ません。

という訳で、漫画とは別にちゃんと本業を持っておいて、漫画は副業、あるいは趣味で描くというパターンも考えられます。

漫画家さんたちが語る『勤め人をやめて漫画家を目指すのは止めたほうがいいぞ」というお話

小説家とかだと、作家業が軌道に乗るまでは普通に仕事してた人が結構多いです。漫画家も、売れるまでは他の仕事をしていたという人もチラホラいる気がします。

しかし、漫画家が本命で、売れるまでは腰かけで他の仕事をしようと言う場合、どういう仕事をするかはよく検討する必要があるでしょう。
つまり、残業が多いような仕事だと、漫画を描く時間なんて無くなるからです。

漫画とは別に本業があるなら、売り上げなんてまったく気にせずに、完全に趣味として、自分の好きなように描いちゃうという考え方もあるかもしれません。
今なら別に商業出版しなくても、twitterとかで沢山の人に自分が描いた漫画を読んでもらう事は可能です。
完全に自分の趣味の変態性欲に忠実に基づいたニッチなエロCG集が、DLSiteでそれなりに売れてたりするなんて事もあります。

おわり

子供の頃に漫画家を夢見た自分が、一旦挫折してみて、むしろ一周回ってビジネスとしての漫画家業について冷めた目で見て、その魅力について考えてみました。

世の中の漫画を、その出版部数データと突き合わせて考えてみると、新しい視野が広がるという話でした。

漫画家ビジネスは、ビジネスとしてスケールさせることが不可能なので、個人でも一発当てられる夢のある世界という事が分かりました。

しかし、他の仕事と同じくらい漫画家が割に合うと言えるには、600万部を売って3億円を稼ぐ必要があると分かりました。
しかし、データを見る限り単刊数千部しか出ていない漫画家がほとんどらしいというのが現実でした。

結論としては、漫画家として一発当てるのは、他のビジネスで一発当てるのと同じくらい難しいかもしれないと言えます。

ですが、色んな漫画を読んで、データを突き合わせて、部数勘を鍛えてしっかり戦略を練って漫画を描く事で、ひょっとすると単刊10万部くらいは狙えるかもしれないという話もしました。

とは言え、余りにもビジネス目線で割り切って、自分では大して描きたいとも思ってない漫画を苦労して描いて、そこまでするくらいだったら普通に他の仕事をした方がマシ…という事もあるかもしれません。

私としては、あらためてこの記事を書きながら、単刊10万部、生涯600万部というハードルの高さにまたもや挫け気味なので、もしやるとしたら完全に趣味として漫画を描いてみつつ、色んな漫画を読んで部数勘を鍛えてみようかなと思いました。

記事を書きながら色々調べていて印象的だったのは、電子コミックの売り上げが紙の漫画の売り上げを上回っているという事実です。これからますます電子書籍の売り上げ割合が増えていく事でしょう。
そうなった場合に、じゃあもう電子だけで売ればいいんじゃね？という話が出てくることが予想されます。例えば連載はWebだけで行って、単行本も電子だけで出版する作品が出てくるかもしれないという事です。

そうなった場合に、”漫画を白黒で描く必要ってあるんだっけ？”という話さえ出てくるかもしれません。
敢えて紙での出版を諦めて、漫画をカラーで描いちゃうことで他の漫画とは差別化した魅力を提示する。みたいな戦略も考えられるかもな。と思いました。
ちなみに、すでにジャンプ漫画は電子書籍限定でカラー版の漫画も出してます。
まあ、カラーと言ってもキンドル端末だと白黒でしか読めなかったりしますけど。

話が逸れましたが、そんなわけなので、漫画家を目指してる方もそうでない方も、是非とも色んな売れている漫画を読んで、データと突き合わせて考えてみるという事をやってみてはいかがでしょうか。

最近、twitterを眺めてると、vTuberについて言及してる人が増えたな～という感じがします。

vTuberが出始めた頃は、ちょっとバカにしてたようなアニメファンも多かったような気がしますが、今ではむしろアニメの話題よりvTuberの話題の方が多く見かける気がします。まあ、私の観測してるTLが偏ってる可能性もありますが。

ちなみにふたばちゃんねるにもいつの間にかvTuber板とホロライブ板ができてました。

何となくですが、日常系アニメのファンがその流れでvTuberにハマってる感じがしなくもないです。
もしかして、vTuberって日常アニメの需要を食っちゃってるんじゃないかな…？何となくそう思ってこのブログ記事を書く事にしました。

日常系アニメの流行について

vTuber云々の話の前に、それまでに日常系アニメが流行していた状況について、かいつまんで書いておく必要があるでしょう。

というわけで「“日常系アニメ”ヒットの法則」という本を読んで勉強しました。
この本は、2011年に書かれたもので、2009年～2010年のけいおん！アニメの大ヒットを受けて、そのヒットの理由を分析する…的な立ち位置の本でした。

日常系アニメというのは、あずまんが大王から始まり、らき☆すたやけいおん！など、美少女達が登場して、起伏のある物語があまり無くて、彼女たちの日常を淡々と描くような作品群の事を指すようです。

どうして日常系アニメが流行っているのか？
著者は、ポストモダン思想の「大きな物語の崩壊」が関係していると指摘します。
ソ連の崩壊に始まり、サリン事件や阪神大震災、９．１１テロ、アメリカのイラク戦争などなど、1990年以降は、今までの常識、価値観が覆るような出来事が次から次に起こりました。そのような時代には、もはや「大きな物語（宗教、イデオロギーなど、みんなが同じ価値観を共有してると信じさせてくれるもの）」が与えてくれる物語は通用しないというわけです。
だから今、物語の無い日常系アニメが流行ってるとの事。

さらに、コンテンツの流行の流れは、どんどん「コミュニケーション」重視になってきている事も指摘されてます。
例えばポケモンはRPGですが、ストーリーはオマケみたいなもので、ポケモンの収集、対戦がメインです。ポケモンを集めるためには他の人と通信して交換する必要がありますし、コミュニケーション性が重視されたゲームで、大ヒットしました。

それからMMOなどオンラインゲームが流行り始めましたが、MMOではもはやプレイの目的は完全に物語よりも他のプレイヤーとのコミュニケーションの方が大きくなってます。その流れでモンハンが出たりしました。

美少女ゲームもゲーム内の美少女とコミュニケーションするゲームと言えます。ときめきメモリアルは高校生活という「日常」を送りながらヒロインとの関係を深めていきます。

アダルトゲームにも「日常」要素が入ってきます。Keyが制作したToHeartではもはやエロシーンよりも「日常」が大きな要素を占めるようになりました。まあKeyのゲームにはしっかりした物語が存在するので日常系漫画とはちょっと違うかもしれません。

ToHeartのようなゲームから主人公の男を取っ払って日常部分だけを切り出したら、日常系漫画の始祖であるところのあずまんが大王が生まれた…みたいな事かもしれません。

それから、ラノベの文脈にも触れられています。スレイヤーズに代表されるラノベでは、アニメ風のイラストが多用されてます。そのせいか、段々と物語性よりもキャラクター性に重きが置かれ始め、「ラノベはキャラクターに依存しており、小説とイラストによってキャラクターを伝えるための道具に過ぎない」的な事を言ってる人までいるそうです。キャラが立ってると、他のファンと価値観を共有しやすくなってコミュニケーションが広がりますし、アニメ化もしやすくなります。この流れは涼宮ハルヒシリーズなどに続いていきます。

細かい作品の系譜についてはここでは説明をしませんが、参考になる系譜図が本に載ってたのでこれを引用だけさせていただきます。

AKB48のような新しいタイプのアイドルの出現にも触れられています。握手会で会えるアイドル、そして他の同好のファンとの交流もしやすくなります。

ここまで見ていくと、日常系アニメが生まれる土壌について分かってきます。
つまり、現代のコンテンツの一種の潮流として、①コンテンツ内容の変化　物語→キャラ同士の日常　②ファン同士のコミュニケーション性の重視　つまり、コンテンツ内でもコンテンツ外でも両方でコミュニケーションが最重要視され始めているという事です。

日常系アニメが出てきた時期と言うのはSNSやブログ、ニコニコ動画が出てきた時期と一致します。
言うまでも無く、これらのツールによってファン同士のコミュニケーションは加速度的に広がりました。

twitterでスクショを貼ったりニコ動で切り抜き動画を上げる場合に、物語性が強い作品だと、作品を知らない人はコンテキスト（文脈）を理解できないですが、日常系なら物語が無い→コンテキストが必要ない→敷居が低いので、日常系作品はネットでシェアするのに有利と言えます。

ここまで述べたような、ファンのニーズの変化とは別の観点として、アニメ制作側の都合の変化の話もあります。

アニメのビジネスモデルの変化

私は結構前から疑問に思ってたんですが、昔はアニメは夕方に放送されていた気がしますが、そういうアニメは最近はめっきり減って、ジャンプアニメとかまで深夜に放送されるようになってますよね？例えば鬼滅も深夜アニメでした。
そして、昔やってたデジモンとかのアニメは１年間（50話くらい）放送されていましたが、深夜アニメは基本、１クール（12～13話）の放送です。
どうしてそんな変化が起きたんだろう？
その疑問の答えもこの本に書かれていました。つまり、アニメのビジネスモデルに変化が起きているという事です。

日本のアニメビジネスは、元々、ディズニーを参考にして構築した、キャラクタービジネスが中心だったようです。
例えばキャラクターの名前が付いたお菓子を売るといった事です。今でも仮面ライダーのカレー、フィッシュソーセージ、グミ、チョコなどが売られてますよね。つまりそういったキャラクター商品の会社が番組のスポンサーになっていたという事です。

ようするに、アニメ番組自体はキャラクター商品の宣伝としての要素が強かったわけです。
お子様に広く認知してもらうために、ゴールデンタイムに放送する必要がありましたし、１年間とか長い期間放送し続ける必要もありました。

しかし、これはハイリスクハイリターンで危険の大きいビジネスモデルでした。
まず、ゴールデンタイムに１年間アニメを放送し続けると、広告枠の料金とアニメの制作費は膨大なものになります。様々なキャラクター商品の開発費もかかりますし、お子様に売るものなので、単価は上げられません。
もしもアニメがつまらなくてウケなかったら、キャラ商品も売れず、あっけなく全てが崩壊してしまいます。

転機が起きたのは、1980年代からです。
家庭用ビデオ、LD、DVDなどの映像メディアが登場しました。

それにより、アニメそれ自体を直接商品（DVD、ブルーレイ）にして売る事が出来るようになりました。
DVDは、子供向けキャラ商品より採算性に優れています。
キャラビジネスアニメは数百万人にリーチする必要がありましたが、DVDなら数万人が買ってくれれば採算が取れます。

そんな訳で、ゴールデンタイムに放送する必要が無くなり、放送枠が安い深夜帯に移行しました。深夜枠に移動した事で、ゴールデンタイムよりも、過激な内容や、挑戦的な内容が流せるようになりました。そして長期間放送する必要も無くなったので、１クール放送が主流になりました。

アニメの内容も、ターゲットが子供から大人（DVDを買うお金を持ってる）にシフトしたので、内容も大人向け（オタク向け？）になっていきました。

という具合で、これが夕方放送のアニメが減って深夜アニメが増えた背景という事でした。

これは好ましい変化と言えるのではないでしょうか？
キャラビジネスアニメは子供にキャラ商品を買ってもらうビジネスですが、子供に売るというのは実質的にその子のお母さんに買ってもらう事を意味しており、つまりお母さんに嫌われてはいけないといったしがらみがあります。
例えばかつてボボボーボ・ボーボボのアニメがありましたが、当初は19:30のゴールデンタイムに放送開始しましたが、いくら子供には人気だったとしても、内容がシュール過ぎて子供に見せたくないと親御さんに思われてしまいました。次第に枠移動や打ち切りの憂き目にあい、最終的には全てのスポンサーを失う事態になりました。

DVDビジネスのアニメなら、こういった諸々のしがらみを気にせず、とにかく優れた内容のアニメさえ作れば商売になるわけです。それって健全ですよね？

と言いたいところですが、話はそう簡単ではないようです。
色々なアニメが制作されるうちに、「どうやら面白いアニメを作れば売れるというわけではないらしいぞ？」という事が判明してきました。

ストーリーが面白いアニメじゃなくて、キャラに萌えるアニメの方が売れるようなのです。
あと、精神的に疲れている現代の社会人は、もはや起伏の大きいストーリーに精神的に耐えられないので、事件などが何も起こらない日常系作品しか見れないという話もあると思います。

まあそんなわけで、深夜アニメで日常系作品がコンスタントに生まれるようになったのです。

けいおん！の大ヒット

そういう状況の中で、京アニが制作したけいおん！のアニメは、それまでの日常系作品と比べてもちょっと異例の大ヒットを生みました。

この本では、けいおん！が大ヒットしたのは、楽曲が果たした役割が大きいとしています。

そもそも京アニが何故けいおん！を制作する事にしたのか？京アニはそれまでもハルヒやらきすたで楽曲をヒットさせた経験がありますから、もっと楽曲要素を押し出せばアツいんじゃないかないか？そう思ったのかもしれません。バンド活動を扱っている日常系作品であるけいおん！は持ってこいの作品だったと言えます。

けいおん！では関連楽曲が次々とCD化されて、オリコンチャートにランクインしまくりました。

さらに斬新な試みとして、けいおん！の声優に楽器を練習してもらって、リアルライブをやろう！という企画を始めて、これも大好評だったようです。
これはその後の声優ライブの流れを生んだのかもしれません。

その後の状況

「“日常系アニメ”ヒットの法則」は2011年に書かれた本なので、けいおん！までの話しか書かれてませんが、その後の10年間で色々と状況が変わってきています。

残念ながら、アニメDVDの販売数は減少の一途を辿っているようです。
地デジ放送と地デジレコーダーが普及して以来、もうDVDを買わなくても高画質のアニメが録画で何時でも観れるようになりました。

DVDでアニメそのものを商品化する事ができたけど、地デジでアニメ自体は無料で観れるので、DVDを買う理由は無くなりました。厄介な状況です。

そもそも今となってはDVDを観るのにイチイチディスクを入れ替える作業が億劫でさえあります。プライムビデオ、ネトフリ、dアニメなどのサブスクで充実したラインナップのアニメが観れるので、それで満足してる人も多いと思います。私もそうです。

ネトフリは独自制作のアニメに潤沢な予算を出してくれるみたいですが、他のアニメはDVDが売れていた頃と比べると、サブスク中心のビジネスの利益は悪化してるんじゃないでしょうか。

詳しいデータは無いですが、アニメビジネスは苦境に立たされていそうです。

音楽ビジネスにも似たような流れがありました。
一時期、音楽はNapstarという違法シェアソフトのせいでまったく売れなくなって、危機的状況に陥ってました。
それから、Spotifyのようなサブスクサービスが出てきて、音楽業界も、タダで聴かれるよりはマシだという事でそこに乗っかり、めでたく違法シェアを駆逐できたわけです。

が、CDが一杯売れていた頃と比べると、サブスクサービスでの売り上げはちっぽけな物になってしまいました。

というわけで、現在の音楽ビジネスは、Spotifyなどで大勢の人に楽曲を周知してもらって、アーティストがライブをやって、チケット代や物販で儲けるというビジネスにシフトしてきているようです。

で、アニメの話に戻りますが、アニメでも音楽と似たようなライブビジネスへのシフトが起きているかもしれません。

今ググった所、「アニメライブのビジネス構造について」という資料が見つかりました。

https://www.u-bunkyo.ac.jp/center/library/067-080%EF%BC%88%E5%85%AC%E9%87%8E%EF%BC%89.pdf#search=’2.5%E6%AC%A1%E5%85%83%E3%83%9F%E3%83%A5%E3%83%BC%E3%82%B8%E3%82%AB%E3%83%AB+%E5%A3%B2%E3%82%8A%E4%B8%8A%E3%81%92′

アニメライブの一つに2.5次元ミュージカルというものがありますが、DVDの売り上げ低迷に反比例するように、観客動員数が増えているとの事です。

日常系アニメの話のまとめ

さて、ここまで「“日常系アニメ”ヒットの法則」の内容を元に、長々と書いてしまいましたが、話をまとめると、

①コンテンツの潮流は、コミュニケーション志向になってきている。ときメモみたいに画面の中のキャラとコミュニケーションするパターンと、画面外でファン同士でコミュニケーションするパターンがある

②ブログやSNSの登場で、ファン同士のネット上コミュニケーションは恐ろしく加速した。日常系アニメはコンテキストが無いのでtwitterや動画サイトでシェアするのに有利だった

③アニメのビジネスモデルの変化により、アニメの作品そのものをDVDとして売り上げが立てられるようになった。DVDが売れるアニメは、ストーリーが面白い物よりキャラクターに萌えられるものである事が分かった。

④地デジとレコーダーの普及によって、DVDの売り上げはどんどん低迷している。アニメはライブビジネスに手を出して打開しようとしている。

まあこんなところでしょう。

アニメの脱構築

結論に走る前に、ここで日常系作品はそれまでの漫画、アニメから何を”脱構築”したのだろう？という話をしてみたい。

脱構築って何？というと、これはポストモダンの話でよく出てくるワードです。
意味としては、「あるモノについて、まずそのモノをバラバラに分解して、良さそうなパーツだけを拾って別の物を組み立て直す」みたいな事です。

日常系作品が成し遂げたのは、それまでの「アニメには面白いストーリーが必要不可欠！」みたいな思い込みを脱構築した事になります。アニメには必ずしもストーリーなんて必要無かったんだ！というわけです。

セカイ系作品も何かを脱構築してるのかもしれません。「アニメは必ずしも設定を全部説明しなくてもいいんだ！」みたいな感じでしょうか。

深夜アニメも、それまでの子供向けアニメから脱構築したものと言えるかもしれません。「アニメは別にキャラ商品で稼ぐ必要は無いんだ！」という感じです。

一体、アニメの脱構築というのはどういうプロセスで起きるのでしょうか？
それについて考えてみたものの、正直よく分かりませんでした。時代の変化により、ビジネス環境が変わることなどが影響するのかもしれません。

ひとつ言えるのは、これから先もアニメの脱構築は起き続けるだろうという事です。（例えば最近だとなろう系アニメが流行ってます）

vTuberは日常系アニメを脱構築したのか？

さて、ようやく本題のvTuberの話に入ります。
大体ここまでの流れを読んで、すでに私が言わんとする事が分かってきてる人もいるかもしれません。

つまり、vTuberって日常系アニメを脱構築した存在と言えるしれない…という話です。

どういうこと！？

日常系アニメは、それまで必要不可欠だと思われていたストーリーの必要性を否定しました。
「よく考えるとアニメってストーリー無くても良くね？」という訳です。
それにより、日常系アニメはひたすらキャラ萌えに特化したコンテンツになりました。

vTuberは、さらにその上を行き、”そもそもアニメである必要無くね？”という主張を突きつけてきました。アニメでなくなるというアニメの究極的脱構築を成し遂げたのがvTuberです。

「何言ってんだ？vTuber動画と日常系アニメじゃ内容が全然違うじゃん！」と思われるかもしれませんが、どちらもキャラクターを立てる事を最優先にしているという意味では同じなのです。

以前のブログ記事でも書きましたが、読者にキャラクターの魅力を伝えるには、キャラのアクションとリアクションの積み重ねを見せる事が必要になります。まんがタイムきららの作品フォーマットなら、キャラのアクションとリアクションを強制的に大量に積み重ねる事が出来ます。
だから”キャラを立てる”という目的のために”日常系”という手段が用いられているのです。

”キャラを立てる”という目的さえ達成できるなら、必ずしも日常系の内容をそのままなぞる必要は無いと言えます。

vTuberは何故キャラが立つのか？

私はvTuberが出現した当初、これはアニメの置き換えにはならないだろうな…と思ってました。

例えばキズナアイさんの初期の動画を観てもらえば分かりますが、vTuber動画はどうしても一人芝居みたいな感じになってしまいます。

私はキャラクターというのは相対的なものなので、比較対象になる他のキャラと掛け合いとかしないとキャラが立ちはしないだろう…そんな風に思っていました。
キャラが立つにはアクションとリアクションが大事なのですが、一人でボケとツッコミができないように、一人ではアクションとリアクションはできません。

しかし、vTuberはやがてこの問題を克服する秘密兵器を導入しました。

それは、ゲーム実況です。

ゲームなら、一人でもゲームに対してアクションやリアクションをする事が可能になります！
ですのでゲームで遊んでる動画を観ているだけで、視聴者はvTuberのキャラをどんどん理解していけるってわけです。
ですから、人気vTuberはすべからくゲーム実況をやっているハズです。vTuberがゲーム実況する事はほとんど必須要件です。キャラを立てるためにゲーム実況が必要不可欠だからです。

そんなわけで、ゲーム実況という秘密兵器を手にしたvTuberは、日常系アニメと同じくらいのキャラ立ちを可能にしました。

vTuberは動画制作コスパがいい

アニメは一話あたりの制作費用は1000万～1500万円くらいかかるといわれてます。
結構高額ですよね。

これをペイしようと思ったら、DVDが1万枚くらい売れないと困るという事になります。

それに対して、vTuberはどうでしょうか。

例えば、トップレベルの個人vTuber勢であるところのぽんぽこちゃんねるについて見てみます。
ぽんぽこちゃんねるの恐ろしい所は、基本的に毎日動画がアップされているという事です。
アニメだと毎週でさえ相当しんどいのに、毎日なんて絶対不可能ですよね。

ぽんぽこちゃんねるの１月頃の一週間の動画７本について調べたところ、のべ再生数は478,613回、動画再生時間の合計は1:16:28でした。

たった一週間、ぽんぽこさんとピーナッツ君さんの２人でこれだけのボリュームのコンテンツを生み出して沢山の人に見られている…凄まじい生産性だと思いませんか？
それに、ぽんぽこちゃんねるの動画は面白いですし（個人の感想）

しかし、収益的にはどうなんでしょうか？
ユーチューバーの動画の収益は、大体1再生辺り0.1円だと言われてます。
ぽんぽこちゃんねるの一週間の再生数が48万だと、収益は4万8千円くらいという事になります。
いくらvTuberの生産性が高いとは言え、毎日10分の動画を収録、編集しようとすると、一日中働かないと間に合わないかもしれません。

土日も毎日働きづめで一週間で4万8千円、しかも２人で折半と考えると…あんま割のいい商売じゃないかもしれないという気もしますね。
しかし、地道に活動を続けてチャンネル登録数が２倍、３倍に増えて、収入が２倍、３倍と増えていくとするとどうでしょうか？
今こつこつ頑張る事で、あとあと大きな利益を手にすることができる…そういう夢のあるビジネスという事です。

もちろん、vTuberの収益は動画の広告収入以外にも、企業案件動画の収入や、コラボグッズの収益、あるいは自作グッズの売り上げなどもあるので、実際にはもっと上がるはずです。

ここでは「vTuberはアニメ制作より簡単に儲かる！」みたいなニュアンスの話に持っていきたかったんですが、数字を調べてみると思ったよりそうでもなさそうですね…。

さておき、動画の生産性に目を向けると、たった二人で一週間（14人日）で1時間以上のコンテンツを生産できるのは凄すぎますね。

一方アニメはどんなもんなのかと言うと、「アニメ　工数」でググっても、分かりませんでした。アニメは工数じゃなくて単価でやっているからだそうです。ためしに異世界ピクニック１話のスタッフロールの人数を数えてみたら、100人弱が関わっているようです。さらに協力CGスタジオの名前も一杯出てきたので、膨大な人数が制作に関わってると思われます。

まあ、単にコンテンツ時間あたりの生産性でvTuberとアニメを比較したらアニメファンには怒られるでしょうね。
「アニメの方が一杯キャラが出てくるし、背景も綺麗だし、メッチャカッコいいアクションができるけど、vTuberにはそれがない！」という意見もあるでしょう。

３DモデルのvTuberは、VRデバイスやVICONなどのモーキャプ設備を使用して、常時モーションキャプチャーして収録しています。
ですので、例えば10秒間のシーンを収録するのに、アニメだと24コマ×10秒で240コマ、まあリミテッドなので節約したとして20コマくらいの作画が必要になります。これだけで丸一日消費するかもしれません。まあ、とりあえず12時間かかるとしましょうか。
大して、vTuberはリアルタイムでモーキャプしてるだけなので、10秒の収録に10秒しかかかりません。
比較すると、vTuberの生産性はアニメの4320倍となりますね。

逆に言えば、人間にできないようなアクションは、モーキャプできないのでvTuberにはできない事になります。
また、たとえばプリキュアみたいに５人組で活動するvTuberがいれば、にぎやかで面白そうに思えますが、実際はそういうvTuberは見当たりません。何故か？
ぽんぽこちゃんねるのように、毎日レベルのペースで動画を制作するには、それこそ毎日レベルで誰かの家に集合して収録するハメになります。いくら何でも5人もいればそれぞれに都合というものがあるので、毎日集合するなんて現実的ではありません。

何故ぽんぽこちゃんねるが毎日２人で収録できるのか？というと、それはぽんぽこさんとピーナッツ君さんが実の兄妹だからです。同様に、おめシスも２人で活動していますが、それは二人が実の双子（おそらく）だから可能だったという事です。
結局、ゲーム実況という秘密兵器を駆使したライバー以外は、キャラを立てるには複数人で活動した方が圧倒的有利なのです。キャラクター性というのは相対的なものなので、複数人いれば、もう一人と比べてこっちは金が好き、とか、こっちは遊戯王が好き、とかで差分がハッキリしてきます。この差分こそがキャラクター性だとも言えます。

で、それが分かってるならどうしてぽんぽこちゃんねるやおめシスみたいな２人組vTuberが溢れ返ってないのか？というと、いくら家族でも、相当仲のいい相手で、しかもvTuberに理解があって、さらに二人とも相当ヒマ、という条件をクリアできるケースは滅多にないからでしょう。

ついでにvTuberの背景についても触れますが、vTuberの始祖であるキズナアイさんの頃から、vTuberの背景はシンプルにする伝統ができてる…気がします。
キズナアイさんの背景は真っ白ですが、なぜなのか？と言うと、下手に3Dの背景を置くと、”ゲーム画面”みたいに見えちゃうから、ゲームと誤解されるのを嫌ったから。という仮説を聞いた事があります。

話を戻しますが、たしかにvTuberはプリキュアみたいなバッキバキのアクションアニメと比べるとできない事も多いです。
が、この記事では日常アニメとの比較です。日常系アニメではそんなにアクションしません。
日常アニメは、”キャラ立ち”に特化させるために、それまでのアニメからストーリーを捨ててしまいました。

それに対して、vTuberは、もはやアニメという舞台装置さえ捨て去って、”キャラだけ“のコンテンツとなり、ゲーム実況や2人組を駆使してキャラ立ち性能も日常系アニメに負けてません。

この状況に対して日常系アニメはどう答えていけばいいんでしょうか？

ここでの結論：vTuberは日常系アニメの4320倍の生産性を持っていて、キャラ立ちスペックも実は日常アニメに負けてない

vTuberは配信から直接収益を上げられる！

先ほどは、動画メインのぽんぽこちゃんねるについて書きましたが、vTuberには動画メイン勢のほかに、ライブメインで活動してる人達（ライバー）もいます。

動画メイン勢と比べると、ライバーは一つの圧倒的メリットを持っています。

それは、「スーパーチャット」です。要するに投げ銭です。

Youtubeライブではスーパーチャットを受けられます。普通の動画では受けられません。（ただしプレミア公開すれば受けられる）

スパチャの収益性がどれくらい凄いのかは、例えばこちらを見てもらえば分かるかもしれません。

vTuberはライブ配信で何をやってるんだろう？というと、ほとんどのケースではゲーム実況をやってます。

どうしてvTuberはそんなにゲーム実況一辺倒なんだろう？というと、先ほども言った通り、vTuberがキャラを立てるにはゲーム実況するしかないので、自然と上位陣はゲーム実況してる人ばかりになるというのがあるでしょう。
そして、そもそもvTuberは雑談かゲーム実況くらいしかできる事が無いのです。
例えば現実の食べ物を食べたり、おもちゃを持ったりする事は”普通は”できません。
ですので、ユーチューバーに比べてvTuberはできる企画に大幅に制限があります。

おめシスは、高い技術力と様々な工夫でその辺の事情を乗り越えています。
例えば、何らかの技術でバーチャルと現実世界を合成できる仕組みを作って、vTuberなのに現実のおもちゃやガンプラを紹介できるようにしています。
さらに、おめシスは、バーチャルなのを逆手にとって、Unityを駆使して逆に生身のユーチューバーにはできないようなバーチャルならではの企画をよくやってます。面白いです（個人の感想）

おめシスやぽんぽこちゃんねるは動画メイン勢なので、広告収益が頼りになります。スパチャが儲かるならどうしてもっとライブ配信しないんだろう？（余計なお世話ですが）というと、たとえばぽんぽこさんは特に喋りが流暢というわけではないのですが、動画では編集しまくってテンポよく見せているそうです。つまり生配信が得意ではないという事でしょう。

ライブ配信は、決してラクして儲かるというものではありません。
向いている人と向いてない人がいます。そして、努力も必要です。
まず、毎日何時間もゲームで遊んで実況するのが苦痛な人だとできません。ゲームが大好きな事が前提です。
また、自分の素のキャラクターを曝け出して勝負するハメになります。キャラを作ろうとしても、毎日長時間、ずっと演技している訳には行かないからです。
そもそも、ゲームをやってると、ついつい自分の素のリアクションが出てしまうものです。

そして、そうやって出てしまった自分の素のキャラが、視聴者にウケるとは限りません。スパチャしたくなるキャラとそうでないキャラというのはやはりあると思います。

ついでに言うと、できればゲームプレイが上手い必要もあります。下手なゲームプレイを観ていると、どうしてもイライラしてしまうものだからです。

さておき、深夜アニメがDVDの普及によってキャラビジネスをしなくても作品を直接売る事が出来るようになったのと同じように、vTuberもスパチャによって、広告収益以外に視聴者から直接投げ銭を受けられるようになったという事です。

ところで、ライブの視聴者は、別にタダで全部ライブを観れるのに、スパチャするモチベーションは何なんだろう？という疑問があるかもしれません。
私もあまりスパチャしないので、スパチャする心理についてハッキリした事は言えません。

しかし、逆に言えば日常アニメだって、地デジで録画すればいつでも観れるのに、どうしてそれでもDVDを買うんだろう？という話です。

思うに、スパチャするのもDVDを買うのも、「そのコンテンツが好きで、応援したいから」という事ではないでしょうか。

ここでの結論：深夜アニメはキャラビジネスを脱却して、アニメそのものをDVDとして売れるようになって、採算性が上がった。しかしvTuberはさらに上を行って、スパチャで視聴者から直接マネタイズできる

vTuberはtwitterをやってる！

さきほど、「最近のコンテンツの潮流は、コミュニケーション志向であり、それを突き詰めた結果、日常系アニメが生まれた」という話をしました。

コミュニケーション志向という面でも、vTuberは日常系アニメの先を行ってます。

vTuberは自分でtwitterをやってます。

日常系アニメはtwitterでシェアしやすい特徴を持ってますが、vTuberはそもそも本人がtwitterにいます。なんなら本人にリプライを送る事も誰でもできます。
どちらがコミュニケーション志向で上を行ってるかは明らかです。

vTuberは直接コミュニケーションができるコンテンツなのです。

動画にコメントを付けると、vTuberがハートを返してくれたりします。

さらに、ライブ配信では、スパチャすると本人がその場で読み上げてくれることもあります。
このリアルタイムな双方向性は、他のどんなコンテンツより先を行っていると言えるかもしれません。

vTuberはコミュニケーション志向という意味ではダントツ最強コンテンツです。

また、ライバーは毎日何時間もゲーム実況して、全部アーカイブ動画になりますが、いくら何でも毎日全部追いかけるのは、熱心なファンでない限り難しいです。

しかし、vTuberを布教するために、ライブ配信から面白い所だけを切り抜いてまとめ動画を作ってくれる人がいます。そのまとめ動画がバズッて、新たなファンが生まれたりします。
好きなvTuberのファンアートを描く絵師さんも一杯います。ファンアートに対してvTuber本人がリアクションをくれたりする事もあり、それは絵師さんも嬉しいですからますますファンアートを描きます。
そのような、ファンコミュニティとエコシステムがvTuberには存在します。

ここでの結論：日常系アニメはコミュニケーション志向を極めたアニメだったが、vTuberはそのはるか先を行ってしまってる

vTuberは他のコンテンツに乗っかりやすい

普通、アニメの中に勝手に実在する商品とかを出してはいけません。
登場させる必要があるなら、イチイチ権利者に許可を取る必要があります。

それに対して、vTuberは実在商品を勝手にレビューしたり、ゲームを実況したり、他人の歌を勝手に歌ったりしていますよね。

どうしてアニメにできない事をvTuberはできるんだろう？（ハイスコアガール騒動では無許可でSNKのゲーム出しまくったのが怒られて書類送検される人まで出たというのに）

元々、普通のユーチューバーがおもちゃや食べ物のレビュー動画を作ってましたが、権利者はそんな動画をアップされても別に損しませんし、宣伝になって売り上げが上がるだけなので、どうぞやってくださいって感じでした。ゲーム実況もおおむねそんな感じでした。
そういうわけで、Youtube上では商品やゲームを扱っても大丈夫な基盤が形成されていました。
歌についても、すでにYoutubeとJASRACは包括契約を結んでおり、誰でも歌ってみた動画を上げられるように整えられていました。

vTuberは、「バーチャルなユーチューバーですよ」という建て付けをアピールする事で、そういう土壌にフリーライドする事に成功したと言えます。

vTuberは今流行ってる商品を動画に出したり、流行ってる歌を歌ったりする事で、Youtubeのアルゴリズムでレコメンドされやすくなり、バイラル的に圧倒的に有利です。
こういうのはアニメでは絶対にできない事ですね。

ちなみに、企業所属vTuberとゲーム会社との間でトラブルが発生した事もありました。
ゲーム会社からすると、「個人のユーチューバーやvTuberはともかく、企業がウチのゲーム使って勝手に金儲けするのは許さん！」というわけです。
何しろvTuberというのは出てきたばかりで、何がシロで何がグレー、何がクロなのか、お互い手探りだったのだと思います。
紆余曲折を経て、今は大体、vTuber企業はゲーム会社と個別に相談して利益分配の契約を結ぶのが基本になってきてるようです。

そういえば、アニメのキャラがvTuberを始めた！みたいな場合は諸々の権利関係はどうなるのでしょうか。
例えば、ウマ娘のゴルシがvTuberやってましたよね。今ザックリ動画一覧を眺めた感じでは、現実の商品出したりゲーム実況したりはしないで、無難な企画をやっているようで、権利関係には相当慎重になってるみたいでした。

ちなみに、ここまで考えると、だったらあたかもvTuberって体で、中身は実質アニメ。みたいな作りの場合、実在商品とか出していいのか？という話ですが、Youtubeに動画上げるだけならセーフでしょうけど、その動画をまとめてDVDにして売ろう！とか、地上波で流そう！という段階でアウトになる気がします。

ここでの結論：アニメは権利関係はガチガチに縛られてるけど、vTuberは比較的に好き放題出来て、バイラル的にも有利

vTuberはライブビジネスと相性抜群！

先ほど、けいおん！は日常系アニメに音楽の要素を載せたら大ヒットした！という話をしました。

では、vTuberはどうなんでしょうか？
もちろんvTuberでも音楽要素はアツいです。

アニメだと楽曲はオリジナルでお金をかけて制作する必要がありますが、vTuberは”歌ってみた動画”とかで流行ってる歌を好き放題歌えます。

さらに、vTuberのライブビジネスも相当盛り上がっています！
ここでいうライブというのは、ゲーム実況のライブ配信の事ではなく、音楽ライブの事です。（まあライブ配信で歌うvTuberもいるけど）

そういえば、vTuber黎明期は、歌を歌えるvTuberって相当特殊スキルみたいな扱いだった気がします。
当時はときのそらさんや富士葵さんが歌が上手くて凄い！という感じでした。
しかし、vTuberが音楽ライブをやる風潮になってくると、全然歌を歌うキャラじゃなかったようなvTuberも誰も彼もが舞台に立って歌うようになっていった気がします。
例えば、キズナアイさんも今では音楽ライブをやっています。
まあそれだけ、音楽ビジネス、ライブビジネスがアツいという事かもしれません。（二次元キャラの音楽ライブといえば、vTuber以前だと、初音ミクさんのリアルライブが大盛況でしたね。なんとなくあの感じを継承してる気がします）

vTuberのライブ配信といっても２種類あって、現実のライブハウスなどの会場でキャラクターをスクリーン投影するARライブ、もう一つはVR世界でライブをするVRライブです。
あるいは普通にYoutubeライブやニコ生で動画として音楽ライブをするパターンもあります。（ARライブを動画サイトでも同時配信するパターンもあります）

vTuberは元々モーキャプ技術でリアルタイム３Dライブ配信を行っていたので、その技術が音楽ライブでもそのまま活かせました。

現実でもバーチャルでも臨機応変に対応できるという意味では、人間のアーティストやアニメの2.5次元ミュージカルよりも柔軟と言えるかもしれません。

アニメはDVDの売り上げが低迷して、ライブビジネスに活路を見出しているという話をしましたが、そのライブビジネスもコロナ禍の影響で難しくなってしまいました。
その点、vTuberもARライブは難しくなってしまいましたが、じゃあVRライブにしようか。という風に、柔軟に対応できています。

ここでの結論：アニメはDVDの低迷に伴いライブビジネスにシフトしていっているが、vTuberは普段のキャラクターのままライブができて、音楽ライブと相性抜群

vTuberはグローバルでウケる可能性を持つ

vTuberはバーチャルキャラがユーチューバーをやるという建付けですが、ユーチューバーはもちろんYoutubeの文化です。

ニコニコ動画は日本の文化って感じですが、Youtubeは英語圏の文化って感じでしょう。
そういうわけで、vTuberはもともと英語圏との文化的相性が良かった…のかもしれません。

vTuberはややこしいコンテキストがほぼ無いので、バイラルしやすいのですが、それは海外の人にとっても取っつきやすい事を意味します。

何が言いたいかというと、今ではvTuberは英語圏のファンも多いという事です。
ホロライブ所属vTuberの動画のコメ欄とか見てみてください。ほとんど英語コメントで埋め尽くされてたりします。

以前はこんな事になるとは想像もしてませんでした。vTuberはあまりにも日本的すぎると思ってたからです。

どういう流れでホロライブが英語圏にウケていったのか？というのは、私も詳しいわけではありませんが、まずさくらみこさんのGTA5実況→ころねさんのDOOM実況→桐生ココさん→ホロライブENのサメみたいな流れで広まっていった…ようです。

ホロライブは英語圏にウケる前に中国でもウケている時期がありましたが、それについては色々と揉めたりしたようです。

まあつまり、意外な事にvTuberはグローバルでウケる可能性を秘めていたというわけです。
何故なら、vTuberという建て付けは、元をたどるとYoutubeという英語圏の文化にルーツを持っているから…でしょう。

日本のローカルな市場にとどまっているよりは、世界のグローバルな市場にアクセスできる方が、当然有利です。

ここでの結論：vTuberはやり方によってはグローバルにバイラルしてメチャクチャ儲かる…かもしれない

最終結論

こうしてみると、日常系アニメのファンがvTuberに流れるというのは必然的な帰結だったという気がしてきますね。

日常系アニメが視聴者に与えるものは、”コミュニケーション”と”キャラ萌え”だったわけですが、vTuberも”キャラ萌え”を与えてくれますし、”コミュニケーション”については数段先を行っています。何しろキャラクターと直接コミュニケーションできるのですから。

会えるアイドルならぬ、会えるキャラといったところでしょうか。

バイラル性能や、ライブビジネスとの相性についても、vTuberは日常系アニメの上を行ってるようです。

「vTuberは日常系アニメを駆逐するかもしれない」という仮説が正しいかどうかは、これからの市場の成り行きが答えを出してくれるでしょう。
もし本当にそうだった場合に、日常系アニメはこの先どうすればいいんだろう？という話ですが、それはやっぱり、vTuberが与えてくれないものを与えるしかないでしょう。

それが何か？と言われるとハッキリしませんが、例えばvTuberができないようなバキバキのアクションをやるとか、あるいはやっぱり、ストーリー志向への回帰かもしれません。

そもそも、日常系アニメがストーリーを捨てたと言っても、ストーリーが必要ないアニメファンもいたという話で、逆にストーリーを求めてやまないアニメファンもいるはずなのです。
例えば最近なろう系のアニメが人気ですが、これも日常系アニメへの反動なのかもしれません。

（蛇足ですが、vTuberにはストーリーは無いとしてますが、実際にはストーリーが用意されてたりもします。例えば、企業所属のvTuberは最初はLive2Dモデルですが、人気が出てくると3Dモデルが用意され、お披露目配信されて、さらに人気が出ると新衣装とそのお披露目配信、最終的にはステージに立って音楽ライブをやる…そういう流れが一種のサクセスストーリーになってます。このストーリーが実現するかはファンの応援次第なのです。）

最近の日常系作品だと、たとえばゆるキャンが流行ってますが、vTuberにキャンプさせるわけには行かないので、こういう風にvTuberには不可能な企画で戦うというのも有効だと思います。

今回の記事では、日常系アニメとvTuberの共通点について着目していますが、逆に、日常系アニメには存在するけど、vTuberには無い要素とかもあります。
例えば、”聖地巡礼”です。らき☆すたやガルパンでは聖地巡礼が盛んになりましたが、vTuberには当然っちゃ当然ですが、聖地はありません。
vTuber側も、逆に日常系アニメを参考にして要素を取り入れてみるのもアリかもしれません。

UE4のマーケットプレイスから、人気の高いアセット（３Ｄモデル系のカテゴリを除く）を抜き出して並べてみました。

【21/04/16追記】この記事を書いた後教わったのですが、マーケットプレイスのアセットを人気順や評価数順でソートできるサイトがありました。↓

https://orbital-market.com/

…つまり最初からこの記事は用済みだった？苦労が水の泡か！？
というわけでみなさんは是非こちらの便利なサイトを参考にしてください。私も参考にします。

FAQ

Ｑ．なにこれは？

Ａ．UE4のマーケットプレイスのアセットの中から、90回以上評価されてる物（2021年4月14日時点で）を人気アセットと見なして、評価数が多い順に並べた記事です。ただしキャラクター、環境、小物、カテゴリのアセットは含んでません。あとEpic公式アセットも含まれません（公式アセットは評価が付けられない）

Ｑ．なんでこんな記事書いたんですか？

Ａ．UE4のマーケットプレイスは残念な事に評価数やスターの数でソートしたり絞り込みができません。一通り定番アセットを把握したかったのに、そんなんじゃ私も困るし、みんなも困ってると思うので、しょうがないから自分で調査してランキングにしました。

Ｑ．なんで３Ｄモデル系のアセットが含まれてないんですか？

Ａ．個人的にはとりあえず３Ｄモデルよりゲームのテンプレートアセットとかを調べたかったからです。３Ｄモデル系のアセットはあまりにも数が多すぎてしんどかったので除外しました。３Ｄモデル系はその内別途記事にするかもしれません。

Ｑ．評価順じゃなくて、スターの高い順にソートしたりしたいんだが？

今回の調査で作成したスプレッドシートがあるので、これを見てよしなにソートとかしてください。

無料アセット編

有料アセット編

注意点

価格表記は端数を切り上げてます。（9.99ドルのアセットは10ドルとして表記）

目視、手作業で調査したので、抜け、漏れ、表記間違いなどあるかもしれません。

それぞれのアセットにコメントを入れてますが、ほとんどは実際に使って試してません。概要欄を見ながらメモ的になんとなく書いたものです。ご了承ください。

経緯

今までUnityばっかり触ってて、UE4は全然触ってませんでしたが、いい加減そろそろUE4も触ってみようかなと思い始めました。

Unityでの経験からいけば、ゲームエンジンを触る時に真っ先にやる事は、ストアの定番アセットにどんなものがあるかを把握しておくことです。

「こんな便利なアセットがあるって先に知ってたら苦労せずに済んだのに…」という事が頻繁に起きがちですからね。

そこでUE4のマーケットプレイスを調べましたが、ソート、絞り込み機能が貧弱すぎてビビりました。人気のアセットを探す事さえできません。

しゃーないので今回こうやって人気のアセットをまとめてみました。

どうやったかというと、全てのアセットを目視で確認してスプレッドシートに手打ちしていきました。努力の結晶や！

人の手で作られたあたたかみのあるデータを堪能してください。

３Ｄモデル系のアセットは数が多すぎてヤバいので今回は断念しましたが、需要がありそうならいつか別記事でやるかもしれません。

ちなみにマーケットプレイスさえ全部チェックすれば世の中のアセットを全部把握したと言えるかというと、そうでもないです。GitHubとかGumroadにもあったりします。ネットは広大だ。

それと、私じゃない別の方が作られた、2019年6月時点での全てのマーケットプレイスアセットの情報がまとまってるスプレッドシートもありますので合わせて参考にしてください。こちらのデータはバカみたいに手作業で作られたものでは無くて、スマートにスクレイピングされたものみたいです。

感想

思ってたより大変な作業になりましたが、人気のアセットを一つずつ調べたおかげで、割とマーケットプレイス定番アセットの全貌が把握できました。

大体、どれもゲーム作るなら必要になりそうなアセットが並びましたね。

UE4でみんなが作りたがるようなゲームジャンルについては一通りゲームテンプレートが用意されている印象です。FPSを作りたければFPS Multiplayer Template 3.0、TPSならTPS Multiplayer PackかThird Person Shooter Kit、アドベンチャーゲームならFirst Person Story Adventure Template（今回のランキングには載ってませんが、3人称視点のThird Person Story Adventure Templateもあります）、ホラーゲームならHorror Engine、サバイバルゲームならEasy Survival RPG v2かSurvival Game Kit V2、カードゲームならCCG Toolkit、ストラテジーならAdvanced Turn Based Tile Toolkit。

よりどりみどりですね。

自分が作りたいゲームジャンルに合わせてテンプレートを買って、それをたたき台にして作っていけば手っ取り早いのではないでしょうか。

流石に評価が多いだけあって、どのアセットも持ってて損しなさそうなものばかりなので、ぶっちゃけ全部買っちゃってもいいんじゃないでしょうか？

まあここに出てる有料アセット全部買っちゃうと2785ドル（30万円くらい）してしまいますが。さすがに高いかな。

セールになった時を狙って買っていきましょう。

でも、UE4マーケットプレイスはウィッシュリスト機能さえありません。残念過ぎますね。

そんなあなたにオススメなのが、こちらのサイトです。↓

https://www.unrealsales.io/

UE4マーケットプレイスのウィッシュリストが作れます。
セールになったらメールで通知飛ばしてくれるので、今回紹介した人気有料アセットを全部ぶち込んでおきましょう。

さて、今回調べた人気アセットを眺めてて思ったのは、一ヶ月だけ無料化してたアセットがかなり多いですね。
つまり、無料化した時期にゲットしたユーザーが沢山いるので、他のアセットに比べて評価数は下駄を履いていると言えますので、そこんとこも考慮に入れてください。無料化してたアセットについてはその旨コメントに書きました。

無料アセットランキングでも、元々有料アセットだったのが永久無料コンテンツ化したものが多いですね。つまり、Epicは人気のあるアセットはどんどん無料化しようという方針みたいです。

まあありがたいんですが、それがまた、人気の有料アセットをホイホイ買うのを躊躇してしまうポイントでもあるんですよね…買ったアセットが後から無料化したらダメージでかい…。

今回は何も考えずに評価90以上のアセットを人気アセットとしましたが、登場したばかりの新しいアセットは評価数が稼げなくて不利という点にも注意してください。

とにかく、この記事が誰かのお役に立てば幸いです。

DMMブックスが空前の全作品7割引キャンペーン

散々バズッてたのでご存知の人が多いと思いますが、この前DMMブックスで、「初回購入の方のみ、全作品7割引！100冊まで」というキャンペーンが行われていました。

知らなかった人は記事を書くのが遅れてすいません。キャンペーン期間中はどの本を買おうか考えるのに精いっぱいで記事どころじゃなかった。

私は最終的に95冊くらい買ってしまいました。どんな本を買ったのかというとこんな感じ。

総額175,364円が7割引きで52,609円も払ってしまいました。

こんなに積み本増やしてどうするの？と思われるかもしれませんが、今回のキャンペーンの醍醐味は、買った本を読むかどうかはともかく、どの本を買うべきか考えるのが一種のパズルみたいでたのしかったと思います。

普通のkindleでのセールなどと違って今回のキャンペーンの特殊なポイントは、
・ストア内の全ての本が7割引きで買える
・ただし初回購入だけなので、まとめて買う必要がある。
・100冊が上限
という事です。

このような条件があるので、例えば漫画を買おうと思っても、「読んだことなくて面白いか分からない漫画をまとめて全巻買っちゃうのはちょっと…。しかし、中途半端な巻数を買って残りを定価で買い直すハメになるのも…」みたいなジレンマが生じます。

さらに、DMMで本を買い込んでしまうと、買った電書がKindleなどの複数アプリに分散してしまい、管理がやや面倒になるという問題もあります。

そして、Kindle端末ではKindleの本しか読めませんから、DMMで活字本を買ってもPCやスマホ、iPadで読むハメになるという話もあります。（私はKindle端末を持ってませんが、次にセール来たら買うつもりでした）
だから活字本は避けるべきか？

そんな感じで色々と悩ましいのですが、しかし7割引は爆アドなので、アレコレ悩むのがたのしくもあります。

そもそも紙の本と電子書籍にそれぞれメリット、デメリットがありますよね。

紙の本のメリットは、
・読みやすい（紙の本は人間が読むデバイスとして優れている。ページをめくるのがインターフェースとして直感的。今全体のどの辺を読んでるのか分かりやすい）
・電池切れたりしない
・真の意味で所有できる。つまり、譲渡や売買ができるし、勝手に没収されたりしない（電子書籍は譲渡も売買もできないので、所有しているとは言えない。もしストアがサービス終了したら全部ロストしてしまうかも）
・電子書籍はストアプラットフォームごとにアプリが分散してウザい。各社のアプリのダメな仕様に苦しめられるハメになったりする。

電子書籍のメリットは、
・どんだけ読んでもボロボロになったり破れたりしない
・文字をでっかく表示できるから将来視力が落ちても読めそう
・場所を取らない（たとえば紙の本の本棚が部屋にあると、その本棚のスペース分も毎月家賃コストを払うハメになっている）
・マーカーを付けられる。マーカーを付けた個所はリスト化されて一覧にできる
・全文検索できる
・PCやスマホなど、大抵のデバイスで見れる。紙の本より軽い端末で読める
・いつでもどこでも見れる
・一つの端末に大量の本が入れられる

色々な違いはあるものの、個人的には好きな漫画とかは紙の本で欲しいと思ってます。
紙の漫画って、半分くらいはファングッズ的な意味合いがありますね。持ってるだけで嬉しい。電書だと純粋な情報だけなので、持ってる事の満足感がまったく無いですね。

だから、個人的には電子書籍は紙の本の半分くらいの価値かな～というイメージです。

ついでに言えば、KindleはAmazonのプラットフォームなので、10年や20年ではサービス終了しなさそうな安心感がなんとなくありますが、他のプラットフォームは有象無象という感じで、いずれサービス終了しちゃったら購入した電子書籍が全ロスしてしまうんじゃないか？という不安があります。

諸々を全部考慮すると、
・DMMブックスはKindleよりサービス継続の信頼性が分からないので、決定版、保存版みたいな本の買い方はできなそう。ほどほどにいつでも読み返したいような本を買うのが良さそう。つまり、技術書とか事典、辞書、図書館で借りて一度読んだけどまた読み返したい実用書などがいいのでは。
・なんとなく読みたいな～と思ってたものの、買えてなかった漫画を買うと良さそう
・どうせKindle端末で読めないなら、Kindle端末で読んでも意味無い物、例えばフルカラーの本とかを買っておけばディスアドバンテージは無い。
・最近、なつかしいコミックボンボンの漫画が色々復刻されてて、欲しいとは思ってたものの定価で買うのは悩ましい

まあこのような答えになってくるわけです。そうして最終的に選んだのが上記の結果でした。

twitterで検索すると、みんなそれぞれ自分が選んだ本を公開してくれてる人が多くて、参考になりました。
一種の祭りとして盛り上がってましたね。

7割引クーポンの期限は１週間だったのですが、私はその一週間、ああでもないこうでもないと散々悩んだ挙句、何か買い忘れてる気がする…と思ってわざわざ南船橋のららぽーとにあるジュンク堂書店とヴィレヴァンまで赴きました。

私は生まれてこの方、ケチな性分ですから、いつもは本当にどうしても必要な物しか買えません。
何かを買った時に、買った嬉しさはあるものの、お金を失ったつらさも同じくらいあるという感じです。
だからジュンク堂に行ったところで、「こんなに一杯本が売ってるけど、どーせ自分には買えない」みたいな気分なのが普通でした。

しかし、この時ばかりは「自分は今、この本屋にある本は何だって好きなだけいくらでも買えるんだぞ」という万能感に浸る事が出来ました。（とは言えDMMブックスはジュンク堂ほど品揃えは良くないですが）

実際に本を読むためにというよりも、このような生まれて初めてともいえるような感覚に浸るためにお金を払ったとさえ言っても過言ではないでしょう。

ジュンク堂の書店の棚を一つずつじっくり見て回りましたが、そうしてみると読んでみたいな～と思う本を色々と発見できました。最近は本屋をじっくり回ったりしてなかったので、新鮮でした。

そんな事をしてたせいで購入冊数が膨らんでしまいましたが…。

なんにせよ、DMMブックさんのキャンペーンのおかげでたのしい経験ができたので感謝です。

twitterで「過去にエッチな漫画を買ってたせいで7割引クーポンをもらえなかった！」というツイートしてる人を多く見かけましたね。
私もそうでしたが、せっかくなのでこの際エッチ漫画と一般書のアカウントは分けておこうと思って別垢を作ってクーポンもらいました。

Likebook P6を買った話

さて、上記でも書いた通り、DMMで電子書籍を買ってもKindle端末で読めない事が問題でした。

私はまだKindle端末を持ってませんでしたが、次のセールの時に買おうと思ってました。

なぜKindle端末にこだわるか？と言うと、Kindle Paperwhiteはディスプレイに電子ペーパーが採用されており、眼が疲れにくいというイメージがありました。
（しかし、Likebook P6を注文した後にググって知りましたが、別に電子ペーパーが液晶より目に優しいというエビデンスはないらしいです。）
電子ペーパーと液晶、眼が疲れるのはどっち？　検眼医「変わらない」

KindleでDMMブックスを読む方法って無いのかな？と調べてみたら、”楽天のKobo端末を改造する”みたいな怪情報が出てきましたが、その他に、電子ペーパーディスプレイのAndroid端末を使うという手がある事を知りました。

電子ペーパーのAndroid端末…そういうのもあるのか。
たしかにAndroidならKindleだろうがDMMだろうが好きなアプリを入れ放題です。

ググってみたところ、電子ペーパーAndroid端末は、BOOXというシリーズと、Likebookというシリーズの２強のようでした。

E-ink（電子ペーパー）タブレットの紹介＆おすすめ

それぞれのシリーズで、6インチ端末、7.8インチ端末、10インチ端末の3種類があるようです。
個人的には6インチ端末一択でした。私は出かける時は可能な限り手ぶらでいたいので、持ち歩くならできるだけ軽い端末がいいからです。布団の中で読むにしても軽い方がいいです。
7.8インチや10インチは重すぎます。それだったらiPadがあるのでそっちで読みます。

大きめの電子ペーパー端末は、ペンで手書きメモを書くという使い方もあるみたいです。（6インチ端末にはペン機能はありません）

6インチに絞ると、BOOX Poke3という端末か、Likebook P6という端末の２択になります。
それぞれの端末について、参考になる詳しいレビュー記事があります。

BOOX Poke3を買いました

電子ペーパー読書端末、Likebook P6を買いました！

価格を比較すると、BOOX Poke3が190ドル+送料30ドルで220ドル（現在のレートで2万4千円くらい）で、Likebook P6はAmazonで15,299円です。

端末の性能的には断然BOOX Poke3の圧勝ですが、残念ながらBOOX Poke3には技適が付いてないようですので選択肢から外れました。
というわけで、Likebook P6一択になったので、これをポチりました。

Kindle Paperwhiteと比較すると、
・Likebook P6は164gで軽め。Kindle PaperwhiteはWifiモデルで182g
・解像度はどちらも300dpi
・Likebookは非防水。Kindleは防水。
・価格はLikebook P6が15,299円、Kindle Paperwhiteは15,980円（広告なし、8GB、wifi）ただしKindleの方は去年のプライムデーに6,000円オフになってた実績があります。
・端末容量はLikebook P6が16GB、Kindleは8GBまたは32GB．さらにLikebookは最大128GBのマイクロSDカードが刺せます。
・Likebook P6はカバーが付属

実際にKindleアプリを入れてみた感想としては、まあボチボチ使えるかな…。といった感じです。
ページ送りで微妙にワンテンポ時間がかかってしまいます。
これは端末の性能不足というよりは、Kindleアプリの問題です。
Kindleアプリはページ送りでページめくりエフェクトとスライドエフェクトを選択できますが、エフェクトを無しにすることができません。（ちなみに端末のボリュームボタンでページ送りできるようにする機能がありますが、ボリュームボタンでのページ送りだとエフェクト無しで切り替えられます。しかしLikebook P6にはボリュームボタンがありません。）
スライドエフェクトのせいで、電子ペーパー端末ではページ送りに時間がかかってしまいます。

レビュー動画を見る限り、Kindle端末の方がややページ送りが速いみたいです。Kindle端末ではページ送りエフェクトがありません。

まあこの辺は汎用機と専用機の差みたいなものでしょう。

DMMアプリの方はページエフェクトを無しにできます。ぶっちゃけKindleアプリより快適に読めます。Amazonはこういう所でDMMに負けていいんでしょうか。
さらに言うとDMMアプリはダウンロードしないで本を読むという選択肢があるので端末容量に余裕が無くても読めたりします（その分通信データが増えてしまうと思いますが）

まあ、どうしてもKindleアプリのページ送りの遅さが気になるなら、Kindleを読むためだけにKindle端末を買い足すという手もあるでしょう。

電子書籍アプリ以外の機能は？というと、ブラウザとかは電子ペーパー端末では快適には使えないみたいですね。使えなくは無いけどモッサリ…な感じです。オマケ程度に考えた方がいいでしょう。

デフォルト設定だと一定時間のスリープで端末電源が自動オフになりますが、自動でオフにならないように設定した方がいいです。いつでもスッと本の続きを読みたいのに、電源を入れ直してKindleアプリを起動し直して…ってやってるとかなり時間がかかって体験が良くないです。

さて、端末を買う前は想定してなかった電子ペーパー端末の嬉しい機能として、壁紙機能があります。
電子ペーパーの面白い特性として、電源無しで画像をずっと表示できる事があります。
Likebook P6では、スリープ時や電源オフ時の壁紙を自由に指定できます。色んな画像からランダムで表示させることもできます。

これは結構面白いです。なにしろ300dpiなので、紙の印刷と同じくらいの精細さがあります。
本を読んでない時はスリープにしてテーブルに立てかけておけば、ちょっとしたフォトスタンドみたいな感じになります。

一方Kindle端末では、壁紙の指定はできずデフォルトの壁紙がランダムに表示される仕様らしいです。
これは残念ですね。なにしろ端末は普段はずっとスリープ状態なわけですから、わけわかんない壁紙より自分の好きな画像が表示されてる方が断然うれしいですよね。

さて、Likebook P6について色々紹介しましたが、あとからググって分かりましたが、結局電子ペーパーは液晶より目が疲れないってわけでもないらしいです。じゃあ電子ペーパー端末の長所ってなんかあるの？という話になります。

まあ、液晶より省電力というのはあるでしょう。やはりLikebook P6も、バッテリーは結構長持ちするようです。
それと、電子ペーパーの方が液晶より紙の感じに近くて、気分が上がる…そういう感じはします。まあ気分の問題ですが。

そんなわけで、私と同じように、「DMMブックスのキャンペーンで電子書籍を買い込んじゃったけど、どうせなら電子ペーパー端末で読みたい」って方にはLikebook P6は有力な選択肢になると思います。
（ちなみに漫画は読めるけどやや画面が小さい感じ。活字本も固定レイアウトの本だと画面サイズ的に読むのがキビしいと思いますので注意）

前置き

UnityやUnreal Engine4などのゲームエンジンの人気の秘訣は開発者コミュニティにあると言われています。

それまではToB向けのゲームエンジンが多く、使い方を知るにはドキュメントだけが頼りで、分かんない事があったらイチイチサポートに連絡するしかなかったようです。

UnityやUnreal Engine4はタダだったり低価格だったりして、個人開発者でも利用できるものだったので、沢山の開発者がフォーラムやブログで情報提供し合って、ググれば大抵の情報は出てきて助かる感じになりました。
UnityやUE4などのゲームエンジンにとって、開発者コミュニティは最大の資産です。

正直言って、ゲームエンジンを触るにあたっては、プログラミング能力とか以上にコミュニティ情報へのアクセス能力の方が重要じゃないかとさえ思ってます。
というのも、コミュニティにアクセスしない人は、何かトラブッたり、新機能が必要になると全部自分で解決しないといけないですが、コミュニティを深堀りすれば、大抵の問題はすでに誰かが解決法が見つけてくれてたり、アセットやGitHubで必要な機能が作られてたりするからです。

そんな感じで情報へのアクセスが重要なのは分かりましたが、とは言えフォーラムやらは大抵”英語”でやり取りされてます。最近は日本語の情報も多くなってきましたが、結局深堀りすると英語情報に行きあたってしまいます。

しかし、英語が分からない人はフォーラムの文章が読めません。

「残念だけど諦めるしかないか…」

いえ、諦める必要はありません！

我々にはGoogle翻訳やDeepL翻訳などの翻訳テクノロジーがあります！
しかも、無料で使えます！

昔はYahoo翻訳とかはちょっと意味が取りずらい微妙な翻訳でしたが、最近はディープラーニング技術の発達で、メチャメチャ読みやすい日本語に翻訳してくれるようになりました！

私自身、英語は書くのも読むのもサーパリですが、それらの翻訳テクノロジーを駆使して言語の壁を乗り越えてきました。

そこで今回の記事では、Google翻訳などの翻訳テクノロジーを駆使して、まったく英語がチンプンカンプンな人でも様々な英語情報にアクセスできる攻略法を色々書いてみたいと思います。

１．英語のニュース記事、ブログ記事、フォーラム、あるいはGitHubのリードミーなどのWebページを読みたい

大抵のWeb上の英語情報はこの方法で攻略できます。

まず、使用するブラウザはChromeを使ってください。WindowsだろうがMacだろうがiOSだろうがAndroidだろうが…AndroidはデフォルトでChromeですが。
何故ならChromeならブラウザ自体にGoogle翻訳機能が内蔵されてるからです。

Chromeのブラウザで英語のWebページを開くと、画面右上にこんなウインドウが表示されます。

この”英語”のタブを”日本語”に切り替えると、ページが日本語に翻訳されます。

翻訳した日本語を原文に戻したい時は、アドレスバーのGoogle翻訳アイコンをクリックするともう一度翻訳ウインドウが表示されます。

「英語を常に翻訳」というチェックボックスもありますが、常に翻訳されてもそれはそれで困るので、チェックを入れるのはオススメしません。

スマホのChromeの場合は画面の下に同じようなのが表示されます。

ChromeからYoutubeを開いて外国の動画とかを見てると、画面のUIとかは日本語で表示されますが、コメントは全部英語です。この場合、日本語のページと判断されて翻訳ウインドウが出てこなかったりします。
でも、コメントを日本語で読みたかったりします。

その場合は手動で翻訳できます。

Webページ上で右クリックすると「日本語で翻訳」というメニューがあるので、ここから強制的にページを翻訳できます。

注意点

Google翻訳は結構読みやすい翻訳にしてくれますが、翻訳の”クセ”のようなものがあります。
時々、文章をまったく逆の意味に翻訳してしまうというものです。
本来「～である」という文章を、なぜか「～でない」とかにしてしまう事があります。
このクセがある事を頭に入れておいて、なんか言ってる事が変だったら文脈から判断してください。

重要な情報だから正しい意味が取れないと困る！という場合は、Google翻訳を使わずにDeepL翻訳を使ってみる方法があります。
原文の英語をコピペして、DeepL翻訳で翻訳します。

https://www.deepl.com/ja/translator

DeepL翻訳は翻訳がかなり正確なので便利ですが、Webページをそのまま翻訳できないのが不便です。

また、ChromeのWebページ翻訳には文字数制限がありませんが、DeepL翻訳は5000文字までの制限があります。（有料プランだと文字数制限は無くなります）

２．英語のYoutube動画を観たい

ゲームエンジン関係のカンファレンス動画や、アセットのチュートリアル動画が英語だったりします。

Youtube動画なら、機械翻訳された日本語字幕を表示する事が出来ます。

まず、動画右下の歯車アイコンをクリックすると、「字幕」というメニューが出てきます。字幕メニューが表示されない動画は残念ながら翻訳できません。

↓「字幕」メニューを選択するとこうなります。この時点で「日本語」が選べるなら、それは公式で日本語字幕が用意されているという事です。ありがたくそれを選択しましょう。
それ以外の場合は、一旦「英語（自動生成）」を選択します。

↓すると、音声認識で作られた英語字幕が表示されます。
次に、この英語字幕をさらに日本語に翻訳してもらいます。

↓もう一度、歯車アイコン→字幕を選ぶと、先ほどは無かった「自動翻訳」というメニューが選べますので、これをクリックします。

↓翻訳する言語が選べますが、スクロールした一番下に日本語がありますので、それを選びます。（マウスの中ボタンをクリックしてからマウスを下に動かすと高速スクロールできる）

これで、日本語の字幕が表示されます。

なにしろ自動で音声認識した英語をさらに日本語に翻訳してるので、翻訳の精度はかなり怪しいですが、これでも無いよりはありがたいです。

ちなみに、翻訳機能が使えない動画や、Vimeo動画とかの時はどうすりゃいいの？というと、
パソコンの録音デバイスを”ステレオミキサー”にした上で、Google翻訳ページの”音声入力による翻訳”を開いた状態で、翻訳したい動画を再生すれば文字起こし可能なはずです。（すいませんが自分で試した事ありません）

参考：【Windows 10】音声ファイルから無料で文字起こしする方法

３．Discordの英語情報を読みたい

最近は、UnityのアセットストアやUE4のマーケットプレイスで売ってるアセットのサポートがDiscord上で行われる事が多くなりました。
つまり、Discord上の英語情報にアクセスする事が重要になってきました。

というわけで、Discordの英語を読む方法ですが、まず、アプリ版のDiscordだとページ翻訳機能が使えないので、Chrome内でDiscordを開いてください。

Discordでも今までと同様にWebページ翻訳を使えばいいじゃん。と思いきや、ページ翻訳ウインドウが表示されません。
しかも、ページ上を右クリックしても「日本語で翻訳」が選べません。

どうすればいいのか？というと、いっその事Discordの言語設定を日本語→英語にしちゃうという方法があります。

こうする事で、Discordでも翻訳ウインドウが表示されて翻訳できるようになります。

しかし、チャットのタイムラインを上に遡っていくと、翻訳されない英語のままのチャットが出てきます。
この場合、どうすればいいかというと、アドレスバーの翻訳アイコンをクリックして、一旦日本語から原文に戻して、もう一度日本語に翻訳させれば英語のままだった部分もちゃんと日本語に翻訳されます。

ちなみにSlackの英語もDiscordと同じ感じで読めます。Slackは画面上の右クリから「日本語に翻訳」が選べるので簡単です。

４．英語のWordファイル、パワポファイル、エクセルファイルを読みたい

英語で書かれたOfficeのファイルを翻訳して読みたい場合、Google翻訳からできます。

https://translate.google.co.jp/?hl=ja&sl=en&tl=ja&op=docs

ファイルをアップロードすると翻訳されて表示されます。

理論上、Googleからはファイルの中身が見えてしまうので、機密情報や個人情報が含まれてるファイルの場合は注意した方がよいかもしれません。

DeepL翻訳からもWordまたはパワポファイルの翻訳が可能です。

文字数が多すぎるファイルだと翻訳できないかもしれません。その場合、ファイルの中身を分割して保存するなどの工夫が必要になります。

５．英語のGoogleスライド、Googleスプレッドシートファイルを読みたい

一旦、Googleスライドはパワポの形式で、スプレッドシートはエクセルの形式でダウンロードしてから、Google翻訳ページで翻訳できます。

６．英語のGoogleドキュメントを読みたい

Googleドキュメントはメニューから翻訳できます。

これを使うと翻訳されたドキュメントのコピーが作成されます。
文字数が多すぎると翻訳に失敗します。ドキュメントを分割するなどの工夫が必要です。

あるいは、裏技として、画面左上のこのアイコン上で右クリックしたときだけ「日本語で翻訳」が選べます。これは文字数に関係なく翻訳して読めます。↓

しかし、この方法で翻訳するとメチャクチャな日本語になっちゃうのでオススメしません。

７．英語のpdfファイルを読みたい

アセットのマニュアルがpdfファイルのパターンが多いので、何とかしてこれも翻訳して読みたいです。

まず、翻訳したいpdfファイルをGoogleドライブにアップロードします。

アップしたpdfを右クリック→アプリで開く→Googleドキュメントを選択すると、pdfファイルをGoogleドキュメントに変換できます。

あとは上述したGoogleドキュメントの翻訳方法を使えば日本語で読めます。

８．英語のテキストファイル（.txt）を読みたい

まあ、テキストファイルなら普通にGoogle翻訳のページにペーストして翻訳すればいいんですが、文字数が多いと途中までしか翻訳されなかったりします。

実は、テキストファイルをChromeのウインドウにドロップして「ページを翻訳」すれば、文字数無制限で翻訳できます。

９．ソースコードの英語コメントを読みたい

アセットのソースコードを見てると、当たり前ですが大抵英語でコメントが書かれてます。

これを日本語で読む方法は、以前に記事に書いたのでそちらを参考にしてください。
（WindowsのVisual Studioのみ対応）

英語のコメントを日本語に翻訳するVisualStudio2017拡張を公開しました

英語のコメントを日本語に翻訳するVisualStudio拡張が動作しなくなってたので何とかした

１０．自作アプリの外国語ローカライズデータを作成したい。

GoogleスプレッドシートとGoogle Apps Scriptを活用して翻訳ローカライズデータを作成する方法については、以前に記事を書いたのでそちらを参考にしてください。

Googleスプレッドシートでアプリの翻訳用データを作る

１１．英語のフォーラムやDiscordに書き込みたい。あるいは英語のメールを出したい

今までは英語情報を読む方法について書いてきましたが、結局のところ、買ったアセットが上手く動かないみたいな事になったら、フォーラムやDiscord、あるいはメールで英語を書いて問い合わせする必要があります。

どうやって英語を書けばいいのか？というと、やっぱりGoogle翻訳やDeepL翻訳に頼ります。

まず日本語で文章を書いて、翻訳すれば英語になります。（当たり前）

それだけの話ならわざわざ解説するまでも無いですが、ここで気になるのが、ちゃんと正しく英語に翻訳されてるんだろうか？という事です。

簡単に確認する方法として、翻訳された英語を再び日本語に訳してみる方法があります。
真ん中の「言語を入れ替え」アイコンをクリックすると、日本語に再翻訳されます。

ここで再翻訳された英語が元々の日本語の意味と全然違う場合は修正する必要があります。

ある程度英語ができる人なら、英語の文章を修正して何とかします。

英語がサーパリな人は、元々の日本語の言い回しを変えてみて試してみましょう。

ややこしい言い回しを使うと正しく翻訳される可能性が低くなりますので、なるべく平易な日本語で書く方がいいです。

書き込む時にどうしても自信がない時は、「Google翻訳を使いました」って書いちゃえば、多少文章がおかしくなってても相手も気を使ってくれるかもしれません。

おわり

というわけで、今回の記事では主にゲームエンジンのユーザー向けに、英語がサーパリ分からなくても翻訳テクノロジーを駆使して様々な英語の情報にアクセスする方法について書いてみました。

GoogleやDeepL翻訳が誰にでも無料で最新の翻訳テクノロジーを使わせてくれるおかげで、Web上の英語情報へのアクセスは極めて容易になってきました。ありがとうGoogle。

「ここまでアレコレ工夫して努力するヒマがあったら、そもそも英語の勉強を頑張った方が早いんじゃねえか？」という意見もあるかもしれません。
まあそれも一理ありますね。
いくら翻訳テクノロジーの恩恵で英語情報へのアクセスが容易になったとしても、結局のところ、英語圏の人と直接会話する事はできません。（今のところは）
英会話を学んだ人なら会話もできるのでアドです。

しかし、翻訳テクノロジーにも、それはそれでアドバンテージがあります。
まず、英語を勉強しても、英語に触れないでいる時間が多くなるとどんどん忘れていくので、常に勉強し続けるハメになりますが、翻訳テクノロジーならな～んも勉強しなくてほったらかしてても、むしろ勝手にどんどん進歩していってくれます。
さらに、英会話だと英語しか喋れませんが、翻訳テクノロジーなら英語だろうが中国語だろうがフランス語だろうが、同じ方法で簡単に翻訳できます。

便利だなあ。

ちなみに、私が今、翻訳テクノロジーを使いたいのに使えなくて困っているのが、電子書籍です。

例えばKindleの洋書なんかは、テキストデータなんだから技術的にはWebページと同様に全文翻訳して日本語で読むことが可能なはずなのに、実際にはできません。

日本語に翻訳されてない洋書は一杯あるので、これさえできるようになればなあ…と常々思ってます。

最後に注意点ですが、上でも書きましたが、翻訳を使うとサーバーにテキストが送信されてしまいますので、気になる人は機密情報や個人情報の取り扱いには注意してください。

また、この記事のテクニックを使った事で何かトラブルが起きたとしても、責任は負いかねます。
例えば、誤った英語に翻訳されたメールを送信しちゃって相手を怒らせたりしても自己責任です。

結論

今Unityのネットワークマルチゲーム作るならMLAPIよりMirrorの方がいいかも

以前はUnityに完全に騙されてMLAPIを推しちゃってたけど、今はもうそれほど推してない。
騙したUnityが全部悪い。これだけはハッキリと真実を伝えたかった。

前置き

以前、Unityのネットワークマルチの現状について記事を書きました。

この記事は、ありがたい事に結構多くの方に読まれているようです。

しかし、この記事はUnityが書いた「自分のゲームに適したネットコードを選ぼう」という、Unityで使える色々なネットワークライブラリの比較記事の内容を鵜呑みにして書いたものです。

その後、UnityがMLAPIを買収した事で、件のブログ記事がMLAPIアゲしたいがための提灯記事だった疑惑が極めて濃厚になりました。

つまり、インチキ記事だったかもしれないという事です。
とは言え、この時点では疑惑は疑惑に過ぎなかったわけですが、その後、MirrorのDiscordを眺めてるとこのような書き込みを発見しました。

な…なんということでしょう。
このLukeさんという方は、Unityで働いていて、MLAPIのディスコにもよく出現するので、MLAPIチームの人だと思われます。

彼が、Mirrorのディスコで
・我々は別にMLAPIを安定した製品に使用可能なライブラリにするつもりとか無いねん
・今後もMLAPIで色々実験しておもちゃにして遊ぶぜ
・安定したライブラリが要るならMirrorの方がいいよ

ほとんどこういう意味の爆弾発言を投下しました！
う…ウソだろ…？だってUnityは公式ブログで、

”安定してサポートされたネットワークをMLAPIで提供する！”って言ってたじゃねえかよ！
Unity嘘だよな？

あまりに過激な書き込みだったので、ひょっとしてこのLukeさんは本物じゃなくてなりすましなんじゃないかと疑う人もいました。

やっぱり本物らしいです。
ちなみにLukeさんはこんな書き込みもしています。

件の、私が鵜呑みにしてしまったUnityブログのMLAPIアゲ、Mirrorサゲな比較表の内容を修正したコラ画像です。
一体何が起きてるんでしょうか？ふざけているのか？

私は正直言ってLukeさんの書き込みを見て最初怒りを覚えました。
「真面目に仕事しろよ！こっちは真剣にゲーム作ってんだよ！！」

UnityがMLAPIを安定したネットワークライブラリに仕上げる気が無くて、実験して遊びたいだけなら、そんなもん誰だって使いたいわけないですよね。

Unityは今までにUNETの開発をしくじり、DOTS Netcodeの開発もしくじりつつあり、信頼は地の底へと落ちつつあったところに、この追い打ちです。
いい加減にしてくれよ…そう思いますよね。

さらにLukeさんは「こんな書き込みしてるのがバレたらUnityをクビになっちゃうかもな～（爆笑」みたいな投稿もしてます。

これも、最初は世の中ナメとんのか？と思いましたが、冷静に考えてみると、もしかしたらLukeさんは自分のクビを賭けてまで、何か大事な事を我々に内部告発しようとしてくれてるのかもしれません。

何か、Unityの中で非常に良くない状況が発生しているのかもしれない…そんな事を勘ぐってしまう書き込みでした。

さて、つまるところ、これらのLukeさんの告発が本物だった場合、これまであくまで疑惑に過ぎなかった”UnityブログMLAPI提灯記事事件”はクロだと確定したと言えるでしょう。

つまり、Unityの記事のMLAPIの過剰な高評価はウソであり、Mirrorの方が優れている可能性が高い…という事です。

Mirrorについて

Mirrorってなんなの？というと、かいつまんで言うと、有志が開発しているUNETの後継ネットワークライブラリです。

Mirrorの作者のvis2kさんがMirrorの歴史について記事を書いてくれてるので、それを読めば経緯が分かるでしょう。

https://mirror-networking.gitbook.io/docs/trivia/a-history-of-mirror

かなり興味深い事実が色々と書かれてます。

vis2kさんは、昔はUNETの登場に心を躍らせてMMOゲーム開発に夢中になってました。
試しにそのMMOシステムをuMMORPGというゲームテンプレートアセットとして売ってみたら大人気になったそうです。

しかし、ボトルネックになったのはUNETの大量のバグです。
vis2kさん達は、必死でUnityにバグレポートを出したのに、Unityは「仕様です」と返答するだけで、全然修正してくれなかったそうです。（当時はクローズドソースだったのでユーザーは自分でバグを修正できず、途方に暮れるしか無かった）
実はその裏で、UNETのコアメンバーは沈みつつある船から脱出するかのごとく、次々とチームを去っていたのです！当然、修正したくてもできないですね。

そしてとうとう、UNETは放棄されました。
しかし、UNETのHLAPIは突如オープンソース化されたので、vis2kさんはこのHLAPIのバグを修正しまくり始めました。
これが後のMirrorになったと。そういう経緯だったそうです。

「どうしてUNETチームは自分たちでUNETを作れるくらい凄い人達なのに、バグが修正できずにチームから逃げ出すハメになったんだろう？」という事についてもvis2kさんは述べています。
HLAPIのソースを掘っていくと判明した事ですが、実はUNETはNetworkView（UNET以前にUnityに搭載されていたレガシーのネットワーク機能）の上に乗っかって作られていたようです。

NetworkViewはRaknetというサードパーティのライブラリをラップしたものでした。
つまり、Raknetの上にNetworkViewを増築して、さらに３階にUNETを建て増しした…そういうカオスな状態になってしまっていて、恐らくもはや誰にも解読不能なコードだらけになっていただろう事は容易に想像が付きます。

まあそんなわけで、忌まわしいUNETのHLAPIを改造しまくって、やがてLLAPI（トランスポート層）も自作の物にすげ替えて完全に置き換えられた物がMirrorというわけです。

ちなみに、vis2kさんは現在Mirrorの開発に週８０～１００時間を費やしてるそうです。要するに毎日ずっとMirrorを開発してるって事ですね。

Mirrorの長所（MLAPIと比べて）

採用実績

Mirrorには、実際に発売されてるゲームで採用されているという実績があります。

https://mirror-networking.com/showcase/

これが何を意味するのかと言うと、これらのMirror採用ゲームの開発、および運用において、色々とMirrorで起きたバグは報告、修正されているはずという事です。

つまり、Mirrorがそれなりに安定している事は約束されている事を意味します。

一方、MLAPIには事実上、採用事例はありません。

アセットがある

ネットワークライブラリがいくら高機能でも、アセットストアにゲームテンプレートアセットが無いと、ゲームを作り始めるのは面倒です。

現在、Unityアセットストアにあるネットワークマルチができるゲームテンプレートは、殆どPhoton Cloud（PUN）対応の物ばかりです。

https://assetstore.unity.com/packages/templates/packs/mfps-2-0-multiplayer-fps-101171

https://assetstore.unity.com/packages/templates/systems/ufe-bundle-24884

https://assetstore.unity.com/packages/tools/game-toolkits/pun-multiplayer-add-on-for-opsive-character-controllers-148555

PUNはたしかに手軽に他人とネットワークマルチが試せて便利なのですが、秒間メッセージ数の制限があるため、マルチプレイ人数は4～8人で頭打ちになるので、それ以上の人数のバトロワとか作ろうとしても困難です。

とは言え、PUNからPhotonServerに移行すれば秒間メッセージ数の制限は無くなります。しかし、PhotonServerは”サーバを設置する権利”にお金を払うハメになります。これはサーバ代とは別にかかります。MirrorやMLAPIのヘッドレスサーバならそんなコストはかかりません。

PUN以外だと、たま～にMirrorに対応してるアセットもあります。

https://assetstore.unity.com/packages/templates/systems/pirates-of-voxel-play-189096

https://assetstore.unity.com/packages/templates/systems/ummorpg-remastered-159401

https://assetstore.unity.com/packages/templates/systems/ummorpg-2d-remastered-102632

https://assetstore.unity.com/packages/templates/systems/usurvival-95015

https://assetstore.unity.com/packages/templates/systems/umoba-62542

uSurvivalとかuMobaとか、uなんちゃらという名前のアセットがいくつかありますが、これらはMirror作者のvis2kさんが全部開発しています。

まあ、時系列的にはuMMORPGを作っていたvis2kさんがMirrorの開発も始めたって流れですが。
ともあれ、ネットワークライブラリの作者自らがバキバキに最適化してくれているネットワークマルチのゲームテンプレートという事で、相当パフォーマンスが高いようです。

uSurvivalのマニュアルによると、コミュニティのメンバー達の協力で負荷テストを行ったところ、122人の同時参加に成功したそうです。（結構強力なサーバーを借りてサーバにヘッドレスビルドを置いた場合）

さらに、uMMORPGでは480人参加をテストした事があるそうで、その時の動画が上がってます。

uMMORPGやuSurvivalは、個人的にはアセットストアにあるマルチプレイヤーゲームテンプレートで一番実用的なものなんじゃないかと思ってます。

unityで100人以上が接続できるアセットってvis2kさんのもの以外では見つかりません。100人繋がるならuSurvivalをちょっと弄ればバトロワが作れそうですよね。

とはいえ、これらのアセットを実際のゲームで使われた例はあるのか？というと、そういう事例については聞いた事がありません。まあ、ゲーム開発者がテンプレート使ってゲーム作りました。なんてわざわざ言わないってだけかもしれません。

Mirrorはゲームテンプレート以外のアセットでもちょくちょく対応してるアセットがあります。

例えば、Easy Build Systemというゲームで建築機能が実装できるアセットは、UNETもMirrorもPUNも全部対応しています。さらに、uSurvival、uRPG、uMMORPGへの統合も用意されてます。（uSurvivalにもデフォルトで建築機能はありますが、それより高機能です）

https://assetstore.unity.com/packages/templates/systems/easy-build-system-v5-2-5-45394

他にも、Enviroという昼夜、天候制御アセットはUNETとMirrorをサポートしてます。

https://assetstore.unity.com/packages/tools/particles-effects/enviro-sky-and-weather-33963

さて、ではMLAPIは？というと、今のところMLAPIをサポートしているアセットやゲームテンプレートは存在しません。

まぁ…MLAPIは急にUnity公式になって、いきなり出てきた感があるので、もしかすると今後じわじわサポートするアセットが増えるのかもしれませんが、今のところは何もありません。

ですが、４月にUnityはMLAPIの「Boss Room」サンプルを発表しました。

https://blogs.unity3d.com/jp/2021/04/08/enter-the-boss-room-our-new-multiplayer-sample-game/

今まで散々「MLAPIにはロクなサンプルがねえ！なんか用意しろ！」と言われ続けたのに応えた形ですね。結構凝った作りです。MLAPIでゲームを作るならとりあえずこれを叩き台にすればいいのではないでしょうか。

さらに、「Boss Room」と同時期に、MLAPI用のPhotonトランスポートも用意されました。

トランスポートって何？というと、MirrorやMLAPIでは低レベル層のトランスポートレイヤーが何種類も用意されており、例えばudp通信を使うトランスポートやtcpを使うトランスポートなどを容易に差し替える事が出来ます。

PhotonCloudを利用して通信するトランスポートが用意されたという事は、MLAPIでもPUNと同様に無料で簡単にインターネット越しのマルチプレイを試すことができるという事です。

MirrorやMLAPIは、LAN内で簡単に接続できるのが便利でしたが、ネット越しのマルチプレイをしたいと思ったら、今までは素朴なP2Pで繋ぐか、専用サーバを用意するかで手軽ではありませんでした。Photonトランスポートはそこを補ってくれます。
ちなみにPUNの方はネット越しのマルチプレイは簡単にできるものの、逆にLAN内で接続したくても絶対Photonのリレーサーバを経由しないといけないので、インターネットに繋げない環境だとマルチできないという弱点がありました。

という事は、MLAPIはPhotonトランスポートが用意された分だけ、Mirrorより有利じゃないの？と思うかもしれませんが、一応、MirrorにもNobleConnectという便利なものがあります。

NobleConnectの話

NobleConnectってなんじゃ？というと、これです。

https://assetstore.unity.com/packages/tools/network/noble-connect-free-141599

つまり、UNETとMirrorにNATパンチスルーとリレーサーバの機能を追加してくれるソリューションです。これにより、MirrorでもPUNのように無料で簡単にネット越しのマルチプレイが試せます。

先ほども書きましたが、Mirrorでは、専用サーバを使わない場合、インターネット越しにマルチプレイするには、素のP2P接続しか使えません。つまり、ホストがポート開放したりする必要があるという事です。

NATパンチスルーによって、ポート開放みたいな面倒な事をしなくても、ネット越しに接続する事が出来ます。NATパンチスルーでも接続に失敗する場合は、リレーサーバを経由して通信する事で、確実な接続を保証してくれます。

PUNだと絶対にリレーサーバを経由してしまうので、通信が遠回りになってしまいますが、NobleConnectならなるべくP2Pで繋ぐので、遅延が小さくなるというメリットがあります。（ちなみにMirrorはサーバークライアント型なので、クライアント同士は直接接続しませんが、PUNはP2Pネットワーク型なのでクライアントから他のクライアントに直接RPCが打てたりします）

NobleConnectは無料で使用する事ができ、8人まで同時接続できますので、開発中に簡単にマルチプレイを試せます。

気を付けないといけないのは、無料版のNobleConnectにはマッチメイク機能が付いてません。ポート開放は不要なものの、ゲストはホストのIPを直接打ち込んで接続する必要があります。

PUNのように自動でマッチメイクして繋いでほしい時は、15ドルで別売りされてるMatch Upアセットが必要になります。

https://assetstore.unity.com/packages/tools/network/match-up-104411

ちなみに、88ドルで売っているNobleConnect有料版を買うと、Match Upアセットも付属しています。そして、100人まで同接できるようになります。（５年間）

https://assetstore.unity.com/packages/tools/network/noble-connect-140535

もし、同接人数が100人以上必要な場合は、NobleConnectの公式サイトから月額プランを契約する事になります。大体、価格の相場はPUNの半額くらいです。例えば1000人だと月160ドルです。何故PUNより安いか？というと、PUNが必ずリレーサーバを経由するのに対して、NobleConnectは大抵の場合はP2Pで接続されるので、たまにリレーサーバを経由する時以外はサーバに負荷がかからないからです。つまり、リレーサーバを経由しないでP2Pで繋いだ接続も同接制限にカウントされちゃうという事でもあります。

https://noblewhale.com/

さて、こうしてみると、MLAPIはPhotonトランスポートによって、MirrorはNobleConnectによって、ネット越しにP2Pで繋ぐのが容易になりました。
という事は、専用サーバ構成やLAN内通信ができる分だけ、MLAPIもMirrorもPUNの上位互換と化していると言えるかもしれませんね。
ただし、Photonトランスポートは恐らくPUNの秒間メッセージ制限を引き継いでると思うので、厳密にはMirrorが優勢かもしれません。

MLAPIの行方

MLAPIの作者はTwoTenさんです。
TwoTenさんは現在20歳です。MLAPIを作り始めた時は16歳の高校生の頃だったとどこかで読んだ気がします。そんな若さでネットワークライブラリを開発してしまうって天才なんでしょうか。

TwoTenさんは2019年にMirrorをボコボコに批判したブログ記事を書いて、その後消してます。

MirrorはいまだにUNETの悪い所を引き継いでしまってるのが良くないそうです。MLAPIは完全にゼロベースで書かれてるそうです。

まあ、TwoTenさんのMirror叩きが妥当なのかはさておき、少なくともMirrorにはアセットがあり、コミュニティがあり、確かな採用事例があります。それに対してMLAPIはUnityから買収されるまでほとんど誰も使ってなかったようです。私から確認できる事実はそういう事です。

私はMLAPIがUnity公式のネットワークソリューションに採用された時、「これでUnityに安心して使えるネットワークソリューションができた！」と大喜びして記事まで書いてしまいましたが、その後にLukeさんのディスコ投稿やvis2kさんによるMirrorの歴史を知ってしまった今、まったく手放しでは喜べません。

Unityのネットワークの歴史を振り返ってみてください。

最初のNetworkViewはRaknetをラップしたもので、これはいい感じに動いていました。

それから新しくUNETを作るぞ！とUnityは張り切ってましたが、結局これは、中身はNetworkViewを魔改造したコードで、色んな人が代わる代わるコードを引き継いでいる内に、誰にも手が付けられない違法建築コードが爆誕して、まったくバグ修正もままならない状態になり、コアメンバーが全員泥船から逃げ出して、挙句の果てに放棄された。それが実情だったと判明しました。

お次にUnityはDOTSこそがUnityの未来だ！とか言い出して、DOTSベースのNetcodeをゼロから開発し始めました。UnityはDOTS Netcodeが2021年のQ2に製品品質でリリースされます！と主張していました。

https://blogs.unity3d.com/jp/2019/06/13/navigating-unitys-multiplayer-netcode-transition/

今現在、すでに2021年Q2に突入していますが、DOTS Netcodeがリリースされる気配は全くありません。それどころか、ECSはパッケージマネージャから非表示にされて、隠されてしまいました。

一部では、ECSは完全にポシャりつつあるという見方が有力であるとも言われています。

Unityは最初のNetworkViewはRaknetのラッパーだし、UNETは弄りまわしてグチャグチャにしちゃった挙句放棄。DOTS Netcodeはあれほど宣伝してたのに結局うまく行かなくて盛大にポシャりつつある疑惑…

お気づきの通り、ハッキリ言ってUnityは自力でちゃんとネットワークライブラリを完成させたことはありません！

というか、Unityのやってる事全部メチャクチャだよ！これが上場企業の仕事なのか！？

DOTS Netcodeが約束の期限に全然間に合わない事に気付いたUnityは、慌ててTwoTenさんのMLAPIを買収してUnity公式のネットワークソリューションとしてでっち上げました。

そんな事したってまだ当分MLAPIは実験段階だし、結局2021年Q2に製品に使えるネットワークが提供されてない事実は変わらないんだよなあ…

UnityはどうしてMirrorじゃなくMLAPIを買収したのか？という話がありますが、もしかするとUnityの中でUNET放棄事件がよっぽどトラウマになっていて、まだUNETの負の遺産が残ってるMirrorより、ゼロベースで書き直されてるMLAPIの方が魅力的に見えたのかもしれません。

しかし、いくらTwoTenさんが天才だとは言え、所詮は高校生の趣味のプロジェクトだったMLAPIをいきなり公式ソリューションに祀り上げるとは…よっぽどUnityは切羽詰まってたんでしょうか。自力でネットワークライブラリ開発する能力ありませんって白状してるようなものでは…。

Unityは現在、買収したMLAPIをベースに色々と足りない機能を実装しまくっているようです。

この先、MLAPIはどんどん良くなっていくのでしょうか？以前は私もそのように楽観視してましたが、これまでのUnityの所業を振り返ると、これまでと同様に弄くり回して遊んでダメにしちゃってポイ…なんてことになる可能性も低くないのでは…。

Lukeさんのディスコ投稿の「MLAPIをおもちゃにして実験して遊ぶぞ～」的な発言も不安を煽られます。

かなりUnityの事を悪しざまに言ってしまいましたが、Unityはこれまでの失敗の反省を生かして、MLAPIの開発にRFCプロセスという手法を取り入れたりしてます。

https://github.com/Unity-Technologies/com.unity.multiplayer.rfcs

これは、民主的なプロセスを通して開発を進めていく仕組みです。

MLAPIに新機能が欲しい人は、まず仕様書を書いてコミットします。それからその仕様書について、Discord上であーだこーだ議論します。議論した結果、採用だとジャッジされたら初めてその仕様を実装するという流れです。

このような仕組みを取り入れる事で、UNETの時のような開発の完全崩壊を防ごうという意図だと思います。

結局MirrorとMLAPIどっちがいいの？

さて、色々とMirrorとMLAPIの事情を深堀りしてましたが、「で？結局どっちがいいの？」と言われると、どうなんでしょうね。

「エンジニアだったらくだらねーことウダウダ言ってるヒマあったら実際に負荷テストしてパフォーマンス比較とかしてみりゃいいじゃねえか！」と思う人もいるかもしれませんが、すいませんが正直そこまでやるのは気乗りしないんですよね…。

何故なら、私が今推してるのは、MirrorでもMLAPIでもなく、UE4だからです。

この際ハッキリ言っておきますが、私のような単にネットワークマルチのゲームをサクッと作りたいだけのユーザーが、こんな風にMirrorやらMLAPIやらのDiscordを深堀りしてお互いの事情を調べ上げて、そこまでして初めてどのネットワークライブラリを採用するのか安牌か、高度な政治的判断をようやく下せる…そんな事するハメになるゲームエンジンって、異常ですよ。

何でネットワークライブラリが群雄割拠してんだよ！結局、決定版のライブラリが存在しないからそうなっちゃうんですよね。

そんな風にずーっとネットワーク戦国時代でバベルの塔状態でユーザーに混乱を与え続けてるUnityに比べて、UE4はデフォルトのネットワークひとつで事足りてます！
デフォルトのネットワークが決定版だからです。

そもそも、EpicはUE4のネットワークを使ってフォトナを開発したわけですからね。当然、UE4のネットワークは堅牢で安定していて、高機能なのは当たり前です。
そのおかげで、非常に多くのUE4のゲームで採用されており、マーケットプレイスのアセットもかなり多くがネットワークに対応しており、大きなコミュニティも存在します。
Unityの情報やらなにやらバラッバラに散らばってるネットワーク機能とは大違いです。

多人数マルチが当たり前になっていくであろうこれからの時代、一体どのネットワークライブラリを採用すればいいんだ…なんて不毛な事に悩んでるヒマがあったら、ネットワークが貧弱なUnityから堅牢なUE4に乗り換えるべき…そんな風に思ってますね。

Unityはこの先永遠にネットワーク機能で混乱し続けてそうだよな…別にネットワークマルチを作らないなら全然いいんですが。

じゃあそもそも何でこんな記事を書いたんだよ！と言うと、個人開発はUE4に移行するでいいとしても、仕事での開発は、様々な事情が絡んで、そう簡単にはUnityからUE4なんて移行できなかったりするので、やっぱりしばらくはUnityでのネットワーク機能をどうするかも悩む必要がありそうです。

本気で製品としてネットワークマルチのゲームを開発するなら、混乱しているUnityのネットワーク使って後でトラブルの山を抱えるより、堅牢なネットワークのUE4に移行しちゃった方が結果的に安くつくんじゃないかと思うけどな…。

そういえば、「Unityのネットワークはひどい！バトロワとか作れない！」とか文句を言うと、Unityは「でもFall GuysはUnityでネットワークマルチ60人対戦を実現してるもんね！」って反論してくるのが常態化してましたよね。

Unityは相当Fall Guysの事を誇りに思ってたらしく、ブログやPVで紹介しまくって自慢しまくってました。

そんでそのFall Guysを開発したMediatonicはどうなったかと言うと、UE4のEpicに買収されちゃったというオチが付くわけですが。

まあ、最近のUnityのネットワーク事情を象徴してるような出来事だと思います。

オマケ：Epic Online Servicesがアツい

先ほど、Mirrorでネット越しのマルチプレイを実現するのに、NobleConnectが利用できるという話をしました。しかし、NobleConnectは同接数を増やそうとすると、高額な料金プランを契約する必要があります。

私が今注目しているのは、Epic Online Services（EOS）です。

実は、EOSではNobleConnectが提供してるようなNATパンチスルーやリレーサーバが完全無料で提供されています！

タダは嬉しいですよね。

以前の記事で、SteamP2Pも無料のリレーサーバが使えるという話を書きましたが、SteamP2Pの弱点は、Steamじゃないと動作しない事です。つまり、スマホアプリでは使えないし、Steam以外のストアからのアプリでは使えません。

EOSが凄いのは、そのような縛りも一切なく、どんなストアでも、マルチプラットフォームで動作するとの事です。

EOSはEpicのサービスですが、UE4だけじゃなくて、Unityからも使用する事が可能です。

実際、Mirror向けのEOSトランスポートが用意されてます。

https://github.com/FakeByte/EpicOnlineTransport

私も機会があればぜひ試してみたいと思ってます。

UE5のアーリーアクセスが出たぞ！！！！

正直言って、去年に初めてUE5の情報が出た時は「はあ？本当かよ…？」みたいに思ってました。

だって、「無限にポリゴン描画できま～す！」とか、なに頭悪い事言ってんだとしか普通思えないですよ。

「そんな魔法みたいな事が可能だったらみんなとっくにやっとるわい！！！！」という話に尽きます。

完全に半信半疑だったのが、アーリーアクセスで実際に出てきてみたら、Naniteでおおむね宣伝通りに”本当に魔法が実現されていました”。

どうせ誇大宣伝だろと思ってた私はそこで初めてブッたまげたわけですよ。

だって、いくらEpicが凄いって言っても、所詮はゲーム屋です。
普通はゲームエンジンに搭載されるテクノロジーなんて、とっくの昔に研究者がシーグラフで発表した論文の中から目ぼしい枯れたテクノロジーが随分かかってから実装されるみたいなのがせいぜいでした。
所詮はゲーム開発者がガチのCG研究してる人に技術発明で勝てるわけない。そういう空気だったと思います。

だから、EpicがUE5でNaniteとかいう魔法のテクノロジーをいきなり製品レベルで搭載してきたのは常識を覆す事態ではないでしょうか。
これはEpicの技術開発レベルが完全に最先端レベルに到達してしまってる可能性を示唆しています。
ぶっちぎりという事です。
いくらNaniteが魔法のテクノロジーとはいえ、UE5のソースコードは全て開示されてる訳なので、Unityなどの競合ゲームエンジンがパクろうと思えば今からパクれると思います。
しかし、Epicの進歩の速度がぶっちぎりになっているんだとしたら、Unityが必死こいてNaniteをパクり終えるころにはEpicは遥か先を行ってしまってるという事態にもなりかねません。
Epicと競合他社との技術格差はこの先広がっていく一方で、決して縮まる事は無いんじゃないか…そんな事まで予感させるほどにUE5はすごいです。

UE5はNaniteだけじゃなく、完全動的GIを実現するLumenもめちゃめちゃ凄いです。
Lumenさえあれば、もうライトマップなんて一切ベイクする必要無し！美麗な間接光が完全リアルタイムで描画できます。素晴らしい。
ただし、Lumenの方は魔法のような見た事もないテクノロジー…というわけでも無さそうです。

そもそもUE4はボクセルコーントレーシングというLumenみたいな完全動的GI技術が搭載される予定でした。
しかし、結局当時のハードウェア性能ではやっぱりキビしいという判断で見送られていたわけです。
UE5でLumenが搭載されたのは、いよいよハードウェア性能が追い付いたという事でしょう。

たとえばCryEngineにはとっくにSVOGIという完全動的GI機能がありました。

https://simonmajar.com/blog/mNG8/the-need-for-lumen

GodotEngineにもSDFGIというのがあります。

https://godotengine.org/article/godot-40-gets-sdf-based-real-time-global-illumination

ちなみにUnityはEnlightenによるレガシーなリアルタイム？GIしかありません。気の毒ですね。

https://forum.unity.com/threads/update-on-global-illumination-2021.1067015/

↑Unityは2021.1で画期的な動的GIを実装すると約束してましたが、まあいつも通り失敗してしまい（特に驚きはない）、苦肉の策として、非推奨にしてたEnlightenを復活させるそうです。お笑いですね。

UE5はアドしか感じない

私がここで言っておきたいのは、「現在UE5を快適に動かせるようなPCを持ってる人は選ばれた人間」であるという事です。

UE5の「古代の谷」というサンプルデモの推奨実行スペックを見てみましょう。

相当なハイスペックが要求されてますね。
CPUは12コア以上が必須。
メモリは最小32GB～推奨64GB。
グラボはおおむねVRAM8GB以上積んでるようなヤツが要求されてます。

推奨スペックだとフル解像度で実行できますが、最小スペックだと解像度半分にしないとつらいみたいですね。（ちなみにUE5にはTemporal Super Resolutionという超解像技術が搭載されてるので解像度半分でも綺麗に描画されるかも）

ちなみにですが、私のPCのスペックは、
CPU：Ryzen3950X (3.5～4.7GHz 16コア/32スレッド)
メモリ：64GB
グラボ：GTX1080（VRAM8GB）
ストレージ：SSD 1TB NVMe PCI-Express4.0
　　　　　　HDD 10TB

こんな感じです。去年にPCをアプグレした話も記事に書いてます。

さらに余談ですが戌神ころね氏はRyzen5950XとRTX3090を積んでるそうです。

さて、こんなハイスペＰＣを持ってる人って世の中にどれくらいいるんでしょうか？

そもそも論として、PCを保有してない世帯が日本では３割くらいいるそうです。PCが無ければUE5どうこう以前の問題です。ここで３割の人が脱落します。（家には無くても会社でPC触れる人もいるでしょうが、ゲーム開発会社とかでもない限りあんま会社のPCがハイスペって事は少なそう）

全体では7割超え…パソコンの世帯単位での保有状況をさぐる

次に、Steamの統計データを見てみましょう。Steam統計はSteamユーザーだけの統計なので、そもそもSteamユーザーってだけで全体の上位1割くらいのPCエリートが集まってると思われる点に注意してください。

まずCPUですが、12コア以上のCPUを積んでる人はSteamユーザーの1.3%くらいしかいません。16コア以上に至っては0.3%ほどです。

仮にSteam勢が全体の上位１割と仮定すると、CPU12コア以上の人は全体の0.13%です。
すなわち、もしあなたが12コア以上のCPUを持ってたら、あなたは760人に1人の超エリート層という事になります。

次にメモリですが、”More than 16 GB”、つまり16GBよりも多くのメモリを積んでる人はSteamユーザーの12.5%しかいません。

グラボについては、VRAMが8GB以上のグラボを使ってる人はSteamユーザーの3割くらいいます。ここはさすがSteam勢。

そういえばtwitterを見てたらストレージが足りなくて古代の谷をインスコできないという方もいるようです。（キャッシュとプロジェクトで合わせて200GBくらい要求される）
それは仕方が無いのでSSDを買い足してください。まあHDDでも動くかも。

さて、現在UE5の推奨スペックPCを所有してる時点で勝ち組の超エリートであるという事がお分かりいただけたでしょうか。
世間のほとんどの人は、推奨スペックが満たせずに古代の谷を動かすことを断念せざるを得ないのです（まあスペック足りなくても動くは動くかもしれないけど。快適ではなくとも）

UE5は自作PCあるいはBTO勢にとっての福音です！

例えばMacを使っていると、その時点で推奨スペックを満たせるようなMacってほとんど無いから脱落するでしょう。（M1MacのCPUスペックは結構高いですが、現状Lumenが動作しないなどの不具合があるようです）

WindowsでもノートPCだと推奨スペックを満たすPCはごく一部では無いでしょうか。ノートPCだとCPUやグラボをアップグレードできないのでPC自体を買い換えるハメになります。

ハッキリ言って今まで自作PC勢はバカにされる事がままあったと思います。
「そんなバカクソでかいＰＣ使っててバカじゃねえのｗｗ？クソ高いパーツ揃えて何するわけ？どうせtwitterするだけだろｗｗｗ！自作ＰＣなんて単なるオナニーなんだよなあ」

まあ、実際にはそんな風に言われてなかったとしても、そう言われてるような気はしていたかもしれません。
自作PCやってるユーチューバーとか見てても、CPUをバキバキにオーバークロックとかしたところで、結局やる事はシネベンチ回してスコア見て自己満するだけだったりします。

実際今までは、一般人がハイスペＰＣを持っていたところで、活用できる局面は今まであまりなかったという事です。
Unityとかも別にロースペＰＣで動くし、メニーコアＣＰＵを積んでても全然活用してくれなくてイラッとします。

しかし、UE5は超ハイスペを要求してきて、実際にスペックをしばき倒してくれます！
UE5は例え16コアあってもCPU100%でぶん回して余すことなく有効活用してくれます。タスクマネージャでCPU100%になってるのを眺めるのは自作PC勢の至福の瞬間だと言われてます。（適当）
自作PC勢は今こそUE5をインスコして「俺のＰＣならこんなにUE5が動いちゃうんだよなあ」とか言ってマウントを取るべき時です！！

スペック不足でUE5が遊べてない大多数の人から羨ましがられる事間違いなしですよ。
パソコンスペックを上げるだけで優越感が得られるだけではなく、”実際に優越できる“機会というのは貴重だと言わざるを得ません。

ＰＣスペックが高いだけで選ばれし人間になれる、私がUE5にアドしか感じないと言ってるのはそういう事なのです。

例えばおめシスのこの動画を観てください。

レイ氏がさっそく嬉々としてUE5で遊んで、古代の谷を実行しています。
レイ氏は最近、ハイスペＰＣパーツを買い揃えてハイスペＰＣを組んだばかりです。
自作PC勢というのはこんな風に自分のスペックを見せびらかせるチャンスを虎視眈々と窺っている生き物なのです。

ちなみにUE5は今すぐ触るのが一番アドであるという事も申し添えておきます。
何故ならば、時が経つにつれてみんなのPCスペックもじわじわ底上げされていくので、UE5を触れる人も増えていくと思われます。
何よりも、今はまだPCスペックの重要性に気付いている人は少ないですが、いずれみんな気付き始めると思われます。
アドバンテージというのは、みんなが知らないからこそアドなのであり、みんなが気付いちゃうとこぞってスペックを求めるようになったりして、アドは薄れます。

よって、UE5のアーリーアクセスが始まった今すぐ触るのが一番先行者利益が得られるはずという事です。

数年前にAMDがRyzenを発表して以来、CPUの性能が線形的に向上するという凄まじい時代に突入しています。
つまり、2万5千円払えば4コアのCPUが買えるし、4倍の10万円払えばコア数も4倍の16コアCPUが買えてしまいます。
当たり前でしょ？と思うかもしれませんが、当たり前ではありません。Ryzen以前はたとえば14コアのXeonは1947ドルもしました。
線形的にCPUのスペックがあげられるなら絶対最上位の16コアのRyzen買った方がトクじゃんという事実も気付いてる人はまだまだ少ないようです。（まあ今まではゲーム遊ぶだけとかならマルチスレッド性能よりシングルスレッド性能が問題だったりしたので4コアとかで十分でしたが、古代の谷が12コア要求って事はこれからはゲームもメニーコアがアドになってくのかもしれません）

なんでコア数が多い方がアドなのか？というと、Unreal Engineはマルチスレッドに最適化されていて、ゲームのビルドやシェーダコンパイルなどはコア数が多いほど線形的に処理が速くなっていきます。
つまり、16コアCPUを使っていれば、処理に待たされる時間は8コアCPUの半分近くになったりします。
これは、CPU代を数万円ケチっただけで、人生をドブに捨ててる時間が大幅に増えてしまう事を意味します。こういう面でもハイスペＰＣ勢は時間的アドバンテージを獲得できます。

という訳で、長々と話しましたが、ハイスペＰＣ持ってる人は今からUE5触ると爆アドという話でした。

別にそんな凄いゲーム作る気無いんだけど…という人でも、まあそんな気負わなくても、UE5は適当に触って遊ぶだけでもメッチャ面白いオモチャじゃないかと思いますので、是非触ってみてください。
私も触ってみてます。

ハイスペＰＣ持ってない…という人は今すぐBTOとかでハイスペＰＣをポチると良いのではないでしょうか。別に損しないと思います。

これからの時代は、パワーのある人ほど大量の計算資源を扱えるし、逆に大量の計算資源を扱えるほどパワーを持てるようになる、計算資源＝パワーの時代と言われてます。
どういう意味か？と言うと、例えば高性能なグラボを持ってる人は、仮想通貨をマイニングするだけで儲けられます。これなんかは、計算資源を直接パワーに変換できる良い例ですね。
仮想通貨に限らず、今後は計算資源がパワーに直結するような話が色々増えていくと思われます。

計算資源を手に入れるには、クラウドのAWSを使ったりする手もありますが、自分のPCをハイスペにする方が安くて手っ取り早く計算資源を増やせます。
「スマホでなんでもできるからPCなんて要らないや」という人もいますが、結局のところ、PCにできてスマホで出来ない事はまだまだ多いです。PCだと簡単にできる事をスマホで苦労して手間をかけてやるハメになってるケースもあるでしょう。それはディスアドです。

そういうわけで、私はできるだけ相対的に計算資源強者でいる事をオススメします。
ただ、私が懸念しているのは、ただでさえ今でもグラボがマイニング勢に買い占められて全然売ってないのに、これに加えてみんながハイスペＰＣのアドバンテージに気付き始めるとハイスペＰＣパーツの購入が殺到して永遠に入手困難な時代が来るんじゃないかなって心配してます。

というわけで、「ハイスペＰＣ買ってUE5触りたいけど挫折したらお金が無駄になっちゃう」みたいな懸念は不要でしょう。もしそうなったら仮想通貨を掘ればいいだけの話です。

最後に、論旨からズレるので触れてませんでしたが、UE5自体は古代の谷の動作スペックを満たしてなくても普通に動作すると思います。
UE5はUE4と互換性があるので、動作負荷的にも変わらないと思います。
しかし、UE5の新機能を活用し始めるとやはり古代の谷と同様のスペックが必要になってくるでしょう。

UE5を触らないディスアド

UE5の登場は今までのゲーム制作の最適化作業をすべて過去のものにしました。

Naniteで無限にポリゴン描画できるようになったので、3Dモデルのリトポ作業は不要になりました。（ただしスキンメッシュにはNaniteは使えない）

Lumenで完全リアルタイムＧＩが実現したので、ライトマップのベイクも不要になりました。

UE5のメチャメチャ美麗なデモを観ていると、UE5って大規模なゲーム会社じゃないと使いこなせなくて、個人開発者には関係無いでしょ？とか思う人もいるかもしれませんが、私はむしろ個人開発者への恩恵が大きいのではと思います。

リトポとかライトマップベイクって、ぶっちゃけクリエイティブな作業じゃ無くないですか？
別にやりたくてやってた作業じゃなくて、ハードウェアの制限上、やらないと動作しないから仕方なくやってたってだけです。

Unityなんて綺麗な間接光を表現しようと思ったらライトマップをベイクするしか無いですから、ライトをちょっと調整するたびに延々とベイク待ちするハメになってました。
GPUライトマッパーが登場したおかげである程度高速にベイクできるようになりましたが、シーンが大きくなってくるとVRAMが不足してGPUベイクがコケて、CPUベイクに勝手に切り替わってクッソ待たされるハメになってイラッとします。

ゲームの本質と無関係なこういうワケわからんとこであれこれ苦労させられるハメになってて、当時はそうするしかないからしゃーないと思ってましたが、UE5でそんな苦行から全部解放されるなら、もうUnityなんて触りたいと思いませんよね。

UE5を使えば開発者はゲームのクリエイティブな側面に集中できるというわけです。
ですので、個人開発者も、作業効率とモチベーション維持のためにもUE5がオススメです。

まあ、NaniteやLumenはモバイルは非対応らしいので、必ずしもリトポやベイクから完全開放されるわけではないですが。

映像制作用途でUE4を使ってた人なんかには神の贈り物以外の何物でもないと思います。

ポリゴンが無限に使えるUE5の登場がインパクトありすぎて、つい、「今までの自分のゲーム制作の苦労って何だったんだろう？」みたいな事を考えてしまい、過去の人生を振り返ってしまいました。

考えてみると、自分の人生ってゲームの進歩とともに歩んできたようなもんだったという気がします。

そして、高校生くらいから現在に至るまでずーっとゲームを作るという事についてああでもない、こうでもないとやってきた憶えがあります。

不思議な事に、そんな風に何十年もゲームを作ってた？はずなのに、実際には今まで自分の理想通りに自作ゲームが完成した試しが無いという事実に目を向けざるを得ません。
一体どういう事なんでしょうか？私の人生って何なの？

振り返ってみると、私がゲーム制作に挑戦するたびに、なんやかんやと”壁”にぶつかってしまって挫折する事の繰り返しだったような気がします。

そうして考えてみると、この前登場したUE5は神の贈り物にしか見えません。私が高校生の頃にこれがあったら…

今の若者は、最初からタダでUE5みたいな神のゲームエンジンが触れて、Blenderも今では2.93が出て完全に神のモデリングソフトと化してますし、あまりに恵まれた環境で非常にうらやましいです！

ですが、当の若者は恵まれすぎてて逆にそういうアドバンテージに気付いてない人が多いのではないでしょうか。

というわけで、今回の記事では、自分語りをしつつもゲーム制作に挑戦した時にどういう壁にぶち当たったのか？それをどう乗り越えようとしたのか？について書こうと思います。

まあ、”しくじり先生”みたいなもんでしょう。若者は私みたいな失敗を繰り返してはいけない！という話です。

幼少期

私が生まれたのは1987年ですが、何故か生まれた時からすでに家にファミコンがありました。

なんか親が興味本位でファミコンを買ってみたものの、「Ｆ１レース」と「サッカー」だけ遊んで飽きて放置されてたようです。

自分が２歳くらいですでにファミコンで遊んでる様子が撮影されたホームビデオを見た憶えがあるので、そういう意味では生まれながらにゲームエリートだったと言えるかも。

幼少時は毎年の誕生日とクリスマスのプレゼントは500円までというキツすぎる縛りがあったので、毎回中古の安いソフトを買ってもらってました。
どういうファミコンソフトのラインナップだったかというと、
ガチャポン戦士２、ガチャポン戦士３、ガチャポン戦士４、SDヒーロー総決戦、パワーブレイザー、Zガンダムホットスクランブル、ドンキーコングJr、ドラゴンボール3 悟空伝、魔界村、第二次スパロボ

ちょっとソフトは実家に置いてるので定かでは無いですが、こういうラインナップだった気がします。
ガンダム大好き少年だったのでガンダムに偏ってるな…

今にして見るともっとマリオとかドラクエとかロックマンとかの名作を遊ばせてやれよと思います。（名作は中古価格も高いので予算の関係上買えない）

小学生～中学生

たしか小１くらいでゲームボーイを買ってもらいました。

ゲームボーイで強烈な思い出はやはり小３くらいの頃に出た初代ポケモンです。
当時のキッズはみんなそうでしたが、私も死ぬほどポケモンにハマッてました。

あとは「星のカービィ２」を遊んでカービィにも死ぬほどハマッてました。
自由帳にカービィのラクガキをしまくってました。もちろん、リアル友達を偽カービィ化して勝手に漫画にするみたいな事は当然やってました。

他で印象的だったゲームボーイソフトは「ポケットカメラ」です。
ポケットカメラにはカメラが搭載されており、30枚まで写真を保存できます。ただし、白黒の荒い写真しか撮れません。（そもそもゲームボーイが白黒だし画素も荒いので当たり前）
当時はスマホなんて当然無く、携帯電話にもまだカメラは付いてなかった時代ですから、相当先進的なソフトでした。

まだ公式サイトが残ってますね。↓
https://www.nintendo.co.jp/n02/dmg/hardware/pocket_c/index.html

ポケットカメラの機能のすさまじさは写真を撮るだけではありません。
写真を加工できるペイント機能、スタンプ機能、アニメーション作成機能、作曲機能までありました。

そして、写真の特定の位置をクリックすると別の写真にジャンプできるJUMP機能もあったので、これらを全部組み合わせると、ちょっとしたアドベンチャーゲームが作れてしましました！

もちろん当時の私はなんやかんや作ってましたが他人に遊ばせるというよりは作るだけで満足してた気がします。

ポケットプリンタという外部プリンタにゲームボーイを繋ぐと写真のプリントまでできました。
今思うとつくづく任天堂の先進性に脱帽ですね。

スーファミも小３で買ってもらいました。

やっぱり「カービィＳＤＸ」や「星のカービィ３」は死ぬほど遊んでましたし、「ドラクエ６」も死ぬほど面白かったですね。「ヨッシーアイランド」も神ゲーでした。聖剣２、マザー２、マリオカート、マリオＲＰＧ、スパロボＥＸ

ゲーム制作への興味の芽生えという意味では、「ＲＰＧツクール」でＲＰＧを作ったりしましたね。
内容は、自分の家の周りを完全に再現して、ボスは学校の先生だった気がします。
これは完成して自慢するために友達の家に持っていったらセーブデータが消えて非常にショックを受けました。

ＲＰＧツクールによるゲーム制作の壁
セーブデータが消えると作ったゲームが消える

小５の頃にＧジェネが遊びたすぎてプレステを買ってもらいました。

プレステのポリゴンによる３Ｄゲームの衝撃は大きかったです。まあすでに友達の家で６４のマリオとかは遊ばせてもらってましたが。

ＦＦ７とかバイオ２、バイオ３、せがれいじり、メタルギアソリッド…

ＦＦ９は死ぬほどハマってましたね。

たしか中２の頃に福袋の当たりでＰＳ２を入手した覚えがあります。

ＰＳ２では真三国無双２に気が狂うほどハマッてました。地球防衛軍とかもやってましたし、敵が一杯出てくるのがおもろいなという風潮でした。

ＩＣＯも相当好きでした。ＩＣＯはHDRライティングとブルーム効果を実装してたのが当時としては先進的でした。

ICOの続編の「ワンダと巨像」ではさらにポストエフェクトが進化してますが、その辺の技術的な詳細については4gamerの記事で書かれてます。
当時としてはワンダのグラフィックスは”意味が分からないくらいすごい”という感じでした。

3Dゲームファンのための「ワンダと巨像」グラフィックス講座

中３でキングダムハーツが出たと思いますが、これまた当時としては異常なクオリティのグラフィックにたまげました。

キングダムハーツで衝撃的だったのは、FF7の主人公のクラウドがゲストで登場するんですが、メチャメチャカッコいいキャラデザからの、役割はただのハデスのしもべの噛ませ犬だったのでたまげました。（たしかファイナルミックスではセフィロスと戦うシーンとかが追加されて株が上がってる）

大体ここまで読んでお分かりの通り、私は生まれて以来ゲーム漬けに近い人生を送っているので、進学についても何かゲーム作れる仕事に就けそうな学校に入ろうかな～みたいな事を考え始めました。

高専生

なんとなく「ゲームを作るにはプログラミング？が必要らしいね」ぐらいの適当な知識だけで高専の情報系の学科に入った気がします。

それまでマトモにＰＣを触った事も無かったので、具体的にゲームってどうやって作るのか？などは一切知りませんでした。ゲーム会社の特殊な機材が無いと作れないんだろうなくらいに思ってました。

情報系の学科というだけあって、学校の授業ではＣ言語を学びました。

どういう感じかと言うと、教科書にプログラミングの課題があるので、ＰＣのメモ帳でコードを書いてコマンドプロンプトの黒い画面でコンパイルして実行する…みたいな感じです。

↑こんな感じです。（これはVisual Studioなのでちょっとちがうけど）

当時の私の正直な感想としては「これがプログラミング…クソつまんねえな…」と思いました。
アレコレ苦労してコーディングさせられる割りには出力結果はなんか黒い画面に文字がチョロッと出るだけ…インプットの苦労に対してアウトプットの対価がヘボすぎるんだよなあ…。
余談ですがこのようなプログラミング授業と対極にあるのがパチンコじゃないかなと思います。パチンコはハンドルを回すだけで画面演出がジャンジャンバリバリ表示されます。インプットの簡単さに対してアウトプットのド派手さがすごいです。インプット：アウトプット比が大きいほど人間はハマると言われてます。
人間を夢中にさせる仕組みというのはこうあるべきで、C言語の授業は人間を退屈させる仕組みの極致と言わざるを得ないでしょう。面白いのは、そういうパチンコのソフトウェアも中味は多分Ｃ言語とかで書かれてるであろうという点です。

教科書に沿ってプログラミング言語を学ぶ時の問題点は、やっててもこれが具体的に何の役に立つのかサッパリイメージできない点にあるのではないでしょうか。
おもしろくもないし、何の役に立つのか分からない事には学習意欲が出ません。

まあなんだかんだ言ってもこの段階でポインタの概念やらまで理解できたのは後々役に立ったのでありがたい授業だったと思います。

そういえば、ちょっと戻りますが中学生の頃にパソコンの授業でちょっとだけhtmlの書き方について教わりました。
htmlは簡単に書けるし、出力されるホームページはC言語のコマンドプロンプトよりよっぽどグラフィカルでたのしいです。画像とかもバシバシ表示されます。
C言語とかよりhtmlの方がよっぽど簡単にゲーム作れそうだな…と思いました。

Ｃ言語によるゲーム制作の壁
Ｃ言語にはグラフィックスがそもそも無い

Ｃ言語にはグラフィックスが無いと言いつつも、クラスメイトのＫ君はなんとコマンドプロンプト上で工夫してゲームを作っていました！

どうやったのかというと、こちらの画像↓のような感じで文字を使って迷路マップやキャラクターを表現していました。

プレイヤーが移動方向を入力すると、迷路全体が再描画されてバーッと上にスクロールして画面が更新されるといった風です。

私としてはたしかに凄いなと思って感心して真似したりはしたものの、でもすでに三国無双やキングダムハーツを味わっていた私としては、「俺が作りたいゲームってこういうんじゃないんだよな…」と思ってイマイチ気が乗りませんでした。

↑当時自分が作った迷路ゲームが発掘されたのでスクショ

この際ついでなので物申しておこうと思いますが、去年から義務教育でのプログラミング授業が始まったみたいですが、「頼むからメモ帳でＣ言語教える授業みたいなのはやらないであげて」と言いたい。
子供の内からプログラミング→つまらない　みたいな刷り込みが出来てしまうと将来の可能性の芽が潰えるかもしれません。

実際、現状では小学校のプログラミング授業って何をやってんだろ？と思って検索してみました。

なるほど。Scratchとかマインドストームとかやってるのか。
まあ、正直言ってイケてるチョイスですね。

マインドストームというのは私も高専の授業で当時触りましたが、これはかなり面白いです。
モーターやらコンピュータやらバッテリーやらがくっ付いたコアユニットがあって、これをプログラミングで制御できます。
コアユニットにタイヤを付ければ走らせることができますし、なんか複雑な機構を考えれば歩かせたりもできるでしょう。レゴなので好き勝手に形を作れます。

プログラミングした通りに実際に自分が作ったマシンが目の前で動くわけですから、手ごたえが大きいです。色々試行錯誤して試してみる意欲が湧いてきます。メモ帳Ｃ言語とは大違いです。

小学生大喜びだろうなあ。

ちなみにマインドストームはMicroPythonというPythonでプログラムを書くようです。最近はノードによるビジュアルプログラミングも可能だとか。

一方、Scratchは元々教育向けのプログラミング環境でした。

こちらもブロックを使ったビジュアルプログラミングが採用されていて、いいですね。
メモ帳でＣ言語書いてると「何で俺こんなに文字打たされてんだろ…」という気持ちになってきますし、なんか一か所だけ文末のセミコロン付け忘れて、「何が何だか分からんけど動かない」とかなりがちです。そういうのってなんかプログラミングの本質的な部分と無関係なところで躓かされて腹立つ気がします。

ビジュアルプログラミングならそういう厄介な事はありません。

そしてScratchはコマンドプロンプトと違って”絵”がすぐ出せます。ここが大きいですね。
後で話しますが、C言語でなんかちゃんと絵を出そうとしたら理不尽なくらい大変です。

パッと絵が出て動かせるならゲーム気分でたのしめるでしょう。
今の子供たちは恵まれたプログラミング教育が与えられそうで羨ましいですね。私が小中学生の頃はプログラミングのためのＰＣさえ手元に無く、プログラミングが何なのかも全然知らないような有様でした。

そういえば最近のキッズ達はプログラミング教育云々関係なしに、ことごとくマイクラにドハマりしていて、小学生にしてMod導入技術やサーバーホスティングなどのＩＴリテラシーがメキメキと鍛えられているとかいないとかいう噂を耳にしますね。

そんなにキッズ達がマイクラに夢中なら、せっかく教育版マイクラがあるんだからプログラミング教育にもこれを使うのも良さそうですね。

https://forest.watch.impress.co.jp/docs/serial/progedu/1278765.html

やっぱプログラミングと言えばゲームっすよ。
教育版マイクラではMicrosoftのMakeCodeとかいう、あんま聞いた事無いですがScratchと同じようなブロックビジュアルプログラミングを使うみたいですね。

さて、話が大幅に逸れましたが、私の高専時代に話を戻します。
そういえば当時は高専生は全員がポケコンを購入させられました。

ポケコンは関数機能が豊富なので、一部の授業で使ったんだと思います。
このポケコンは授業中に触ってても怒られません。そしてBASICが内蔵されており、プログラミングが書けます。

そんな訳で、クラスメイトの中には授業中に延々とポケコンを触ってなんかゲームを作ってるヤツもいました。
このBASICには画面の液晶を使ってちょっとしたグラフィックスを描画する機能もありました。

私はポケコンでのゲーム制作はやってませんでした。
たしか電池が切れるとメモリが消えちゃいますし、多少グラフィックが描けても自分の作りたいゲームってもっと違うんだよな…とか思ってたのかもしれません。
というか、私は授業中はひたすらラクガキするのに忙しかったので。

そんなこんなで、当時の私は「Ｃ言語のプログラミングってつまらんな…プログラマになったら一生こんな仕事をしなきゃ行けないのか…やだなあ」みたいな感じでコーディングへの嫌悪感を募らせていました。
自分はただ単にゲームが作りたいだけなのに、なんでこんな苦行をさせられなきゃいかんのだ？とか思ってました。

転機が訪れたのはそんな頃でした。
当時の私は一部のクラスメイトとＭＴＧ（マジックザギャザリング）でひたすら遊び狂ってました。

そんなＭＴＧ仲間の内数人が、電算部とかいう部活に入って何やら面白い事をしているという話を聞きました。
電算部というのは要するにパソコン部です。厳密にはプロコンに出場するみたいな目標があるにはあったようですが、実態はパソコンで遊ぶだけの部活でした。基本的には部室のLANで無限にAge of empireⅡで遊んでるとかそういう部でした。

そんで、みんなで電算部の部室に見学に行ったら、先ほどＣ言語で迷路作ってたＫ君が、
「俺電算部でゲーム作ってんねん」
とか言い出しました。

そこでＫ君が部室のＰＣで見せてくれたのが、大体こういう感じのテトリスのゲームでした。

「作ったー！？」

私が人生で最大級の衝撃を受けた瞬間だったかも。
プログラミング使えばゲーム作れるらしい？→Ｃ言語とかこんなん書いててもカッコいいゲーム作れないじゃん…
という、上げて、落として、からのこれだったので。

テトリスできとるやん！！

Ｃ言語だと全然グラフィックスが出せなかったのに、Ｋ君はどうやってテトリスの画面を出したんでしょうか？

その秘訣は、Visual Basicでした。（当時は6.0）

Visual Basicは、フォームエディタという、画面上にボタンや画像などの部品を直接配置して編集できる神機能が搭載されてました。

これにより、C言語と違ってなんも考えないでもグラフィックスが表示できます。
コードについても、例えばあるボタンがクリックされた時のイベントを記述する…みたいな感じでイベントベースで直感的に書けます。

Ｃ言語のによるゲーム制作の壁、簡単にグラフィックスが出せないという点を、VisualBasicで克服できた！

ここで気付いたのは、ゲームを作るにしても、”コーディングだけだとほぼ無理”であって、フォームデザイナみたいな”ビジュアルエディタ”が無いと作れないという事実です。

電算部では他にもすでに卒業されたＯＢが残されたという、ダンレボのクローンゲームも触らせてもらいました。当時の私たちにとっては完全に神扱いでした。

高専生はアプリ側とコントローラのハード側で分担して音ゲー作りがち（そして高専祭の出し物として展示される）

そんなワケでしたから私は興奮のあまり即日で入部届を書いて入部したのでした。
それからは毎日部室に入り浸ってVisual Basic触ったり、エイジオブエンパイアやったりＭＴＧやったりする日々が始まりました。

ちなみに私達が部室で遊んでたゲームはEOAだけではなく、ネットで配布されてたフリーゲームとかもよく話題になってました。

当時（2003年～2006年くらい）は色んなフリーゲームが「ふりーむ！」や「Vector」で公開されてました。

当時の私はこういう個人制作フリーゲームを遊んで、「個人でもゲームが作れるんだ！」って夢と希望がムクムクと湧いていました。

当時はまだ３Ｄゲームの作成はノウハウが広まっておらず困難でしたので、本格的な３Ｄゲームを制作されていた灯さんなんかは崇拝の対象でした。

私は部室だけでは飽き足らず、家でもパソコンが触りたくなってきたので、１年生の冬休みに年賀状配達のバイトしてその金でパソコンを買いました。メモリが256MBしか無く、Cerelonの2.4GHzシングルコアとかそんなパソコンでした。
インターネット回線はADSLが高すぎたのでケーブルテレビの5Mbpsくらいしかないけど月3千円の回線を引いてもらいました。

パソコンを買ったと言ったらいとこが「月姫」を貸してくれて、遊んでみたらドハマりしたという話があるんですが詳細は省きます。

私は自分でもVisual Basicでテトリス作ってみたり、格ゲー（といってもキャラに複雑な動きはさせられないので分離したパーツを動かすジョイメカファイトみたいな感じ）に挑戦して挫折してみたりとなんやかややってました。

↑当時作ってたゲームの例。下から床がせり上がってくるので天井に潰されないようにどんどん下へ降りていく。

C言語のせいでうんざりしていた私もVisual Basicのおかげでかろうじてプログラミングに興味を抱けるようになりました。
しかし、色々やってる内に段々とVisual Basicに限界を感じ始めました。

そもそも論として、Visual Basicはゲームを作るためのソフトではありません。
業務アプリとかを作るためのものです。（ちなみにVisual Basicを覚えるとエクセルとかのVBAも書けるようになって便利）

当然、3Dゲームなんて作れません。

VisualBasicによるゲーム制作の壁
ビジュアルエディタが付いてるのは良かったけど、そもそもゲーム向けじゃないし、3Dゲームが作れない。

２年生になったあたりから、Visual Basicに限界を感じ始めた我々の間では、Windowsプログラミングというものが話題になってました。
いわゆる、猫でも分かるWindowsプログラミングです。

どうやら、Win32APIなるものを叩けば、C言語でもウインドウやビジュアルが表示できるとか。
しかし、私はWindowsプログラミングでウインドウを表示するためだけに意味不明のおまじないみたいな大量のコードを記述するハメになるのが気に入りませんでした。VisualBasicなら１行も書かなくてもウインドウ出せたのに。

http://www.kumei.ne.jp/c_lang/sdk/sdk_00.htm

個人的にはWindowsプログラミングにはあんま意欲が出ませんでした。それに、当時の私は月姫のファンアート描くので忙しかったのです。

そうこうしてる内に、電算部の方ではさらに一歩進んで「どうやらDirectXという技術を使うと憧れの3Dゲームが作れるらしい」という噂になってました。

3Dゲームが作れるとあっては、さしもの私も食いつきました。
果敢にチャレンジしたものの、DirectXによる3Dゲーム開発は、Windowsプログラミングの20倍くらい意味不明でした。
当時は現在と違って、ググったらなんでも情報が出てくるというものではありませんでした。

「デバイス？レンダーステート？ドローコール？メッシュ？マテリアル？テクスチャ？シェーダー？スキンメッシュ？行列？ベクトル？透視変換？ＶＲＡＭ？」

ハッキリ言って全てが意味不明でした。（そうは言っても当時のDirectX9.0は今のDirectX12に比べると大分簡単だったかもな…）

私は結局挫折したんですが、我々の中でDirectXの書籍を読んでなにかしら理解できていそうなのはＡ君だけでした。

それでＡ君は高専祭に向けて３Ｄゲームを作るぞ！という目標を立てて、私も制作への参加を誘われました。私が頼まれたのは３Ｄゲームのキャラクター制作でした。ずっとラクガキしてたので、プログラミングよりもデザイン方面の能力を見込まれたという事でしょう。
私自身ももうプログラマよりもイラストレーターか何かになりたいな～という気分でした。

さて、そうは言っても３Ｄキャラクターのモデリングなんてどうやればいいのかさっぱり見当も尽きませんでした。
教えてもらったのは、メタセコイアというモデリングソフトが使えるとの事で、しかも無料版でも普通にモデリングして出力可能だそうで。

↑とりあえずなんやかんや作ってみたモノ

さて、３Ｄゲームを作るとなると、３Ｄモデルだけでなく、アニメーションも付ける必要がありますが、当時は学生が触れるもので３Ｄアニメーションを作成できるソフトはロクにありませんでした。

名前は忘れましたが、海外のフリーソフトをアニメーション作成に使いました。
スキンメッシュには対応しておらず、関節ごとにパーツをばらして動かす必要がありました。

そんなこんなで、Ａ君がプログラマで、私が３Ｄキャラを作成を担当したゲームは完成して高専祭で展示できました。

Visual Basicによるゲーム制作の壁、3Dゲームが作れないという問題を、DirectXで克服できた！（ただし克服できてるのはＡ君であって私ではない）

ちなみに、当時からすでにBlender（多分Version2.3の頃）はあったはずですが、今は神ソフトと化したBlenderも、当時から無料で高機能ではありましたがネット上に全く情報がなく、意味不明なインターフェースを備えていて完全に謎のソフトで素人は手を出してはいけないという雰囲気だった気がします。

さて、ゲームができてめでたし。ではあるものの、自分はDirectXに挫折して、プログラミングしたのはＡ君であるという点に私の中で引っかかるものがありました。

「３Ｄゲームは作りたいけど、DirectXはチンプンカンプンで触りたくない…」と考えた私は、HSPに手を出してみる事にしました。

大体この辺まで読んでいただいた方はお分かりかと思いますが、私は”とにかくゲームさえ作れれば手段はどうでもいい”というタイプの人間で、プログラミングなんて好きでやってるわけでは無いのです。やらないとゲームが作れないと言うから仕方なくやってるだけで、やらなくて済むならこんなもんやりたくないのです。（今でもそう）

参考にした書籍はこれです↓

HSPを使えば、Win32APIやDirectXみたいなややこしいプログラムをすっ飛ばして簡単に3Dモデルを表示したりできます。

これでいいじゃん！と思ってしばらく触ってましたが、最終的にはスキンメッシュのキャラが表示できないかなにかの理由で断念しました。

HSPは簡単にグラフィックスが出せたり3Dモデルが表示できるけど、用意された機能しか使えないからあまり凝った事ができない

さて、プログラミングについてはそんな感じで試行錯誤してましたが、３Ｄモデリングの方にも結構熱中してました。
当時はメタセコイアのコミュニティが結構盛り上がってました。

メタセコイアはC++でプラグインが書けて、自由に拡張できるのですが、当時は色々な便利なプラグインを開発されてる方一杯いました。

例えば、Sio29さんのCelshadeを使うとメタセコ上でトゥーンシェーダ調表示ができました。

プラグインでは無いですが、Mikotoというフリーソフトはメタセコの３Ｄモデルを読み込んでスキニングしてポーズを付ける事が出来ました。（ただしXファイルなどにエクスポートしたりはできない）

さらに、時期は少し遅れますが、mqdlさんが作ったKeynoteは、メタセコ上でMikotoのようなスキニング、ポージングを可能にして、さらにXファイルやFBXファイルもエクスポートできるという神プラグインでした。

余談ですが、メタセコ開発者の方は、後年になってメタセコの4.0アップデートで2万円のEXバージョンを用意する事にして、スキニング、FBXエクスポート機能を目玉に据えようと思ったものの、すでにKeynoteなどのユーザープラグインで同じ機能が実現されてしまっているので、しょうがないので今までのプラグインの互換性を切ってしまいました。
それでKeynoteプラグイン作者のmqdlさんや大勢のプラグイン作者達との確執が生まれ、mqdlさんは今ではXISMOという自前の3Dモデリングソフトを開発されているみたいな話があったりします。（この余談は噂、ゴシップレベルの話で、正確なところは当事者にしか分かりません。間違ってたらすいません）

プラグイン開発コミュニティ以外にも３Ｄモデラーコミュニティも盛り上がってました。

その中でも私が完全に神として崇拝してたのはntnyさんでした。

ntnyさんの作る３Ｄモデルはクオリティが凄く、さらに製作されたモデルをドシドシ配布してくれていたので、私はいつも配布モデルを舐めるように眺めていました。
クオリティが高いというか…ntnyさんのモデリングは一種の”発明”のようなもので、二次元キャラを３Ｄキャラに立体化するテクにおいては当時、神の領域でした。
当時配布されていたモデルは全部私のHDDの中に保存されてます。

また余談ですが、その後ntnyさんはフライトユニットさんに所属されたようです。
フライトユニットさんがキャラクターのモデリングを行った「シャイニングフォースイクサ」のキャラクターモデルは、当時としてはクオリティが異常でした。

↑シャイニングフォースイクサのキャラクターメイキングです。メタセコを使ってモデリングしてますね。詳しい事は分かりませんが、私はntnyさんの貢献が大きかったんじゃないかと勝手に思ってます。

ntnyさんはその後、Unityのユニティちゃんのデザインとモデリングを担当され、Unityテクノロジーズに所属されています。

ntnyさんが書いた「ローポリ　スーパーテクニック」はバイブルです。

↑すいません、ntnyさんの本のページから引用させてもらいますが、こんな風にメタセコ特有の下絵を投影しながらのモデリングと、エッジだけで形を整えていってから面張りする手法が元イラストの再現性を高めるための秘訣だったんじゃないかと。これはかなり真似させてもらいました。

ntnyさんの起こしたモデリング革命がその後の日本のゲームのアニメ、イラスト風３Ｄモデルのクオリティ底上げに繋がったんじゃないか…そんな風にまで思ってしまいます。

話したい事はいくらでもありますが、一旦私の学生時代の話に戻しますが、３年生になって、またＡ君の３Ｄゲームの第二弾を作ろうという話が持ち上がりました。
私は今回もキャラクターモデル担当ですが、今回のチャレンジとしては、スキンメッシュモデルを作ってみようという事になりました。

↑その時作ったモデルがこれ。う～ん、まあこんなもんじゃないですかね。

たしか当時すでにペンタブ（intuos2の一番小さいヤツ）を買っていたので、それでテクスチャを描いたんじゃないかな。

当時はメタセコのKeynoteプラグインはまだ無かったので、おちゃっこさん（当時はおちっこさん）が開発された、RokDeBone2という素晴らしいフリーソフトを使用させていただきました。

RokDeBone2を使うと、メタセコの３Ｄモデルを読み込んで、頂点ウエイトペイントしてスキニングしてアニメーションを付けてXファイルをエクスポートできます。

Ａ君のプログラミングスキルは相当向上していて、今回のゲームは野菜の栽培パートとダンジョンパートに分かれており、ダンジョンでは敵がA*アルゴリズムによるＡＩでこちらを追跡してくるといった様相でした。

私もこうして完成したゲームには満足したものの、やっぱり自分でプログラミングして自分のキャラを自分で制御したいなあという気持ちも強まっていきました。

たしか、この頃の電算部界隈ではC#が流行っていた気がします。
C#を使うとVisual Basicみたいなフォームデザイナも使えるし、C++より簡単に書けるし、何よりもインテリジェンスで入力補間してくれるのが神！みたいな感じでした。（フォームデザイナはC#の機能と言うよりVisualC#の機能かな。当時はなんかＣ＋＋だとちゃんとインテリジェンスが表示されなかった）

私もちょっとオセロのＡＩとか作ってみましたが、それっきりでした。
今さらフォームデザイナとか言われても、私の気持ちは完全に３Ｄゲーム開発の方を向いていたからです。（実はManaged DirectXを使えばC#でもDirectXが使えるんだけど、それこそ書籍やネット情報が皆無で、手の出しようが無かった）

それよりはＡ君からＣ＋＋について色々教わったりしてました。（クラスって何なの？みたいな話）

そういえばこの頃は「ひぐらしのなく頃に」がメッチャ面白いらしいとネットで噂になっており、修学旅行で東京に行った際にメロブかどっかで（地元には同人ショップは存在しない）ひぐらしを買ってプレイした結果ドハマりしてましたね。

そうこうしてる内に4年生になり、そろそろ進路について考える時期になりました。
まあ言うても、結局はゲームプログラマ目指す感じかな？という気分でした。

ゲームプログラマ志望で就活するとなると、当然自作ゲームの提出が要求されますので、ゲームを作らなければなりません。もちろん３Ｄゲームでしょう。

DirectXはトラウマなので触りたくないけど、３Ｄゲームは作らなきゃいけない…

このジレンマを解決するために私が着目したのが、葉迩倭さんのLunaライブラリです。

https://web.archive.org/web/20060203120746/http://www.twin-tail.jp/

LunaライブラリはDirectXのラッパーライブラリです。Win32APIやDirectXの面倒な部分を一切省いてCやC++でゲームを開発する事が出来ます。
衝突判定やスキンメッシュの表示、地面の上を歩けるようにする機能など、ゲームに必要そうな機能が当時としてはかなり充実してました。

↑Lunaライブラリで遊んでみてる様子

「なんかHPSの時の話と似てるなあ…」と思われるかもしれませんが、HSPと違うのは、Lunaは単なるラッパーライブラリなので機能が足りなければ直接生のDirectXを触る事も可能です。（もしHSPでも可能だったらすいません）

ちなみに、Lunaライブラリの作者の葉迩倭さんは当時スクエアで働いていたそうですが、今はSPARKという会社の副社長兼CTOをされてるそうです。

そんな訳で、私はC++を勉強しつつ、Lunaライブラリで就活提出用の３Ｄゲーム制作を始める事になりました。

当時の私がネットでよく見てたのは、自作ゲーム開発コミュニティ？みたいな界隈の人達です。
ゲームヘル2000というコミュニティが盛り上がってました。

OMEGAさんという方は、Every ExtendがPSPで商業ゲーム化されててメチャメチャ尊敬してました。（Every ExtendもLunaライブラリが使われてるらしい）えぐぜりにゃ～も面白かった。

↑2009年のIGDAのOMEGAさんのセッション

ABAさんはシューティングゲームを沢山作られていました。BulletMLという弾幕記述言語を生み出しました。

kenmoさんのゲーム制作に関する記事はいつも参考にさせてもらってました。

https://kenmo.hatenadiary.org/

今ではサクナヒメで有名なえーでるわいすのなるさんが当時公開していた花咲か妖精というゲームはアクションが爽快で尊敬してました。

D5さんが作られたシスプリガントレットという同人ゲームは、体験版しか遊べてませんがメッチャ面白くて印象に残ってます（辺境に住んでたので買いに行けない）

https://web.archive.org/web/20070305233604/http://d5-dot.net/

さて、Lunaライブラリで何やかややってた私に話を戻します。

Lunaライブラリではシェーダも使えるんですが、私のPCのマザボオンチップのグラフィックスチップではプログラマブルシェーダ（2.0）に対応してなくてシェーダが読み込めませんでした。
慌ててSapphire製の安いグラボを買った気がします。

↑当時モデリングしたキャラ

↑これは当時発売されたDS版FF3のモデルのテイストに衝撃を受けてパクリにかかってる

↑どうやってフィールドマップを作成しよう？と考えた時に画像でマップを書いて、それを一旦C#のプログラムでテキストデータに変換して、そのテキストデータを自作したメタセコプラグインで読み込んでハイトマップメッシュを生成しているの図

↑最初はこんな風にキャラがフィールドを歩いて敵を倒す、アクションＲＰＧを目指してましたが、ジャンプ処理やらなんやら考え始めると、意外と面倒という事に気付きました。

↑結局作り直して、こういう人魚の主人公にして海の中を泳ぐゲームにすることで、地面を歩く場合の諸々のアクション実装の面倒さを回避しました。

↑これはハッチング風シェーダとか作って遊んでる様子

初めて自分でちゃんと３Ｄゲームを開発してる中で、結構色々な学びがありました。
例えば、処理のボトルネックをプロファイラで確認したら、ドローコールの発行が一番クソ重かったことなどです。
メッシュが分かれたり、マテリアルが分かれたりすると、その度にドローコールが増えてしまいます。
ですので、キャラクターのメッシュ、マテリアル、テクスチャは絶対に一つにまとめた方がよい事。
この辺は今のUnityでのゲーム開発でも通じる所です。

３Ｄゲームを作ろうとして気付いた事ですが、まず、普通のWindowsプログラムには、C#のフォームデザイナみたいなグラフィックエディタは付いてません！
UIとかの部品は全部コードで設定するハメになります。面倒です。

さらに3Dゲームだと、実際は3Dのグラフィックエディタが無いと制作は困難を極めます！例えば敵キャラの配置をコードだけで設定しようとしても、画面上のUIと違って不可能に近い問題になります。
私は悩んだ挙句、メタセコを３Ｄエディタだと見做して、敵を置きたい場所に頂点を配置して、それを自作プラグインでデータエクスポートしてゲームに読み込めるようにしました。

本来なら３Ｄエディタをまず自作すべきなんでしょうけど、そんな事やってたらいつになったら実際のゲーム制作が開始できるのか分かったものではありません。

DirectXによるゲーム制作の壁
ビジュアルエディタが無い（要自作）

そんなこんなで就活が始まるまでに慌ててゲームをでっち上げて、就活が終わった頃には５年生になっていたという感じでした。

恒例のＡ君とのゲーム制作もやっていましたが、やはり本格的な３Ｄゲームを作る時間は取れなくなってきたのでダンレボクローンみたいな音ゲーを作ったりして、私はイラストをちょっと提供するだけとかになってましたね。（入部当時は神扱いだったダンレボクローンをＡ君は乗り越えたんだなあという感慨）
この頃のＡ君はGame Programming Gemsとかいう分厚いゲーム開発Tips集とか読んでました。

５年生になると、卒業まで１年かけて卒業研究をする必要があります。
大体は指導教員のお手伝いみたいな感じでやるものですが、私は教員の方の専門とは違う事を一人で勝手にやる事にしました。

何をやるかと言うと、３Ｄのシミュレーションの研究をやる事にしました。とは言え、それは研究としての体裁を整えるための方便で、本当の目的はDirectXの勉強でした。

実は、就活で提出したゲームが、生のDirectXじゃなくてLunaライブラリを使用しているという点でウケがイマイチだったのが引っかかってました。やっぱりゲーム会社に入る前にちゃんと生のDirectXを勉強しといた方がいいかもな。と思いました。
また、過去のDirectX挫折のトラウマも払拭する必要がありました。

計画としては、Lunaライブラリみたいな感じで自作のDirectXライブラリを構築しつつ、その上で研究の３Ｄシミュレーションを実行すればよいというものです。

↑最初の頃やってみた布のシミュレーション

布のシミュレーションはすぐできたしあんま面白くないなあと思いましたが、Ａ君からヒントをもらって、水の流体シミュレーションに挑戦する事にしました。

自作のDirectXライブラリの方は、イチからコツコツと書いていきました。（結局半分くらいはLunaライブラリの写経だったと思うけど、それでも自作したと言い張る）

↓参考になった書籍はこれです。

シェーダの本ですが、最初の方に分かりやすい３Ｄプログラミングの解説があります。

DirectXライブラリの自作で一番厄介だったかもしれないのは、Direct3Dデバイスがロストした時の復旧作業ですかね。テクスチャから何からいい感じに全部再ロードしてあげる必要があります。
なんかウインドウモードとフルスクリーンの切り替え時？とかにデバイスがぶっ壊れたりするそうです。こんな処理自動でいい感じにやってくれよ…。

他にはファイル上のテクスチャとメモリ上のテクスチャとＶＲＡＭ上のテクスチャをいい感じに管理してあげなきゃいけないのがややこしくて混乱しました。今ならUnityならこの辺何も意識する必要無いのに。

あとはスキンメッシュアニメーションの実装は概念も数学もコーディングも全てが厄介で大変でしたね。

C++の勉強でよく参考にさせていただいたのは、ロベールのＣ＋＋教室さんですね。

DirectXの勉強で参考にさせていただいたのは、まるぺけつくろーどっとコムさん、もんしょの巣穴さん、t-potさん、電波の缶詰さん、など。大変助かりました。

そういえば、この頃はニコニコ動画がメチャメチャ盛り上がってて、毎日ランキングの1～100位を舐めるのが日課でした。
ニコニコのMADで東方を知って、そういや東方にハマッてる友達いたな…って彼から東方原作を借りてドハマりして…って感じで当時は東方厨になってました。
ZUNさんを崇拝して個人制作ゲーム熱がさらに加速するといった面もありました。

そんなこんなで卒業が近づき、卒業研究は、このブログで以前に触れた事もありますが、SPHを実装して水の流体表現を行いました。

SPHを実装しただけで特に新規性も無いし、どこが研究なの？と今の僕なら言うかもしれませんが、まあ高専生の卒研なんてこんなもんです。

さて、振り返ってみると、私やＡ君の間では、ゲームと言えば例えばキングダムハーツとか（野村哲也さんは神格化されていた）ダーククロニクルとかそういうので盛り上がっていて、我々が作ろうとしていた３Ｄゲームは常にそういうクオリティを目指していたわけです。（理想と現実の違いは大きい）

しかし、この頃になって私はようやく気付き始めていたんですが、
「もしかして３Ｄゲーム作るのってメチャメチャ大変なんじゃね？」
という点です。まず、３Ｄビジュアルエディタが無い時点で詰んでます。
３Ｄエディタの自作なんてそれだけで途方もない労力がかかります。

あと本格的なゲームを作るんだったら実はエクセルこそが最強のゲーム制作ツールなんじゃね？という事も段々理解してきました。

また最初の頃に疑問に戻ってきますが、「私はゲーム作りたいだけなのに、なんでここまで苦労しなきゃいけないんだ」という話です。
悩んだ末に、「３Ｄゲームじゃ無くて２Ｄゲーム作ればいいんじゃね？」という結論に至ります。
直近でハマってるゲームが東方である事も影響しているでしょう。

↑これはABAさんのBulletMLを自作ゲームで読み込んで表示してみてる様子
影響というかモロに東方クローンを作りにかかってました。

↑これはC#製の2Dコリジョンエディタ。2Dのこういうちょっとしたエディタ作るくらいなら全然手に負えるわけです。3Dになっちゃうとそもそも表示できない（Managed DirectXとか使わない限りは）ので、3Dのエディタってどう作ればいいのか見当も付きませんでした。ああ～、３Ｄのゲームエディタさえあればなあと夢見る日々（そして後々Unityに出会う）

３Ｄゲームが作りたくてわざわざDirectXライブラリまで自作したのに結局2Dゲーム作るとか馬鹿なんですか？と思われるかもしれませんが、実は大量の弾幕表示は2Dとは言えDirectXでポリゴンとして一括描画した方が描画負荷的に有利だったりしますので、無駄ではありません。

社会人

さて、就職してからも自作ゲームの熱はまだ続いていました。上の東方クローンは飽きて放棄されましたが。
私は一応ゲーム会社に就職できて、Ａ君も某有名ゲーム会社に就職しました。
今にして見ると、電算部のみんなやＡ君との出会いが無かったら私ってここまで来れてなかったよな…それは感謝なんですが、まあ感傷的になるのは今回の記事の目的ではないのでその辺にして。

2008年のこの頃、私はＣ＋＋によるゲーム制作に心底ウンザリし始めていました。
何かというと、Ｃ＋＋で開発していると、コードを変更するたびにコンパイル＆ビルドしないとテストできません。そしてＣ＋＋はＣ＃と違ってコンパイル時間がクッソ長い！
本当にちょっとしたテストプログラムだったらすぐビルドできるので、開発の最初の頃は気になりませんが、ゲーム規模が大きくなってくると、ちょっとしたコード修正やデバッグの旅に数分～１０分待ちとかになってきて段々と開発の進捗が出なくなってきます。

つまり、Ｃ＋＋はイテレーションに弱すぎる！（今思えば今度こそManaged DirectXでC#使えば良かったかも。この頃はもうXNAが出てたけど）

ついでに言えば、Ｃ＋＋はちょっと循環参照しただけですぐコンパイルエラーを吐いて文句言ってくるのも軟弱だと思ってました。例えば、ＡクラスがメンバにＢクラスを持っていて、ＢクラスもメンバにＡクラスを持ってたりするとアウトです。Ｃ＃なら文句言わず動いてくれるはずなのに（まあそもそも設計に問題があるかもだし、今考えれば工夫すれば回避できそうだけど）

ダメ押しで言うと、Ｃ＋＋は油断するとすぐメモリリークしてしまいます。メモリ管理が面倒です！（自分で全部管理できるのは良い面もあるけど…勝手にガベコレ走られたりしないし）

ちょっと最近の話に飛びますが、こういうＣ＋＋への忌避感があっただけに、Unreal Engine 4が発表された時に、コードでスクリプト書くならＣ＋＋しか使えないと聞いて、私はイヤでした。
現実問題として、今でもUE4のＣ＋＋コンパイル待ち時間は問題になってるようです。分散ビルドなどのテクを使えば緩和できるようですが。

Ｃ＋＋によるゲーム制作の壁
コンパイル待ちでイテレーション止まる

さて、Ｃ＋＋のコンパイル待ちに業を煮やしていた私は、あるアイデアを思い立ちました。
Lua言語の組み込みです。

↓参考になった書籍はこれです

Luaというのはスクリプト言語ですが、Ｃ＋＋などのプログラムに実行系を埋め込んで、実行時に動的にLuaスクリプトを読み込んでコンパイル、実行ができます。

凄いのは、コンパイルは一瞬で終わるし、実行速度もスクリプト言語とは思えないほど高速でした。
LuaとC++間のやり取りのオーバーヘッドも小さいです。
要するに、ゲームで使って問題ないくらい高速だという事です。

Luaは基本的な言語機能を持ってますが、面白いのはテーブルという連想配列機能です。
テーブルにはキーにもバリューにも好きな型を自由に入れられます。
なんなら、関数をバリューに入れる事も出来ます。
関数を持ったテーブルはクラスに見立てて扱う事も可能です。（バリューを上書きすれば継承みたいな事もできます）

そして、toLuaというツールを使えば、例えばＣ＋＋の指定したクラスのメソッドを全部Lua側に自動で公開するみたいな事も可能です。

つまり、私の計画というのはこうです。
私の手元には、自分で実装したDirectXのラッパーライブラリがありますが、この中のメソッドを全てLuaに公開してしまうという事。
そうすれば、私はもう一切Ｃ＋＋に触れなくてもLuaだけでゲームロジックが実装できてしまいます。
何が嬉しいのか？というと、あれだけイライラさせられていたＣ＋＋のコンパイル待ちから完全に開放されるという事です。イテレーション速度が爆速になります！Luaのコンパイルは一瞬だからです。

実際に試してみたら、上手い事行きました！
ちなみに、上述した通り、私は３Ｄゲーム制作には懲りていたので、２Ｄ機能だけです。

（そういえば、UE4の話に戻りますが、UE4にＣ＋＋だけじゃなく、ビジュアルスクリプトのブループリントも用意されてるのは、私がＣ＋＋にLuaを乗せた話と似てるかもしれません。ブループリントのコンパイルは一瞬で終わるので、高速なイテレーションで開発する事が可能です。）

この成功で、私は今まで散々ぶつかってきたゲーム制作上の壁を全て取り払えたと思ってました。
今までどういう壁にぶつかってきたかおさらいしましょう。
・C言語だとビジュアルが出せない！　→　Visual Basic使えばＯＫ
・Visual Basicだと３Ｄゲーム作れない！　→　DirectX使えばＯＫ
・DirectXはチンプンカンプン！　→　じゃあHSPにしよう
・HSPは３Ｄ機能が弱い！　→　じゃあLunaエンジンを使おう
・Lunaエンジンだと就活で評価されない！　→　観念してイチからDirectX勉強しよう
・３Ｄゲーム制作には結局３Ｄエディタが必要！　→　なら３Ｄは諦めて２Ｄゲームを作ればいい
・Ｃ＋＋での開発はコンパイル待ちが苦痛！　→　Lua上でゲームを実装すればＯＫ

一通りの問題が片付いたと思った私は、気を良くして一気に大作ゲームの開発を構想します！

当時の私の状況は、今考えると明らかに洗脳か何かされていたとしか思えないくらい東方に入れ込んでました。でも当時のオタクはみんなそんなもんだったんじゃないかなあ。同期の同志達とカラオケ行って「えーりんえーりん！」とか歌ってた頃です。

私は、東方の原作シューティングになにか洗脳効果が仕込まれてるんじゃないかと思ってます。つまり、シューティングゲームなので画面をずっと凝視する必要がありますが、そこに非常に美麗な弾幕模様が映し出されて、それに加えてZUNさんのあの音楽が鳴り響く事で、頭がトリップしてしまうという説です。まあこれは冗談ですが。

当時の東方の盛り上がりっぷりを説明するのは難しいんですが、二次創作音源界隈ではビートまりおとか石鹸屋が席捲しており、ニコニコ動画では二次創作紙芝居動画がドシドシ投下されており、同人誌や同人ゲームの熱量も異常でした。

私は就職で都会に引っ越してきてメロンブックスとかに行けるようになったので、そういう同人の熱量を目の当たりにしてました。

ちなみに当時崇めていた同人サークルは、徒歩二分さん、ZAZEN BEATさん、雨山電信社さん、YAYUYOさん、フミンバインさん、モスグリーンさん、Felis Ovumさん、武者プルーンさん、奴は仮名さん、めるくまあるさん、FLIPFLOPsさん、ダイオキシンさん、他多数。

というような、過熱した東方の供給を一身に受けた私が、どのようなゲームを開発しようとしたか？

「戦国ランスのシステムで東方二次創作ゲーム作ろう！」
という計画に至りました。

なぜ戦国ランスか？と言うと、当時ハマっていて、「こんなおもろいゲームがあるんか！」と思ってたから。

それから、当時は東方二次創作イラストを描くのにハマっていました。
そして、当時の私の脳内では常に消化しきれないほどの二次創作の話のネタが溜まっていってました。
ついでに言えば、当時はやっていたニコニコの東方二次創作動画みたいなのも作りたくなってました。
それでいて、やっぱりどうしてもゲームも作りたいという気持ちもありました。

「イラストが描きたいのか動画が作りたいのかゲームが作りたいのか、どれかに絞れよ！」と思われるかもしれませんが、私の計画では全てをひっくるめて満足させる事が出来るはずでした。

計画はこうです。
①戦国ランス風ゲームなので、立ち絵が沢山必要になる。立ち絵をどんどん描いて、どんどんpixivにアップする。これでイラスト描きたい欲求が満たせる。
②描いた立ち絵を使ってシナリオを実装する。シナリオが進んだらそこまでのゲームプレイ動画を収録してニコニコ動画にアップする。これは実質ゲーム制作進捗動画と東方二次創作紙芝居動画を兼ねる。これで東方二次創作欲求が満たせる。
③これをどんどん繰り返していたら、最終的には大作ゲームが完成するので同人ゲームとして販売する。

とりあえず、バトルシステムやシナリオパートの実装をやってみたら上手くいったので、立ち絵とシナリオ制作とニコニコへのアップを行いました。

この計画はかつてないほど上手くハマッていたのは確かでした。
実際に2008年～2010年の２年間くらいはずっとこの計画を進めていました。

しかし、２年くらいかけてようやく気付いたのですが、これはキリがないぞと。
当時の構想メモを見ると、妄想だけは無限に膨らんでるものの、2年でこの進捗だと、完成するまでに１０年くらいかかってしまうのでは？

いくら何でもそれはキビシイよな…という事に今さら気付いて、この計画は残念ながら頓挫しました。
二次創作がしたいならゲームじゃ無くて素直に同人誌描けばいんじゃね？みたいなアドバイスも頂いて、「言われてみればそうかもな…」みたいに思い始めてました。

二次創作ゲームの壁
構想が壮大過ぎてエターナる

そんなこんなでゲーム制作へのボルテージがやや萎み始めていた私ですが、そんな時に出会ったのがこちらの動画でした。

なんだこれは！？

美麗なグラフィックの超本格派に見えるストライクウィッチーズの３Ｄフライトシューティングゲーム！？
こんなものを個人で開発した！？
明らかに当時の同人ゲームの３Ｄゲームの水準を超えているように見えます。
魔法ですか？
学生時代にＫ君が見せてくれたテトリス以来の衝撃で、完全に度肝を抜かれました。

作者さんのコメントを見ると「Unity3Dで開発中」との事。

Unityって何だ？

これが私とUnityの出会いだったわけです。

当時はバージョン3とかだったUnityに触れてみた私は、一目でその革新性に気付きました。
何と言っても、Unityは高度な3Dエディタを搭載しています！
今まで３Ｄエディタが無いせいで３Ｄゲームの開発は実質不可能でしたが、Unityは問題を完全に解決してくれました！

さらにたまげたのは、ゲームをいちいちビルドしなくてもエディタ上ですぐ実行できる事です！
私がＣ＋＋でイライラして苦労してLuaを組み込んだのと同レベルのイテレーション速度が実現されています！

そして高度な物理演算システムや、キャラクターの制御、テレインシステムなどなど、今まで見た事もないレベルの高度な機能が至れり尽くせりで搭載されています！

これほどの神機能にもかかわらず、Unityには無料バージョンが用意されていて、基本機能は無料で使えました。
さらに、Unityはマルチプラットフォームに対応しているようで、じわじわと流行し始めていたiPhone（当時はiPhone4）上でゲームを実行できるとの事！（当時はUnityのiPhoneサポートとAndroidサポートはそれぞれ4万円のアドオン）

Androidアプリをネイティブ開発するにはjavaが必要で、iOSアプリを開発するにはObjective-Cが必要で、それぞれ習得する手間がありましたが、UnityならC#だけでマルチプラットフォーム開発できます。（まあ理想と現実は少し違うという話は当時の私は知らない）

この時期からUnityに飛び付いていた人というのは結構珍しいのかもしれません。当然、当時の私には、後々になって誰も彼も、猫も杓子もUnityを使い出すなんて事態になる事は想像できてませんでした。

私はUnityがもたらしてくれる革命性を完全に理解してさっそく飛び付きましたが、今まで散々苦労したからこそすぐにUnityのメリットに気付く事が出来たのかなと思います。
C言語や生のDirectXの問題点は実際に自分で触ってみないと気付きにくいもので、ポッと出のUnityが何がどう優れているのか判断するのは意外と難しい事なのかもしれません。

2011年の初頭、auから初めてのandroidスマホの発売が始まったので、さっそく私は機種変してみました。（悪名高いｱｱｱｯ、レグザフォン）

スマホを触ってる内に、そのゲーム端末としてのポテンシャルの高さを感じました。
当時の私は、「こりゃあコンシューマゲームはいずれスマホゲームに駆逐されるわ」と思い込んでましたが、今にして見るとそうはなりませんでしたね。

「よし、unityでスマホゲーム作って一発当てよう」と私は決意しました。
iOSアプリ開発のために、iPodTouchを買って、Macbookも買いました。
あと会社も辞めました。

初めてUnityで作ったゲームはこんなんです。

いわゆる球を割っていくゲームですね。

せっかくUnityを使ってるのに何故か2Dゲームを作ってます。
よく憶えてませんがいくつか理由が考えられます。

まず、今まで３Ｄゲーム開発にトラウマを抱いていたから。
そして構想を広げ過ぎてエターナる事にもトラウマがありますから、小さいミニゲームを作ってみたのでしょう。
さらに言うと、実は当時のスマホの性能では普通に3Dゲームを実行するのは困難で、メチャメチャ最適化する必要があったので、2Dゲームにしとくのが無難という風潮だった気がします。

とは言え、Unityには当時2D機能なんて無かったので、3D上で無理やり2Dゲームを作るという荒業が要求されました。

さてさて、Unityに出会った後も紆余曲折あったのですが、キリが無いので今回の記事では一旦ここまでにしておきましょう。

私が青春時代にゲーム制作に挑戦して、そしてぶつかった多くの困難と、それを乗り越えてきた苦労を感じていただけたでしょうか？

まとめ

さて、改めて申し上げますが、

今、はじめからUE5に触れる事ができる若者は非常に幸運です。

Unityに出会ってからの話は端折りましたが、実際はそれからもUnityで数々の壁にぶち当たりました。

例えば、作成した3Dモデルをリトポとかして最適化するのが面倒問題
→UE5ならNaniteによって最適化無しでほぼ無限にポリゴン表示可能

イチイチライトマップ焼くのが面倒問題
→UE5ならLumenによってリアルタイムＧＩできるのでライトマップのベイク不要

結局高品質なアセットが足りないからすごいグラフィックスのゲーム作れない
→UEならMegascansを無料で使い放題

いや～、私の学生時代にUE5があったらな～。

私は自分の青春時代がそれほど悪かったとは思ってませんが、ただ悔いが残るのは、ゲーム開発で立ちはだかる様々な障壁と格闘してるのに精いっぱいで、肝心のゲームの中身、本質部分に集中する事が出来なかった事です。

ゲーム開発の環境なんて時代とともに移ろっていきます。かつては生のDirectX、それからLunaのようなラッパーライブラリ、そしてUnity、UE5など。
肝心なのはゲームの中身です。本質的な部分はうつろいにくいですから。
だから私ももっとゲームの中身の部分に集中して取り組みたかったですね。

そもそも私はプログラミング自体は好きという訳ではありません。
ゲーム作るのに必要だったからやるハメになってただけです。
まあ、それで人一倍苦労こいたおかげで今はエンジニアやってるわけですが。

ただ当時、生のDirectXに真剣に取り組んで、3Dの基礎的なアーキテクチャを学ぶことが出来たのは今でも通用する知識で役立ってるかなと思います。

UE5なら、ゲーム開発初心者でもゲームの中身の部分に集中して取り組めるはずです。
ＣやらＣ＋＋やら知らなくても、ブループリントでサクサクロジックが組めますし、マケプレに行けばゲームテンプレートも充実しています。

ゲーム制作に興味ある若者は、UE5の登場という爆アドを活かして、是非ともチャレンジしてみてください。

UE5が何がどう爆アドなのか？は、この記事をここまで読んでいただいた方なら、しみじみとお分かりいただけたと思います。

私も歳は食ってしまったものの、ゲーム作りたい気持ちは今でも変わらないので、今からでもUE5で今度こそ何かを作ってみたいと思ってます！

そういえば、あれは2015年くらいの事だったかと思いますが、久しぶりにＡ君と会った事がありました。
その時に、「また一緒にゲーム制作しないか？あの頃みたいに」と振ってみました。
そしたら「…ゲーム制作……？」みたいな反応だったのが印象的でした。
学生の頃はあんなに徹夜してゲーム作って、３度の飯よりゲーム制作が好き！みたいな感じだったＡ君が。

しかし、時間が経てば人は変わるものですし、むしろいい歳こいてゲームゲーム言ってる私の方が異常なんだろうな。
劇画オバＱのラストみたいな気分になったのを憶えてます。

我々はどこから来たのか　我々は何者か　我々はどこへ行くのか

前置き

タイトルの通り、今回の記事は結論ありきです。

私はこれからの時代はゲームも多人数マルチプレイが当たり前になると思ってますが、マルチプレイゲームにはネットワーク部分の実装であるネットコードが当然必要になります。

ネットコードというのは単にプレイヤー同士がデータを送受信できればそれでOKというものではありません。
プレイヤーに快適なマルチプレイを提供するには、膨大な量のノウハウと技術が注ぎ込まれた強いネットコードを用意する必要があります。

マトモなネットコードの開発と言うのはもはやUnityでサクッとゲームを完成させたいだけの個人開発者や小規模チームの手に負えるものではありません。

私が今回の記事も含めてこれからいくつか記事を書いて主張していこうとしてる論旨は、「ネットワークマルチのゲームを作る時は、チームに専門家がいない限りはもはや自力で開発するよりプロが作ったゲームテンプレート使っといた方が良い」という話です。

話を分かりやすくするために、Unityでネットワークマルチゲームを作りたいと思ってる開発者のAさんがいるとしましょう。

もしもAさんが、将来ネットコードの専門家になりたいというなら、苦労してでも自力でネットコードを開発すべきでしょうが、単にゲーム作りたいだけなら、素直に売ってる既製ネットコードを購入した方が無難だと言えます。ネットコード開発はむやみに大変だからです。
そもそも論として、Aさんはネットワークマルチのテストが可能な環境を持っているのでしょうか？個人で家で開発してるとしたら、どうやってインターネット越しのマルチプレイをテストするのでしょうか？既製のネットコードはすでに沢山のユーザーが使っており、不具合が報告されるたびに修正されています。つまり、既製ネットコードを正しく使ってる限りは自分でテストするまでも無く高品質なマルチプレイが保証されるはずです。

自力でネットコード開発した方が良いかもしれないケースがあるとすれば、Aさんの開発チームにたまたまネットワークゲームの専門家がいる場合くらいでしょうか。
専門家って例えば誰？と言われると、例えば「オンラインゲームを支える技術」の著者みたいな方ですかね。

「でも、チームに専門家がいない場合に既製ネットコード使ってて不具合出たらどうやって直すの？」と思われるかもしれませんが、それはネットコード開発元のサポートに問い合わせするしか無いですね。サポートが死んでたら一巻の終わりなので、サポートが手厚そうなネットコードを選択した方がいいでしょう。

その辺は、言うたらUnity使ってる時点でUnityの不具合出たらバグ報告してひたすら修正されるのを待つことしかできないのでそれと同じ事だと思いますね。

さて、ネットコードと言われてもゲームジャンルごとに話が異なるので、今回の記事では分かりやすい例として格闘ゲームについての話をしてみたいと思います。
なぜ格ゲーか？というと、格ゲーは２人のプレイヤーが殴り合うゲームなので、100人バトロワとかと比べて比較的話がシンプルなので、とりあえず最初という事で格ゲーの話からやっていきます。

たとえば、開発者のAさんは、PUNの入門記事を読んで、これでネットワークマルチの格闘ゲームが作れるぞ！と意気込んで自力でゼロベースでネットマルチ格ゲー開発を始めたとします。

ここで問題なのが、Aさんはネットコードについては初心者なので、PUNの基礎だけ知ってイケそうな気がしちゃってますが、初心者であるがゆえにネットコードのあまりに闇が深い落とし穴に気付けていない事です。
「まあまあ、最初は誰だって初心者なんだから、一度は自分でやってみて、失敗したらまたやり直せばいいじゃない。」と思われるかもしれません。

しかし、これがまたネットマルチ開発の闇なのですが、ゲームの開発中は自分のPCのローカル内で遅延ゼロ、パケット損失ゼロの環境でしかテストしなかったりするので、ゲームが全部完成するまでネットコードの問題に気付かなかったりします。

３年かけて格ゲーを完成させてしまって、Steamなどで販売してみて、そして実際のプレイヤーのインターネット環境でプレイされて初めて全ての問題が噴出してしまうかもしれません。
そこで初めて貧弱な自作ネットコードのマズさに気付いても、手遅れではないでしょうか。完成したゲームのネットコードを後から既製の物に差し替えようとしても、ネットマルチのゲームロジックというのはネットコード基盤の上にべったり乗っかっていて、ほぼ差し替え不可能で、全部作り直すしか無かったりします。

そういう訳ですので、私はことネットコードについては、「まずは自作してみてダメだったらやり直せばいい」論については、上手く動かない事に気付いた時には手遅れになりがちなので、リスクが大きすぎると思ってます。

「でも初心者ゆえに罠にハマってしまうんだったら、最初から専門家になるまで勉強してからじゃないんとネットマルチのゲーム作っちゃダメなの？」と思うかもしれませんが、別に強いネットコードが自作できるくらいまで勉強する必要はありませんが、少なくとも適切なネットコードの選択ができるくらいにはざっとネットコードの概要だけでも把握しておくと良いかと思います。

私も全然ネットコードの専門家ではありませんが、最近は趣味と仕事を兼ねてネットコードについて色々と調べてます。

初心者の方でも罠を踏まないで済むくらいの情報を提供できればと思って今回の記事を書いてます。

Universal Fighting Engine 2（UFE）について

さて、Unityで有名な格ゲーのネットコードというと、アセットストアで売ってるUniversal Fighting Engine 2（UFE）が有名ですね。

値段の異なる色んなバージョンが売っててややこしいのですが、値段と機能の比較表はこんな感じです。

59ドルのライト版から99ドルのベーシック版に上げると、高度な敵AIが使えるようになるようです。

ベーシックから199ドルのスタンダード版に上げると、ネットワークマルチができるようになります。

スタンダードから349ドルのプロ版に上げると、”ロールバック”のネットコードが使えるようになります。今回の記事では重要なポイントです。

そして、プロからソース版に上げると、ソースコードにアクセスできるようになります。

親切な事に、下位バージョンから上位バージョンへは差額でアップデートできるはずです。

UFEの例えばプロ版349ドルという値段は、アセットストアのアセットの値段として考えるとメチャメチャ高いように見えるかもしれませんが、ネットコードの値段として考えるとメチャメチャ安いです。

格ゲーの有名な既製ネットコードとしてはGGPOというものがありますが、これのライセンス料は公開されてないので分かりませんが、恐らく桁違いに高かったはずです。（ただしGGPOは2019年に無料オープンソース化されました）

ちなみに、この記事を書いてる時点で、ちょうどUFEのライト版とスタンダード版とプロ版が半額セールになってます（7/6まで）

さて、あらかじめ断っておきますが、私はUFEを実際に触った事はありません。
それでも、開発者Aさんと同様の立場で自作ネットコードとUFEどっちにすべきか？という判断の話くらいはできると思います。

とりあえず、UFEのプロ版のストアレビューに目を通してみました。
おおむね好評みたいです。機能面で不満を言ってる人はあまりいないようですが、ドキュメントとサポートが不足している事について不満がある人が一杯いますね。
サポートが不十分な可能性…これはぶっちゃけ不安要素ですね。

レビューの次はスペック、機能面に目を向けてみます。
UFEは高機能な格ゲーエンジンですが、今回の記事ではネットコード周りについて重点的に確認しましょう。
↓UFEのネットコードについてのドキュメントはこちらです。

http://www.ufe3d.com/doku.php/global:netcode

これによると、まずUFEは独自の決定論的物理学が実装されているようです。さらに、遅延ベースのネットコードと、プロ版以上で使えるロールバックネットコードの２種類のネットコードが使えて、それらを組み合わせる事もできるそうです。

素晴らしいですね！

実際の通信についてはIPアドレス直打ちの素のP2PまたはPhoton Cloud(PUN)の２種類が選べるようです。

いきなりよく分からん用語を並べられても、何がすごいのかよく分からないかもしれませんが、これについては後で解説したいと思います。

UFEの機能面もわかった所で、次は、「そんで実際にUFE使って作られたゲームってあるんだっけ？」という点を調べてみましょう。

私がググった限りでは、残念ながらUFEが実際に売られてるゲームで使われてる例は一つしか見つかりませんでした。

それは、Fight of Godsです。

世界中の宗教の神々がバトルするという、ネタ感満載のゲームですが、中身はかなり真面目な作りだそうです。Steamのリリース日は2019/03/28と書かれてます。UFE製だけあってちゃんとネットマルチに対応してます。Steam以外にも、Switch版、PS4版、さらにアーケード版も発売されているそうです。
かなりちゃんとしたゲームのようですね。

チラッとSteamのレビュー欄を見る限りでは、ネットマルチに対して不満を書いてる人は見当たりませんでした。これは快挙だと思います。まあ、ネットマルチに対応したのがかなり最近らしいのでレビューで触れられてないだけかもですが。

UFEの実績がこのゲームしか見つからなかったのは残念ですが、UFEでどんなゲームが作れるのか知りたい方はとりあえずUFEを触る前にこのゲームを遊んでみておくと良いのではないでしょうか。

さて、UFEがどれくらい良さそうなのか？について、アセットのレビュー、機能スペック、採用実績の３つの観点から眺めてみましたが、いかがでしょうか？
「いい所もあるけどサポートがダメらしいし分からないな」って感じでしょうか。まあ私もそう思いましたが、少なくともネットコードの機能については私は素晴らしいと思いました。

何と言ってもロールバックメカニズムを搭載してる所がすごいです。
ロールバックって何なの？何がすごいの？という所を次から話していきます。

GGPO（Goodgame peaceout）について

さて、格ゲーのネットコードには大まかに遅延ベースのものと、ロールバックのものがあると分かりました。
どっちがどうなの？と言う話の前に、一旦、有名な格ゲーネットコードの一つであるGGPOの話をしたいと思います。
↓GGPOの開発者のインタビュー記事がこちらにあります。

https://www.gamasutra.com/view/news/124368/Interview_How_A_Fighting_Game_Fan_Solved_Internet_Latency_Issues.php

かいつまんで内容を書くと、GGPOを開発したトニーさんは、元々格ゲー大好きでした。
カプコンが2005年ごろにネットマルチに対応したスト２を発売してくれて、トニーさんは大喜びでした。「これでアーケードじゃなくても家でネットマルチでスト２対戦できる！！」

しかし、実際にネット対戦してみると、ラグが相当ひどくてマトモに遊べませんでしたので、トニーさんは落胆しました。

さて、一旦インタビュー記事の内容から離れますが、当時の状況について考えてみます。
当時は格ゲー作ってるのは日本のゲーム会社だけで、格ゲーのネットコードは大抵が遅延ベースだった感じだと思います。（遅延ベースがどういうものかは後で説明します。）

ここでポイントになるのは、何故トニーさんの手元でマトモに遊べないような問題を、発売に至るまで日本のゲーム会社が気付けなかったのかという点です。

先ほどのAさんの例では、ローカルPC内でしかテストしなかったのが原因でしたが、カプコンみたいな立派なゲーム会社はさすがにもっとちゃんとテストしてるハズで、例えば開発者同士が自宅からインターネット対戦してみて問題ないか確認するくらいはしていたはずです。

“とはいえ”、所詮は日本の国内同士での通信だっただろうと思われます。

国内のpingの速度を今測定してみましたが、ウチから北海道でも22msで、福岡でも21msです。

pingは通信の往復にかかった時間なので、片道なら半分、つまり私が北海道の人と対戦したら、パケットが相手に到達するまでに11msしかかかりません。
60fpsのゲームならフレーム時間は16.6msなので、遅延はたったの1フレームに収まります。

私はあまり格ゲーをやらない人間なので適当ですが、1フレームの遅延ならほぼ気にならないでしょう。その場でローカルマルチで遊んでるのと同じプレイ感で遊べるはずです。

これが当時の日本のゲーム会社が格ゲーのネットコードは別に遅延ベースで問題無いだろうと考えた理由だと思います。つまり、国内でテストしてる分には全く問題なく快適に遊べるから、問題が発覚しなかったのでしょう。

一方、アメリカでプレイした場合はどうなるでしょうか。
アメリカは国土が広いので、西海岸から東海岸までのpingは67msくらいかかります。これだと、パケットが相手に到達するまでに2フレームかかります。

さらに、日本とアメリカ間でプレイしたらどうなるでしょうか。pingは130msくらいに達してしまうらしいです。
これだと、パケット到達は4フレームもかかります！
4フレームも遅延すると目に見えて反応が遅れるのが分かって、格ゲーみたいにタイミングがシビアなゲームだと相当ストレスが大きくなってくると想像できます。

つまり、当時の格ゲーのネットコードが遅延ベースで良しとされていたのは、国内で遊ぶ分には問題なかったからで、でもワールドワイドで発売してみたら無視できないくらい遅延が大きいケースがあって、快適に遊べなかったという事です。

格ゲーマーにとっては光は遅すぎるという話がありますが、そういう事ですね。

はてさて、トニーさんのインタビュー記事の内容に話を戻します。
スト２のマルチプレイにガッカリしたトニーさんは、自分だったらもっといいネットコードを書けるかもしれないと思ってGGPOの開発を始めました。

GGPOには”ロールバック”というアイデアが搭載されていました。
遅延ベースだと、pingが高い対戦相手の場合は、スティックを倒してからキャラが動き出すまで何フレームも待つハメになってイライラしますが、ロールバックだとネットマルチにも関わらず、スティックを倒した瞬間に遅延ゼロで自分のキャラが動きます。
まさに魔法のような技術です。

トニーさんはこのような素晴らしいGGPOを開発してゲーム会社に売り込み始めて、今ではカプコンやバンナムの多くのゲームがGGPOによるロールバックネットコードを採用しています。スカルガールズも採用してます。

ちなみにGGPOはそれなりにライセンスが高額で、ライセンス料が高くて採用できないゲームもあったようですが、2019年にGGPOはMITライセンスでオープンソース化されました。
これにより、ますます多くのゲームがGGPOを採用していくかもしれません。

そうして、トニーさんは快適なネットマルチで格闘ゲームを遊べるようになったとさ。

めでたしめでたし。

ネットマルチ対応格ゲーを作るための前提条件とは？

諸々の説明が終わった所で、実際の格ゲーネットコードの話に入っていきます。

というか、こちらに素晴らしい格ゲーネットコードの解説記事がありますので、こちらを元に解説する感じです。↓

https://web.archive.org/web/20141212191217/http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/

まず、遅延ベースだのロールバックだのの以前に、実装しておかなければならない前提条件が存在します。

それは、ゲームを決定論的に実装しておかなければならないという事です。

決定論的実装については以前に書いたブログ記事でPhoton Quantumの説明で出た話ですが、まさにあれと同じ話です。

決定論的とはなにか？というと、”入力が同じなら、出力が同じであることが保証されている”という事です。

Unityで普通にゲームを作ってると、決定論的な実装にはなりません。
何故なら、まずUnityの物理エンジンが決定論的ではないからです。実行環境によって、同じ入力でも微妙に出力が違ってきたりします。
それと、Unityは可変フレームレートがデフォルトです。つまり、Time.deltaTimeを使って、フレームレートが上下しても1秒間のプレイヤーの走る距離が変わらないように実装できます。
これは便利ですが、決定論的な実装とは相性悪いと思います。決定論的実装だと固定フレームレートが必要になるんじゃないかな。

[追記 21/07/04]
決定論的実装にとってもう一つの大きな問題、”浮動小数点問題“もあります。
ゲームを完全に決定論的に実装したつもりでも、float（浮動小数点）を使ってる時点で、もはやCPUアーキテクチャが異なるマシン間では誤差が出てしまうので正確に同期できなくなる問題です。
つまり、x86のCPUを搭載したWindowsマシンとARMのCPUを搭載したWindowsマシンでは同期できなくなるかもしれません。

ただ、コンパイラでIEEE754準拠モードを強制してコンパイルすれば問題を回避できるらしいです。
とは言え、それはfloatの計算の最適化を無効にする事を意味するので、浮動小数点の演算速度がガタ落ちしてしまうようです。
↓詳細はこちらの記事をご参照ください。
Floating Point Determinism

さらに、コンパイラ云々の話はC++とかの場合に可能な話で、一般的に言ってC#だとどうしようもないみたいです。何故ならC#がビルドして生成するのはネイティブコードじゃなくてILという中間言語であって、ゲームを実行するマシン上のそれぞれのJITコンパイラがILを解釈して実行するという仕組みだからです。参考↓
Coercing floating-point to be deterministic in .NET?
[追記ここまで]

ゲームが決定論的実装だと、例えばゲームのリプレイ機能なんかも簡単に作れるようになります。
東方の原作シューティングゲームでは、リプレイ機能がありますよね。あれのリプレイデータの中にあるのは、プレイヤーがどのフレーム数でどのキーを入力したかの入力情報だけです。
決定論的実装なので、入力情報さえあれば、何度でも同じゲーム内容をシミュレートできるという訳です。
東方も固定フレームレートなので、処理落ちすると普通にゲームが遅くなりますよね。

ちなみに、決定論的実装ではランダム要素は使えません。ランダム要素があると毎回結果が変わってしまうからです。ただし、乱数テーブルを使えば疑似的にランダム機能が使えます。

さて、それでどうしてネットマルチの格ゲーには決定論的実装が必要なんですか？と言う話です。
ゲームが決定論的なら、マルチプレイで送るデータはお互いの入力データだけで済みます。

決定論的じゃなかったら、お互いのキャラの現在の座標やステータス、アニメーション、とにかく同期に必要な全てのデータを毎回送るハメになります。

相手に最速でデータを送りたければ、データは小さい方が良いです。
それに、入力じゃなくお互いの状態を送る方法だと、チートできてしまいます。送信データを改竄して、常にHPマックスにすれば、自キャラを無敵にしたりできちゃいます。入力データだけをやり取りする方法ならそういうチートは不可能になります。

さらに言えば、決定論的なゲームであれば、自由にゲームを巻き戻したり、進めたりできるはずです。
「もしも相手が４フレーム前にパンチボタンを押していたとしたら、現在の画面はこうなってるハズ」みたいなシミュレートが自由にできます。

このようなシミュレート機能がロールバックネットコードには必須になります。まあ遅延ベースなら必須では無いかも。

なんか色々とややこしい話が出てきて混乱されている方もいるかもしれませんが、要するに私がここで言いたい事は、ネットマルチ格ゲーは前提として決定論的に実装する必要があるけど、Unityで決定論的実装するのはそれだけですでにかなり難しいという事です。

でも、UFEを使えば決定論的実装がされているので心配無用です。

遅延ベースのネットコード

さて、例のトニーさんを落胆させた遅延ベースのネットコードを見ていきましょう。

まあこれはシンプルなんで難しくないです。

例えば、私とAさんがネット対戦するとします。
私からAさんまでのパケット到達に３フレームかかるとします。まあ予備のバッファとして１フレーム足しておいて、４フレームの遅延を設定しましょう。

すると、単にゲームの進行は私の入力から４フレーム遅延して実行されます。
それだけです。

ちなみに格ゲーの通信はシビアなのでTCPだとお話にならないのでUDP通信である事が前提中の前提です。
とはいえ、もし私が送信したパケットが相手に届かずに損失してしまったらどうしますか？
いくら入力だけ送り合えば同期できる決定論的ゲームでも、肝心の入力が送れなかったらもう同期が崩壊しちゃうんじゃないですか？

心配ご無用です。それなら、いつ損失してもいいように、常に過去５フレーム分とかセットで入力データを送ればいいのです。どうせ入力データのサイズは小さいので５倍になっても大したことありません。
これなら、あるフレームのパケットが届かなくても、次のフレームに過去のフレームのデータも含まれてるのでシミュレートできます。
ただし、届かなかったフレームはシミュレートが進められないので画面が止まります。

↑この図を見ると分かりますが、まずパケットが届かなかった方の画面が１フレ止まってから、辻褄を合わせるために次のフレームでもう一方の画面も１フレ止まります。

ちなみに、画面を止めないテクもあります。
例えば、届いたパケットを常に１フレ待ってからシミュレートするというテクです。
そうすれば、どこかでパケット損失が発生しても、すでにその次フレームで表示すべき入力情報は届いているので、画面を止めなくて済みます。

これらの工夫でパケット損失の問題は上手い事行きそうですが、実は他にも問題があります。
処理落ちの問題です。
相手側のプレイヤーで処理負荷が高まって１フレームだけフレーム落ちしたらどうなりますか？

ちゃんと相手がフレーム落ちした事を検知しないと、自分と相手のゲーム内容が段々ズレていってしまいます！
これを検出するためには、送信パケットに自分のゲームの進行フレーム数を含めておきましょう。
例えば、自分の進行フレーム数が100フレだとします。それで設定した遅延数が4だとすると、相手から今回届くのは96フレのパケットのハズです。
でも、95フレのパケットが届いてしまいました！
この場合、相手がフレーム落ちしたらしいな…と分かります。しゃーないので、こちらも1フレ画面を止めてあげて辻褄を合わせる必要があります。

さて、元記事によると遅延ベースのネットコードの技術はこんな感じです。色んな工夫してるんだな～と感心しますが、とは言え結局4フレーム遅延しちゃうのはどうにもできてません！

というわけで次は魔法のテクノロジーであるところのロールバックネットコードを見てみましょう。

ロールバックネットコード

ロールバックのネットコードは遅延ベースの遅延を何とかするために考案されました。

ロールバックでは、なんと遅延ゼロでのゲームプレイが実現できます。
しかし、そうは言っても私とAさんの間にはパケット到達までに３フレームの時間差が発生するはずです。一体どういう事なんでしょうか？

↑ロールバックのメカニズムについて解説するために、こういう状況について考えてみます。私と対戦相手のAさんは、０フレーム目にお互いまったく同時にパンチボタンを押したとします。この画面は私の側です。私側のゲームは私がパンチボタンを押した事は認識していますが、相手がこのタイミングで何を入力したのかは当然ながら不明です。

↑２フレーム目です。私のパンチモーションが発生中ですが、相手の０フレーム目の入力は未だにこちらに届いてません。なので相手は棒立ちのままです。

↑３フレーム目です。ここでようやく相手の０フレーム目の入力が届いて、実は相手も０フレーム目にパンチボタンを入力していた事が分かりました。すると、今まで棒立ちだった相手がいきなりノーモーションでパンチ出してます！相手の動きが飛んだように見えますが、たしかにお互いが０フレーム目でパンチボタンを入力していたので、この時点で辻褄が合いました。これがロールバックです。
ちなみに相手の画面でも全く同じ現象が起きてるハズです。

一体何が起きたかと言うと、実は相手の入力が届いた時点で、ゲームは内部的に０フレームまで巻き戻されました。それで、まるで過去を改変するがごとく、相手が０フレーム目にパンチボタンを押していたとしたらどうなっていたか？という前提でまた現在のフレームまでシミュレートを進めます。すると、このような結果になるという訳です。

このように、相手の入力データが届くたびに常にゲームが過去に巻き戻って（ロールバック）再シミュレートされるのがロールバックネットコードです。

ちなみに、相手の最後の入力データから現在フレームまでの相手の行動は適当な予測で埋められます。予測って何か？というと、そんなに難しい予測はしてないと思います。相手が何も入力してなければその後も何も入力してないだろうと予測するし、相手が左にスティック入れっぱなしだったらその後もずっと左にスティック入れっぱなしだと予測されるでしょう。

さて、このロールバックネットコード、遅延ゼロで遊べるのは素晴らしいですが、常に過去改変されちゃうのが問題と言えば問題です。

例えば、自分がヒット発生まで時間がかかる大パンチを放ったとします。相手は棒立ちです。
これは完全にヒットして相手が吹っ飛んだ…やったぜ！と思ったら次の瞬間吹っ飛んでたのは自分だった…なぜ？
実はこちらが大パンチを打った直後に相手が発生の速い小パンチを打ってきていたからでした。
みたいな理不尽なケースも高pingの環境では起こり得ますね。

そうは言ってもロールバックネットコードの恩恵は大きいようです。
↓こちらでは何故か近所の友達との間のpingが300ms超えな環境での遅延ベースネットコードのゲームプレイとロールバックのゲームプレイを比較しています。

https://www.resetera.com/threads/an-example-of-how-good-rollback-netcode-can-make-high-ping-connections-playable-in-fighting-games.161146/

違いは一目瞭然ですね。

もっとロールバックネットコードについて詳しく知りたい方はこちらの動画がオススメです。

自力でこれを実装できるだろうか？

さて、ここまででネットマルチ格ゲーを作るために必要な、決定論的実装の話や遅延ベースネットコード、ロールバックネットコードの話を見てきました。

これらの技術について、この話を聞いて「なるほど、分かった」と言ってゴリゴリ実装できる人がいたとしたら相当な天才なのではないでしょうか。

そのような天才以外の方は、とりあえず自前で作るよりUFE2使ってみるのが無難な気がしますね。

UFEならこれらのややこしい技術が全部搭載されてますからね。
ちなみに、UFEのドキュメントによると、ロールバックネットコードに遅延ベースを組み合わせるのが一番良さそうだと書かれてます。何故かというと、高ping環境の対戦だと、かなりのロールバックが発生してしまうので、対戦相手がワープしたりする現象が頻発してしまうので、それなりに遅延も入れておくことで理不尽なワープ現象を軽減できるからとの事です。

しかし、UFEで私が一つ気になるのは、通信方法が素のP2P以外ではPUNしか用意されてない事です。
PUNを使うと必ずリレーサーバを経由して通信してしまうので、遅延が悪化します。これは上で書いた通り、格ゲーだと結構クリティカルです。それよりは、NATパンチスルーで簡単にP2P接続できる手段を用意してくれたらありがたかったですね。

というわけで、今回の記事は、「Unityでネットマルチの格ゲー作るならとりあえずUFE2使っとくのが無難じゃないか」という話でした。

今回は格ゲーについてでしたが、今後は他のジャンルについても、ネットコードは闇が深いから下手に自作するより専門家が作ったゲームテンプレート使った方がいいよという話をしていこうかなと思っています。

この記事がなにかの参考になれば幸いです。

前置き

例によって今回も前置きが長くなりそうなので、まあ読み飛ばしていただいても構いません。

個人でゲームを作っている人と、ゲーム会社とでは、作れるゲームに格差が生じます。

基本的に、人員と資金の潤沢なゲーム会社には、一人ぼっちあるいはごく少数人数での個人開発で対抗するのは難しいです。当たり前の話ですね。

しかし、どれだけでっかいゲーム会社だって、その始まりは個人開発レベルでスタートしたはずです。どうやってもゲーム会社と個人で格差があるように見える現在でも、新興のゲーム会社は次々に生まれています。

開発能力に絶対的な格差があるとしたら、なぜ資金も人員も足りていない新興ゲーム会社がその市場に食い込める余地が生じるのでしょうか？

その理由は、「社会では時々技術革新によって大きなうねりが生じる」からです。

技術革新と言うのは、トランプの大富豪における”革命”のようなものです。普段は勝ち組と負け組の間にはハッキリと壁があって、弱者が強者と入れ替わるチャンスは殆どありません。
しかし、大富豪で革命が起きるとその瞬間に弱者と強者が入れ替わって、立場がシャッフルされうる”チャンス”がそこに生じます。

社会に大きな影響を与えて我々の生活を変えてしまうような技術革新であるほど、そのチャンスも大きいものになります。

つまり、新興の会社というのは、元はと言えばそのチャンスの存在が目に見えていて、チャンスに手を伸ばした人達であるという事です。

もっと具体的な話をしましょう。

2006年ごろ、すでに家庭用ゲームの市場は強大なゲーム会社達に牛耳られており、新規参入は難しい状態でした。
しかし、ガラケーでソーシャルゲームを提供するというチャンスに目を付けたいくつかの企業がありました。グリーやモバゲーです。私は世代じゃなかったので詳しくないですが、元々はSNSが先にあって、そこにソーシャル要素のある簡単なゲームを乗せてみたという感じだったみたいです。
いわゆるソシャゲの走りです。
ガラケーのiモード上で提供されるようなゲームなので、見た目としてはショボくて、家庭用ゲームを作ってた会社からすると鼻で笑われるようなものだったかもしれませんが、実際は見た目の問題じゃなくて、それまでに無かったソーシャルなゲーム性が与えてくれる新しい体験が支持されたという事です。
家庭用ゲームはゲーム機を買わないと遊べませんが、携帯電話はみんな持ってたので、今にして思うとそこにはビッグチャンスがあった事は明らかです。

2011年ごろには、Cygamesがガラケー向けに「神撃のバハムート」や「アイドルマスター　シンデレラガールズ」をリリースしてます。すでにガラケーソシャゲもクオリティによる差別化が必要になっており、個人レベルのチャンスは無くなってきていた時期でした。
しかし、ガラケーと入れ替わるようにiPhoneやAndroidのスマホ端末が登場しました。
あらためて説明するまでもなく、スマホによる技術革新の社会への影響は大きく、つまり個人開発者にも大きなチャンスが生まれた時期でした。
ガラケーアプリからスマホネイティブアプリへの転換期です。
このビッグウェーブに乗って成功した個人開発者も多かったと思いますが、私自身はそれほど上手く波に乗れたという感触はありませんでしたが、この波のおかげでUnityの需要が急激に高まって、私もUnityエンジニアとして働く事になったという恩恵はありました。

2014年には、Unityがバリバリ盛り上がってた時代にいきなりUnreal Engine4がリリースされました。（たしか当時は無料じゃなくて月額3000円のサブスクだった）
Unreal Engineはそれまではあまり個人で使うようなゲームエンジンという印象がありませんでした（無料のUDKもあったけど非商用オンリー）が、バージョン4で個人でも使用可能な価格で、技術的にも非常に高度な機能が搭載されて登場したので大きな衝撃がありました。
このUnreal Engine4の技術革新に速攻で食いついて活動していた人の中には今では大きく成功している人もいます。
私もずっとUE4は気になってはいつつも（パシフィコ横浜のUnreal Engine Festには毎年行ってた。タダだったし）Unityの仕事に追われてこの波にも上手く乗れませんでした。

同じころ、OculusがVRヘッドセットのOculus Riftの開発者向けキットの販売を開始しており、VRのビッグウェーブが始まろうとしていました。
私はたまたまゲームジャムで同じチームになったゆーじさんにOculus Riftを体験させてもらって、「これは面白い！」と思ってかなり食いつきました。
当時のVR界隈と言うのは面白くて、VRの未来に可能性を感じまくって自主的にVRの伝道師、エヴァンジェリスト的活動をやっている方々もいました。彼らVR個人開発者のこのような地道な活動がVRの認知度向上に繋がったので、その貢献は大きかったと確信しています。
私も界隈で色んな人と出会えたりして面白かったです。
VRのビッグウェーブもかなり大きなものでした。私も波に乗っかって、VRで3Dモデリングができる「Artstage」というアプリを作ってSteamでリリースしました。ですので一応波に乗ったと言えば乗ったと思いますが、それだけで食えるというほどのものではなかったです。
ちなみにOculusは、それまで散々個人VR開発者の恩恵に預かってきて、個人開発者との関係を大事にしていたはずなのに、正式版のRiftやGearVRを発売してOculus Storeを立ち上げると、「もう個人開発のしょぼいアプリは受け付けないよ」みたいな態度を表面化したように感じます。
Quest向けアプリも事前審査が必要になって、個人開発者が相手にされてない状況が強くなって、もうVRでは個人開発者のチャンスはあまり無さそうだなという印象があります。（でもAppLabでやっと個人開発アプリも受け付けてくれるようにはなったけど）

直近で大きな波だったと思うのは、vTuberブームでしょうか。2018年ごろからの現象だったかと思います。
当時はVRの波に可能性を感じて大きく投資を広げていた企業も増えていましたが、結局のところ、VRでのキラーコンテンツが見つからなくて、VRで何をやればいいのか模索の時期でした。
そこに、VR技術を応用してリアルタイムでキャラクターを動かすvTuberが登場して、その領域に一気に注力し始めた企業も増えました。

はてさて、こういう波以外にも、世の中ではディープラーニングの波とか仮想通貨の波とかまあ常に色んなチャンスの波が生じていたわけですが、キリが無くなるのでこれくらいにします。

ことゲームに関して言えば、最近はあまり大きなチャンスの波は起きてなくて、硬直化した状況にあると思います。
と言うのも、家庭用ゲームは相変わらず順当に進化を続けており、クオリティで殴りあうような戦いになっており、とても大変です。
スマホゲームも、原神などを見ればわかる通り、もはや求められるクオリティは家庭用ゲームと遜色ないレベルになってしまいました。
つまり求められる資金も人員も肥大化しており、レッドオーシャンと化しており、個人が食い込めるチャンスと言うのは小さいという事、つまり新規参入が難しくなってます。

さらに今私が懸念しているのは、ゲームのクオリティ云々を超えた次元で、ゲーム会社と個人開発者の間に決定的かつ致命的な格差が生まれつつあるのではという事です。

それが何かと言うと、「サーバーインフラ格差」です。

私はこれからの時代はゲーム会社のゲームだろうが個人開発だろうが、”マルチプレイヤーが当たり前”になっていくと思ってます。
マルチプレイヤーゲームを作るとなると、そこには何かしらのゲームサーバーが必要となり、つまりサーバーコストを払うハメになります。

最近流行っているバトルロイヤルゲーム、フォトナやフォールガイズでは、公式が用意した専用サーバ上でのみ遊べます。
専用サーバのホスティングには膨大なコストがかかりますが、何故バトルロイヤルゲームがそのようにしているかと言うと、チートを根本的に防ごうと思うと公式専用サーバが確実かつ手っ取り早いからです。

しかし、このようなゲームを個人で開発、運用する事って可能なんでしたっけ？
よしんば、めっちゃ頑張ってAWSを駆使してバトロワゲーム開発に成功したとしましょう。
それを、フリーで公開してtwitterで宣伝したら、メチャメチャバズッてサーバに人が殺到して、結果的に月額100万円のAWS代が請求されてしまいました！
いくらサーバ代が高くても、それだけプレイヤーを集客できたという事なので、長期的にはマネタイズして利益を出していく事は可能でしょうが、短期的に毎月100万円のコストを個人開発者が吸収する事は無理でしょう。
つまり、バトロワゲームのサーバコストのリスクを個人開発者は背負いきれないので、個人でバトロワ作るのは不可能という事です。

そんなわけで、私はこれからのマルチプレイヤー当たり前時代では、個人と大きなゲーム会社の間ではどんどん格差が広がっていって決して埋まらない不平等になっていくという懸念がありました。

そういう事を考えていた中で知ったのが、Epicが提供しているEpic Online Services（EOS）です。
EOSの提供するマルチプレイヤーシステムでは、無料かつ無制限に、リレーサーバも提供してくれます。

つまり、リアルタイムゲームサーバはタダで使えるようになったという事です。
無論、ホスティングされた専用サーバとリレーサーバでは話が違います。リレーサーバによるP2Pマルチプレイヤーではチートを排除しきれません。
とは言え、専用サーバまで用意して、チートを完全に排除する必要があるのはバトロワが競技性が高いゲームだからであって、例えばモンハンみたいな協力プレイのマルチプレイヤーならP2Pマルチでも十分かもしれず、ゲームの仕様次第です。

私はこれを知って、「Epicって気前がいいんだな～」と感心していましたが、そこに追い打ちをかけるように先日発表されたのが、EOSでのアンチチートとボイチャの提供です。

Epic Online Services が2つの新しい無料サービスを追加します

先ほど、フォトナは公式専用サーバだから、根本的にチートが防げると言いましたが、実はそれだけだと不十分で、何故ならクライアント側だけで出来ちゃうチート（ウォールハックなど）があるからです。

ですのでフォトナではEasy Anti-Cheatというアンチチートソフトも導入して、クライアント側でのチートを防いでいます。このようなアンチチートソフトのライセンス料は目玉が飛び出るほど高いという噂で、インディーゲーム開発者には手が出ないものでした。

それが無料。

ボイチャも同じような話で、メチャメチャコストがかかるものでしたが、無料になってしまいました。

「そんな旨い話があってたまるか！」と警戒したくなるほどの旨い話です。
Epicは、マルチプレイヤーゲームの開発でネックになるインフラコストなどを次々と無料化していってます。
この恩恵を受けるのは、個人開発者もゲーム会社も同様ではあるものの、実際には元々金を持っていたゲーム会社より金の無い個人開発者の方がアドバンテージが大きいです。

つまり、Epicは私が懸念していたような、サーバインフラコストにより広がりつつあった個人と会社のマルチプレイヤーゲーム開発格差問題を解消してくれたという事です。

私はこれはEpicが生み出してくれた新しいチャンスの波だと思います。

今すぐこのチャンスに食いついてUnreal EngineとEpic Online Servicesを駆使してマルチプレイヤーゲームを作ったら面白い事になるかもしれないなという事です。

「でも、それだったら今までUnreal Engineをずっとやってた人にアドバンテージあるんじゃないの？」と思われるかもしれませんが、ある程度はそうですが、EOSに関しては今からでも出遅れないと思います。何故なら、EOSはSDK自体は前からあったものの、ずっとUEやUnityへの統合プラグインが用意されてなかったので、殆どの人は手が出なかった状態だったからです。
そして、ちょうど今、EOSがUEに統合されつつあり、（UE5EAにEOSプラグインが入ってる。ただしまだドキュメントは無い）もうじきUnity統合プラグインも完成するはずなので、今からでも間に合います。

「スマホゲーム会社だってすぐ食いついてくるんじゃないの？」とも思われるかもしれませんが、スマホゲーム会社は必ずしもリアルタイムマルチプレイヤーゲームのノウハウを持っているとは限りません。
原神みたいなオープンワールドマルチプレイヤーゲームやフォトナのようなバトロワゲームの流行に合わせて開発をすぐさま転換できるかは分かりませんが難しいかもしれません。

それに、ゲーム会社なら別にEOSによる無料化とか関係なく、マルチプレイヤーゲームをやりたかったらすでにやってるはずです。

Unityをずっと使っていて、Unityエンジニアを大量に雇用している会社がUEに転換できるか？というと、それもまた難しいかもしれません。個人開発者なら、UEで作るとなれば単にUEをやればいいだけなので簡単です。（ちなみにEOSはUEでもUnityでもなんでも使えます）

そんなわけで、今回のEpicが作ってくれたチャンスの波は、決してビッグウェーブではないかもしれませんが、意外と気付いてる人が少なくて、だから乗ってみるのも面白いかもしれないなという話でした。

さて、クソ長い前置きが終わった所で、本題に入ろうかと思います。

ここまで話した通り、Epicは無料のEOSで、本来ならメチャクチャ膨大な金額がかかるインフラコストを、全て肩代わりしてくれるそうです。

これは、実質的にゲームを作ろうとしているあなたに対して、凄い金額の札束をポンとくれているのと同じ状況です。
面白いのは、ゲームを作らない人は１円ももらえない事です。当然ですが。
ゲームを作ってリリースすれば、事実上メチャメチャお金がもらえる事になります。そして、ゲームが人気になればなるほどメッチャ大量のお金をもらっている事になります。

Epicが純粋にゲームを作ろうとしている人を応援しようとしてくれている気持ちが表れてる施策だな～と感じますね。

↓こちらの記事では、Epicみずからが、「人気ゲームだとボイチャとアンチチートで数百万ドルかかりますが、EOSでは無料で提供します」みたいな事を言ってます。

https://www.gamasutra.com/view/news/383914/Epic_Online_Services_expanded_with_free_anticheat_and_voice_chat_tools.php

しかし、どれだけ私がここで爆アド！爆アド！！と叫んでもイマイチピンと来ない方もいらっしゃるかもしれないので、実際の金額ベースで、Epicが与えてくれる恩恵に全力で乗っかると、どれくらいのお金がもらえてる事になるのかざっくりと算出してみたいと思います。

Epicの恩恵に乗っからない場合はどれくらいのコストがかかってしまうのか？という話でもあります。

Epic Online Services(EOS)

先に、どんなゲームを作る事を想定するかを決めたいと思います。
まあ何でもいいですが、Valheimみたいなサンドボックスサバイバルゲームで、これを私が作った結果、何かの間違いでメチャメチャ売れてしまったとしましょう。
RustみたいにPVP重視のモードも入れた結果、割とチートする人が出現して、チート対策も重要になったとしましょう。ボイチャもできます。そういうゲームです。

Epic Online Servicesについては別にUnreal Engineでゲームを作る必要は無く、Unityでも利用できます。

・リレーサーバ

リレーサーバ代については、同じくリレーサーバを提供してるPhotonCloudと比較してみます。

https://www.photonengine.com/ja-JP/Realtime/Pricing

PhotonCloudは2000CCUのプランで月額67,532円です。そのようなゲームを仮に3年間運用したとすると、243万円かかります。EOSならタダです。

リレーサーバ代としてEpicから実質243万円もらった。

・アンチチート

EOSが提供するアンチチートソフトは、Easy Anti-Cheatという、フォトナやApex、RUST、Dead by daylightで採用されている最高級のアンチチートソフトです。

高級なアンチチートソフトはOS上のアプリケーションレベルを超えて、OSの下のカーネルレベルで動作するので、チート検出能力が段違いです。

このようなアンチチートソフトが本来いくらなのか？というと、問い合わせないと教えてくれないので分かりませんが、↓こちらのredditスレでは、とあるアンチチートソフトの値段は月額6千ユーロ（約78万円）だったという噂です。

この噂ベースで算出してみると、アンチチートソフトへの３年間の支払いは2808万円となります。

アンチチートソフト代として、Epicから実質2808万円もらった。

・ボイチャ

ボイチャはVivoxが有名ですが、Vivoxも5000CCUまでは無料で使えるので太っ腹ですが、それを超えちゃうと一気に高額な料金がかかってきます。
発表されてる価格イメージを見る限り、少なくとも無料分を超えると月額2500ドルからかかってくるようです。

仮に月額2500ドル（約27万円）だとすると、3年間の運用で972万円です。

ボイチャ代として、Epicから実質972万円もらった。

これらのEOSの３つのサービスだけでも、あなたは３年間で4千万円分のアドが得られる事になります。
しかも、それはEOSのサービスの一部です。それに、今後も新しいサービスが追加されるかもしれません。

その他

EOS以外にも、Epicがゲーム開発者に無料で提供してくれているものは色々あるので羅列していこうと思います。EOS以外だとUnityは恩恵を受けられなくてUEオンリーなものが多いです。

・Megascans

ご存知の通り、UnrealEngineではMegascansが全部無料で使えます。これは全部でいくらのアドバンテージなのか、正確には分かりませんが、ざっくり300万円分くらいになるようです。

Megascans代として、Epicから実質300万円もらった。

・毎月の無料アセット

Epicは、マーケットプレイスの有料アセットを毎月無料で提供してくれています。
適当ですが、毎月3万円分くらいのアセットをくれています。
ちょうど2年くらい前からやっているので、2年前から毎月コツコツもらっていた人は、全部で72万円分くらいのアセットをもらえているハズです。

マケプレアセット代として、Epicから実質72万円もらった。

・Unreal Studio

UnrealStudioとDatasmithを使うとUE4にCADモデルなどの色んな形式の3Dモデルをインポートできるようになります。
Epicはこれを月額5千円で提供する予定でしたが、気が変わってタダになりました。
3年間で18万円の節約です。

UnrealStudio代として、Epicから実質18万円もらった。

・Infinity Bladeアセット

Epicは2019年に、400万ドル相当の「Inifinity Blade」のアセットを無料でリリースしました。

Epic、400万ドル相当の『Infinity Blade』のアセットをリリース。Unreal Engine マーケットプレイスのおすすめ無料コンテンツも更新。

Infinity Bladeアセット代として、Epicから実質4億円もらった。

・Paragonアセット

Epicは2018年に、1200万ドル相当の「Paragon」のアセットを無料でリリースしました。

Epic Games、1,200万ドル相当の Paragon アセットを無料で公開

Paragonアセット代として、Epicから実質12億円もらった。

というわけで、あなたはすでにEpicから16億390万円もらっているという事に気付きましたね。
…いや、まあInfinity BladeとParagonはさすがにこじつけっぽいのでスルーするとして、それを抜かしても390万円のアドがある事が分かりました。

Epic MegaGrants

さて、これまでは、「本来お金がかかるものを無料で提供してくれているので実質お金もらってるようなもん」という話でしたが、Epic MegaGrantsについては、マジで現金がもらえます。

これが何かというと、Unreal Engineを使ってなんか面白い事をしようとしてる人を応援するためにお金を配っちゃうというものです。

最初にEpicがやったのがUnreal DevGrantsというもので、総額500万ドルが用意されてました。例えば”ジラフとアンニカ”が受賞してます。

総額 20 万ドルを超える新たな Unreal Dev Grants 受賞者発表！

DevGrantsは用意していた500万ドルが尽きた時点でいったん終わったんですが、今度はなんと総額1億ドルのEpic MegaGrantsが始まりました。
”黄昏に眠る街”はMegaGrantsを受賞しています。

MegaGrantsについて、詳細はおかずさんの解説動画があります。

MegaGrantsで景気よくお金を配りまくってて、おかずさんの話によると、このペースで行くと今年の夏～秋くらいまでに応募しないと予算が尽きるっぽいので、急いで応募する必要があるでしょう。

落ちても何回でも再応募できるらしいし、応募するだけやってみて何の損も無いので、Unreal Engineでなんかやってる人は応募した方がアドだと思います。

MegaGrants、はよ応募しないと終わっちゃうよ！と慌ててしまうかもしれませんが、DevGrantsが終わったと思ったらMegaGrantsが始まったって感じなので、MegaGrantsが終わってもまたすぐ次のなんちゃらGrantsが始まるんじゃないの？と言う気もしますが、実際どうなるかは誰にも分かりません。

受賞率は、応募者の7%くらいらしいです。

ちなみにいくらくらいもらえるのか？というと、枠としては5千～50万ドルだそうですが、Godot Engineでさえ25万ドルなので、個人制作のゲームだと1～2万ドルとかでしょうか？（適当）5千ドルと言うのは本当に最低ラインで、大抵はもっと上になるらしいです。

まとめ

さて、そんな訳で、”もしあなたが大人気マルチプレイヤーゲームを作ろうとしている個人開発者だったとすると、Epicはすでにあなたに4400万円（3年分）をくれている”という話でした。

他にもEpicはArtstationの買収に伴いArtstationの学習コンテンツを一定期間無料化してくれたり、とにかく色々と提供してくれていて、挙げるとキリがありません。

Epicはたしかに個人開発者に大きなチャンスを提供してくれていますが、例えばアンチチート無料の恩恵を受けたければ、アンチチートを使うようなゲームを作る必要があります。当たり前ですが。

EOSのアドバンテージの恩恵を受けるためには、EOSを使いこなす必要があるという事です。
そして、アドを全部拾ってこそ、最大のアドが得られて、それで初めて個人開発者がゲーム会社を出し抜けるチャンスが見えてくるかもしれないなと思ってます。

Epicが作ってくれた今回のチャンスの波は、そういう物のように見えます。

これまでは、個人で本格的なマルチプレイヤーゲームを開発しようとしても、下手に人気が出てしまった時のリスク（サーバ代、ボイチャ代）が恐ろしくて躊躇してしまっていたのを、Epicがリスクを取り除いてくれたので、今この瞬間は個人でも攻めていけるチャンスが生まれるかもしれないという話です。

今回の記事は自分用のメモみたいな側面が大きいですが、誰かの参考になれば幸いです。

前置き

この前、格ゲーのネットコードについて解説記事を書きました。

自分で記事を書いてて思ったのですが、格ゲーに限らず決定論的にマルチプレイヤーゲームが作れたらかなりアドバンテージが大きいなという事です。

個人的に特にメリットが大きいと感じるのは、決定論的ゲームはネットワークマルチ時に、お互いの入力だけを送信し合えば済むので、チート耐性が高い事です。
フォトナやフォールガイズは公式専用サーバを用意してチート耐性を高めてますが、その代わり、メチャクチャサーバ代が高くつくという代償を払ってます。
（まあ、仮にフォトナやフォールガイズを決定論的実装で作ったとしても、各クライアント上でそれぞれ数十人分全員のプレイヤーの動きをシミュレートさせるのは負荷的に無理なのでいずれにしろバトロワは公式専用サーバが必要になりそうですが）

決定論的なゲームなら、サーバ代を安く抑えつつ（Epic Online Servicesならタダ）、チートも防ぐことが出来ます。

意外と見過ごされがちな点ですが、個人レベルで作るゲームは、リリース後の”運用サポートコスト”は最低限に抑えるべきです。

例えば個人でFPSを作ったとして、ゲームのチート耐性が低いと、ゲームが人気になるとチーターが湧いてきます。
まあ、一般的な対応としてはゲーム内に違反者報告機能を組み込んで、ゲームユーザーが開発者に通報できるようにして、開発者がチーターをバンするような流れを作る感じでしょうか。

しかし、よく考えてみてください。
それってメッチャ大変じゃないですか？

開発者は通報された人をどんどんバンしちゃっていいんでしょうか？
でも誤通報だったらどうしますか？誤ってバンされたらユーザーは当然怒ります。
じゃあサーバから試合のログデータを引っ張り出してホントにチートがされたっぽいか確認しますか？しかし、個人レベルのゲームでそこまでしっかりログを収集して蓄積できてないかも。
仮にできていたとしても、通報された人全員に対してこんな作業をイチイチやってたらキリがありません。ずっとチーターのバン作業に追われ続けて、開発作業はストップしてしまいます。本当にこんな作業がしたくてゲーム作ったんだっけ？

実際の例を上げますが、例えばどうぶつタワーバトルでもゲームのバグを利用して不正にレートを上げた人を開発者がバンした結果、twitterで揉めるといった事態も起きてます。

こういうトラブルが何度も起きると開発者は本当に疲弊してしまいます。

そういうわけなので、個人開発ゲームではなるべく運用サポートコストがゼロになるように設計した方がいいわけです。
一番いいのは、マルチプレイヤー機能なんて実装しなくて済むならしないに越した事はありません。
そうは言っても、これからはマルチプレイヤーが当たり前時代なので、そういうわけにもいきません。

開発者がサポートに追われて疲れるのは、チーターが湧いてくるのが原因で、チーターが湧いてくるのはゲームにチート耐性が無いのが原因です。
なので、決定論的なゲームにして、そもそも原理的にチート不可能にすれば、解決です。

そんな訳で、今回の記事ではあらためて決定論的ゲームのメリット、デメリットを考察して、決定論的ゲームを作るための課題、現在取り得る決定論的ゲーム開発の選択肢について考えてみます。

ちなみに、決定論的ゲームの考え方というのは格ゲーのネットコードの考え方と同じです。格ゲーネットコードの記事で”遅延ベースのネットコード”と呼んでいたものは、”決定論的ロックステップ”とも呼ばれていて、”ロールバックネットコード”と呼んでいたものは”決定論的ロールバック”とも呼ばれてます。

決定論的ゲームのメリット

このブログでは今まで何回も書いてきてる事なのでさっくりと流します。

・”決定論的ロックステップ”や”決定論的ロールバック”のネットコードを実現するために必要。

・普通は各プレイヤーの”状態”を送信し合うので、状態値を改竄すればチートできてしまうが、決定論的ゲームでは各プレイヤーの”入力”だけを送信し合うので、チートできない。

・入力データは小さいので通信帯域を節約できる。

・ロールバックを実装すれば遅延無しでキャラを操作できる。

決定論的ゲームのデメリット

これもさっくり流します。

・そもそもゲームを決定論的に作るのが技術的に難しい。

・全てのクライアント端末が、全プレイヤーのシミュレートを処理する必要があるので、格ゲーみたいにプレイヤー数が少ない場合はともかく、プレイヤー数が増えてくると計算負荷がどんどん大きくなって、無理になってくる。特に何フレームもロールバックする時はキビしい。
よってフォトナみたいな多人数バトロワは処理負荷的に無理。

決定論的ゲームを実現するための課題

これも格ゲーネットコードの記事で書いたので流します。

・決定論的な物理エンジン実装が必要

・固定フレームレート実装が必要

・浮動小数点問題の解決が必要

決定論的ゲームを実現するための手段

さて、そろそろ本題に入っていきます。
決定論的ゲームを実現するための手段って何があるんだっけ？
私が軽く調べた限りでは、３つの方法があるようでした。

・格ゲーならUFE2を使う

・Photon Quantumを使う

・DOTSとUnity Physicsを使う

ちなみに、３つの方法はどれもUnityでの方法です。
Unreal Engineで決定論的ゲームを実現する方法は調べた限り無いようでした。
UnityとUE以外については調べてません。なんか他に簡単で有力な方法を知ってる方がいればむしろ教えてください。

ちなみに、決定論についてEpic創業者のティム・スウィーニー氏じきじきにコメントしているフォーラムがありました。

https://forums.unrealengine.com/t/please-add-deterministic-lockstep-networking-for-rts-style-games/19255/8

「Unreal Engineのどのバージョンでも決定論について話題が出るけど、たしかに決定論的にゲームエンジンを設計しておけばそれは可能だったかもしれないけど、UE4はそうしてないんだよ。UE4では素直にレプリケーション使ってね。現在のインターネットは十分な帯域幅があるから大丈夫だよ」みたいな感じの事を仰られてます。

まあ私としては帯域よりもチート耐性を問題にしてるんですが。

ついでに触れておきますが、例えばオセロのゲームを作る場合、別にオセロはお互いの打ち手を送信し合えば済むので、何も考えなくても決定論的に作れると思います。物理の同期とか要らないですからね。
この記事では物理エンジンが必要になるようなゲームのケースについて述べてます。

まあそういう訳で、３つの決定論的ゲームの実現方法についてそれぞれ見てみましょう。

UFE2（Universal Fighting Engine 2）を使う

格ゲーネットコードの記事でも書いた通り、作るのが格ゲーなら素直にUFE2を使えば良いと思います。

Photon Quantumを使う

格ゲー以外のゲームを決定論的に作るなら、Photon Quantumが選択肢に上がってきます。

Quantumには、独自の決定論的な物理エンジンが実装されてます。
フレームレートについては固定30fpsか60fpsの２択が選べます。
そして、独自の数学ライブラリも用意されていて、浮動小数点の代わりに固定小数点を用いる形になるので、浮動小数点問題も解決されてます。
デフォルトでロールバック機能が実装されてます。

かなり素晴らしいですね。もうこれでいいじゃん！と思っちゃうところですが、実は問題があります。
それは、Quantumを使用するためのコストが結構でかい事です。

Quantumを使うには、Gaming CircleというPhotonのサブスクサービスに加入する必要があります。

今まで、このGaming Circleのサブスク代は月額1000ドルでした！
高すぎ！
今まで私的にはQuantumが眼中に入らなかった理由はこれです。

さらに、QuantumではCCUベースで別料金がかかってきます。
1CCUあたり月額0.5ドルです。（ただしGaming Circleで500CCUまで無料サービスが付いてきます。250ドル相当）

こんなわけなので、今まで個人開発者としては高すぎて選択肢に入ってこなかったQuantumですが、実はもうすぐ個人開発者は月額250ドルでGaming Circleに入れるプランが追加されることが予告されてます。

まあ250ドルでも高いっちゃ高いですが、1000ドルよりはマシになりました。
ちなみにGaming Circleではいろんなジャンルのゲームテンプレートにもアクセスできます。

もっと詳しい詳細についても書きたいんですが、Quantumはサブスクに入らないとまったくSDKやドキュメントにアクセスできないので、宣伝されている以上の情報は完全に謎に包まれていますので分かりません。

ちなみに、Gaming Circleのサブスクを解約したらどうなるの？というと、まずSDKはダウンロードできなくなりますし、UnityにインポートしたSDKも動作しなくなる？らしいです。
つまりQuantumで一度ゲーム開発を開始しちゃうと、そう簡単には解約できなくなる点に注意です。
さすがにビルドしたランタイムのゲームは解約しても動作するようですが。

私がここで物申しておきたいのは、PhotonCloudのビジネスモデルについてです。
PhotonはPUNもQuantumもFusionも、ネットワークライブラリとリレーサーバ課金が抱き合わせ商法でセットで売られてます。

まあ商売なんだからしょうがないですが、個人的にはもうEpic Online Servicesで無料のリレーサーバが提供されてる今となってはPhotonのリレーサーバにお金払うのイヤなんですよね…。

というわけで、Quantumを使わないで決定論的ゲームを作る方法も探ってみたいと思います。

DOTSとUnity Physicsを使う

UnityのDOTSって、実は結構決定論を志向してます。

DOTS向けに開発中の物理エンジン、Unity Physicsはかなり決定論的です。
惜しいのは、浮動小数点問題が残ってる点で、これにより、アーキテクチャの異なるCPU間では浮動小数点の演算結果に違いが出て、決定論的では無くなります。

実は、この問題を回避した方がいます。

↑こちらの方が改造したバージョンのUnity Physicsでは、クロスアーキテクチャの完全な決定論が実現されているらしいです。

リポジトリはこちら↓

https://github.com/Kimbatt/unity-deterministic-physics

どのように実現したかというと、SoftFloatという浮動小数点演算をソフトウェア上で行うライブラリを組み込んで、Unity Physics内の浮動小数点演算を全てSoftFloatに置き換えたという訳です。

決定論的になったのは嬉しいですが、代償として、ハードウェア浮動小数点演算の最適化の恩恵を受けられないので、シミュレーション速度は1/2～1/4程度まで低下してしまったそうです。
まあ遅くはなったものの、逆に言えばそれくらいの低下で済んでるので、使い方次第では問題無いでしょう。

物理エンジンが決定論になったのはいいとして、Burstについても見ていきましょう。

BurstについてはUnityは昔から「決定論になる予定です！」と宣伝してましたが、いまだに全然決定論になってません。

https://forum.unity.com/threads/burst-compiler-deterministic-floats.522856/

まず、浮動小数点がクロスアーキテクチャでの決定論に対応してません。これについてはUnityの人の言い方だと、「実装する予定はあるけど今忙しいから当分実装しない気がする」くらいのテンションっぽいです。

さらに、浮動小数点問題が解決したとしても、JobSystemやらなんやらで、マルチスレッドをバリバリ駆使したゲームで、スレッド実行順とかが絡んできちゃうし、本当に決定論的なゲームなんて可能なんだっけ？という問題もあるそうです。

こうして見ると、DOTSで決定論的ゲームを作るのも、まあ少なくともDOTSが完成してからじゃないと難しいのかもですね。
DOTSっていつ完成するんだっけ？というと、さあ、本来もう完成してるハズでしたが、実際は3年後か5年後か…。

私もせっかくなのでDOTSでの決定論について触って検証してみようとしましたが、そもそもECSがサーパリ分かんなくて諦めました。誰か検証された方がいましたら教えてください。

Unity PhysicsがECSからしか触れないのもなんか腹立ちますね。GameObjectから触りたい…。

ちなみに、格ゲーネットコードの記事で、「Unityで固定フレームレートを実現するのは難しいかも…」と書きましたが、その後ググったら簡単に実現する方法がありました。

http://kagring.blog.fc2.com/blog-entry-75.html

Time.captureFramerateに値を設定すると、固定フレームレート的な挙動になるようです。
例えばこの値を60にした場合、「現在のフレーム時間が16.6ms未満だったら、16.6ms経過するまで待機」という挙動になり、固定フレームレートのゲームの挙動になります。
多分Time.deltaTimeの値も16.6ms固定になると思います。

まとめ

そんなわけで、今回の記事では決定論的なゲームを作る方法を探ってみました。

自分の印象としては、格ゲーならとりあえずUFE2使えばいいけど、格ゲー以外なら、価格面などの条件が合うならPhoton Quantum使えば良さそう。
そうでなければDOTSを頑張ればもしかするといけるかもしれない。
という感じでしょうか。

とは言え、DOTSを頑張って改造して決定論にするなんて、そんな事が簡単にできるんだったらUnityチームだってとっくにやってるはずなわけで、だからかなり大変かもしれないですね。

自力で未知の領域で手探りで頑張るよりは、決定論的ゲームは今の時点では諦めて、普通にゲーム作っちゃう方が無難な気もしますね。

決定論的実装の方法が確立されて、情報が出回りだしたら改めてその時に検討し直すといったところでしょうか。

これまで散々、UE5に移行するぞ移行するぞ！と言っては来たものの、もしUnityで決定論的ゲームが作れるなら、決定論とEOSを組み合わせればサーバ代がゼロかつチート耐性も付くという、聖杯になり得るわけで、そこで未練が生じていたので今回調べてみました。

まあ、今のところは難しいらしいと分かれば、心置きなくUE5で普通にマルチプレイヤーゲーム作ればいいかなと思いました。
Quantum使うとEOSが使えなくなるからタダじゃなくなりますしね。

そんなわけでしたが、この記事が参考になれば幸いです。

前置き

みなさんはビジネス（仕事）について詳しいでしょうか。

社会人は誰しも、ビジネス（仕事）をして生きています。（ニートは除く）
そして、ビジネスに自分の人生の時間の多くを費やしています。

そんな自分の一生を費やすハメになるビジネスですが、案外、ビジネスについて深く理解している人は多くないのかもしれません。私もあんまり理解できていません。

私が学生の頃は、世の中のビジネスなんて、お店（飲食店、花屋、などなど）をやるか、アルバイトをやるか、会社員をやるか、程度の種類しかイメージ出来てませんでした。

社会に出てからはフリーランスと言う生き方もあるとわかりましたが、まあせいぜいそれくらいです。

ここで言うビジネスの種類と言うのは、ラーメン屋、ファミレス、スーパー、とかそういう意味の種類ではなく、もっと仕組みの違いとしての種類の話です。

まあ、ビジネスの種類と言っても、ぶっちゃけお金が儲けられて合法でありさえすれば何でもアリなので、世界は広大ですから、無限に種類があると言ってもいいのかもしれません。

例えば転売ヤーなんかも、まあ違法でない以上は一種のビジネスと言えるかもしれません（私は転売の過熱でSwitchやガンプラが買えなくて困ってます）

コンビニはフランチャイズという方式のビジネスをやってます。
例えばローソンのビジネスと言うのはローソンのコンビニで物を売って儲ける事ではありません。実際にモノ売るのはその店舗のオーナーがやる事です。

フランチャイズのビジネスというのは物を売るんじゃなくて、ローソンのオーナーやりたいです！と言う人にローソンを出店する権利を売るビジネスです。

ですので、個々の店舗が儲かろうが儲かるまいが、ローソン本部には大して影響ありません。

コンビニ本部の直営店もありますが、割合としてはごく一部らしいです。コンビニ店舗がメッチャ儲かるんだったらオーナーなんて募集せずに全店舗を自前で直営すればいいのに、そうしないでわざわざオーナーを募集するという事は、コンビニ店舗は大して儲からないという事です。

そのようなフランチャイズのカラクリを知らないで、脱サラしてうっかりコンビニオーナーなんて始めてしまうと、苦労する事になるかもしれません。

私はスタートアップ企業に関わった事があり、なんなら自分でもスタートアップのシード投資に応募した事もあります。

しかし、なんやかんやあって今にして思うのは、自分はスタートアップには向いてないかもしれないな…という事です。

ぶっちゃけ私は自分が死ぬまで暮らせそうな最小限度の金さえ稼げればいいという、ささやかな願いしか持ってません。それだけ稼いだら後は一生、趣味だけやって暮らしたいですね。

そんな欲の無い人間は起業家には向いてないでしょう。何故なら、ライバルの起業家と言うのはみんな「世界を変えてやるぞ！」というようなでっかい野望に燃えている人達ばかりですから、そういう中での競争に勝てる見込みありません。

身の丈に合わせて細々と経営していこう…みたいな選択肢はそもそもスタートアップには存在しません。スタートアップという仕組み上、ゼロかバチかしか選べません。

スタートアップと言うのは風船と言うかシャボン玉に例えられるかもしれません。
シャボン玉には膨らませないという選択肢はありません。ベンチャーキャピタルなどからジャブジャブ資金調達して事業を膨らませていきます。慌てすぎるとシャボン玉は破裂（バーン→お金が無くなって詰む、倒産）してしまいます。
スタートアップは基本的に自分たちが持ってるお金以上の金額を投資し続けるからです。いくら儲かってもそれ以上のお金をさらに投資家から調達してバンバン投資します。何でそんな事する必要あるんですか？というと、ライバルもみんなそうやってますから、自分達もそうしないと負けるからです。

うまいこと目一杯まで膨らませたら、割れない内にさっさとイグジットを目指します。
イグジットは例えば上場（IPO）したりしますが、上場してしまえば起業家は大金持ちです。しかし、だからと言ってさっさと引退するというわけには行きません。上場した以上は10年、20年は責任もって経営を続ける必要があります。

個人的にはそんな風に身の丈を超えて、無理やり成長させ続けなければいけないやり方が性に合わない気がします。

スタートアップは自分のやりたい事業ができると思う人もいるかもしれませんが、そんな事はありません。できるのはマーケット（市場）にフィットする（要するに儲かる）ビジネスだけです。単に自分がやりたい事をやってても、市場から強烈にダメ出しを食らいます。つまり、誰も求めてない事業にはお客が付かない、誰もお金を払ってくれないという事。そんなだと続けていられなくなるので、スタートアップはマーケットにフィットするまでピボット（方針転換）しまくるハメになります。そうしてる内に最初に自分がやりたいと思ってた事業とは全然違っていってしまうというのもありがちです。

ちなみに、何人か顧客が付いて、一応これで自分の食い扶持分くらいは食っていけるぞ！と言う状態は個人事業主なら嬉しい状況ですが、スタートアップではそんな小さすぎてスケールしなそうな成功は認められません。投資を受けてない企業なら文句言われないのでいいですが、ベンチャーキャピタルから投資を受けてたら、「もっと爆発的に成功する事業をやってくれなきゃこっちは投資が回収できなくて困るんだよ！」と突き上げられるハメになります。

そんなんじゃなくて、もっとこう…一人で小規模にボチボチ気楽に稼いでいけるようなビジネスは無いもんかなと最近は考えてます。

私は自分がもっと世の中の色んなビジネスの種類を知るべきだという必要性を感じてます。
そうする事で、生き方の選択肢を増やすことが出来るでしょう。

自分に合ってない仕事、生き方をしていて苦しんでいる状態でも、他の生き方を知らないと苦しい仕事を続けるしかありませんが、選択肢がある事を知っていればもっと自分に合った生き方を選ぶことができるでしょう。

モバイルハウスで暮らす赤井さん

そんな事を考えていて、たまたま見かけた記事がこちらです。

phaさんとモバイルハウスを見に行こう。「動く家」の住人が見せてくれた、「定住」と「移動」の狭間の暮らし

赤井成彰さんという方は、１トントラックの荷台に家を作ってしまって、「モバイルハウス」と呼んで、そこに２年間くらいずっと住んでるそうです。

さらに、相模原の藤野の森に、「モバイルヴィレッジぼちぼち」という、モバイルハウスで暮らす人たちだけの村のようなものを作ろうとしているそうです。

私はこういう話を聞くと、たのしそうだな～と思ってすぐに憧れてしまいがちです。

赤井さんはどうしてモバイルハウス暮らしを始めたのか？と言うと、「家賃を削りたかったから」との事。そういう綺麗ごとじゃない即物的というか、身も蓋も無い理由なのは好ましいと思いました。大変に共感できます。

生活費を節約したい時は、家賃などの固定費から見直すというのはとても有効な手です。
かと言って、「モバイルハウスに住めば家賃ゼロ円！」と思い付いて実行してしまうのは極端と言うかアグレッシブすぎて感心しました。

モバイルハウスは賃貸よりコスパがいいのか？

赤井さんはモバイルハウスを作った後、早速日本一周の旅に出たそうです。
そういう放浪の旅には、たしかにモバイルハウスは最適だと思います。

しかし、そうやって旅を続ける中で、このような生活では人との繋がりが得られないという事に気付きました。
それは確かにそうだと思います。旅をする中で色々な出会いもあるかもしれませんが、移動し続けていますから、すぐに別れるハメになります。

モバイルハウスは移動し続けながら生活するには便利ですが、逆に「ここにしばらく住もうかな」と定住しようと思ってもそれは難しそうです。道の駅の駐車場とかで１泊、２泊くらいしたところで問題なさそうですが、それ以上定住しようとしても追い出されそうな気がします。
そう考えると結構孤独な旅でもありそうです。

モバイルハウスで定住しようとしたら、どこかの駐車場と契約してそこに停める必要がありそうです。（そうしたとしても、「駐車場に住んでる人がいる！」とかチクられたら追い出されるかもしれません）

そういう中で、赤井さんに藤野の土地を（タダで）貸してくれるという人が現れ、赤井さんはそこに定住して「モバイルヴィレッジぼちぼち」を作ろうと決めたそうです。

↓ちなみに”ぼちぼち”の場所はGoogleMapに載ってます。

さて、モバイルハウスに住めば、たしかに家賃は0円で済みます。しかし、モバイルハウスに定住するとなると、パッと見は気付かないコストや問題が色々ありそうなことに気付きます。
トータルのコスパで考えた場合、本当にモバイルハウスは賃貸より優れているのかどうか考えてみたいと思います。

これは誰かをダメ出しとかバカにしてるとかディスってるとかそういう意図では無い事をあらかじめ念押ししておきたいと思います。ただ単に、もし自分が本当にモバイルハウスに住むと想定した場合に直面しそうな事を書いてるだけです。

まず、前提として相模原市藤野とかあの辺の立地だと、普通にワンルームの賃貸アパートを借りても家賃月2万円以下で済んでしまうという事があります。

また、赤井さんはモバイルハウスでの生活費がどれくらいかかるのか、詳細な記録を取っており、動画で公開してくれてます。

モバイルハウスで１年暮らすと、大体年間70万円かかる見込みだそうです。つまり、月当たり6万円の生活となります。

内訳の円グラフも出してくれてますので、これを元に算出すると、
モバイルハウス１カ月の生活費
・交通費　2.88万円
・食費　　9,600円
・娯楽、交際費　8,400円
・通信費　7,800円
・日用品　4200円
・お風呂　1200円

この辺のデータを元にコスパとか考えてみましょう。

１．水道をどうするか

人間、何はなくとも水の確保が一番優先されます。
賃貸なら当然水道がありますので、月2000円くらい払えば綺麗な水をいくらでも使うことが出来ます。
”ぼちぼち”では、近くの川を生活用水にしているそうです。川と言ってもかなり上流の川なので、綺麗な清流という感じ。
その川で野菜を洗ったり、水浴びしたりしているそうです。
飲み水はどうしてるか？というと、近所の方が集落みんなのために作ってくれた、湧水をろ過して流してくれる装置があって、それを汲んで使ってるそうです。
ちなみに、都心の公園に住んでいるホームレスの方は、公園の水道でタダで綺麗な水使い放題です。

２．ご飯をどうするか

水の確保が出来たら、ご飯をどうやって用意するか？を考えます。
賃貸ならキッチンがあるので、そこで料理できます。ガスコンロなりIHコンロもあります。ご飯は炊飯器で炊けます。

モバイルハウスではどうするか？というと、赤井さんはカセットコンロを使って料理してるみたいです。収納式テーブルもあるので包丁使ったりもできます。
ご飯は土鍋を使って炊くようです。大体、20分くらい火にかけてから、10分蒸らすと炊けるようです。
おかずは記事ではジャガイモとトマトとにんにくのスープを作ってました。ジャガイモとニンニクは”ぼちぼち”の畑で採れたものだそうです。

どうして野菜だけの食事なのか？と言うと、赤井さんは全然ベジタリアンというわけではないんですが、肉を料理して油なんかが出てしまうと洗剤を使って皿とかを洗う必要がありますが、汚れた水の処理に困るから野菜中心の食生活になったそうです。
たしかに流しもなければ下水道もありませんから、油やら汚れた水の処理は難しいですね。盲点でした。
それを言ったらごはんのとぎ汁なんかもどうしてるんだろう。ラーメンのスープとかも困りそうです。

赤井さんは月の食費を9600円としていますが、これは激安です。なぜここまで食費が抑えられるのか？というと、まず基本は自炊している事と、近所の農家さんが野菜とかくれたりするそうです。また、自分で畑で野菜とか育てて部分的に自給自足できているという事もあるでしょう。

私も結構自炊する方だと思いますが、自炊では冷蔵庫と電子レンジがメチャメチャ活躍します。
一度の料理で大量の量を作って小分けして冷凍しておく。食べる時はレンチンするだけ。このテクで手間とコストを大幅に節約できます。
モバイルハウスでは冷蔵庫が無いので、食料を保存することが出来ません。これは大きなディスアドバンテージでしょう。毎日食料を調達して、１日３食料理する手間が必要です。

ついでに言うと、カセットコンロは燃費だけで言えばガスコンロやIHコンロに比べてかなり燃費が悪いらしいです。まあその分、ガスの基本料金がかからないというメリットはあります。

３．トイレをどうするか

ご飯の次に大事なのはトイレです。
モバイルハウスで旅をしている間はそこらじゅうにある公衆トイレとかを使わせてもらえばいいわけだから、トイレには困らないでしょう。
しかし、モバイルハウスで定住するとなれば、自分達でトイレを何とかするしかありません。
できれば、公園のそばなんかに定住できれば公園のトイレを使えて便利だったとは思います。

”ぼちぼち”ではトイレを自分で作ったようです。

コンポストトイレなので、排泄物は時々土とかき混ぜておけば、たい肥になるとかそういうヤツだと思います。

という事は、誰かが排泄物をかき混ぜる仕事をしなきゃいけないし、トイレを作ったら誰かが常にトイレを綺麗に掃除する必要があります。人間の生活と言うのはインスタ映えするようなたのしい事だけやってればいいというものではなく、地道にトイレ掃除とかもやんなきゃいけないもんなんだよなと思いました。

４．風呂をどうするか

コスパを考えた場合に真っ先に疑問だったのはお風呂です。
賃貸でたまにお風呂無し物件とかありますが、コスパを考えると家賃が1万円上がったとしてもお風呂付の方が良くないか？と思ったりします。何故なら、銭湯の料金は東京で480円です。回数券を使ったとしても440円で、一ヶ月毎日30回銭湯に行ったら13,200円かかります。

モバイルハウスでも話は同じで、”ぼちぼち”の最寄りの銭湯はいやしの湯という温泉がありますが、入浴料は750円です。一ヶ月毎日行ったら22,500円かかる事になります。この時点で、2万の賃貸アパートの方が安くつくじゃんと思ってしまいます。

しかし、赤井さんは、お風呂代は“年間で”11,180円だったと動画で言ってます！これは衝撃的安さです。11,180円だと1年間に15回しかいやしの湯に行けない計算になります。
どうしてそれが可能だったのか？というと、夏は川での水浴びだけで済ませていたからだそうです。
たしかに夏は気持ちよさそうですが、それ以外の季節は水が冷たくてキビシそうです。

環境の事を考えると、川では石鹸やシャンプーも使えないのではないかと思います。

５．ネット回線をどうするか

赤井さんはYoutubeやtwitter、Facebookで活動を発信してますから、ネット回線は重要です。
スマホでテザリングすればいいじゃん？と思うかもしれませんが、スマホの回線を固定回線代わりにしてネットやってると、月間数十GBを消費してしまい、かなりスマホ料金がかかってきます。

そこで、赤井さんはWiMaxのポケットWi-Fiを使ってるそうです。
WiMaxなら月4千円くらいの固定料金で回線使い放題です。ポケットWi-Fiあるならむしろスマホの回線は解約できるまであるかもしれません。

６．電気をどうするか

当然ながら、モバイルハウスには電気は引けません。
という事は、電灯も、冷蔵庫も、洗濯機も、エアコンも、テレビも無いという事です。

と言っても車にはエアコンが付いてるので、暑ければ車に入れば涼めます。寝る時は荷台なので夏は暑かったり冬は寒かったりするでしょう。

電灯が無いでしょうから、”ぼちぼち”は夜は真っ暗になってあまり活動できないのではないかと思います。キャンプでも、夜はキャンプファイア代わりにちょっと焚火するくらいしかする事ありません。
モバイルハウスの中ではLEDランタンとかそういうのを灯りに使ってるのではないでしょうか。

洗濯については、単に時々コインランドリーまで行けば事足りるでしょう。

一番の問題は、ノートPCやスマホ、ポケットWi-Fiのバッテリーをどうやって充電するのか？ですが、赤井さんはポータブル電源を使っています。
じゃあ、そのポータブル電源はどこで充電するの？というと、モバイルハウスの屋上にソーラーパネルが設置されており、天気がいい日は半日で満充電できるそうです。
車のシガーソケットから充電できるポータブル電源もあったりするので、そういう手も使えそうです。

７．ゴミをどうするか

ゴミの処理はどうしてるんでしょうか？
まあ、普通に考えると自治体のゴミ収集に出してるかと思われます。

という事は、モバイルハウス定住は、ゴミ収集のような行政サービスが行われてるエリア内でやる必要があるかと思います。

８．住所をどうするか

なにげに問題なのが、住所の問題です。

Amazonの荷物や郵便物はモバイルハウスに届くんでしょうか？
”ぼちぼち”の場合は看板とポストさえ設置すればもしかすると届くかもしれません。
駐車場の場合はどうでしょうか。坂口恭平さんは「独立国家のつくりかた」のなかで、”駐車場のモバイルハウスでピザ注文してみたけど届いたよ”みたいな事を書いてました。

それはいいとして、住民票の手続きの問題もあります。
よく訊くのが、ネカフェ難民の人が住所不定になって職に就けない問題とかありますが、もしかすると”ぼちぼち”なら住所移せる可能性はあります。
そうでない場合は、実家とか、何かしらモバイルハウスとは別に拠点を持って、そこに住所を設定しておく必要があるでしょう。
ワクチンのクーポンなんかも住民票の住所に配送されると思います。

９．虫、野生動物をどうするか

藤野の森ともなれば、都会ではあまり見かけないような虫とかミミズとかムカデとか、そういうのが一杯いるかと思われます。

記事でも赤井さんが「ヒルが出るので足元に気を付けて」と言ってます。
この前高尾山に登りましたが、ヤバいくらい蚊に襲撃されました。藤野の森でも同じような感じかもしれません。
要するに、虫とかに耐性がある人じゃないとこういう暮らしは難しいかもしれないという事です。

虫だけじゃなくて、猪、鹿、アナグマ、狐やらの野生動物もわんさか出現するらしいです。
見かけるだけならほのぼのでいいですが、野生動物は畑の作物を荒らすので、厄介な敵です。
赤井さんは動物対策で畑をフェンスで囲ってました。

１０．所得税、健康保険、国民年金をどうするか

赤井さんの生活費の内訳には所得税、健康保険、国民年金が含まれてません。
赤井さんは”ぼちぼち”で暮らす前は日本一周の旅をしてましたが、多分所得はゼロだったのではないでしょうか。

所得がゼロだと当然所得税はかかりません。

健康保険についても所得に比例して保険料が上がりますが、所得がゼロだと7割引きになったりして、月当たり1300円で済みます。

国民年金も、所得が少ない人は全額支払い免除可能です。ただし、半額しか支払った事にならないので、将来満額受け取りたい人は払っておいた方がいいという事になりますが。

１１．女性でも可能なのか

女性でモバイルハウス暮らしは可能なのでしょうか？

ゆるキャンなんかでもしまりんがソロでキャンプしてますが、現実には防犯的にどうなんだろう？と思いますが、あまりキャンパー界隈の事情は詳しくないので実情は知りません。

モバイルハウスなら少なくとも防犯対策をしっかりしておく必要がありそうです。

生活と言うのは本来コスパの問題じゃない

さて、こうしてモバイルハウスと賃貸暮らしを比較してみましたが、いくらモバイルハウスなら家賃がゼロだとは言え、色々と困難な要素も多そうで、コスパだけを考えると賃貸で暮らした方が良さそうな気がしてきました。

しかし、そもそも論として、コスパで考える事は絶対的な正義と言えますか？

私は何でもかんでもコスパで考えるコスパ厨ですが、実はコスパで考えるというのは、何か他の目的があって、それに気を取られている状態なのです。
だから生活にコスパを求めるというのは、例えばお金をより一杯稼ぐために生活を手抜きしようとしている事になります。

ぶっちゃけて言えば、そんなにコストを払いたくないんだったら、突き詰めて言えば今すぐ死ねばコストはゼロで一番オトクです。

ですから生活にコスパを持ち込むのは、ある意味で貧しい暮らしかもしれません。だって、もし100億円持ってたらコスパを気にして生活しますかね？

私は時々考えるのですが、現代社会の人間は、自分の生活から結構疎外されている…ような気がします。
縄文人とか弥生人は、自分達で狩りや採集、釣りをして、自分達で作物を育てて、自分で自分の家を建てて、自分の服も自分で作る、そんな風に自分の生活を自分で賄う暮らしをしていたはずです。
それに比べて我々は、他人が栽培した野菜、他人が釣った魚を食べて、他人が建てた家に家賃を払って、他人が作った服を着て暮らしています。何故そうなったか？と言えば、そうした方が圧倒的にコスパが良い社会システムが出来上がったからです。

たしかに便利な世の中ですが、誰もが土地やら家の持ち主に毎月家賃を払って暮らしていて、それを当たり前だと思い込んでいる事に疑問を差しはさんでみたっていいじゃないですか。

赤井さんがモバイルハウスを始めたのは、たしかにキッカケは「家賃を減らしたかったから」という身も蓋も無い理由だったかもしれませんが、今となっては既存のお仕着せの社会システムへの挑戦ともいえる、意義深いチャレンジだと思います。

ちょっと話が飛びますが、マイクラの人気の理由の一つには、ああいう狩猟、採集、栽培サバイバル生活に人間は本能的に憧れてしまうという面があると思います。
ゲームで自給自足サバイバルしてみたいなら現実でもやってみたい人は一杯いるはずという事です。

極端な生き方をすると、誰かが応援してくれる

さて、そろそろ今回の記事の話のポイントに入っていきます。

赤井さんは自分の生活を自分で取り戻して、非常に丁寧な暮らしをしているという事は分かりましたが、いくら家賃がゼロとは言え、年間70万円の生活費をどこから引っ張ってくるのか？という問題に行きつきます。

実は、赤井さんは有料のFacebookグループを運営していて、グループに加入するには月額1000円のサブスクに加入する必要があるのですが、このグループのメンバーが112人います！
つまり、赤井さんには毎月11万円の収入があるという事です。

ここが話のポイントです、つまり、

応援してくれる人が100人いて、それぞれから月1000円ずつもらえればそれだけで生きていける

という事。

赤井さんが家賃を削るためにモバイルハウスを作って住むという極端な生き方を選んだ結果、むしろ毎月11万円もらえてるという事。
これがもしも無難に2万の賃貸アパートに引っ越してたら、それだと普通過ぎて別に誰も応援しようとは思わなかったでしょう。コスパの事ばっかりかんがえてもしょーも無いという事がよく分かります。

それにしても、どうして赤井さんがここまで応援されているのでしょうか？
というのも、モバイルハウスは赤井さんの発明ではありません。以前からモバイルハウスを作ってた人は一杯います。

モバイルハウスは坂口恭平さんの「独立国家のつくりかた」の中ですでに提唱されてました。
モバイルハウスのコミュニティもあるらしく、実際、赤井さんはモバイルハウス制作のワークショップなどを経てモバイルハウスを作りました。

そういう中で、なぜ赤井さんの注目度が高まっているのか？というと、これは推測ですが、なんだかんだ言ってもガチでモバイルハウスだけに住んでる人は赤井さん以外にほとんどいないんじゃないでしょうか。
付け足すと、ちゃんとYoutubeやSNSで活動を発信してる人の中でという条件も付くでしょう。

なんだかんだ、モバイルハウスに本当に住むとなると、困難が多そうです。
坂口さんも、モバイルハウスを作ったまでで満足して、実際に生活したとは著書には書いてませんでした。
マジに２年以上モバイルハウスで生活している赤井さんは、リーダーとして相応しいカリスマを感じます。

ちなみに今ググったら、ミュージシャンの高橋雄也さんという方も2013年から2年ほどモバイルハウスに住んでたそうです。

会社に壊されない生き方 (3)モバイルハウスで得た「生きることへの自信」

というわけで、そんな赤井さんに注目して取材するメディアが増えていったようです。それで私もたまたま昨日Web記事で知ったわけですが。

2020年12月にはザ・ノンフィクションというテレビ番組でも取り上げられています。

そういう感じで知る人は知ってるくらいに知名度が上昇して、サブスク112人に至ったのではないかと推測します。

ユーチューバーで食っていこうと思ったら、Youtubeは広告モデルですから、チャンネル登録数が数十万人とか数百万人とか集める必要があって、みんなにウケるコンテンツを出し続けないと行けなくて大変ですが、ニッチで極端な事をやってても、本当に応援してくれて毎月1000円出してくれるファンさえ100人いてくれればそれで食っていけるという事ですね。

今は112人ですが、まだまだハネる可能性も秘めてるのではないかとも思います。もしも1000人になんてなったら、月収100万円です。夢がありますね。

さて、この記事ではもう少し突っ込んで考えてみたいのは、赤井さんのように、極端な生き方をして、応援してもらって生きていくという手法はビジネスモデルにできるだろうか？という点です。

もちろん、赤井さんは、最終的にこれで食っていけるだろうなんて事を見越してモバイルハウス生活を始めたわけではありません。でももしかするとこのような生き方をビジネスのメソッドとして一般化できる可能性は無いでしょうか。

赤井さんが応援される理由

極端な生き方さえすれば、何でも応援してもらえるのでしょうか？
例えば、「１年間ポテチだけ食って生活する！」とかも極端な生き方ですが、それでサブスクが集まるかと言うと…集まるかもなあ。でもその前に健康を害して死ぬかもしれない。

冗談はさておき、赤井さんが応援されているのは、単に極端だったからだけではなく、応援したくなるような活動だったからかもしれないので、それについて考えてみましょう。

モバイルヴィレッジぼちぼちの活動って結構DASH村っぽいですよね。
日本人はDASH村が大好きみたいですが、さすがに鉄腕DASHは永遠にDASH村やっててマンネリ気味かもしれません。
それに、鉄腕DASHはあくまでテレビ番組です。TOKIOは忙しいからマジで付きっきりで農業やら何やらやってるわけではありません。収録の時だけ訪れている感じでしょう。
その点、赤井さんの活動はリアルそのものなので、新鮮でコンテンツ力が高いかもしれません。

そして、先ほども言った通り、既存の今まで誰もが当たり前だと思っていた暮らし方をひっくり返して実践してみる、というのは社会的にも意義深い実験だと思います。
特に、これは赤井さんもインタビューで語られている事ですが、昨今のコロナ禍で、今までのあたりまえの生活と言うのは根本から揺らぎ始めています。
例えば、人の流れを減らすために積極的にテレワークが推奨されていますが、どうせテレワークで仕事できるなら、もうわざわざ家賃や地価の高すぎる都心に住む必要なんて無くなるわけです。
↓例えばこちらの夫婦も田舎の中古の古民家を600万円（やすい）で買ってリノベして暮らしてます。

要するに、今まで当たり前とされていた暮らし方を見つめ直し始めている人が増えているという事です。

そういう状況ですから、もしも赤井さんの生活実験が大成功して、これぞ安く楽しく人生を生きる方法だ！という事実が実証されれば、もしかするとみんな真似し始めて一大ムーブメントになるかもしれません。

とは言え、じゃあ自分がサブスクしてくれるファン欲しさに赤井さんと同じような生活ができるかと言うと…実際難しいです。
赤井さんは元々ずっとハワイで自給自足生活する事を夢見ていて、そういう態勢を整えていた方でもありますし、ずっと前から心の底からやりたかった生活をやっているからできているのであって、他人が上っ面だけを見て真似しようとしてもそうそうできるものではないでしょう。

というわけで、赤井さんが応援される理由を分析してみました。

まず、自分が心の底からやりたいと思ってる事をやった方がいいという事。
ウケそうだからと言ってやりたくも無い事を始めるくらいなら、普通に労働した方が無難でしょう。

次に、できれば社会に役立つような事をやった方がいいという事。
twitterでは何の役にも立たない無意味なコンテンツがバズリがちですが、いくらRT数が多かろうが、じゃあそれに金を払ってくれるか？というと、くれません。

それから、コンテンツ力がある事をやった方がいいという事。
まあこれについては、何をやろうが大抵はコンテンツになってしまうとは思います。
Youtubeでも誰得なんだよとしか思えないニッチなコンテンツでも界隈では人気だったりします。
マス向けのコンテンツはテレビやユーチューバーがやってますから、むしろニッチで狭くて深いコンテンツの方が少数の熱狂的ファンを獲得できるかもしれません。

タダでもいいから住んで欲しいという土地や家が増えてくる可能性

最後にこの話題に触れておきます。

赤井さんのモバイルヴィレッジぼちぼちの土地は、その土地の地主さんが無料で提供してくれてるそうです。
赤井さんはその地主の方とはモバイルハウスのワークショップでの繋がりの縁があったそうです。

私は「タダで土地を貸してくれるなんて気前がいいなあ」と思いましたが、よく考えると地主の人にとってもメリットのある話なのかもしれません。
土地と言うのは誰も住んでないと、無尽蔵に荒れ果てていきます。タダでもいいから誰かに住んでもらってある程度土地を手入れされた状態で維持してもらえるなら、無料で土地を管理してもらってるのと同じですから、地主にとってもありがたい、お互いウィンウィンの関係となります。（ぶっちゃけヤギかなんかを放しておくという手もあるかもですが、それも誰かがヤギを管理する手間がかかります）

ここでポイントなのが、赤井さん達がモバイルハウス住みだという事です。
私はモバイルハウスの村の話を聞いた時、「移動できるのがモバイルハウスの良さなのに、それで定住するって、だったら家建てた方が良くないか？」と思ってしまいましたが、よくよく考えると敢えてモバイルハウスの赤井さんに住んでもらったのは理由がありそうです。

要するに、モバイルハウスは固定資産では無いという所が重要です。
地主の方がタダでもいいから誰かに住んでもらいたいな～と思っても、そこに家とか建てられると、固定資産税が発生してしまうので困ってしまいます。
これは私の憶測ですが、固定資産になるものは一切建てないのが”ぼちぼち”の土地を提供する条件なのかもしれません。

さらに、赤井さんは近くの耕作放棄された畑も提供してもらっており、荒れ果てた畑を必死こいて開拓し直して、作物を植えています。
これについても、畑の持ち主からすれば、荒れた畑を耕し直してくれて、さらにいつでも耕作可能な状態にメンテし続けてくれる人と言うのは、涙が出るほどありがたい存在だと想像できます。

ちなみにですが、赤井さんがあっさり畑で農業できているのは、赤井さんは大学では農業を勉強していて専門家だったからであって、何も知らない素人がいきなり農業やろうとしても絶望的です。

先ほどリンクを貼った高橋さんという別の方のケースでも、最終的に”カフェの建物と土地をタダで貸してくれる”という方が現れて、高橋さんはモバイルハウスからカフェに移住したそうです。
まあ、家も誰も住んでないとあっという間に荒れ果ててしまいますし、最近では荒れた空き家は固定資産税が爆増するという罰を受けるケースもあります。
というわけで、土地どころか家までも、タダでもいいから住んでくれ！というケースは意外と増えてきてるのかもしれません。

一時期、奥多摩の空き家バンク制度が話題になりました。
空き家をタダでくれるというものですが、私もちょっと注目してましたが、結婚してないといけないやら何やらの資格要件が面倒で諦めました。

さて、ここまで見てくると分かるのが、タダでもいいから住んでくれ！とか、タダで家あげます！みたいなケースが増えてきているという事です。
さらに言えば、今後はますますそのようなケースが増えていくと予想されます。なにしろ日本の人口は急激に減少していってるにも関わらず、マンションはますます増えているからです。都心はともかく田舎や地方都市は、当然空き家まみれになります。

案外、あと数十年もすれば家賃ゼロが当たり前な時代がくるかもしれませんね。

最後に

というわけで、今回の記事ではモバイルハウス暮らしの赤井さんについて書いてみました。

赤井さんは本当に自分がやりたい暮らしをやっていたら、いつの間にかサブスクで応援してくれる人が集まっていた、というものですが、もしかするとこういう生き方は狙って再現できるかもしれない？という視点を添えてみました。

記事の最初にスタートアップの話をしましたが、スタートアップはピボットを繰り返すハメになって、最初に自分がやりたかった事業とは全然違う事をする事になりがちなのに対して、赤井さんの場合はひたすら自分がやりたい暮らしをやってたら、いつの間にかそれで食えるようになったという違いが対照的ですね。

まあ、サブスク暮らしなんてのは、そうそう簡単に誰でもできるような事ではありません。
しかし、とりあえず死ぬまでボチボチ暮らしたいだけの人間なら、多分、スタートアップでガムシャラに頑張ってイグジットを目指すほどには難易度高くなさそうだとは思いました。

とは言え、こういうのって、ユーチューバーもそうだと思いますが、１ジャンルにつき１人しか枠が無いような気がしますので、赤井さんのやってる事をそっくりそのまま真似してもしゃーないと思います。そんな事をするよりは自分の好きな事を素直にやった方がいいでしょう。
ですが、極端に生活費を切り詰めるという方向性は、もしもあまりうまく行かなかったとしても金銭的にはノーダメージなのがいいですね。

サブスクはお金もらえて嬉しいだけでは済まないという点にも注意が必要です。お金を受け取ってしまった以上は、どうしても責任というものが発生してしまいます。
赤井さんはインタビューで「実験でやってるだけなので、この暮らしが気に入らなければやめればいい」と仰ってますが、とは言え112人からサブスクしてもらってる以上は、もし自分だったらもう後には引けないな…と思ってしまう気がします。

話変わりますが、オッドタクシーというアニメでもカバサワというキャラがサブスクでファンを集めた結果、自分の活動がどんどん後に引けなくなっていって過激化してしまうという描写がありましたね。

サブスクでなくとも、グッズ販売とかなら、もらったお金に対して対価のモノを渡してしまってそれ以上は求められずに済みます。その辺は使い分けなのかなと思いました。

参考

↓最近ではモバイルハウスのムック本なんかも出ています。ブームが始まりつつあるのかもしれないですね。

UE5の神的な新機能であるところの、「Nanite（ナナイト）」、いわゆる無限にポリゴンを表示できるというアレですが、それについての情報をメモ書きします。

6月5日に公式動画の“Inside Unreal Nanite編“が公開されました。

私は「エピックジャパンの人が日本語字幕付けてくれたら観ようかな」と思ってずっと待ってましたが、ついに日本語字幕が付いていたので早速視聴しました。
色々とためになる情報があったので、自分でも一応ブログにまとめておこうというのが今回の記事になります。

ちなみに、すでに公式ドキュメントで優れた情報が提供されていますので、私の記事よりまず先にそちらを確認されることをオススメします。

https://docs.unrealengine.com/5.0/ja/RenderingFeatures/Nanite/

Naniteの概要

概要について、まずは公式ドキュメントから引用させてもらいます。

Nanite は、Unreal Engine 5 の新しい仮想化ジオメトリ システムであり、新しい内部メッシュ フォーマットとレンダリング テクノロジーを使用して、ピクセル スケールの詳細と多数のオブジェクトをレンダリングします。あなたが知覚できるディテールだけをインテリジェントに処理し、それ以上は行いません。Nanite のデータ形式は高度に圧縮され、きめ細かいストリーミングと自動詳細度をサポートします。

なるほど…たしかに正確な説明なんでしょうけど、すいませんが何も知らん人がいきなりこれを読んでもちょっとよく分からないかも。

まあ要するに、Naniteはポリゴンを無限に描画できるようにする機能です。

Naniteの経緯

Naniteのメイン開発者であるBrianさんは、それまでずっとUE4のバーチャルテクスチャ機能に取り組んできました。

[UE] Virtual TextureとそのStreamingの仕組み、またよく頂く質問への回答

それまで３Dモデルのテクスチャというのは全ての解像度のミップマップを全部メモリに読み込んでましたので、表示する3Dモデルが多くなるにつれてメチャメチャメモリを消費していました。

しかし、バーチャルテクスチャのストリーミングによって、３Dモデルのテクスチャは”今この瞬間”必要なテクスチャの必要な部分だけをストリーミングしてメモリに読み込むので、つまりはどんだけ高解像度のテクスチャを大量に使っても、消費されるメモリはだいたい常に一定に収まるようになりました。
（メチャメチャ高解像度のテクスチャを作っても、普段は普通の解像度のミップマップしか読み込まれなくて、画面にモデルが大写しになるくらい近づいた時だけ読み込まれる）

つまり、ゲーム開発者はもうテクスチャのメモリ予算（バジェット）のやり繰りについて一切考えなくて良くなったという事です。
メモリを節約しなきゃ…とかいってテクスチャの解像度をケチったりしなくて良くなりました。

Brianさん達は、「このバーチャルテクスチャの考え方を３Dモデルのポリゴンにも応用できるんじゃね？」という大胆なアイデアを考え始めました。（というかBrianさんは10年以上このアイデアについてあれこれ考えていたそうです）

それで生まれたのがNaniteです。

つまり、Naniteとは一言で言えばバーチャルテクスチャストリーミングのポリゴン版と言えるでしょう。
言葉で言うのは簡単ですが、ポリゴンはテクスチャほど簡単に扱えるものではありません。死ぬほど困難な作業だったんじゃないかと想像できます。

とにかく、バーチャルテクスチャストリーミングによってテクスチャのメモリ予算について開発者は一切気にする必要が無くなったのと同様に、Naniteによってメッシュのメモリ予算についても気にする必要はなくなりました。

何が嬉しいのか

何が嬉しいって、無限にポリゴン出していいよとか言われたらそんなもんテンション爆上げだろうが！！
おっと、失礼しました。

ゲーム開発者ならご存知の通り、今までのゲーム開発では、描画できるポリゴン数には限界がありました。
つまり、描画するポリゴン数が多ければ多いほど負荷が上がるという事です。ポリゴン数に比例してパフォーマンスが下がります。まあ、最近はシェーダ負荷によっては必ずしもそうは言えないとか、モバイルだとポリゴン数よりフィルレートが問題だ、みたいな話もありますが、いずれにしろ、ポリゴン数は少ないに越した事はありませんでした。

ですので、限られたポリゴン予算をどう割り振るか、背景に何ポリ割り振るのか？自動車は何ポリでモデリングすればいい？そういう事をイチイチ悩むハメになりました。
こういう割り振りの設計は沢山のアーティストの思惑が絡み合って、みんな「俺のモデルにもっとポリゴン使わせろ！」とか主張し合って大喧嘩になったりして、大変労力がかかって面倒なものでした。

そして、少ないポリゴンのモデルでもリッチに見えるように、工夫するというか誤魔化すテクニックが色々とありました。
例えば、スカルプトなどで作ったハイポリモデルから、ちまちまとリトポ作業してローポリモデルを生成します。それで、ハイポリモデルから法線マップをベイクするといった作業です。

ついでに言えば、遠くのモデルは低ポリのモデルに差し替わるようにする工夫、LODというものもありましたから、それぞれのモデルについてLOD版のモデルも用意する手間がありました。

こういうのは、ぶっちゃけて言うと大して面白い作業ではないかもしれません。
リトポしたところで見映えが良くなるわけでは無いからです。できるだけ見映えが悪くならないように限界までポリゴン数を削るという、まあやらないで済むならそれに越した事は無い作業ではないでしょうか。

というわけで、今まではポリゴン描画数に限界があったので、ポリゴン予算割り振りの打ち合わせとか、リトポとか、まあぶっちゃけて言ってしまえばゲームのクオリティアップとは関係ない不毛な作業に大きな労力を取られるハメになってたわけです。

で、Naniteでポリゴン数の制限が取っ払われたら、どうなるのか？

アーティストはもうアレコレ悩む必要が無くなります。自分が作った最高品質のモデルが出し放題です！
リトポ？法線マップのベイク？もう不要ですよ。だってベイク前の超ハイポリモデルをそのまま使っていいんだもん。

CG映画で表示してたような鬼みたいにポリゴンが多い超ハイポリモデルでも、そのままUE5で表示してゲームに登場させる事が可能になるでしょう。

LOD的な技術もNaniteでは自動化されています。モデルが遠くに表示されるにつれてじわじわローポリに切り替わっていきますが、ゲームプレイヤーが知覚できない範囲で行われます。
LODみたいにパッとモデルが切り替わって、プレイヤーに違和感を覚えさせてしまうといった事は起きません。

Naniteによってアーティストの負担は軽くなります。
つまり、ゲームがより簡単に作れるようになるという事です。

性能

古代の谷デモ

ダウンロードサイズが100GBもあった事で話題のUE5の古代の谷デモですが、背景のモデルは一つ辺り100万～200万ポリゴンの超ハイポリMegascansモデルがそのまま使われてます。

さらに、古代の谷ステージ全体で100万個くらいのモデルが配置されてるそうなので、ステージ全体で1兆ポリゴンです。

それでもサクサク動作してしまいます。
これがNaniteの実力というわけです。

実装の詳細？

Naniteの実装の技術的な詳細についてはこの記事では取り上げません。
何故なら、私がよく分かってないからです。

Naniteは魔法みたいなテクノロジーですが、技術的にはやはりメチャクチャややこしい事を沢山やってるようです。
私はUE5でNaniteを使えさえすればよいので、詳細についてはそこまで興味ありません。
どういう使い方をすればいいのかさえ知れればそれでいいです。

↓Naniteの技術的な詳細に興味がある方は、Nanite作ったBrianさん達がSiggraph2021で発表した講演の資料がこちらにあるのでそっちを見てください。

http://advances.realtimerendering.com/s2021/

メッシュのクラスタリングとオクルージョンカリング

さて、Naniteは無限にポリゴンが描画できると言っても、クソ真面目に超超ハイポリゴンをそのまま全部描画してるわけではありません。
目一杯メッシュに近づけば、たしかに元のハイポリメッシュそのままで表示されますが、遠くになるにつれてメッシュはこっそり荒くなっていきます。

とは言え、それは人間に知覚できないレベルで起きます。Nanite以前は遠くのメッシュはLODに切り替わったりしてましたが、あれだと切り替わりの瞬間に明らかにパッとローポリに切り替わったな…という事がモロバレになったりしてましたが、Naniteではポリゴンが荒くなる変化には全く気付きません。

つまり、どんだけ高ポリゴンのモデルを画面に大量配置しても、結局画面内のポリゴン密度は変化しないという事になります。
ですから、画面上に何ポリゴン出そうが、結局描画する量は一定であり、負荷も一定になるという事です。

さらにNaniteではほぼ完全なオクルージョンカリングが行われます。
Nanite以前でもモデル単位のオクルージョンカリングは行われてましたが、モデル単位であり、モデルがほんの一部でも画面に映ってたら、当然ながらモデル全体が描画されていました。

しかし、Naniteでは無駄な描画をピクセルレベルで弾くようです。つまり、基本的に画面のピクセルごとに１回ずつしか描画されない事になります。
常に最小限の描画だけがおこなわれるので、これも描画負荷一定に繋がります。

とは言え、オクルージョンカリングは完全ではなく、条件が悪いと複数回描画（オーバードロー）されるピクセルも出てきます。
例えば、古代の谷サンプルも実は条件が悪いです。古代の谷はMegascansのモデルをキットバッシュ的に配置して作成されていますが、つまり見えない部分で沢山のメッシュの重なりが発生しており、あまりに近い距離でメッシュが重なってるとNaniteはオーバードローが発生してしまいます。

↓これは古代の谷のNaniteオーバードロー表示です。色が明るい部分ほどオーバードローが沢山発生しているという事です。