지난 일요일에는 오랜만에 애들하고 눈썰매장을 방문했다.
애들은 흥분에 도가니속에 가는 차에서부터 뛰고 난리도 아니였는데
11시쯤 도착했는데도 이미 꽤 많은 사람들이 붐비고 있었다.
지난해와는 달리 프라스틱 썰매가 튜브썰매로 바뀌어 신기했다.
막상 타보니 속도가 기존 썰매에 비해서 느리고 부피가 크다보니
대기줄이 더 늘어져서 한번 타는데 거진 20분을 기달려 10초 타고
내려오게 되서 애들도 지치고 재미가 없어서 짜증을 내기 시작했다
반대편에 가보니 공터에 눈이 안녹은건지 일부러 뿌린건지는
꽤많은 수가 프라스틱 썰매로 부모가 끌고 애들이 거기 타고 놀고
있어서 거기서 애들하고 놀기로 하고 열심히 순록이 되었다.
비싼돈내고 입장해서 한거라고는 머리 뿔만 안달았지 코도 빨개지고
완젼 루돌프 순록이 된느낌…
암틈 애들은 즐거운 하루였고 나는 고달픈 하루였다…
RPG 게임을 만들어 볼려서 글을 쓰고나서 한달이 벌써 지났다..~~휴
생각보다 게임이란게 쉽지 않음을 느꼈고 게임 개발 경험없이 처음부터 만드는 과정이 매우 험난하였다.
이제겨우 마을 3개 테스트 맵을 그려서 캐릭터가 이동하는 수준을 해결하였다.
이왕 시작한거니까 서비스 오픈할때까지 열심히 코딩을 해야 할거 같다.
개발을 하면서 참 많은것을 배우고 경험하게 되었다.
우선 모든 게임 프로그램이 MFC형태를 쓰지 않고 win32 코딩을 한다는 점이였다. 화면 출력 속도를 위한 방법이라 단순히 생각하고 초기 클라이언트에서는 win32로 코딩을 시작했다
하지만 굳이 그렇게 하지 않아도 되는 방법을 알게되었고 mfc로 다시 코딩을 하여 똑같은 속도를 내는 방법을 알게 되었다.
directX 를 집접사용하는 방법을 사용할려고 했으나 굳이 그럴 필요를 못느껴 CDX 라이브러리를 이용한 화면 출력방식을 채택했다.
맵을 그리는 툴은 mappy 라는 프로그램을 이용하여 처리하였다.
초기 이미지 리소스는 일본에서 판매한 rpg maker의 맵타일과 캐릭터 이미지를 약간 도용^^ 하여 마을을 그려봤다.
미니 교역 개임은 개발 초기에 생각과 동일하게 대항해 시대의 교역 시스템을 모방할 계획이다.
단 화면 처리는 2D 로 처리할 계획이다.
모든 게임에서 맵과 캐릭터를 제공하는 방식으로는 혼자서 모든걸 다 처리한다는게 무리라 판단하여 기본적인 툴과 캐릭터 디자인 가이드를 공개하여 누구라도 자신의 캐릭터를 제작해서 등록하는 게임이 되도록 구성하였다.
맵 역시 전세계 지도를 기준으로 본인이 해당 마을을 그려서 올리면 해당 내용을 확인후 게임에 반영할 계획이다.
미니 교역 게임은 모든 네티즌이 같이 맵과 캐릭터를 그려나가는 구성을 할 계획으로 진행하고 있다. 이미 한물간 방법일지도 모르지만
3D캐릭터로 시작하게 되면 리소스를 일율적으로 그려내는데 너무나 큰 공이 들어가야 되고 컴퓨터의 고사양에서 게임이 되는 단점으로 재배하기로 하였다.
이름에서 풍기듯이 미니 교역 게임 역시 단순 프로그램 하나로 실행이 가능하도록 만들고 있다. 미니msn을 써본 분이라면 다 들 좋아할듯…
프로그램 사이즈는 최대 1메가 이하로 가능하며 맵과 캐릭터는 실시간으로 업데이트되도록 구성하였다.
기본적인 구매와 교환이 완료되면 클라이언트와 리소스 제작툴을 오픈할 계획이며 추후에 개발 내용을 오픈하는것도 신중히 고려하고 있다.
1월내로 초기 베타 클라이언트가 오픈될 예정입니다.
리소스 디자인이나 맵 디자인에 관심이 많으신 분들이 적극 참여해줬으면 좋겠습니다.
한동안 대항해시대를 하다가 게임을 접고나니 허전한 마음에 이번엔 게임서버 개발에 도전해 볼려고 몇일째 끙끙대고 있다.
거창하게 rpg를 꿈꾸며 내부 구성을 최대한 확장성을 고려해서 디자인 해봤다. 아마도 다른 게임서버 엔진도 비슷하지 않을까 기대하면서
thread 방식과 poll 방식 두가지 모두 게임에 적합하지 않은거 같아서 이번엔 좀더 복잡한 효과적인 방법을 고민하게 되었다.
Thread 방식은 코딩하기 편한반면 다중 접속자에 대한 부하가 증가되면 접속 클라이언트간 데이타 교환에 어려움이 많다. Poll방식은 Thread방식에 비해서 부하가 적은 반면 속도가 느린 클라이언트로 인한 전체 네트웍의 랙 현상이 두드러지게 된다.
Server, Connection Pool, Thread, Poll 의 혼용과 모든 기능을 object로 통일하여 설계 해 봤다.
완성이 될때까지는 무식하게 텔넷으로 일일이 프로토콜 쳐가며 테스트 중인데 언능 GUI 클라이언트를 만들던지 해야겠다.
클라이언트가 서버에 접속하게 되면 최초 Connection Pool에 대기모드로 들어가고 최초 스래드가 클라이언트를 컨넥션 풀에서 끌어온다음에 게임에 필요한 object 정보들을 내려주고 최종 로그아웃한 스래드로 이동시켜 주는 방식이다.
각 스래드 간에서는 BroadCasting이 될수 있도록 하여 이동이나 대화가 가능하도록 하였다.
대항해시대에 비추에 생각하면 하나의 도시나 해역이 하나의 데몬에 해당하고 광장 또는 주점과 같이 데몬안에 스래드로 구역이 나눠질 수 있다.
오브젝트는 Gate, NPC, User, Item, Quest 로 구분된다.
Gate 는 스래드간 이동 또는 데몬/서버간 이동을 위한 통로로 Object 실행으로 해당 장소로 이동하게 된다.
NPC는 자동 동작 오브젝트로 User가 근접할때 자동 인식을 하게 되어 특정한 동작(공격, 인사)을 하게 된다.
User는 로그인 한 유저의 정보를 관리하게 된다.
Item 은 User 또는 NPC가 소지하게 되는 오브젝트로서 무기,스킬,소비아이템등의 성격을 부여할 수 있게 된다.
Quest는 시나리오 오브젝트로서 장소이동, NPC 선택 또는 전투, Item 취득 과같은 내용을 포함하게 된다.
오브젝트 실행 명령은 create, delete, object, move, exchange 로 구성하고 있다.
create, delete는 스래드에 입장시 초기 오브젝트들의 목록이나 아이템등의 표시를 위해서 이용되면 user object 의 생성도 같은 방식을 이용한다.
object는 해당 오브젝트를 실행하는 명령으로 아이템의 사용 또는 npc와의 대화, gate 로의 이동등이다.
move 는 자신의 object 또는 다른 user또는 npc의 움직임을 수행한다.
exchange는 아이템 또는 퀘스트의 구매, 취득, 교환등의 기능을 수행한다.
이제부터는 클라이언트 쪽을 만들어야 되는데 머드게임같이 간단히 텍스트 베이스로 할지 아니면 오픈소스 클라이언트로 할지 고민중이다. 3d나 2d로 하면 이쁘기는 한데 그래픽에 대한 막막함으로 어떡할지 고민스럽니다. 딱 2d로 돌아가는 비트맵수준의 클라이언트가 있다면 간단히 그려가면서 만들기도 할텐데…
게임개발을 한번도 안해봤기 때문에 이런구성이 정답인지는 잘 모르겠다. 또한 이러 형태의 오픈소스 서버가 이미 존재할 수도 있을것이고. 암튼 공부하는 차원에서 시작한거니까 minimsn처럼 공개하는 그날까지 열심히 코딩해 볼려고 합니다.
약칭 minitrade 게임 완성을 꿈꾸며…