HN 日本語サマリー

← 一覧へ戻る
Web開発

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

The backend that ran every game we made, ten years and counting (m2h.nl)

5 pointsby MikeHer0 コメント

要約

著者は、過去10年間に開発した全てのゲームで使用してきた、自社構築のバックエンドシステム「GDT(Game Development Toolkit)」について解説しています。PHPで構築され、Google App EngineとFirestoreを基盤とするこのシステムは、クラッシュレポート、リモート設定、クラウド認証、コンソールポートなど多岐にわたる機能を提供し、月額10〜50ユーロという低コストで、10年間ダウンタイムなく稼働しました。最近、C#版に移行しましたが、そのシンプルさと堅牢性がゲーム開発を支え続けた秘訣です。

全文翻訳

Writing · 2026年9月22日 · by Mike Hergaarden 私たちが作った全てのゲームを支え続けたバックエンド、10年以上の軌跡 7つのゲーム、11のプラットフォーム、クラッシュレポート、リモート設定、クラウド認証、コンソールポートのための1つの自社製バックエンド。開発者1人、10年、そして今はC#で。 過去10年間に私が取り組んだ全てのゲームは、同じバックエンドと通信しています。Marooners、Verdun、Tannenberg、Isonzo、Crash Drive 2、Crash Drive 3、そして今年からは、他のスタジオがこのバックエンドを基盤に構築した7番目のゲームです。Steam、Epic、Windows Store、PlayStation 4および5、Xbox OneおよびSeries、Switch、iOS、Android、WebGL。これら全てが、PHPで構築された1つのGoogle App Engineプロジェクトにレポートし、Firestoreによってバックアップされています。私はこれをGDT、Game Development Toolkitの略と名付けました。名前は一般的ですが、ツール自体も同様です。バックエンド、管理画面、アカウント連携やクローズドテストのための小さなプレイヤーポータル、そしてUnityパッケージ。そして、このツールはゲームごとに新しい役割を担ってきました。PHP版はプレイヤーが気づくようなダウンタイムなしで10年間稼働し、最近C#版に置き換えられました。この記事ではPHP時代のことを取り上げます。スクリーンショットはC#版からのもので、終盤には新機能についてのセクションがあります。 これらのゲーム全てにかかるホスティング費用は、月額10〜50ユーロでした。プレイヤー数、特に無料のモバイルゲームのプレイヤー数に依存します。誰もプレイしなければ、費用はかかりませんでした。プレミアムゲームでは、有料プレイヤーあたりのコストは無視できるほどでした。私はこれを一人で構築し、メンテナンスはほとんど必要ありませんでした。Googleは古いPHPランタイムを維持し、新しいランタイムへの移行も問題なく、ただ動き続けました。シンプルさを保つこと、PHPを含めて、は計り知れないほど報われました。これはまた、私たちの仕事の中で誰も見ない部分でもあります。プレイヤーはゲームを見、レビューアはゲームを見ますが、全てのローンチと全てのポートを可能にしたものは、管理ログインの背後にあります。長年、これを公開したいと思っていました。それでは、ご覧ください。 ゲーム数 7 (うち6つは自社製、1つは他社製) プラットフォーム数 11 使用期間 2016年から現在まで バックエンド PHP on Google App Engine, Firestore (約20,000行); 2026年9月以降はC# on Cloud Run 月額費用 全ゲーム合計で10〜50ユーロ 開発・保守 開発者1人 Crash Drive 3のダッシュボード、ローンチから4年後。ログインした直近300人のプレイヤーのうち、10人中4人がAndroid、4分の1がiPhone、4分の1がSwitchでした。この混在が、私たちがあらゆるプラットフォームに展開する理由です。SteamやSwitchで支払ったプレイヤーは、常に誰かとドライブする相手がいます。 始まり これ以前は、ゲームごとに小さなPHPスクリプトをたくさん書いていました。オンラインで何かが必要になるたびに、メインメニューのライブニュース、カウンター、バージョンチェック、ちょっとしたイベントなどです。それらは醜く、私は常にゼロから書き直していました。それを変えたのは、Maroonersのコンソールリリースでした。6人の友人たちが作ったパーティーゲームをPlayStation 4、Xbox One、PCに持ち込むことになり、私はポートチームでした。マットがテストとUIを担当しました。ゲームが私たちの手から離れると、内部で何が起こっているのか全く分かりませんでした。PCでは、何か問題が発生するとSteamフォーラムに投稿があります。コンソールでは沈黙が続き、後に認証失敗となります。最初の試みは、Redisバックエンドを持つPiwikでした。データベースがボトルネックになることは分かっており、Redisは非常に高速なので、フリーランサーにセットアップを依頼しました。Redisの仕組みを全く知らなかったからです。まともに動作させることはできませんでした。パワーは、求めていない複雑さをもたらし、何か問題が起こるたびに、出荷するのではなく、誰かのアーキテクチャを読んでいました。それがツールにおいて私が我慢できないことです。朝に機能を構築し、午後にライブにしたいと思っており、それに邪魔になるものは全て排除しなければなりません。そこで、それを捨てて、App EngineとFirestore上で、PHPで、スキーマもフレームワークもなしで、自分で構築しました。その再構築のために、オランダのR&D税額控除であるWBSOを申請しました。資金は modest でしたが、それを真剣なプロジェクトとして書き出すことで、そのように扱うようになりました。クリスマスの休暇中に多くの部分が構築されました。Maroonersでは既に動作していたため、休暇明けにVerdunに組み込むのは数週間ではなく数日でした。WW1チームの誰かが、私が休暇中にずっと作業していたのかと尋ねました。そこから、ゲームごとに成長していきました。WW1ゲームは、Jos、マット、私が設立した会社WW1 Game Seriesによって作られ、チームは長年で25人に成長しました。Crash Drive 2は再び私一人で、マットがテストとUIを担当しました。Crash Drive 3は私たち4人でした。各リリースで機能やプラットフォームが追加され、各機能は古いゲームが動作し続けるように構築されました。APIのルートはまだapi_v1と呼ばれています。後方互換性が不可能になったその日、新しいゲームはapi_v2で開始されるでしょう。その日は決して来ませんでした。 バックエンドの機能 人々が「アナリティクスバックエンド」と聞くと、右肩上がりの線があるダッシュボードを想像します。それは、2人から25人までのチームのために、それ以上のことを行います。 🐛 クラッシュとエラーレポート。例外、クラッシュダンプ、スクリーンショットとログファイル付きのバグレポートを、そのゲームのダッシュボードに表示します。 🔐 クラウド認証。Steamチケット、Epicトークン、Windows Store、PSN。1つのエンドポイント、プラットフォームごとに1つのユーザーレコード。BANはゲームごと、または全てのゲームで一度に行えます。BANされたSteamプレイヤーは、SteamプロフィールでもゲームBANされ、Steamをそのように支援するのは満足感があります。 🎛️ リモート設定。クライアントが1日キャッシュする、ゲームごとの型指定された設定。アナリティクスを切り替えたり、最小バージョンを設定したり、キャッシュブースト週末をスケジュールしたり、パッチなしでバランス数値を変更したりできます。 📈 オンライン統計。常に増加するグローバルカウンターなので、改ざんされたクライアントは履歴を書き換えることができません。Crash Drive 3のプレイヤーは1億4900万キロメートルを運転し、そのうち3500万キロメートルをドリフトし、3800万個の樽を崖から突き落としました。 🧾 SteamとEpicのDLCと所有権チェック。ゲームがクライアントを信頼する必要がないようにします。 👥 プラットフォームをまたいだフレンド、招待、セッション。PhotonのWebhookを基盤としています。 🗳️ プラットフォームごとの投票、バウチャー、キーセット(プレスやテスター用)、そしてクリックと、ゲームからのフィードバックによる実際のコンバージョンを追跡するリンクトラッカー。これにより、DiscordのリンクがTwitterの同じリンクよりも約10倍効果的であることが分かりました。 🏗️ ビルド。Jenkinsがダッシュボードに接続されています。ボタン1つでビルドが開始され、結果は自動的にSteamの最新ブランチに着地し、別のボタンで公開されます。ビルドログには各ステップのタイミングが記録されており、ビルドが遅くなった原因を見つけ、その後も監視を続けました。 ⏱️ ベンチマーク。ゲームはシーンまたはシナリオを実行し、数値を投稿します。それらはダッシュボードに記録され、ビルド間で比較可能です。 💬 Discord。新しいレビュー、キュレーターの言及、セールス目標、クラッシュの急増、チーター、新しいビルド、コミット。全てのSteamレビューは、レビュアーのプレイ時間とSteamがスコアにカウントしているかどうかの情報と共に、チャンネルに表示されます。Crash Drive 2に210時間費やしたプレイヤーが「本当にこのゲームをプレイするのが恋しい!」と書いたレビューを、チーム全員が1時間以内に見ることができました。否定的なレビューも同様に扱われるため、ほぼ即座に対応できます。 🧪 クローズドテスト。WW1ゲームとCrash Drive 3のために、以前のゲームを所有しているプレイヤーを招待して次のゲームをテストしてもらいました。プレイヤーポータルにサインインすると、バックエンドがSteamでそのプレイヤーがゲームを所有しており、十分にプレイしているかを確認し、NDAのためにHelloSignに誘導し、署名済みNDAが返されたことを確認し、Discordをリンクしてテスターロールを付与し、Steamキーを配布します。スプレッドシートなしで数百人のテスターを管理しました。 📜 コミット履歴ページ。最初はSVN、後にGitで、ポストコミットフックから供給され、さらにFavro、Trello、UserEchoも含まれます。バックエンドは既に全ての情報を持っていたため、それらを他所に置くよりも安価でした。 これら全てで、およそ20,000行のPHPコードが使用されており、以下のように組み合わされています。 重要な決定事項 件数ではなく、レートでアラートを出す システム全体で最も役立つルール:クラッシュアラートは例外の数を見ません。アクティブユーザーあたりの例外数が閾値(現在は0.05)を超えた場合、またはセッションあたりのエラー数が1.5を超えた場合に発火します。ローンチ日には、何かがトリガーされる前に数千人のプレイヤーがいても、それほど多くのアラートは発生しません。