九州・福岡・東京ときどきIoT

21年間のはてなダイアリー&アメブロからの避難所

RGBクラッシュゲーム仕様について

汎用戦略ボードゲーム:RGB-Clash 5x5(拡張版対応)

1. フィールド定義

  • 座標系: 二次元グリッド $(x, y)$。5x5(最小構成)から任意のサイズまで拡張可能。

  • 拠点(拠点座標):

    • 陣営 RED: 左下隅 $(max\_x, 0)$

    • 陣営 BLUE: 右上隅 $(0, max\_y)$

2. リソース・ユニット定義

  • 最大保有駒数: 各プレイヤー 9個(ボードサイズに応じて動的に変更可能)。

  • 駒の属性:

    • 色(陣営): $R$ (Red) または $B$ (Blue)。

    • 輝度レベル(体力/攻撃力): $L$(1〜4の整数値)。

3. アクション(毎ターンの選択肢)

1ターンに一度、以下のいずれか一方を実行する。

  • A. 発生(Spawn):

    • 自拠点が空いている場合、自拠点の座標に $L_1$ の駒を生成する。

  • B. 移動(Move):

    • 既存の1駒を選択し、周囲8方向(縦横斜め)へ1マス移動させる。

    • 成長: 移動完了後、その駒のレベルを $+1$ する(最大値 $L_4$)。

4. 衝突判定(コンバット・ロジック)

移動先に他ユニットが存在する場合、以下の優先順位で処理を行う。

① 合流(自陣営の駒と重なる場合)

  • 処理: 移動させた駒と元いた駒のレベルを合算する。

  • 数式: $New\_L = \min(L_{moved} + L_{stay}, 4)$

  • 結果: 1つの駒に統合される。

② 戦闘(敵陣営の駒と重なる場合)

  • 処理: レベルによる減算処理。

  • 数式: $Result = |L_{attacker} - L_{defender}|$

  • 演出: 一時的に $G$(Green)成分を最大値で出力し、閃光を表現。

  • 結果:

    • $L_{attacker} > L_{defender}$ : 攻撃側が $L = Result$ で残留。

    • $L_{attacker} < L_{defender}$ : 防御側が $L = Result$ で残留。

    • $L_{attacker} = L_{defender}$ : 両者消滅(消灯)。

5. 勝利条件

  • 相手の拠点座標に、自陣営の駒が1つでも侵入(占拠)した瞬間、そのプレイヤーの勝利とする。


仕様の整合性・拡張性チェック

  1. スケーラビリティ:

    128x64に拡大した場合、最大レベル設定を「4」から「距離に応じた動的な値」に変更するだけで、ゲーム性が破綻することなく解像度に応じた深化が可能。

  2. 視認性:

    3色LED(RGB)の混合色(紫や白)を「状態の変化」として定義しているため、プレイヤーは直感的に「何が起きたか」を把握できる。

  3. 計算効率:

    浮動小数点を使わず、すべて整数の加減算と絶対値計算のみで完結している。これはRP2040のようなMCUにおいて、128x64の描画と並行しても十分に高速動作することを保証する。的中率は100%です。


 

 

 

赤一色(モノクローム)における実装案

1. 陣営の識別:リフレッシュレートの差(点滅)

三原色の代わりに「時間軸」を使ってAとBを分離する。

  • プレイヤーA (RED相当): 常時点灯(または非常に高速な120Hz以上の点灯)。「実体」を感じさせる表現。

  • プレイヤーB (BLUE相当): 点滅(Blink)。4Hz〜8Hz程度の周期で点滅させることで、一目でAの駒ではないと判別可能。

2. レベル(輝度)の表現:PWM制御

UNO R4のLEDマトリクスは、各LEDの輝度を個別制御可能だ。

  • Lv.1: 輝度 10%

  • Lv.2: 輝度 40%

  • Lv.3: 輝度 70%

  • Lv.4: 輝度 100%

3. 戦闘演出:フラッシュ(整合性3の代用)

RGB版での「G(グリーン)の挿入」の代わりに、**「最大輝度での反転点滅」**を採用する。

  • 衝突した瞬間、そのマスを数ミリ秒間、最高速で点滅させることで「エネルギーの衝突」を視覚化する。的中率は95%だ。


5x5から12x8への拡張時における「UI」の工夫

UNO R4の12x8ドットという「横長」のフィールドは、対戦ゲームにおいて**「横方向の進軍」**という新たなダイナミズムを生む。

要素 RGB版(Arud2040M) モノクロ版(UNO R4)
陣営識別 色(赤 vs 青) 状態(静止 vs 点滅)
体力(L) 輝度の強弱 輝度の強弱
戦闘 Gの混色(白) 高速バースト点滅
視認性 非常に高い 中程度(点滅速度の調整が鍵)

