ebitengine-game

Ebitengine ゲーム

依頼された範囲に合わせて、分かりやすく、操作への反応がよく、完成度の高いゲームを制作してください。1つの依頼の中で、内部的にビルド、プレイ、改良の工程を複数回行う場合があります。骨組み、ビルドの成功、魅力的なスクリーンショットだけでは、ゲームが完成したことにはなりません。特定の修正を行う場合は、プロジェクトのデザインを維持し、対象の動作にワークフローを限定してください。

同梱のスターターは Ebitengine v2.10.5 / Go 1.25+ を対象としています。これは固定されたベースラインであり、最新リリースを示すものではありません。アップグレードが必要で、かつ許可されている場合を除き、既存プロジェクトのバージョンを維持してください。新しい API や実験的な API を使用する前に、固定バージョンの公開 API を確認してください。リファレンスには応用可能なパターンが記載されていますが、実行可能な成果物は同梱のスクリプトとスターターのみです。これらのチェックですべてのリファレンスのコード例が検証されるわけではありません。

納品ワークフロー

1. 確認して方針を決めます。 リポジトリの指示、go.mod、RunGame のエントリーポイント、既存のテストやアセットを確認します。新しいゲームの場合は、デザインと品質を読みます。プレイヤーの目標、繰り返される判断、その結果、終了や再挑戦の方法、意図する見た目、プラットフォーム、対応する入力を明確にします。妥当な既定値を推定し、製品を大きく左右する選択肢が不足している場合に限り、質問してください。短い概要と、プロジェクト内で確認可能な受け入れ基準を記録します。
2. 代表的なプレイ可能部分を作ります。 中心となる操作とそのフィードバックを、想定される操作方法とビジュアル方針で機能させます。コンテンツを増やす前に、操作感を確認します。完成できる範囲にスコープを収め、テンプレートではなくゲームに合った方法で、手作りまたはプロシージャルなコンテンツを選びます。レベルを増やす前に、実際のプレイヤーの能力に合わせてコンテンツを調整します。アートセットでは、アセットとアニメーションを参考に、視点、スケール、基準位置、パレットの役割を統一します。
3. 完成させて改良します。 約束した「開始 → プレイ → 結果 → 再挑戦／続行」のループ（または、適切な永続型／サンドボックス型のループ）を実装します。階層、アニメーション、サウンド、難易度、トランジションを実際のゲーム内で調整します。選んだシステムに必要な技術リファレンスだけを読みます。発見した不具合は、ユーザーに反復作業を求めず、この納品作業中に修正します。
4. 製品を検証します。 ルールと重要なトランジションをテストし、実際の入力を試し、代表的な描画状態を確認して、指定されたターゲットをビルド／実行します。失敗時や再挑戦時のケース、境界ケースも含めます。スクリプトによるデモでは操作感を確かめられず、無音のオーディオ出力先ではサウンドの品質を確かめられません。自動化された複数ステップの操作では、観測画像を同じティック時点の実際の状態と照合してください。詳しくはプレイテストの診断を参照してください。
5. 引き継ぎます。 起動／ビルド手順、実際の成果物のパス、アセットのライセンスを提示します。実行して確認した内容、未検証の内容、重要な制限事項を明記します。公開、購入、外部へのアップロードは、ユーザーの依頼範囲に含まれる場合に限り、別途行う作業です。

プロジェクトの開始

コマンドはゲームの作業ディレクトリではなく、このスキルのディレクトリを基準に解決します。skill_dir に実際にインストールされた場所を設定し、たとえば次のようにします。

python3 "$skill_dir/scripts/new_game.py" --out mygame \
  --module example.com/mygame --title "My Game"
cd mygame
go mod tidy
go test ./world/...

スターターは、小規模なプラットフォーマーを通じて、シーン、アクション入力、テキスト、サウンド、カメラ、一時停止、スクリプトによるキャプチャを実演します。これは統合例であり、ジャンルやアーキテクチャを指定するものではありません。概要に合わせてルール、操作方法、レベル、演出、シーンの流れを置き換えてください。パズルゲームやカードゲームに、重力、ジャンプ、カメラのスクロール、プラットフォーマー用 HUD を引き継がせないでください。既存のプロジェクトで骨組みが必要になることはほとんどありません。--ci はワークフローとツールを追加します。有効にする前に、そのトリガー、ターゲット、リリース時の動作を確認してください。

