Skip to content

warau-uichi/ichigeki

BranchesTags

Repository files navigation

イチゲキーン - 実装ToDoリスト (Progress)

このドキュメントは、「イチゲキーン」ゲーム開発の進捗を追跡するための詳細なToDoリストです。

I. プロジェクトセットアップと基本環境 (Project Setup & Basic Environment)

  • Gitリポジトリの初期化 (git init)
  • 基本プロジェクト構造の作成 (src (ゲームコード用)、docs、tests、assets (リソースファイル用 .pyxres 格納想定) フォルダなど)
  • Python仮想環境のセットアップ (uv venv または python -m venv .venv を推奨)
  • 作成した仮想環境フォルダ (.venv など) を .gitignore に追加
  • pyproject.toml の作成と基本情報 (プロジェクト名「イチゲキーン」、バージョン「0.1.0」、Python要件「>=3.9」など) の記述 (PEP 621 準拠)
  • 初期依存パッケージのインストール (uv pip install pyxel ruff coverage または pip install pyxel ruff coverage) と pyproject.toml への記録 (または requirements.txt の作成と更新)
  • Ruff の設定 (pyproject.toml 内または ruff.toml): PEP 8準拠、行長制限 (例: 88文字または99文字)、使用ルールセット設定 (例: select = ["E", "F", "W", "I", "UP", "PL"])
  • .gitignore ファイルの作成 (Python (__pycache__/, *.pyc), Pyxel (*.pyxres.lock), OS固有ファイル (.DS_Store など) を含む)
  • GitHub Actions: CIワークフローファイルの雛形作成 (.github/workflows/ci.yml)
    • Pythonセットアップのステップ (使用するPythonバージョンを指定)
    • uv (または pip) による依存パッケージインストールのステップ
    • Ruff (lint & format check) のステップ
    • unittest 実行のステップ (初期はスタブでも可)

II. ゲームエンジンの初期設定と基本表示 (Game Engine Init & Basic Display) - (GAME_SPEC Stage 1準拠)

  • Pyxel初期化処理の実装 (pyxel.init): 画面サイズ (256x192), FPS (30), ウィンドウタイトル「イチゲキーン」
  • メインゲームループ (update, draw 関数、pyxel.run) の基本構造作成 (例: src/main.py に配置)
  • Pyxelリソースファイル (assets/game.pyxres など) の作成 (Pyxel Editorを使用) とプロジェクトへのロード設定 (pyxel.load("assets/game.pyxres"))
  • プレースホルダープレイヤー1スプライトの作成 (Pyxel Editorで単色矩形など) と .pyxres のイメージバンク0に保存
  • プレイヤー1を画面中央付近に描画する処理 (pyxel.blt)
  • プレイヤー1の基本的な左右移動ロジック (キー入力: pyxel.KEY_A (左), pyxel.KEY_D (右), pyxel.btn() を使用)
  • プレイヤー1が画面境界を越えないようにする処理 (x座標の値をクランプする)

