私たちが作った全てのゲームを支え続けたバックエンド、10年以上の軌跡

10年間、そしてこれからも、我々が作った全てのゲームを支えてきたバックエンド

Writing · 2026年9月22日 · by Mike Hergaarden

2016年以降、我々が作った全てのゲームは、私が自身で書いたバックエンド上で動作しています。その仕組みと、今年C#に移行した理由について説明します。

過去10年間に我々が作った全てのゲームは、同じバックエンドと通信しています。Marooners、Verdun、Tannenberg、Isonzo、Crash Drive 2、Crash Drive 3、そして今年からは別のスタジオのゲームも含まれます。SteamからSwitch、WebGLまで11のプラットフォームが、すべてPHPで構築されFirestoreを基盤とする一つのGoogle App Engineプロジェクトにデータを送信しています。

私はこれをGDT、すなわちGame Development Toolkitと名付けました。汎用的な名前ですが、そのツールも汎用的です。バックエンド、管理画面、小さなプレイヤーポータル、Unityパッケージ、そして出荷するゲームごとに新しいジョブが発生します。PHP版はプレイヤーが気づくような障害なしに10年間稼働しました。今月、C#版に置き換えられたため、この記事ではPHP時代の話と、新しいバージョンのスクリーンショットを紹介します。

これらのゲームすべてを合わせたホスティング費用は、プレイヤー数に応じて月額10ユーロから50ユーロでした。ほとんどのプレイヤーは無料のモバイルゲームをプレイしており、有料ゲームではプレイヤーあたりのコストは誤差の範囲です。私は一人でこれを構築し、メンテナンスはほとんど必要ありませんでした。Googleは古いPHPランタイムを維持し、新しいランタイムへの数回の移行も何も壊さず、ただ動作し続けました。シンプルさを保つこと、PHPを含めて、それが報われました。

これはまた、私たちの仕事の中で誰も見ることのない部分でもあります。プレイヤーはゲームを見、レビューアはゲームを見ますが、すべてのローンチとすべてのポートを可能にしたものは、管理ログインの背後にあります。長年、これを紹介したいと思っていました。それでは、ご覧ください。

［画像: Crash Drive 3のダッシュボード：1日あたりの新規プレイヤー数、プラットフォーム別・ビルド別の直近300人のプレイヤー、時間あたりのアクティブプレイヤー数］

Crash Drive 3のダッシュボードは、ローンチから4年後のものです。サインインした直近300人のプレイヤーのうち、10人中4人がAndroid、4分の1がiPhone、4分の1がSwitchでした。この混在が、私たちがどこでもリリースする理由です。SteamやSwitchで購入したプレイヤーは、常に誰かと一緒にプレイできます。

始まり

それ以前は、ゲームごとに小さなPHPスクリプトをたくさん書いていました。ゲームがオンラインで何かを必要とするたびに、メインメニューのライブニュース、カウンター、バージョンチェック、ちょっとしたイベントなどです。それらは見栄えが悪く、毎回ゼロから書き直していました。

それを変えたのは、Maroonersのコンソールリリースでした。6人の友人で作ったパーティーゲームをPlayStation 4、Xbox One、PCに展開することになり、私はポートチームでした。ゲームが私たちの手から離れると、内部で何が起こっているのか全く分かりませんでした。PCでは、何か問題があればSteamフォーラムに投稿がありますが、コンソールでは沈黙が続き、後に認証失敗となります。

最初の試みは、Redisバックエンドを持つPiwikでした。データベースがボトルネックになることは分かっており、Redisは非常に高速なので、フリーランサーにセットアップを依頼しました。Redisの仕組みを全く知らなかったからです。しかし、うまく動作しませんでした。複雑さは予期せぬものを持ち込み、問題が発生するたびに、出荷するのではなく、他人のアーキテクチャを読むことになっていました。それがツールにおいて私が我慢できないことです。朝に機能を構築し、午後に公開したい。その邪魔になるものはすべて排除しなければなりません。そこで、それを捨て、App EngineとFirestore上で、スキーマもフレームワークもなしで、PHPで自分で構築しました。その再構築のために、オランダのR&D税額控除であるWBSOを申請しました。資金は少額でしたが、真剣なプロジェクトとして扱うことで、そのように扱えるようになりました。

かなりの部分がクリスマス休暇中に構築されました。Maroonersですでに動作していたため、休暇明けにVerdunに組み込むのに数週間ではなく数日しかかからず、WW1チームの誰かが私が休暇中に働き続けたのかと尋ねました。