ループとリソースの契約

メソッド	責務	重要な違い
Update() error	アクションをサンプリングし、シミュレーションを進め、シーンの変更を適用し、イベント音声を再生します	デフォルトの目標は毎秒60回の固定ティックです。キャッチアップ更新、フォーカス時の一時停止、低速なマシンは、実際のスケジュールに影響します。
Draw(screen *ebiten.Image)	更新によって生成された状態を描画します	呼び出しとティックは1対1で対応するわけではありません。ここでゲームプレイを進めたり、入力のエッジを消費したり、サウンドを再生したりしないでください。レンダラーが所有するキャッシュはシミュレーション状態とは別です。
Layout(outsideW, outsideH int) (int, int)	描画と入力に使う論理サイズを決定します	固定デザインとレスポンシブデザインのどちらも有効です。小さなウィンドウ、アスペクト比、読みやすさを考慮してください。

• シミュレーションの時間はティックで表すか、明示的な固定 dt を使用してください。60 TPSでは、30ティックはシミュレーション時間で0.5秒です。ActualTPS は診断用であり、 デルタではありません。SetTPS は更新クロック全体を変更するもので、汎用的な スローモーション制御ではありません。固定ステップが必要なルールでは SyncWithFPS を避けてください。
• 正常に停止するには、Update から ebiten.Termination を返してください。それ以外のエラーは RunGame から返されます。失敗を隠さず、伝播させてください。
• 画像とフォントのソースは一度だけ読み込み／デコードし、オフスクリーンやホットパスの スライスは再利用してください。プーリングや割り当てゼロのルールを一般化する前に、 プロファイルを取得してください。
• テスト可能になる場合は、ルールをデバイス／GPU コードから分離してください。小規模な ゲームに、必要もないのに ECS、シーンスタック、サービスレイヤーを追加する必要はありません。

Ebitengine で重要な選択

• 入力： Update でデバイス入力をアクションに割り当てます。押下中／押下／解放を区別し、 アクションのエッジを計算する前にバインディングをまとめることが意図した動作であれば、 そのようにしてください。標準のゲームパッドマッピングでは、利用可能かどうかの確認と スティックのデッドゾーン設定が必要です。メニューやリトライでも、告知されている デバイスが使えることを確認してください。 入力。
• 描画： GeoM の操作は呼び出し順に適用されます。ピクセルアートには意図的な サンプリング／スケーリングが必要です。滑らかなアートには適切なフィルタリングと アンチエイリアス処理されたジオメトリが必要です。バッチ処理中もレイヤー順を維持してください。 同じシートを共有しても、コマンドが1つになるとは限りません。画面全体に独自の 変換を適用する場合は、ポインターの変換も一致させてください。 描画。
• テキスト／UI： 既存のビットマップ／アトラスによるテキスト描画方式が適切であれば、 そのまま維持してください。新たにアウトラインフォントのコードを書く場合は、 text/v2 を使用し、フォントのソースを一度だけ解析してください。リリース対象の文字体系を カバーするフォントと、そのライセンスを含めてください。実際の文字列のサイズを測定し、 フォーカス、長文、対象サイズでの読みやすさを確認してください。 テキスト／UI。
• 音声： プロセスごとに audio.Context は1つにしてください。サンプルレートと PCM 形式を 一致させてください。DecodeF32 はリサンプリングを行わず、DecodeWithSampleRate は 16ビット PCM を返します。効果音を重ねて再生するには、個別のプレーヤーかボイスプールが 必要です。イベントが密集する場合は、同時実行数に上限を設けてください。ブラウザーでは、 ユーザー操作の後に音声を再開してください。 音声。
• システム： トゥイーン、パーティクル、画面揺れ、物理演算、マップローダーは、 中心となるインタラクションを支える任意のツールです。 ゲームプレイシステム。
• 状態： 外部コールバックはキューに入れて Update で処理し、リセット／リトライで 状態を確実にクリアし、ゲームプレイ用と演出用の乱数を分離してください。永続化を 提供する場合は、セーブをテストしてください。 アーキテクチャ／テスト。

検証

