0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Amazon Q CLI でゲームを作ろうに応募してみる

Posted at

#0. きっかけ

以下、一部CLAUDE.md や、.claude/order.md など、Claude Code を匂わせるような設定ファイルが見受けられますが、実際にはAmazon Q Developer を使っています。

#1. 準備

Role&Rules

以下の任意の名前のマークダウンファイルを作成し、load CLAUDE.md のように指示します。

details
# CLAUDE.md

## Goal

- このリポジトリは以下の状態を目標とします
  - 可読性が高い
  - 変更が容易である
  - 認知負荷が高くならないような工夫が施されている
  - 初学者にも分かりやすい
- CLI で動く中学生が真似してみたくなるようなゲームを完成させます


## Environment
- マスターはmacOS, Ubuntu(WSL) のいずれかで開発しています


## Role

- あなたは優秀なITエンジニアです
- 勉強家で常に最新の技術動向のキャッチアップに努めています


## Rule

- 常に日本語で会話します
- 原則としてテスト駆動開発(TDD)で進めます
- 期待される入出力に基づき、まずテストを作成します
- 実装コードは書かず、テストのみを用意します
- テストを実行し、失敗を確認します
- テストが正しいことを確認できた段階でコミットします
- その後、テストをパスさせる実装を進めます
- 実装中はテストを変更せず、コードを修正し続けます
- すべてのテストが通過するまで繰り返します


## Process

1. 開発環境の制約を考慮し、テストファイルには以下を必ず含める:
    - モジュール/パッケージ解決の問題への対処
    - 外部依存関係がない場合の代替実装
    - 環境固有の制約に対応した実装方針
    - 言語・フレームワーク固有のベストプラクティスの適用
2. 開発指示内容を実装可能なタスクに分解し `amazon-q/tasks` に以下で述べる出力形式でmdファイルをタスク毎に作成します
    a. 各機能は必ず「テスト作成タスク」→「実装タスク」のペアで分割します
    b. テスト作成タスクでは実装コードを一切書かず、テストのみを作成します
    c. 実装タスクではテストコードを変更せず、既存テストをパスさせる実装のみを行います
    d. 各ペアは独立したコミット単位とし、テスト→実装の順序を厳密に守ります
    e. 技術的な実装順序と依存関係を考慮します(実装タスクは対応するテスト作成タスクに依存)
    f. 優先度は機能の重要度と実装の前提条件を基準に設定します
    g. タスクファイル名は task_{03d}.md とします
    h. タスクファイルに出力する詳細は `amazon-q/tasks/task_template.md` に従ってください
3. タスクファイル群を出力しきったら、一度自分で文章に難解な部分がないかレビューします
4. レビューし終わったら、開発作業に着手する前に、タスク内容の確認をマスターに求めます
5. マスターから開発作業の着手許可をもらったら、開発作業に着手します
6. 開発作業中は、タスク進捗の最新状態をマスターに把握してもらうため、必ず`tasks`内の各ファイルのステータスを随時更新します
7. 開発作業が完了したら、README.md を更新します
8. README.md の更新が終わったら、マスターにどのような思想で開発したのか、工夫した点は何かを説明してください。


## Interaction

- マスターの意図を正確に理解するため、必要に応じて確認の質問を行います
- 開発指示書に含まれてないが、「もっとこうしたらユーザが喜ぶのに」や「もっとこうしたら開発者の開発が楽になるのに」という提案は積極的にします
- 作業中断の原則:
  - 明確で具体的な確認事項がある場合のみマスターに報告する
  - 「何か確認したいことはありますか」のような曖昧な質問は行わない
  - 技術的な判断や実装方針で迷いがある場合は、具体的な選択肢を示して確認を求める
  - 確認事項がない場合は、最後まで作業を完了させてから報告する

#2. 作成の方針

一度簡単にCUIのみで実行できるゲームを作ります。
その後、PyGameライブラリを使ってGUI化していきます。

#2-1. 作るゲームのアイディア出し