そこから、ゲームごとに成長していきました。WW1ゲームは、Jos、Matt、私が設立した会社であるWW1 Game Seriesによって作られ、チームは長年で25人に成長しました。Crash Drive 2は再び私一人で、MattがテストとUIを担当しました。Crash Drive 3は私たち4人でした。各リリースで機能やプラットフォームが追加され、各機能は古いゲームが動作し続けるように構築されました。APIルートは依然としてapi_v1と呼ばれています。後継ゲームは、下位互換性が不可能になった日にapi_v2で開始される予定でした。しかし、その日は来ませんでした。

バックエンドの機能

人々は「アナリティクスバックエンド」と聞くと、右肩上がりのグラフが表示されるダッシュボードを想像します。しかし、それは2人から25人のチームにとって、それ以上のことを行います。

• 🐛 クラッシュとエラーレポート。 例外、クラッシュダンプ、スクリーンショットとログファイル付きのバグレポートを、そのゲームのダッシュボードに表示します。
• 🔐 クラウド認証。 Steamチケット、Epicトークン、Windows Store、PSN。単一のエンドポイント、プラットフォームごとに1つのユーザーレコード。BANはゲームごと、またはすべてのゲームを一度に行えます。BANされたSteamプレイヤーは、SteamプロフィールにもゲームBANが適用され、Steamをそのように支援するのは満足感があります。
• 🎛️ リモート設定。 クライアントが1日キャッシュする、ゲームごとの型指定された設定。アナリティクスを切り替えたり、最小バージョンを設定したり、キャッシュブースト週末をスケジュールしたり、パッチなしでバランス数値を変更したりできます。

［画像: Crash Drive 3のリモート設定：広告タイミング、アルファスイッチ、日付付きのキャッシュブーストイベント］

• 📈 オンライン統計。 改ざんされたクライアントが履歴を書き換えることができない、増加し続けるグローバルカウンター。Crash Drive 3のプレイヤーは1億4900万キロメートルを運転し、そのうち3500万キロメートルをドリフトし、3800万個の樽を崖から突き落としました。
• 🧾 SteamとEpicのDLCと所有権チェック。 ゲームがクライアントを信頼する必要がないようにします。
• 👥 プラットフォーム間のフレンド、招待、セッション。 PhotonのWebhookを介して行われます。
• 🗳️ プレスやテスター向けのプラットフォームごとの投票、バウチャー、キーセット、 およびクリック数と、ゲームがフィードバックするため実際のコンバージョン数を追跡するリンクトラッカー。これにより、DiscordのリンクがTwitterの同じリンクよりも約10倍コンバージョン率が高いことを学びました。
• 🏗️ ビルド。 Jenkinsがダッシュボードに接続されています。ボタン一つでビルドが開始され、結果は自動的にSteamの最新ブランチに配置され、別のボタンで公開されます。ビルドログには各ステップのタイミングが記録されており、ビルドが遅くなった原因を見つけ、その後も監視し続けました。
• ⏱️ ベンチマーク。 ゲームはシーンまたはシナリオを実行し、数値を投稿します。それらはビルド間で比較可能なダッシュボードに表示されます。
• 💬 Discord。 新しいレビュー、キュレーターの言及、セールス目標、クラッシュの急増、チーター、新しいビルド、コミット。すべてのSteamレビューは、レビューアのプレイ時間とスコアにカウントされるかどうかを示すメッセージとともにチャンネルに届きます。Crash Drive 2に210時間費やしたプレイヤーが「このゲームを本当にやりたい！」と書いたメッセージを、チーム全員が1時間以内に見ました。否定的なレビューも同様に扱われるため、ほぼ即座に対応できます。

［画像: Discordに届くSteamレビュー：プレイ時間とスコアへのカウント有無を示すメッセージが1件ずつ］

• 🧪 クローズドテスト。 WW1ゲームとCrash Drive 3で、以前のゲームを所有しているプレイヤーを招待して次のゲームをテストしてもらいました。プレイヤーポータルでサインインすると、バックエンドがSteamで所有権と十分なプレイ時間を確認し、NDAのためにHelloSignに誘導し、署名済みであることを確認し、Discordをリンクしてテスターロールを付与し、Steamキーを配布します。スプレッドシートなしで数百人のテスターを管理しました。

［画像: コミット履歴ページ：Steamブランチごとの変更ログ付きSVNコミット］

