게임 프로그래밍은 감으로 한다고요? 숫자가 먼저 봅니다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

손맛을 믿기 전에 남길 작은 숫자들

프레임, 입력, 충돌을 한 줄씩 적는 습관

게임 프로그래밍에서 가장 많이 듣는 말 중 하나가 손맛은 감으로 맞춘다는 이야기입니다. 물론 마지막 판단에는 감각이 필요합니다. 하지만 감각만 믿으면 어제 좋았던 점프가 오늘은 왜 둔하게 느껴지는지 설명하기 어렵습니다.

Will Perone 같은 개인 개발자 포트폴리오를 살펴볼 때도 화려한 결과물보다 먼저 보이는 것은 작은 실험을 끝까지 검증하는 태도입니다. 데모가 작을수록 더더욱 수치 기록이 강력합니다. 복잡한 분석 플랫폼을 붙이지 않아도, 콘솔 로그와 CSV 한 장이면 게임 플레이의 흐름이 선명해집니다.

숨겨진 팁은 간단합니다. 모든 값을 다 기록하지 말고, 플레이어가 불편함을 느끼는 순간과 직접 연결되는 값만 남기세요. 예를 들어 점프 게임이라면 프레임 시간, 입력 시점, 착지까지 걸린 시간, 충돌 판정 실패 횟수만 있어도 충분합니다.

• 입력 지연: 키를 누른 프레임과 캐릭터가 반응한 프레임 차이를 남깁니다.
• 점프 체공 시간: 체공 시간이 의도보다 길면 조작은 가벼운데 게임은 느슨해집니다.
• 충돌 보정 횟수: 벽에 끼거나 계단에서 덜컥거리는 순간을 숫자로 잡습니다.
• 카메라 추적 오차: 플레이어 위치와 카메라 중심의 차이를 매초 평균으로 봅니다.

팁: 로그 이름은 멋지게 짓지 말고 input_delay_ms, jump_air_time, camera_error처럼 바로 읽히게 두는 편이 나중에 훨씬 빠릅니다.

툴을 새로 만들지 않고 툴처럼 쓰는 꿀팁

스프레드시트와 텍스트 파일이 의외로 강하다

많은 개발자가 게임 프로그래밍 툴을 처음부터 크게 만들려고 합니다. 하지만 작은 포트폴리오 프로젝트에서는 에디터 확장보다 잘 정리된 텍스트 파일이 먼저입니다. JSON, INI, CSV처럼 눈으로 읽을 수 있는 포맷을 쓰면 빌드 없이 밸런스를 바꿔 볼 수 있습니다.

예를 들어 enemy.csv에 체력, 속도, 공격 간격, 감지 범위를 넣어 두면 기획과 프로그래밍 사이의 대화가 빨라집니다. 여기서 말하는 기획은 거창한 직무 구분이 아닙니다. 게임의 규칙과 경험을 설계하는 일에 가깝고, 관련 용어는 기획자에 대한 설명처럼 역할 중심으로 보면 이해가 쉽습니다.

생활 해킹처럼 쓸 수 있는 방식도 있습니다. 값 하나를 바꿀 때마다 결과를 새 빌드로 확인하지 말고, 개발자 모드에서 단축키로 파일을 다시 읽게 만드세요. 이 작은 기능은 포트폴리오 품질을 크게 올립니다. 보는 사람은 코드보다 먼저 반복 속도를 느낍니다.

1. 게임 시작 시 balance.json을 읽습니다.
2. F5 같은 개발자 전용 키로 같은 파일을 다시 로드합니다.
3. 화면 한쪽에 현재 적용된 값을 작게 표시합니다.
4. 바꾼 값이 마음에 들면 파일에 주석처럼 이유를 남깁니다.

작은 표 하나로 밸런스 토론 줄이기

아래처럼 비교표를 만들면 감으로 이어지던 논쟁이 빨리 끝납니다. 복잡한 대시보드가 없어도 충분합니다.

• 플레이어 이동속도 4.5: 조작은 안정적이지만 맵이 넓게 느껴집니다.
• 플레이어 이동속도 5.2: 탐험은 경쾌하지만 좁은 발판에서 미끄럽습니다.
• 플레이어 이동속도 4.9: 초반 튜토리얼과 보스전 모두에서 무난합니다.

수학 라이브러리를 무겁게 쓰지 않는 방법

벡터와 보간은 디버그 화면에 먼저 올린다

게임 프로그래밍에서 math는 성능만의 문제가 아닙니다. 벡터, 행렬, 보간, 난수, 충돌 계산은 플레이어가 느끼는 감각으로 바로 이어집니다. 그래서 수학 코드는 숨겨 두기보다 화면 위에 드러내는 편이 좋습니다.