どんなゲームに仕上げていくか、の相談からAmazon Qにしていきます。

details
> まずは作るゲームのアイディア出しからしていきましょう。
承知いたしました。CLIで動く中学生が真似してみたくなるようなゲームのアイディア出しを行いましょう。

以下のような観点から、魅力的なゲームアイディアを提案させていただきます:

## 🎮 ゲームアイディア候補

### 1. 数字当てゲーム(進化版)
• コンピュータが思い浮かべた数字を当てるゲーム
• ヒント機能(「もっと大きい」「もっと小さい」)
• 難易度選択(1-10, 1-100, 1-1000)
• スコアランキング機能

### 2. テキストRPG冒険ゲーム
• 選択肢で進むストーリー
• HP、経験値、アイテムシステム
• 複数のエンディング
• セーブ・ロード機能

### 3. 単語当てゲーム(ハングマン風)
• 隠された単語を文字を入力して当てる
• カテゴリ選択(動物、食べ物、国名など)
• 間違い回数制限
• ヒント機能

### 4. じゃんけんトーナメント
• CPU相手のじゃんけん
• トーナメント形式
• 連勝記録
• 戦績統計表示

### 5. 迷路脱出ゲーム
• ASCII文字で描かれた迷路
• WASD操作で移動
• ゴールまでのタイム計測
• 複数ステージ

## 🎯 推奨アイディア

「数字当てゲーム(進化版)」を推奨します。理由:

• **シンプルで理解しやすい**:中学生でもルールがすぐ分かる
• **段階的に機能追加可能**:基本版→ヒント機能→ランキング機能
• **プログラミング学習に最適**:条件分岐、ループ、ファイル操作など基本要素を学べる
• **拡張性が高い**:AI対戦、オンライン機能なども後から追加可能

どのアイディアがお気に入りでしょうか?または、他にご希望があれば教えてください。

アイディアを膨らませていきます。
このとき、「もっと面白くして」「もっと楽しく」とかではなく、ゲームをプレイしてくれる人を想像しながら、詳細を検討していきます。

> テキストRPG冒険ゲームがよいですね。テーマは中学校の理科。科学好きな子にもっと科学を好きになってもらえるような仕掛けを組み込んでいきたい。要件だ しを一緒にしていきましょう。
素晴らしいアイディアですね!テキストRPG冒険ゲームで中学校理科をテーマにするのは、科学好きな子どもたちにとって非常に魅力的だと思います。

## 🧪 テキストRPG冒険ゲーム「理科の冒険者」要件出し

### 基本コンセプト
• **テーマ**:中学校理科(物理・化学・生物・地学)
• **目標**:科学好きな子にもっと科学を好きになってもらう
• **対象**:中学生(12-15歳)

### 🎮 ゲーム要件案

#### **ストーリー設定**
• プレイヤーは「科学研究所の見習い研究者」
• 謎の現象を解決するため、4つの世界(物理界・化学界・生物界・地学界)を冒険
• 各世界で理科の知識を使って問題を解決

#### **ゲームシステム**
1. キャラクター成長
   • 知識ポイント(物理・化学・生物・地学)
   • 実験スキル
   • 観察力レベル

2. 戦闘システム
   • 理科クイズで敵を倒す
   • 実験で謎を解く
   • 正解すると経験値獲得

3. アイテムシステム
   • 実験器具(顕微鏡、試験管、磁石など)
   • 参考書(ヒント機能)
   • 標本コレクション

#### **教育的仕掛け**
• **実際の実験手順**をゲーム内で体験
• **身近な現象**の科学的説明
• **発見の歴史**を冒険として体験
• **間違いから学ぶ**仕組み

### 🤔 確認したい点

1. 難易度レベル:中学1年〜3年のどの範囲をメインにしますか?
2. 学習要素の比重:ゲーム性と学習のバランスはどの程度にしますか?
3. プレイ時間:1回のプレイでどのくらいの時間を想定しますか?
4. 進行方式:リニア進行 vs 自由探索、どちらがお好みですか?

