기술 블로그

3D 장면이 무거울 때는 폴리곤 수를 줄이는 것 못지않게 보이지 않는 것을 일찍 걸러내는 일이 중요하다. 백페이스, 프러스텀, 오클루전 컬링은 비슷해 보여도 해결하는 문제가 서로 다르고 비용 구조도 다르다. 안 보이는 이유가 방향 때문인지, 시야 밖이기 때문인지, 가려졌기 때문인지 구분해서 적용해야 한다는 점을 OpenGL과 Unity 문서를 함께 정리한다.

고차 함수와 데이터·로직 분리는 프로그램을 똑똑하게 만드는 마법이 아니라, 반복되는 패턴을 함수로 묶고 자주 바뀌는 설정을 코드 밖으로 빼서 변경 비용을 낮추는 추상화에 가깝다. SICP와 Unity ScriptableObject 사례를 함께 보면서, 게임처럼 규칙과 예외가 계속 늘어나는 환경에서 무엇을 코드로 두고 무엇을 데이터로 뺄지 가르는 기준을 정리한다.

RPG 몬스터 설계의 첫 질문은 ‘이 정보가 모든 고블린에게 공통인가, 이 한 마리만의 상태인가’다. 플라이웨이트 패턴처럼 타입 데이터와 개체 상태를 분리하면 메모리 중복뿐 아니라 수정 범위까지 함께 좁아지고 데이터 의미도 선명해진다. 오브젝트 풀은 멋이 아니라 생성·해제 빈도가 실제 병목일 때만 얹는 최적화라는 점도 함께 정리한다.

WinAPI로 게임 개발을 시작할 때 가장 먼저 이해해야 할 것은 창 만드는 함수가 아니라, 메시지를 받아 윈도우 프로시저로 보내는 Win32의 흐름 자체다. Win32와 Winsock은 자주 함께 등장하지만 역할이 다르므로 분리해서 익히는 편이 낫다. 입문자는 거대한 설계보다 작은 루프부터 직접 움직여 보는 순서를 정리한다.

스타크래프트 봇 개발은 프로게이머 빌드를 코드로 옮기는 작업이라기보다, 공개 API로 게임 상태를 관측하고 그 위에서 행동을 선택하는 에이전트를 만드는 작업이다. BWAPI와 SC2 API, 리플레이 분석을 활용해 ‘관측 → 해석 → 행동’ 파이프라인을 만드는 입문 순서가 메모리 해킹보다 훨씬 현실적이라는 점을 정리한다.

스타크래프트의 마이크로가 깊이로 남은 이유는 단순히 손이 빠른 게임이라서가 아니다. Move·Attack-Move·Hold Position·Stop 같은 기본 명령의 차이를 자동화하지 않고 플레이어가 직접 해석해 개입하게 만든 설계 때문이다. 불편함과 깊이가 함께 있는 이 RTS의 조작 감각이 어떻게 실력 표현의 공간이 되었는지를 정리한다.

게임 디자이너는 보상의 양을 자주 고민하지만, 실제로 더 자주 문제를 만드는 것은 도전의 조절이다. 칙센트미하이의 플로우처럼 실력과 난이도가 맞물릴 때 몰입이 생기며, 보상은 진행감을 보강할 뿐 대체하지 못한다. 좋은 밸런스는 정답이 아니라 ‘플레이어가 다음 도전에 다시 손을 뻗을 이유’를 계속 만들어 주는 일이라는 점을 정리한다.

작은 팀이 자유롭게 느껴지는 이유는 낭만이나 재능이 아니라 의사결정 거리가 짧고 실패 비용이 낮기 때문이다. 반대로 큰 팀의 답답함도 단순한 관료주의가 아니라 변경 한 번의 파급 비용이 넓어진 결과에 가깝다. 라미 이스마일과 Wolfire 사례를 빌려, 핵심은 팀 규모 자체가 아니라 실험과 수정의 왕복 시간을 어떻게 짧게 유지하느냐에 있다는 점을 정리한다.

Wolfire의 Overgrowth 사례가 보여 준 오픈 개발의 핵심은 화려한 기술 시연이 아니라, 선주문·주간 알파·비공개 포럼·블로그를 하나의 운영 구조로 묶어 자금·피드백·신뢰를 한꺼번에 쌓은 데 있다. 오픈 개발이 ‘솔직해 보이기’가 아니라 개발 리스크를 커뮤니티와 공유하는 운영 방식이라는 점, 그리고 인디 팀에 그 의미가 큰 이유를 정리한다.

MMORPG 서버 설계의 진짜 문제는 ‘방을 몇 개로 나눌까’가 아니라 ‘각 플레이어에게 지금 무엇이 relevant한가’를 어떻게 싸게 계산하느냐다. 거리 기반 필터링과 공간 분할 같은 interest management가 그래서 중요하다. 좋은 서버는 많이 보내는 구조가 아니라 ‘어떻게 덜 보내도 충분하게 만들까’를 푸는 구조에 가깝다는 점을 정리한다.