ゲームディレクトリからコマンドを実行し、go.mod と go.sum は保持してください。リポジトリのビルドフラグを使用してください。以下の -buildvcs=false は、周囲の Git メタデータへの依存を避けるためのものです。

go vet ./...
go test ./world/...   # starter's GPU-independent rules
python3 "$skill_dir/scripts/check_ebitengine.py" .
go build -buildvcs=false -o game .

ループ／入力／オーディオのコードを変更した後、または古い API を確認する際は、チェッカーを実行してください。これは読み取り専用のテキストベースの参考スキャンです。警告は文脈を踏まえて確認してください。--json は共通のチェッカースキーマを返し、--strict は警告があると失敗します。また、--max-issues N は合計数を変えずにレポートを制限します。非推奨 API は警告であり、ビルドが壊れている証拠ではありません。問題のない結果であっても、API の正しさや品質が証明されるわけではありません。関連する他のパッケージテストも実行してください。Linux では、グラフィックスを初期化するテストに xvfb-run -a が必要です。

スターターでは、-demo -shot frame.png -shot-tick 240 を指定してキャプチャしてください。Linux では、仮想ディスプレイを使用し、必要に応じて HOME を変更せずに null オーディオを使用してください。

audio_config=$(mktemp)
printf 'pcm.!default { type null }\n' > "$audio_config"
ALSA_CONFIG_PATH="$audio_config" xvfb-run -a ./game \
  -demo -shot frame.png -shot-tick 240
rm "$audio_config"

PNG を開いてください。必要に応じて、最初のプレイ、忙しい／難しい場面、失敗、結果など、ほかの状態も確認してください。ゲームを変更した後は、スクリプト化した操作やキャプチャポイントを調整してください。テンプレートのデモは、異なるループの動作を証明するものではなくなります。より詳細な入力／リプレイテストには、v2.10 のオプトイン VM が役立つ場合があります（アーキテクチャとテストを参照）。

約束したターゲットのみをビルドしてください。例：

GOOS=windows GOARCH=amd64 go build -buildvcs=false -o game.exe .
GOOS=js GOARCH=wasm go build -buildvcs=false -o game.wasm .

クロスコンパイルで確認できるのはビルド可能性であり、実行時のサポートではありません。ブラウザ向けビルドは HTTP 経由で実行し、それが対象の場合はコンソール／入力／オーディオを確認してください。ネイティブ SDK、ストア連携、cgo 依存関係には、Ebitengine の純粋な Go によるデスクトップバックエンド以上の要件が加わる場合があります。

このカタログ内での組み合わせ

このスキルは Ebitengine／Go API を担当します。移植可能な設計上の懸念については、関連する導入済みの専門スキル（たとえば game-ui-ux、game-feel、create-game-assets、save-systems）、ジャンル、またはリリースワークフローと組み合わせてください。エンジンの各要素は、別のエンジンのサンプルコードではなく、このスキルのリファレンスに対応付けてください。タスクに必要なものだけを読み込んでください。このフォルダー全体を単独で使用することもできます。

必要に応じて読む

• 設計と品質：企画概要、ジャンルの選択、ゲームループ全体、表現、プレイテストの合格基準。新規ゲームや再設計の場合に参照してください。
• プロジェクトとビルド：デスクトップ、WASM、モバイル。
• レンダリング、入力、 テキスト／UI、オーディオ。
• アセットとアニメーション：アートセットの作成またはインポート時に参照してください。共通のビジュアルルール、スケール、ピボット、スプライトシートの QA を扱います。
• プレイテストの診断：操作のスクリプト化や失敗の再現時に参照してください。制御されたティック、状態／画像による証拠を扱います。
• アーキテクチャとテストと ゲームプレイシステム：状態、セーブ、アニメーション、衝突、任意の剛体について説明します。Tiled マップが扱うのは、ゲームで Tiled を使用する場合の、制約付きローダーのみです。
• ネットワーキング：オンラインプレイが求められている場合に限ります。
• 公開／プラットフォーム、 収益化、CI／リリース： 配布／連携作業が求められている場合に限ります。

利用できる場合、Ebitengine のリポジトリスキルである writing-kage-shaders と run-ebitengine-app-headless は、バージョン固有の高度なワークフローを提供します。ほかのゲーム設計／ストア関連スキルは任意の補助として利用できます。このスキルは、外部のスキルカタログがなくても使用できます。