COB / BOS — ユニットスクリプトのバイトコード

Total Annihilationのユニットはどれもスクリプトを実行しており、それによってピースを動かし、武器の発射炎を出し、効果音を鳴らし、ゲームのイベントに応答します。ソース言語はBOS（「Basic Object Script」）で、エンジンが実際に実行するコンパイル済みのバイトコードはCOB（「Cobble」。「compiled BOS」をもじったCavedogの駄洒落）です。ファイルはユニット1体につき1つで、FBIにあるそのユニットのObjectNameにちなんだ名前が付きます。

# Decompile a unit's bytecode back to readable BOS
kbot cob decompile scripts/ARMCOM.cob

# Disassemble to opcode-level assembly with control-flow arrows
kbot cob disassemble scripts/ARMCOM.cob -a

# Lint a whole directory for common script issues
kbot cob lint scripts/ -q

# Round-trip the entire scripts/ tree to verify byte-perfect compile
kbot cob roundtrip scripts/

import "github.com/coreprime/kbot-io/formats/scripting"

cob, _ := scripting.LoadFromFile("scripts/ARMCOM.cob")
fmt.Printf("%d scripts, %d pieces\n", cob.NumScripts, cob.NumPieces)
for i, name := range cob.ScriptNames {
    fmt.Printf("  [%d] %s\n", i, name)
}

2つの言語、1つのファイル形式#

エンジンが目にするのはCOBだけです。BOSは人間が書くための便宜上のもので、「ユニットのスクリプトを編集する」というのは、実際にはBOSのソースを編集し、COBに再コンパイルし、そのCOBをユニットのアドオンの.ufoに入れて配布することを指します。

最小限の例：

// armcom.bos — fragment from the Arm Commander
piece base, pelvis, lthigh, lleg;

#define SIG_WALK 2

Create() {
    hide pelvis;
    set-signal-mask SIG_WALK;
}

Walk() {
    set-signal-mask SIG_WALK;
    while (1) {
        turn lthigh to x-axis  [-25] speed [50];
        turn lleg   to x-axis  [50]  speed [100];
        wait-for-turn lthigh around x-axis;
        sleep 100;
    }
}

kbot cob compileはこれをバイナリのブロブに変換します。kbot cob disassemble -aはオペコードのストリームを制御フローの矢印と並べて表示します。kbot cob decompileはその逆を行い、ほぼ必ずバイト単位で同一にラウンドトリップするBOSを復元します（kbot cob roundtripがゲームのカタログ全体でこれを検証します）。

ソースは、.version 6で始まらない限りTAのスクリプト（COBバージョン4）としてコンパイルされます。コンパイラーは、TA 3.1cが誤って実行してしまうものを、プレースホルダーを書き出して済ませたりせず拒否します。TA: Kingdomsの構文（play-sound、Mission-Command、__tak_math_*、.sound_name）と%は、TAのスクリプトではエラーになります（TAには剰余の命令がなく、かつて%の変換先だったワード0x10037000は、TAではビット単位のXORです）。未知の識別子や、ゲームの32個のスタックスロットより多くを必要とする関数もエラーです。コンパイルはできるものの確認したほうがよいもの、つまり2回定義された関数（ゲームの名前検索と同じく、呼び出しはすべて最初の定義に結び付きます）は、TA互換性のlintルールによる指摘とあわせて警告として表示されます。--strictを付けると、警告でもコマンドが失敗します。kbot cob assembleは、手書きのリスティングに同じチェックを適用します。

COBのディスク上のレイアウト#

typedef struct {                          // 44-byte header (11 × uint32)
    uint32 VersionSignature;              // 4 for TA, 6 for TA: Kingdoms
    uint32 NumScripts;                    // Number of functions (Create, Killed, …)
    uint32 NumPieces;                     // Number of named pieces
    uint32 LengthOfScripts;               // Total code size, in DWORDs
    uint32 NumberOfStaticVars;            // Static-variable count
    uint32 UKZero;                        // Always 0 in retail bytecode; purpose unknown
    uint32 OffsetToScriptCodeIndexArray;  // → uint32 × NumScripts: code-index per script
    uint32 OffsetToScriptNameOffsetArray; // → uint32 × NumScripts: absolute offsets into string pool
    uint32 OffsetToPieceNameOffsetArray;  // → uint32 × NumPieces: absolute offsets into string pool
    uint32 OffsetToScriptCode;            // → packed uint32 opcode stream
    uint32 OffsetToNameArray;             // Byte just past the piece-name offset array (= sound-name offset table start for TAK v6, or string-pool start for TA v4)
} COBHeader;

