안녕하세요. 배틀드래곤을 개발한 사람입니다.
개발착수에서 서비스 오픈까지 약 1년 반정도가 소요되었는데 그 과정
을 그냥 나열식으로 시간날때마다 틈틈히 올리도록 할께요.
나름대로 개발중 얻은 know-how나 프로그램 루틴도 삽입하도록 하겠습
니다.
1. 배틀드래곤을 만들게된 동기
- 개인적으로 네트워크 액션을 선호하는데 대분분이 RPG형태로
액션을 찾아보기 힘듬(SubSpace, NetWar, Tanarus ?, 건체이스,
포트리스등)
- 건체이스를 플레이 하면서 업그레이드를 기다리다 지쳤음(^.^)
왜 업그레이들 안하시는지, 탱크, 무기, 맵좀 계속 추가하면 재미나게
계속 할텐데.
- 다들 RPG를 개발하고 있기 때문에 시장공략에 유리함(경쟁상대가 적음?)
- 개인적으로 만들기가 RPG보다 용이함.
- 일반 CD-ROM 게임보다 마케팅이 유리하며 시장성이 크다고 판단.
(특별한 광고비, 판촉비가 없음)
- 기타 등등
2. 배틀드래곤 게임 기획시 고려된 사항
- 캐릭터의 이동에 속도, 가속도, 관성을 부여하여 반응이 바로바로
나타나지 않도록 게임을 디자인(동기화를 하기 편함).
- 한방에 죽는형태의 게임은 배제한다. (어디서는 맞았는데 어디서는
안맞는 현상이 발생해도 큰 무리가 없음?, 에너지 개념)
- 최대한 지역을 구분하여 같은 지역의 사용자가 아니라면 정보를 공유하지
않게하여 트래픽을 줄임.
- 중간 프레임을 자동으로 처리하도록 하여 빈번한 데이타 전송을 피한다.
- 인터페이스는 키보드로 설정(1개의 캐릭터만 조정하는 액션게임이므로
마우스로 하면 지루해질 가능성이 있음. 단점으로 많은 방향이
필요하게
됨 36방향)
- 가능한 무기의 종류를 광범위하게 피해를 주는 종류(지뢰, 폭탄등)를
설정하여 정확한 값을 피한다.
3. 게임제작
- 캐릭터 설정. 로봇과 공룡중 고민. 우리나라 게임연령층이 로봇보다는
공룡을 더 좋아함. 로봇은 좀 식상한 느낌이 있음. 우리나라에서
메크
워리어, 헤비기어 같은 게임이 잘 안먹혔음. 음... 공룡이 좋긴한데
공룡도 좀 유치한데... 아... 공룡이라 하지 말고 드래곤이라
해야지.
- 맵 에디터 제작 : 32x32로 제작. 단 모든 이미지는 64x64로 만들어
50%축소 해서 사용. 좀 더 세밀한 이미지를 얻음. 맵 palette에
120
color할당. 8개는 palette animation에 사용됨. 총 128 color.
맵 소스는 에니메이터에서 2D로 제작함.
- 캐릭터 제작 : 키보드를 사용하기 때문에 모든 동작을 36방향으로
제작.(에니메이션 데이타는 19방향으로 수직으로 카피해서 사용)
티라노, 랩터는 3D studio로 제작.(제작 도중 개발자 그만둠)
브라키오, 테라노, 트리세라는 일렉트릭 이미지(Mac)으로 제작.
- 패널(Pannel), 아이콘, 초기화면 제작.
- alpha blending, overlap 효과 추가.
(256에서 overlap시키는게 불가능한줄 알고 있었는데 netwar에서
그림자, 폭발을 실시간 overlap으로 구현하더라고요. 그래서 2주간
고민한 끝에 겨우 구현. 생각보다 효과도 괜찮고, 쉽더군요. 시간
되면 이 부분도 올릴께요. -> 다들 알고 있나?)
- 무기, 아이템 추가
- 발란스 조절.
4. 프로토콜의 선택
stand alone형 게임은 많이 개발해 보았어도 네트워크 부분은 처음이라
시행착오를 많이 겪었습니다.
- TCP/IP : 보내고 받는다. 100명에게 보내려면 각 100명에게 모두 보내고
받는다.
- UDP : 100명이나 1000명에게 보내기 위해 1번만 보낸다. 프로토콜 간단,
헤더 짧음. (왜 이걸로 게임을 안만들지?)
* stand-alone형 게임은 많이 만들어 보았지만, 네트워크 쪽으로는
문외한
상태에서 개발을 시작했음.
우리나라 개발자들이 많이 쓰는 방식 - 만들면서 공부한다.
- UDP로 개발을 완료한 후, 인터넷상으로 테스트.
간혹 특정 ISP에서는 라우터에서 UDP패킷을 통과시키지 않는다는
사실을
발견함. (정확한건지 모르겠는데 INET으로 서버를 천리안으로
인터넷을
사용하여 테스트 했음). 빈번한 데이타 발생시 패킷을 자주 읽어버리는
문제점 발생. 앞뒤 패킷이 순서없이 막 도착함.
- 게제동의 네트워크 게시판 정독.네트워크 게임은 대부분 TCP/IP를 사용
한다는 사실을 발견.
- TCP/IP에 대해 공부(볼륨1, 볼륨2 정독)
- TCP/IP로 네트워크 부분 전면 수정
프로토콜을 UDP로 사용하는것은 문제가 있지 않나 생각되네요. 분명히
장
점은 많은데 불안 해서. 차라리 UDP는 TCP/IP와 병행해서
채팅데이타 같이
읽어버려도 중요하지 않는 정보에 사용하는것이 좋을듯 하네요. 그러려면
socket을 2개 열어야 겠지요. 배틀넷은 UDP로 사용자 상태를 검사하는것
같던
데. 그런쪽으로 써도 좋을듯 하고.
다음에는 서버 프로그램을 만들어 나간 과정을 써 보도록 하겠습니다.
생각보다 글쓰기가 쉽지 않네요. 나름대로 열심히 쓴건데. 장난비슷하게 된거
같기도 하고. (이제 좀 ROM족에서 벗어나려나?)
안녕하세요. 배틀드래곤을 개발한 사람입니다.
요즘 버젼업때문에 정신이 없어서 글이 늦어졌습니다.
역시 문장력이 부족하니 나열식으로 쓰겠습니다.
[1차버젼]
- mode : non-blocking
- protocol type :
command type - 1 byte
length -
2 byte
message -
length
command type의 종류는 대략
CMD_NONE 0
CMD_ACCESS_LOGIN 1
CMD_ACCEPT_LOGIN 2
CMD_USER_ADD
3
CMD_USER_REMOVE 4
CMD_DINO_SET_DATA 5
CMD_DINO_DIE 6
CMD_TEXT_DATA 7
CMD_LOST_CONNECTION 127
와 같은 형태이며 총 43개를 사용했습니다.
(다 공개하면 해킹의 우려가 ...)
command중 가장중요한 CMD_DINO_SET_DATA(위치전송)은 1초에
2번 발생.
- server env : dual-pentium 300Mhz, 512RAM
NT4.0(service
pack3)
- send/receive : 발생되는 event를 바로바로 처리
대략 위와같이 만들어서 내부 인트라넷에서 4명이서 테스트 실시함.
결과 : 공룡들이 한참 멈추어 있다가 한순간에 주루룩 이동, 멈추었다가
주루룩 이동을 반복하여 게임이 진행이
안됨.
원인 : 소켓자체에서 전송해야 하는 데이타가 아주 적은경우 버퍼링을
하기때문이라고 생각됨.
방안 : 일정이상은 버퍼링을 한 후 데이타 전송.
[2차버젼]
- send/receive : 발생되는 event를 자체 버퍼에 버퍼링. 모든 command는
버퍼에서 처리
결과 : jumping과 latency가 발생됨.
원인 : 위치 데이타를 1초에 2번 발생시켜며 자체 버퍼링을 한후 처리하기
때문에 당연한 결과로 생각됨.
방안 : 네트워크상에서는 latency를 피할 수 없으므로 동기화를 시키기
위해서 prediction(예측) system을 도입
--------------------------------------------------------------------------
[3차버젼]
- global time 설정 : 서버시간을 할당받은후 3번의 ping을 통해
모든 client가 공유할 수 있는 time을 설정.
위치 데이타에 global time을 포함시킨다. 데이타를 전송받은 각 client는
old global time과 new global time을 비교하여 몇프레임후에 전달받은
데이타인지를 파악하여 그 프레임만큼 예측하여 위치 조정.
그 위치값과 현재의 위치값을 계산된 프레임으로 나누어 프레임당 이동해야
할 방향, pixel수를 정한후 적당한 가속도를 부여한다.(에구 복잡)
이렇게 해도 latency는 발생하나 어느정도는 보완이 가능함.
- send/receive : 발생되는 event를 자체 버퍼에 버퍼링. 모든 command는
버퍼에서 처리
결과 : 어느정도는 자연스러움. 멈춤현상은 여전히 발생.
원인 : 정확히 1초에 2번씩 데이타를 전송해도 네트워크 특성상 매번 0.5에 한번씩
데이타가 오지 않고, 3초, 0.1초, 0.4초씩 임의로 receive됨.
방안 : 실제 데이타가 오기 전까지 현재의 진행방향으로 가상으로 이동시킨후(멈춤
없이), 실제 데이타가 왔을때 오차를 계산하여 보정하면서 목표점으로
이동시킴.
-> 요 부분에서 시간을 많이 잡아 먹었음.
[4차 버젼]
- DB 프로그램 제작 : 단순한 ISAM file로 제작. (자체 DB ?)
DB까지 만든후 NetsGo 서비스 오픈
결과 : 난리가 났음. 3일동안 2000명이 다운로드 받아감. 동시접속자 100명이상.
서버는 사용자가 10명만 넘기면 계속적으로 튕겨냄. 1명당
1분을 못버팀.
원인 : 테스트없이 바로 오픈한 결과로 생각됨.
전용선 용량이 턱없음. 56K 사용. 최대치가 80%로 설정되어있으나
그래프가
고저
없이 120%에서 수평선을 3일동안
계속 유지됨. error traffic이 계속
발생됨.
방안 : 튕기는 원인 파악. 전용선 용량 512K로 증설.
다음에는 4차 버젼에 이어 계속 서버 프로그램을 만들어 나간 과정과 약간의 소스를
공개하도록 하고, 이어서 다른 통신사에 서비스를 오픈하기 위한 문제점과 과정을
연재해 나가겠습니다.
두서없이 나열만 해서 의미가 전달될까 모르겠네요.
안녕하세요.
아래 몇분이 질문을 하셨는데, 일단 간단한 답변을 하겠습니다.
1. 현재 사용하는 전용선 :
네츠고 - 512K
채널아이 - 256K
유니텔 - 512K
인터넷 - 512K
요렇게 4개를 사용합니다.
2. 1차~4차버젼까지의 개발기간
약 2개월정도 소요되었습니다만, 다른 일들을 병행하면서 하였기
때문에 풀로 작업을 했다면 약 1개월 정도가 걸렸을듯 합니다.
3. 현재 평균 접속 인원
들어와 보시면 압니다.
그럼 연재를 계속하도록 하겠습니다.
[5차 버젼]
소스 검토. 몇가지 버그 수정. 최적화 할 부분을 아주 많이 발견 해냄.
전용선 512k로 증설,
심하게 튕기는 문제에 실망한 사용자들이 많이 빠져나감
(평균 20~30명선으로 격감)
네츠고 게시판의 1~100번까지가 비난의 글로 가득참.
게임도중에 튕긴다는 문의 메일이 하루에 20통 이상씩 도착.
* 온라인 게임은 사용자들이 관심이 많기 때문에 초기에 서비스를 오픈하면
관심있는 사용자들은 많이들 와보지만 이때 사용자들을 실망시키면(튕겨 나간
다던지..) 다시 돌아 오게 만드는데 많은 시간이 소요됩니다.
자체 테스트를 많이 실시해서 안정화를 시킨후 오픈하는것이 옳지 않나
생각됩니다.
사용자가 튕기는 모든 원인이 전용선 용량이 문제가 있다고 생각했는데
선을 늘려도 해결이 안되자 당황하며 서두르기 시작함. (원래 성격이 낙천적
이라 왠만한 일에 서두르지 않음)
선 트래픽 (20~30%, error traffic 0%)
부랴부랴 6차버젼 제작
[6차 버젼]
- 메인 루프
while(1)
{
ActiveCommand(short int Num)
{
읽을 데이타가 있는지 소켓 검사
데이타의 길이를 receive
실제 데이타 receive
command 처리 (데이타=command)
}
만약 보낼 데이타가 있다면
SendWriteBuffer(short int Num)
{
// 보낼 데이타의 길이를 더한후 실제로
write
char Buff[WRITE_BUFF_MAX+3];
Buff[0] = LOBYTE((WORD)Len);
Buff[1] = HIBYTE((WORD)Len);
memcpy(&Buff[2], CLIENT[Num].WriteBuffer,
CLIENT[Num].WriteBuffSize);
Len += 2;
CLIENT[Num].Tcp.Write(Buff, Len);
}
ConnectionCheck(void)
{
현재 접속되어 있는 사용자의 traffic을
검사
send, write 상태가 5초이상 0이면 disconnect로
간주
}
}
단순하죠?
- Receive
데이타는 receive될때 TCP/IP 메세지를 받게 되고
case WMU_DONE_READING :
if(DoneReading((SOCKET)lParam) == FALSE)
{
AddTextFile_ERROR("Error
Done Reading");
LostConnectionFromSocket((SOCKET)lParam);
}
break;
을 통해 각각의 버퍼에 누적시켜두게 됩니다.
- Send
void CServer::PutByte(short int Num, char Data)
{
if(CLIENT[Num].WriteBuffSize
>= WRITE_BUFF_MAX-2)
{
LostConnectionFromNum(Num);
return;
}
CLIENT[Num].WriteBuffer[CLIENT[Num].WriteBuffSize]
= Data;
CLIENT[Num].WriteBuffSize ++;
};
void CServer::PutWord(short int Num, short int Data)
void CServer::PutLong(short int Num, long Data)
void CServer::PutBuffer(short int Num, char *Buff, int
Size)
의 형태로 실제로 데이타를 보내지 않고 버퍼에 누적시킨후
루프를 한번 돌때마다 모아서 실제로 send를 처리함
// 실제 write 부분
BOOL CTcp::Write(LPVOID pData, int nLen)
{
int nBytesSent;
if(pData == NULL || nLen <=
0)
return(TRUE);
nBytesSent = send(m_s, (LPCSTR)pData,
nLen, 0);
if(nBytesSent == SOCKET_ERROR || nBytesSent
!= nLen)
{
m_nLastError = WSAGetLastError();
PostMessage(g_hWnd, WMU_TCP_MESSAGE,
WMU_ERROR_WRITING, (LPARAM)m_s);
return(FALSE);
}
PostMessage(g_hWnd, WMU_TCP_MESSAGE, WMU_DONE_WRITING, (LPARAM)m_s);
return(TRUE);
};
위와 같은 방식으로 했을경우 사람이 많을 경우 (30~40명, 적나 ?)에는
더 심하고, 사람이 적을 경우(5~10명)에도 아래의 메세지를 받으면서
WMU_ERROR_WRITING : 주로 발생
WMU_ERROR_READING : 10번에 1번꼴
lost connection이 발생합니다. 간격은 대중없이 3~10분사이
원인 : 모르겠음
추측 :
메세지 방식이기 때문에 바로 바로 처리가 안되서 발생하는 문제가 아닐까?
방안 :
blocking방식으로 수정
free battlenet source, ultima online source(가짜?) 심층 분석
에구 힘드네요.
다음에는 7차 버젼(blocking방식)을 연재해 나가겠습니다.
-> 만들때는 힘들어도 서비스 오픈 해놓으면 짜증날때도 많지만 대체로 재미와
보람을 느낄수 있으니 열심히들 만드세요.
그럼.