ModifiableGames

UserPreferences

http://lgdc.sunsite.dk/articles/3.html

1. 머릿말
2. 데이터 주도적인 게임들
3. 로직/목적 기반 게임들
4. 스크립팅
5. 가상 머신(Virtual Machine)
6. DLLs
7. 맺음말

1 머릿말

세상에 존재하는 프로그램은 두 가지 분류로 나눌 수 있다. 첫번째는 바깥 세상과는 전혀 상호작용 없이, 내부적으로만 무언가를 계산해서 출력하는 프로그램이고, 두번째는 임의의 입력을 받아들여서, 계산을 한 후에 결과를 출력하는 프로그램이다. 당연히 외부 입력을 전혀 받지 않는 프로그램은 없을 것이다. 하지만 여기서의 분류는, 간단한 선택만을 받아들이는 프로그램과 대량의 외부 데이터를 파일 등으로 받아들이는 프로그램을 구분하기 위한 것이다.

어떤 프로그램의 기능을 일반화하고, 그 기능을 실행하는 데 필요한 부분 중 일부를 프로그램 외부의 데이터 파일로 빼내게 되면, 그 프로그램은 훨씬 강력해진다. 데이터 파일을 교체하는 것만으로도, 같은 입력에 대해서 원래와는 전혀 다른 결과를 출력하는 프로그램을 만들 수 있다는 말이다.

2 데이터 주도적인 게임들

이 방식은 간단히 말하자면, 레벨이 최초에 로드될 때, 특정 파라미터들(데미지, 디펜스 등등)을 읽어와 변수에다 집어넣어놓은 다음, 계산할 때 이 값들을 수정하는 방식이다. 밸런싱이 잘못된 게임을 수정할 때 코드를 건드릴 필요가 없으므로 좋다. 코드를 직접 수정하는 것은 노가다에다, 느리고, 재컴파일을 필요로 할 뿐만 아니라, 재수가 없으면 새로운 버그를 만들어낼 수도 있다.



이런 방식의 장점은 구현 뿐만 아니라 사용하기도 쉽다는 것이다. 간단한 아스키 파일은 PC 와 사람 모두 읽기 쉽다. 복잡한 문법도 필요 없으니, 수정하기도 쉽다. 하지만 수정의 용이성에는 반대 급부로서 기능의 부재가 따라온다.

어떤 전략 게임에서, 속도는 빠르지만 화력이 약한 유니트를 그 반대로 바꾸면, 새로운 게임 플레이를 경험할 수 있을 것이다. 하지만 그것은 어디까지나 전략 게임이지, 축구나 체스 게임이 아니다. 바로 이런 점에서 데이터 파일을 사용하는 방식은 상당히 제약되어 있다.

3 로직/목적 기반 게임들

데이터 파일의 기능을 비교적 간단하게 확장시키고 싶다면, 그 안에다 어떤 조건을 체크할 수 있는 기능을 집어넣으면 될 것이다. 두 사람이 함께 플레이해서 둘 중의 하나가 죽어야만 끝나는 게임이라면 대략 아래와 같은 형식으로 데이터 파일을 작성하게 된다.



if player2.IsDead then player1.Win () 
if player1.IsDead then player2.Win ()   


이런 형식의 데이터들을 규칙(rule) 또는 목표(goal)라고 부른다. 플레이어의 "승리" 목표는 다른 플레이어의 "죽음" 목표가 달성되었을 때 이루어지게 된다. 일반적으로 이런 데이터는 왼쪽의 목표들을 모두 만족시킨 경우, 맨 오른쪽의 목표가 달성되었다고 표시하는 방식으로 구현한다.



이 코드가 하는 일은 엔진이 관리해야하는 기본적인 목표나 조건들을 정의하는 것이다. 이들은 프로젝트마다 틀리지만, 간단한 예를 들면 "죽음" 플래그이다. 플레이어가 어떤 식으로든 죽으면, "죽음" 목표가 충족된 것이다. 게임 안에서 무한 루프를 돌며, 이를 체크하고, 어떤 조건들이 만족하면, 그에 따른 오른쪽의 조건을 충족시키는 것이다. 이를 이용해서 간단한 데쓰 매치를 스크립트로 만들어 보면, 다음과 같을 것이다.



if player1.Win then GameOver 
if player2.Win then GameOver 
if player1.IsDead and player2.IsDead then GameOver 
if player1.IsDead and not player2.IsDead then player2.Win 
if player2.IsDead and not player1.IsDead then player1.Win   


한 플레이어가 다른 플레이어를 죽이면, 그가 승리한 것이다. 누군가 승리하면 게임 오버다. (계속 무한루프를 돌면서 위에서부터 아래를 체크하므로, 다음 루프에서 게임 오버가 될 것이다.) 만약 서로를 동시에 죽이게 된다면, 누가 이긴 건 아니지만, 그것 또한 게임 오버다.