その後に、次のレイアウトで続きます。

┌─ Script code ─────────────────────────────┐  uint32 opcodes/operands, packed
├─ Script code-index table ─────────────────┤  uint32[NumScripts] — *not* byte offsets
├─ Script name offset table ────────────────┤  uint32[NumScripts]
├─ Piece name offset table ─────────────────┤  uint32[NumPieces]
└─ String pool ─────────────────────────────┘  NUL-terminated names, in order

スクリプトの解決#

コードインデックスのテーブルに入っているのは、uint32のワードオフセットで、バイトオフセットではありません。スクリプト番号iのバイトコードを見つけるには、次のようにします。

uint32 first_instr_word = ScriptCodeIndexArray[i];
uint32 byte_offset      = OffsetToScriptCode + first_instr_word * 4;

スクリプトは、次のスクリプトが始まる位置で終わります（最後のスクリプトの場合は、インデックステーブルの先頭で終わります）。

オペコードのストリーム#

COBはスタックベースの仮想マシンです。ほとんどのオペコードは、スクリプトごとのデータスタックから引数をポップし、処理を行い、結果をプッシュして戻します。インラインオペランド（ジャンプ先、ピース番号）を持つオペコードもあります。

各オペコードは1つのuint32で、レイアウトは次のとおりです。

       MSB                          LSB
  ┌─────────┬─────────┬─────────┬─────────┐
  │   0x10  │ family  │ op      │ flags   │
  └─────────┴─────────┴─────────┴─────────┘

最上位バイトは常に0x10で、family/op/flagsはオペコードによって異なります。ゲームはワード全体を比較しません。word & 0x100FF000で処理を振り分けるので、このマスクの外のビットは無視され、0x10064001はJUMPとして実行されます（kbotの逆アセンブラーは、こうしたワードを変更なしにアセンブルし直せるようJUMP@0x10064001と書きます）。PUSH（0x10021000）とPOP（0x10023000）は、さらに下位3ビットから読み出し元や書き込み先を読み取ります。kbot-ioのscripting/opcodes.goがカタログで、scripting.Opcodes()はすべての命令を、インラインオペランドとスタック効果とともに一覧にします。

オペコードのファミリー#

小さいながらも代表的な例：

0x10021001 PUSH_CONST     <value>      ( -- v )
0x10021002 PUSH_LOCAL     <var#>       ( -- v )
0x10023002 POP_LOCAL      <var#>       ( v -- )
0x10033000 MUL                         ( a b -- a*b )
0x10051000 LESS_THAN                   ( a b -- a<b )
0x10066000 JUMP_IF_FALSE <byteOffset>  ( v -- )    pops; falls through if v != 0
0x10064000 JUMP          <byteOffset>  ( -- )
0x10065000 RETURN                      ( v -- )    pops the return value
0x10001000 MOVE          <piece> <axis> ( speed distance -- )
0x10003000 SPIN          <piece> <axis> ( speed -- )
0x1000F000 EMIT_SFX      <piece>       ( flags -- )
0x10068000 SET_SIGNAL_MASK              ( mask -- )

並行処理モデル#

1つのユニットは、Walk、Aim、SmokeUnit、MoveWatcherなど、多くのスクリプトを同時に実行できます。これらは協調的にスケジュールされます。

• sleep <ticks>：Nティック（1ティックは1/30秒）のあいだ制御を譲ります。
• wait-for-turn <piece> around <axis>：そのピースが現在のturnアニメーションを終えるまで制御を譲ります。wait-for-moveも同様です。
• signal <n>：signal_mask & n != 0であるスクリプトをすべて停止させます。
• set-signal-mask <n>：現在のスクリプトが関心を持つシグナルを宣言します。

シグナルマスクは、スクリプトがプリエンプション（割り込み）を実現する手段です。MoveWatcherはマスクSIG_MOVEを設定して速度を監視し、ユニットが止まるとSIG_MOVEを送って、待機ポーズを始める前に歩行アニメーションをきれいに停止させます。

プリエンプションの実際の流れ#

