2009/05/21
Reiot
Uncategorized
idogame, lua

동접 1천명 == 3백만원
매출 1조짜리 기업 NHN에서 출시한 아이두 게임과 게임 오븐에 대한 짧은 생각:
- 하루 최고 동접 1000명을 찍으면 한달에 300만원을 지급한다? 한게임 유입자수 풀을 키우려는 전략이겠지만, 너무 짜다. 돈은 현재의 2배 정도로 늘리되, in game ad를 무조건 탑재하도록 하면 윈윈이 되지 않을까.
- 정말 이걸로 돈을 벌려면, 접속 시간을 최대한 늘이는 게임 또는 특정 시간의 접속 비율을 높이는 방향으로 게임을 디자인해야 할 것이다. (자꾸만 동접 늘리는 트릭만 구상하는 레이옷..)
- 게임오븐 IDE은
.NET이 아니라 Native C++으로 만들어졌고, 루아(luabind)로 서버 및 클라이언트를 개발한다. 놀라운 점은 IDE 자체적으로 스크립트 디버깅이 가능한데, 브레이크 포인트라든지 콜스택, watch를 모두 지원한다는 것. (dev.naver.com/opensource에다가 이것만 따로 무료로 공개해주면 좋으련만!!!)
- 네트워킹 역시 루아로 이루어지는데, key-value로 된 메시지를 보내거나 SyncObject라고 해서 자동적으로 테이블을 상대편으로 복제할 수 있다. 얘들도 __newindex 로 루아 테이블 내부 값의 생성, 삭제 및 변동을 추적했을까나~
- 사실 게임 오븐으로 만든 서버를 어떻게 호스팅하는가? 가 가장 궁금하다. 그냥 서버 exe 를 적당한 서버로 배포해서 실행하지는 않을테니, 여기에 설마 클라우드 개념이 들어갔을까? 흐흠..
2009/05/01
Reiot
Uncategorized
autoexp, boost, serialization, tuple
프로토콜 객체로 std::pair 나 boost::tuple 을 채택할 때의 문제는 순서가 틀리더라도 타입만 변환이 된다면 컴파일 타임 에러가 나지 않는다는 점과, first/second 라든지 get() 이 한눈에 안들어온다는 점이다. 또 디버거에서도 내부 값을 찾아 보기가 힘들고 컴파일 시간도 길어지기 때문에, boost::preprocessor 나 boost::tuple 기반의 직렬화 기법이 편하고 관리하기도 좋지만, 그냥 구조체로 만들어서 적당히 memcpy로 보내는 걸 다들 애용하는 것이리라.
boost::tuple<int,short,char> t;
int i = get<0>(t);
int j = get<1>(t);
int k = get<2>(t);
그런데, 이걸 코드 생성기에서 이렇게 만들면 어떨까?
class login : public boost::tuple<wstring,string,int>
{
public :
const wstring & userid() const { return get<0>(); }
void userid( const wstring & v) { get<0>() = v; }
const string & passwd() const { return get<1>(); }
void passwd( const string & v) { get<1>() = v; }
int key() const { return get<2>(); }
void key( int v ) { get<2>() = v; }
};
login msg;
msg.userid(L"reiot");
msg.passwd(".com");
msg.key(1975);
wstring userid = msg.userid();
string passwd = msg.passwd();
int key = msg.key();
이 정도면 읽기도 쉽고 직렬화하기도 편한 객체처럼 보일 것 같은데… (여전히 디버거에서는 보기가 귀찮지만.. autoexp.dat 를 잘 고치면 해결할 수 있지 않을까나~)
2009/05/01
Reiot
Uncategorized
exception, visual studio

요즘은 디버깅할 때 Ctrl+Alt+E를 눌러서 first chance exception이 발생할 때에도 브레이크포인트가 걸리게 하는 편이다. 뭔가 내가 모르는 문제가 저 안에서 벌어지고 있다는 게 못마땅하기 때문인데, 언젠가부터 64비트 OS에서 32비트 서버 어플리케이션에서 소켓 연결을 할 때, First chance exception 0x000006C5 : The tag is invalid 라는 예외가 던져져서 디버깅할 때 짜증이 솟구치는 나날들이 계속되었다. 더군다나 현재 채택한 DB 쿼리 방식이 필요할 때마다 재연결하는 connection pooling 이라서 디버거를 좀 오래 잡고만 있어도 계속 예외가 던져져서 집중이 자꾸 깨지곤 했었다.
조사해보니 마이크로소프트도 포기한 예외였는데, 도무지 이걸 무시할 방법을 찾지 못하다가 (Win32 예외 목록에 없으니까!) 그저께 커스텀 예외도 추가할 수 있다는 것을 우연찮게 겨우 이제서야 알게 되었다.
지금은… 마음이 편하다.
최근 덧글