기본적으로 전체 게임이 간단한 if-then 컨트를 구문으로 이루어져 있다고 하자. 이 구문들이 코드 속에 들어가있는 것이 아니므로, 수정을 가할 수 있다. 다음과 같이 수정했다고 해보자.



if player1.IsDead then GameOver 
if player2.IsDead then GameOver 
if player1.Win then GameOver 
if player2.Win then GameOver 
if player1.AchievesGoal and player2.AchievesGoal then player1.Win and player2.Win   


누군가 하나가 죽으면, 게임 오버이고 누구도 승리하지 못한다. 둘 다 살아 남아서, 어떤 목표를 이룬 경우에만, 둘 다 승리하게 되는 것이다.

이것은 강력한 테크닉이다. 데쓰매치 게임이 간단하게 협력(?) 게임으로 바뀐 것이다. RPG나 어드벤쳐 게임 같은 경우에는 완전히 새로운 스토리 라인을 만들어낼 수도 있을 것이다.

하지만 이런 if-then 방식의 스크립트로만으로는 "이것을 10번 반복하면 너는 승리한다"와 같은 비교적 간단한 스타일의 구문도 만들어내기 어렵다. 불가능한 것은 아니지만 - Prolog나 LISP 같은 rule based 언어가 C 같은 절차적 언어와 기능상에서 같은 능력을 가지고 있다는 것은 증명이 되었다. - 완전히 다른 사고 방식을 요구할 것이다. 이는 기획자나 MOD를 개발하는 사람이 상당한 수준의 지식을 가지고 있어야 한다는 말이다. 한 예로 리눅스 기반의 Abuse 라는 게임을 들 수 있다. 이 게임은 LISP 기반의 스크립트 엔진을 가지고 있었다. 그러나 스크립트 엔진의 성능에 비해서, MOD 숫자가 상당히 적었다. 게다가 대부분 원래 개발자들이 만든 것이었다.

4 스크립팅

Prolog/LIST 기반의 if-then 구조는 몇 가지의 목표(goal)를 나열하기 위한 정도라면 몰라도, 그 이상이라면 상당수의 프로그래머에게 익숙하지 않은 방식이다. C 같은 순차적 언어가 더 많이 알려져 있다. 그러므로 뭔가 C 같은 순차적인 언어를 만들어내는 것이 더 나아 보일 것이다. 파서와 인터프리터를 구현하고, 이들이 게임을 컨트롤하게 만드는 것이다. 임의의 값들을 읽어들이고, 뭔가를 복사하고, 함수를 호출하는 기능들을 구현해야 할 것이다.

달리 말하자면, 게임 로직을 C로 구현하는 것이 아니라, 따로 만든 언어(대부분 간단한 버전의 C 또는 파스칼)를 이용해 구현한다는 말이다. 그리고 이 스크립트들이 실제 게임 코드 안에서 잘 작동하게 환경을 만드는 것이다.



이 방법의 가장 큰 장점은 디자이너에게 상당한 수준의 자유를 제공하게 된다는 것이다. 스크립트 언어를 극한(?)까지 만들어내면, 디자이너에게 마치 C 코드를 수정하는 것과 같은 정도의 자유도를 줄 수 있다. 게임 자체가 완전히 뒤바뀔 수 있다는 말이다. 지상 유니트가 날아다니거나, 그 반대가 실행될 수 있다. 무기가 변경/삭제/추가될 수도 있을 것이다. 스크립트에서 액세스가 가능한 함수만 만들어낸다면, 게임을 마음대로 주무를 수 있다.

이 방법의 단점을 당연히 해야할 일이 많다는 점이다. 될 수 있는 한 이미 만들어져있는 각종 툴들을 사용해서, 노력들을 줄이는 것이 좋다. 예를 들어 yacc 같은 툴을 이용해서 파서 구현을 쉽게 할 수 있을 것이고, 이미 만들어져 있는 C/Pascal 인터프리터를 현재 게임 엔진에다 집어넣는 것도 고려해봐야할 것이다. 하지만 이런 작업이 언제나 가능한 것은 아니다. 왜냐하면 이런 도구들 중에는 속도를 별로 고려하지 않은 것들이 많기 때문이다. 스크립트 엔진이 아무리 좋아도, 그 엔진이 게임을 10 fps로 만들어 버린다면, 고려할 가치가 없다는 말이다. 이런 문제 때문에 결국 스크립트 엔진을 바닥에서부터 제작하는 곳이 많다. 하지만 결국 스크립트를 사용하는 사람이 프로그램에 대해 어느 정도의 지식을 가지고 있어야 한다는 단점이 있다.

이런 방법의 대표적인 예가 퀘이크 1에서 쓰인 QuakeC 스크립트다.

5 가상 머신(Virtual Machine)

