boardgame-studio: Skill for Cursor

자동 플레이 시뮬레이션

목적은 밸런싱이 아니다. 테이블에 들고 가기 전에 명백한 사고를 거르는 필터다.

사람을 모아놓고 30분 룰 설명을 했는데 게임이 안 끝나거나, 3라운드 만에 필승법이 드러나면 그 자리가 통째로 날아간다. 그런 사고를 미리 막는 게 전부다.

보드게임 밸런스는 소수점을 다투는 영역이 아니고, 그 정밀도는 시뮬로 얻을 것도 아니다. 30판 승률로 카드 수치를 조정하려 들면 오버피팅이다.

준비

ruleset.md 와 spec.json 이 있어야 한다. 룰북 없이는 LLM이 무엇을 근거로 플레이할지 알 수 없고, 그러면 이 워크플로우에서 가장 값진 "룰북만 읽고 이해되는가"를 확인하지 못한다.

진행

- [ ] 1. 무엇을 확인할지 정한다
- [ ] 2. 엔진을 구현한다
- [ ] 3. 스모크로 엔진을 검사한다
- [ ] 4. 비용을 추정한다
- [ ] 5. LLM으로 돌린다
- [ ] 6. 리포트를 뽑는다
- [ ] 7. 각 각도에서 검토하고 제안을 받는다

1. 무엇을 확인할지

먼저 사용자에게 묻는다. 이게 없으면 엔진을 어디까지 만들지도 정할 수 없고, 나중에 리포트를 받아도 무엇을 봐야 할지 모른다.

흔한 것들이다.

• 게임이 끝나기는 하는가
• 목표 플레이타임에 맞는가
• 3라운드 만에 결판나지는 않는가
• 아무도 안 쓰는 카드가 있는가
• 룰북만 읽고 플레이할 수 있는가
• 특정 개정(예: 시작 자원 5→4)이 의도한 효과를 냈는가

정해진 것을 --focus 에 그대로 넣는다. 로그에 남아서 리포트와 검토가 이 질문에 먼저 답하게 된다.

node tools/sim.mjs run <slug> --focus "3인에서 초반 확장이 너무 빠른지"

사용자가 특별히 말한 게 없으면 "전반 점검"으로 두고 진행한다.

2. 엔진

bgs-sim-engineer 에게 맡긴다. 전체를 구현하지 않아도 된다. 의심스러운 핵심 루프만 떼어내도 답이 나온다. 복잡한 게임을 통째로 만들려다 룰 개정이 무서워지면 본말이 전도된다.

엔진 상단의 rulesetVersion 은 ruleset.md 와 같아야 한다. 다르면 러너가 실행 전에 멈춘다.

3. 스모크

node tools/sim.mjs smoke <slug>

랜덤 봇으로 수천 판을 돌린다. 밸런스가 아니라 엔진 검사다. 교착, 무한 루프, 예외, 미종료 판을 잡는다. 게임별 전략 지식이 필요 없고 수천 판이 몇 초에 끝난다.

통과 못 하면 여기서 멈춘다. 교착에 빠지는 엔진으로 LLM 판을 돌리면 돈만 태운다.

4. 추정

node tools/sim.mjs estimate <slug>

판당 결정 수를 실측해 비용과 시간을 낸다. 판당 결정이 200회를 넘으면 그 자체로 게임이 너무 길다는 신호이니 룰셋을 한 번 보는 게 낫다.

5. 실행

node tools/sim.mjs run <slug> --games 30 --players 2,3,4

기본 30판이면 충분하다. 좌석 편중을 통계적으로 유의하게 잡으려면 5%p 차이에 300판, 3%p에 800판이 필요하지만, 그 정밀도는 시뮬로 얻을 게 아니라 테이블에서 얻어야 한다. 30판에서 한 좌석이 8할을 이긴다면 판수와 무관하게 명백한 사고고, 30판에서 안 보이는 편중은 대개 지금 걱정할 일이 아니다.

초기 배치는 같은 시드를 쓴다. 상황을 고정하고 판단만 흔들리게 해서 룰 개정 전후 비교의 노이즈를 줄인다. 그래도 LLM은 재현되지 않으므로 애매하면 결론을 내리지 않는다.

비용은 프롬프트 캐싱이 대부분을 결정한다. 룰북이 매 턴 동일한 시스템 메시지로 들어가서 자동으로 캐시되는데, 프롬프트가 1024토큰을 넘어야 캐시가 걸린다. 룰북이 짧으면 캐시가 안 걸려 비용이 예상보다 나올 수 있다.

설정

전부 studio.config.json 에 있다. 각 값이 왜 그런지는 파일 주석에 적혀 있으니 바꾸기 전에 읽는다.