1 부프로그래밍 기법들1.0 데이터 주도적 설계의 마법Page 37 ~ 43NHN NEXT, NEXON 라태웅

데이터 주도적 설계의 마법 게임은 로직과 데이터로 이루어짐

로직 : 게임 엔진의 핵심 규칙들과 알고리즘을 규정 데이터 : 내용과 행동의 세부적인 사항들을 제공

로직과 데이터는 떨어져 있으면 쓸모가 없음 그러나 결합 되면 마법과도 같이 게임에 생명을 부여함

데이터 주도적 설계의 마법

데이터 주도적 설계의 마법 데이터는 코드 자체에 내장되기 보다는 파일들로부터 로드되어야 함

이 당연한 개념으로부터 수많은 마법들이 피어나게 됨

게임 개발을 크게 혁신할 수 있는 몇 가지 아이디어를 소개할 것

아이디어 #1 : 기본 ( 텍스트 파일 읽기 ) 텍스트 파일을 읽어서 처리할 수 있는 시스템이 필요

게임이 실행될 때 , 필요할 때마다 텍스트 파일들을 읽어서 처리할 수 있도록 “ 데이터 주도적 (data-driven) 설계”를 해야한다 .

최종 출시 때는 이진 파일을 사용하겠지만 ,

프로그램 코드를 고치지 않고도 프로그래머를 비롯하여 테스터나 게임 디자이너들을 포함한 팀 전체가 게임의 설정이나 환경을 이리 저리 바꿔볼 수 있다 .

아이디어 #2 : 최소한의 원칙 상수들을 하드 코딩 (hard-coding) 해서는 안됨

모두 텍스트 파일에 넣어야 컴파일하지 않고도 상수를 바꿀 수 있음 상수를 자유롭게 변경시키면서 좀 더 나은 방식을 찾을 수 있게 됨

Ex) 카메라 이동 같은 기본적인 기능 -> 비프로그래머들도 텍스트 편집만으로 카메라의 행동 방식을 자유롭게 바꿀 수 있게 됨

아이디어 #3 :하드 코딩을 아예 없애라 어떤 것이든 바뀔 수 있다고 가정해야 함 . 실제로 어떤 것이든 바뀌기 마련임 설계 상의 결정 사항들을 자유롭게 바꿀 수 있으면 게임을 최고 수준으로 진화시킬 수 있음

ex) 무기를 하드 코딩으로 4 개를 만들면 무기가 추가될 때마다 코딩을 하고 컴파일을 해야 함 .

하지만 이를 추상화해서 데이터로부터 읽게 하면 무기가 100 가지더라도 데이터만 추가해주면 됨

아이디어 #3 :“ 아예 없애라” – 농담이 아님 ! 게임 개발 과정은 반복적이며 진화적임 애초에 생각했던 게임과 최종적으로 만들어진 게임이 전혀 다른 물건인 경우도 흔함 규칙 , 캐릭터 , 종족 , 무기 , 레벨 , 제어 방식 , 객체 등을 자유롭게 변경하고 수정할 수 있도록 하는 것이 매우 핵심적인 문제

그렇지 않으면 사소한 것 하나를 바꾸려고 해도 항상 프로그래머의 손을 거쳐야 하기 때문에 시간과 돈의 낭비임

이 낭비가 부담스러워 게임 개선을 아예 포기하기도 함 즉 , 게임 속에 내재된 무한한 잠재력을 그냥 지워버리는 결과를 낳음

아이디어 #4 :게임의 흐름은 스크립트로 제어할 것 스크립트 : 게임의 행동 방식을 프로그램 코드 밖에서 정의하기 위한 수단

게임에서 일어나는 일련의 단계를 정의하거나 이벤트를 발생하게 하는 데 주로 쓰임

스크립트는 데이터 주도적 원칙의 훌륭한 실제 예임

아이디어 #4 :게임의 흐름은 스크립트로 제어할 것 스크립팅 언어를 설계할 때에는 조건 분기 방식에 신경써야 함 스크립팅 언어 안에서 변수들을 유지시키고 비교하는 방법

게임 코드에 함수를 만들어 두고 코드에 존재하는 변수를 비교하는 것 디자이너는 변수를 선언하고 , 갱신하고 , 비교하는 것보다 함수를 사용하는 것을 선호할 것 But, 스크립팅 언어가 필요함 완전히 새로운 문법을 직접 정의 스크립트 파서도 만들어야 함 빠른 속도를 위해서는 텍스트를 이진 형태로 변환하는 컴파일러도 필요할 수 있음

아이디어 #5 : 스크립트 남용의 해악 데이터 주도적 설계론의 애초의 원칙을 잊어서는 안 됨 !!!

