구조를 이해하지 못하면 발생하는 것들
게임을 제작할 때에는 반드시 그래픽 리소스, 기획이나 플랜 혹은 게임 디자인이 필요하고, 프로그래머의 역활과
그것을 총괄하는 프로듀싱 능력이 필요합니다. 혹은 그 모든 것들을 혼자서 해야 한다면 더욱 어려운 상황을
자주 맞이하게 되고 구조에 대한 이해가 뒷받침 되지 않으면 해결을 하기 어려워집니다.
오늘 이야기는 특정 파트가 문제라는 것이 아닌 혼자서 개발을 할 때 결국 프로그래밍을 해야하는데
자신이 프로그래밍으로 어떻게 해결 할 것인가에 대한 것과 프로그래밍이 귀찮아지면서 발생하는 원인들에
대해서 이야기를 해볼까 합니다.
불가능한 것은 없다 다만 찾으려고 하지 않을뿐
게임에서 다양한 연출을 구현하려고 할 때, 그래픽으로 할 수 있는 것이 좋은가? 혹은
프로그래밍으로 해결하는 것이 더 효과적인가를 두고 많은 논의와 논쟁이 벌어지곤 합니다.
프로젝트에 따라 달라지고 2D인가 3D인가에 따라서도 달라지겠지만 대부분 프로그래밍 파트에서
안된다고 말하는 경우는 바로 빠듯한 스케줄 때문이지 불가능한것은 없습니다.
예를들어 3D환경에서 2D 스프라이트 캐릭터가 라이팅이 되는 경우에 반사광을 넣고 싶고
실시간이 아니더라도 그것을 표현하려고 했을 때 현재 환경에서는 쉐이더로 처리가 가능하지만
그것마저도 불가능한 상황에서 2D 스프라이트를 2장을 겹쳐 뒤쪽에 드로우 하는 것은 라이트 컬러로
설정해서 구현하자고 제안하면 프로그래머는 이렇게 대답합니다.
쓸모없는 리소스로 인한 최적화가 어렵다.
현재 구조에서 그것을 구현하려면 하드코딩이 들어가기에 코드 관리가 어렵다.
프로그래밍을 해보지 않은사람들에겐 ‘아…어렵구나, 포기해야 하는 사안이구나’ 라고 생각하겠지만
프로그래밍을 해봤다면 그냥 귀찮고 내가 생각한 구조가 아니기에 버그가 날 확률이 높아지는 것을 피하는 것입니다.
또한 위에서 언급한 리소스의 문제라면 코드로 몇 줄로 해결이 가능한 경우도 존재하지만 그것을 그래픽이나 다른 파트에
알려주진 않으며 반드시 이야기를 해야 하는 상황이라면 스케줄을 늘리고 마치 대단한 업적을 달성한듯 이야기 하기도 합니다.
그리고 이것을 자신이 모두 해야 한다면 납득이 가고 프로그래머의 변명을 자신도 하고 있게 됩니다.
게임을 좋아하지 않는 프로그래머가 만드는 버그
게임을 플레이 하면서 한번쯤은 경험해봤을 큰 몬스터와의 전투에서 던전이나 좁은 길 혹은 문에
몬스터가 더이상 다가오지 못하고 문에 끼어 바보짓을 하며 플레이어는 원거리로 공격을 하는 상황에 직면했을 때에
게임에 대해서 관심이 없거나 직접 플레이를 하지 않는 프로그래머들이 시키는대로만 작업을 할 경우 이런 상황을
그저 방치해버립니다. 하지만 명확하게 조건이 존재하기에 프로그래밍을 할 줄 안다면 해결방안은,
[조건]
- 몬스터의 주변에 플레이어가 존재한다면? 다가간다
- 몬스터의 공격범위에 플레이어가 있다면? 공격 그게 아니라면 이동
- 다가갈 수 있는 범위에 플레이어가 존재하지만 이동할 수 없다면? 조건문
- 조건문에서 몬스터 자신이 피격당할 경우 && 움직일 수 없다면? 피격 방향으로 순간이동
이외에도 얼마든지 게임을 설계한 사람이 대체 방법을 구할수 있음에도 이런 상황이 벌어지는 이유는 대부분
프로그래머라면 알고 있지만 더이상 노력하고 싶지 않고 월급쟁이이기에 시키는대로만 코딩하는 경우도 있습니다.
그 외에도 길찾기 알고리즘을 쓰지 않고 그냥 가장 가까운 좌표로 플레이어에게 이동시킨다면 벽 넘어에 있는
플레이어에게 가려고 벽을 비비며 제자리 이동을 하는 경우도 발생합니다.
만드는 입장과 플레이 하는 입장차이
만드는 입장과 플레이하는 입장에서는 엄청난 차이가 있는데, 예를 들어 과거에는 연출에 스킵이라는
기능이 없었던 시절이 더 길었지만 어느 순간부터 유저들은 지루해지고 스토리를 보기 꺼려하며 넘기고 싶어
버튼을 연타하거나 어떻게든 그것을 벗어나기 위해 발악하는 모습을 보고 스킵 기능을 넣기 시작했습니다.
스킵은 어느 구간을 넘기는 간단한 것으로 그냥 버튼을 오래 누르면 다음 장면이나 다음 씬 혹은 플레이가
시작될 구간으로 이동 시키는 것이 전부입니다. 하지만 구체적으로 들어가면
화면에 스킵을 띄울 UI가 필요하고 실수로 누르지 않게 하기 위해서 버튼을 길게 눌러 지속시키거나
도중에 버튼에서 손을 떼고 캔슬이 되는 기능을 만들어야 하며 또한 그것을 시각적으로 표현해야 하기 위해
더 많은 코드가 필요합니다. 플레이어에겐 1-2초만에 벌어지는 상황이지만 만드는 입장에선 무척 귀찮습니다.
이외에도 겉으로 보기엔 별 것 없는 것들이 구조적으로는 많은 워크플로어가 발생합니다.
누가 좀 해줬으면 좋겠지만 어려운 이유
프로그래밍만 해도 힘든데 연출, 그래픽, 애니메이션, 그리고 가장 중요한 밸런스 테스트등 해야 할 것들이
너무 많다보면 테스트만으로 구토가 나올 정도로 많은 테스트를 진행하게 되며 특히 밸런스를 잡지 않고
테스트를 해야 한다면 수천번을 플레이해야 합니다. 예를들어 레벨업 시스템이나 스테이터스의 변동 수치 혹은
아이템이나 장비등을 수시로 변경하다보면 점차 코드를 관리해야 하는 입장에서는 어느 순간 무엇을 고쳐서
발생한 버그인지 알기 어려워지기도 합니다. 그렇기에 한 번에 완성시키고 싶어 보다 나은 기획과 밸런스 테스트등은
누군가 해줬으면 좋겠다고 생각하게 되지만 게임의 구조나 지식이 없는 사람에게 맡기면 엉뚱한 아이디어만 내거나
그 사람이 시행착오를 할 때까지 기다려줘야 합니다.
예를 들면, 이번 시나리오 연출은 어떻게 해야 할까요?
- 멋지게 해주세요
- 화려하고 막 불꽃튀고 펑펑터지게
- 그래픽을 하시는 분이니까 더 잘 아시겠죠(실제로 들었던말)
혹은 아마추어가 만든 기획서를 봐도 구체적인 것이 하나도 없습니다. 이것은 기획자를 까기위한 이야기가 아니며
게임 구조를 모르는 사람에게 맡기면 발생하는 이야기를 하고 있는 것입니다. (대부분 구체적이지 않은 형용사만 사용함)
(너무나 유명한 영상)
일반적인 게임의 구조에 대해서
일반적으로 게임의 구조는 그저 입력장치(키보드, 마우스, 터치, 게임패드등)에서 플레이어 조작으로
입력을 받고, 상태를 업데이트(캐릭터 움직임, 적AI등) 이후 화면을 그리는 것이며 그것을 초당
30-60으로 반복하는 것이 우리가 흔히 알고 있는 프레임이며 프레임이 높을수록 자연스럽게 움직이고
시각적으로 받아들이게 됩니다. 이런 순환 구조가 기본이며 플레이어가 무엇을 할 수 있고 없고를
규칙을 통해서 만드는 것이 게임이며 시스템은 언제 버튼을 누를 수 있고 버튼을 누르면 무엇이
발생하는지를 보여주는 것이 큰 틀로 보면 시스템입니다.
구조에 대한 이야기를 마치며
이외에도 게임 개발 기술에는 설명하지 못한 많은 이야기들과 제대로 설명이 되진 않았지만 게임을 만들 때
생각해야 할 부분들이 너무나 많습니다. 게임의 전체적인 루프, 게임의 플레이 방식, 게임의 플랫폼, 게임의 장르,
게임의 재미를 위한 구조, 전체적인 구조 및 세부적인 상황에서 어떻게 처리를 할 것인지 각자 만드는 방식에 따라서
구조가 달라지기에 한가지로 게임의 구조는 이렇다! 라고 말하긴 어렵습니다.
이야기의 핵심은 어떻게 만들려고 하더라도 해결책은 ‘이미 존재한다’라는 것과 귀찮지만 프로그래밍으로
구조를 정리하고 만드는 것들이 가능하다는 것입니다. 게임을 재밌게 만드는 것과는 별개의 문제이며
구조를 이해하지 않고 게임을 만든다면 완성은 어떻게든 되겠지만 엉성한 작품이 될 것이라는 생각과 함께
긴 이야기를 마칩니다.