［画像: コミットフック経由でDiscordに届く同じコミット：変更されたパスを含む］

• 📜 コミット履歴ページ。 最初はSVN、後にGit。ポストコミットフックから供給され、Favro、Trello、UserEchoも統合されています。バックエンドはすでにすべてを知っていたため、それらを他の場所に置くよりも安価でした。

これらすべてで、約20,000行のPHPが使用されており、その構成は以下のようになっています。

［画像: アーキテクチャ：Unityクライアント、URLでルーティングされる単一のApp Engineプロジェクト、FirestoreとCloud Storage、プラットフォームAPIとDiscord］

重要だった決定事項

件数ではなく、レートでアラートを出す

システム全体で最も役立つルール：クラッシュアラートは例外の数を見ません。アクティブユーザーあたりの例外数がしきい値（現在は0.05）を超えた場合、またはセッションあたりのエラー数が1.5を超えた場合にトリガーされます。ローンチ日には、何かがトリガーされる前に数千人のプレイヤーがいても、何も起こりません。2年後、数百人がオンラインの場合でも、同じルールが1時間以内に壊れたパッチを検出します。何年もチューニングし直す必要はありませんでした。

これが繰り返し私たちに与えてくれたのは、不可解なバグに対するスピードです。特定のプラットフォーム、特定のビルド、ごく少数のプレイヤーにのみ発生するクラッシュが、1時間以内にスクリーンショットとログファイルとともにログページに表示されます。それを修正し、ビルドを押し、ビルドがSteamの最新ブランチに配置され、もう一度押して公開すると、アラートは静かになります。

［画像: ビルドページ：ビルドIDとデポサイズを持つSteamブランチ、およびステップごとのタイミングが表示されたビルドPCログ］

ゲームに合わせてスケールするセールス目標

オーナー数が100未満の場合は、バックエンドは10件のセールスごとにDiscordに通知します。1,000未満の場合は100件ごと。100,000未満の場合は5,000件ごと。それ以降は100,000件ごとです。ローンチ日には、チーム全体が最初の100件のセールスが1件ずつ入ってくるのを見守り、1年後には誰もスパムを受け取ることはありません。メッセージはMilestone penguinと呼ぶボットから送信され、ペンギンは今も訪れています。Crash Drive 2は2026年3月に295万ユニークプレイヤーを突破しました。これはバックエンドが登場してからのプレイヤー数のみです。それ以前は、Webで1億回以上、Androidで1000万回以上ダウンロードされていましたが、その頃はストアダッシュボードと推測しかありませんでした。この小さな機能が士気にこれほど貢献するとは予想していませんでした。

［画像: Milestone penguinからの2回の訪問。2回目はCrash Drive 2の295万ユニークユーザー達成時］

イベントではなく、バケット

設計全体がデータベースを中心に展開しています。開始時はDatastore、後にFirestoreと呼ばれましたが、どちらにしてもMySQLではありません。JOINはなく、クエリは制限され、読み書きごとに料金が発生します。すべてのイベントを個別の行として保存すると、その方法では重すぎます。プレイヤーが数千人いるゲームでは、1日に数百万行が書き込まれ、1つのチャートのためにそれらを読み戻すコストはホスティング費用を超えてしまいます。そのため、アナリティクスはクライアントでバッチ処理され、サーバーで集計されて時間ごとおよび日ごとのバケット（カウントする項目ごとに1行）になり、移動平均が計算されます。1日あたりのプレイヤーが数千人いるゲームのダッシュボードは、数百回のFirestore読み込みで、1時間ごとにキャッシュされます。

時折、実際のクエリ言語が恋しくなることもありました。しかし、バケットを事前に計画しておけば、ほとんど必要なく、そのトレードオフがApp Engineを小さなインスタンス1つで稼働させ、請求額をプレイヤー数に連動させています。

ログを汚染したクラックされたビルド

ある時点で、クラックされたCrash Drive 3のビルドが数千件の例外を送信し始めました。攻撃ではなく、単に壊れたクラックが世界中のマシンでクラッシュしていたのです。修正は1行の設定でした。バージョン5000未満のPCビルドからの例外を無視する。オンラインプレイはこれらのビルドでは決して利用できなかったため、クラウド認証はすでにそれらを拒否していました。海賊版をデータ品質の問題として計画していませんでしたが、リモート設定を使えば5分で済みました。同じバージョンとビルドチェックは、改造された実行ファイル、トレーナー、チートビルドを実行しているプレイヤーを特定し、BANするための安価な方法であることが判明しました。