III. アセット作成 (Asset Creation) - (GAME_SPEC Visual & Audio Style準拠)

  • ステージ関連 (Pyxel Editor):
    • ステージ1のタイルマップデザイン (背景、足場、境界) とPyxel Editorでの作成
    • ステージ背景用タイルセットの作成と .pyxres のタイルマップ0に保存
  • キャラクター関連 (Pyxel Editor):
    • プレイヤーキャラクタースプライトの最終デザインと作成 (16x16ピクセルなど、サイズを統一)
      • アイドル状態 (例: イメージバンク0, u=0, v=0, w=16, h=16)
      • 移動アニメーション (左右、各2-4フレーム程度)
      • 攻撃アニメーション (起動、アクティブ、リカバリの各フェーズが視覚的に分かるフレーム)
      • パリィアニメーション (防御姿勢のフレーム)
      • 被ダメージ/敗北アニメーション (例: のけぞり、消滅エフェクトのコマなど)
      • 勝利ポーズアニメーション (オプション、1-2フレーム)
    • (もしあれば) NPC専用スプライトの作成 (プレイヤーと色違い、または若干異なるデザイン)
    • 作成したスプライトシートを .pyxres のイメージバンクに整理して保存 (例: プレイヤー1はイメージバンク0、プレイヤー2/NPCはイメージバンク1)
  • 武器/エフェクト関連 (Pyxel Editor):
    • 武器スプライトの作成 (キャラクターアニメーションに武器の動きを含めるか、別途描画するかを決定)
    • 攻撃エフェクトスプライト (斬撃、衝撃波など、数フレームのアニメーション)
    • ヒットエフェクトスプライト (火花、打撃感を示すエフェクト)
    • パリィ成功エフェクトスプライト (ガードエフェクト、火花など)
    • 作成したエフェクトスプライトを .pyxres のイメージバンクに保存 (例: イメージバンク2)
  • サウンド関連 (Pyxel Editor):
    • SE: 攻撃音 (剣の振り音、ヒット音 - ヒット音はやや重く鋭い音)
    • SE: パリィ成功音 (金属がぶつかるような「カキン」という音)
    • SE: 被ダメージ音 (うめき声や打撃を受けた鈍い音)
    • SE: 移動音 (歩き、オプションでダッシュ音 - 異なる音質)
    • SE: UI決定音、カーソル移動音、キャンセル音 (それぞれ区別できる短いシステム音)
    • SE: 相打ち発生音 (攻撃ヒット音とは異なる、やや重厚な衝突音)
    • SE: 攻撃失敗ペナルティ発生/解除音 (オプション、状態変化がわかる短い効果音)
    • BGM: タイトル画面用 (ループ可能な短い曲、期待感のある雰囲気 - オプション)
    • BGM: ゲームプレイ中用 (ループ可能な緊張感のある曲、和風またはチップチューン - オプション)
    • 作成したサウンドと音楽を .pyxres のサウンドバンク、ミュージックバンクにそれぞれ保存

IV. コアゲームプレイ実装 (Core Gameplay Implementation) - (GAME_SPEC Stages 2, 3, 4 & 特殊ルール準拠)

  • プレイヤークラス/エンティティの設計と実装 (例: src/player.py):
    • プレイヤーの座標、状態 (アイドル、移動中、攻撃中など定数で管理)、スコア (勝利ラウンド数)、攻撃失敗カウンターなどを保持するクラス Player を作成
    • プレイヤー状態に応じたアニメーション管理ロジック (スプライトのu,v座標やフレーム番号を更新するメソッド)
    • プレイヤーの更新処理メソッド (update) と描画処理メソッド (draw) を実装
  • プレイヤー2の実装:
    • Player クラスのインスタンスとしてプレイヤー2を作成
    • プレイヤー2の描画と左右移動ロジック (キー入力: pyxel.KEY_LEFT (左), pyxel.KEY_RIGHT (右))
    • プレイヤー2が画面境界を越えないようにする処理
  • 攻撃システム:
    • プレイヤー1の攻撃アクション実装 (キー入力: pyxel.KEY_F, pyxel.btnp() を使用し、プレイヤー状態を ATTACKING_STARTUP へ遷移)
    • プレイヤー2の攻撃アクション実装 (キー入力: pyxel.KEY_K, pyxel.btnp() を使用し、プレイヤー状態を ATTACKING_STARTUP へ遷移)
    • 攻撃状態の管理: ATTACKING_STARTUP, ATTACKING_ACTIVE, ATTACKING_RECOVERY の各状態と、それぞれのフレーム数 (持続時間) を定義。タイマーやカウンターで遷移を管理。
    • 攻撃ヒットボックスの定義: 攻撃アニメーションの特定フレーム (アクティブフレーム中) で、プレイヤー位置からの相対座標とサイズでヒットボックス矩形を計算するロジック。
    • キャラクターハートボックス (被ダメージ判定エリア) の定義: プレイヤーの現在のスプライト位置を基準とした固定の矩形。
    • 攻撃ヒットボックスと相手ハートボックスの衝突判定 (AABB: Axis-Aligned Bounding Box) ロジックを実装。
    • ヒット時の処理: 攻撃がヒットした場合、被ダメージ側は敗北状態 (DEFEATED) へ遷移。攻撃側はリカバリー状態 (ATTACKING_RECOVERY) へ。
  • パリィシステム:
    • プレイヤー1のパリィアクション実装 (キー入力: pyxel.KEY_S, pyxel.btnp() を使用し、プレイヤー状態を PARRYING へ遷移)
    • プレイヤー2のパリィアクション実装 (キー入力: pyxel.KEY_DOWN, pyxel.btnp() を使用し、プレイヤー状態を PARRYING へ遷移)
    • パリィ状態の管理: パリィのアクティブフレーム数を定義し、タイマーで管理。
    • パリィ判定ロジック: パリィアクティブ中に、相手の攻撃ヒットボックスと自身のキャラクターが定義するパリィ判定用矩形 (ハートボックスより広い場合もある) との衝突を判定。
    • パリィ成功時の効果: 相手の攻撃を無効化し、相手プレイヤーを一定時間硬直状態 (例: STUNNED 状態、数フレーム行動不能) にする。
  • 一撃必殺とラウンド管理:
    • ヒット＝ラウンド終了のロジックを実装。
    • ラウンドカウンターと各プレイヤーのスコア (勝利ラウンド数) をグローバルまたはゲーム管理クラスで管理。
    • ラウンド開始時のプレイヤー位置リセット、状態リセット (IDLE)、攻撃失敗カウンターリセット処理。
    • 試合勝利条件 (例: 設定ラウンド数先取、例: 3ラウンド中2本先取) の判定ロジック。
  • 特殊ルール・ペナルティ:
    • 攻撃失敗ペナルティのロジック実装:
      • 各プレイヤーの連続攻撃失敗カウンターを Player クラス内などで管理。
      • 攻撃アクションが終了 (リカバリー状態完了) した際に、ヒットフラグが立っていなければカウンターを増加させる。
      • 攻撃がヒットした場合はカウンターを0にリセットする。
      • カウンターが3に達した場合、該当プレイヤーの移動速度に関連するパラメータを一定時間変更する (例: is_penalty_active フラグとペナルティ解除タイマーを設定)。
      • ペナルティ解除ロジック (タイマー経過で移動速度パラメータを元に戻す)。
  • 相打ち処理:
    • 同時ヒット (両者の攻撃が同じフレームでお互いのハートボックスにヒット) の判定ロジック。
    • 相打ち発生時の処理: ラウンド引き分けとして扱い、両者のスコアは変更せず、プレイヤー位置と状態をリセットしてラウンドを再開。

