[💬] 기획자 조패기 그만하고 개발하자!

[123123(121.150)]

어차피 능력없는 기획자는 팀원을 못구하든, 기술이 없건, 자기 기획을 구현하지 못하는건 당연한거고.

다른 사람 팀에 잔소리 하면서 참견해 얻을 수 있는게 뭐가 있을까?

잠깐 나보다 못난 팀, 안 될거 같은 팀 참견하면서, 잠시동안의 위안은 얻을수 있지만,

결정적으로 지금 자기가 개발하고있는 프로젝트는 멈춰있는 상태인거다.

결론은 개발이나 하자!

그러는 김에 나도 개발글 오랬만에 하나 쓰고 가야 겠다.

주제는 Data Driven Architecture 다.

(Data Oriented Programming 아님!)

게임을 구성하는 요소를 크게 나누면

데이터와, 로직이 있다.

로직은 객체가 무엇을 해야하는지를 나타내고,

데이터는 객체가 무엇인지를 나타낸다.

다른 말로 하면 로직은 객체의 기능이고,

데이터는 객체의 속성과 구성을 말한다.

Data Driven이란 Data를 분리하는데서 시작한다.

레벨 파일이라던지,

아키타입 파일이라던지,

스크립트 파일이라던지,

트윅이라던지,

기타 본체가 되는 게임이랑 상관 없는 것들을 구분하는게 그 시작이다.

어떻게 생겼냐면, 게임 어플리케이션이 정보를 읽어 와서, 

그 정보를 가지고 게임의 내용들을 만드는거지,

게임 자체에 하드 코딩 되어 있는 내용이 아니라는 뜻이다.

최대한 적은 콘텐츠만 하드코드 되어있어야 하고,

최소한의 기본값 정도만 하드코드 될수 있고,

오브젝트는 데이터베이스나 파일을 이용해서 만들어 져야 하고,

따로 엔진에 new Object가 없어야 된다.

왜 그럼 이따구로 만들까?

먼저, 프로그래밍 언어로 코드를 짜는건 어렵고, 프로그래머는 할일이 많다.

또 기획자는 해봐야 하는게 너무나 많기 때문이다. 이 수치가 맞는지 안 맞는지 어떻게 체크 할까?

감으로? 수식으로? 예측한 결과보다 더 좋은 수치를 찾을수도 있는게 테스팅의 좋은점이기 때문이다.

프로그래머가 아닌 사람한테

boost::unorderedmultimap<boost::string, Engine::GameObject>::iterator it = ~~~

이딴식으로 평소에 본적도 없는 프로그래밍 언어로 짜여진 무언가를 수정하는건 엄청나게 힘든일이기 때문이다.

심지어 오타 하나라도 생기면 빨간줄 또는 크래쉬가 나는 게임을 보면, 공포가 생길 수 밖에 없다.

또 코드가 바뀌는건 새로 컴파일을 해야하거나 빌드를 해야한다는 뜻이다. 

큰 프로젝트는 빌드하는데 10분 넘기는건 당연한거고, 이걸 줄이려고 여러가지 방법들을 이용하지만,

그렇다 하더라도 빌드하는데 오래걸리는건 당연한것이다. 

그래서 Data Driven이 좋은건 알겠는데, 그럼 어떻게 해야할까?

serialization 이라 불리는걸 해주면 된다. 

(serialization 한국어로 직렬화 라는데 으음.. 그냥 시리얼라이즈 쪽이 좋은거 같다;;)

중요한 값들을 읽어 와서, 정보를 쑤셔 넣어주면 된다는것이다.

(비지터 패턴(visitor pattern)의 일종이다.)

주된 구현 법이 있지만, 오픈소스 라이브러리는 이럴때 쓰려고 있는것이니, 오픈소스 라이브러리를 쓰자!

물론 직접 구현해도 되고, 디자인 패턴을 공부하는 가장 좋은 방법중 하나니까 만들어도 나쁜건 아니다!

구현 할때 필요한 것

serialize 메소드 또는 serialize 방법을 정의한 인터페이스를 지원하는 객체,

파일/데이터베이스에 저장 및 로드를 캡슐화한 스트림 객체 or serializer

객체를 serialize 하는 방식을 정의한 연산자 등등.

이런것들이 있으면 됨.

이러면 이것들로 텍스트 정보나, XML 정보, JSON 정보 등등의 여러가지 data들을 읽어 올수 있다.

serialization 단계는

1. 오브젝트를 만든다. (아직 활성화 된건 아님.)

