game-development

ゲーム開発

ユーザーが求めた体験を、指定された規模で構築します。プロジェクトのエンジン、操作方法、スタイル、無関係な作業は維持してください。プロトタイプはプロトタイプのままで構いませんが、完成版のゲームには、求められたコンテンツ、進行、失敗、リトライの導線が必要です。

ゲームを理解してから構築する

新しいゲームや大幅なゲームプレイの再設計を行う場合は、類似ゲームを少なくとも2つ調査します。説明文、トレーラー、検索結果の抜粋だけに頼らず、関連するゲームプレイを視聴するか、プレイ可能なデモを調べてください。プレイヤーの行動、タイミング、フィードバック、難易度、ミスからの復帰方法を確認します。実装の詳細が不明な場合は、関連するエンジンのドキュメントを読みます。

参照元、映像のタイムスタンプやプレイした場面、観察事項、それらを根拠とする判断を簡潔に記録します。デザインを提案する前に、両方の例を実際に確認したことを確かめてください。関連性が高く短い映像や、アクセスしやすいデモを優先します。取得に失敗した場合は、別の情報源と、ブラウザーや直接ダウンロードなど利用可能な別のアクセス方法を試してください。サンドボックスによって操作がブロックされた場合は、通常の承認手順を利用します。あるツールのネットワークエラーだけで、調査ができないと判断してはいけません。代替手段もブロックされた場合は、確認できなかった情報を説明します。現在のプロジェクトに関する既存の調査は再利用します。確立されたデザインのバグ修正や小規模な追加では、新たな調査プロジェクトではなく、焦点を絞った再現と確認を行います。

主要なアクション、目的、課題、報酬、操作方法、プレイ開始から最初の1分間の流れを定義します。まずコアとなるインタラクションを実装し、周辺を作り込む前にプレイして確認します。観察した挙動に基づいて調整します。流用したタイミングの値は出発点であり、普遍的なルールではありません。デザインのみを求められた場合は、依頼された提案を示し、参照から確認したことと、未検証のアイデアを区別します。

求められた体験を構築する

アクションを分かりやすく、すばやく反応するものにします。ゲームプレイ、アニメーション、カメラ、サウンド、インターフェースのフィードバックを連動させ、プレイヤーが何が起きたか分かるようにします。エフェクトは過剰にならないようにし、必ず元の状態に戻るようにします。必要な入力方法を実装し、該当する場合は一時停止、失敗、リトライ、クリアへの明確な手段を用意します。

既存のアーキテクチャを使い、要件に対応できる最もシンプルな実装を選びます。シミュレーション、移動、プロシージャル生成のワールド、永続化、パフォーマンスに関わる変更を行う場合に限り、技術的なチェックを読みます。

利用可能な場合は、アセットにはgame-development-asset-generationを、メニューやHUDにはresearch-backed-frontend-developmentを使用します。それらの調査を再利用し、重複して調査しないようにします。開発中にプレゼンテーションを組み込み、ゲームプレイ時のサイズと動作中の状態で確認します。意図的なプレースホルダーの範囲は維持し、完成した作品を納品する際には仮素材を置き換えます。

プレイして確認し、修正する

実際のキーボード、ポインター、タッチ、コントローラー入力を使って、影響を受ける一連の操作を試します。ゲームプレイ関数を直接呼び出しても、入力経路のテストにはなりません。結果を確認します。攻撃を受けると体力が変化し、敗北すると状態が変わり、リトライすると再びプレイ可能なゲームに戻る必要があります。到達しにくい状態には再現可能なフィクスチャを使いますが、そこに至る遷移もテストします。

プレイ時のスクリーンショットや録画を実際に見て、ログを確認し、問題が見つかったら修正してから、該当するシナリオをもう一度プレイします。視認性、カメラの構図、当たり判定、フィードバック、関連する画面サイズを確認します。既存のテストを使い、失敗を検出できる場合は、対象を絞った回帰テストを追加します。ビルドが成功しただけでは、ゲームプレイが正しいとは確認できません。

ブラウザーやプレビューを操作する前にpolite-browser-useを適用し、録画には利用可能な場合view-videoを適用します。求められた挙動と関連するチェックに合格したら完了です。それができない場合は、具体的な阻害要因を説明します。プレイして確認した内容と、未検証の点を報告します。依頼されていない限り、ゲームを公開またはアップロードしないでください。