10월 10일 올라온 이 글은 9월 12일 캘거리 인디 로데오 발표를 옮긴 것으로, 게임 동작 상당 부분이 코드 밖(에셋·씬·실행 상태·튜닝 값)에 있어 에이전트가 보지 못한다는 점을 문제로 꼽아요. 해법으로 난수 시드 하나로 상태를 재현하고, 모든 상태 변경을 기록·재생 가능한 명령으로 만들고, 게임 로직을 엔진과 떼어 엔진 없이 테스트하고, 스크린샷은 odiff 로 비교해 유사도 퍼센트를 평가 지표로 쓰고, 프로파일링도 텍스트로 내는 도구를 쓰라고 권해요. 저자는 작은 프로젝트에는 필요 없었고 개발 막바지에 덧붙이기는 매우 어렵다고 스스로 밝혔고, 속도 향상 수치는 내놓지 않았어요.
용어 풀이
- odiff
- 두 이미지를 비교해 차이 이미지와 유사도를 내는 오픈소스 명령줄 도구
- ECS
- Entity Component System, 게임 객체를 데이터 조각 단위로 나눠 다루는 설계 방식
- HN
- Hacker News, 개발자 커뮤니티 사이트
운영자 인사이트
게임이 아니어도 GUI·시뮬레이션처럼 결과가 코드 밖에 드러나는 시스템이라면, 에이전트에게 코드를 더 읽히기보다 상태 재현·명령 재생·텍스트로 된 측정값부터 마련하는 편이 반복을 빠르게 해요. 다만 HN 에서는 한 덩어리 객체 구조가 큰 게임에선 버티지 못한다는 반론도 나왔으니 규모에 맞춰 골라 쓰세요.
여러 관점으로 보기
- HN 토론 결정적 재생이 버그 재현에 쓸모 있다는 경험담이 이어졌지만, 모델이 기존 기능을 깨뜨리고 손맛(feel)을 못 잡으며 한 덩어리 객체 구조는 큰 게임에서 ECS 같은 설계가 필요하다는 반론도 나왔고, 저자는 한 번에 만드는 게임이 아니라 큰 프로젝트를 겨냥한 글이라고 답했어요. Hacker News