どの要素から詳しく検討していきましょうか?

わからない質問に対しては、「わからないので教えて」と質問することで、新たな発想を得ることができます。

details
> 中学3年生まで範囲にしましょう。序盤はゲーム性重視、終盤は学習重視にしましょう。楽しく入り込んでもらい、いつの間にか夢中になって科学に興味をそそ られている状態がよいですね。プレイ時間は15分〜30分。進行形式については、あなたに相談したい。リニア進行は決まったシナリオに沿って進めていくものと認識しているのですが、自由探索とは?
素晴らしい方針ですね!中学3年生まで範囲で、序盤はゲーム性重視→終盤は学習重視という段階的なアプローチは、子どもたちを自然に科学の世界に引き込む理想
的な設計だと思います。

## 🗺️ 進行方式について

### **リニア進行**
• 決まったシナリオに沿って一本道で進む
• ストーリーが分かりやすい
• 学習内容を段階的に積み上げられる

### **自由探索**
• プレイヤーが行きたい場所を選んで探索
• 複数のエリア(実験室、図書館、野外観察地など)を自由に移動
• 興味のある分野から始められる
• 発見の楽しさを重視

## 🎯 推奨案:**ハイブリッド方式**

以下の組み合わせはいかがでしょうか:

### **序盤(ゲーム性重視)**
• **自由探索**で興味を引く
• 4つのエリア(物理・化学・生物・地学の研究室)を自由に選択
• 各エリアで簡単な謎解きやミニゲーム
• 「あれ?面白いな」という発見を重視

### **中盤〜終盤(学習重視)**
• **リニア進行**でストーリー展開
• 序盤で集めた知識を組み合わせて大きな謎を解く
• 「あの時学んだことがここで活かされる!」という達成感
• より深い科学的思考を促す

### **メリット**
• 最初は自由度で興味を引く
• 後半は体系的な学習で理解を深める
• 15-30分という時間にも適している

この**ハイブリッド方式**についてどう思われますか?それとも、完全にどちらか一方の方式がお好みでしょうか?
> いいですね、さすがです。ハイブリッド方式で行きましょう。次に何を検討したら、より良いゲームに仕上がると思いますか?
ありがとうございます!ハイブリッド方式で進めましょう。

次に検討すべき重要な要素を優先順位順に提案いたします:

## 🎯 次に検討すべき要素

### **1. 具体的なストーリー設定**
• **メインクエスト**:どんな謎や問題を解決するのか?
• **世界観**:研究所?学校?未来都市?
• **キャラクター**:主人公、案内役、ライバルなど
• **動機**:なぜ冒険するのか?(世界を救う、謎を解く、コンテストに勝つなど)

### **2. 学習コンテンツの具体化**
• **各分野の重要トピック**選定(中1〜中3範囲)
• **実験・観察の再現方法**
• **クイズの出題形式**(選択肢、記述、実験手順など)
• **間違いから学ぶ仕組み**の設計

### **3. ゲームメカニクスの詳細**
• **プレイヤーの成長システム**
• **アイテム・装備システム**
• **セーブ・ロード機能**
• **難易度調整の仕組み**

## 🤔 私の推奨

「具体的なストーリー設定」から始めることを推奨します。

理由:
• ストーリーが決まると、学習コンテンツの組み込み方が明確になる
• キャラクターや世界観が決まると、中学生が感情移入しやすくなる
• 開発の方向性が定まり、後の設計判断がしやすくなる

どの要素から検討を始めたいでしょうか?それとも、他に重要だと思われる要素はありますか?

こんな感じでストーリー設計を進めていきます。
ある程度出来たら、「一旦詳細はお任せします。実際にものを作ってレビューし、改善していく手法にしましょう。」というと良いです。

#2-2. シンプルなCLIベースのゲームを作ってもらう

まずはシンプルにCLIベースでゲームとして成立するのか確認していきます。

details

入力の問題ですが、ゲーム自体は正常に動作しています!