よくあるパターンは、MoveUnitがWalkアニメーションのスクリプトを起動し、移動が止まると、Idleが始まる前にきれいに後片付けするためにエンジンがSIG_MOVEを送る、というものです。流れは次のとおりです。

   Engine                 MoveUnit script        Walk script        Idle script
     │                          │                     │                  │
     │  unit ordered to move    │                     │                  │
     ├─ start-script MoveUnit──▶│                     │                  │
     │                          ├─ set-signal-mask    │                  │
     │                          │   SIG_MOVE          │                  │
     │                          ├─ start-script Walk─▶│                  │
     │                          │                     ├─ set-signal-mask │
     │                          │                     │   SIG_MOVE       │
     │                          │                     │ (loops:          │
     │                          │                     │   turn pieces,   │
     │                          │                     │   sleep, repeat) │
     │                          │                     │                  │
     │  movement completes      │                     │                  │
     ├─ engine sets velocity=0  │                     │                  │
     │                          ├─ signal SIG_MOVE ──┐│                  │
     │                          │                    ││                  │
     │   ◀─── KILLED ──────────────────────────────  ◀┤                  │
     │   ◀─── KILLED ──────────┤                     │                  │
     │                                                                   │
     ├─ start-script Idle ─────────────────────────────────────────────▶│
     │                                                                   │ (loops)

注目すべき点は3つあります。

1. シグナルが発生すると、SIG_MOVEを設定した両方のスクリプトが停止します。MoveUnit自身も含まれます（仕事は終わっているので問題ありません）。
2. シグナルを送るスクリプト（MoveUnit）は、停止させられる前にシグナルを送るところまでは生き残ります。ランタイムはsignalオペコードから戻った後でマスクを確認するからです。
3. IdleはSIG_MOVEを設定しないので、次のsignal SIG_MOVEの影響を受けません。

実例 — cortruck.cob（CORE建設トラック）#

kbot cob decompile scripts/cortruck.cob：

piece base;

SmokeUnit() {
    var local_0, local_1, local_2;

    while (get BUILD_PERCENT_LEFT) { sleep 400; }

    while (1) {
        local_0 = get HEALTH;
        if (local_0 < 66) {
            local_2 = (256 | 2);
            if (rand(1, 66) < local_0) { local_2 = (256 | 1); }
            emit-sfx local_2 from base;
        }
        local_1 = (local_0 * 50);
        if (local_1 < 200) { local_1 = 200; }
        sleep local_1;
    }
    return 0;
}

Create() { return 0; }

Killed() {
    var severity;
    if (severity <= 25) { explode base type (32 | 256); return 0; }
    if (severity <= 50) { explode base type (32 | 256); return 0; }
    if (severity <= 99) { explode base type (32 | 256); return 0; }
    explode base type (32 | 256);
}

対応する逆アセンブル（kbot cob disassemble -a -s SmokeUnit）を見ると、実際のオペコードのストリームが、while/ifの本体を貫くJUMP_IF_FALSE/JUMPの矢印付きで表示されます。逆コンパイラーの出力があいまいなときに役立ちます。

lintによる検査#

kbot cob lint（とアセットエクスプローラーのLintタブ）は、kbot-ioの既定のルールセットを実行します。内容は、Cavedog自身のスクリプトと、コミュニティから寄せられたMODの修正パッチに見つかった実際のバグに基づくスタイルルール、ファイル単位のチェック2つ、そしてバージョン6を宣言していないすべてのCOBに対するTA 3.1c互換性ルールです。スタイルルールの一覧：

TA互換性ルールは、TA 3.1cが異常終了するものや、異なる動作をするものを報告します。これらはエラーで、ほかのルールと同じく--ciのSARIF出力に現れ、TA: Kingdoms（バージョン6）のファイルには適用されません。

ルールの詳しい説明はkbotのREADMEにあります。逆コンパイラーは、元の変数とピースの番号付けを意図的に保ちます。そのため、逆コンパイル→lint→修正→コンパイルのサイクルを回すと、手入れが必要なMODが浮かび上がります。

注意点#