예를 들어 캐릭터가 목표 지점으로 이동할 때 현재 속도 벡터를 선으로 그리고, 목표 방향을 다른 색으로 표시해 보세요. 코드 리뷰보다 빠르게 문제가 보입니다. 캐릭터가 목적지에 가까워질수록 떨린다면 정규화, 임계값, 부동소수점 비교 중 하나가 원인일 가능성이 큽니다.

여기서 꿀팁은 수학 함수를 바로 최적화하지 않는 것입니다. 먼저 입력과 출력 범위를 저장하세요. lerp, smoothstep, normalize 같은 함수가 어떤 값을 받는지 기록하면, 나중에 최적화할 부분과 건드리면 안 되는 부분이 분리됩니다.

• normalize 전 길이: 0에 가까운 벡터가 들어오는지 확인합니다.
• lerp 계수: t 값이 0과 1 사이를 벗어나는지 봅니다.
• 충돌 법선: 튕김 방향이 이상하면 먼저 법선 벡터를 그려 봅니다.
• 랜덤 시드: 재현 가능한 버그를 위해 시드를 화면에 표시합니다.

전문가식 접근은 거창하지 않습니다. 같은 입력이면 같은 결과가 나오게 만들고, 그 결과를 눈으로 확인할 작은 장치를 붙이는 것입니다.

컨퍼런스식 지식보다 내 프로젝트식 실험

큰 게임 행사에서 나오는 강연은 방향을 잡는 데 도움이 됩니다. 예컨대 GDC 같은 게임 개발자 행사는 업계 흐름을 이해하는 참고점이 됩니다. 다만 개인 개발자가 그 방식을 그대로 복사하면 프로젝트 크기와 맞지 않을 수 있습니다.

작은 프로젝트에서는 발표 자료보다 내 코드에서 얻은 30초짜리 실험이 더 가치 있습니다. 카메라 감속을 바꾸고, 점프 중 중력 배율을 다르게 주고, 충돌 박스 크기를 5% 줄인 뒤 기록을 남기세요. 그 기록이 쌓이면 포트폴리오는 단순 결과물이 아니라 개발자의 판단 과정이 됩니다.

숫자를 모아도 망가지는 순간들

평균만 보다가 플레이 감각을 놓친다

숫자를 모으기 시작하면 또 다른 함정이 생깁니다. 평균 FPS, 평균 입력 지연, 평균 클리어 시간이 좋아졌다고 해서 게임이 반드시 좋아지는 것은 아닙니다. 플레이어는 평균이 아니라 특정 순간의 불편함을 기억합니다.

그래서 마지막으로 봐야 할 값은 평균보다 최악의 순간입니다. 60프레임을 유지하다가 보스 등장 때 200ms가 밀리면 플레이어는 그 한 번을 기억합니다. 입력 지연도 대부분 20ms여도 특정 상황에서 90ms가 나오면 조작감은 무너집니다.

개인 프로젝트의 예산도 비슷합니다. 시간을 어디에 쓸지 정하지 않으면 툴, 이펙트, 리팩터링이 서로 예산을 잡아먹습니다. 자원 배분 관점은 계획예산 제도처럼 큰 조직의 개념에서도 힌트를 얻을 수 있습니다. 개발 시간 역시 한정된 예산이라고 보면 우선순위가 또렷해집니다.

• 실수 1: 로그를 너무 많이 남김 - 필요한 값을 못 찾을 정도로 로그가 많으면 결국 아무것도 보지 않게 됩니다.
• 실수 2: 성공한 플레이만 기록함 - 실패, 낙사, 취소 입력, 되돌아간 동선이 진짜 개선 지점입니다.
• 실수 3: 포트폴리오에 결과만 올림 - 문제, 실험, 바꾼 값, 다시 확인한 장면을 함께 남기면 developer로서의 설득력이 커집니다.

포트폴리오에는 멋진 말보다 재현 가능한 장면

Will Perone이라는 이름을 검색하는 사람은 결국 developer가 어떤 방식으로 문제를 푸는지 보고 싶어 합니다. 그래서 포트폴리오에는 추상적인 설명보다 재현 가능한 장면이 좋습니다. 같은 입력, 같은 시드, 같은 맵에서 전후를 비교할 수 있으면 글 하나가 작은 기술 문서가 됩니다.

마지막 팁은 간단합니다. 데모마다 debug_notes.md를 하나 두고, 바꾼 값과 이유를 세 줄만 남기세요. 며칠 뒤 다시 열어도 판단의 흐름이 살아 있고, 방문자는 단순한 게임 화면 너머의 game programming 역량을 읽게 됩니다.