ジョブごとに3つのクロン

すべてのスケジュールされたジョブは3回登録されます。00分、01分、02分に登録され、各実行は、その分を3で割った余りがゲームのインデックスと一致するゲームを処理します。すべてのゲームを順番に処理する1つのクロンは、タイムアウトと毎時の負荷スパイクに遭遇するでしょう。3つの小さなクロンは快適に完了し、インスタンス数を一定に保ちます。設定ファイルではコピー＆ペーストの間違いのように見えますが、私の好みの解決策です。モジュロ演算1つで、維持すべきキューやスケジューラはありません。

壊れたJSONを修復するための5つの試み

クライアントはゴミを送信します。スタックトレースからの制御文字、デバイス名からの無効なUTF-8、Windowsファイルパスからのバックスラッシュ、リクエストボディを書き換えるペアレンタルフィルター、そして接続が傍受または完全にブロックされる国（イランが最も記憶に残っています）。アナリティクスエンドポイントは、5段階の攻撃的な修復を試みてから諦めます。各成功した修復は、どの修復が行われたかを示すメモを私のデバッグチャンネルに投稿します。これにより、プレイヤーのマシンに触れることなく本番環境をデバッグできます。

コンテキストでBANされたチーター

クラウド認証呼び出しは、ゲームデータの一部も送信します：プレイ時間、通貨、アンロックされたアイテム、購入履歴。サーバーはそれらを物理的に可能なことと比較します。1時間未満のプレイ時間で全車アンロック、または購入履歴なしで1000万ゲーム内通貨は即時BANです。ルールはバックエンドにあるため、新しいチートが出現したその日の午後にルールを強化できます。

BANは1つのゲームまたはすべてのゲームに対して行うことができ、ブロックされたデバイスは、我々が作るすべてのゲームでブロックされたままです。グローバルBANリストには現在130,000件以上のエントリがあり、Crash Drive 3だけでも約10,000件です。チーターに対しては、私が構築できたどんな検出スキームよりも、迅速な対応が重要でした。サーバーは、すべてのクライアントが嘘をつく可能性があると仮定します。すべてを自分でチェックし、カウンターは増加し続けます。

Unityプラットフォームレイヤー：11モジュール、11プラットフォーム

バックエンドは私が始めた理由です。プラットフォームレイヤーは、このすべてが報われた理由です。

すべてのプラットフォームSDKは、異なる形式で同じことを求めてきます：ユーザーにサインインさせる、実績をアンロックする、セーブを書き込む、プレゼンスを表示する、フレンドのセッションに参加する。ツールキットのUnity側は、それぞれに対して1つの抽象モジュールを定義し、プラットフォームごとに1つの実装を用意しています。

［画像: 11モジュールと11プラットフォームのマトリックス］

ゲーム側からは、このようになります。Crash Drive 3の出荷時のコードから抜粋した4行です。

// どのプラットフォームでビルドが実行されても、実績をアンロックする
AchievementsModule.SP.SubmitAchievementStatus(SystemModule.SP.PrimaryPlayer, "FirstStunt", 100, null);

// コミュニティ合計のために何かをカウントする
M2HGDT.AddQueuedOnlineStat("pushedCacti", 1);

// パッチなしで変更できる値を取得する
int secondsBetweenAds = OnlineSettings.GetInt("MinTimeBetweenAds", 240);

// プレイヤーが現在何をしているかをプラットフォームに伝える
PresenceModule.SP.SetPresence(SystemModule.SP.PrimaryPlayer, PresenceDataCD3.GetData(scene, eventType));

最初の行は、ビルドに応じてSteam、Epic、Xbox、Game Center、またはPlay Gamesの実績、あるいはPlayStationのトロフィーになります。キューに入れられ、リトライされ、より低い進行度で再送信されることはありません。2番目の行は、クライアントが報告する他のすべてと一緒にバッチ処理され、増加のみのカウンターとして記録されます。これが3800万個の樽の由来です。3番目の行は、クライアントがその日に更新した設定ファイルからの型指定されたルックアップで、オンラインになったことのないクライアントにはデフォルト値が使用されます。4番目の行は、Steam、Epic、Xbox、PlayStationの豊富なプレゼンスを更新し、それがない場所では何も行いません。ゲームコードはすべてのプラットフォームで同じです。

