[[TableOfContents]]

이부분의 핵심은 게임은 데이터와 로직으로 되어있으며 데이터는 코드 자체에 내장되기 보다는 파일에서 읽어들여야 한다는 것이다. 

=== 아이디어 #1 : 기본 ===
게임이 시동될 때 뿐 아니라 필요할 때마다 텍스트 파일을 읽어들일 수 있게 하라. 데이터 주도적(Data-Driven) 설계에 꼭 필요하다. 왜냐면 게임은 프로그래머 뿐만 아니라 디자이너, 테스터 등과 같이 만드는 것이 때문이다. 프로그래머가 아닌 이상 소스코드를 보는 것은 어렵지만 텍스트 파일은 약간의 규칙으로만으로도 이해 가능하다. 

=== 아이디어 #2 : 최소한의 원칙 ===
상수들은 하드코딩(Hard-cording)하면 안된다. 하드 코딩이란 데이터를 엔진에 바로 탑재하는 걸 말한다. 즉 #1 기본에 반하는 것이라고 볼 수 있다. 하드코딩을 하만 안되는 이유는 역시 #1과 비슷하다. 요컨데 소스코딩보다는 Text를 읽어들이는 것이 아무나 수정을 가능케 하고 쉽게 할 수 있다는 게 장점이다. 이는 게임을 제작할 때나 테스트 할 때 엄청 편해진다. 다시 한 번 강조하지만 게임은 프로그래머만이 만드는 게 아니다. 

=== 아이디어 #3 : 하드코딩을 완전히 없애라. ===
어떤 것이든 바뀔 수 있다고 가정해야 하고, 실제로 어떤 것이든 바뀌게 마련이다. 유연하게 만드는 것이 필요하다. 게임의 추상화가 필요하며 변하지 않을 것과 변할 수 있는 것을 분리하여 범용적인 기능성을 추구해야한다. 예를 들어 초기에 무기가 4개 필요하다고 할 때 딱 4개만 쓸 수있는 코딩을 하지 말고 100개도 만들 수 있는 식의 프로그래밍을 하라는 것이다. 이해가 안가는가? -_-; [[BR]]
==== "아예 없애라." - 농담이 아니란다 -_- ====
게임 개발 과정은 반복적이며 진화적이다. 애초에 생각했던 게임과 최종적으로 만들어진 게임이 전혀 다른 물건인 경우도 흔하므로 규칙, 캐릭터, 종족, 무기, 레벨, 제어방식, 객체등을 자유로이 수정 가능하게 할 수 있는 프로그래밍이 필요하다. 프로그래머가 피곤하지 않으려면 꼭 필요하다. Data 하나 수정하기 위해 프로그래머가 다시 컴파일 해야하는 일이 계속 일어난다면 프로그래머는 미칠 것이다.... 키키 -_- 

=== 아이디어 #4 : 게임의 흐름은 스크립트로 제어할 것 ===
스크립트.... 다들 잘 알 것이다.(참고로 현재 요약하는 사람은 스크립트 언어를 한 번도 사용 안해봤다 -.- 파이썬이나 공부해 볼까 -_-) Quake3 해봤는가? 좀 전문적으로 했다면 몇 가지 명령어로 별별 희안한 것을 다 해 볼 수 있었을 것이다. 간단한 예가 치트키가 되는데 보통 치트키는 테스트 용으로 만든 것이다. 이게 바로 스크립트다(아 쉽게 설명했다 --) 스크립트의 문제점이라면.... 스크립팅 언어가 필요하며 또한 파서(Parser)가 필요하다는 점이다. 하여간 스크립트를 사용하면 시스템 설계가 상당히 단순화 된다고 한다.... -_- 

=== 아이디어 #5 : 스크립트 남용의 해악 ===
스크립트의 원칙은 로직과 데이터의 분리다. 그런데 스크립트는 로직과 데이터의 양면은 모두 가질 수 있다는 점이 문제가 된다. 즉 프로그래머는 핵심 엔진과 스크립트 파서만 짜고 나머지는 스크립트 작성자에게 떠 맡기고 탱자탱자 놀 수도 있다 -.-. 스크립트는 일을 편하게 하려는 거지 놀자고 하는 것이 아님을 명심해야한다. 이상적인 프로그래머는 문제를 하향식으로 분할 할 수 있어야하며, 그럼으로써 로직을 조작하기 위한 필수적인 제어방식들을 스크립트에 노출 시킬 수 있어야 한다. 

=== 아이디어 #6 : 데이터 중복을 피하라. ===
코드를 중복하지 않는다는 건 다들 알 것이다(대표적인 예가 class의 상속이다). 데이터도 이러한 방식이 가능한데 데이터를 전역적으로 만드는 방법이 있다. 여기에 클래스의 상속 개념이 들어간다. 예를 들어서 고블린 - 빠른 고블린 - 고블린 인스턴스 순으로 상속 받는다 치자. 여기서 고블린과 빠른 고블린의 차이는 속도뿐이라면 빠른 고블인은 고블린에서 단지 속도만 고치고 나머지는 고블린에 정의된 것을 그대로 사용하면 된다(데이터의 선언 정의 필요 없이) 물론 빠른 고블린을 상속 받은 고블린 인스턴스는 속도는 빠른 고블린 나머지는 고블린에 있는 것을 그대로 사용하면 끝. 어떤가 간단하지? 

=== 아이디어 #7 : 데이터를 만들어내는 도구를 작성할 것 ===
예만 들어 설명하겠다. 맵 에디터가 그것이다 -.- 게임 만들 때 프로그래밍 언어 뿐만 아니라 커스텀 툴을 사용하는 것은 다들 알 것이다(모른다고? -_-) 맵 에디터 처럼 게임에 필요한 데이터들을 잘 조합하거나 만들 수 있는 툴을 만들어 쓰는 게 여러모로 편하다. 

=== ê²°ë¡  ===
데이터 주도적 방법론을 채택하는 것은 어렵지 않지만, 그 결과가 눈에 안보인다고 불평할 지도 모른다. 하지만 간단한 예를 들면서 마치겠다. [[BR]]
토탈 어나이얼레이션이란 게임을 아는가? (이하 TA) 알면 1주마다 유닛 추가 되는 걸 알 테니 됐고, 모른다면 심즈의 예를 들겠다. 심즈도 역시 데이터 주도적 방법론을 사용했는데 대표적인 예가 스킨이 되겠다. 그리고 아이템도 마찬가지고 ^_^ 
참고로 덧붙이지만 TA가 없었다면 여러분이 미친듯이 즐긴다는 스타크래프트도 없었을 것이다. 여러분이 보고 있는 현재 스타크래프트는 처음에 만들어진 그것과 완전히 다르다고 할 수 있을 정도였다. TA와 다크레인이란 RTS게임을 보고 소스코드까지 갈아치운 결과물이 현재 스타크래프트다.... 

----
["GameProgrammingGems"]