1. 윈속의 역사
이미 게임을 하나 운영하고 있는 곳이라면 많은 것이 갖춰져 있습니다.
개발자 이외에도 DB, 서버, 패치 시스템, 그리고 그것을 돌려주는 여러 DBA, SE분들이 있습니다.
그러나 아무 것도 없는 곳에서 새로 온라인/네트워크 게임을 만든다면 맨땅에 헤딩을 해야 합니다.

우선 기획서가 나오고 DB라던가 여러 가지 인프라들이 먼저 있어야할 것이지만,
가장 단순하게 윈도우 서버와 클라이언트부터 만든다고 가정합시다.
자, 그럼 서버는 어떻게 만들어야 할까요?
서버를 만들기 전에 서버와 클라이언트에는 어떤 "Winsock Model"을 사용할런지부터 결정해야 합니다.

원래 소켓은 Windows 운영체제가 아니라 BSD UNIX에서 먼저 만들어졌습니다.
그래서 초창기 윈도우 3.1 같은 경우에는 소켓(http://www.joinc.co.kr/modules/moniwiki/wiki.php/man/12/BSD%20socket)
이 아예 존재하지 않았습니다.

이는 단순 소켓 지원 여부를 떠나 당시 마이크로소프트(앞으로 MS)의 중요한 의사 표방이기도 합니다.
소켓은 TCP/IP, UDP를 위한 라이브러리이고 TCP/IP, UDP같은 프로토콜은 바로 인터넷의 기반이 되는 프로토콜들이죠. 모든 것을 집어삼킨 HTTP 역시 TCP/IP 80번 포트를 이용한 텍스트기반 프로토콜 아니겠습니까?

다시 말해, MS는 현재의 인터넷이 이리 사용될지 몰랐습니다, 무려 90년대 중반까지도요!
MS는 소켓과 TCP/IP가 아닌 자신들의 프로토콜로 MS-Network라는 현재의 인터넷과 비슷무리하지만 다른 개념을 만들고 싶었습니다.

그 망상은 Windows 2000 이 등장하면서 공식적으로 사라졌는데 \\로 접근하던 다른 PC접근과 네트워크 공유를 NetBIOS(NetBIEU) 설치 없이 TCP만 설치하면  되도록한 것이 그 증거(?)라고 볼수 있습니다. 정확하게 말하면 NetBIOS over TCP/IP 이란 개념인데 아뭏든 90년대에도 MS는 인터넷도, TCP도, BSD 소켓도 반대! 그냥 MS껄로 다 정ㅋ벅ㅋ할꺼야!!였었습니다.


....................




...........





.....


..


그러나 어쩌겠습니까?
모두가 알다시피 인터넷(다시 말해 TCP/IP과 그것을 쓰기 위한 BSD Sockets)이 대세가 되었는데요.

할수 없이, MS는 BSD 소켓과 똑같은 윈도우용 소켓 라이브러리를 제작합니다.
BSD 소켓 4.3에 기반해 1993년 WinNT 3.51과 함께 Winsock 1.1을 공개합니다.
즉, Winsock은 WINdows + SOCKet의 약자지요.




이 윈속 1.1은 놀랄만큼 BSD 소켓과 동일합니다.
고인이신 스티븐슨의 UNIX Network Programming에 있는 소스 대부분이 헤더 파일만 약간 바꾸면 그대로 돌아갈 정도입니다.

이는 다이렉트X 초창기의 모습과 유사합니다. DOS 게임 개발자들에게 복잡한 Windows Procedure와 콜백을 잘 몰라도 DOS 게임을 그대로 포팅할수 있도록 한 배려와 비슷한 모습입니다.

하지만 이때까지도 MS는 TCP/IP의 가능성을 잘 몰랐습니다.
...그래서 Winsock 1.1을 사용하는 Windows 서버는 ....상당히 구렸습니다.
윈도우는 서버로는 절대 안된다는 말이 이때부터 흘러나왔죠.

그러나 1995년 WinNT 4.0의 등장과 함께 선보인 Winsock 2.0부터 상황은 달라지기 시작합니다.
아키텍쳐부터 싹 달라졌습니다.
1.0과의 호환성은 100% 유지하면서 Windows에 최적화된 진짜 Winsock이 등장한 것입니다.
(달라진 아키텍쳐로 "개인방화벽" 프로그램이 만들어질 수 있었습니다. 자세한건 "SPI"로 검색을 ^^)
현재 우리가 주력으로 사용하는 Winsock은 16비트 모드가 제거되어 1996년에 발표된 2,2를 사용하고 있으며
Win8이 등장할때 Winsock에 Registered IO extensions 이 추가된다고 하는데 간만에 Winsock에 새로운 기능이 추가되는 것이라 기대가 큽니다.

2. 윈속 모델

드디어 오늘 기초의 핵심인 윈속 모델 이야기를 하겠습니다.
안타깝게도 윈속이 버전업이 되었다고 해서 윈속의 성능이 공짜로 올라가는 것은 아닙니다.

네트워크 프로그래밍에서 첫쨰 난관은 언제 "1) 누가 서버에게 Connect를 해 올줄 모른다"는 점입니다. 그리고 이때 클라이언트가 Connect를 해오는 순간, 아주 빠르게 accpet()를 해줘야 합니다. 접속이 수천개가 되면 이 작업 역시 딜레이가 걸리고 컨텍스트 스위칭이 걸립니다.
그런 다음, 일단 양쪽이 연결이 되면 "2) 서버든 클라든 언제 상대방의 메시지를 듣기 위해 recv()를 해야할지 모른다"는 점입니다(아시겠지만 연결을 끊는 close() 역시 사실은 상대방에게는 recv()입니다.)

이미지 출처 : http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzab6%2Frzab6connectionor.htm

사실 게임 클라이언트처럼 소켓 5개 정도에서는 큰 차이가 없습니다만,
서버는 한 프로세스가 수백~수천개의 접속을 관리해야 합니다.
이를 위해 단일 thread를 돌리는 방법으로는 고작 수십명이면 금방 한계에 찹니다.
아무리 서버장비가 좋아도 똑같습니다.
왜 단일 thread는 안될까요?
thread라는게 마법은 아닙니다. 단순히 CPU 한계치까지 일을 시킬 뿐, 계속 루프를 돌며 찌질하게 검사하는 역활 밖에 할 수 없습니다.

좋은 서버란 가장 적은 thread와 CPU를 사용해 가장 많은 접속을 빠르게 처리해줄수 있어야 하며 이를 위해 두가지 개념을 먼저 알아야 합니다.

우선 비동기(asynchronous )라는 개념이 들어갑니다.
쉽게 말해 계속 루프를 돌며 검사하는게 아니라 클라이언트에게 접속요청이 왔거나 메시지가 왔을때에만
해당 소켓에게 알맞은 작업을 해주는 것입니다.

그래서 비동기 Winsock을 위해 4가지 모델이 고려되었습니다.

...는 아니고...

모델명	특징	기타
Window Message Select       (WSAAsyncSelect)	소켓 이벤트를 윈도우 메시지를 이용해 알려준다.	윈도우 메시지를 이용하므로 반드시 윈도우가 생성되어야 하며 MFC의 CSocket 클래스가 바로 이 모델.
Kernel Event Select      (WSAEventSelect)	소켓 이벤트를 커널 이벤트로 알려준다.	한 객체당 최대 64개의 이벤트 밖에 못쓰므로 서버로 쓰기 위해서는 코드가 쓸때없이 복잡해짐.
Overlapped I/O     (Overlapped)	소켓 이벤트를 비동기 읽기/쓰기를 위한 오버랩 구조체를 이용해 알려준다.	위의 둘과 달리 Overlapped와 IOCP는 Win95, 98에서는 안됩니다. 이 기법은 파일에 비동기로 읽기쓰기를 같이 하기 위함이었으나 소켓이든 파일이든 둘다 같은 HANDLE 이잖아요? ^^ 역시 MS의 꽁수의 결정체라 불릴만 합니다.
Overlapped I/O + IOCP     (IOCP)	위의 방식에 더해 커널 큐잉을 통해 소켓 이벤트를 통보받는다.	사실상 윈됴에서 서버는 이넘으로 정해져있다. C#에서 비동기 선언해도 IOCP가 만들어진다. 결론은 서버는 IOCP가 정답입니다!

...이런 모델들입니다.


두번째는 넌블로킹(non blocking)개념입니다.
단일 thread가 아닌 비동기 서버를 짰다고 합시다.
이때 어떤 이벤트가 일어나면 비동기로 OS가 서버에게 알려줍니다.
그러나 send(), recv() 같은 함수는 블로킹(blocking)함수 입니다.
send(), recv() 작업이 끝날 때까지 서버 프로그램은 다음 일을 할수 없습니다.
이때 WSASend(), WSARecv같은 넌블로킹 함수로 대체한다면, 작업이 끝나기 전에 서버는 다음 작업으로 진행될 수 있습니다.

아마 넌블러킹 함수는 네트워크 프로그래밍에서 처음 보신 분들도 있을 것이지만,
수많은 I/O관련 함수들의 고급은 전부 넌블러킹으로 흘러가게 됩니다.
넌블러킹 함수는 어쩔수 없이 Callback 함수가 반드시 뒤따라갑니다.
그래서 처음 접하면 조금 어렵습니다............................................가 아니라 실은 많이 어렵습니다,
거기에 Overlapped나 IOCP같은 비동기 통보까지 더해지면 아주 복잡해집니다.

다행히 클라이언트에서 주로 쓰이는 WSAAsyncSelect 모델과 WSAEventSelect 모델에서는 넌블로킹이 그리 중요한 개념은 아닙니다. 유선 인터넷이 하도 빨라서요... 
클라이언트에서 넌블로킹을 잘못 쓰면 소켓 응답 오기 전까지 게임 프로그램 자체가 위험해질수도 있고
그 사이 화면 UI처리같은 다른 할일들도 신경을 써야 합니다(<-이거 은근 고급 토픽입니다.).



3. 오늘의 소스
오늘의 소스는 간단한 클라이언트/서버 소스입니다.
클라이언트는 MFC로 만들었고 Winsock Model 역시 CSocket, 즉 윈도우 메시지 방식입니다.
서버는 boost::asio로 짰습니다. 기본 TCP 서버를 그대로 썼습니다.
단, 한 파일로 설명된 소스를 보기 좋게 클래스별로 나눠놨습니다.
이 정도면 네트워크 프로그래밍에 익숙하지 못한 초보분이라도 약간의 노력이면 다음 시간부터 따라오실수 있을 것입니다.

이 간단한 프로그램들로 네트워크 게임을 위한 첫 삽질이 시작될 것입니다.




4. 더 생각해볼꺼리


내용은 맘대로 퍼갈수 있지만 동의없는 수정은 안되며 출처(http://www.gamedevforever.com/ , http://rhea.pe.kr/ )를 명시해주세요.

// 원래는 1월 12일에 포스팅해야 하는데 퐆프님께 허락받고 스케쥴보다 일찍 올립니다. 기획 카테고리엔 글이 너무 적어요 ;ㅅ;

전편에서는 스타크래프트 유닛의 이동을 예로 들면서 재정의(Override)를 이용한 다형성(Polymorphism)에 대해서 간단하게 설명해보았습니다. 하지만 아마도 C++, JAVA 등과 같은 객체지향적 프로그래밍 언어를 전혀 공부해본적이 없는 사람이라면 아직 뭐가 뭔지 제대로 이해하기는 어려울 겁니다. 하지만 너무 낙심할 필요는 없습니다. 현업 프로그래머라도 경험과 시행착오가 쌓이지 않으면 제대로 활용하지 못하는 것이 바로 이 개념이니까요.

그런데, 두 번째 포스팅을 이어가기 전에 한 가지 짚고 넘어갈 점이 있습니다. 기획자가 왜 프로그래머의 영역인 객체지향이나 추상화를 알아야 하는가하는 '논란'입니다.

흔히 기획자가 프로그래밍을 공부하는 경우의 단점으로 '창의성 저하'를 많이 언급합니다. 프로그래밍을 공부한 기획자는 어떤 아이디어를 떠올릴 때 구현여부를 먼저 고민하기 때문이라는 이유죠. 물론 그런 기획자도 있을 수 있겠지만, 어설프게 프로그래밍을 공부했다고 해서 어떤 아이디어가 기술적으로 구현할 수 있는지를 정확하게 판단하는 것 자체가 불가능한 일입니다. 그리고 게임 개발에 있어서 '이 아이디어는 구현할 수 없다'는 판정을 받는 경우는, 그것이 기술적으로 불가능하다기보다는 개발의 효율성이나 최적화의 관점에서 포기하는 경우가 대부분입니다. (또는 기획서가 무슨 말을 하는 건지 이해하기 어렵거나, 만들기 귀찮아서일 수도 있음)

즉 구현이 불가능한 것은 아니지만, 프로젝트의 목적에 부합하지 않거나, 혹은 개발기간이나 비용, 엔진성능 또는 유저 시스템 요구사양의 한계 때문에 포기하는 것이죠. 어떤 아이디어의 기술적인 구현여부나 방법을 최종적으로 결정하거나 판단하는 것은 기획자가 아니라 테크니컬 디렉터(TD) 정도의 실력과 짬밥이 쌓여야 가능한 일입니다.

따라서 시스템 기획 단계에서부터 객체지향적 설계방식을 숙지하고 있는 기획자가 기획 아이디어를 1차적으로 추상화하거나 혹은 추상화의 단서를 제공하여 프로그래머와 함께 조율을 하는 것이 서로에게도 좋고 개발 프로세스 전체에 있어서도 바람직하다는 것이 필자가 이 포스팅을 통해 전하고 싶은 핵심입니다.

그러면 추상화는 대체 어떻게 해야 할까요? WoW의 스킬을 예로 들자면, 화염구, 얼음 회오리, 돌진, 방패막기, 각종 버프 등과 같은 각각의 스킬은 구체화된 객체(object)라고 할 수 있습니다. 객체지향 프로그래밍에서는 이렇게 구체화된 최종 결과물을 인스턴스(instance)라고 부르죠. 여러분들이 만약 스킬 시스템을 기획한다면, 초기 기획단계에서 구상한 스킬 목록을 바탕으로 공통점을 추려내서 비슷한 것끼리 분류하는 작업이 바로 추상화입니다.

그런데 문제는, 객체지향에서 말하는 추상화를 제대로 이해하지 못한 상태에서 공통점을 추려내면, 바로 위에서 말한 1번이나 2번과 같은 분류 정도 밖에는 할 수 없다는 사실입니다. 그렇다면 객체지향을 공부하고 C++ 같은 언어를 좀 만져봐야만 하느냐? 물론 공부를 하는 것이 좋습니다. 적어도 여러분이 시스템 기획자로 성장하기를 원한다면, 최소한 C++ 책 한 권 쯤은 독파하시기를 권합니다. 저는 오래 전에 객체지향적인 프로그래밍 언어를 공부하지 않은 상태에서 이론적으로만 객체지향을 공부한 적이 있었는데, 확실히 직접 코드를 만지면서 공부하는 것보다 훨씬 이해하기 힘들었습니다. 하지만 이런저런 이유로 아직 프로그래밍을 공부할 상황이 안 되거나 공부해도 잘 이해하기 어렵다면, 일단은 워크래프트3 에디터 같은 좋은 에디터 툴을 다뤄보면 아주 큰 도움이 됩니다.

워3 에디터의 경우, 툴의 오브젝트 에디터에 워3에서 기본적으로 제공하는 유닛과 스킬, 기타 오브젝트들에 대한 데이터를 볼 수 있습니다. 그런데 이것들을 잘 살펴보면, 그 다른 건 전혀 건드리지 않고 단지 데이터만 수정해서 새로운 유닛이 되거나 새로운 스킬이 만들어질 수 있습니다.

예를 들어 화염구와 같은 스킬은 이름을 냉기화살로, 데미지 속성값을 냉기타입으로, 발사체 모델링을 얼음덩어리로 수정하면 화염구가 아닌 냉기화살이 돼죠. 워터엘레멘탈 소환 스킬은 소환물 데이터를 드래곤으로 바꾸면 드래곤 소환스킬로 변합니다. 이런 일들이 가능한 이유는 처음 시스템을 설계할 때부터 확장성과 유연성을 가질 수 있도록 철저한 추상화를 거쳤기 때문입니다. 그리고 이와 같이 데이터(값)만 바꿔서 구현할 수 있는 것은 하나의 공통성을 가지고 있다고 할 수 있으며, '개발(구현)의 관점'에서 본다면 하나의 객체로 간주할 수 있습니다.

그럼 다음 포스팅에서는 추상화에 대해서 보다 깊이 있게 들어가 봅시다. 다음 포스팅이 올라올 때까지 여러분이 즐기는 게임에서 특정 시스템을 놓고 데이터만 다르고 나머지는 같은 공통성을 가진 객체들을 분류하는 연습을 한 번 해보시길 바랍니다.

to be continued...

안녕하세요. 친절한티스 라는 필명(?)을 쓰고 있는 박기헌입니다. 다른 네임드 필자분들이 워낙 고급 주제로 글을 올려주시는 바람에 저의 쩌렙티가 팍팍나는 글을 읽고 많은 분들이 실망하실까봐 걱정이 이만 저만 아닙니다. 그래도 작게나마 이제 막 프로그래밍에 입문하시는 분들에게라도 도움이 되겠지 생각으로 글을 써볼까 합니다.

RTTI란?
Run-Time Type Infomation 또는 Run-Time Type Identification 이라고도 합니다. 한글로 풀이하자면 "실시간 형식 정보" 라고 할수 있겠죠. 그럼 이게 무엇에 쓰는 물건인가? 라고 하면, 일단 다형성에 대해 알아야 할 것 입니다. C++에서는 대표적인 특징 중 하나로 다형성이라는 것이 있습니다. 부모 객체의 포인터로 자식 객체를 가리킬수 있는 것이죠. 간단하게 코드로 봐보자면 밑에와 같습니다.

class Parent
{
public:
	virtual void Print()
	{
		printf( "i'm your father!!\n" );
	}
};

class Child : public Parent
{
public:
	Child() : m_iMagicNum(777), m_pMagicPointer(NULL) {}

	virtual void Print()
	{
		printf( "i'm succeeding you father!!\n" );
	}

	void PrintMemVar()
	{
		printf( "Magic~ Magic~ : %d, %d\n" );
	}
private:
	int m_iMagicNum;
	int* m_pMagicPointer;
};

void main()
{
	Parent *pParent = new Child;
	pParent->Print();
}

위의 main 함수를 보시면 부모 클래스인 Parent 포인터 변수를 통해 Child 객체를 생성하여 Print 함수를 호출하고 있습니다. 여기서는 "i'm succeeding you father!!" 가 출력되겠죠. 이와 같은 코드는 실무에서 빈번하게 일어납니다. 실제 객체가 어떤 모양이든 간에 상관없이 인터페이스 클래스를 통해 객체들을 통합적으로 관리할수 있는 이점을 제공하기 때문이죠.

그런데 여기서 Child의 PrintMemVar 함수를 호출할 일이 생긴다면 어떨까요? pParent는 실제 Child 객체이니까  PrintMemVar 함수를 호출할 수 있어야 합니다. 그런데 pParent는 현재 Parent 형이니  PrintMemVar 함수에 대한 정보가 없습니다. Child 형으로 형 변환을 해주어야   PrintMemVar 함수를 호출 할 수 있죠.

void main()
{
	Parent *pParent = new Child;
	pParent->Print();

	// Child* 형으로 형변환
	Child *pChild = (Child*)pParent;
	pChild->PrintMemVar();
}

잘 작동합니다. pParent가 애초에 Child 객체이니 당연한 결과죠. 하지만 이 코드는 굉장히 위험한 코드입니다. 위의 코드야 앞서 pParent가 Child 객체인 것을 알고 있으니 이런 식으로 코드를 작성할 수 있는 것이지 실무에서는 현재 가리키고 있는 객체가 Child 형인지 Parent인지 또는 전혀 다른 상속 객체인지 알 수가 없습니다.

pParent가 Child가 아닌 Parent로 객체를 생성한 후, Child*형으로 형변환 하여 PrintfMemvar를 호출 해보면 전혀 예상치 못한 값들이 출력됩니다. 실제 프로젝트에서 이런 상황이 발생하게 되면 최악의 경우 크래시가 발생할 확률이 커집니다. 이런 문제를 방지 하기 위해 형변환을 하기 전 객체의 형식 정보를 확인할 필요가 있습니다.

RTTI는 바로 이 확인 작업을 위한 장치로 현재 객체의 형식 정보를 검사할 수 있는 명령어를 제공하고 있습니다. 대표적으로 dynamic_cast가 그것입니다. ( 이 외에, typeid, type_info 등이 있습니다. 자세한 것은  http://msdn.microsoft.com/en-us/library/b2ay8610.aspx 참고 )

void main()
{
	Parent *pParent = new Child;
	pParent->Print();

	// pParent가 Child* 형으로 변환 가능한지 검사
	// pParent가 Child* 형이 아니면 NULL 이 반환된다.
	Child *pChild = dynamic_cast<Child*>(pParent);
	if( pChild )
		pChild->PrintMemVar();
}

위의 메인 함수에 추가된 코드 입니다. dynamic_cast를 통해 형 변환을 수행하면 pParent가 가리키고 있는 객체가 Child 이라면 포인터를 반환하고 그렇지 않으면 NULL 포인터를 반환하게 됩니다. 이를 통해 안전하게 Child 형으로 변환하여 Child에서 정의한 함수를 호출할 수 있습니다.

dynamic_cast의 문제 
dynamic_cast 로 안전하게 다운캐스트( down cast, 부모형에서 자식형으로 형변환 )를 할수 있다면 모든 문제가 다 해결된거 같습니다. 그런데 문제가 있습니다. dynamic_cast가 느리다는 겁니다. dynamic_cast 를 사용하면 내부적으로 RTTI 정보를 체크하고, 변환할 객체에 대한 형식 정보를 비교하는데 이 수행 비용이 큰게 문제입니다. 

게임에서 퍼포먼스는 생명과도 같습니다. 아무리 멋진 게임이라도 프레임이 뚝뚝 끊기거나 느리면 하기 싫어지죠. 그래서 많은 프로그래머들이 1프레임이라도 더 빠르게 하기 위해 많은 노력을 합니다. 느린 dynamic_cast 대신에 빠르면서도 안전하게 다운캐스트 할수 있는 방법은 없을까 생각해볼 수 있죠.

만들어 봅시다
dynamic_cast 보다 빠르면서 같은 기능을 수행할 수 있는 방법은 의외로 간단하게 구현 할 수 있습니다. 

class CRTTI
{
public:
	CRTTI( const wstring strClassName, const CRTTI* pBaseRTTI );
	inline const wstring& GetClassName() const;
	inline const CRTTI* GetBaseRTTI() const;

private:
	const wstring		m_strClassName;
	const CRTTI*		m_pBaseRTTI;
};

위 클래스가 새로운 RTTI 검사를 위한 클래스입니다. 정말 간단하죠? 단순히 클래스 이름과 부모 클래스를 위한 멤버변수 하나가 전부입니다. 그러면 이것을 어떻게 이용해서 객체의 형식을 검사할지 보겠습니다.

// 최상위 클래스에 선언
#define DeclRootRTTI(classname) \
	public: \
		static const CRTTI ms_RTTI; \
		virtual const CRTTI* GetRTTI() const { return &ms_RTTI; } \
		static bool IsKindOf( const CRTTI* pRTTI, const classname *pObject ) \
		{ \
			if( NULL == pObject ) \
			{ \
				return false; \
			} \
			return pObject->IsKindOf( pRTTI ); \
		} \
		bool IsKindOf( const CRTTI* pRTTI ) const \
		{ \
			const CRTTI* pTmp = GetRTTI(); \
			while( NULL != pTmp ) \
			{ \
				if (pTmp == pRTTI) \
				{ \
					return true; \
				} \
				pTmp = pTmp->GetBaseRTTI(); \
			} \
			return false; \
		} 

// 자식 클래스들에 선언
#define DeclRTTI \
	public: \
	static const CRTTI ms_RTTI; \
	virtual const CRTTI* GetRTTI() const {return &ms_RTTI;}

#define ImplRootRTTI(classname) \
	const CRTTI classname::ms_RTTI(L#classname, NULL)

#define ImplRTTI( classname, baseclassname) \
	const CRTTI classname::ms_RTTI(L#classname, &baseclassname::ms_RTTI)


// Parent 클래스는 최상위 클래스다
class Parent
{
public:
	DeclRootRTTI(Parent); // RootRTTI 선언

public:
	virtual void Print()
	{
		printf( "i'm your father!!\n" );
	}
};
ImplRootRTTI(Parent);

// Child 클래스는 Parent로부터 상속 되었다
class Child : public Parent
{
public:
	DeclRTTI;

public:
	Child() : m_iMagicNum(777), m_pMagicPointer(NULL) {}

	virtual void Print()
	{
		printf( "i'm succeeding you father!!\n" );
	}

	void PrintMemVar()
	{
		printf( "Magic~ Magic~ : %d, %d\n" );
	}
private:
	int m_iMagicNum;
	int* m_pMagicPointer;
};
ImplRTTI(Child, Parent); // Parent에서 상속됨을 알린다

매크로 때문에 코드가 복잡해 보일 수 있지만 잘 보시면 별거 없습니다. CRTTI를 각 클래스에 정적 변수로 선언을 해주고, 상위 클래스가 있는 경우 CRTTI의 m_pBaseRTTI 멤버 변수에 상위 클래스의 CRTTI 정적 멤버 변수를 저장하는 것이 전부 지요. 그리고 이 각 클래스의 CRTTI 정적 멤버 변수를 비교함으로서 클래스의 형식 정보를 알아 낼 수 있습니다. 단순 포인터 비교이기 때문에 속도도 빠르지요.

그럼 실제 사용 예제를 보겠습니다.

#define IsKindOf(classname, pObject) \
	classname::IsKindOf(&classname::ms_RTTI, pObject)

void main()
{
	Parent *pParent = new Child;
	pParent->Print();

	// pParent가 Child* 형으로 변환 가능한지 검사
	if( IsKindOf( Child, pParent ) )
	{
		Child *pChild = (Child*)pParent;
		pChild->PrintMemVar();
	}
}


// 좀더 dynamic_cast 와 비슷한 방식으로 사용 하기 위한 방법
// DeclRootRTTI 매크로에 밑의 코드를 추가
static classname* DynamicCast( const CRTTI* pRTTI, \
	const classname* pObject ) \
	{ \
		if( !pObject ) \
		{ \
			return NULL; \
		} \
		return pObject->DynamicCast( pRTTI ); \
	} \
	classname* DynamicCast( const CRTTI* pRTTI ) const \
	{ \
		return ( IsKindOf( pRTTI ) ? ( classname* ) this : NULL ); \
	}

#define DynamicCast(classname, pObject) \
	((classname*) classname::DynamicCast(&classname::ms_RTTI, pObject))

void main()
{
	Parent *pParent = new Child;
	pParent->Print();

	// pParent가 Child* 형으로 변환 가능한지 검사
	Child *pChild = DynamicCast(Child, pParent);
	if( pChild  )
		pChild->PrintMemVar();
}

밑의 DynamicCast 부분을 보시면 dynamic_cast와 같은 방식으로 사용하면서도 수행 속도에서는 훨씬 빠른 형식 정보 검사를 할수 있습니다. 

해결해야 할 점
기존 dynamic_cast에 비해서 빨라졌다 하나 아직은 개선의 여지가 있습니다. 상위 클래스와 비교시 상속 깊이만큼 루프를 돈다는 점이나 메모리 비친화적이라는 점, 매크로를 많이 쓴다는 등이 있겠네요. 이런 점등은 좀더 고민해봐서 개선을 해봐야 할 것입니다. 

 

1. 시작합니다.

저번 시간에는 프롤로그에 가까웠지요. 이번부터가 진짜 강의입니다. shaderFX는 다 설치 하셨는지요?
이번 시간에는 shaderFX의 기본 사용법과 기초 이론을 알아보도록 하지요.
또한 shaderFX 를 이용해서 할 수 있는 일도 간단하게 소개해 드릴께요.

2. ShaderFX 기본 사용법

2-1 실행해 봅시다.

이제 ShaderFX가 설치되었으면 우선 실행을 해야 합니다. Render/ShaderFX를 실행해 봅시다.

이런 창이 열릴 겁니다. 왠 도마뱀이 꼬리를 치고 있네요.
등록되었다지 않았다는 말이 나오고 있긴 하지만, 어차피 무료입니다. 사용하는데는 아무런 문제가 없습니다.

이게 shader FX 라고 하는 프로그램이고, 그냥 '또 하나의 메터리얼 에디터' 라고 생각하셔도 아무런 문제가 없습니다. ^[각주:1]

2-2 쉐이더를 만들고, 오브젝트에 적용해 봅시다.

자 그럼 뭔가 일단 하나 만들어 보고 시작할까요.
가장 만만한 녀석인, 주전자 하나 만들어 봅시다. 그래픽 디자이너라면 이 정도는 쉽게 하시겠지요?
네? 원화 디자이너라서 못하신다고요? 허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허
이건 기술 축에도 들지 못하는 간단한 기능입니다. 그냥 클릭 두 번만 하면 되는건데요. ^[각주:2]

주전자가 만들어졌으니 이제 여기에 메터리얼(shader)을 입혀야 겠지요

shaderFX의 창에서 StandardMat_ 어쩌고라고 씌여진 창을 클릭합니다.
이게 지금부터 만들 shader의 루트(Root) 창 입니다. 가장 기본이 되는 베이스예요.

그리고 주전자도 클릭합니다. 이제 주전자에 이 shader를 적용할 예정이니,
반드시 두 개가 같이 선택이 되어 있어야만 하는 거지요.

자, 이렇게 두 개가 모두 선택이 되었다면, 이번엔 shaderFX의 창에서 Tool/Assign Material to Selection 을 누릅니다.

음? 왠 경고가 뜹니다.

경고 내용을 차분하게 읽어보면, '당신은 아직 FX 파일이 어디에 생성될 것인지 결정하지 않았으니 임시로 내가 만들어 놓겠소' 라는 뜻입니다. 뭐, 일단은 큰 상관 없습니다. [확인] 을 눌러서 다음으로 넘어가 보지요.

짜잔.

축하드립니다! 첫 번째 쉐이더를 완성하셨습니다!!! 자 이제 끝!

... 물론 이건 끝이 아닙니다. 이제 시작일 뿐이죠.







2-3 빠알간 주전자를 만들어 봅시다.

프로그래머가 쉐이더를 배울 때, 제일 처음 하는 것이 바로 이 '빨간 공' 만들기 입니다 .
우리는 명색이 그래픽 디자이너이니, 빨간 공으로 만족할 수 없습니다. 빨간 주전자를 만들어 봅시다!!! 간디작살
만들기는 매우 간단합니다.

shaderFX의 화면의 빈 곳에서 오른쪽 클릭을 하면 나오는 메뉴에서, Maps/Color 를 선택하는 것입니다.
Map는 말그대로 맵을 만든다는 것이고, 그 중 "Color Map" 하나를 만든다는 것이지요.

필자의 이름이 그림에 고스란히 노출되었지만, 못 본 척 하고 지나가도록 합시다.

이렇게 하면, 왠 회색 사각형 카드 같은게 하나 나오게 됩니다. 이게 Color Map 오브젝트 입니다.
이름도 Color 네요.
이 Color 오브젝트를 선택하면 오른쪽에 해당되는 인터페이스가 나오므로, 여기서 빨간색으로 바꿔 줘 봅시다.
오른쪽 인터페이스에서 이름도 바꿀 수 있으니까, 원하시면 바꾸시면 되지요.

빨간색 오브젝트가 되었습니다. 공은 아직도 하얀색이지요. 별로 바뀐게 없습니다.

자 이번엔 빨간색 오브젝트 아래에 있는 RGB 라고 씌인 녹색 동그라미를 보십시오.
이걸 마우스 왼쪽 클릭 - 드래그 하면 왠 선이 나오는데 , 이것을 Ambient Color 로 이어줍니다.

그냥 드래그해서 Ambient Color에 놓고 오면 됩니다.
즉 "빨간 맵을 엠비언트라고 하는 요소에 적용" 했습니다.
공이 빨갛게 변했습니다!!! 이런 종북좌파빨갱이!

선을 끊는 방법은, 선을 선택하고 Delete 키를 누르기만 하면 됩니다.
다시 이어주는 것은 언제건 상관없이 할 수 있습니다.

색을 바꾸는 것은 다시 color 오브젝트를 선택하고 , 다른 색으로 바꿔주면 됩니다.
그런데 되지 않습니다. 응?

놀랄 필요 없습니다. 이렇게 칼라를 바꾸는 경우에는 F5나 Color옆의 'Set'버튼을 눌러주기만 하면 적용됩니다.

2-3 저장하기
일단 첫 쉐이더를 완성하셨음을 축하드립니다. 프로그래머들도 이런 식으로 첫 번째 쉐이더를 만들거든요. ^[각주:3]
어쨌거나 이제 이 쉐이더를 저장하는 법을 알려 드리겠습니다.

shaderFX 에서 저장하는 법은 두 가지가 있습니다. 하나는 shaderFX에서 만든 이 구조 (선을 연결해서 이어 만드는 구조 - 노드구조- 라고도 하지요) 를 .SFX 파일로 저장하는 것과, 여기서 제작한 것을 표준 쉐이더 파일 포맷인 .FX 파일로 저장하는 것입니다.

일반적으로 이 작업을 하실 때에는 .SFX 파일을 꼭 저장하셔야 나중에 불러와 수정하거나 할 수 있기 때문에 이것은 꼭 저장을 하셔야 합니다. 이것이 일반적으로 그래픽 디자이너가 알고 있는 '저장' 의 개념이지요.^[각주:4]
.SFX 파일은 shaderFX 전용 파일 포맷으로, 다른데서 쓸 수 없습니다. 오직 shaderFX에서만 쓸 수 있는 파일입니다.

.FX 로 저장한다는 것은, 마치 그래픽 프로그램에서 다른 프로그램으로 파일을 넘기기 위해 익스포트(Export) 하는 개념과 비슷합니다. .FX는 쉐이더 프로그램 언어인 HLSL(High Level Shader Language) 의 표준 파일 포맷으로, 이것으로 저장하게 되면 3D max를 비롯하여 일부의 게임 엔진에서도 이 쉐이더 파일을 직접 사용할 수 있으며, 다른 게임 엔진이라고 하더라도 약간의 수정을 통해 게임에서 실제로 사용할 수 있게 만들 수 있습니다.

.SFX 파일로 저장하기는 어렵지 않습니다.

그냥 우리가 알고 있는 일반적인 저장이기 때문입니다. Ctrl+S 만 눌러줘도 저장할 수 있습니다. .SFX 파일로요.

그런데, 이 쉐이더 파일을 게임엔진이나 맥스에서 사용할 수 있는 전용 쉐이더 프로그램으로 export 하려면, 다른 메뉴를 사용해야 합니다. 이것은 실제로 이 강의 동안에 사용할 일은 없을 것입니다만, 만약 여러분들이 만든 쉐이더를 실제로 게임에 사용해야 할 필요가 생겼다던가 할 때에는 FX 파일로 익스포트를 해 주어야 합니다.

이렇게 저장하기 위해서는 아래 그림과 같이, 3D max에서 사용할 수 있는 FX 파일과
기타 다른 프로그램들에서 사용할 수 있는 FX 파일로 익스포트 할 수 있습니다.

익스포트 옵션은 여러 개가 있습니다. DirectX 를 위한 옵션도 있고, 다른 여러 엔진에 따라 저장할 수 있는 옵션들이 있습니다. 미리 익혀 둘 필요는 없고, 만약 사용할 일이 생기면 그 때 엔진 프로그래머와 상의하면 되겠습니다.

이렇게 FX로 출력하면, "표준 hlsl 언어"로 출력되어, 대부분의 게임엔진에서 어느 정도만 수정하면 사용할 수 있게 됩니다. 그렇지만 연습용이 아닌 이상 실제로 사용하기는 쉽지 않은데요,

그것은 바로 아래와 같이 '코드가 너무 쓸데없이 복잡하게 나오기 때문' 입니다.
단순히 붉은 주전자 하나만 출력하는 쉐이더 코드임에도 불구하고, 최적화를 전혀 해주지 않기 때문에 복잡한 라이트 연산이 모두 들어 있는 채로 출력됩니다. ^[각주:5]

즉 제작하기 간편한 대신 최적화가 전혀 되어 있지 않은 채로 익스포트 되기 때문에, 사실상 실무에서 사용하기 위해서는 이 fx 파일을 바로 사용하기 보다는 이 파일을 참고해서 재 작성하는 쪽이 훨씬 빠르고 편합니다.

자, 이렇게 해서 가장 기본적인 쉐이더를 shaderFX를 이용하여 작성해 보았습니다.
어찌 보면 이번 시간도 기초 설명이었네요. 언제 본격적인 내용이 연재될까...

다음 시간에는 이런 것이 연재됩니다.

- 텍스쳐를 넣어봅니다!!! 뭐, 사실 위의 것을 할 수 있으시다면 벌써 할 수 있으십니다!!! 매우 쉽지요.
- 그런데, 여기서 드디어 이론이 들어갑니다! float3의 비밀이 풀리는 시간입니다. 프로그래머는 알고 있지만 그래픽 디자이너들은 잘 모르던 방식의 색이론에 대해서 배우게 됩니다!!!

오늘 포스팅할 주제는 '툴' 입니다!
이전에 가벼운 해킹에 대한 주제를 골랐었는데..
웬지 이번에도 해킹에 대해 쓰게 되면 계속 그 주제만 만지게 될 것 같아서..
이번엔 툴! 툴에 대해서 이야기를 해보려고 합니다.

게임을 만들때에는 툴도 항상 만들게 됩니다.
특히 요즘에는 툴의 중요성이 더욱 늘어난 것 같습니다.
물론 좋은 엔진을 구입하면 좋은 툴이 포함되어 나오기 때문에 만들지 않는 경우도 있습니다..
하지만!! 저희팀은 좋은 엔진을 구입하지 않았기 때문에.. 툴을 만듭니다!

그런데 툴을 만들때에 툴만 전문으로 만드는 프로그래머가 있는 팀은 거의 없을겁니다.
그렇다보니 툴에 대해 전문적이지 않은 게임프로그래머들이 툴을 만들게 되고 그러다보면 가끔씩은 툴툴대며 만들기도 합니다.. 

또 툴을 만드는것이 익숙하지 않다보니 실수아닌 실수가 많이 생기게 됩니다.그 중에 가장 큰 실수는 아무래도 툴을 위한 코드가 생각보다 커지는것이 아닐까 생각됩니다. 이것을 줄일 수 있다면 이것 자체만으로도 오버엔지니어링을 최소화하는 방법이라고 볼 수 있을것입니다.

툴을 만들때 중요한것은 레이아웃이라고 생각합니다. 레이아웃을 쉽고 빠르게 만들 수 있어야 좋은 툴을 만들 수 있습니다. 그렇지 않고 정말 기능만을 가진 벽돌같은 툴을 만든다면 작업자들이 사용하는데 굉장히 불편해할 것입니다. 속도가 빠른것보다는 편의성이 좋아야 작업자가 작업을 더 빠르게 할 수 있을테니까요.. 

그런데 가끔 팀 내부에서 쓰는 툴이라고 해서 레이아웃에 신경쓰지 않고 만드는 경우를 종종 보게 되었습니다. 그렇게 되면 툴을 사용하는 작업자들이 불편하게 계속 쓰게 되고 그런것들이 쌓여서 전체적인 개발 시간에도 영향을 주게 되기도 합니다. (그래서 좋은 엔진을 사는게 좋은것 같습니다. 좋은 엔진에는 좋은 툴이 있으니까요.)

또는 레이아웃에 신경을 쓰지만 그것을 위해 툴을 위한 코드가 과하게 많아지는 경우도 존재합니다. 이것은 툴의 개발 및 유지를 힘들게 하고 또한 마찬가지로 개발 시간에 영향을 주게 될 것입니다.

그래서 저는 C# WPF로 툴을 만드는것을 추천하려고 합니다.

C#으로 툴을 만드는것에 거부감을 가지시는 분들이 생각보다 많은것 같습니다. 거부감을 가지고 계신 분들은 대부분 C#으로 툴을 만들게 되면 엔진은 보통 C++이기 때문에 C++과 C#의 통신을 위해 CLR을 작업했던 분들입니다. C++에 있는 기능을 C#에서 쓰기 위해 CLR로 C++ 클래스들을 모두 랩핑을 하고.. 또 C++이지만 C++이 아닌 이상한 환경에서의 비정상적인것처럼 보이는 동작을 CLR 작업을 하면서 겪으셨기 때문일것입니다. 그런데 MFC로 작업을 하게 되면 어차피 C++이니 이러한 작업이 필요없어지고 또 MFC도 많은 발전을 해와서 레이아웃을 작업하는데 굉장히 편해졌기 때문에 MFC를 더 선호하시는 분들이 많습니다.

일단 이부분에 대해서 말씀드리자면 저도 역시 CLR로 C++과 C# 통신을 만드는것은 추천하지도 않고 저희팀에서는 CLR 작업은 전혀 하지 않습니다. CLR이 쉽게 익숙해지지 않아서 작업하는데 많은 불편함이 있고 클래스들을 랩핑하는것 또한 위에서 말한 오버엔지니어링에 속한다고 생각하기 때문입니다.

그래서 저희팀에서 사용하는 방법은 Dll Interop을 사용하여 C++과 C#의 통신을 합니다.