はじめに
2024年1月1日に VGS-Zero (Video Game System - Zero) という RaspberryPi Zero 2W のベアメタル環境で動作するオリジナルのゲーム機エミュレータと SDK を公開しました。
VGS-Zero は、RaspberryPi Zero 2W をテレビに HDMI ケーブルで接続し、USB ゲームパッドで遊ぶタイプ（据え置き型）の新しいゲーム機です。
無料でゲームを開発＆販売ができる SDK も公開していて、開発したゲームを完全ロイヤリティフリーで自由に販売して頂くことができます。
なお、OS は Linux ではなく独自カーネルです。
特徴
VGS-Zero の特徴について、カーネル視点とゲーム機視点の両面から解説します。
独自カーネルの特徴
ラズパイ全般（※Picoを除く）は Linux で動かすのが一般的ですが、VGS-Zero は OS 無しのベアメタル環境 で動作するので、レインボースクリーン（VideoCoreIVの初期化処理）の後、わずか2〜3秒でゲームが起動します。
ラズパイ（GPi Case）、Rockchip、AllWinner などの Linux を用いたよくあるエミュレータゲーム機とは異なり、永い OS のブート待ちに暇を持て余したり、SD カード破損のリスクに怯えることなくサクッとゲームをプレイできます。
些細なことかもしれませんが、どうやら私にとってそれはかなり重要な事のようです。
3秒間で仕度しな！（超絶アスペ？）
これは、私が超絶アスペという訳ではなく、ポケットから取り出して瞬時にスリープモードから復帰してプレイアブルな状態になるデバイス（スマートフォン）に慣れきってしまった現代人にとって死活問題なのかもしれません。
私は GPi Case や中華ゲーム機（RG350Mなど）といったガジェットを何台か持っているのですが、恐らく Linux + SD カードという組み合わせの悪さ に起因する諸問題がダルくなって遊ばなくなるのではないかと考えられます。
それらのハードウェアは解析用途で買ったものでゲームを遊ぶことは殆ど無いため、実際のところはよく分かりませんが...昔のゲーム自体は結構好きなのですが、最近は昔のゲームカセットの値段が高すぎるという事情もあり、昔のゲームが遊びたければ任天堂Switchのサブスクに入るのが一番かなと。
「起動速度だけが問題であれば気にならない」という人間ができた方も多くいらっしゃると思われますが、「媒体の耐久性の低さ」は問題だと思う方は多いかもしれません。私もこれまで何度 SD カードを壊したことか...（久々に遊ぼうとして半年ぶりに充電して電源投入したら GRUB で固まるとか）
一般的な Linux カーネルは OS を起動するだけでも無数のファイル入出力を行うため、入出力（特に出力）の耐久性が極めて低い SD カードで Linux を動かすと、電源断によるデータ破損やファイルシステム不整合などに陥りやすく、メディア交換や OS 再インストールなどの面倒な作業がカジュアルに発生します。（※メディアが壊れた訳ではなく電源系が安定せずに落ちてしまいファイル不整合というパターンも多いかも）
そもそも、Linux カーネルは SD カードにインストールして動かすことを想定した設計ではないと思われます。（参考までにリーナス・トーバルズが Linux の開発を始めたのは 1991 年で、SD カードの規格が制定されたのは 1999 年です）
一方、VGS-Zero は Linux とは異なる Circle ベースの独自カーネルです。
Linux カーネルはサーバ用途、デスクトップ用途、プログラミング用途、ゲーム用途など「何にでも使える汎用性」がありますが、VGS-Zero カーネルはゲーム（game.pkg）しか動かすことができません。
VGS-Zero カーネルが SD カードへの I/O を行うのは、ブート時の game.pkg の読み込み（read only）と、save.dat（セーブデータ）のロードとセーブに限られています。
game.pkg のサイズは最大 16 MB (128メガビット) です。
「100メガショック」で有名なあの NEO-GEO を上回る巨大なサイズですが、RaspberryPi Zero 2W には無限に等しいサイズの RAM（512MB）が搭載されているので、ブート時に全て読み込んで記憶することが可能です。
また、VGS-Zero のセーブデータは最大でも 16KB と極めて小さく、更にデータの中身に更新が無いセーブデータの保存リクエストはカーネルが write skip します。これにより、書き込み耐久性が低い SD カードの寿命を最大限に延ばす「SD カードに優しいデザイン」にしたつもりです。（これでもまだ「もっと優しくする余地」が残っています）
VGS-Zero 独自カーネルは RaspberryPi Zero 2W の 1GHz クアッドコア（4 コア）の CPU リソースのほぼ全てを余すこと無く全力 で使用して Z80、VDP、VGS（音声システム）のエミュレーションによりゲームを動かします。
ゲームを動かすのにエミュレーション技術を採用する理由は、VGS-Zero カーネルとゲームのコードバイナリの分離のため です。
Windowsなら.exe、Linux なら elf に相当するものが VGS-Zero の game.pkg で、このファイル内にプログラムコードと画像イメージ等の 8KB バンクデータ（最大 256個）、BGM データ（最大 256曲）、効果音に用いる 44100Hz 16bit 1ch の PCM データ（最大 256個）が格納されています。
RaspberryPi 版の VGS-Zero カーネルは、GPL ライセンスの Circle を使っているため、実行形式ファイルをカーネルから分離しなければゲーム側のライセンスを自由に設定できない不自由が生じます。
そのような不自由は避けたかったため、game.pkg をカーネルから分離しました。これにより、VGS-Zero カーネルだけオープンソースにすればライセンス上の問題が発生しなくなります。
なお、それだけの理由なら .exe や elf などと同じようにネイティブコード（ARMv8）の実行形式ファイルにした方が性能面でのメリットが大きいです。
しかし、ゲームのコードがネイティブコード（ARMv8）に依存すると将来的に互換性の問題が発生することになるため、VGS-Zero では LLVM の代用として Z80 を採用しました。
幅広いプログラミングを行う上で Z80 では不便なところも多いかもしれませんが、ゲームのプログラミングであれば Z80 で必要十分だと私は考えています。（これは若干暴論かもしれませんが...）
Z80 なら私が開発したエミュレータ（MIT ライセンスの OSS）があり、それを使えば権利上の問題が発生しないという利点も大きいです。
Z80 エミュレータなら LLVM よりも遥かにコードサイズが小さく（シングルヘッダで使える!!）、クロスコンパイラやデバッガなどのツールチェインが豊富にあり、MSX や PC-88 などでプログラミング経験がある人も多い（学習コストが低い）など、他の CPU（エミュレータ）や LLVM と比較しても多くの採用メリットがあるかもしれません。（Rust は使えませんが）
ゲーム機としての特徴
VGS-Zero には 16MHz の超高速な Z80 CPU（エミュレータ）が搭載されていて、更に 16KB の巨大な RAM 領域の全てを ゲームプログラムで専有 することができます。
RAM (16KB)
実際に Z80 CPU のコンピュータでプログラミングした経験がある方なら、16KB は必ずしも「巨大なサイズ」ではないと感じるかもしれません。
例えば MSX2 なら最低でも 64KB の RAM が搭載されていますし、PC-8801 のメイン RAM も 64KB です。（ちなみにゲームギアは 8KB ですね）
VGS-Zero は 16KB の RAM でも必要十分になるようにハードウェア全体での最適化設計がされているため、実際にプログラムを組んでみると大きすぎて持て余す筈です。（少なくとも私ならゲームギアの 8KB ですら結構持て余します）
参考までに、後述の Battle Marine が β1 時点で使用していた RAM サイズ（スタック領域と合算）は 2KB 以下でした。これは、メモリ削減に苦労した結果ではなく、むしろ（何も考えずに）かなり冗長に作った結果が 2KB でした。つまり、その 8 倍の 16KB もあれば、プログラマが「メモリが足りない!!」と嘆くことはほぼ無いと想定しています。
削りすぎる意味もない（8KB にするとミラーリングが必要なのでエミュレーションのオーバヘッドが若干大きくなる）ので、エミュレーションの総計算量が最も少なくなる 16KB を確定仕様としました。
なお、16KB を超えると RAM バンク等の実装が必要になり、エミュレーションのオーバヘッドが大きくなるだけでなく、ハードウェア仕様も複雑になってしまうのでよくないと考えました。
万が一足りなくなっても VRAM のキャラクタパターンテーブル（8KB）を RAM の代用として使える裏技仕様も用意されているので、プログラマが RAM 不足に悩むことはまず無いだろう...と思いたいです。
それでも足りなくなったら、VRAM バンク切り替えに対応してキャラクタパターンテーブルを複数バンクに対応するとかかな...RAM 増設の逃げ道はいくらでもあるのですが、最初からその仕様にするとハードが複雑になってしまうので、先ずは「拡張余地を残しつつシンプルに」する方針で設計しています。
音源システムとゲームシステムの分離
Z80 時代の一般的なゲームコンソールでは、AY-3-8910 (PSG 音源) や FM 音源などのチップチューン音源で音楽や効果音を再生するため、チップチューン音源の制御プログラム（音源ドライバ）に一定量の CPU リソースを割り当てる必要があり、また音楽や効果音のシーケンスデータやシーケンス制御処理用に一定量の RAM リソースを割り当てる必要があります。
VGS-Zero には VGS (Video Game Sound) という SUZUKIPLAN が開発した独自のチップチューン音源を搭載していますが、この音源ドライバ・プログラムは RaspberryPi Zero 2W のネイティブ・コード (ARMv8) で動作し、音楽（MML）と効果音（.wav）のデータもネイティブ RAM (512MB) 側で管理しているため、ゲーム側（Z80)の CPU と RAM をほぼ専有する必要がありません。
必要な CPU リソースは音楽や効果音の開始・停止などを指示する OUT 命令の実行（1回の指示につき1回）のみです。これは、クロックレートが低い Z80A でもほぼ無視できるオーバーヘッドです。
例えば AY-3-8910 の ch1 で音を鳴らすには、音程周波数の設定に 2 回のレジスタラッチと 2 回のデータライト、音量設定に 1 回のレジスタラッチと 1 回のデータライトで最低でも 6 回の OUT 命令の実行が必要です。それを 3ch 分実行する必要があり、ミキシングやエンベロープ設定などもすれば更に増えるため、膨大な数の OUT 命令を実行しなければなりません。しかし、VGS なら音楽や効果音の再生 or 停止指示の時に 1 回の OUT 命令実行のみで事足ります。
また、開発難度（専門性）が高い音源ドライバの開発リソース（予算）をゼロに出来る点も大きいかもしれません。
個人的にこの点のメリットが一番大きいと考えています。
音源ドライバを開発するのはそこそこ大変なので、チップチューン音源を搭載したゲーム機のゲームのスタッフロールを眺めると、メインプログラマとは別にサウンドプログラマというスタッフが居ることに気づくと思われます。
もちろん、メインプログラマがサウンドプログラマを兼任しているケースもあるかもしれません。また、作曲担当者が音源ドライバの開発をしていたケースもあるかもしれません。（古代祐三さんとか？）
家庭用ゲーム機の音源ドライバ関連の業界事情はよく分かりませんが、パソコンの場合 PC-98 版の東方 Project（旧作）の音源ドライバも作者（ZUN さん）による自作ではなく PMD が使われていました。
PMD はフリーの音源ドライバで MML コンパイラがシェアウェア（有料）というスタイルでマネタイズされていたものですが、とても出来が良かったので商用のゲームソフトで使われているものも多くありました。海月製作所のラブ・エスカレーターとか。（※ラブ・エスカレーターは雑誌に付属していたデモしか見たことがないのですが PMD が常駐していたと思われます）
PC-98 では PMD 以外にも FMP やツクールシリーズの MUSIC.COM なども有名だったかもしれません。私も PC-9801 でプログラムを組んでいた中学生の頃はチンプンカンプンだったので大人しく PMD の MML コンパイラを郵便小為替で買って使っていました。
大人＆職業プログラマになった今なら PMD 相当のものを自作できると思いますが、仮に PC-98 でゲーム制作をする案件がきたら PMD、PC-88 であれば可能なら（※）MUCOM88 を使うと思います。（つくるのが大変なので）
※ MUCOM88 のライセンスは CC BY-NC-SA 4.0 なので、非営利目的なら使うことができます（当然ながら営利目的の案件の場合は無理なので自作するしかない）
実は当初、VGS-Zero では PSG+SCC を音源システムとして採用しようと考えていたのですが、Z80 で作られたライセンス面での問題が無さそうな OSS の音源ドライバが見つからなかったため、ライセンス面で 100% 問題無い VGS (2か条BSD でそもそも完全自作) を採用した経緯があります。
Z80 での扱いやすさを追求した独自 VDP
VGS-Zero は、VDP（Video Display Processor）を用いてグラフィック出力をする古典的なテクノロジーを採用したゲーム機です。
そのため、MSX、ファミコン、SG-1000、セガ・マスターシステム、ゲームギア、メガドライブ、スーパーファミコン、X68000 あたりの VDP (PPU) を搭載したコンピュータでゲーム開発経験があるプログラマであれば、ほぼ学習無し（VRAM メモリマップを参照するだけ）でプログラミングできるものと思われます。
フルアセンブリ言語で記述する必要が無い分、それらのコンピュータよりも更に難度が低い筈です。
ただし、C言語を使う必要があるので、BASIC でプログラミングが出来る MSX よりは若干難度が高めかもしれません。
また、一般的な VDP では 2 回の OUT ポート出力で VRAM アドレスをセットしてから I/O で VRAM の入出力をする必要がありますが、VGS-Zero の VDP（VGS-Video）は VRAM が Z80 から見えるメモリ上（0x8000〜0xBFFF）にマッピング（mmap）されています。
これにより I/O 命令無しで高速な VRAM アクセスができる形になっています。
VGS-Video は基本的に C言語 のプログラムで扱うことを想定していますが、仮にフルアセンブリ言語で組むにしても MSX や家庭用ゲーム機などよりも構造がシンプルなので簡単にプログラミングができる筈です。
VGS-Video では、BG（背景）、FG（前景）、スプライトの3レイヤーを扱うことができ、BG/FGを独立してハードウェアスクロールすることができます。スプライトは256個を同時に表示でき、水平上限がありません。
スキャンライン位置は、セガ・マスターシステム（mode4）、ゲームギア（mode4+）、メガドライブ（mode5）などと同様にVカウンタで取得できるため、ラスタースクロールの為に IRQ を実装する必要がありません。
一応、IRQ を使うこともできるようになっていますが、IRQ 一切無しでプログラミング可能なハード仕様に設計しました。（フル C言語 で組もうとすると IRQ を使うのが面倒なので）
8bit CPU で扱う VDP としてはかなりゴージャスに感じるかもしれませんが、これだけの機能を 16KB という TMS9918A (MSX1 や SG-1000 に搭載されている VDP) と同じサイズの VRAM で実現できています。
MSX2 の VRAM は最低 64KB (※標準的には 128KB) なので、MSX2 の 1/4 のサイズです。
VRAM のメモリマップはざっくり纏めると以下のような構造です。（詳細はコチラ）
| CPU address | VRAM address | Map |
|---|---|---|
| 0x8000 ~ 0x83FF | 0x0000 ~ 0x03FF | BG ネームテーブル (32 x 32) |
| 0x8400 ~ 0x87FF | 0x0400 ~ 0x07FF | BG アトリビュート (32 x 32) |
| 0x8800 ~ 0x8BFF | 0x0800 ~ 0x0BFF | FG ネームテーブル (32 x 32) |
| 0x8C00 ~ 0x8FFF | 0x0C00 ~ 0x0FFF | FG アトリビュート (32 x 32) |
| 0x9000 ~ 0x97FF | 0x1000 ~ 0x17FF | OAM (8 x 256) |
| 0x9800 ~ 0x99FF | 0x1800 ~ 0x19FF | パレットテーブル (2 x 16 x 16) |
| 0x9F00 ~ 0x9F0A | 0x1F00 ~ 0x1F0A | 色々な VDP レジスタ |
| 0xA000 ~ 0xBFFF | 0x2000 ~ 0x3FFF | キャラクタパターンテーブル |
なお、キャラクタパターンテーブル（8KB）は VRAM に展開しなくても ROM のバンク番号を指定して VROM として扱う機能（DPM; Direct Pattern Mapping）もあり、その機能を使えばキャラクタパターンテーブルの 8KB を RAM として代用することもできます。
ROM の特定バンクをキャラクタパターンにロードする DMA 機能があるので、例えば RPG や STG のマップなど、ROM バンクから色々なデータを読み込むためのロード・エリアとして活用することを想定しています。（キャラクタパターンテーブル本来の用途よりも代用の用途の方がメインになる想定です）
VRAM サイズを 16KB にしたのは Z80 でのプログラミングをしやすくするため（Z80 ファースト） です。
VRAM と RAM が各 16KB になっているからこそ、I/Oを一切使わずに RAM アクセスが実現できているため、Z80 のプログラムをシンプルにすることができ、結果的に（私にとって）ゲームが創りやすくなります。
フルアセンブリ言語でのプログラミングが簡単になるのはもちろん、C言語でもポインタアクセスで簡単に VRAM 操作ができるメリットは大きいです。ポインタアクセスのみで VRAM 操作ができればインラインアセンブラで実装が必要な箇所が少なくなり、フル C言語 での高速な VRAM アクセスが可能になります。
VGS-Video の弱点としては、スーパーファミコンやメガ CD の VDP のような回転、拡大・縮小、半透明に対応できていない点です。（この点については、RaspberryPi Zero 2W の性能限界もあり実現できませんでしたが、あった方がバンク数やグラフィックデザイナーの労力を抑えられるので良いと思っています）
また、ポリゴンは使えません。
ポリゴンは酔うのであまり好きではありません。
メガドライブや X68000 相当の VDP をシンプルに強化したイメージ でハードウェア仕様を設計したつもりです。
ゲームに特化した演算ハードウェア（HAGe）
Z80 でゲームプログラミングをすると、2のn乗を除く乗算、除算、剰余算やアークタンジェント（角度を求めるために必要な三角関数）の計算処理がボトルネックになりがちですが、それらの計算処理を高速に実行できる HAGe (High-speed Accumulator for Game）と呼ばれるゲーム向けの演算用途に特化したハードウェアを搭載しています。
HAGe の力により、弾幕 STG などのように素の Z80 では高速動作させることが難しいゲームでも、簡単＆高速に実装できます。
また、C言語の memset, memcpy に相当する DMA ハードウェアも搭載しているので、メモリ間のブロック転送が（LDIRよりも）かなり高速に実行できます。
これらの特徴により 「C言語のみ」でも 16bit の商用ゲーム（メガドライブ）相当のゲームが開発可能 です。
金色に輝く「16-BIT」でお馴染みのメガドライブのメイン CPU は MC68000 ですが、VGS-Zero の Z80 はクロックレートだけならその倍程度のスピードで動きます。（MC68000 は 32 ビットレジスタが使えるので羨ましい限り...将来的に自作の MC68000 エミュレータを作ったら MC68000 搭載版 VGS-HEX とかも出すかもしれません。自作じゃなくてMusashiで良いかもしれませんが）
Z80+C言語で商用相当のゲーム開発
一般的な Z80 を搭載しているゲーム機（セガ・マスターシステム、ゲームギアなど）やパソコン（MSX、PC-88など）でクオリティの高い商用ゲーム開発をするにはフルアセンブリ言語でのプログラミングがほぼ必須です。
もちろん、性能がそれほど要求されないタイプのゲーム（RPG、ADV、SLGなど）であれば、商用ゲームでもC言語やBASICで作られたものもあったかもしれませんが、Z80全盛期（1980年代）のゲームの花形はアクションゲームで、大量のキャラクタを滑らかに動かす必要があります。
大量のキャラクタを滑らかに動かそうとすると、BASICはもちろんC言語でも結構厳しくなります。
商用ゲームでもC言語が使われ始めたのは16ビットCPU以降で、パソコンであれば PC-9801 や X68000 あたりではないかと思われます。
私はその時代の商用ゲームを作ったことが無いので実際のところは分かりませんが、16ビットの時代はフルアセンブリ言語で作られたプログラムが神格化されつつあり、32ビット時代になると完全なオーパーツ（幻想入り）になったという印象です。
ですが、VGS-Zeroのスペック（16MHz）なら 8 ビット CPU でもC言語で十分商用クオリティのゲーム開発が可能だと考えています。
ちなみに Z80 を 16MHz にした理由は、ターゲットデバイス（RaspberryPi Zero 2W）のベアメタル環境（OSを用いずCPUとRAMを完全専有できる環境）のシングルコアで Z80 エミュレータ（自作）を動かす限界性能が 16MHz だったためです。
ターゲットデバイスを RaspberryPi 4 にすれば、Zero2 の 1.5 倍ぐらいの速度なので 24MHz ぐらいでもイケたのですが、4は結構高い（1万円ぐらいする）ので、3,000円ぐらいでお手軽に購入できるZero2を採用。
本当はもう少しだけ速くしたかったのですが...
（具体的には後期 80486 ぐらいの性能が欲しかった）
VGS-Zero でのゲーム開発事例
VGS-Zero のリポジトリに豊富な examples も用意したので、あとは誰かが面白いゲームを作って販売して大ヒットしてくれれば良いのですが、どこの馬の骨とも知らぬ謎のゲーム機向けに本気でゲームを創ってくれる人は私以外に存在しない筈なので、まずは自分で創ってみました。
このゲームは、2024年1月1日〜2024年1月28日までの約1人月 で開発しました。
ゲームデザイン、プログラミング、グラフィック、音楽、効果音を全て私1人で創ったので 純粋な1人月の工数 でこれぐらいのゲームが創れます。
実際のところは片手間（趣味）で開発しているので、専業で頑張れば 1〜2人週以下ですが
VGS-Zero のデモンストレーションを兼ねたものなので、無料でプレイできるのは勿論、ソースコードやアセットデータも全て GitHub で公開しています。
このゲームは、工数制約を課した上で企画、デザイン、作曲、プログラミングの全てを私が独力でやった場合どれぐらいのゲームが創れるか というベンチマークを兼ねて開発しましたが、もちろん、ゲーム本編も手抜きをせず「ちゃんとした市販ゲームとして売り出せる水準」のものを目指したつもりです。
趣味で開発するものなら市販ゲーム水準のクオリティを目指す必要はないかもしれませんが、様々な事情があり「一定数売れるゲーム」を創る必要性が生じました。（後述）
VGS-Zero が目指しているもの
VGS-Zero は一応「ゲーム機」と名乗ってますが、既存のゲーム機に競合するつもりは全く無くて（相手にされるとも思っていなくて😂）、仮に何らかのマーケットを狙うとすれば 新しいゲームを開発する上でのテストプラットフォーム のようなポジションでしょうか。
もちろん、Unreal Engine などのガチのゲームエンジンと競合するつもりもなくて、ハイクオリティな（AAAタイトル等の）ゲーム開発なら VGS-Zero よりも Unreal Engine の方が優れているのは明白です。
ですが、開発予算はかなり抑える事ができます。
具体的には、ゲーム開発を生業とする企業が本気でゲームを創った時の予算を、スーパーファミコンやメガドライブの頃のソフト（1タイトル1,000〜5,000万円）ぐらいに抑えられるようにしたつもりです。（プロトタイプ開発なら Unreal Engine でもそれよりも安く作れると思いますが販売ができるクオリティにはならない筈です）
BGM（VGS）の仕様のクセが強めですが、難度が高いサウンドドライバのプログラミングが不要というメリットがあるので、サウンドドライバのプログラミングが必要だったスーファミやメガドラの開発費よりも安く抑えられます。（BGM のクオリティ面ではVGSの「BGMだけ」でもヒットアプリを創ることができたので問題無いかなと）
何ならカーネルを改造して FM 音源エミュレータを載せれば良いかと。カーネル側なら GPL の OSS でも問題なく使えるので比較的簡単かと思われます。
もちろん、改造した alter VGS-Zero (?) は GPL 汚染されるので OSS として公開しなければなりませんが、game.pkg がカーネルから分離されている限り、ゲームのソースコードを OSS にする必要はありません。
先ずは3,000万円前後のお手頃な予算で VGS-Zero 向けにゲームをサクッと作って販売し、そこでヒットしたタイトル（ドラクエなりFFなりのようなタイトル）が創れたらSwitchやPlayStation向けにしっかりとした予算（うん億円？）を組み、Unreal Engine なりを使ってゲームを開発すれば、投資効率良くハイクオリティな面白いゲームを世に出せるのではないか？...と、思ったり思わなかったりしています。
「今どきスーファミクオリティのゲームなんて売れるのか？」という点が最大の懸案事項だと思われますが、その点について私は「ゲームは面白ければ売れる」と信じています。
ただし、私は AAA タイトルのようなものには全然興味が無くて、ゲームはスーパーファミコンやメガドライブぐらいの頃のものが混沌としていて面白かったと思っている節もあるので、上述の盲信は思い出補正による「お花畑思考」かもしれません。
なので、「思ったり思わなかったり」することしかできません。
営利企業で「3,000万円前後のお手頃な予算」の予算稟議を通すのがどれだけ大変なのかも理解しているつもりなので、発言を裏付ける「確たる何か」が欲しいところです。
私が VGS; Video Game System で創りたいものは 「私にとって最もビデオゲームが創作しやすいプラットフォームの創出」 の一点のみで、その点に限れば VGS の初期設計をした 10 年以上前からずっと揺らいでいませんが、果して VGS が私の単なる自慰行為なのか、はたまた商業で通じるものなのか。
という訳で、それを試すのにうってつけの悪夢のような企画を考えてみました...
任天堂Switch対応（予定）
VGS-Zero を 任天堂Switch で使える SDK にする というかなり無謀な目標を設定してみました。
多分、Switch に対応すればガチのゲーム会社が VGS-Zero を使ってくれるようになるかも？という非常にシンプル且つ浅はかな目論見です。
ガチのゲーム会社さんが VGS-Zero で（もちろん本気で）開発したゲームなら私なんかが創ったゲームより絶対に面白くなる筈です。ガチのゲーム会社さんに限らず、地球上には私より面白いゲームを創れる才能があるクリエイターはあまりにも多く居るので、彼らに面白いゲームを創ってもらうことができれば、先述の「スーファミクオリティでもゲームは面白ければ売れる」ということが証明できるのではないかと。
なお、仮に私以外の人や法人が VGS-Zero で創ったゲームで大ヒットしても私には 1 円も入らないことになりますがその点は全く問題ありません。お金を稼ぐことはスコアアタックみたいで面白いからそこそこ好きなのですが、そこに固執して VGS-Zero の可能性をシュリンクさせる程度の価値は無いという認識です。
という訳で、ダメ元で任天堂さんに Battle Marine の 任天堂Switch移植 のための開発リソースのアクセス申請を（もちろん個人名義で）してみたところ「Steam、スマホまたは家庭用ゲーム機でのゲーム販売実績が必要」とのことでリジェクトされてしまいました。
正直、法人じゃないと相手にされないかもと思っていたので、今の任天堂さんは寛大です。
必要なら法人を設立しようと思っていましたが、法人を作るのは色々面倒くさいし住民税が勿体ないと思っていたので助かります。
単に Steam やスマホに移植して有料販売をするだけなら簡単過ぎるので、任天堂Switchでゲームを出す以上「ちゃんと一定数の売上が見込めるタイトル」にしなければダメだと思います。（もちろん、リジェクト理由にそこまでのことは書かれていませんでしたが、恐らくそういったコンテキストなのだろうと勝手に解釈しておきました）
という訳で、まずは VGS-Zero SDK for Windows (※これは OSS ではなくクローズドで開発中) を完成させて Steam での販売を目指し、その後 iOS、Android 向けにも有料で販売してみようと思っています。（スマホアプリなら一瞬で作れるので Steam ファーストで）
今回は Free To Play（広告付きの無料や基本無料）は無しで有料販売縛りにします。（ラズパイなどのマニアックな機器を持っていれば無料で遊べる形にしているので厳密には F2P かもしれませんが）
Steam(Windows) + iOS + Android での売上目標は 税込み 550円 で売って合計 3,000 本 です。
3,000 本に届かなければ次のゲームを創ってまたチャレンジ、無事 3,000 本に届いたら再度（今度はシッカリと企画書を書いた上で）任天堂の審査に挑もうという所存です。
なお、3,000 本という数字には根拠があります。
売上 550 円から消費税 50 円と販売手数料 150 円を差し引いた粗利を 350 円として、私の工数を（かなり雑に）1 人月 100 万円とした時の損益分岐点（リクープライン）が約 2,858本 になるので、1 人月で開発したゲームなら約 3,000 本売れれば利益がでる（=ビジネスになる）と客観的に判断できます。（販売価格を 550 円 から 1,100 円にした場合のリクープラインは1,429 本）
最終売上 3,000 本だと粗利は 105 万円だから、開発工数（100 万円）を差し引いた利益率は 5% (5万円) なので、利益率としてはかなり微妙なところですが、赤字と黒字の間にはとてつもなく大きな壁があります。
当然ながら、倍の 2 人月掛けて開発した時の目標値は 5,715 本にハネ上がるので、開発に時間を掛けるほど目標の最低ライン（リクープライン）は高くなります。
なお、1 本目はベンチマークとして 1 人月縛りにしましたが 2 本目以降は 1 人月縛りにはしない予定です（ただし、価格は $5 から変えずリクープラインのみで調整する方向で）
10 年ぐらい前に初代 VGS を使って半年ぐらい掛けて創ったスマホゲームを $5 で販売した時の実績が約 500 本だったので、1 人月で創って 3,000 本 というのは私にとってかなりチャレンジングですが、これが達成できれば前章の下記の発言に自信が持てるようになるかもしれません。
先ずは3,000万円前後のお手頃な予算で VGS-Zero 向けにゲームをサクッと作って販売し、そこでヒットしたタイトル（ドラクエなりFFなりのようなタイトル）が創れたらSwitchやPlayStation向けにしっかりとした予算（うん億円？）を組み、Unreal Engine なりを使ってゲームを開発すれば、投資効率良くハイクオリティな面白いゲームを世に出せるのではないか？...と、思ったり思わなかったりしています。
私の場合、目指すゴールは「予算うん億円の AAA タイトル」ではなく「任天堂Switchで（ほぼ）AS IS での販売」ですが。
また、純粋な「スーファミやメガドラのソフトと同じぐらいのクオリティのソフト」にするのであれば 3,000 万円程度の工数（30ヶ月）を掛ける必要があるので、1人月のクオリティで果たして同等に語れるのか？という問題があるかもしれません。（この点は、ある程度ボツ・ラインナップが増えてから検討するかも）
NKT が始まる...
少し補足すると、単価 ¥550 の買い切りモデルだと広告出稿して伸ばすのも厳しい（ほぼ 100% 赤字になる）ので、恐らく実現可能性はかなり低いと想定しています。単価 ¥550 という価格設定は広告出稿により売上を伸ばすプロモ手段を禁じる為の枷でもあります。もちろん、プロモなしでゲームが売れる筈がないと思っているので、初動は赤字でも良いから一定数の広告なら打つとは思いますが、赤字が膨らめばリクープラインが更に高くなることになります。（お金がかからないプロモなら全力で頑張る）
私の経験上「有料販売はそんなに甘くない」と思っているので、3,000 本どころか Steam のタイトル出品手数料 15,000円 にすらに届かない「ボツ・タイトル」がどんどん増えていくことなるだろうと想定していますが、結果的に VGS-Zero で遊べるそれなりのクオリティの カタログ・ラインナップ が増える ことになるので「それはそれでアリかな」などとマゾマゾしいことも考えていたりします。