V. NPC対戦モード実装 (NPC Battle Mode Implementation) - (GAME_SPEC Stage 5準拠)

  • NPCの基本AIロジック実装 (例: src/npc_ai.py にAIロジック関数群、または Player クラスを継承した NPCPlayer クラスを作成)
    • NPCの移動パターン: プレイヤーとのX座標の差を測り、一定距離を保つように左右に移動。時折ランダムな移動を挟む。
    • NPCの攻撃トリガー条件: プレイヤーがNPCの特定範囲内に入り、かつプレイヤーが攻撃中でない場合に、一定の確率で攻撃を実行。
    • NPCのパリィ試行ロジック: プレイヤーが攻撃モーション (スタートアップ状態) に入ったのを検知し、一定の確率または計算されたタイミングでパリィを実行。
    • (オプション) CPUの強さの段階分けの基礎: AIの反応速度、攻撃頻度、パリィ成功率などのパラメータを調整できるように設計。
  • NPC対戦モード選択時、プレイヤー2の入力処理を無効化し、代わりにNPCのAIロジックがプレイヤー2のインスタンスを操作するように update ループを修正。

VI. UIとゲームフロー実装 (UI & Game Flow Implementation) - (GAME_SPEC Stage 6準拠)

  • ゲーム状態管理システムの設計と実装 (例: src/game_manager.py に GameState Enumと現在のゲーム状態を保持する変数を定義。main.py で状態に応じた update_xxx, draw_xxx 関数を呼び出す構造)
    • STATE_TITLE (タイトル画面)
    • STATE_GAMEPLAY (ゲームプレイ中)
    • STATE_ROUND_OVER (ラウンド終了時)
    • STATE_GAME_OVER (試合終了時)
    • (オプション) STATE_CHARACTER_SELECT (キャラクター選択 - 将来拡張用だが、ステートの枠組みは用意)
    • (オプション) STATE_PAUSE (ポーズ画面)
  • タイトル画面 (update_title, draw_title 関数の実装):
    • 「イチゲキーン」タイトルロゴまたはテキストを画面中央に表示 (pyxel.text または pyxel.blt)
    • 「2P対戦 (Press Key_P1_Attack)」と「NPC対戦 (Press Key_P2_Attack)」モード選択UIをテキストで表示。
    • プレイヤー1の攻撃キー (F) で2P対戦開始、プレイヤー2の攻撃キー (K) でNPC対戦開始など、入力に応じたゲーム状態遷移 (STATE_GAMEPLAY へ) とゲームモードフラグの設定。
  • ゲームプレイ画面UI (既存の draw 関数内または draw_gameplay 関数の拡充):
    • スコア表示: 各プレイヤーの勝利ラウンド数を星や数字で画面上部 (例: P1は左上、P2は右上) に表示。
    • ラウンド開始/終了メッセージ表示: "Round X", "Fight!", "Player 1 Wins!", "Player 2 Wins!", "Draw Game!", "Ippon!" などのメッセージを画面中央に一定時間表示するロジック。
    • (オプション) ヒット確認テキスト「K.O.!」や「一本！」の表示 (ヒット時に短時間表示)。
  • ラウンドオーバー画面 (update_round_over, draw_round_over 関数の実装):
    • ラウンド勝者 (または相打ち) のメッセージを画面中央に表示。
    • 一定時間表示後、または決定キー入力待ちで次のラウンド (STATE_GAMEPLAY) または試合終了 (STATE_GAME_OVER) へ遷移。
  • ゲームオーバー画面 (update_game_over, draw_game_over 関数の実装):
    • 試合勝者 ("Player X WINS THE MATCH!") の最終表示。
    • 「Press Attack to Return to Title」など、タイトル画面へ戻るオプションと入力処理 (STATE_TITLE へ遷移)。
  • (オプション) ポーズ機能 (pyxel.KEY_ESCAPEなどで STATE_PAUSE へ遷移) とポーズ画面UI (update_pause, draw_pause)
    • 「PAUSE」表示。
    • 「ゲーム再開 (Resume)」「タイトルへ戻る (Quit to Title)」選択肢と操作。

