게임 개발 기술과 구조 이해

기술은 아이디어의 현실 조건이다

좋은 게임 디자인은 결국 실행되어야 한다. 규칙, 조작감, 레벨, 밸런스가 아무리 좋아도 엔진 안에서 구현되지 않으면 플레이어는 경험할 수 없다. 그래서 디자이너와 기획자도 기술의 기본 구조를 알아야 한다.

기술을 이해한다는 것은 직접 모든 코드를 짠다는 뜻이 아니다. 무엇이 쉬운 변경이고, 무엇이 위험한 변경인지 구분하는 능력이다. 이 감각이 있으면 더 현실적인 기획을 하고, 개발자와 더 정확하게 대화할 수 있다.

엔진은 게임을 담는 작업 환경이다

Unity, Unreal, Godot은 서로 다르지만 많은 엔진이 비슷한 기본 개념을 공유한다. 먼저 씬은 게임의 한 장면 또는 상태를 담는 공간으로 이해할 수 있다. 마을, 전투 맵, 메뉴 화면처럼 구분할 수 있다. 엔진마다 이름과 관리 방식은 다르지만, 게임을 여러 장면이나 상태로 나누어 다룬다는 생각은 공통적으로 유용하다.

씬 안에는 오브젝트가 있다. 캐릭터, 문, 총알, 카메라, 조명, UI 버튼도 모두 오브젝트가 될 수 있다. 오브젝트는 혼자 모든 기능을 갖지 않고, 여러 컴포넌트나 스크립트, 노드 같은 단위로 역할을 얻는다. 예를 들어 플레이어 오브젝트에는 위치 정보, 충돌체, 애니메이션, 입력 처리, 체력 같은 기능이 붙는다.

이 구조를 이해하면 기능을 더 작게 나누어 생각할 수 있다. "플레이어를 만든다"가 아니라 "입력, 이동, 충돌, 피격, 애니메이션, 사운드를 연결한다"로 바뀐다. 좋은 구현은 큰 덩어리를 작은 책임으로 나누는 데서 시작된다.

게임은 프레임마다 갱신된다

게임은 정지된 화면이 아니라 아주 빠르게 반복되는 계산이다. 매 프레임마다 입력을 읽고, 캐릭터 상태를 바꾸고, 물리를 계산하고, 충돌을 확인하고, 애니메이션을 갱신한 뒤 화면을 그린다. 이것을 넓게 게임 루프라고 부른다.

플레이어가 버튼을 누르면 즉시 결과가 나와야 조작감이 좋다. 하지만 실제로는 입력 처리, 이동 계산, 충돌 판정, 애니메이션 전환, 사운드 재생이 순서대로 연결된다. 이 중 하나가 늦거나 어긋나면 "반응이 둔하다", "맞았는데 안 맞은 것 같다", "점프가 불안정하다"는 느낌이 생긴다.

물리와 충돌도 마찬가지다. 벽에 닿았는지, 공격 범위 안에 들어왔는지, 총알이 적을 맞혔는지는 모두 규칙이 아니라 계산으로 판정된다. 디자인 문서에는 "검이 적을 맞힌다"라고 쓰지만, 구현에서는 공격 범위, 판정 시간, 우선순위, 무적 시간까지 정해야 한다.

하드코딩을 줄이면 수정 속도가 빨라진다

초보자가 자주 하는 실수는 수치를 코드 안에 직접 박아 넣는 것이다. 예를 들어 공격력 10, 이동 속도 5, 적 체력 100을 코드에 고정하면 수정할 때마다 개발자의 손을 거쳐야 한다. 이런 방식은 작은 프로젝트에서는 빠르지만, 밸런스를 반복해서 조정해야 하는 게임에서는 곧 병목이 된다.

그래서 수치는 코드가 아니라 데이터로 빼는 것이 좋다. 표, JSON, CSV, 데이터 에셋, 스크립터블 구조 등 프로젝트에 맞는 방식을 사용하면 디자이너가 직접 값을 바꾸고 테스트하기 쉬워진다. 적의 체력, 드롭률, 스킬 쿨타임, 상점 가격, 경험치 곡선은 데이터화하기 좋은 항목이다.

좋은 구조는 "기능을 만드는 코드"와 "내용을 조정하는 데이터"를 분리한다. 코드는 규칙을 실행하고, 데이터는 그 규칙의 값을 제공한다. 이 차이를 이해하면 밸런스 수정 속도가 크게 빨라진다.

저장과 로딩은 나중에 붙이기 어렵다

세이브 데이터는 단순히 현재 점수를 저장하는 문제가 아니다. 플레이어 위치, 인벤토리, 퀘스트 진행도, 해금 상태, 설정값, 난이도, 플레이 시간 등 무엇을 저장할지 정해야 한다. 더 중요한 것은 나중에 게임이 업데이트되었을 때 예전 저장 파일을 어떻게 읽을지다.

초보 프로젝트에서는 저장 구조를 늦게 생각하다가 문제가 생긴다. 아이템 이름을 바꾸었더니 세이브가 깨지고, 스테이지 구조를 수정했더니 플레이어가 없는 위치에서 시작하며, 버전이 달라져 로딩이 실패하는 식이다.

초기부터 저장할 데이터와 저장하지 않을 데이터를 구분해야 한다. 또한 버전 정보를 함께 저장해 두면 업데이트 후 변환 처리를 할 수 있다. 저장은 기능의 끝이 아니라 게임 구조의 일부다.

성능 문제는 대부분 누적에서 온다

게임이 느려지는 이유는 하나가 아니다. 프레임레이트가 떨어지는 것은 한 프레임 안에 처리할 일이 너무 많다는 뜻이다. 적이 너무 많거나, 이펙트가 과하거나, 물리 계산이 복잡하거나, 화면에 그려야 할 오브젝트가 많을 수 있다.

메모리는 불러온 이미지, 사운드, 모델, 애니메이션 데이터가 차지한다. 필요 없는 리소스를 계속 들고 있으면 로딩이 길어지고 기기가 버티지 못한다. 드로우콜은 화면에 물체를 그리기 위해 그래픽 장치에 요청하는 횟수다. 요청이 지나치게 많으면 단순한 화면도 느려질 수 있다.

온라인 게임에서는 네트워크 지연도 중요하다. 플레이어가 입력한 순간과 서버가 결과를 확정하는 순간 사이에 차이가 생긴다. 그래서 실시간 대전 게임은 판정, 예측, 보정, 동기화 문제를 함께 설계해야 한다.

기술을 아는 디자이너가 더 강한 선택을 한다

기술 지식은 창의성을 제한하지 않는다. 오히려 어떤 아이디어가 비싼지, 어떤 구조가 오래 버티는지, 어떤 기능을 먼저 검증해야 하는지 알려 준다.

디자이너가 엔진의 장면과 오브젝트 구조를 이해하면 요구사항을 더 명확히 쓸 수 있다. 게임 루프를 이해하면 조작감과 판정 문제를 더 정확히 말할 수 있다. 데이터 구조를 이해하면 밸런스 조정이 빨라진다. 저장과 성능을 이해하면 출시 직전의 큰 사고를 줄일 수 있다.

게임은 감각의 예술이지만 동시에 구조의 산물이다. 기술을 이해한 기획은 구현 가능성을 얻고, 구현을 이해한 디자인은 더 단단한 재미를 만든다.