“ 로직과 데이터”를 분리해야 함

복잡한 로직은 코드 내부에 , 데이터는 코드 외부에 두어야 함을 명심

스크립트가 위험한 이유는 스크립트가 데이터의 성격과 로직의 성격을 함께 가지고 있기 때문

아이디어 #5 : 스크립트 남용의 해악 스크립트를 다루다 보면 스크립트 안에 복잡한 로직을 넣고 싶어짐

But, 스크립트에 복잡한 로직을 넣으면 프로그램 코드를 작성하는 것과 별다른 차이가 없어짐

스크립트가 복잡해질 수록 프로그래머는 엔진만 만들어 놓고 외면 나머지 일은 스크립트 작성자가 모두 떠맡게 됨

스크립트란 일을 편하게 하기 위한 것이지 어렵게 만들기 위한 것이 아님 !!!

아이디어 #5 : 스크립트 남용의 해악 복잡한 로직을 코드 안에 두어야하는 이유는 프로그램의 기능성과 디버깅에 있어서 매우 중요한 문제 !

스크립트가 복잡해질수록 스크립트의 문제를 해결하는 데 필요한 디버깅 정보의 양도 많아짐

ex) 복잡한 로직이 코드안에 있다면 Visual Studio 의 경우 바로 디버깅하면 됨 !

아이디어 #5 :경계가 애매하다는 것이 문제 코드와 스크립트 사이의 경계가 애매하다는 것은 사실 분명한 것은 로직이 복잡해지면 무조건 코드에 넣어야한다는 것 디자이너나 스크립트 작성자가 프로그래밍을 하게 해서는 안 됨 스크립팅 엔진만 만들고 디자이너에게 떠넘긴다면 일종의 직무 유기임

문제를 하향식으로 분할하여 로직을 조작하기 위한 도구로 스크립트를 사용해야 함

아이디어 #6 :데이터의 중복을 피해라 코드를 중복하지 않는 것은 프로그래밍의 표준적인 관례 서로 다른 두 지점에서 동일한 행동이 일어나야 하는 경우 그에 대한 코드는 하나만 존재해야 함 ( 함수 등을 통해서 )

데이터도 동일한 개념이 적용 주된 방법은 여러 곳에서 쓰일 데이터를 전역적인 데이터로 만드는 것

또한 특정한 위치에서는 데이터 일부를 수정하게 할 수도 있어야 함

아이디어 #6 :데이터의 중복을 피해라 이를 위해서는 “상속”이라는 개념이 필요

한 객체의 공통적인 부분을 설정하고 , 이를 상속받아 여러 객체의 개별적인 설정을 하도록 하는 것이 바람직

즉 , 공통적인 속성들을 상속받고 , 그 중 특정한 속성들을 추가하거나 재정의하여 데이터의 중복을 피할 수 있음

아이디어 #6 :데이터의 중복을 피해라

아이디어 #7 :데이터를 만들어 내는 도구를 작성할 것 게임의 규모가 크다면 텍스트 파일이 너무 복잡하고 커져서 다루기 힘들어짐 따라서 텍스트 파일들을 작성하는 도구를 만드는 것이 해결책

게임 에디터 , 레벨 에디터 등 다양한 도구가 있지만 공통점은 제대로 된 도구를 만들면 게임 개발 속도가 훨씬 빨라짐

데이터 주도적 설계론에 위배되는 것이 아니고 데이터를 좀 더 견고하고 효율적으로 만드는 데 도움을 주기위한 것일 뿐

결론 데이터 주도적 방법론을 채택하는 것은 어렵지 않음 하지만 그 결과가 가시적으로 드러나게 하기는 쉽지 않음 But, 모든 것이 데이터 주도적이 되면 놀랄만한 잠재력과 가능성이 피어남

ex) 토털 어나이얼레이션 (RTS 게임 )

데이터 주도적 설계를 극한까지 밀어 부침 게이머들이 유닛을 만들어서 올려 서로 다운로드 받아 즐길 수 있음 데이터를 통해서만 정의되고 새로운 유닛들을 추가하는 것이 얼마든지 가능

발표를 마치며… 실제 게임 업계에서는 이미 데이터 주도적 설계론을 많이 채택

하지만 원칙을 지켜서 끝까지 개발하여 출시하는 게임은 극소수

내가 데이터를 쓰는 것인지 프로그래밍을 하는 것인지 구분이 안가는 경우가 많음

원칙을 항상 되새기고 명심해서 설계해야 진정한 데이터 주도적 설계의 파워를 느낄 수 있을 것이라고 생각