자기만의 게임엔진을 만들어보자! #2

안녕하세요? 디퍼드H 입니다. 혹시 저의 강의를 기다리신 분 있나요? (없진 않겠죠? ㅡ.ㅡa) 갑작스런 싱가폴 친구들의 등장과 함께, 남의 집에서 얹혀살기(무지 불편했다는...), 이사까지...(조만간 다시 이사를 해야하는 실정입니다. 뭔가 복~~잡한 사연으로 인해) 여러일들 때문에 강의가 늦게 올라오고, 늦게 올라온 것도 모자라, 내용이 많이 부족하거나 적을 수도 있는 사연을 이해.. 이해 해주길 바라면서, 강의를 시작해보죠.

사실 저번 강의를 올리면서, 많은 고민을 했었습니다. 그 고민의 이유는 바로 메세지 시스템인데요. 사실 메세지 시스템은 저의 강의 가장 핵심적인 부분이기도합니다. 원래, 엔진을 처음 만드시는 분들 또, 학생(막 게임 프로그래밍에 접하신분들)을 위해서 강의를 하기에는 바로 메세지 시스템을 설명하기에는 조금 무리가 있다고 판단을 했거든요. 헌데, 예상외로 메세지 시스템에 대해 많이 궁금하신분들이 많아, 이번 강의는 메세지 시스템에 대해서 한번 짚고 넘어가고자 합니다.  물론 학생 분들이나 엔진을 처음 만드시는 분들은 아, 대충 이런 이야기이구나! 하고 넘어가더라도, 문제가 없을 겁니다. 왜냐? 시간이 지나서 다시 다룰거거든요. 전체적으로, 심도 있는듯 없는듯 한번 저의 메세지 시스템에 대해 한번 보도록 하죠.

제가 메세지 시스템을 만들때, 보통 롤 모델이 필요했습니다. 어떻게 만들어야 가장 효과적일까? 그렇게 생각하다보니 제일 먼저 떠오르는것이 우체국시스템이더군요. 우체국을 모르시는 분들은 없을거라 생각합니다. 우체국의 시스템은 오랫동안 아직도 유지되어 오고 있습니다. 이것은 바로, 그 시스템이 효과적이다라는 의미이겠죠. 이렇게 생각하면서 저는 메세지 시스템의 롤 모델은 우체국에서 이용되는 시스템(편지겠죠.) 정하고 메세지 시스템을 설계했었습니다. (사실 저 같은경우 어떠한 시스템이라던가 그외 필요한 것을 구현할때에는 보통 주위를 많이 이용하는 편입니다. 크게 많이 도움이 되더군요.) 우리가 보통 편지를 보내고 또, 다른사람에 받는데 까지에는 다음과 같은 방법이 이용됩니다. 우선 우린 편지를 씁니다.(편지를 쓸때에는 보내는사람, 받는사람, 주소, 그리고 내용이 들어가죠.) 편지는 편지통으로 들어가고, 그 편지는 우체국으로 모입니다. 우체국에서는 이편지를 주소에 따라 편지를 배정하고, 마침내 편지는 받는사람에게 가죠. 설마, 이렇게 편지가 여러분들께 가는것은 모르는 사람들은 없겠죠? (있다면 큰일입니다!) 이제 이 시스템을 우리가 구현할 메세지 시스템에 알맞게 바꾸어나가보도록 하죠. 우선 아래의 그림을 봅시다.

 

모든걸 다 넣으려고 하니, 그림이.. 크군요. 아무튼, 위의 그림을 보시면 이상한 클래스 이름들이 눈에 띕니다. 메세지 매니저 뭐 이름 그대로 아주 직관적이라 메세지를 처리하는곳이구나 라는게 감이 오지만 ISociable 클래스는 무엇인가? 라는 의문점이 생깁니다. 제가 메세지 시스템을 구현할 때, 정말 알맞은 변수명을 찾으려고 고생을 했는데 나온것이 ISociable 이었습니다. 우리 이전에 말했던 우체국 시스템(자꾸 우체국 시스템하니 좀 많이 어색한 것 같군요. 정말로 어색하지만 양해 부탁드립니다)을 이용해서 말한다면 주소 등록본(?) 아니 주민등록본(?) 과 비슷한 메세지(편지)를 서로 주고 받을 수 있도록 해주는 클래스라고 생각하시면되겠습니다. 편지를 주고 받는다 = 대화를 한다 -> 사회적이군! 이라는 결론으로 ISociable라고 지었는데, 개인적인 의견으로는 뭐 알맞다고 생각합니다(사실 멋지다고 생각한다는...)  이 클래스에는 메세지와 관련된 메소드와 변수를 가지고 있습니다.

 