VII. テストの実装 (Test Implementation)

  • unittest を用いたテストディレクトリ (tests/) とテストファイルの基本構造設定 (例: tests/test_player.py, tests/test_game_logic.py, tests/test_collision.py)。
  • コアロジックのユニットテスト作成:
    • プレイヤーの移動と画面境界処理のテストケース (境界値テストを含む)。
    • 攻撃とパリィの基本的な状態遷移テスト (正しい入力で正しい状態に変わるか)。
    • 衝突判定ロジックのテスト (AABB関数が正しく矩形の重なりを判定できるか、具体的な座標値でテスト)。
    • 状態管理 (プレイヤー状態、ゲーム状態) の遷移テスト (特定の入力や条件での状態変化をシミュレート)。
    • ラウンド管理・スコア計算ロジックのテスト (ラウンド勝利時のスコア加算、試合勝利条件判定など)。
    • 特殊ルール (攻撃失敗ペナルティ) の適用条件と効果のテスト (カウンターの増減、速度変化の確認)。
    • 相打ち判定ロジックのテスト。
  • coverage.py の設定と実行 (coverage run -m unittest discover tests, coverage report -m)、カバレッジレポートの確認 (目標80%など)。
  • GitHub Actions: CIワークフローに coverage レポート生成・アップロード (Codecovなどへの連携、またはアーティファクトとしての保存) ステップを追加。

VIII. ドキュメントと最終調整 (Documentation & Final Adjustments) - (GAME_SPEC Stage 7準拠)

  • GAME_SPEC.md の最終確認と更新 (実装内容との整合性チェック、特に開発段階で変更が生じたルールの反映)。
  • docs/TECHNICAL_REQUIREMENTS.md の最終確認と更新 (使用ライブラリやツールの最終的なバージョン固定、開発中に判明した技術的課題や解決策の追記など)。
  • コード内コメント (docstrings: クラス、メソッド、関数の説明) の整備 (PEP 257準拠)。読み手が理解しやすいように、引数、戻り値、処理内容を記述。
  • (オプション) SphinxによるHTMLドキュメントのセットアップと生成
    • docs/source ディレクトリ作成と conf.py 基本設定 (sphinx-quickstart を使用)。
    • myst_parser 拡張機能の追加 (conf.py の extensions リストに)。
    • sphinx.ext.autodoc, sphinx.ext.napoleon (Google/NumPyスタイルdocstring対応) 拡張機能の設定。
    • 主要モジュールやクラスの .rst または .md ファイルを作成し、automodule や autoclass ディレクティブでdocstringからドキュメントを生成。
  • GitHub Actions: (オプション) Sphinxドキュメント生成とGitHub Pagesへのデプロイワークフローの追加。
  • ゲームバランスの最終調整 (キャラクターの移動速度、攻撃の発生/持続/硬直フレーム、パリィの受付時間、NPCの強さの各段階など) をテストプレイを通じて実施。
  • 発見されたバグの修正と全体的なブラッシュアップ (操作感の向上、視覚的フィードバックの改善など)。
  • リリース準備 (バージョン番号更新 (pyproject.toml やドキュメント内)、README.md の作成/更新 - ゲーム概要、操作方法、実行方法、貢献方法などを記載)。

