■ '디토랜드로 게임 만들기' 기획기사 바로가기
└[프리뷰] 내가 만드는 가상월드 '디토랜드'
└[실전①] 뼈대를 알아야 살을 붙인다
└[실전②] 템플릿만 개조해도 반은 OK
└[실전③] 만들었으면 QA가 필요하다
└[실전④] QA 후, 피드백의 효과는 어땠을까
3편에서 QA 테스트를 진행하고 결과를 정리했으니, 남은 건 수정하는 일입니다. 그런 다음 다시 QA를 거쳐서 만족스러운 결과가 나오면 출시되는 게 일반적인 게임 출시 과정이죠.
피드백을 받고 개선하는 과정이나 수정할 항목을 분류하는 방식은 각 개발팀마다 다르겠지만, 이번에 디토랜드로 만든 '훼이크3'는 1) 파라미터만 수정하거나 워크스페이스 단계에서 바로 바꿀 수 있는 것 2) 기존 UI 및 스크립트 내부까지 손봐야 하는 것 3) 시스템 자체를 심층 분석해야 하는 것 이렇게 세 가지 항목으로 구분해두었습니다. 그리고 코스트가 덜 드는 순으로 1차 분류한 뒤 게임 밸런스 및 플레이에 영향을 미치는 정도를 2차로 분류해서 우선 수정해야 할 사항을 결정했죠.
그렇게 해서 우선 무기 밸런스 및 캐릭터 속도, 오브젝트 배치 변경부터 진행하고 다음에 킬 메시지 파트를 수정, 채팅 관련 요소는 마지막으로 둔 채 수정 작업에 들어갔습니다.
■ 파라미터만 고쳐도 느낌이 달라진다
보통 대미지나 HP 등은 스크립트 내부가 아닌, 외부에 파라미터를 따로 빼서 관리하곤 합니다. 테스트하면서 워낙 이리저리 자주 바꿔야 하니, 굳이 스크립트를 열지 않고 엔진에서 바로 처리하는 게 더 빠르기 때문이죠.
디토랜드에서는 그 파라미터가 속성창 하단에 스크립트 파라미터에 따로 배정되어있습니다. 디토랜드 툴박스에서 구할 수 있는 무기들의 장탄 및 장전 시간, 사격 속도 관련 정보는 해당 무기 -> Body 폴더에 위치해있죠. 에임 보정 및 탄환 속도, 사거리 정보는 Barrel에 저장되어있습니다. 대미지 및 스플래시 범위는 Effect에서 찾아볼 수 있고요.
플레이어 이동속도 및 점프속도, 리스폰 시간 및 HP 관련 정보는 Character의 DefaultCharacterSetting이나 FPSCharacterSetting 등 이름이 붙은 서버스크립트에 있습니다. 그곳에서 이동 속도나 점프 속도, HP 파라미터 등을 조절해주면 되는 거죠.
가장 기초적인 방법은 그 파라미터들을 하나하나 수정하면서 어떤 게 좋을지 확인하는 방법입니다. 멀티 테스트를 지원하니 혼자서 일일이 하나하나 보지 않고 이것저것 같이 써보면서 추가로 수정할 방향을 찾을 수도 있죠. 그렇게 계속 수치 조정과 테스트를 반복하면서 적합한 밸런스를 찾아나가야 합니다.
이전에 지적받은 개틀링 건은 연사 전에 예열 시간을 좀 더 늘리고, 에임 반동을 더 키운 뒤 대미지를 순차적으로 줄이는 방향으로 설계했습니다. 아무래도 게임 특성상 히트 스캔 무기가 없어 연사 무기가 단발 무기보다 이득일 수밖에 없는데, 다른 연사 무기와 비교도 안 될 정도로 연사 속도가 빠른 개틀링 건은 대미지만 줄인다고 해서 밸런스가 맞춰질 것 같지 않았기 때문입니다.
그외 다른 연사 무기는 라이플이 가장 올라운더였다는 평가가 있었고, 실제로 잠깐 해봤을 때도 라이플이 가장 무난했던 것 같으니 그걸 기준으로 어떤 요소는 +, 어떤 요소는 -하는 식으로 체크했습니다. 그래서 블래스터는 예열 시간과 에임 각도를 좀 더 줄이는 식으로 수정했습니다.
스나이퍼 라이플은 스크립트 구조가 히트스캔 방식이 아니다보니 QA 전부터 탄속을 높여서 그에 가깝게 구현해둔 상태였습니다. 그렇지만 줌샷의 리스크에 비해 리턴이 높지 않아서 큰 의미가 없다는 지적이 있어 탄속과 대미지를 좀 더 높였죠. 줌 모드에 관한 정보는 AddOn과 그 아래의 ScopeServerScript에 저장되어있어서 옵션을 확인했는데, 줌 크기에 관한 것만 있고 속도는 시간 제약 없이 조건문으로 바로 이행되게 되어있어 크게 손을 볼 여지는 없었습니다.
피스톨은 대미지는 더 높이되 사거리를 조절해서 단거리에선 위협적이지만 장거리 대처는 어렵게 바꿨습니다. 스플래시 무기 중 T버스터는 대미지만 우선 조정했고, 로켓런처는 인풋 딜레이를 최대한 줄여서 조준해서 발사한 뒤 마우스를 움직여도 처음 조준한 방향으로 가게끔 유도했죠.
■ 맵 구조물이나 UI는 그냥 나오지 않는다
기존에 있는 기믹이나 아이템의 수치를 조정하는 일은 무기, 캐릭터 수치를 바꾸는 과정과 동일합니다. 다만 새로운 오브젝트를 만들거나, 아이템이 루팅되는 로직을 바꾼다면 이야기가 달라지죠. 일부 기믹을 구현하기 위해서는 캐릭터 설정까지 조금 고쳐봐야 할 텐데, 그것까지는 좀 시간이 소요되는 터라 툴박스에 있는 새로운 기믹을 추가해서 중앙 교전 비중을 높이는 방향으로 설계했습니다. 그리고 중앙에 있는 탑에 좀 더 유니크한 특성을 주기 위해서 체력 회복+스피드+점프 버프가 다 추가된 엘릭서 아이템이 확정적으로 나오게끔 바꿨고요.
원래 템플릿에 있는 아이템 스폰 스크립트는 토이박스에 있는 아이템풀이 랜덤으로 나오는 방식입니다. RandomItemSpawnServer라고 되어있는 스크립트에서 처리하는 건데, Toybox에 새로운 폴더를 만들고 그 안에 특정 아이템만 넣은 뒤 local ItemList = Toybox.Items:GetChildList() 이 부분의 Items만 새로운 폴더명으로 바꿔주면 됩니다. 그 스크립트를 중앙에 있는 스폰포인트에만 넣어주면 다른 스폰포인트와 상관없이 중앙만 적용되죠. 이번엔 UniqueItems라고 따로 배정해놨으니, 거기에 있는 아이템을 싹 다 없애버리고 엘릭서만 남겨두면 됐습니다. 그런 방법을 응용해서 무기도 다 동일하게 랜덤하게 나오는 것이 아니라, 지역별로 무기가 다르게 나오도록 수정했습니다.
UI는 기본적으로 스크린 UI를 붙이고 텍스트를 넣으면 되지만, 그 UI를 제때 출력되게 만들기 위해서는 스크립트를 살펴봐야 합니다. 킬 및 스코어 관련 정보는 System 내 Score_PointKD의 PointKD_Server 스크립트와 클라이언트 스크립트에 있으니 이쪽을 손보는 한편, HUD를 좀 개조해야 했죠.
Score_PointKD 폴더를 좀 더 자세히 살펴보면 PointHUD가 있고, 여기서 KillNotice 텍스트에서 해당 플레이어가 누구를 죽였나 출력됩니다. 가보면 그냥 You Killed Enemy라고 써있는데, 이 Enemy창이 계속 바뀌기 위해서는 여기에 관여하는 스크립트를 거슬러 올라서 찾아봐야 했죠.
보통 멀티플레이 게임은 정보를 서버에서 처리하고, 그 처리된 정보를 클라이언트가 받아서 처리합니다. 여기서는 PointKD_Server와 PointKD_Client가 각각 서버, 클라이언트 스크립트죠. PointKD_Server 를 훑어보다보면 Game:SendEventToClient라고 써있는 게 보입니다. 말 그대로 해당 정보를 클라이언트 스크립트로 보낸다는 뜻이죠. 이런 것들을 보다보니 킬포인트를 관리하는 코드들이 눈에 들어왔습니다.
그걸 훑어보니 각 플레이어한테 누구를 죽였다는 정보는 보낼 수 있는데, 그걸 모든 플레이어한테 보낼 방법을 찾는 게 일이었습니다. 모든 플레이어에게 그 정보를 보낼 때, 그 특정 플레이어가 다른 특정 플레이어를 죽였다는 걸 인지시키기 위해서 어떤 식으로 코드를 짜야할지 궁리하는 것도 문제였죠. 플레이어 리스트를 관리하는 PlayerListServerScript를 찾아가서 봤더니, 플레이어 몇 명이 들어오고 그 명단이 리스트에 올라가는 것까지는 처리가 되어있는데 각각 플레이어를 구분짓는 규칙이 킬, 데스 결과에만 반영이 되어있어서 이걸 좀 손을 봐야했습니다.
그걸 이리저리 손보다가 몇 번 오류가 나기도 했는데, 상용 엔진과 달리 브레이크나 외부 툴로 코드체크를 못하는 게 좀 아쉬웠습니다. 그래도 전통의 Debug.Log로 제가 쓴 코드가 아예 작동을 안 하고 있다는 걸 확인했으니, 시행착오를 통해서 완성할 수는 있을 겁니다. LUA 스크립트를 아예 맨땅에 헤딩하고 있는데다가 남이 통째로 만든 걸 뜯어고친 적은 없다보니, 그 구조를 다 파악도 못하고 있긴 하지만요.
■ 피드백을 거친 뒤, 어땠나요?
UI도 UI였지만, 채팅은 아에 손을 대지 못했습니다. 채팅 관련된 부분을 어디에 수정해야 할지, 제 능력으로는 찾아보기 어려웠기 때문이죠. 캐릭터의 애니메이션 추가와 조작법 추가도 어디에서 고쳐야 할지는 대강 알겠는데, 막상 적용해보면 Input에서 막혀버립니다. DefaultInput 이 스크립트를 고쳐봐도 그 기능이 제대로 활성화되지 않았기 때문이죠.
아니면 저기서 동작 처리할 때, 논리를 잘못 짰기 때문에 그럴 수도 있을 겁니다. 기계는 딱 말한 그대로만 하기 때문에, 조금이라도 잘못되거나 모호하다 싶으면 아예 처리를 못하니까요. 어쨌거나 당장에 처리할 수 있는 것은 했으니, 얼마나 개선됐나 동료 기자과 플레이해보고 물어봤습니다. 제가 의도한 것과는 다르게 스나이퍼 라이플이 워낙 버프를 많이 받아 저격전 위주로 가긴 했는데, 이전보다는 교전 이 산발적이지 않고 집중된 모습을 보였죠.
이렇게 총 4편에 걸쳐서, 디토랜드를 활용해서 게임을 개발하는 과정을 정리해보았습니다. 아직 OBT 단계이기도 하고, 제가 LUA 언어를 모르기 때문에 완벽한 무언가를 당장에 만들어내기는 좀 어려웠습니다. 그렇지만 계속해서 업데이트가 되고 있는데다가 디토랜드를 활용한 샘플 게임도 여러 개 추가되고 있으니 나중에는 이런 것도 쉽게 처리 가능해질 거라 생각합니다. 남이 만들어둔 툴만 적당히 이어붙여도 그럴싸한 게임이 나오는 게 샌드박스 게임 플랫폼의 궁극적인 모습이고, 디토랜드는 이제 그 첫발을 내딛었으니까요. 조금 더 시일이 지나 기능이 완전해지고 예제가 더 추가되면, 그때 아마 다시 한 번 다루게 되지 않을까 싶습니다
Ruudi@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
