AIにゲーム開発要件を記述する:シーン、ノード、コンポーネント、インタラクションの記述方法
AIに「ジャンプ機能を作って」と記述すると、実行できない断片的なコードが返ってきました。完全なゲームレベルを作成したいけど、ノードツリー構造をどう説明すればいいかわからず、AIが生成した階層がぐちゃぐちゃになってしまった。
問題はAIの能力ではありません。曖昧なプロンプトは、レシピだけで料理を作るのに材料表がないのと同じです。AIは自由に解釈するしかなく、結果はあなたのイメージとは全く異なるものになります。
ゲーム開発の要件は実は標準化できます。シーン、ノード、コンポーネント、インタラクション。この四つの核心概念にはそれぞれ対応する記述テンプレートがあります。この記事では、実践で検証されたメソドロジーを共有します:シーン四要素法、ノードツリーJSON形式、コンポーネント記述テンプレート、インタラクション五要素公式、さらに5つの直接コピーして使えるプロンプトテンプレートを提供します。
Cocos Creatorでミニゲームを開発していて、AIで効率化したいけどいつもうまくいかないという方に、ここに答えがあるはずです。
なぜゲーム要件には標準化された記述が必要か
曖昧な要件記述はAIゲーム開発の最大の敵です。「ジャンプ機能を作って」と言ったら、player.y += 10というコードが返ってきました。物理システムも、衝突検出も、アニメーション遷移もなく、実行したらキャラクターが空に瞬間移動してしまいました。
この種の問題には三つの典型的な症状があります。
一つ目:AIはノード階層を理解できない。Cocos CreatorでPlayerノードを作成し、その下にHealthBar子ノードを付けてHPバーを表示するとします。しかし「プレイヤーを作成して」とだけ言うと、AIはHealthBarを子ノードにする必要があることを知りません。HealthBarを独立したノードとしてシーンのルートに置いてしまうかもしれません。コードを実行すると、HPバーはプレイヤーについてこなくなります。
比較してみましょう。
❌ "プレイヤーを作成する"
✅ "Playerルートノードを作成し、Spriteコンポーネントをマウントしてキャラクターテクスチャを表示。子ノードHealthBarでHPバーを表示、相対位置 (0, 32)"
二つ目のバージョンは親子関係を明確にしているため、AIが生成するコードは階層が混乱しません。
二つ目:コンポーネント組み合わせ関係の混乱。Cocos Creatorの核心アーキテクチャは「ノード+コンポーネント」です。ノード自体は空の殻で、コンポーネントが機能を与えます。PlayerノードにはSprite(テクスチャ表示)、RigidBody2D(物理剛体)、Collider(衝突検出)、PlayerScript(カスタムロジック)の四つのコンポーネントがマウントされる可能性があります。「キャラクターを移動できるようにして」とだけ言うと、AIは移動スクリプトだけを渡し、物理コンポーネントを忘れるかもしれません。キャラクターが壁を通り抜けてしまい、衝突フィードバックがまったくありません。
正しい記述はコンポーネントリストを明確にするべきです。
❌ "キャラクターを移動できるようにする"
✅ "PlayerノードにRigidBody2Dコンポーネントをマウント(type: dynamic)、子ノードにColliderコンポーネント(tag: 'player')、さらにPlayerScriptを追加してキーボード入力を処理"
三つ目:インタラクションロジックの断片化。「ボタンをクリックしたらジャンプする」と言うと、AIはタッチイベントリスナーコードを渡しますが、どれくらいの時間ジャンプするか、どれくらいの高さか、ジャンプ中に再ジャンプできるか、ジャンプ後の状態復帰など、これらの詳細が処理されていません。コードを実行すると、ボタンをクリックしたらキャラクターは確かに動きますが、アニメーションがカクカクし、状態がロックされ、連続クリックでバグが出ます。
完全なインタラクション記述には五つの要素を含めるべきです:トリガー条件、イベントタイプ、ターゲットオブジェクト、レスポンス動作、状態変化。これについては後で詳しく説明します。まずはこの公式を覚えておきましょう。
インタラクション記述 = トリガー条件 + イベントタイプ + ターゲットオブジェクト + レスポンス動作 + 状態変化
曖昧な記述の根本原因は、構造化思考の欠如です。AIには明確なコンテキスト、具体的な指示、明確な境界条件が必要です。プロンプトエンジニアリングにはCREATEフレームワークがあり、これは本来汎用プログラミングのベストプラクティスですが、ゲーム開発にも同様に有効です。
| フィールド | ゲーム開発への応用 |
|---|---|
| C - Context | エンジンバージョン(Cocos Creator 3.8)、プロジェクト構造、既存コードスタイルを提供 |
| R - Role | AIを「Cocos Creator開発エキスパート」と明確にする |
| E - Example | 期待するノードツリーJSON形式の例を示す |
| A - Action | 何をするかを明確にする(ノード作成、コンポーネントマウント、イベントリスン) |
| T - Tone | コードスタイルを指定(TypeScript + Cocos Creator API) |
| E - Edge | 制約条件を説明(FPS ≥ 60、ノード数 ≤ 50) |
このフレームワークの核心ロジックは、「何をするか」を「どのような条件下で」「何のツールを使って」「どのような基準を達成するか」に分解することです。次の四章では、シーン、ノード、コンポーネント、インタラクションの四つの次元を中心に、CREATEフレームワークを再現可能なテンプレートに落とし込みます。
シーン記述の四要素法
シーンはゲーム開発の最上位概念です。完全なシーン記述には四つの要素が含まれます:タイプ、スタイル、要素、インタラクションポイント。この四つを明確に記述すれば、AIは骨格の整ったレベルを生成できます。
まず四要素の定義を見てみましょう。
| 要素 | 定義 | 記述方法 |
|---|---|---|
| シーンタイプ | ゲームレベル / 界面 / メニュー | 「{タイプ}シーン、{要素}を含む」 |
| ビジュアルスタイル | 2D / 3D、ピクセル / 写実 | 「{スタイル}アートスタイルを採用、{ゲーム名}を参考」 |
| 核心要素 | プレイヤー、敵、アイテム、UI | 「{数量}個の{タイプ}オブジェクト、位置{座標}」 |
| インタラクションポイント | クリック可能 / 衝突エリア | 「{数量}個のインタラクションエリアを定義、{イベント}をトリガー」 |
このメソッドの核心は、まずシーンの「骨格」(タイプ+スタイル)を決定し、それから「コンテンツ」(要素+インタラクションポイント)を埋めることです。家を建てるようなもので、まず設計図を描き、それから家具を配置します。
実戦例を見てみましょう。箱押しゲームのレベルを作成する場合、記述はどう書けばいいでしょうか。
【シーン記述】
シーンタイプ:箱押しゲームレベルシーン
ビジュアルスタイル:シンプルな幾何学スタイルを採用、背景は単色、グリッドサイズ 64x64
核心要素:
- 1つのPlayerノード(位置:1行目1列目)
- 3つのBoxノード(位置:2行目2列目、3行目4列目、5行目2列目)
- 3つのTargetノード(目標位置、くぼんだマスとして表示)
- 壁ノード(シーン境界を囲む)
インタラクションポイント:
- PlayerはBoxを押すことができる、衝突検出が変位をトリガー
- BoxがTargetに到達したら勝利検出をトリガー
- シーン境界衝突がブロックをトリガー
【技術的制約】
エンジン:Cocos Creator 3.8
言語:TypeScript
パフォーマンス:FPS ≥ 60、ノード数 ≤ 50
この記述は四要素をすべて網羅しています。タイプは「箱押しレベル」、スタイルは「シンプル幾何学」、要素はPlayer、Box、Target、壁の四つのオブジェクトの具体的な位置をリスト、インタラクションポイントは箱押し、勝利検出、境界ブロックの三つの核心ロジックを定義しています。技術的制約を別途リストすることで、AIが生成するコードがパフォーマンス要件を満たすようにします。
ここで注意すべきポイントがあります:核心要素の位置は「第N行第N列」で記述し、ピクセル座標を直接書かないこと。こうするメリットは、AIがグリッドサイズ(64x64)に基づいて自動的にピクセル座標に変換し(1行目1列目 = (64, 64))、コードがより柔軟になり、グリッドサイズを変更する際にすべての座標を手動で調整する必要がなくなります。
もう一つテンプレートを提供します。直接コピーして使用できます。
## シーン記述テンプレート
【基本情報】
- シーン名:{sceneName}
- シーンタイプ:{タイプ:戦闘シーン / メニューシーン / 決算シーン}
- ビジュアルスタイル:{スタイル記述}
【核心要素リスト】
1. {ノード名}:{数量}個、初期位置 ({x}, {y})
2. {ノード名}:{数量}個、機能記述
3. ...
【インタラクションポイント定義】
- {インタラクションポイント名}:トリガー条件 {条件}、レスポンス動作 {動作}
- {インタラクションポイント名}:...
【技術要件】
- エンジンバージョン:{version}
- 言語:{TypeScript / JavaScript}
- パフォーマンス指標:{FPS / ノード数 / メモリ}
このテンプレートはほとんどの2Dミニゲームのシーンに適しています。四要素を記入すれば、AIは構造の完全なレベルの骨格を生成できます。第三章では、「核心要素リスト」をノードツリーのJSON形式に展開し、AIに階層関係を理解させる方法を説明します。
ノードツリーの標準記述形式
ノードツリーはCocos Creatorシーンの核心データ構造です。各ノードは子ノードを持つことができ、子ノードは親ノードの位置(相対座標)を継承し、ツリー構造を形成します。AIにノードツリーを記述する最も明確な方法は、JSON形式を使用することです。
なぜJSONなのか?構造化されており、パース可能で、AIが直接理解できるからです。JSONを渡せば、AIはルートノードが誰で、子ノードが何で、各ノードにどのコンポーネントが付いているか、属性は何かを理解します。コード生成時、AIはJSONの階層関係に従ってノードを階層ごとに作成し、親子関係を間違えません。
まず標準的なノードツリーJSON構造を見てみましょう。
{
"rootNode": "Scene",
"tree": {
"Player": {
"components": ["Sprite", "RigidBody2D", "PlayerScript"],
"position": {"x": 100, "y": 200},
"properties": {
"size": {"width": 64, "height": 64},
"anchor": {"x": 0.5, "y": 0.5}
},
"children": {
"HealthBar": {
"components": ["ProgressBar"],
"position": {"x": 0, "y": 32}
},
"Weapon": {
"components": ["Sprite"],
"position": {"x": 48, "y": 0}
}
}
},
"Enemies": {
"components": [],
"children": {
"Enemy1": {
"components": ["Sprite", "EnemyScript"],
"position": {"x": 300, "y": 150}
},
"Enemy2": {
"components": ["Sprite", "EnemyScript"],
"position": {"x": 400, "y": 250}
}
}
},
"UI": {
"components": [],
"children": {
"ScoreLabel": {
"components": ["Label"],
"content": "Score: 0"
},
"PauseButton": {
"components": ["Button"],
"onClick": "pauseGame()"
}
}
}
}
}
このJSONは、シンプルな戦闘シーンを記述しています。ルートノードはSceneで、その下に三つのトップレベルノードがあります:Player(プレイヤー)、Enemies(敵コンテナ)、UI(インターフェース)。Playerの下にはさらにHealthBarとWeaponの二つの子ノードがあります。AIがこのJSONを読むと、HealthBarをPlayerの子ノードとして作成し、位置はPlayerからの相対位置(0, 32)だと理解します。
ノードツリー記述には三つの重要なポイントがあります。
一つ目:親子関係を明確にする。子ノードのpositionは親ノードからのオフセットです。例えば、HealthBarのpositionが(0, 32)というのは、Playerの真上32ピクセルの位置にあることを意味します。Playerが(200, 300)に移動すると、HealthBarは自動的に(200, 332)についていきます。このメカニズムにより、HPバーは常にプレイヤーについて回ります。
HealthBarをシーンのルートノードに置き、Playerの子ノードにしなければ、HPバーはプレイヤーについてきません。私はこの失敗を経験しました:AIが生成したコードはUI要素をすべてルートノードに置き、実行するとHPバーとプレイヤーが分離され、プレイヤーが移動してもHPバーがその場に留まりました。後にJSON形式でノードツリーを記述するように変更したら、AIが生成するコードの階層関係が正しくなりました。
二つ目:コンポーネントは継承ではなく組み合わせ。Cocos Creatorの設計思想は「ノードは実体、コンポーネントが機能を与える」です。ノード自体には何の振る舞いもなく、Spriteコンポーネントを付けて初めて画像を表示でき、RigidBody2Dを付けて初めて物理属性を持ち、Scriptを付けて初めてカスタムロジックを持ちます。この組み合わせ式設計は継承式設計より柔軟です。PlayerにはSprite + RigidBody + Scriptを付け、EnemyにはSprite + RigidBody + EnemyScriptを付け、二つのノードは一部のコンポーネントを共有しつつ、それぞれ独立したスクリプトを持ちます。
JSONではcomponents配列でコンポーネントリストを記述します。AIは配列の順序通りにコンポーネントをマウントし、各コンポーネントの属性はpropertiesで補足できます。
三つ目:ノード命名は規範に従う。キャメルケース(Player、Enemy、HealthBar)を使用し、機能性ノードはアンダースコアを使用できます(bg_sprite、ui_canvas)。命名を明確にするメリットは、AIが生成するコードの変数名が一貫し、後でコードをメンテナンスする際にノードの用途が一目でわかります。
もう一つ実戦例を見てみましょう:シューティングゲームのノードツリーです。このJSONは直接AIに渡して、完全なシーンコードを生成させることができます。
{
"rootNode": "GameScene",
"tree": {
"Player": {
"components": [
"Sprite(テクスチャパス: assets/player.png)",
"RigidBody2D(type: dynamic, gravityScale: 0)",
"Collider(tag: 'player')",
"PlayerScript"
],
"position": {"x": 200, "y": 400},
"properties": {"size": {"width": 64, "height": 64}},
"children": {
"BulletSpawnPoint": {"position": {"x": 32, "y": 0}}
}
},
"Enemies": {
"children": [
{
"Enemy1": {
"components": ["Sprite", "Collider(tag: 'enemy')"],
"position": {"x": 600, "y": 200}
}
},
{
"Enemy2": {
"components": ["Sprite", "Collider(tag: 'enemy')"],
"position": {"x": 700, "y": 300}
}
}
]
},
"Bullets": {
"components": [],
"description": "弾プールコンテナ、動的にBulletノードを作成"
},
"UI": {
"children": {
"ScoreLabel": {"components": ["Label"], "content": "Score: 0"},
"RestartButton": {"components": ["Button"], "onClick": "restartGame()"}
}
}
}
}
このJSONにはいくつか注目すべきポイントがあります:
- Playerの下にBulletSpawnPoint子ノードがあり、位置は(32, 0)です。このノードは弾の発射点で、プレイヤーから32ピクセルオフセットしています
- Enemiesはコンテナノードで、配列形式で複数のEnemy子ノードをリストしています
- Bulletsは弾プールコンテナで、
descriptionフィールドで動的にBulletノードを作成する親ノードであることを説明しています - UIの下のRestartButtonには
onClick属性があり、コールバック関数名を直接バインドしています
AIに渡す際、技術的制約を追加します。
上記ノードツリーJSONに基づいてCocos Creatorシーンを作成してください。
要件:
1. Cocos Creator 3.8 APIを使用
2. TypeScriptコード、型注釈を含む
3. スクリプトコンポーネントは@ccclassデコレータを使用
4. イベントリスンはnode.on()メソッドを使用
AIはJSONの階層関係に従って完全なシーン作成コードを生成し、ノード作成、コンポーネントマウント、属性設定の三つのステップを含みます。コードを受け取った後、スクリプトコンポーネントの具体的なロジックを補充するだけで、シーンの骨格が完成します。
コンポーネント記述テンプレート
コンポーネントはノード機能の担い手です。AIにコンポーネントを記述する際、核心は四つのフィールドを明確にすることです:機能、属性、依存、サンプル設定。このテンプレートは、Cocos Creatorのすべての組み込みコンポーネントとカスタムスクリプトコンポーネントに適しています。
まず四フィールドの定義を見てみましょう。
| フィールド | 必須性 | 記述 |
|---|---|---|
| 機能 | 必須 | コンポーネントが何をするか(一文) |
| 属性 | 必須 | 設定パラメータ(タイプ + 記述) |
| 依存 | 任意 | ノードが必要とする属性 / 他のコンポーネント |
| サンプル設定 | 推奨 | 典型的な設定値 |
このテンプレートのロジックは、まずAIにコンポーネントの用途(機能)を伝え、次に調整可能なパラメータ(属性)をリストし、最後に前提条件(依存)を説明することです。AIはこの構造に従ってコンポーネントマウントコードを生成し、属性値はサンプル設定に従って記入します。
実戦例を見てみましょう:Spriteコンポーネントの記述。
## コンポーネント名:Sprite
**機能**:画像テクスチャを表示、2Dゲームで最も使用されるレンダリングコンポーネント
**属性**:
- spriteFrame:SpriteFrame - 画像リソース | デフォルト値:null
- sizeMode:SizeMode - サイズモード(CUSTOM / RAW / TRIMMED) | デフォルト値:TRIMMED
- type:SpriteType - レンダリングタイプ(SIMPLE / SLICED / TILED / FILLED) | デフォルト値:SIMPLE
**依存**:
- ノードが必要とする属性:size属性(sizeMode = CUSTOMの場合)
**サンプル設定**:
spriteFrame: assets/player.png
sizeMode: RAW
この記述はSpriteコンポーネントの核心属性をすべてリストしています。AIがこれを読むと、次のようなコードを生成します。
const sprite = node.addComponent(Sprite);
sprite.spriteFrame = assets.player;
sprite.sizeMode = SizeMode.RAW;
もう一つ物理コンポーネントの例を見てみましょう:RigidBody2D。
## コンポーネント名:RigidBody2D
**機能**:2D物理剛体、ノードに物理属性を付与(重力、衝突)
**属性**:
- type:RigidBodyType - 剛体タイプ(STATIC / DYNAMIC / KINEMATIC) | デフォルト値:STATIC
- gravityScale:number - 重力係数 | デフォルト値:1.0
- linearVelocity:Vec2 - 線速度 | デフォルト値:(0, 0)
**依存**:
- 必要な他のコンポーネント:Collider2D(衝突検出)
**サンプル設定**:
type: DYNAMIC
gravityScale: 0.5
linearVelocity: (100, 0)
ここに依存フィールドがあります:RigidBody2DはCollider2Dと組み合わせる必要があり、衝突検出ができます。AIがこの依存を読むと、同じノードにCollider2Dコンポーネントを付けるよう促すか、自動的に追加します。
ここでよくある落とし穴を紹介します。以前AIに「キャラクターに物理属性を持たせて」と記述したら、AIはRigidBody2Dだけを付け、Colliderは付けませんでした。コードを実行すると、キャラクターは確かに重力の影響で落ちますが、地面に当たるとそのまま通り抜けてしまいました。衝突検出がないからです。後にコンポーネント記述テンプレートを使用し、依存フィールドを追加したら、AIが生成するコードにはRigidBody2D + Collider2Dの両方が付くようになりました。
コンポーネント記述テンプレートの標準形式をまとめましょう。
## コンポーネント名:{ComponentType}
**機能**:{コンポーネント機能を一文で記述}
**属性**:
- {属性名}:{タイプ} - {記述} | デフォルト値:{default}
- {属性名}:{タイプ} - {記述} | デフォルト値:{default}
**依存**:
- ノードが必要とする属性:{Node 属性}(例:size、anchor)
- 必要な他のコンポーネント:{Component 名}(例:RigidBody2D)
**サンプル設定**:
{property}: {value}
{property}: {value}
**コード例**:
```typescript
// コンポーネントを取得
const sprite = this.node.getComponent(Sprite);
sprite.spriteFrame = newSpriteFrame;
このテンプレートはCocos Creatorのすべての組み込みコンポーネント(Sprite、Label、Button、RigidBody2D、Collider2Dなど)に適用でき、カスタムスクリプトコンポーネントにも適用できます。PlayerScriptコンポーネントを作成する場合、同じテンプレートで記述します。
## コンポーネント名:PlayerScript
**機能**:プレイヤーの移動、ジャンプ、衝突レスポンスのカスタムロジックを処理
**属性**:
- moveSpeed:number - 移動速度 | デフォルト値:200
- jumpHeight:number - ジャンプ高さ | デフォルト値:100
- health:number - 現在のHP | デフォルト値:100
**依存**:
- ノードが必要とする属性:RigidBody2Dコンポーネント(物理移動用)
- ノードが必要とする属性:Collider2Dコンポーネント(衝突検出用)
**サンプル設定**:
moveSpeed: 300
jumpHeight: 150
health: 100
AIがこの記述を読むと、完全なPlayerScript TypeScriptクラスを生成し、@propertyデコレータで定義された属性、onLoad / start / updateライフサイクルメソッド、move / jump / takeDamageなどのカスタムメソッドを含みます。コードを受け取った後、具体的なロジックを埋めるだけで、骨格は完成しています。
インタラクション記述公式
インタラクションはゲームロジックの核心です。プレイヤーがボタンをクリック、キャラクターが敵と衝突、弾がターゲットに命中、これらはすべてインタラクションです。AIにインタラクションを記述する最も明確な方法は、五要素公式を使用することです。
インタラクション記述 = トリガー条件 + イベントタイプ + ターゲットオブジェクト + レスポンス動作 + 状態変化
五つの要素の意味:
- トリガー条件:どのような状況でトリガーされるか(衝突、クリック、キーボード入力)
- イベントタイプ:具体的なイベント名(TOUCH_START、onCollisionEnter)
- ターゲットオブジェクト:どのノード / コンポーネントがイベントに応答するか
- レスポンス動作:どのメソッド / 関数を実行するか
- 状態変化:データ / ビジュアルがどう変化するか
この公式は、インタラクション記述が完全なクローズドループであることを保証します。どの要素が欠けても、AIが生成するコードにはバグがあります。
例を見てみましょう。「ボタンをクリックしたらジャンプする」と言うと、AIはタッチイベントリスナーコードだけを渡しますが、どれくらいの高さまでジャンプするか、どれくらいの時間かけるか、ジャンプ後の状態復帰については説明していません。コードを実行すると、ボタンをクリックしたらキャラクターは確かに動きますが、アニメーションがカクカクし、状態がロックされ、連続クリックで問題が発生します。
正しい記述は五つの要素をすべて明確に書くべきです。
## インタラクション名:クリックジャンプ
【トリガー条件】
- トリガー方式:タッチクリック
- トリガーオブジェクト:JumpButtonノード
- トリガータイミング:TOUCH_END(指が画面から離れる)
【イベントリスン】
- リスンノード:JumpButton
- イベントタイプ:Node.EventType.TOUCH_END
- コールバック関数:onJumpButtonClicked
【レスポンス動作】
- 実行メソッド:PlayerScript.jump()
- パラメータ渡し:height = 100, duration = 0.3
【状態変化】
- データ変化:Player.position.y += 100
- ビジュアル変化:Playerノードがjumpアニメーションを再生(scale: 1.0 → 1.2 → 1.0)
- 状態変化:Player.isJumping = true(0.3秒間継続)
【コード実装】
```typescript
jumpButton.on(Node.EventType.TOUCH_END, (event) => {
const playerScript = player.getComponent(PlayerScript);
playerScript.jump({ height: 100, duration: 0.3 });
}, this);
この記述は五つの要素をすべて網羅しています。AIがこれを読むと、完全なタッチイベントリスナーコードを生成し、コールバック関数、パラメータ渡し、状態管理を含みます。コードを受け取った後、jump()メソッドの具体的な実装ロジックを補充するだけで、インタラクションは完成です。
もう一つ衝突インタラクションの例を見てみましょう。
```markdown
## インタラクション名:衝突ダメージ検出
【トリガー条件】
- トリガー方式:衝突検出
- トリガーオブジェクト:PlayerノードCollider + EnemyノードCollider
- トリガータイミング:onCollisionEnter(衝突開始)
【イベントリスン】
- リスンコンポーネント:PlayerノードのColliderコンポーネント
- イベントタイプ:Collider2D.onCollisionEnter
- コールバック関数:onPlayerHitEnemy
【レスポンス動作】
- 実行メソッド:PlayerScript.takeDamage(amount)
- パラメータ渡し:damage = 10
【状態変化】
- データ変化:Player.health -= 10
- ビジュアル変化:Playerノードがフラッシュ白アニメーションを再生(0.1秒)
- 状態変化:Player.isHurt = true(0.2秒間継続)
【コード実装】
```typescript
onCollisionEnter(self: Collider2D, other: Collider2D) {
if (other.tag === 'enemy') {
const playerScript = this.node.getComponent(PlayerScript);
playerScript.takeDamage(10);
this.flashWhite(0.1);
}
}
ここで注意すべきポイントがあります:トリガーオブジェクトは二つのノードのColliderコンポーネントで、トリガータイミングはonCollisionEnterです。AIがこれを読むと、PlayerのColliderコンポーネントで衝突イベントをリスンし、衝突オブジェクトのtagが'enemy'であることを判断してからダメージロジックを実行することがわかります。
インタラクション記述にはよくある落とし穴があります:状態変化が明確に説明されていない。以前AIに「敵と衝突したらHPを減らす」と記述したら、`health -= 10`というコードが渡されましたが、ビジュアルフィードバック(フラッシュ白アニメーション)も状態ロック(isHurt)も追加されていませんでした。コードを実行すると、プレイヤーが敵と衝突したら確かにHPは減りますが、視覚的なヒントがなく、プレイヤーは自分がダメージを受けたことを知りません。連続衝突で瞬時にHPがゼロになります。
後に五要素公式を使用し、状態変化を追加したら、AIが生成するコードにはフラッシュ白アニメーションと状態ロックが含まれ、インタラクション体験が完全になりました。
ここで標準的なインタラクション記述テンプレートを提供します。
```markdown
## インタラクション名:{インタラクション記述}
【トリガー条件】
- トリガー方式:{タッチ / キーボード / 衝突}
- トリガーオブジェクト:{ノード名}
- トリガータイミング:{TOUCH_START / TOUCH_END / onCollisionEnter}
【イベントリスン】
- リスンノード:{ノード名}
- イベントタイプ:Node.EventType.{イベントタイプ}
- コールバック関数:{関数名}
【レスポンス動作】
- 実行メソッド:{スクリプト名}.{メソッド名}
- パラメータ渡し:{パラメータリスト}
【状態変化】
- データ変化:{変数名} = {新しい値}
- ビジュアル変化:{アニメーション / 色 / 位置変化}
このテンプレートはタッチインタラクション(ボタンクリック、スクリーンスワイプ)、衝突インタラクション(キャラクターが敵と衝突、弾がターゲットに命中)、キーボードインタラクション(方向キー移動、スペースキージャンプ)に適しています。五つの要素を記入すれば、AIは完全なイベントリスンコードを生成できます。
Cocos Creatorのタッチイベントには四つのタイプがあります。参考のためにここにリストします。
| イベントタイプ | トリガータイミング |
|---|---|
| TOUCH_START | 指が画面に触れる |
| TOUCH_MOVE | 指が画面上でスワイプ |
| TOUCH_END | 指が画面から離れる |
| TOUCH_CANCEL | タッチがシステムによってキャンセル(着信中断など) |
リスン方式はnode.on(Node.EventType.{イベントタイプ}, callback, target)です。破棄時はnode.off()でリスンをキャンセルし、メモリリークを避けます。これらの詳細はテンプレートに反映されており、AIは規範に従ってコードを生成します。
5つの実戦プロンプトテンプレート
前章ではシーン四要素、ノードツリーJSON、コンポーネント記述テンプレート、インタラクション五要素公式を説明しました。この四つのメソドロジーをプロンプトに落とし込むには、標準的な形式が必要です。ここでは、シーン作成、ノード作成、インタラクション実装、スクリプト作成、パフォーマンス最適化の五つのシナリオをカバーする、直接コピーして使用できる5つのテンプレートを提供します。
テンプレート1:完全なシーンを作成
【役割】あなたはCocos Creator開発エキスパートで、TypeScriptとノードコンポーネントアーキテクチャに精通しています。
【タスク】以下のゲームシーンの完全なコードを作成する。
【シーン記述】
シーンタイプ:{タイプ}
ビジュアルスタイル:{スタイル}
核心要素:{ノードリスト}
インタラクションポイント:{インタラクションリスト}
【ノードツリー構造】
```json
{ノードツリー JSON}
【技術要件】
- エンジン:Cocos Creator 3.8
- 言語:TypeScript、@ccclassデコレータを使用
- API:Cocos Creator公式APIを使用(node.getComponent、node.onなど)
【出力要件】
- シーンコード(完全なノード作成ロジック)
- スクリプトコード(型注釈とコメントを含む)
- イベントリスンコード(インタラクションロジック)
### テンプレート2:ノードを作成しコンポーネントをマウント
【役割】Cocos Creator TypeScript開発者
【タスク】{ノード名}ノードを作成し、{コンポーネントリスト}コンポーネントをマウント
【ノード属性】
- 名前:{nodeName}
- 位置:({x}, {y})
- サイズ:{width}x{height}
- アンカー:({anchorX}, {anchorY})
【コンポーネント設定】
- {コンポーネント名}:
- {属性}:{値}
- {コンポーネント名}:
- {属性}:{値}
【出力要件】
- TypeScriptコード、型注釈を含む
- Cocos Creator 3.8 APIを使用
- 各行のコードに説明する日本語コメントを追加
### テンプレート3:インタラクションロジックを実装
【役割】Cocos Creatorイベントシステムエキスパート
【タスク】以下のインタラクションロジックを実装
【インタラクション記述】
トリガー条件:{トリガー条件}
イベントタイプ:{イベントタイプ}
ターゲットオブジェクト:{ノード名}
レスポンス動作:{メソッド名}
状態変化:{変化記述}
【技術的制約】
- node.onでイベントをリスン
- イベントタイプはNode.EventType列挙を使用
- コールバック関数はeventパラメータを含む
- 破棄時はnode.offでリスンをキャンセル
【出力要件】
- TypeScriptコード
- 完全なリスン、コールバック、破棄ロジックを含む
- エラー処理を追加(ノードが存在しない、コンポーネントが欠落)
### テンプレート4:スクリプトコンポーネントを作成
【役割】Cocos Creatorスクリプト開発エキスパート
【タスク】{スクリプト名}スクリプトコンポーネントを作成
【スクリプト機能】
{機能記述}
【属性定義】
@property({タイプ})
{属性名}:{タイプ} = {デフォルト値}
【メソッドリスト】
- {メソッド名}({パラメータ}):{戻り値タイプ}
- 機能:{記述}
- {メソッド名}({パラメータ}):{戻り値タイプ}
- 機能:{記述}
【ライフサイクル】
- onLoad:{初期化ロジック}
- start:{開始ロジック}
- update(dt):{毎フレーム更新ロジック}
【出力要件】
- TypeScriptコード、@ccclassと@propertyデコレータを使用
- 完全なライフサイクルメソッドを含む
- 型注釈と日本語コメントを追加
### テンプレート5:ノードツリーのパフォーマンスを最適化
【役割】Cocos Creatorパフォーマンス最適化エキスパート
【タスク】以下のノードツリー構造のパフォーマンスを最適化
【現在のノードツリー】
{ノードツリー JSON}
【パフォーマンス問題】
- ノード数が多すぎる:{数量}
- DrawCallが高すぎる:{回数}
- メモリ使用量が大きすぎる:{サイズ}
【最適化目標】
- FPS:≥ 60
- DrawCall:≤ 20
- メモリ:≤ 100MB
【最適化戦略】
- ノード統合:{統合案}
- ノードプール使用:{再利用案}
- コンポーネント最適化:{コンポーネント最適化案}
【出力要件】
- 最適化後のノードツリーJSON
- TypeScript最適化コード
- パフォーマンス比較データ(最適化前 vs 最適化後)
この五つのテンプレートは、AIゲーム開発の完全なプロセスをカバーしています:シーン作成からノードマウント、インタラクション実装、スクリプト作成、最後にパフォーマンス最適化まで。各テンプレートはCREATEフレームワークに従っています:Context(役割設定)、Action(タスク記述)、Edge(技術的制約、パフォーマンス指標)、Example(ノードツリーJSON例)。
使用時は、テンプレートを直接コピーして`{}`の内容を置換してください。例えばテンプレート2で、Playerノードを作成する場合、`{nodeName}`を`Player`に、`{コンポーネントリスト}`を`Sprite, RigidBody2D, PlayerScript`に、属性は実際のニーズに従って記入します。AIはテンプレートに従って完全なコードを生成し、ゼロからプロンプトを書く時間を節約できます。
## まとめ
この記事では四つのメソドロジーと五つの実戦テンプレートを説明しました。核心ポイントを振り返りましょう。
**シーン記述四要素**:タイプ、スタイル、要素、インタラクションポイント。まずシーンの骨格を決定し、それからコンテンツを埋めます。AIが構造の完全なレベルを生成します。
**ノードツリーJSON形式**:ルートノード → 子ノード → コンポーネント → 属性 → 位置。構造化形式で階層関係を記述し、AIはツリー構造に従ってノードを階層ごとに作成し、親子関係を間違えません。
**コンポーネント記述四フィールド**:機能、属性、依存、サンプル設定。まず用途を説明し、次にパラメータをリストし、最後に前提条件を説明し、AIはこの構造に従ってコンポーネントマウントコードを生成します。
**インタラクション記述五要素**:トリガー条件、イベントタイプ、ターゲットオブジェクト、レスポンス動作、状態変化。五つの要素が完全なクローズドループを形成し、AIが生成するコードには漏れがありません。
この四つのメソドロジーをプロンプトに落とし込み、五つの実戦テンプレートで表現します:シーン作成、ノード作成、インタラクション実装、スクリプト作成、パフォーマンス最適化。テンプレートはCREATEフレームワークに従い、直接コピーして`{}`の内容を置換するだけで使えます。
次回AIにゲーム要件を記述する際、JSON形式でノードツリーを記述し、五要素公式でインタラクションロジックを記述してみてください。前後の効果を比較してください:曖昧な記述が生成するコードは断片的で、階層が混乱し、インタラクションが欠落しています。標準化された記述が生成するコードは構造が完全で、階層が明確で、インタラクションがクローズドループです。効率の向上は実感できるものです。 7 min read · 公開日: 2026年5月23日 · 更新日: 2026年5月25日
AI と Cocos 小ゲーム開発実践
検索からこのページに来た場合は、前後の記事もあわせて読むと同じテーマの理解がかなり早く深まります。
前の記事
AIを活用したCocos小游戏開発:完全ワークフローと効率比較
AIを活用したCocos小游戏開発の完全ワークフローを紹介。ツール選択マトリックス、5つのフェーズの実践経験、効率比較データを含む。企画からリリースまで3日で完了、効率10倍向上。
第 13 / 18 記事
次の記事
インディーズゲーム開発:AIに任せるべきタスクと自分で判断すべきこと
インディーズゲーム開発者がどのタスクをAIに任せ、何を自分で管理すべきかをどう判断するか?本記事では、コード生成、アート制作からクリエイティブな意思決定まで、AI協力の完全な認知マップを構築するための明確な判断フレームワークを提供します。
第 15 / 18 記事
関連記事
インディーゲーム開発:まずゲームプレイを検証し、それからシステムを構築する(MVP実践ガイド)
インディーゲーム開発:まずゲームプレイを検証し、それからシステムを構築する(MVP実践ガイド)
ミニゲームのステートマシン設計:ホーム画面から戦闘、決算までの完全な流れ
ミニゲームのステートマシン設計:ホーム画面から戦闘、決算までの完全な流れ
AI で Cocos シーン説明書を生成:コードアシスタントにゲームを理解させる方法
コメント
GitHubアカウントでログインしてコメントできます