프로그래머는 역시 코드로 보는게, 바로 뙇(요즘 이게 대세더군요) 감이 오실겁니다. 이전에 설명한 내용이라 넘어가도록 하죠. 다음은 ISociable을 관리하는 객체인 ISociableManager가 있습니다. 우체국으로 생각한다면, 우체국의 중요부서중 하나라고 생각하시면됩니다. 나머지 하나는 물론 메세지 매니저죠. ISociableManager와 MessageManager의 상호작용으로 우체국의 역활인 메세지를 받아 저장하고, 매 프레임 마다 메세지를 Dispatch를 한다고 보시면 됩니다.  ISociableManager는 메세지를 Dispatch하는 역활을 맡고 있고, MessageManager는 메세지를 메세지 큐에 매 프레임마다 들어오는것을 보관하고 관리를 합니다. 우선 아래의 그림을 보도록 하죠.

 

위 그림은 그래픽 시스템에서 다이렉트x의 초기화를 위해 윈도우 값이 필요해, 윈도우 핸들값을 메세지를 요구할 경우를 가정해서 관계도를 나름 멋지게(?)그려보았습니다. 사실 그림과 간단하게 붙어있는 설명들을 읽으시면, 뙇 어떻게 MessageManager와 ISociableManager 상호작용을 해서 메세지 시스템이 구현되는지 한눈에 아실거라 생각이 들지만, 그렇지 않을 분들을 위해 설명을 시작하도록하죠. 이 예시만 이해가 되신다면, 여러분도 여러분만의 메세지 시스템 구현을 위한 준비가 되었다고 봐도 될 것입니다.

우선 윈도우 시스템과 그래픽 시스템은 ISociable클래스를 상속받아, 메세지 주고 받을 수 있습니다.(코드적으로 설명하자면, 윈도우 시스템과 그래픽 시스템은 RecvMessage 메소드를 들고 있고, ISociableManager에 등록도 되어 있다는 말이겠죠?) 윈도우 시스템에서는 메세지를 우선 메세지 매니저로 메세지를 보냅니다.  메세지 매니저는 그 메세지를 매니저가 가지고 있는 메세지 큐에 넣습니다. 다음 프레임에 메세지 매니저에서는 메세지가 Dispatch 되어야하는지 우선 확인을 합니다. 후일 메세지 시스템 구현 부분에서 자세하게 다루게 되겠지만, 메세지 클래스는 여러가지 멤버 변수들을 가지고 있습니다. 그 중 하나인, DelayTime의 멤버변수는 언제 메세지가 Dispatch되어야하는가를 가리키는 변수명입니다. 만약 DelayTime이 1.0f의 값을 가지고있다면 1초 후에 이 메세지를 Dispatch해야 한다는 것을 의미합니다. 게임 엔진이 60fps로 돌아간다고 가정했을때, 이 메세지는 약 60프레임 이후 메세지가 Dispatch 된다는 것을 의미합니다. 메세지 시스템에서는 매 프레임마다 이 변수의 값에서 -0.166666f 값을 빼주면서 0 이하가 된다면 이 메세지는 처리되어집니다. 메세지 처리가 준비되었을때, 메세지 시스템에서는 DispatchMessage 메소드를 실행시키기 시작합니다. 이 메소드는 메세지에서 수신자의 id혹은 이름을 꺼내서 ISociableManager에 등록되어있는 ISociable객체를 찾아서 RecvMessage 함수를 실행시킵니다. 예시로 돌아가서, 메세지에서는 수신자가 WindowSystem으로 되어 있었습니다. 현재 윈도우 시스템은 ISociableManager에 등록되어 있고 결국 메세지 매니저에서는 윈도우 시스템에서 구현된 RecvMessage 함수를 실행시키고 이 함수내에서 윈도우 핸들을 달라는 메세지에 알맞는 행동이 구현되어 있을 것입니다.  그럼 윈도우 시스템은 아마 윈도우 핸들 값을 동봉한 메세지를 날려주겠죠?(데이터를 어떻게 동봉하는가?는 후일 구현부분에서 다룰것입니다.)

지금까지 여러분들과 함께 메세지 시스템은 어떻게 만들것인가? 만들어지는가? 에 대해서 확인해보았는데요. 오늘은 자세한 듯하면서, 또 어찌보면 아닌듯이 알아보았습니다. 어떤분들은 지금까지의 내용으로도 충분히 여러분만의 메세지 시스템을 만들 수 있다고 생각이 듭니다. 여러분들은 충분히 할 수 있습니다! 이번강의에서 일부러 메세지 클래스를 어떻게 만드는건가? 또 MessageManager와 ISociableManager 구현과 팁은 포함시키지 않았습니다. 이 내용은 후일 강의를 진행해 나가면서, 때가 되면 다루어 보도록 하겠습니다. (많은 댓글과 열혈한 성원은 강의 진행에 무지 도움이 되어 메세지 시스템 구현 강의가 빨리 진행될 것을... 알려드립니다 ~ ㅋ^^) 사실 오늘 넘 정신이 없다보니 중간중간 여러분들이 이해 안되는 부분이 있을 수 있을거라 생각이 (엄청) 듭니다. 여러분들 중 이해가 안되거나 궁금한 내용은 댓글로 남겨주신다면 최대한 성실히 답변해드리도록 하겠습니다.