실무자가 말하는 게임 개발

오늘 프로젝트를 맡겨준 회사 대표님께서 특강을 해주셔서 그 내용을 정리해봤습니다.

레벨 디자인 - 유저는 생각보다 관대하지 않음

• 요즘 사람들은 어려움을 잘 못 견딤. 참을성이 예전 같지 않음
• 그래서 내가 재밌다고 생각하는 난이도보다 한 단계 더 쉽게 만들어야 함
• 개발자는 이미 게임을 손에 익힌 상태라 체감 난이도가 왜곡됨
• 유저한테 뽕맛을 느끼게 해주는 게 중요함. 다 때려부수는 시원한 느낌
• 실력으로만 승부하게 하면 재미없을 수 있음 → 확률 요소나 사기적인(OP) 요소를 섞어주는 게 좋아 보임

이 부분이 특히 우리 게임에도 바로 적용 가능한 얘기였음. 타워디펜스 쪽 밸런싱할 때 참고할 만함.

코드 붕괴를 막는 습관

• 자주, 작게 커밋하기
• 푸시 전에 게임 켜지는지 반드시 확인
• 위험한 명령어는 되돌릴 수 있는지 먼저 확인
• 팀이면 같은 파일 동시 수정 안 하도록 역할 분담. 충돌 지옥 방지

수치는 한 곳에서 관리

• 게임 안의 수치는 하나로 통일해야 함. 안 그러면 툴팁에 적힌 값이랑 실제 적용되는 값이 달라지는 참사가 생김
• 주인(원본)은 한 곳에서만 정하고, 나머지는 그 값을 참조해서 물어보도록 구현해야 함
• 유니티에는 이걸 대비한 표준 자료 구조가 있음 (우리도 ScriptableObject / DataTable로 관리 중인 부분)

회귀 위험 (Regression)

• 전에 고쳤던 버그가 나중에 또 다시 살아날 수 있음
• 그래서 느리게 가더라도 탄탄하게 가는 게 결국 이득임
• 리팩토링과 모듈화가 잘 되어 있어야 회귀도 줄고 유지보수도 편함

만든 사람은 자기 게임을 못 봄

• 만든 사람은 객관적으로 자기 게임을 볼 수 없음
• 플레이어는 내 상상과 전혀 다른 곳에서 웃고, 전혀 다른 곳에서 막힘
• 내 자리에선 안 보이던 문제가, 남의 자리에선 첫 실행 몇 분 만에 터짐
• 그러니 살짝이라도 어물쩡한 느낌이 들면 과감하게 갈아엎는 게 낫다

일하는 방식

• 하루 끝에 "오늘 게임이 어제보다 뭐가 좋아졌나" 스스로 물어보기
• 할 일은 그냥 메모장에 적어두기
• 큰 결정은 바로 지르지 말고 작게 먼저 시험해보기