ゲームは、ツールキットが答えられない質問に答える単一の抽象クラスを実装します：メインメニューにいるか、このポップアップを表示するか、プレイヤーがレベルをロードしているか、このセッションに参加するか。これにより、ツールキットはコンソールエンゲージメント画面、コントローラーからユーザーへのマッピング、サスペンドとレジューム、クロスプレイ招待、PSNアクティビティなどを独自に処理します。

これによりコンソールが簡単になったわけではありません。認証は依然として認証です。しかし、各プラットフォームを一度だけ理解すればよいということを保証しました。MaroonersのPlayStation 4、Xbox One、PCへのポートは私一人で行いました。最初のSwitchポートと最初のXbox Seriesポートでは、外部企業を一度ずつ、主に時間を節約するために依頼しました。それ以降のすべてのゲームのすべてのポートは、私たち自身で行いました。Crash Drive 3が1日で12プラットフォームでリリースされたとき、プラットフォーム作業のほとんどは、以前のゲームによってすでに費用が賄われていました。

シンプルさを保った理由

PHPにはビルドステップがありません。Firestoreにはスキーマがありません。App Engineは、忙しくなるとインスタンスを追加し、そうでないときは削除します。単一のエントリポイントがURLごとにすべてのリクエストをルーティングし、ゲームごとの設定がデフォルトをオーバーライドします。それが全体のアーキテクチャです。

同規模のスタジオが、キュー、コンテナ、関心事ごとのサービスを備えた教科書的なクラウドアーキテクチャを採用し、その後、出荷するのではなくそれを維持することに時間を費やすのを見てきました。あるオランダのUnity開発者が、大手クラウドベンダーのアドバイスを受けて構築したマルチプレイヤーバックエンドについて話していました。それはあらゆるものにスケールするように設計されていました。また、プレイヤーがゼロでも月額最低1000ユーロかかり、数千人がオンラインの私たちのコストの20倍でした。

追加するすべての抽象化は、ローンチがうまくいかない午前3時に理解する必要があるものであり、誰もプレイしていなくても毎月支払うものです。私は午後にシステム全体を読めるようになりたかったし、今でもそうです。機能の追加は新しいファイルと新しいelse ifでした。ゲームの追加は設定ファイルでした。プラットフォームの追加はモジュールのフォルダでした。移行が必要になったことは一度もありませんでした。

疑念と、それがどう経過したか

自分でこれを構築したのは間違いだったのではないかと思った瞬間がありました。Unityはリモート設定を発表しました。他の企業は、当時私のものよりも見栄えの良いダッシュボードを持つホスト型のアナリティクスおよび設定製品をローンチしました。切り替えは簡単だったでしょうし、私は単に頑固だったのかもしれないと考えたことを覚えています。

その後、それらの製品は廃止されたり、価格が変更されたり、統合の書き換えが必要になるような方法で再構築されたりしました。私のバックエンドは、私以外誰も変更できなかったため、決して変わることはありませんでした。年に1、2本のゲームをリリースし、それぞれを長年サポートする小規模スタジオにとって、その安定性はホスト型製品が提供できたどんな機能よりも価値があります。

やり直したこと、そしてやったこと

思ったよりも少なく、この記事を執筆している間にほとんどをやり直しました。その教訓は過去数週間でC#バージョンに直接反映されたため、ツールキットは、その記事の執筆と同時に、長年で最大のアップグレードを受けました。

• PHPの代わりにC#、App Engineの代わりにCloud Run。 完了：現在、すべてのゲームがそれに実行されています。両端で1つの言語を使用できることが真の利点です。リクエストコードはUnityクライアントが共有するプロジェクトに配置されるため、フィールド名の誤りは本番環境での空の値ではなく、コンパイルエラーになります。PHPはその数年間正しい選択でしたが、この移行はPHPの性能不足ではなく、言語統一のためです。
• より粗い機能のクリーンアップ。 投票、バウチャー、リンクトラッカーは、1つのゲームのニーズのために構築され、一般化されることはありませんでした。それらは改善されました。
• コアでのPhotonの削減。 新しいUnityパッケージにはPhotonの参照がありません。ダッシュボードでping統計を必要とするゲームは、小さなアダプターを提供します。

維持したもの：バケット、スキーマレスストア、冗長なクロン、アクティブユーザーあたりのアラート、そしてプレイヤー数に連動する請求額。これらが長持ちした理由です。

2026年：C#バージョン