• COBヘッダー内のオフセットはすべてファイル内の絶対オフセットですが、ScriptCodeIndexArrayのエントリはコードセクション内のワードオフセットです。混同しやすいので注意してください。
• オペコード内のピース番号は、ピース名テーブルへのインデックスです。文字列ではありません。COBは名前を文字列プールとして持ちますが、ランタイムは速度のためにインデックスを使います。
• get UNIT_VALUEのオペコードは、TAとTA: Kingdomsで微妙に異なります。TA: Kingdomsは魔力の回復やコマンドポイントなどの値IDを追加しており、TAの値テーブルはもっとコンパクトです。kbotの逆コンパイラーは現在TAの値に名前を付けており、TAKの21以上のポート番号は数値リテラルとして出力されます（それでもアセンブラーを通したラウンドトリップは成り立ちます）。差分の全体はTA: Kingdoms — COB v6の差分を参照してください。
• 変数には2種類あります。local_N（関数ローカルのスタックスロット）とglobal_N（呼び出しをまたいで保持される、ユニットごとの静的変数）です。逆コンパイラーは既定でlocal_N / global_Nを出力するので、読みやすくするにはソース上で名前を付け替えてください。
• CavedogのScriptorツールは、ときどきCURRENT_SPEEDをリテラルの29としてインライン化します。そのため、ラウンドトリップ後にMoveWatcher型のスクリプトが壊れます。kbotの逆コンパイラーはシンボル名を復元します。どうしてもScriptorでラウンドトリップする必要があるなら、括弧で囲んでください（(get CURRENT_SPEED) > 5）。

典型的なサイズ#

TA: Kingdoms — COB v6の差分#

v6のファイルレイアウト#

┌─ 44-byte v4 header ──────────────────────────────────┐
│ VersionSignature == 6, NumScripts, NumPieces, …      │
├─ Sub-header (8 bytes, TAK-only) ─────────────────────┤  (soundNameOffsetTableStart, soundNameCount)
├─ Script code (uint32 opcode stream) ─────────────────┤  same encoding as v4
├─ ScriptCodeIndexArray (uint32 × NumScripts) ─────────┤  unchanged
├─ ScriptNameOffsetArray (uint32 × NumScripts) ────────┤  unchanged
├─ PieceNameOffsetArray (uint32 × NumPieces) ──────────┤  unchanged
├─ SoundNameOffsetArray (uint32 × Count) ──────────────┤  TAK-only — count from sub-header[1]
└─ String pool ────────────────────────────────────────┘  script names → piece names → sound names (in that order)

8バイトのサブヘッダーは、OffsetToNameArray（バイト44で終わる標準の11 DWORDヘッダーの末尾）と、コードセクションの先頭（OffsetToScriptCode、通常は0x34 = 52）の間にあります。中身はリトルエンディアンのuint32が2つです。

サウンド名オフセットテーブルの各エントリは、文字列プール内のNUL終端文字列を指す、ファイル内の絶対オフセットです。文字列は"SetMission o 1, s"、"create ARASWORD"、"ARROW10"のようなものです。バイトコードはこれらを、MISSION_COMMANDオペコードを通じて（オフセットではなく）インデックスで参照します（付録Cを参照）。このテーブルがサウンド名の配列と呼ばれるのは、標準のScriptorコンパイラーがADDSOUNDアクションで文字列を登録するからです。実際の中身は、音声ファイル名ではなくエンジンのコマンド文字列です。

kbotでの表現#

scripting.COBは、サウンド名を構造化された[]stringフィールドとして持ちます。不透明なバイト列として保存することはありません。それ以外のもの（サブヘッダーの値、オフセットテーブル、プール内の各文字列のオフセット）は、書き込み時にこのリストから再構築されます。

type COB struct {
    // …canonical TA fields…
    SoundNames []string // TAK-only; nil for v4
}

v4のファイルではこのスライスは常にnilで、サブヘッダーとサウンド名オフセットテーブルはどちらも出力から省かれます。

逆アセンブラーと逆コンパイラーは各文字列を.sound_nameディレクティブとして出力するので、.cobaや.bosを経由するラウンドトリップでも失われません。

.version 6
.statics 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"
.script Start
…

新しいオペコード#

TAKの.cobファイルは、TA 3.1cにハンドラーのない命令（PLAY_SOUND、MISSION_COMMAND、TAK_MATH_*演算子）と、TAでは何もしない命令（no-op）として実行されるDONT_SHADOWを使います。ゲーム側での正確な意味は文書化されていませんが、バイナリのレイアウト（サイズとインラインパラメーターの数）は製品版のすべてのTAKの.cobからわかっており、逆アセンブル→アセンブルのラウンドトリップで元のバイトをそのまま復元するには、それで十分です。完全なリファレンスは付録Cを参照してください。