인터프리터에 의해서 발생하는 성능의 감소는 원하지 않고, C/C++의 강력함을 원할 때, 사용할 수 있는 방법 중에 하나가 가상 머신을 직접 구현하는 것이다. 이 말은 소스 코드를 컴파일/링크해서 배포하는 것이 아니라, 소스 상태로 게임과 같이 배포한 다음, 실제로 게임을 실행할 때 컴파일해서, 직접 구현한 가상 머신 상에서 돌린다는 말이다.



당연하지만 이것은 꽤 심각한 프로젝트다. 컴파일러, 바이트코드 정의, 가상머신을 구현해야 한다. 컴파일러는 C/C++와 같거나 그 이상의 성능을 가진 언어를 컴파일해야하고, 가상머신은 메모리를 많이 소모하지 않으면서, 매우 빨라야 하는 데다가, 게임 관련 변수와 함수를 액세스할 수 있도록 만들어야한다. 이런 작업은 이미 만들어져 있는 툴들을 사용하지 않는 이상 거의 불가능에 가깝다. 이러한 방법을 택한 게임 중에 유명한 것이 언리얼(개발에 3년이 걸렸다.)이다. 언리얼은 AI 및 게임 세계 전체가 C++을 기반으로 확장한 언어와 가상 머신에 의해서 동작한다. 퀘이크 3 아레나도 이 방법을 택했다. 사실 이런 가상 머신들이 길찾기(pathfinding) 등과 같은 작업에 사용할 정도로 빠른 것은 아니지만, 게임 플레이 자체는 거의 대부분 가상 머신을 통해서 이루어진다.

자바 가상 머신을 게임 안에서 재사용할 수 있다는 점을 알아두기 바란다. 자바 프로그램은 JNI를 통해서 확장될 수 있고, 이는 게임과 어느 정도 맞아떨어진다. 게다가 Embedded Java 기술을 이용해 가상 머신을 게임의 일부로서 로드할 수도 있다. 이는 게임 로직을 자바로 작성한 다음, 바이트 코드로 컴파일해서, 이것을 게임 안의 가상 머신을 통해 실행할 수 있다는 말이다. 이런 방법 중에 가장 흥미있는 것이 Q2Java 프로젝트(퀘이크2 안에다 자바 가상 머신을 집어넣는 프로젝트)다.

Java 페이지를 참고.

6 DLLs

가상 머신의 가장 멋진 점은, 실제 게임 엔진이 게임 플레이를 위한 일종의 툴 밖에 되지 않는다는 점이다. C/C++ 정도의 언어를 아는 사람이라면 바로 게임 파일을 수정해서 다른 게임을 만들어낼 수 있을 것이다. 하지만 이런 유연성은 위에서도 말했듯이 엄청난 노력을 필요로 한다. 이미 수많이 나와있는 C/C++ 컴파일러를 따로 만들어야 하고, 이 컴파일러가 만들어내는 바이트코드를 빠르게 실행할 수 있는 가상머신, 즉 CPU를 만들어야 한다는 말이다. 그러므로 더 싸게 먹히는 대안이 필요하다. 바이트 코드를 만들어내는 데는 그냥 일반 컴파일러를 사용하고, 게임 로직은 다른 모듈이나 라이브러리(윈도우에서는 DLL, 유닉스 계열에서는 lib)에 두는 방법이 대안 중의 하나일 것이다. 이 라이브러리들을 컴파일해서 링크할 수 있는 도구만 제공한다면, 컴파일을 할 수 있는 사람이면 누구나 게임 로직을 새로 만들어낼 수 있을 것이다.



기술적인 문제점만 해결한다면, 강력한 기능을 제공할 수 있다. 게임의 가장 미세한 부분까지 비교적 쉽게 수정할 수 있는 데다가, CPU의 성능을 100% 활용할 수 있다. 게다가 실제 게임 구현이나 수정은 최종 사용자에게 보이지 않는다. (미션팩 등을 지원해야 하는 상용게임에 유용하다.) 하지만 여기에도 두 가지 문제가 있다. 첫번째는 게임 로직의 수정이 플랫폼에 종속적이게 된다는 것이다. 여러 플랫폼에 포팅되어야하는 게임이라면 이 문제는 상당히 심각하다. 두번째는 위에서 나온 모든 방법들이 스크립트를 일종의 안전한 환경에서 수행했던 것에 반해, 이 방법은 바로 CPU를 이용해서 스크립트를 실행한다는 점이다. 즉 프로그램이 크래쉬될 확률이 훨씬 높다.

7 맺음말

프로그램 경험이 좀 있다면 데이터 파일을 사용하는 방법 정도는 대부분 알 것이다. 구현의 용이성에 비해 얻는 이점이 너무 크기 때문에 대부분의 사람들이 이 방법을 스스로 발명(?)한다. 어쨌든 이 글에서는 훨씬 강력하고, 그에 따라 훨씬 복잡해지는 방법들을 소개했다. 다음 게임 프로젝트를 시작할 때는 시간과 구현 가능성을 저울질해서 게임 프로젝트에 적당한 것을 선택하도록 하라.

• see also XML, CsvFileProcessing, Lua