書き換えは過去2ヶ月かかりました。Cloud Run上の1つのC#サーバーが、同じFirestoreデータに対して動作します。Cloud RunはApp Engineのようにゼロにスケールするため、請求額は同じように推移します。URLとJSONはそのまま維持されました。なぜなら、2021年のSwitchビルドがアップデートされる可能性は低く、違いに気づくべきではないからです。比較ツールは、読み取り専用のすべての応答をPHPと比較し、リプレイツールはスイッチ前にゲームのライブトラフィックをテストゲームに対して再生しました。新しいゲームには、その隣に署名付きAPIと、サーバーとリクエストコードを共有するUnityパッケージが提供されるため、フィールド名の誤りはコンパイルエラーになります。

パッケージは古いものと同じように読み取ります：GDTOnlineSettings.GetInt("MinTimeBetweenAds", 240), GDTFeatureFlags.IsOn("newGarage"), GDTAnalytics.TrackEvent("Gameplay", "MatchEnd", map, seconds)。コンソールは、ストレージとブラウザを1つの小さなインターフェースから接続するため、パッケージはコンソールSDKを参照せず、公開リポジトリに配置できます。

管理画面は、時期が来ていた再設計を受け、長年欲しかった機能が追加されました：履歴付き設定とプラットフォームごとの値、ビルド範囲と言語；プレイヤーの割合にロールアウトされるフィーチャーフラグ；カレンダー上のライブイベント；修正ビルドと自動回帰マーク付きでグループ化されたバグレポート；ゲームを横断するプレイヤーごとの単一プロファイル、復元用のクラウドセーブとプライバシー要求のためのエクスポート・削除機能；プラットフォームごとのグループを持つリーダーボード；AppleとGoogleでチェックされた購入；回答したい質問に対するUnityコールを記述するアナリティクスウィザード；そして、ホスト型製品が一度提供して廃止したヒートマップ。セルごとの位置は送信前に合計され、サーバーでは1日ごとに合計されるため、コストは一定に保たれます。

［画像: アナリティクス：保存されたビュー、推測の代わりに選択できるピッカー、マップごとの線］

［画像: アナリティクスページのウィザード：目標を選択し、ゲームで使用する名前を入力し、コールをコピーする］

［画像: テストゲームのヒートマップ：トラックと、クラッシュが積み重なるヘアピン］

［画像: ダークモードの同じ管理画面］

これらのスクリーンショットは、架空の数値を持つテストゲームを示しています。

10年後

このシステムを誇りに思っています。私たちが実施したすべてのローンチでその実力を証明し、今でも私以外の人が日常的に使用しています。WW1ゲームを制作しているBlackMill Gamesは、今でもVerdun、Tannenberg、Isonzoをこれで実行しており、今年新しいゲームを構築した際も、置き換えるのではなく、これを維持しました。所有権の変更を乗り越えるバックエンドは、何か正しいことをしているのです。

現在、私たちが作ったすべてのゲームはC#バージョンで動作しており、次のゲームも初日から動作するでしょう。

もう一つ、私が話すすべての小規模Unityスタジオが同じプラットフォーム問題をゼロから解決しているのを見てきたので、C#バージョンは別のスタジオのGoogle Cloudプロジェクトで、彼らの請求書で、彼らのアカウントで、彼らのプレイヤーデータと共に実行できます。それが便利そうであれば、その様子はこちらをご覧ください。

［画像: Mike Hergaarden］

この記事を書いた人

私はM2Hの創設者、Mike Hergaardenです。2004年からマルチプレイヤーゲームを構築しており、Exit Gamesと協力してPhoton Unity Networkingを共同作成し、M2Hチームと共にCrash Drive 3を12プラットフォームにリリースし、誰もが同じ世界でプレイできるようにしました。技術的な側面は、私が最も好きな仕事の部分です。

ストーリー全体 → ゲーム一覧 → LinkedIn →

その他の記事

• Shipping to twelve platforms on one day 2026年9月
• Optimizing performance of Unity games 2021年7月
• The server side of game development 2012年1月

次の記事をメールで受け取る

これはライティングリストです。年に数回、書く価値のあるものがあるときに、このような記事をお届けします。ゲームニュースは別のリストです。スケジュールはなく、詰め込みもなく、ワンクリックで解除できます。

受信トレイがない？ LinkedInでフォローするか、RSSフィードをリーダーに入れてください。または、M2H Discordで話し合いましょう。