ラウンドトリップの状況#

TAK拡張のBOS表記#

逆コンパイラーは、TAKのCOBがBOSを経由してラウンドトリップできるよう、次の擬似呼び出しを出力します。コンパイラーも同じ構文を受け付けますが、.version 6の後に限ります（例外はdont-shadowで、TAはこれを何もしない命令として実行します）。dont-shadowとMission-CommandはScriptorの標準のTAKキーワードを使います。数学オペコードにはScriptorでの文書化された名前がない（Scriptorは??や????と表示する）ので、kbotは__tak_math_*のプレースホルダーを使い続けます。

// Statement-level (emitted on their own line):
dont-shadow(<piece>);                                  // DONT_SHADOW — disables shadow casting for one piece
Mission-Command("sound name", arg1, arg2, …);          // MISSION_COMMAND — engine call (statement form drops the return value)
return_val = Mission-Command("sound name", args…);     // assignment form keeps the pushed result

// Expression-level (binary operators: two values popped, one pushed):
local_x = __tak_math_09(a, b);   // TAK_MATH_09
local_x = __tak_math_0a(a, b);   // TAK_MATH_0A
local_x = __tak_math_0b(a, b);   // TAK_MATH_0B

Mission-Commandの最初の引数は、引用符で囲んだ文字列で書くサウンド名です。コンパイラーはこれをサウンド名テーブルから探します（そのため、対応する.sound_nameディレクティブが、ファイル内でそれより前に現れていなければなりません）。残りの引数はスタックにプッシュされ、エンジンが消費します。

v6のメタデータの残りは、ファイル先頭の2種類のディレクティブが担います。

.version 6
.sound_name "create NPCEMEN"
.sound_name "SetMission o 1, s"
.sound_name "ARROW10"

.versionは常に出力されます（v4のTAのファイルも、同じパイプラインで同一にラウンドトリップさせるためです）。.sound_nameはそれぞれ、COBごとのサウンド名テーブルの1エントリです。ライターはlen(SoundNames)とエントリの出現順から、8バイトのサブヘッダーとサウンド名オフセットテーブルを再構築します。

v6で値のないreturn;がすべて出力する、TAKのSTACK_ALLOC ; RETURNというエピローグは、コンパイラーが処理します。.version 6のとき、return;はSTACK_ALLOC ; RETURNに、return <expr>;は前置きなしの<expr> ; RETURNに変換されます（Cavedogのコンパイラーと同じです）。

自分のインストールで再現するには：

kbot ctx use kingdoms  # or wherever you registered TAK
kbot cob roundtrip

ポート20より上のポートのシンボル#

TA: Kingdomsのスクリプトは、46までのget_unit_valueポートを使います（CURRENT_SPEED、VETERAN_LEVEL、魔力プールのフィールドなど）。kbotの逆コンパイラーが現在シンボル名を付けるのはポート1〜20だけで（付録Bを参照）、TAKの21以上のポートは数値リテラルとして出力されます。バイトコードにはどちらにしても整数として格納されるので、ラウンドトリップには影響しません。損なわれるのはBOSの読みやすさだけです。TAKのポート名の追加は、別途管理されています。

付録A — 全オペコードのリファレンス#

TAまたはTA: Kingdomsが実行するすべての命令です。正となる情報源は、kbot-ioのformats/scripting/opcodes.goです。スタック表記はForth流の( before -- after )を使います。インラインの列は、オペコードのワード自体に続くuint32ワードの数を示します（スタックからではなく、デコード時に消費されます）。

アニメーション — ピースの操作（0x100x）#

待機の操作（0x101x）#

スタックの操作（0x102x）#

算術（0x103x）#

TAには剰余の命令がありません。TAのスクリプトで%を使うとコンパイルエラーになります。0x10039000〜0x1003B000はTA: KingdomsのTAK_MATH_*演算子で（付録C）、TAでは異常終了します。

エンジンへの問い合わせ（0x104x）#

ポートの一覧は付録Bを参照してください。

比較と論理（0x105x）#

制御フローと並行処理（0x106x）#

JUMP / JUMP_IF_FALSEのoffsetは、現在の命令からではなく、OffsetToScriptCodeからのバイトオフセットです。

エフェクト（0x107x）#

設定の操作（0x108x）#

オペコードのエンコーディング#