## 🎉 完成!「理科の冒険者 〜ウパ丸とコケマユの文明再構築記〜」

### **🌟 完成した機能一覧**

#### **✅ 完全な3章構成**
• **第1章**: 探索と発見(理科室・校庭・工作室)
• **第2章**: 文明再構築プロジェクト(発電・通信・生態系)
• **第3章**: 統合システム構築(エネルギー統合・最終チャレンジ)

#### **✅ 完璧なクイズシステム**
• **全15問**の仮説検証ベースクイズ
• **段階的ヒント**システム(3段階)
• **論理的に一意の正解**
• **中学理科の全範囲**をカバー

#### **✅ 感動的なストーリー**
• **6匹の仲間**の段階的回復

(以下略)

なんか出来ているらしいので確認する。
image.png
image.png
image.png

いや、むずいってw

image.png

なんかクイズの中身自体の調整は時間を要する、もしくは生成のアプローチを変えないといけない気がします。
一旦、動いてそうなので、細かいところはあとで修正することとする。

2-2. GUI化

> pygameを使って、GUIにしたい。まずはCUIから開発指示書を作り、GUIの開発準備をして。
完了しました!CUIベースのゲームをCUIディレクトリに整理し、pygame GUI版の開発準備を整えました。

## 📁 現在のプロジェクト構造

amazon_q_game_trial/
├── CUI/                   # CUI版ゲーム(完成版)
│   ├── main.py           # CUI版メインファイル
│   ├── quizzes.py        # クイズデータ
│   ├── characters/       # キャラクターデータ
│   ├── experiments/      # クイズ管理システム
│   ├── story/           # ストーリーテキスト
│   ├── utils/           # 共通機能
│   ├── save/            # セーブデータ
│   └── README.md        # CUI版説明
├── GUI/                  # GUI版ゲーム(開発予定)
│   └── README.md        # GUI版説明
├── .claude/             # 開発管理
│   └── order.md         # pygame GUI化の開発指示書
└── README.md           # プロジェクト全体説明


## ✅ 完了した作業

1. CUIディレクトリの作成: 既存のCUIゲームをCUI/に移動
2. GUIディレクトリの準備: pygame版開発用のGUI/ディレクトリを作成
3. 依存関係の追加: pyproject.tomlにpygame>=2.5.0を追加
4. 開発指示書の作成: .claude/order.mdにpygame GUI化の詳細な要件を記載
5. README更新: CUI版とGUI版の両方の実行方法を記載

## 🎮 現在の実行方法

CUI版(いつでも実行可能):
bash
cd CUI
python main.py


GUI版(開発完了後):
bash
cd GUI
python main_gui.py


これで、CUI版はいつでも実行できる状態で保持され、pygame GUI版の開発を並行して進められます。

作られていた開発指示書は以下。

# 開発指示書

## プロジェクト概要

### プロジェクト名
理科の冒険者 〜ウパ丸とコケマユの文明再構築記〜 pygame GUI版

### 目的
現在のテキストベースCLIゲームをpygameを使用してグラフィカルなGUIゲームに変換し、中学生にとってより親しみやすく視覚的に魅力的な学習体験を提供する

### 対象ユーザー
- 中学生(12-15歳)- 主要対象
- 理科に興味のある小学校高学年〜高校生
- 理科教育関係者(補助教材として)

## 要件定義

### 機能要件

#### 必須機能
- [ ] pygame基盤のGUIシステム構築
- [ ] 既存のテキストベースゲームロジックの移植
- [ ] キャラクター画像表示システム
- [ ] メニュー・ボタンによる操作システム
- [ ] テキスト表示・ダイアログシステム
- [ ] クイズ画面のGUI化
- [ ] セーブ・ロード機能のGUI対応
- [ ] 設定画面(音量、画面サイズ等)

#### 任意機能
- [ ] BGM・効果音システム
- [ ] アニメーション効果
- [ ] パーティクルエフェクト
- [ ] フルスクリーン対応
- [ ] キーボードショートカット

### 非機能要件

