ターン制バトル RPG ― .NET Framework 4.8 制作チュートリアル

「Models と Services に分ける」という最小限のレイヤリングは、責務（Responsibility）をはっきり分離し、実装の見通しを良くするためです。

フォルダー分割がもたらす 4 つのメリット

このプロジェクトでの具体的な役割

実務的フォルダー設計のヒント

1. ルールは「名詞⇔動詞」
   • ドメインオブジェクト（名詞）→ Models／Entities
   • ビジネスロジック（動詞）→ Services／UseCases
2. UI は別プロジェクトにしても◎
   • TurnBasedRpgFw48.WinForms などに分ければ DLL 参照で済む。
3. 名称は物理フォルダと合わせる
   • 名前空間 TurnBasedRpgFw48.Models ↔ フォルダー Models
   • Visual Studio の “同期” 機能で自動補完。
4. 階層は多すぎないこと
   • 初学者教材では 2～3 階層が限界。複雑化は学習コストが跳ね上がる。
5. 将来の変更に備えた“疎結合”
   • Models は Services に依存しない（一方向依存）。
   • 逆依存が必要になったらインターフェース経由にする。

まとめ

• Models ⇔ Services の 2 分割だけでも「責務の境界」を明確にできる。
• この記事では早い段階でフォルダーを切ることで、後工程の「テスト拡充」「UI 分離」「機能追加」を楽にする布石になっている。
• 規模が大きくなったら Repositories / Infrastructure を追加し、レイヤード・アーキテクチャへ発展させるのが定石。

まずは記事の通りにフォルダーを作成し、“場所を探す時間”をゼロにする開発体験を味わってみてください。

なぜ base(…) が必要なのか

• Character のコンストラクターはprotected Character(string name, int hp, int atk) の 1 つだけ。引数なし（パラメータレス）のコンストラクターが存在しないため、派生側 (Player) は 必ずどれかの Character(…) を呼び出さなければコンパイルエラー になります。 
• base(…) は Java の super(…) に相当。最初に実行され、Name / HP / Atk プロパティをセットします。

// Character 側
protected Character(string name, int hp, int atk)
{
    Name = name;   // 読み取り専用プロパティ
    HP   = hp;     // private set なのでここでしか代入できない
    Atk  = atk;    // 初期化必須
}

「40」と「10」はどこで決める？

処理の流れ（コンストラクターチェーン）