このToDoリストは、GAME_SPEC.mdのステージ区分を参考にしつつ、技術的なセットアップから具体的なゲーム機能の実装、テスト、ドキュメント作成までを網羅するように構成しました。各項目は、実際の開発でタスクとして管理しやすいように、ある程度具体的なアクションを示しています。オプション項目も残してありますが、プロジェクトのスコープや期間に応じて取捨選択してください。

Docker開発環境セットアップ

概要

このプロジェクトでは、開発環境の差異を吸収し、セットアップを簡略化するためにDockerおよびDocker Composeを利用できます。 Dockerfile にてPython、Pyxel、uvおよびその他の必要なライブラリが導入された開発イメージを定義し、docker-compose.yml でそのイメージを使用したコンテナのビルドと実行を管理します。

前提条件

  • Docker がインストールされていること。
  • Docker Compose がインストールされていること (Docker Desktopには通常含まれています)。

セットアップ手順

  1. リポジトリのクローン:

    git clone <repository-url>
cd <repository-name>

  2. (ホスト側) X11フォワーディングの許可 (GUI表示のため): PyxelのGUIアプリケーションをDockerコンテナからホストマシンに表示するには、ホスト側でXサーバーへのアクセスを許可する必要があります。ターミナルで以下のコマンドを実行してください。

    xhost +local:docker

    注意: この設定はセキュリティリスクを伴う場合があります。開発目的でのみ使用し、不要になったら xhost -local:docker で元に戻すことを検討してください。また、この設定はXサーバーセッションが終了するとリセットされる場合があります。Wayland環境では別途設定が必要になる場合があります。

  3. Dockerイメージのビルド: プロジェクトのルートディレクトリ（Dockerfile と docker-compose.yml がある場所）で、以下のコマンドを実行してDockerイメージをビルドします。

    docker-compose build

  4. 開発コンテナの起動: イメージのビルドが完了したら、以下のコマンドで開発用コンテナを起動します。-d オプションはバックグラウンドで起動します。

    docker-compose up -d

    フォアグラウンドで起動しログを確認したい場合は -d をつけずに実行してください。

    docker-compose up

コンテナ内での操作

  1. コンテナへのシェルアクセス: 開発コンテナ内でコマンドを実行するには、まずコンテナのシェルにアクセスします。

    docker-compose exec dev bash

    これにより、コンテナ内の /app ディレクトリ（プロジェクトルートがマウントされている場所）でbashシェルが起動します。 コンテナ内のユーザーは devuser です。

  2. 開発コマンドの実行: コンテナのシェル内では、プロジェクトのツール（uv, python, ruff など）が利用可能です。 仮想環境は /app/.venv に作成されており、PATHが通っているため直接コマンドを実行できます。 例:

    • 依存関係の同期: uv pip sync --all-extras
    • Ruffでリンティング: ruff check .
    • Ruffでフォーマットチェック: ruff format --check .
    • テストの実行: python -m unittest discover -s tests
    • Pyxelゲームの実行 (X11フォワーディング設定が正しければ): python src/main.py (仮のパス)

コンテナの停止

開発作業が終了したら、以下のコマンドでコンテナを停止・削除できます。

docker-compose down

ボリューム (dev_bash_history) は削除されません。完全にクリーンアップしたい場合は docker-compose down -v を実行します。

注意事項

  • docker-compose.yml の volumes 設定により、ホストのプロジェクトファイルがコンテナ内の /app にマウントされます。ホスト側でファイルを編集すると、即座にコンテナ内に反映されます。
  • PyxelのGUI表示はX11フォワーディングに依存しており、環境によっては追加の設定やトラブルシューティングが必要になる場合があります。

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •  

Languages