Booster Champion 仿真赛第一季正式把题目落在了 3v3 足球锦标赛上。这个方向很适合检验智能体能力：足球不是单点控制问题，三个队员要同时处理站位、传球、逼抢、射门和防守切换，仿真环境又能让团队快速迭代策略，而不被硬件损耗、场地预约和安全风险拖慢。
3v3 足球为什么比“单机器人跑得快”更难
3v3 的难点不在于让一个智能体追球，而在于让三个智能体形成稳定协作。
一个朴素策略可能是“三个人都冲向球”。它在早期测试里看起来很积极，但比赛中通常会暴露几个问题：队友互相挡路，后场无人保护，球权转换后回防太慢，射门角度被自己人压缩。
更实用的策略会把角色拆开：
striker：优先接近球、制造射门机会。support：站在可传球区域，避免和 striker 抢同一路径。defender：保持在球和己方球门之间，处理反击。
在仿真赛里，这类角色不一定要写死。可以根据球的位置、队员距离、比分和剩余时间动态切换。真正的工程重点，是让切换条件可解释、可调试，而不是把所有行为塞进一个黑盒函数。
仿真赛的价值：快迭代、可复现、能做回放分析
仿真环境最大的优势是复现。一次丢球到底是守门区域设计问题，还是两个智能体同时抢球导致空档？只要环境能记录状态，就可以把比赛片段拿出来反复跑。
可以这样组织训练和评估流程：
- 本地快速跑规则策略，确认基本行为不崩。
- 批量对战基线队伍，统计胜率、控球率、射门次数、失球来源。
- 保存关键回合的状态序列，用脚本回放并定位错误决策。
- 再引入强化学习、模仿学习或搜索策略，而不是一开始就把复杂模型堆上去。
这类赛事对参赛队伍的要求不是“写一个聪明函数”这么简单，而是要搭一条能持续验证策略的流水线。
可以这样实践：先写一个可替换的 3v3 策略骨架
下面是一个最小 Python 示例，用来演示 3v3 足球智能体的角色分配。它不依赖具体赛事 SDK，属于可改造的伪项目骨架：你需要把 state 的字段替换成实际仿真环境提供的数据结构，把返回的动作映射到比赛 API 支持的控制指令。
保存为 team_policy.py 后可直接运行，先观察角色分配是否符合预期。
from dataclasses import dataclass
from math import hypot
from typing import Dict, List, Tuple
Point = Tuple[float, float]
@dataclass
class Player:
id: int
pos: Point
@dataclass
class GameState:
ball: Point
teammates: List[Player]
own_goal: Point = (-52.5, 0.0)
opponent_goal: Point = (52.5, 0.0)
def distance(a: Point, b: Point) -> float:
return hypot(a[0] - b[0], a[1] - b[1])
def move_towards(target: Point, speed: float = 1.0) -> Dict:
return {"type": "move", "target": target, "speed": speed}
def assign_roles(state: GameState) -> Dict[int, str]:
players = sorted(state.teammates, key=lambda p: distance(p.pos, state.ball))
return {
players[0].id: "striker",
players[1].id: "support",
players[2].id: "defender",
}
def decide_actions(state: GameState) -> Dict[int, Dict]:
roles = assign_roles(state)
actions = {}
for player in state.teammates:
role = roles[player.id]
if role == "striker":
actions[player.id] = move_towards(state.ball, speed=1.0)
elif role == "support":
# 站在球的斜后方，给 striker 留出射门路线。
support_spot = (state.ball[0] - 8.0, state.ball[1] + 10.0)
actions[player.id] = move_towards(support_spot, speed=0.8)
else:
# defender 保持在球和己方球门之间。
guard_spot = (
(state.ball[0] + state.own_goal[0]) / 2,
(state.ball[1] + state.own_goal[1]) / 2,
)
actions[player.id] = move_towards(guard_spot, speed=0.9)
return actions
if __name__ == "__main__":
state = GameState(
ball=(10.0, 5.0),
teammates=[
Player(id=1, pos=(3.0, 4.0)),
Player(id=2, pos=(-10.0, 12.0)),
Player(id=3, pos=(-30.0, -5.0)),
],
)
for player_id, action in decide_actions(state).items():
print(f"player={player_id} action={action}")
运行：
python team_policy.py
你可以继续加三类测试：
# 可改造成 pytest：检查最近球员是否成为 striker
state = GameState(
ball=(0.0, 0.0),
teammates=[Player(1, (1.0, 0.0)), Player(2, (9.0, 0.0)), Player(3, (20.0, 0.0))],
)
assert assign_roles(state)[1] == "striker"
这个骨架很简陋，但它有一个好处：角色分配、目标点和动作输出是分开的。后面接入真实仿真 API 时，可以只替换动作适配层，而不用推翻整套策略结构。
参赛前应该补齐的工程清单
准备 Booster Champion 这类 3v3 仿真赛，不建议只盯着模型效果。更稳的做法是先把比赛工程能力搭起来：
- 固定随机种子，保证关键失败案例能复现。
- 给每场比赛输出结构化日志，例如球位置、角色、动作、射门和失球事件。
- 建立基线队伍，不要只和最新版自己对打。
- 把策略参数放到配置文件里，避免每次调站位都改代码。
- 关注边界状态：开球、球出界、队员重叠、时间快结束、比分落后。
风险也很明确：仿真里有效的策略不一定能迁移到真实机器人；过度针对某个基线队伍调参，也可能导致泛化能力变差。比较务实的路线是先用规则策略跑通闭环，再逐步把局部决策替换成学习模型。3v3 足球的乐趣就在这里：它逼着你同时写控制、协作、评估和调试工具，任何一个环节薄弱，都会在比赛里被放大。