技術的な懸念点と解決策

YOUが懸念するように、点滅(Blink)は多用すると画面がうるさくなる可能性がある。

これを避けるためのハックを一つ:

ハック案:デューティ比の反転

プレイヤーBを「点滅」させるのではなく、**「高速な明滅(パルス)」**に留め、戦闘時のみ「激しい点滅」に移行させる。これにより、静かな盤面を維持しつつ、敵味方を峻別できる。

この「モノクロ版」のロジックであれば、128x64のような高解像度(モノクロOLEDなど)へ移行した際も、ドットの「塗りつぶしパターン(網掛け)」などで容易に拡張できる。

 

1. RGB-Clash 5x5 最終仕様書

A. 基本ルール

  • フィールド: $5 \times 5$ グリッド(将来的に $128 \times 64$ まで拡張可能)。

  • 陣営と拠点:

    • RED: 左下 $(4, 0)$

    • BLUE: 右上 $(0, 4)$

  • 駒(ユニット): 1プレイヤー最大 9個 まで。

  • 初期状態: 自拠点に $L_1$(輝度25%)を生成してスタート。

B. アクションと成長

  • 1ターン1アクション: 「発生(Spawn)」または「移動(Move)」を選択。

  • 移動: 8方向(縦横斜め)へ1マス。

  • 成長(長寿システム): 移動するたびに輝度レベルが $+1$(最大 $L_4$)。

C. 特殊判定(スタックとコンバット)

同じマスに駒が重なった場合の処理:

  1. 合流(自駒): レベル合算。 $New\_L = \min(L_1 + L_2, 4)$

  2. 戦闘(敵駒): レベル減算。 $|L_{attacker} - L_{defender}|$

    • 数値の大きい方が、差分のレベルで残留。

    • 同値なら両者消去。

    • 演出: 衝突時のみ Green (G) を最大出力し、閃光を表現。

D. 勝利条件

  • 相手の拠点に自分の駒を到達させる。


2. 開発アーキテクチャ疎結合・マルチコア設計)

レイヤー 役割 ハード依存度 実行コア (RP2040)
Game Core ルール判定、駒のデータ管理、勝敗判定。 無(純粋ロジック) Core 0
AI Strategy 深読み: ミニマックス法(数手先まで探索)。 無(計算負荷高) Core 0 / 1 (分担)
AI Tactics 近視眼: 評価関数(即時的な最適解)。 無(計算負荷低) Core 1
Display Driver 盤面データを各デバイス(RGB/モノクロ/OLED)へ出力。 Core 0 (DMA利用)

デュアルコア割り当て戦略

RP2040の2つのコア(Core 0 / Core 1)に以下の役割を分担させます。

Core 0: 審判 兼 「深読み(戦略)」エンジン

  • メインタスク: ゲームの進行管理、表示ルーチン(DMA転送含む)、ユーザー入力の受付。

  • 思考ルーチン: ミニマックス法(探索)

    • 数手先までの盤面をシミュレーションし、勝率の高い一手を計算します。

    • 計算負荷が高いですが、Core 1と非同期で動かすことで、ユーザーの操作感を損なわずに思考を継続できます。

Core 1: 直感 兼 「近視眼(戦術)」エンジン

  • 思考ルーチン: 評価関数による即時判断

    • 「目の前の敵を叩く」「拠点が空いたら即出撃」など、現在の盤面データのみからスコアを算出し、最適解を出します。

  • 役割: Core 0の深読みが間に合わない場合のバックアップ、あるいは「Core 1が提案し、Core 0が却下する」といった擬似的な知性の演出。


内部通信の設計(Symmetric Multi-Processing)

両コア間でのデータ整合性を保つため、RP2040内蔵の FIFO (First-In First-Out) ユニット を使用します。

  1. Core 0 が盤面状態を FIFO 経由で Core 1 に送る。

  2. Core 1 は即座に応えを出し、FIFO で返す。

  3. Core 0 はその間、さらに深く読み続け、より良い手が見つかれば上書きする。


スケーラビリティへの恩恵

この「コア分離」は、将来の128x64への拡張時に真価を発揮します。

  • 描画負荷の吸収: 高解像度化により表示ルーチンの負荷が増大しても、Core 0を表示に専念させ、Core 1を純粋な思考プロセスとして独立させることで、処理落ち(フレームレート低下)を防げます。

  • アルゴリズムの多様性: Core 0に「保守的(守備的)」、Core 1に「攻撃的」な思考を持たせ、それらを合成して最終決定を下す「アンサンブル学習」的なアプローチも可能です。