Engineer Fighter

https://github.com/orgs/2505-future/repositories

―

Go

TypeScript

AWS

GraphQL

Remix

己の"エンジニア力"を競え──────。

yotu

kacchan

fe01

zatunohito

推しアイデア

（ご存じの通り）GitHub のステータス=エンジニアの「命」 エンジニアの強さを戦わせられる！！

作った背景

戦いたいから。

推し技術

Phaser.jsをエンジンとして作成したゲームにWebSocketを繋ぎこみ、リアルタイムで動くゲームを作成している点。

プロジェクト詳細

概要

エンジニア力を用いて、他人を蹴落とすゲームです。複数人プレイ対応です。一応スマホでもできます。 https://deepwiki.com/2505-future/58hack-front

あそびかた

image

  1. ゲームが開始されると、プレイヤーはフィールドにランダムに配置されます
  2. 画面上の任意の場所で一度クリックすると、「ひっぱり準備状態」になります
  3. カーソルを動かしてもう一度クリックすると、アイコンが移動します！
  4. プレイヤーにぶつかると、ぶつかった相手を吹き飛ばします！
  5. フィールドからはじきとばすことで、相手を脱落させることができます！
  6. 最後に生き残ったプレイヤーが勝者です！

ステータス

各プレイヤーは、GitHub アカウントの情報をもとにした「ステータス」を持っています。エンジニア力が強ければ強いほど、プレイヤーとしての能力も高くなります image

技術構成
  • インフラ構成
  • RemixでSSRを行うために、Cloudflare Workersを利用
  • 開発体験の向上のため、独自のワークフローを定義し、PR作成、同期した際に自動でビルドを行い、プレビューを作成、PRにコメントを行います
  • APIサーバーはサーバーレスで構築し、こちらも自動デプロイまで整備しています
  • WebSocketサーバーは別で実装を行い、コネクションの管理とメッセージの送受信のみのロジックを実行するようにしています image

フロントエンド

Remix で構築しています。SSR の魅力に惹かれて選択しましたが、ほとんどの処理をクライアント側で行うので、普通にミスりました。React,TypeScriptを使いながら開発しています。 image

ゲーム

JS のゲームフレームワークである Phaser を使用しています。 フロントエンド側でゲーム状態を使用することがあるため（例：決着後にランキングを表示する）、データ管理は Phaser のデータ管理機能を使用せず、代わりに 自作の State Manager に持たせています。

バックエンド
  • インフラの変更に強くするためにクリーンアーキテクチャを採用
  • DynamoDBやSupabase、WebSocketの部分を他のインフラに移行できるようにしています image

WebSocket
  • APIGatewayと3つのLambda、DynamoDBを用いてWebsocketをクラウドインフラで実現
  • サーバーレスなので、スケールアウトしやすい
  • APIサーバーとは別で開発を行うことで、APIサーバーと疎結合にしています image

認証
  • クライアントサイドからSSRで安全に認証を行なっています
  • Supabaseを用いてGithub OAuthを使用して認証を行い、トークンを用いて、GitHub GraphQLでユーザー情報を取得しています

AI活用

キックオフ時に以下のような資料が共有されました。 image これがとてもいい資料で、「企画」「要件定義」「設計」「実装」「評価」と ステップを正しく認識させ、役割をAIごとに分担したりする ことでより的確な出力を得られるように工夫してみました。 なお「企画」は人間がやったほうがいいなと思ったので（無限に発散しようとしてくる）、これは対象外です。

要件の洗い出し

Claude を使用しました。 最初は普通に応答しようとしましたが、会話が長くなるにつれ過去の内容を記憶していないように見受けられたので、以下のようなフローで会話しました。

  1. ユーザー >> すでに定まっている企画案、考え、既知の問題点などを話し、情報を整理させたあとに要件や問題点を洗い出すように伝える
  2. AI>> 「情報の整理（メモ）」、「要件」「AI からの提案」の二段階に分けて出力する
  3. 「AIからの提案」についての是非を伝え、改めて情報の整理を行ってもらう。
  4. 2~3 を繰り返す

要するに「ひとつ前の出力を参照できれば、会話の全容がつかめる」といったかんじです。 実際は以下のような感じ。

  • 1

以下は、私が作成しようと思っているゲームのMVPのサービスフローと各概念の定義になります（添付画像）。これらをもとにこれから制作を行う予定です。 あなたは、このサービスのディレクターになりました。まずはサービスフローと概念について読み込み、不足していると考えられる点、不安な点などを書き出してください。なお、MVP である点（必要最小限に要件をとどめている点）には注意してください。

  • 2
提示されたサービスフローと概念定義を確認しました。GitHub データを活用したゲームプラットフォームのMVPについて分析します。

# サービスの概要理解
このサービスは、GitHub アカウントを持つユーザーが参加できるゲームプラットフォームで、ユーザーのGitHubデータ（コミット数、PR数など）を活用してゲームキャラクターのステータスを設定し、ルーム制でゲームを行うシステムと思われます。
（略）

不足している点・不安な点
1.サービスの目的と価値提案
MVPの目的が明確ではありません。このサービスがどのような問題を解決するのか、ターゲットユーザーにどのような価値を提供するのかが不明確です。
GitHub開発者向けのゲーミフィケーションなのか、単なる娯楽なのか、目的を明確にすると良いでしょう。

（略）

# MVPとしての評価
現状のMVPとしては、基本的な機能（ユーザー登録、部屋作成、ゲーム実行）の流れは定義されていますが、以下の点についてはMVPでも明確にしておくべきでしょう：

（略）
  • 3
あなたの質問に対し、以下のような解答が用意されました。まずは内容を整理して、デベロッパーが課題としていること、タスク、そして新たな意見などがあれば下さい。

> 「手の込んだジョーク」という位置づけですが、MVPの評価基準を設定したほうが良いでしょう
では例に従い、「ハッカソン期間内に、GitHubデータを活用した単発プレイ可能なゲームが完成しているか」とする。

> 公開データのみを使用するとのことですが、OAuth認証の処理でのセキュリティ考慮は必要
これには同意。考えられるのは PKCE Flow の導入や state の使用などだが、ひとまずこれはオプショナルな要件として扱いたい。バックログに追加。

（略）

以下 3 のようなテンプレートを使用して応答することで、会話を定型的に行うことができました。

設計

フロントエンドの UI 構築に v0 を使用しています。とはいえ機械的な UI を使うのは嫌だったので、参考程度にとどめています。 image

実装

Cursor を使いたかったのですが、メンバーの半数が審査に落ちました。なので、 GitHub Copilot / Cursor の両方を使っています。

評価

GitHub Copilot for Review を使用しています。GitHub Rules で設定を追加することで、PR 時にオートでレビューを追記してくれます（うれしい）。

そのままだと味気がないので、関西弁でしゃべらせました。エセ感がすごい。 image

yotu

@yotu