winning-avg-corewars

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CoreWars Warrior Development

CoreWars 战士开发

Overview

概述

This skill provides a systematic methodology for developing CoreWars warriors that achieve specified win rate thresholds against multiple opponents. It emphasizes deep opponent analysis, systematic parameter tuning, automated testing, and targeted strategy development rather than ad-hoc trial-and-error approaches.

本技能提供了一套系统化方法，用于开发能在面对多个对手时达到指定胜率阈值的CoreWars战士。相较于临时的试错方法，它更强调深度对手分析、系统化参数调优、自动化测试以及针对性策略开发。

Prerequisites

前置条件

Before beginning warrior development:

Verify pmars (Portable MARS) is available for testing battles
Identify all opponent warriors and their required win rate thresholds
Read and understand the opponent warrior code before writing any counter-strategies
Determine core size and other battle parameters from the task requirements

在开始战士开发之前：

确认pmars（Portable MARS）已可用于测试对战
确定所有对手战士及其要求的胜率阈值
在编写任何对抗策略之前，阅读并理解对手战士的代码
根据任务要求确定核心大小和其他对战参数

Development Workflow

开发流程

Phase 1: Opponent Analysis

阶段1：对手分析

Before writing any warrior code, thoroughly analyze each opponent:

Read opponent source code - Understand the warrior's strategy, not just observe its behavior
Categorize opponent type - Identify if it's a bomber, scanner, replicator, imp, paper, stone, or hybrid
Extract exploitable patterns:
- What step/interval does it use for bombing or scanning?
- What positions in the core does it avoid or target?
- Does it have predictable timing or movement patterns?
- What are its weaknesses (e.g., vulnerable to imps, slow startup)?

Document findings - Create a brief profile for each opponent:

Opponent: stone.red
Type: Bomber
Step: 4 (bombs every 4 positions)
Weakness: Predictable bombing pattern, vulnerable to positions not divisible by 4
Counter-strategy ideas: Use step sizes that avoid multiples of 4

在编写任何战士代码之前，彻底分析每个对手：

阅读对手源代码 - 理解战士的策略，而不只是观察其行为
对手类型分类 - 判断它是轰炸机、扫描器、复制者、Imp、Paper、Stone还是混合型
提取可利用的模式：
- 它使用什么步长/间隔进行轰炸或扫描？
- 它会避开或瞄准核心中的哪些位置？
- 它是否有可预测的时间或移动模式？
- 它的弱点是什么（例如，易受Imp攻击、启动缓慢）？

记录分析结果 - 为每个对手创建简要档案：

Opponent: stone.red
Type: Bomber
Step: 4 (bombs every 4 positions)
Weakness: Predictable bombing pattern, vulnerable to positions not divisible by 4
Counter-strategy ideas: Use step sizes that avoid multiples of 4

Phase 2: Strategy Selection

阶段2：策略选择

Based on opponent analysis, determine appropriate warrior archetypes:

Common CoreWars Warrior Types:

Scanner: Searches for enemies before attacking
Bomber: Blindly drops DAT bombs at regular intervals
Replicator (Paper): Creates copies of itself throughout the core
Imp: Simple MOV 0,1 that creates self-propagating spirals
Vampire: Uses JMP traps to capture enemy processes
Stone: Bomber with defensive spl/jmp stuns
Silk: Optimized replicator with specific step patterns

Strategy Decision Tree:

Against slow bombers → Fast replicators or scanners
Against replicators → Scanners with quick-scan or vampires
Against imps → Imp gates (spl 0, dat 0 pairs) or core clears
Against scanners → Decoys combined with attack components
Against core clears → Fast-spreading replicators

基于对手分析，确定合适的战士原型：

常见CoreWars战士类型：

扫描器（Scanner）：攻击前先搜索敌人
轰炸机（Bomber）：定期盲目投放DAT炸弹
复制者（Replicator/Paper）：在核心各处创建自身副本
Imp：简单的MOV 0,1指令，会创建自我传播的螺旋
吸血鬼（Vampire）：使用JMP陷阱捕获敌方进程
Stone：带有防御性spl/jmp眩晕的轰炸机
Silk：具有特定步长模式的优化型复制者

策略决策树：

对抗慢速轰炸机 → 快速复制者或扫描器
对抗复制者 → 带快速扫描的扫描器或吸血鬼
对抗Imp → Imp闸门（spl 0, dat 0组合）或核心清除
对抗扫描器 → 诱饵结合攻击组件
对抗核心清除 → 快速传播的复制者

Phase 3: Initial Implementation

阶段3：初始实现

Start with simple, focused warriors rather than complex multi-component designs:

Begin minimal - Test the simplest version of chosen strategy first
One component at a time - Add complexity only after understanding base performance
Use proven patterns - Reference established CoreWars strategies from documentation
Avoid premature optimization - Get basic functionality working before tuning

从简单、聚焦的战士开始，而非复杂的多组件设计：

从最简版本开始 - 先测试所选策略的最简版本
逐个添加组件 - 只有在理解基础性能后再增加复杂度
使用经过验证的模式 - 参考文档中已确立的CoreWars策略
避免过早优化 - 在调优前先让基础功能正常工作

Phase 4: Systematic Testing

阶段4：系统化测试

Use the automated test script (

scripts/test_warrior.sh

) for consistent evaluation:

bash

./scripts/test_warrior.sh warrior.red

Testing principles:

