はじめに
以前、以下の記事で紹介した VGS-Zero で Steam 対応の SDK を OSS として公開しました。
以下が Steam 対応の SDK (VGS-Zero SDK for Steam) です。
Linux でゲーム（game.pkg）を開発後、Windows、Linux、macOS でこの SDK を使い各 OS 用の実行モジュール（.EXE, elf）を作成する形になります。
この SDK は、VGS-Zero のローンタイトル（Battle Marine）の Steam 版をコードベースに SDK 化したものです。そのため、この SDK を使って実際に Steam でのゲーム販売をした実績はまだありません。（バグっていたらスミマセン
）
次回作以降では私もこの SDK を使って VGS-Zero で作ったゲームを Steam で販売する予定です。
今は円安がかなり進行していることもあり、Steam でヒットできれば外貨が稼げるチャンスかもしれないので、日本人がどんどん面白いゲームを創って Steam で発売することが日本の国益に資するかもしれません。そこまで高尚なことは考えずとも、ドル建てなら同じ 500 円でも 750 円になるので、今なら海外でヒットできればシンプルに儲かりそうですし、価格勝負で優位に立てるアドバンテージは大きいです。
2015 年ごろに私が書いた記事に次のようなことが書かれていました。
仮に今、真剣に個人でゲームを作って公開するなら、Steamとかでやった方が良いハズ。Steamはスマホアプリ市場と違って、運営型ではなくパッケージ型のモデルが今の所主流なので、未来がありそうな気がします。スマホアプリ市場と同じ道を辿る可能性も五分じゃないかとも思っていますが
それから約9年間の月日が流れた訳ですが、結果的に Steam でも運営型が一定数あるもののパッケージ型も健在なので、「真剣に個人でゲームを作って公開するなら、Steamとかでやった方が良いハズ」という意見は今でも変わっていません。
ですが、AppStoreであろうがSteamであろうが、有料でゲームを売ることはとても大変なことです。
という訳で、これから Steam で（VGS-Zero に限らず）ゲームを販売しようと思っている方々に向けて、私が今回 Battle Marine を Steam で販売するに当たって「売れるため」に実施した要点事項をなるべくローコンテキストで解説してみます。
「これを抑えればヒットできる」というものではないです（実際まだヒットしてません）が、私なりに考えた「ゲームが売れるために必要なこと」を全て実践してみたつもりです。
Qiita での投稿ということで技術的な内容に絞った方が良いと思いつつ、やや営業寄りの解説が多めになってしまったかもしれません。
技術的には十数年前から変わらないレガシーな内容なのであまり目新しいことはありませんが、スマホアプリ開発に掛かりきりだった身としてはオーパーツ化しつつあった記憶を引きずり出すのに中々苦労しました
(1) どの OS に対応すべきか
Steam は Windows、Linux、macOS に対応しています。
私はまず「営業視点」でどのOSに対応すべきかを考え、その後、「技術視点」で対応方式を検討するアプローチで開発を進めました。
（営業視点）
現時点で PC ユーザの 7 割以上は Windows を使っているらしい（参考）ので、Windows への対応は MUST です。
本業の会社から支給された Windows PC は持ってますが、流石にそれを使って個人事業の開発をするのはマズイかもしれないので、2 月初旬に Microsoft Surface Laptop GO2 を購入しました。
本当は GO3 が欲しかったのですが、10万円を超えると資産化（減価償却）が必要で面倒くさいので、楽天市場で 8 万円ぐらいで購入できた GO2 にしました。久々（約10年ぶり）の Windows 機ですが、開発機材ではなく私物での購入だったとしても満足度が高い買い物だったかもしれません。特に MacBook 慣れした人にとって快適に使えるようになっている印象なので、Apple へのフラストレーションが臨界点に達せられた方々にオススメかもしれません。
また、PC の OS シェア率 2 位の macOS は近年シェアを伸ばしつつあるらしいので、macOS も可能な限り対応しておきたいところです。
macOS というとスマホアプリやサーバサイドのプログラマ、デザイナーさん、Logic 信者のサウンドクリエイター、スタバでドヤりたい意識高い系の方々などが使っている印象で、ゲームを遊ぶために買う というイメージがありません。
要するに、macOS 対応のゲームを出しても売れるイメージが全く沸かないのですが、最近日本の TV CM で MacBook の広告が流れているのを見たので、Apple は現在一般層取り込みに力を入れているようです。もしもそれが上手くいけば状況が変わるかもしれません。
家電を一般層へ普及させるには最終的に価格勝負になり、スマホが登場し始めた2008年頃（リーマンショックの影響で超ドル安だった頃）の MacBook ならともかく、今のドル高の情勢では相当厳しいのではないかと見ていますが、結果がどうなるかは分かりません。
シェア率の伸びとしては macOS を上回るものの、まだまだシェアが低い Linux は対応しなくて良いかな？と思いきや、SteamDeck の搭載 OS は Linux ベース（SteamOS）なので、Steam でゲームを販売するなら macOS よりも Linux に力を入れるべき だと考えられます。
ただし、SteamDeck は、ゲーム機として見ればお値段が一番安いモデル（LCD/256GB）でも 59,800 円とお高いこともあり、まだ普及しているとは言い難い状況のように見えます。
2023年4月頃に「今年中に 300 万台行くかも？」みたいな記事（参考）がありましたが、今のところ「300万台に到達した」という朗報を見たことがないので、もしかすると苦戦しているのかもしれません。（※Valveは上場企業ではなく私企業なので詳細は不明）
2023年末ごろまで世界的な半導体不足だったこともあり、仮にニーズがあっても生産が追い付かなかったのではないかとも考えられます。現状、Komodoストアで出せばすぐにsold outになるので 300 万台に向けて猛追中という状況かもしれません。
SteamDeck が普及するかどうかはさておき、営業（ゲーム販売者）サイドの視点では 金払いの良い裕福なユーザーさんが集中している可能性がある SteamDeck への対応は MUST という非常に安直な考え方もできます。（Steamには純広が無いので SteamDeck オーナーピンポイントでリーチするのが難しいですが）
まとめると、
- Windows = MUST (high priority)
- Linux = MUST (middle priority)
- macOS = SHOULD (low priority)
となります。
（技術視点）
Windows だけ対応しておけば Proton (Valve が開発している Wine クローン) でゲームが動かせます。そこで、当初はその方向性で検討していました。
しかし、実際に Windows 版を開発後、Ubuntu の Steam に Proton を入れて動作検証してみたところ、「Proton 頼みにするのは少しリスキーかも」と考え直す必要に迫られることとなりました。
これについては次章で詳述します。
Elden Ring のように何百万本も売れる大手 AAA タイトルなら Windows だけやっておけば Valve が気合（Proton）で何とかしてくれそうですが、目標 3,000 本売れれば御の字の私（インディー）のゲームでは Linux のネイティブ対応は必須だろうと考えました。Steamworksのドキュメントを読む限りLinuxネイティブ対応を推奨している空気を感じ取れたことも大きいです。いわゆる忖度ですね。
(2) OS 依存レイヤーの実装
VGS-Zero SDK for Steam では、以下のメディアレイヤー API を使って VGS-Zero エミュレータを動かしています。
- Windows: DirectX 9c (Direct3D, DirectInput, DirectSound)
- Linux & macOS: SDL2
十数年ぶりに Win32 API + DirectX でプログラムを書きました
当初、UWP + DirectX12 で作ろうかとも思ったのですが、Proton で Windows バイナリを Linux で動かすに当たり、最新のものより枯れた技術の方が安定して動くだろうと（過去に Wine を使った時の経験から）想定して DirectX 9c を選択したのですが、実際に DirectX 9c で作った Battle Marine を Ubuntu 版 Steam の Proton で動作検証してみたところ、全く動きませんでした。
具体的には Direct3D の CreateDevice が失敗していました。
なお、Ubuntu の Proton では動かないものが SteamOS の Proton で動く可能性があるかもしれません。実際、DirectX 9c で作られている Steam 版の東方風神録 が、SteamDeck で互換性チェックを行っていて、その結果は（若干の注意点があるようですが）一応動作するようです。（SteamDeck の実機を持っていないので検証できません...）
2024.02.28 追記
SteamOS での検証を試みようとしたのですが、いつの間にか SteamOS が SteamDeck 専用になっていたようで検証できませんでした。ただ、SteamOS にしたところで恐らく動かないだろうという想定です。Proton は GPU が Vulkan 前提にカスタマイズされていて、私が検証した Ubuntu の PC の GPU は Vulkan に対応していないため CreateDevice で失敗しのではないかと推測中です。（Proton のバージョン 3 で OpenGL のサポートを打ち切ったとの情報がありました）
このレベルで動作しないことは正直想定外だったので、Proton に頼る案を却下して Linux ネイティブで対応する方針へ転換しました。
VGS-Zero の開発者向けエミュレータが SDL2 で実装済みなので、それをコードベースにして開発しています。
ただし、VGS-Zero の開発者向けエミュレータでは SDL2 の Surface (ソフトレンダリング) を使っている関係でパフォーマンス面に不安があったため、Texture (ハードウェアレンダリング) でフレームバッファを用いた GPU 描画をするように修正しています。
VGS-Zero の開発者向けエミュレータでは、パフォーマンスよりも消費電力の低さを優先してSurfaceを使っています。
以下のはてなブログの記事がとても参考になりました。
ありがとうございます
結果的に SDL2 で作ったことで macOS にも修正無しで対応できるようになったので、これで良かったのかもしれません。
むしろ、DirectX 9c で作ってしまった Windows 版をどうしたものかと...
あまり古いバージョンの DirectX (Direct3D) を使っていると、嘗ての DirectDraw のように GPU がサポートしなくなるのではないか？という不安があることに加え、OS 毎に実装が異なるとメンテナンスも面倒なので、将来的には Windows も SDL2 へ移行して全 OS でコード共通化したいところです。
ちなみに任天堂 Switch でも SDL2 が使えるらしいという話を聞いたことがあるので、VGS-Zero SDK for NX も SDL2 ベースになるかもしれません。
VGS-Zero ではなくネイティブで 2D ゲームを作るのであれば SDL2 が一番シンプルで使いやすいのでオススメです。（DXライブラリでも良いかもしれません）
(3) ゲームパッド入力対応
ゲームパッドの入力対応は SteamInput のみ用いる形にしました。
ただし、入力全般を SteamInput にするとデバッグが大変になるので、キーボード入力に限り DirectInput (Windows) と SDL2 (Linux/macOS) を使っています。
SteamInput を使わないと SteamDeck 互換性審査で不利になる（Confirmed がとれない）可能性が高いかもしれません。SteamDeck 互換性審査を通すためには「操作はゲームパッドで完結できるようにする」ということと「入力 API には SteamInput を使う」ということが必要らしいです。
私見ですが、SteamDeck 互換性審査を通すか否かに関係なく SteamInput 対応をするのがオススメです。というのも、各 OS でのゲームパッド入力のネイティブ実装は基本的にかなりの魔窟なので、その辺の対応を Valve の優秀なエンジニアに丸投げできる SteamInput のシステムはとても便利です。
ゲームパッド入力のネイティブ実装で最大の魔窟は macOS 対応です。
以前の macOS は IOKit の HIDManager で標準 HID のゲームパッド入力を拾うことができたのですが、その API を Apple が閉じてしまったので、macOS では 対応しているゲームパッド数が少ない Game Controller Framework しか使えません。
Windows で例えると DirectInput が突然廃止されて XInput しか動かなくなったようなイメージですが、XInput なら 2,000 円前後のお手頃価格のゲームパッドが多くあるのでまだ良いかもしれません。（GCF対応のゲームパッドは1万円前後が相場という私では手が出せない価格設定になっているので1台しか持っていません）
なお、HIDManager は macOS の中でもかなりマニアックな機能なので、Cocoaプログラミング経験者の方でも知らない方が多いかもしれません。以前気合で調べて GitHub の方でサンプル実装を公開しています。
macOS が HIDManager を閉じてしまって以降、昔は普通のゲームパッドで動かせていた Steam の大半のゲームが MFi ゲームパッドでしか動かせなくなってしまいました...
モドシテ
私の場合、趣味だけでなく仕事でも（ゲームパッドに限らず）標準 HID の入力機能が必須なので、この仕様変更が決め手となり私のメイン PC の OS は Ubuntu になりました。
ですが、2013年の MacBook はパーフェクトなハードウェアだったので、私の現在のメイン PC は、ハードオフで4万円ぐらいで購入した 2013 年モデルの MacBook Air に Ubuntu を入れたもの です。MacBook Air (2013) はとても素晴らしいハードウェアなので万人にオススメできます。過去の Apple に感謝しながら 2013 年モデルをメインで使い続けようと思います。
もしも Apple が HIDManager を復活させた時、Valve の優秀なエンジニアがマッハで SteamInput で追従対応をしてくれる筈なので、SteamInput を使っておけば共有ライブラリを差し替えるだけで簡単に追従対応できるものと思われます。
ついでに Windows も XInput と DirectInput の両対応がほぼ必須で、XInput はかなり簡単に実装できますが DirectInput の実装はかなり面倒くさいです。
また、全 OS 共通でキーコンフィグ対応（ボタン割り当てをユーザーが変更できる機能）がかなり面倒くさいのですが、SteamInput を使っておけばキーコンフィグの自前実装が一切不要になります。
(4) クラウドセーブ対応
クラウドセーブへの対応ミスで 2 回ほどバイナリリジェクトを喰らいました
1回目は、Steamworks のクラウドセーブの設定項目で「クラウドサポートをデベロッパーにのみ有効化」というチェックを外し忘れたことでリジェクトされました。
2回目は、ルートパス設定でサブディレクトリの箇所の入力は省略できるように見えたので省略（インストールパスにセーブファイルを保存）していたのですが、どうやらサブディレクトリへのセーブファイル（save.dat）の保存が必須だったようです。そこで、サブディレクトリ「save」を作りその配下にsave.datを保持する仕様に変更したところ、正常にクラウドセーブが動くようになりバイナリ審査が通りました。
私が Steam のバイナリ審査で Failure (リジェクト) になった指摘事項はクラウドセーブ関連のみでした。
クラウドセーブはコード実装無しで対応でき、しかもかなり便利なので、セーブ機能を利用するゲームでの利用はほぼ必須だと思われますが、バイナリ審査を出す時は上記の点を注意した方が良いです。（VGS-Zero SDK for Steam ではsave.datをサブディレクトリsave以下に保存する仕様なので大丈夫かと思われますが）
他にも細かい指摘が何点かあり、修正必須ではなさそうなニュアンスだったのですが、運営の心象を良くするため全て言われた通りに修正しておきました。
(5) アチーブメント対応
私が Steam 対応で一番気合を入れたのがアチーブメント対応です。
Battle Marine はラズパイを持っていれば無料で遊べるので、有料の Steam 版には「お金（550円）を支払うだけの新たな価値」の提供が必須で、そこで目を付けたのが Steam のアチーブメント機能です。
アチーブメント対応にはゲームデザイナーとしての高度なセンスが問われるので、実装難度がかなり高いです。（コーディングは簡単にできますがデザインがとても大変です）
単純に「ステージ3に到達した」みたいな 到達目標 を設置するのは簡単ですが、そういった「誰にでも考えつくアチーブメント」は既にあらゆるゲームで実装済みなので目新しさがありません。もちろん、目新しさがなくても面白ければそれで OK なのですが、私は単なる到達目標のアチーブメントでは「弱い」（そこにお金を支払うほどの価値は無い）と考えました。
既存のアイディアを含めてアチーブメント対応の無数のアイディアを考え、その上で「それ、本当に面白いの？」と徹底的に禅問答しました。
アチーブメント対応は、Steam 対応を始めた 2 月の段階からではなく、ゲームを開発している初期段階（1月1日）からずっと「どうしよっかな」と頭の片隅で考えながらプログラムを組んでいたと思います。
そして、考えに考え抜いた結果生まれたのが「査定システム」です。
Battle Marine は 1 プレイ毎、プレイした結果に応じて階級が査定される仕様になっています。
このアイディアの基礎は ナムコ (現Bandai Namco Entertainment) の「ギャラガ」というゲームで、ギャラガではゲームオーバーになるとショットの発射回数、命中回数、ミスショット率が表示されますが、その項目数を色々と増やしてみました。
そして、各項目から「階級査定の評価」を行っています。
画面右側のプラスやマイナスの数字が査定結果で、一定ランク以下まではこの査定結果と到達ステージにより階級が決まります。また、O4（少佐）以上の高級幹部からは通常の査定とは別の足切り査定項目もあり、かなり複雑な仕様になっています。（ソースコードを公開しているので詳細はソースコード参照）
階級は E1 (二等水兵) から ?? (伝説の水兵) までの全 27 階級があり、米国の海兵隊の階級を参考にしました。
Steam の画面上では見難いのですが（）全ての階級に階級章のデザインもしています。（下図は E9 の階級章）
個人的には海兵隊よりも海上自衛隊（日本）の方が分かりやすいのですが、北米市場をターゲットに見据えて海兵隊方式にしました。（そういえば DOOM の主人公も海兵隊員ですね）
Battle Marine のゲーム本編開発で一番時間を掛けたのが「査定バランス」の調整です。
プレイした結果と査定値を都度スプレッドシートに纏めていき、その結果を見ながらバランス調整をチビチビと行う超絶面倒臭い作業を賽の河原で石を積むかの如く延々と繰り返しました。
もう何回遊んだのかは覚えていませんが、それだけ遊んでもゲームプレイへの飽きは一切無かったので、ゲーム自体の出来は恐らくかなり良いと思います。（自信過剰かもしれませんが...）
しかし、ゲームを「名作」に昇華させるには「ゲーム本編が面白い」だけでは不十分で、この査定バランス調整こそがこのゲームの運命を決定する と半ば自分を洗脳し、気の狂いそうになる記録と調整を延々と続けました。
その甲斐あって、査定バランスはかなり良くなったと思います。
私が Steam 上でガチプレイ時の各階級の獲得数が下図です。
E ランク（恐らく海上自衛隊でいうところの士相当）の層が薄く、W ランク（曹相当）が厚いという、「海上自衛隊員が苦笑いしてしまいそうな妙にリアリティのあるバランス」を意図的に狙ってみました。
なお、私は自衛隊関係者ではなく実際の内情を知らないため、YouTube のオオカミ少佐のニュースチャンネルという元海上自衛隊幹部（少佐）の方が配信されている動画を見て色々と研究しました。
O7 以降（将官クラス）のバランスも中々リアルかな？
戦場で戦うのは O6（大佐＝艦長）までで、将官が戦地でShoot 'Em Upすることは多分無いかもしれませんが、査定結果はプレイヤーの最終階級ということで...
ゲームがリアルである必要は全くないかもしれませんが、リアルにすることで階級のディティールが深まると考えながらバランス調整しました。（ゲーム本編では船がジャンプしたり潜水艦が平泳ぎをするなどリアルとは程遠いものですが）
私が Steam 版 Battle Marine のアチーブメントで実装したのは、獲得階級の 27 実績という竹を割ったようにシンプルなもの のみ です。セールスポイントを分かりやすくするため、よくある「ステージ3到達」みたいな実績は一切実装せず、アチーブメント＝階級 であることを徹底しました。ノイズとなる実績を全て排除することで、このゲームの楽しみ方 がプレイヤーに伝わりやすくなると考えています。
参考までに、私が OB（元帥）と ??（伝説の水兵）を除く 25 階級の実績解除に要した時間は約 33 時間です。
550 円で買ったゲームをここまで遊べれば大満足だと私なら判断します。（自分に甘いかもしれませんが...）
「部長に昇進したぞ!」「なんで俺じゃなくてアイツが本部長に...」「私が村長です」など、階級に関する話題に興味がある人は多いと思うので、これなら「550円を支払う価値のあるアチーブメント」にできたのではないかなと。
実は当初、最高ランクは元帥（OB）だったのですが、「上手い人なら簡単過ぎないか？」と不安になり、伝説の水兵（??）という常人では到達できない階級も設けてみました。
Steam 上のアチーブメント・データには各階級の階級章をデザインして掲載しているのですが、伝説の水兵は階級章のデザインに悩んだ末、下図のようなテキストオンリーのメッセージにしています。
日本語に訳すると、「その人物の公式な軍事記録は残されていない。しかし、それは寓話や伝記で語り継がれ全ての人々から尊敬されている。」という感じでしょうか。
公式な軍事記録が残されていないので階級章が無い仕様（手抜き）です。
私のゲームデザインの最大の弱点はストーリー性が無くて無機質なことなのですが、ゲームを名作にするにはストーリーの存在が不可欠だと思っています。
「伝説の水兵」の実装により、このゲームに「ストーリーらしきもの」が生まれたような、そうでもないような...
烏滸がましくもゲームを創る時は毎回「このゲームを名作にするぞ！」という気概で開発しています。
そして、リリース後はその全てを忘れるように努力しています。
今回のBattle Marineもこれまで無数に創ってきたゲームと同様、記録に残らずただ忘れ去られるだけの存在になるか、はたまた伝説（名作）になれるのか。
そんな感じのストーリー
これが私のゲームデザイナーとしての限界です
(6) ローカライズ対応
私のローカライズ戦略は基本的に「どんな言語の人でも楽しめるシンプルなゲーム」にすること（ローカライズ・フリー）です。
そのため、ゲームバイナリは伝統的に英語のみとしています。
ただし、日本語の形状は結構カッコイイと思っているので、一部シンボリック的な部分（階級名）で日本語表記をしている箇所もありますが、その他のテキストは全て英語のみにしています。
ですが、日本語しか読めない方（何なら文字が読めない子ども）でも楽しんでいただけるように設計したつもりです。
私がスマホ向けに開発した最初のゲーム（Invader Block）を、当時勤めていた横浜の小さな会社の取引先の課長さんに見せた時、その課長さんはあまり興味が無さそうだったのですが後日、「息子にプレイさせたら延々と遊んでいて困る！」という有難い苦情を頂きました。
それがとても嬉しくて個人でのゲーム開発（当時はスマホ）を再開した経緯があるので、「子どもが楽しめるゲームデザイン」にすることを最重要視しています。知育アプリとはちょっと違ってバイオレンス多めかもしれませんが。
結果的にそのゲームデザインはローカライズ・フリーということになるため、実際私が過去に販売していたスマホアプリ（有料販売）の売り上げは8割強が海外からのものでした。（当時は円高であまり儲かりませんでしたが）
とある大手ゲーム会社さんのIR資料によると、家庭用ゲームの1タイトルあたりの販売実績は、
- 日本: 約13万本以下/タイトル
- 米国: 約32万本以下/タイトル
- 欧州: 約34万本以下/タイトル
とのことです。
欧州は地域によって言語が色々あるのでローカライズ難度が高めです。
米国ならほぼ英語のみなので、メイン言語の対応コストパフォーマンスは英語が一番良く、次点で日本語だと考えられます。
そのため、ローカライズのターゲットを絞るなら日本 or 米国の二択にするのが良いというのが私見です。（余力があればスペイン語、フランス語、ドイツ語あたり）
また、日本語などのアジア言語は複雑なキャラクタデータになっていて母語者以外の認知難度が高めです。そのため、シンプルなキャラクタデータ（アルファベット）のみで構成された英語の方がワールドワイドでのセールスを伸ばせる確率が上がるかもしれません。
日本でも義務教育で英語を習うので、簡単な単語なら読める人が結構多く居ます。
RPG などのローカライズ依存が強いゲームだとワールドワイドで売るのは少し難しいかもしれませんが...（次回作は RPG を予定しているのでさてどうしたものか）
(7) ゲーム実況配信への対応
ニコニコ生放送やYouTubeなどの動画配信サイトでのゲーム実況配信が、ゲームの認知獲得（プロモーション）活動において最も重要なメディアだと私は考えています。
とはいえ、ゲーム実況に適したゲームデザインというのは中々難しいです。
実際に配信しなくても良いので、デバッグ時に開発中のゲームの実況配信をしてみると良いかも？と考えて生主の真似事などもしてみたのですが、如何せん私自身がゲーム実況の経験が無いため Battle Marine がゲーム実況配信に適しているか正直よく分かりませんでした...
そもそも喋りながらゲームをプレイするのが物凄く難しい
ゲーム自体がゲーム実況配信に適しているか否かに関係なく、対応しておいた方が良い事ならあります。
私の前職が動画配信サイトを運営する会社（某D社）だったので、仕事でゲーム実況配信をされている方々と接する機会が何度かあったのですが、彼らは基本的にリテラシーが高いという印象です。
具体的には、題材として扱うゲームの説明文などのテキストを隅々まで読み、「どうやったら楽しく実況配信できるか」をプレイしながら入念に調べ、その上で配信に臨んでいるようなイメージです。（もちろん、完全に行き当たりばったりで配信してそれが面白くなる天才肌の方も居るかもしれませんが）
そこで、ゲームのストア掲載テキストで以下のような文言を書き、手軽に実況配信できる旨を明文化しておきました。
動画配信など
本ゲームのテレビやYouTubeなどの動画配信サイトでの配信には一切の制限がありません。
もちろん、収益化の実施についても一切の制限がありません。
作者への事前・事後の連絡も不要です。
雑誌、WEBメディア、SNSなどへのスクリーンショット掲載などについても同様に一切の制限がありません。
些細な事かもしれませんが、メディア露出のチャンスを得るためにはこれが結構重要なことだと思います。
最近は大手が販売しているゲームでも実況に関する許諾をしているものが多くありますが、規約を細かく読んでみると対象を個人に絞っているものが多く、「法人の場合は監修必須」というケースが多いです。
幅広い二次創作を許諾している東方Projectでも、二次創作の許諾対象は飽くまでも「個人」としています。（参考）
もちろん、個人には自由に許諾をし、法人には制限を課するのは各社それなりの事情があってのことだと思います。
しかし、私のゲームは「見ていると自分でもプレイしたくなるもの」にしたつもりなので、露出機会が得られるなら個人か法人かを問うべき理由はありません。そこで、対象が個人 or 法人、または営利 or 非営利に関係なく自由な許諾をすることで「露出機会の損失を減らす形」にしてみました。
Battle Marine を使った e スポーツ大会の開催やスクリーンキャプチャを使った T シャツなどの関連グッズの販売などにも私は一切関知しないのでご自由にどうぞ。（もちろん、私の名義を使うなどして私が一定の責任を負う可能性があるケースでは事前にご相談いただきたいですが、基本的に一切の責任を取らない方針です）
ゲーム実況に限らず、Web メディアなどでもゲーム関連の記事を取り扱う時、ゲームの権利会社への許諾依頼と記事監修などを行うのが普通かと思われますが、記者の編集権のみで自由に記事化できた方が面白いコンテンツ（記事）が生まれやすくなる筈...というのが私の基本的な考え方です。
実際にゲーム実況者さんや記者さんのお眼鏡に適うのかは運ゲーですが。
余談ですが、以前 Qiita に書いた VGS-Zero の紹介記事を Gigazine さんに取り上げていただけました。
Gigazineさんとは一切やりとりしていないので記事化の経緯などは不明ですが、権利方面のことをうるさくしないニュアンスを漂わせておくことがメディア露出をする上で結構重要なことなのかもしれません。
(8) CM （YouTube動画広告）準備
予算が無いのでメインターゲットの北米と英国限定ですが、YouTube の動画広告を作ってみました。
今回はタイトル画面の音楽が結構良い感じにできたので、タイトル画面の音楽を1ループ（約1分）する長さの広告にしています。
YouTubeの動画広告の場合、最初の15秒間が肝要なので、このゲームの一番面白いポイントだと思っている「撃ちまくる楽しさ」を15秒以内で無理やり詰め込んでみました。
そして、サビに向かうところの盛り上がり部分でゲームのメインキャッチ「Enjoy a Retro but New and exhilarating STG experience!」をサラリと表示しつつ、サビと同時に最大限にカッコ良いトランジションで「Now on Sale!」...というのが絵コンテです。
プロモーションは実況配信（他人任せ）にしたいところですが、初期の認知獲得にはどうしても広告出稿（資本投下）が必要だと思っています。
ある程度儲かったら、初期の頃に記事を書いてくれた Gigazine さんの純広告出稿なども検討することも吝かではないですが、ゲーム実況配信をされている方にリーチするならYouTubeの動画広告が一番確実かなと。（お値段もお手頃ですし）
一番重要な時期はゲームをリリースしてから約1カ月間（ストア露出が多い時期）なので、期間はリリースしてから2週間程度の短期間でもそれなりに効果があるだろうと思われます。初期2週間でなるべくストア露出によるオーガニック流入を高める作戦です。
動画広告の審査に結構時間が掛かることもあるので、リリース1週間前には広告クリエイティブの準備を完了させて広告審査に提出するのが良いと思われます。
広告クリエイティブはストアに掲載する予告動画と一緒にまとめて撮影しておきました。（予告動画は広告クリエイティブとは別に2本撮影）
(9) ストア審査
ストア審査でも 2 回ほどリジェクトを喰らいました。
バイナリ審査よりもストア審査の方が大変だった印象です。（ストアアセットの準備もかなり大変ですし）
ちなみに Steam でゲームをリリースするには次の 2 つの条件があります。
- AppID を購入（1タイトルあたり￥15,000）してアプリ登録してから 30 日以上経過
- ストア審査を通して「近日登場」にしてから 2 週間以上経過
当初、これらは AND 条件かと思っていたのですが、どうやら OR 条件だったようです。
つまり、ストア審査を通して 2 週間後が最短のリリースタイミング かもしれません。
なるべく早くゲームをリリースしたい場合、可能な限り早くストア審査を通すことをオススメします。
(10) ランディングページ準備
広告のクリック URL は Steam のストアページで良いかもしれませんが、ストアページだと広告のクリック分析が若干面倒なので、自前のランディングページを準備しました。
このページの CDN は Firebase Hosting です。
Firebase Hosting なら (10GB を超えない限り) 無料で使うことができ、Firebase Analytics と連動してトラフィック集計ができます。
10GB を超えることは無い想定ですが、万が一超えそうになったら広告のクリック遷移先を Steam のストアページのみにするか Blaze プラン（従量課金）に切り替える予定です。
従量課金が必要な程度のトラフィックが発生すれば売り上げが確実に上がるので、サーバコストは問題なく支払えるかと思われます。
まとめ
私が個人で出来る限りのことは全てやってみたつもりです。
人事は尽くしたので、あとは天命を待つだけです。
ゲームが売れるか否かを決めるのは運の要素が結構強いので、人事を尽くさなくても売れることもあれば、人事を尽くしても全く売れないこともあります。
人事を尽くした上で売れなかったら「今回のゲームもつまらなかったか～」と諦めることができ、全てを忘れて心置きなく次回作の開発にシフトすることができます。
若いころなら暫くバーンアウトすることも無くはなかったのですが、数多の失敗プロジェクトを経験してきたことでその辺のメンタリティは養われている方だと思います。（自慢できることではないかもしれませんが）
人事を尽くした失敗は人のメンタルを強くします。
私はそろそろメンタルが強くなり過ぎてきた感がありますが、それでも「どんどん失敗しようぜ
」という気概でこれからもゲームを創っていきたいものです。