オペコードのワードはどれも0x10CCSSFFの形で、各部分は次のとおりです。

• CC = カテゴリのバイト（アニメーション、数学、制御フロー、…）。
• SS = サブコマンドのニブル。上から2番目のバイトの上位ニブルにあります。
• FF = フラグのバイト。

ゲームはword & 0x100FF000で処理を振り分け、ほかのビットは無視します。そのため0x10064001のようなワードはJUMPとして実行されます。逆アセンブラーはこれをJUMP@0x10064001と書き、アセンブラーはそれを読んで同じワードに戻します。PUSHとPOPは、下位3ビットから読み出し元や書き込み先を読み取ります。PUSHは1（定数）、2（ローカル）、4（静的）を、POPは2と4を受け付け、それ以外の値ではスクリプトが異常終了します。

どのゲームも実行しないワードは、逆アセンブラーがUNKNOWN_0x10xxxxxxとして表示します（ta-unknown-opcodeでも報告されます）。実際のファイルでこれを見つけたら、COBのサンプルを添えてissueを開いてください。

付録B — get_unit_valueのポート表#

kbotの逆コンパイラーが現在シンボル名を付ける20個のポートです。実際のTAには約80個あり、TA: Kingdomsは魔法に関する量のために、さらに約15個を追加しています。現在の逆コンパイラーの出力では、ポート20より上はすべて数値リテラルとして表示されます。

それより上のポートには、CURRENT_SPEED（29。CavedogのScriptorがリテラルとしてインライン化することで有名です。上の注意点を参照）、MAX_ID、UNIT_TEAM、UNIT_BUILD_PERCENT、BUILDER、UNIT_ALLIEDなど、ほかにも多くのものがあります。完全な一覧はCavedogの内部資料にあります。公開されているものでは、TAUniverseフォーラムのコミュニティwikiが最も網羅的なカタログです。

TA: Kingdomsはポートの範囲を広げています。kbotが認識するTAKだけのポート（逆コンパイラーはシンボル名を表示し、コンパイラーは入力として受け付けます）は、Scriptorの[UNITVLAUES]テーブルから取っています。

付録C — TA: Kingdomsのオペコード#

エンコーディング（おさらい）#

COBのオペコードのワードはどれも0x10CCSSFFの形で、CCがカテゴリ、SSがサブコマンドです。これらのTAKのオペコードは、新しいカテゴリのバイトを導入するのではなく、既存のカテゴリ内でそれまで使われていなかったCC:SSのスロットを占めているだけです。DONT_SHADOWはアニメーションのカテゴリでDONT_CACHE/DONT_SHADEと並び、MISSION_COMMANDはエフェクトのカテゴリでEXPLODEやPLAY_SOUNDと並んでいます。

kbot ctx use tak-30bb-flat
kbot cob disassemble scripts/araat.cob -a | grep -E 'DONT_SHADOW|MISSION|TAK_MATH|PLAY_SOUND'

リファレンスカタログの実例#

この形式の極端な使い方をしている実際のユニットです。本文中の作例ではなく、本物のスクリプトの複雑さを見るには、これらを開いてください。

• CORKROG — クロゴス（CORE） — ゲーム中で最大級のCOBの1つ（約25 KB、30以上のスクリプト、複数のピースにまたがる複雑なアニメーション）。
• ARMCOM — ARMコマンダー — 代表的な「充実した」ユニット。歩行・照準・待機・建設のサイクル、複数の武器、Dガンの扱い。
• CORTRUCK — 建設トラック — このページのウォークスルーに使った、ほぼ最小限のCOB（スクリプトはSmokeUnit、Create、Killedの3つ）。
• ARMSAM — サムソン — 砲塔を持つユニットのよい例（turret1を回転させての照準、反動アニメーション、wait-for-turnによる同期）。

kbotのコンテキストを設定すれば、kbot cob decompile scripts/<name>.cobで、どれでも手元で逆コンパイルできます。

関連項目#

• 3DO — COBスクリプトが参照するピース名は、ユニットの.3doにあります。
• FBI — ユニットのメタデータのファイル。そこにあるObjectNameがCOBを3DOに結び付け、Soundsがスクリプトで再生できる音声バンクを定義します。
• kbot CLIのcob lintルール表。
• 用語集 — piece（ピース）、axis（軸）、signal mask（シグナルマスク）、tick（ティック）。