2. serialization 해서 데이터를 읽어 온다. (여기서 똥값도 구분하고 필요 하다면 약간의 조정도 거친다.)

3. 객체를 완전히 초기화 한다. (즉 읽어온걸 세팅해준다. )

4. 생성 완료! (이제 실제로 게임에 존재하는거.)

그럼 어떻게 적용하면 될까?

일단 아무데서나 new 하면 안된다.

팩토리 패턴이라는 아주 좋은 방법이 있는데, 이 방법으로 객체를 생성하는게 좋다.

Object* ObjectFactory::CreateObject(string type)

{

switch(type)

{

case "Player" : return new Player();

case "Enemy" : return new Enemy();

case "Tree" : return new Tree();

}

return null;

}

이런식으로 만들면 된다. 

Factory에는 문제가 있는데, 저러면 모든 객체 타입에 대해서 

전부 헤더가 있건, import가 있건 필요하다는것이다. (C# 짱짱인것!)

또 새로운 객체가 추가될때마다 저 크리에이트 오브젝트 파일을 열어서

코드를 수정해야한다....

그래서 map을 쓰면 저게 해결이 된다! (물론 해쉬맵도 좋다 ㅎ.)

Object* ObjectFactory::CreateObject(string type)

{

Object* newObject = null;

newObject = ObjectMap[type]->Create();

return newObject;

}

이런식으로 고칠수 있다. 그럼 map에다가 오브젝트에 종류에 맞춰서 추가해주면 된다.

이러면 이제 위에서 한걸 한군데 합치면 된다.

Object* ObjectFactory::CreateObject(string file, string type)

{

File stream(file);

Object* newObject = null;

newObject = ObjectMap[type]->Create()

Serializer::Serialize(stream, type);

newObject->Init()

return newObject;

}

이렇게 되면 파일에서 읽어서 만들어진 새 오브젝트에 세팅을 해주고,

초기화해서, 만들어 준다.

하지만 여기서 끝이 아니다!

우리는 컴포지션을 아는 문명인이니까 컴포넌트 기반이더라도 읽어오면 된다!

Object* ObjectFactory::CreateObject(string file, string type)

{

File stream(file);

Object* newObject = null;

newObject = ObjectMap[type]->Create()

Serializer::Serialize(stream, type);

while(stream.IsEnd() == false)

{

Component* newComponent = null;

newComponent = CompoMap[compotype]->Create();

Serializer::Serialize(stream, compotype);

newObject ->Add(compotype, newComponent);

}

newObject->Init()

return newObject;

}

이러면 오브젝트에 저장된 각각의 컴포넌트도 무엇을 가지고 있고, 정보만 있다면 주르륵 하고 읽어 온다.

상용 게임엔진들도 저장된 정보를 이렇게 읽어 오는것이고,

레벨이나 모든 기타 등등 필요 한것도 이런 방식으로 읽어오는것이다.

물론 파일을 열어서, 정보를 읽어오는건 오래 걸리는 행동이기 때문에, 자주 읽어야 하는데이터면

그냥 메모리에 올려두고, 다시는 안읽어 오는게 가장 바람직하다. 

다시 읽어오게 만든다면 장점.

게임 테스트 도중에 값을 변경하면서 테스트 가능. (인게임 에디터가 없을시)

다시 읽어오는것의 단점.

게임 프레임이 튀면서 문제가 생김.

결론 : 컴파일 없이, 빌드 없이, 최소한의 빌드만으로 개발하기 위해

하드코딩된 값을 외부로 빼서, 최대한 많고, 빠른 반복를 위해 만들어진 방법이 data driven이다.

[지귀(117.111)]

조타 - dc App

[지귀(117.111)]

잘읽었음! - dc App

[地鬼(dczlatan)]

근데 게임 프레임은 왜 튀는거임??

[123123(121.150)]

ㄴ파일 로드하면서, 파일을 열고 닫는데, 파일이 어떤 형식이건 간에 어느정도 길이의 string을 담고 있을거고, 그걸 읽어 오면서 그 긴 길이의 정보를 다 훑는다고 생각해보셈.

[123123(121.150)]

특히 파일 포멧이 유니코드라면... 부하가 엄청 심한 비교를 해야되는거고;; UTF8이면 그나마 나은 경우지만 그것도 상당히 부담되는건 마찬가지...

[123123(121.150)]

string 비교는 결국엔 source[n] dest[m]의 행렬이 같은지 아닌지를 판단하는것이라 그럼.