#### パフォーマンス要件
- 60FPS での安定動作
- 起動時間3秒以内
- メモリ使用量200MB以下

#### ユーザビリティ要件
- 直感的な操作性
- 中学生が迷わず操作できるUI
- アクセシビリティ対応(文字サイズ調整等)

#### 互換性要件
- Windows 10/11対応
- macOS 10.15以降対応
- Python 3.8以降対応

## 技術仕様

### アーキテクチャ
- MVCパターンベースの設計
- 既存のゲームロジックを活用したレイヤー分離
- pygame イベント駆動アーキテクチャ

### 技術スタック

#### GUI フレームワーク
- pygame 2.5.0以降
- Python 3.8以降

#### 既存システム活用
- 既存のゲームロジック(Game, GameState, QuizManager等)
- 既存のストーリー・キャラクターデータ
- 既存のクイズシステム

#### リソース管理
- 画像ファイル(PNG形式)
- フォントファイル(TTF形式)
- 音声ファイル(OGG/WAV形式)

### GUI設計方針

#### 画面構成
#```
メイン画面
├── タイトル画面
├── メニュー画面(エリア選択)
├── ゲーム画面(ストーリー・クイズ)
├── 設定画面
└── セーブ・ロード画面
#```

#### UI要素設計
- ボタン:統一されたデザイン、ホバー効果
- テキスト:読みやすいフォント、適切なサイズ
- ダイアログ:半透明背景、中央配置
- レイアウト:レスポンシブ対応

## 制約事項

### 技術的制約
- 既存のゲームロジックを可能な限り保持
- pygame の機能範囲内での実装
- クロスプラットフォーム対応

### 業務的制約
- 教育的価値を損なわない
- 中学生が理解できる操作性
- 既存のストーリー・クイズ内容は変更しない

### リソース制約
- 軽量なリソースファイル(画像・音声)
- 配布しやすいファイルサイズ

## 品質基準

### テスト戦略
- 単体テスト:GUI コンポーネントのテスト
- 統合テスト:既存ロジックとGUIの連携テスト
- ユーザビリティテスト:中学生による操作テスト
- テストカバレッジ目標:80%以上

### コード品質基準
- PEP8準拠
- 型ヒント使用
- docstring記述
- 既存コードとの一貫性

## 成果物

### 開発成果物
- [ ] pygame GUI システム
- [ ] リソースファイル(画像・フォント・音声)
- [ ] 設定ファイル
- [ ] 実行可能ファイル(PyInstaller等)

### ドキュメント
- [ ] GUI操作マニュアル
- [ ] 開発者向けドキュメント
- [ ] リソース作成ガイドライン

## 参考資料

### 関連ドキュメント
- 既存README.md
- 既存ゲームロジック

### 外部リソース
- pygame公式ドキュメント
- Python GUI設計ベストプラクティス

## 追加要望・注意事項

### 開発者への追加要望
- 既存のテキストベースの魅力を損なわないよう配慮
- 中学生が「作ってみたい」と思えるような実装
- コードの可読性と拡張性を重視

### 特記事項・注意点
- 既存のゲーム進行ロジックは極力変更しない
- リソースファイルは著作権に配慮した素材を使用
- 教育的価値を最優先に考慮

---

**作成日**: 2025-06-29  
**更新日**: 2025-06-29  
**作成者**: Amazon Q

CUIでおおよそのストーリーを作っていったので、だいぶ開発指示書の内容が良さげですね。
あとは一度作ってもらってからレビュー&改善をしていきましょう。
というわけで、開発開始。
と言っても、待っているだけなんだが。

image.png

今回は残念ながら、以下のようなレートリミットにあたってしまったので、
続きは来月になりますが、一応CUIベースのものは完成しましたので、Tシャル応募はできるかと。
image.png

#3. まとめ

  • Role&Rulesは他のAIエージェントで使っているものを流用可能
  • CUIから作っていくことでストーリーラインのイメージを具現化しやすくなる
  • 来月以降作り込みをしていきたいです。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?