1. new Player(“アリス")
2. Player コンストラクター開始
3. base(“アリス", 40, 10) で Character コンストラクター実行
   • Name = “アリス"
   • HP   = 40
   • Atk  = 10
4. Character の初期化完了 → Player コンストラクター本体（空）へ戻る
5. インスタンス生成完了

: base(…) を書かなかったら？

public Player(string name) { }   // コンパイルエラー

CS7036: ‘Character.Character(string, int, int)’ に適合する引数がありません

• C# のルール：派生クラスのコンストラクターは、暗黙に : base() を付けて呼び出す（引数なしの基底コンストラクターが存在する場合のみ有効）。
• 今回は Character に引数なしコンストラクターが無いので、明示的に書く必要があるのです。

まとめ

• public Player(string name) は プレイヤーを生成する窓口。
• : base(name, 40, 10) で 「HP 40・攻撃力 10 のプレイヤー」という初期状態を Character に一任。
• 派生コンストラクターで追加ロジックが不要なら { } は空でも問題なし。
• 継承では「どの基底コンストラクターを呼ぶか」を必ず意識しよう。

メソッド本体の 2 行

【コード】

Console.WriteLine($“▶ {Name} のターン：攻撃！”);<br>opponent.TakeDamage(Atk);

――――――――――――――――――――――――

■ 各行の役割

行 1 : 行動ログを表示して「誰が何をしたか」を即座に確認できるようにする。

行 2 : 相手（opponent）に攻撃力（Atk）ぶんの固定ダメージを与える。ダメージ計算は Character クラスで一元管理されている TakeDamage メソッドに任せるため、プレイヤーでも敵でも同じ手順で HP を減らせる。

――――――――――――――――――――――――

■ 呼び出しまでの流れ

1. Battle.ExecuteTurn() が actor.Act(target) を実行する。
2. そのターンの actor が Player の場合、動的ディスパッチによって Player.Act が呼ばれる。
3. 行動ログを出力し、TakeDamage が相手の HP を減らす。0 未満になった場合は TakeDamage 内で 0 に丸められる。この一連の処理は 1 ターンあたり数ミリ秒で完了する。

――――――――――――――――――――――――

■ override が必要な理由

Character クラスには抽象メソッド Act() が宣言されており、派生クラスは必ず実装しなければならない。Player.Act に override を付けることで「契約を守っています」とコンパイラに伝え、シグネチャの食い違いによるバグを防ぐ。

――――――――――――――――――――――――

■ さらに発展させるなら

・クリティカルヒットの追加例

if (Rng.NextDouble() < 0.10) damage *= 2;

・攻撃／防御を選ばせる入力メニュー

　Console.ReadKey(true) を使ってキー入力を判定し、行動を分岐させる。

・スキルシステムの実装

　ISkill インターフェースを定義し、各スキルに Execute(Character target) を持たせて Player.Act 内で順に呼び出す。

このコード：

public Battle(params Character[] actors)
{
    _actors = actors.ToList();
}

は、可変長引数を受け取るコンストラクタの例です。以下のように順を追って説明します。

🔹 概要

• Battle クラスのコンストラクタ
• 引数として Character 型の配列（params）を受け取り、それをリスト _actors に変換して保持する

🔸 params Character[] actors の意味

• params 修飾子を使うことで、複数の Character をカンマ区切りで渡すことができます。
• 呼び出し側は 配列を明示的に作らずに 複数の引数を渡せます。

例（呼び出し側）:

var player = new Player("アリス");
var enemy = new Enemy("スライム");

var battle = new Battle(player, enemy);

↑ このように、配列ではなく複数のオブジェクトをそのまま渡せるのが params の利点です。

🔸 _actors = actors.ToList(); の意味

• params で渡された Character[] は配列なので、ToList() を使ってリストに変換しています。
• _actors はおそらく List<Character> 型のフィールドであり、バトル参加者を保持するために使用されます。

🔹 まとめ

🔸 参考：配列で渡すことも可能

もちろん、以下のように配列を渡すこともできます：

Character[] characters = { player, enemy };
var battle = new Battle(characters);

はい、こちらのコード：

while (_actors.All(a => a.IsAlive))
{
    Console.WriteLine($"\n--- ターン {turn++} ---");
                ExecuteTurn();
            }

についても、初心者向けにわかりやすく説明します。

🔹 このコードの役割

この while 文は、

すべてのキャラクターが生きている間だけ、ループを続ける

という意味です。

🔸 

_actors.All(a => a.IsAlive)

 の意味

これは LINQ（リンク） という機能を使った条件判定です。

つまり：

すべてのキャラクター（a）の a.IsAlive が true なら true を返す

🔸 

IsAlive

 プロパティの意味（補足）

例えば Character クラスにこういうコードがあるとします：

public bool IsAlive => HP > 0;

これは「HP が 0 より大きいなら生きている」と判断します。

🔹 while文としての動作

while (_actors.All(a => a.IsAlive))
{
    // バトルの処理を行う
}

このループはこう読み替えられます：

全員が生きているうちはバトルを続ける。誰かが死んだら（HPが0になったら）バトルを止める。

🔸 図でイメージ

Actors: [ 勇者(HP 10), スライム(HP 20) ] → 全員 IsAlive → ループ継続
Actors: [ 勇者(HP 0), スライム(HP 5) ] → 1人死亡 → ループ終了

🔹 まとめ

1. 実際の動作フロー

1. 遅延列挙の生成

IEnumerable<Character> alive = _actors.Where(a => a.IsAlive);

1. ここではまだ走査されず、“条件だけ覚えたパイプ” が返る。
2. foreach 開始で列挙がスタート
   • MoveNext() が呼ばれるたび _actors の次要素を取り出し、ラムダ条件を評価。
   • IsAlive == false の要素はスキップされ、条件を満たす最初の要素だけが Current として actor へ渡る。
3. ループ本体で actor.Act(target); などの処理を実行。
4. 以後 MoveNext() ⇒ 条件判定 ⇒ ヒットしたら本体・・・を 生存者が尽きるまで繰り返す。

2. “LINQ あり” と “if スキップ” 版の等価性

// LINQ（宣言的）
foreach (var actor in _actors.Where(a => a.IsAlive))
{
    ...
}

// 伝統的（命令的）
foreach (Character actor in _actors)
{
    if (!actor.IsAlive) continue;
    ...
}

• パフォーマンスはどちらも O(n)。
• LINQ 版は「生きているキャラだけ」と意図が先に読めるのが利点。
• 追加メモリは不要（遅延実行なので中間リストを作らない）。

3. 遅延実行ゆえの注意

4. var を明示型にしたい場合

foreach (Character actor in _actors.Where(a => a.IsAlive))

• 型が一目で分かる安心感を優先。
• ただし LINQ 連鎖が複雑になると毎回書くのが煩雑なので、var + マウスホバーで型確認する方法も実用的。

5. ひと言まとめ

宣言的に「生きているキャラだけを順番に処理する」

LINQ の Where + foreach は

• 条件フィルタとループを 1 行 で記述
• 遅延実行で無駄なメモリ割当なし
• コードを「意図 → 処理」の順に読める

こうした利点があるため、ゲームロジックでも「状態で絞り込んで処理する」場面で頻出します。

1. フロー全体

1. _actors 内部を 先頭から順に評価
2. 条件 (a != actor && a.IsAlive) を満たす 1 件目を発見した瞬間に返す
3. 変数 target にその Character が入る
4. 該当要素が無ければ InvalidOperationException がスローされ、バトルが落ちる

安全性メモ

• 本チュートリアルでは “生存者が自分だけ” という状況で ExecuteTurn を呼ばない設計なので例外は起きない想定。
• 不安な場合は FirstOrDefault を使い、null チェックでフォールバック処理を書くと堅牢。

2. “LINQ あり” と “for ループ” の等価コード

// LINQ 版
Character target = _actors.First(a => a != actor && a.IsAlive);

// 伝統的 for 版
Character target = null;
for (int i = 0; i < _actors.Count; i++)
{
    var c = _actors[i];
    if (c != actor && c.IsAlive)
    {
        target = c;
        break;
    }
}
if (target == null) throw new InvalidOperationException();

• 簡潔さ: LINQ 1 行で “最初の生存敵を取る” 意図がはっきり
• コスト: 両者とも最悪 O(n)。First は途中で打ち切り可なので無駄走査なし

3. .First／.FirstOrDefault 選択ガイド

var target = _actors.FirstOrDefault(a => a != actor && a.IsAlive);
if (target == null) return; // 行動せずターン終了など

4. “遅延実行” の影響

• First も 遅延実行：呼ばれた瞬間にだけ列挙を開始し、1 件取ったらそこでストップ
• したがって他スレッドで _actors が変更されても、最初に列挙し終わった要素には影響しない
• ただし 列挙中に Remove や Add を行うと InvalidOperationException が出るので注意（foreach と同じルール）

5. varを明示的に変えた場合

Character target = _actors.First(a => a != actor && a.IsAlive);

• 可読性を優先して明示型にしても性能差はない
• LINQ 連鎖で型が変わる場合は var + マウスホバーで確認が実用的

6. まとめ ― キーアイデア

“コレクションから条件に合う先頭要素を 1 つだけ取る”

• First は「無いときは落ちて良い」場面で強い宣言力
• 0 件許容なら FirstOrDefault＋null 判定
• 宣言的コードで意図が明確、ループ途中で止まるため効率的

Where＋foreach と First の両方を理解すれば、LINQ で

「フィルタ → 先頭取得 → 操作」のパイプラインを読み解く基礎はカバーできます。

1. using ディレクティブ

ポイント

名前空間を物理フォルダ構成と合わせておくと、巨大プロジェクトでも型の所在が一目で分かります。

2. namespace TurnBasedRpgFw48

• プロジェクト全体を包む最上位名前空間。
• 同じ接頭辞を共有することで ディスカバリ（見つけやすさ） と 衝突回避 を両立します。

3. internal static class Program

4. private static void Main()

• CLR が最初に呼び出すメソッド。アクセス修飾子は private でも問題ありません（外部から呼ばれないため）。
• 戻り値を void にすると終了コードを返さないシンプルな形になります（整数を返して OS に終了コードを渡すことも可）。

5. バトルの生成と実行

var battle = new Battle(
    new Player("勇者アリス"),
    new Enemy("スライム")
);

battle.Run();

• Battle が内部ループを持ち、参加者の Act() を交互に呼び出して決着まで制御します。
• UI（コンソール出力）の責務も Battle 側に寄せれば MVC 的に Model と Presentation を分離できます。

6. 終了待機

Console.WriteLine("\nEnter で終了…");
Console.ReadLine();

• ゲーム終了直後にコンソールが即座に閉じるのを防ぐ典型パターン。
• ReadLine() はブロッキングなので、ユーザーが Enter を押すまでアプリが維持されます。

全体の流れ（シーケンス）

1. Main が呼ばれる
2. Player / Enemy を組み立てて Battle インスタンスを生成
3. Battle.Run() が内部でターン制ループを実行
4. 勝敗決定 → Run() 戻り → メインスレッドへ
5. ユーザーが Enter を押すとプロセス終了

さらに改善できる点

これで Program.cs が果たす役割と、クラス設計全体の意図がクリアになるはずです。必要に応じてリファクタリングやテスト拡充を行ってみてください。

以下では 元のコンソール版コード（約 200 行・.NET Framework 4.8） を前提に、記事 7 章「発展課題（自由研究）」の サンプル解答 を 3 レベル分まとめて示します。

“差分中心” で示していますので、そのまま貼り付けて動作確認できます。

★☆☆　シンプルに複数の敵を出してみましょう

変更点

1. Program.cs で Battle に渡す配列を 1 体 → 2 体へ増やします。
2. Character 側は変更不要です（既に foreach (var actor in _actors.Where(a => a.IsAlive)) で全キャラを回しているため）。

// Program.cs ─ Main メソッドだけ差し替え
static void Main()
{
    var actors = new Character[]
    {
        new Player("勇者",   hp: 30, atk: 8),
        new Enemy ("スライムA", hp: 12, atk: 4),
        new Enemy ("スライムB", hp: 10, atk: 3)   // ★ 追加
    };

    var battle = new Battle(actors);
    battle.Run();
}

3. Player.cs / Enemy.csでオブション引数を受け取るようにコンストラクタのみ変更します
   この場合、hpとatkが省略されていても規定値が使われます

public class Player : Character
{
    public Player(string name, int hp = 40, int atk = 10) : base(name, hp, atk) { }

}

public class Enemy : Character
{
    public Player(string name, int hp = 12, int atk = 4) : base(name, hp, atk) { }
}

このようにすれば、new Player(“勇者", 30, 8) や new Enemy(“スライムB", 10, 3) として渡せるようになります。

ポイント

• 乱数は Enemy の static Random Rng を全敵で共有していますので、2 体になってもシード衝突の心配はありません。
• 体力や攻撃力を変えてみると、基礎パラメータ調整の体験にもなります。

★★☆　スキル追加

1. ISkill インターフェース

public interface ISkill
{
    string Name { get; }
    void Execute(Character user, Character target, Action<string> log);
    int Weight { get; }    // 発動確率ウェイト（高いほど選ばれやすい）
}

2. 例：Fireball スキル

public sealed class Fireball : ISkill
{
    private static readonly Random Rng = new Random();
    public string Name   => "ファイアボール";
    public int    Weight => 3;          // BasicAttack の 3 倍重み

    public void Execute(Character user, Character target, Action<string> log)
    {
        int dmg = user.Atk * 2 + Rng.Next(-1, 2);   // 強め＋ばらつき
        target.TakeDamage(dmg);
        log($"{user.Name} は {target.Name} に {Name} を放ち {dmg} ダメージ！");
    }
}

3. Character クラスの拡張

public abstract class Character
{
    // 追加プロパティ
    public List<ISkill> Skills { get; } = new List<ISkill>();

    // Act() を改修（共通処理：Player / Enemyでオーバーライド可）
    public virtual void Act(IEnumerable<Character> actors, Action<string> log)
    {
        var target = actors.First(a => a != this && a.IsAlive);

        // ★ 30% の確率でスキルを発動
        bool useSkill = Skills.Any() && Enemy.Rng.Next(100) < 30;
        if (useSkill)
        {
            ISkill skill = GetRandomSkillByWeight();
            skill.Execute(this, target, log);
        }
        else
        {
            BasicAttack(target, log);
        }
    }

    private ISkill GetRandomSkillByWeight()
    {
        int total = Skills.Sum(s => s.Weight);
        int roll  = Enemy.Rng.Next(total);
        foreach (var s in Skills)
        {
            if ((roll -= s.Weight) < 0) return s;
        }
        return Skills[0];
    }
}

4. スキルを登録

// Program.cs 抜粋
var hero   = new Player("勇者", 30, 8);
var slimeA = new Enemy ("スライムA", 12, 4);
var slimeB = new Enemy ("スライムB", 10, 3)
{
    // スライムB だけファイアボールを習得
    Skills = { new Fireball() }
};

var battle = new Battle(new Character[] { hero, slimeA, slimeB },
                        log: Console.WriteLine);
battle.Run();

学習効果

• インターフェースで振る舞いを差し替える体験（ポリモーフィズム再確認）
• List<ISkill> を コンポジションとして持たせ、動的に拡張可能にしています。
• 重み付きランダム選択で、確率ロジックの基礎も学べます。

★★★　Windows Forms 版（UI フロント分離）

前提：フォーム Designer で下記コントロールを貼るだけです。

• btnNextTurn（Button, Text=「▶ 次のターン」）
• lstLog（ListBox, Dock=Fill）

1. MainForm.cs

public partial class MainForm : Form
{
    private readonly Battle _battle;

    public MainForm()
    {
        InitializeComponent();

        // モデルはそのまま再利用
        _battle = new Battle(
            new Character[]
            {
                new Player("勇者", 30, 8),
                new Enemy ("スライムA", 12, 4),
                new Enemy ("スライムB", 10, 3) { Skills = { new Fireball() } }
            },
            log: AddLog);                // デリゲートで UI へ流す
    }

    private void AddLog(string msg)
    {
        lstLog.Items.Add(msg);
        lstLog.TopIndex = lstLog.Items.Count - 1;   // 自動スクロール
    }

    private void btnNextTurn_Click(object sender, EventArgs e)
    {
        if (_battle.IsFinished)
        {
            MessageBox.Show("バトルは終了しました！");
            return;
        }

        _battle.ExecuteTurn();          // 1 ターンだけ進行
        if (_battle.IsFinished)
        {
            AddLog("=== Battle Finished ===");
            btnNextTurn.Enabled = false;
        }
    }
}

2. Battle クラスに 2 つだけ追加

public bool IsFinished => _actors.Count(a => a.IsAlive) <= 1;

public void ExecuteTurn()
{
    _turn++;
    _log?.Invoke($"\n--- Turn {_turn} ---");

    foreach (var actor in _actors.Where(a => a.IsAlive))
        actor.Act(_actors, _log);
}

UI 分離のコツ

• Battle は UI に一切依存しないまま Action<string> log でメッセージを流し込むだけに留めます。
• WinForms 側は「1 ターンごとに ExecuteTurn → ListBox に追加」するだけで、モデル層の再利用を体験できます。
• ボタン連打でデバッグ／テストがしやすく、初心者にも UI/ロジック分離の価値が伝わります。

まとめ

これらを段階的に実装していくことで、初学者でも 「動かしながら OOP を拡張する楽しさ」 を体験できます。

1. シーケンス図 ― 1 ターンの流れ

• 実線矢印 … 呼び出し
• activate / deactivate … メソッドの実行区間

2. アクティビティ図 ― Battle.Run() のロジック

• この図は while (_actors.All(a => a.IsAlive)) ループとターン増分処理を視覚化しています

3. ステートマシン図 ― Character の生存状態

• Alive … HP > 0
• Dead … HP == 0。以降 IsAlive が false となり、Battle.ExecuteTurn() の Where(a => a.IsAlive) フィルタでループ対象外になります。

結論から言うと Battle クラスを「静的クラス (static class)」にするのはおすすめしません。

理由は「バトルごとに状態を持つ必要がある」からです。静的クラスはインスタンスを生成できないため、状態を保持できず “1 回限り” のユーティリティ関数置き場のような役割に限定されてしまいます。

静的クラスとインスタンス クラスの役割の違い

なぜ Battle はインスタンス クラスが適切か

1. 状態を持つ
   • ターン数、ログ、敵味方の HP など、バトルごとに異なる値を保持するため。
2. 複数のバトルを管理できる
   • 例えば “連戦モード” や “テストで並列にバトルを走らせる” 場面で支障がない。
3. 拡張／テストがしやすい
   • 「IBattle インターフェース → Battle 実装 → MockBattle」で単体テスト可能。
4. SOLID 原則に沿う
   • 単一責任の原則：バトルのロジックだけを担当し、生成や記録は別クラスに委譲できる。

もし静的にしたいと感じる動機と対策

代替実装例

今のままインスタンス クラス

public class Battle
{
    private readonly Character _player;
    private readonly Character _enemy;
    private int _turn = 1;

    public Battle(Character player, Character enemy)
    {
        _player = player;
        _enemy  = enemy;
    }

    public void Run()
    {
        while (_player.IsAlive && _enemy.IsAlive)
        {
            Console.WriteLine($"\n--- Turn {_turn} ---");
            _player.Act(_enemy);
            if (_enemy.IsAlive) _enemy.Act(_player);
            _turn++;
        }
        Console.WriteLine(_player.IsAlive ? "You Win!" : "You Lose...");
    }
}

「純粋ロジックだけ」静的クラスに抽出

public static class DamageCalculator
{
    public static int CalcPhysicalDamage(int attack, int defense)
        => Math.Max(1, attack - defense);
}

Battle は上記の DamageCalculator を呼び出すだけにしておくと、

状態 と 純粋関数 が分離され、コードの見通しが良くなります。

まとめ

• 静的クラスは「状態を持たないユーティリティ集」に限定して使う
• バトルのように“毎回異なる状態が必要な概念”はインスタンス クラスで表現する
• 設計の判断基準は「状態と責務」に注目するとぶれにくい

これらを踏まえ、Battle クラスは現状の インスタンス クラス のまま維持し、

もし共通計算だけ静的化したい場合は 補助クラス に切り出すのが王道です。