Run sufficient rounds (100+) for statistical significance
Track results in a structured format across iterations
Test against ALL opponents after every change, not just the one being targeted
Record parameter values alongside results for later analysis

使用自动化测试脚本（

scripts/test_warrior.sh

）进行一致性评估：

bash

./scripts/test_warrior.sh warrior.red

测试原则：

运行足够轮次（100+）以保证统计显著性
在迭代过程中以结构化格式跟踪结果
每次修改后测试所有对手，而不只是针对目标对手
记录参数值和对应结果，以便后续分析

Phase 5: Parameter Optimization

阶段5：参数优化

When tuning parameters (step sizes, gate positions, spl counts):

Systematic search - Use grid search or binary search over parameter ranges
Understand relationships - Document why certain values work (e.g., step=17 avoids common bombing intervals)
Track tradeoffs - Changes that improve one matchup may harm another
Hypothesis-driven changes - Before each modification, state the expected outcome

Key parameters to tune:

Step size for bombers/scanners (affects coverage pattern)
Gate position for imp defenses
Number of SPL instructions (affects process count vs. speed)
Starting offset from main code

调整参数（步长、闸门位置、spl数量）时：

系统化搜索 - 在参数范围内使用网格搜索或二分搜索
理解参数关系 - 记录某些值有效的原因（例如，步长=17可避开常见轰炸间隔）
权衡利弊 - 改善一个对战结果的修改可能会损害另一个
基于假设的修改 - 每次修改前，说明预期结果

需要调优的关键参数：

轰炸机/扫描器的步长（影响覆盖模式）
Imp防御的闸门位置
SPL指令的数量（影响进程数与速度的平衡）
主代码的起始偏移量

Phase 6: Debugging Failures

阶段6：故障调试

When a warrior consistently loses to an opponent:

Profile the failure - Use pmars debugging to watch the battle:
bash
```
pmars -b -r 1 warrior.red opponent.red
```
Identify failure mode - Is the warrior being bombed, captured, out-replicated, or core-cleared?
Trace causation - At what point in the battle does the warrior lose control?
Develop targeted fix - Address the specific failure mechanism, not symptoms

当战士持续输给某个对手时：

分析故障情况 - 使用pmars调试功能观察对战：
bash
```
pmars -b -r 1 warrior.red opponent.red
```
确定故障模式 - 战士是被轰炸、捕获、复制压制还是核心被清除？
追踪因果关系 - 战士在对战的哪个节点失去控制权？
开发针对性修复方案 - 解决具体的故障机制，而非症状

Phase 7: Multi-Opponent Optimization

阶段7：多对手优化

When facing different win rate requirements:

Prioritize high-threshold opponents - Focus more effort on 75% targets than 33% targets
Consider specialized warriors - Sometimes separate warriors per opponent outperform one universal warrior
Identify compatible strategies - Find approaches that don't harm each other
Accept strategic tradeoffs - A warrior optimized for hard targets may sacrifice performance on easy targets

面对不同胜率要求时：

优先处理高阈值对手 - 花更多精力在75%胜率目标上，而非33%的目标
考虑专用战士 - 有时为每个对手单独开发战士的表现优于通用战士
寻找兼容策略 - 找到不会相互影响的方法
接受策略权衡 - 针对硬目标优化的战士可能会牺牲在简单目标上的表现

Common Pitfalls

常见陷阱

Mistakes to Avoid

需避免的错误

Ad-hoc parameter changes - Changing values without clear hypotheses leads to random walks
Ignoring opponent code - Reading behavior isn't understanding; examine the actual source
Over-engineering early - Complex multi-component warriors obscure what works and what doesn't
Neglecting hardest opponents - Easy wins don't compensate for failing required thresholds
Batch testing - Test after EVERY change to understand impact immediately
Syntax/spacing issues - Redcode assemblers are sensitive; verify syntax with dry runs
Copying without understanding - Adapting code from examples requires understanding why it works

临时参数修改 - 没有明确假设就修改值会导致无意义的尝试
忽略对手代码 - 只观察行为不等于理解，要检查实际源代码
过早过度设计 - 复杂的多组件战士会掩盖有效和无效的部分
忽视最难对付的对手 - 轻松获胜无法弥补未达到要求阈值的失败
批量测试 - 每次修改后立即测试，以了解影响
语法/空格问题 - Redcode汇编器对格式敏感；通过试运行验证语法
盲目复制 - 改编示例代码时需要理解其工作原理

Red Flags During Development

开发中的危险信号

Making changes without being able to explain expected improvement
Win rate oscillating without trending upward
Spending most time on already-passing matchups
Not using debugging tools to understand failures
Submitting warriors that don't meet all thresholds

无法解释修改预期的改进效果
胜率波动但没有上升趋势
大部分时间花在已经通过的对战上
不使用调试工具理解故障
提交未达到所有阈值的战士

Verification Checklist

验证清单

Resources

资源

scripts/

Contains

test_warrior.sh

- An automated test script that runs battles against all opponents and reports results in a consistent format. Use this for every iteration to track progress systematically.

包含

test_warrior.sh

- 一个自动化测试脚本，可与所有对手进行对战并以一致格式报告结果。在每次迭代中使用它来系统地跟踪进度。

references/

Contains

corewars_strategies.md

- Reference documentation covering CoreWars warrior archetypes, common patterns, and known effective techniques. Consult this before implementing unfamiliar strategies.

包含

corewars_strategies.md

- 参考文档，涵盖CoreWars战士原型、常见模式和已知有效技术。在实现不熟悉的策略前查阅此文档。