Windows 2003 Server Resource Kit Tools 설치(C:\Program Files\Windows Resource Kits\Tools)
설치된 Windows 2003 Server Resource Kit Tools 실행파일을 \Windows\System32 에 복사(같은 이름의 파일들이 있으면 원본 유지)
시작 – 실행 INSTSRV prjAttend c:\windows\system32\srvany.exe (서비스에 등록할 이름을 prjAttend라고 할 경우) INSTSRV GSAgent c:\windows\system32\srvany.exe (서비스에 등록할 이름을 GSAgent라고 할 경우)
시작 – 실행 – regedit HKLM\System\Current Control Set\Services\prjAttend 에 “Parameters”라는 키 추가 HKLM\System\Current Control Set\Services\prjAttend\Parameters 에 “Application”이라는 문자열 추가 HKLM\System\Current Control Set\Services\prjAttend\Parameters\Application 에 실행파일 경로(예, C:\Welfare24\RFID\01.출석관리\prjAttend.exe) 값 추가
시작 – 제어판 – 관리도구 – 서비스에 생성된 prfAttend의 등록정보 중 로그온탭에 있는 <서비스와 데스크톱 상호작용 허용> 선택상자 체크
구글 검색, GPG 검색으로 c# 개발에 대해 부정적인 시각이 매우 많네요. 그런데 요즘 구인 글 보면 c# 서버 개발 가능자란 문구가 좀 보이는데요… 아직까지 캐주얼 게임에만 적용된 C#서버만 보였는데, MMORPG 개발사인데 C#서버 개발 가능자를 뽑긴 하던데… 요즘엔 MMORPG에 C#서버로 돌리나요? 업계 동향 보니깐 아예 c#으로 가는 팀도 많아 보이던데…. 혹시 경험 및 사례 있으시면 조금 공유 부탁 드려봅니다.
질문과 답변 형식으로 궁금증을 해소하는 편이 읽는 이가 이해하기에 나을 듯 싶다.
참고로 굳이 C#을 고려한 걸 보면 C#을 도입했을 때의 장점은 분명히 알리라 믿고 이 글에서는 성능 문제에만 초점을 맞춘다.
C#이 느리다던데요?
무엇과 비교하는냐에 달렸다. C/C++과 비교하면 느리다. 그런데 얼마나?
2
C# versus C++ versus Java performance comparison2에서 가져온 이 자료에 따르면 Windows에서 C++은 C#보다 단지 15%가 빠를 뿐이다. 2009년도에 성능 차이가 이 정도였으니 현재는 격차가 더 적을 것이다. 물론 벤치마크의 방식과 샘플 데이터에 따라 결과는 달라진다. 하지만 대부분의 벤치마크에서 비슷한 수치를 보고한다.
그런데 왜 사람들은 C#이 느리다고 하죠?
C# 응용프로그램이 느리다고 느끼는 이유는 몇 가지 있다.
Just-in-time 컴파일
.NET Framework 는 JIT 컴파일을 한다. 여러분이 Visual Studio 에서 C#을 컴파일하면 바이너리 코드가 아닌 VM(가상머신) 언어로 결과가 나올 뿐이다. 나중에 응용프로그램을 실행할 때 .NET Framework 런타임이 VM 언어를 다시 네이티브 바이너리로 컴파일한다.
이런 까닭에 응용프로그램의 초기 구동시 반응이 느릴 수밖에 없다. 대부분의 프로그래머는 코드를 몇 줄 고치고 프로그램을 실행하고 닫는다. 이런 과정을 반복하기 때문에 장시간 운영되는 라이브 환경에서 나오는 성능보다 훨씬 낮은 체감 성능을 느낀다.
.NET Framework 에는 C# 코드를 바로 네이티브 코드로 컴파일하는 도구가 있긴 하다. 하지만 이런 도구를 사용하면 JIT가 제공하는 최적화를 놓치게 된다. 이러한 도구는 구동 시간이 중요한 클라이언트에 써야지 전체 처리량(Throughput)이 중요한 서버에 쓸 게 아니다.
가비지 컬렉션 방식
.NET Framework의 메모리 할당 방식은 간단히 말해 스택 할당이다. 따라서 할당 속도는 C++ 보다 빠르다. 물론 C++ 처럼 메모리 할당 전략을 프로그래머가 마음껏 바꿀 재량권은 상당히 박탈당한다.
빠른 할당에 비해 해제는 상당히 느린 편이다. 메모리가 부족하다 싶을 때 가비지 콜렉터가 한꺼번에 정리하기 때문이다. .NET Framework 의 런타임은 전체 처리량에 맞춰 최적화했다. 따라서 이러한 전략은 웹 서버와 같이 일시적인 느려짐이 크게 문제되지 않는 곳에 매우 적합하다. .NET Framework 초기에 ASP .NET 에 초점을 맞춰 마케팅이 이뤄진 점만 봐도 이러한 설계 철학이 이해가 된다.
따라서 C# 으로 서버를 개발한다면 소위 말하는 렉이 주기적으로 발생한다. 렉이 가끔 발생해도 문제되지 않는 서버에 쓰는 게 좋다. 렉이 발생해도 플레이어가 크게 불평하지 않는 캐주얼 게임이 아니라면 게임서버보다는 캐시서버 등에 적합하다고 보면 된다.
메모리 부족
같은 양의 데이터를 처리한다고 볼 때 C# 응용프로그램이 메모리 소모량이 심하다. 몇 가지 이유가 있지만 무엇보다 가비지 콜렉션을 최후까지 미루는 탓도 크다.
이렇다 보니 메모리가 부족한 환경에서는 가비지 콜렉션을 자주 해야 한다. 그뿐 아니라 스왑도 자주 발생한다. I/O 가 서버 성능에 가장 큰 영향을 미치는 요소 중 하나라는 점을 생각해야 한다.
단, 라이브 환경에서는 값싼 메모리를 마구 투입하면 되므로 큰 문제가 되지 않을 수도 있다.
참고로 .NET Framework 는 COM 을 통해 메모리 할당 전략을 어느 정도 바꿀 수 있다. 다만 해제 전략과 관련된 어떠한 API 도 제공하지 않는다.
C# 으로 구현한 상용 게임이 있어요?
있다. 마비노기 영웅전3! 그 외에도 개발 중인 MMORPG 도 있다. 단, 프로젝트마다 아키텍처와 문제해결 방식이 다르다. 고민 많이 해야 한다.
4
그렇게 좋다면 왜 C# 서버를 도입한 곳이 별로 없죠?
렉 문제와 설계의 어려움
앞서 말한 렉 문제가 게임 플레이에 크게 악영향을 주는 경우가 있다. 각 서버군 별로 나눠서 필요한 곳에만 C#을 적용해도 된다. 하지만 여러 개의 프로그래밍 언어를 개발팀이 익히고 유지보수해야 하는 문제가 있다. 또한 어떻게 아키텍처를 설계해야 C# 도입의 장점을 최대한 살리고 그 단점을 최소로 줄일 수 있는지 파악하기 힘들다.
느리다
어라, 방금 전까지 C#의 성능이 훌륭하다고 말하지 않았나? 아니, 그건 오해다. 15%? 작다면 작지만 어떤 경우에는 크다. 그게 핵심 엔진 코드라면 치명적일 수도 있다. 대체로 이러한 성능 차이는 분산 서비스로 설계하면 문제가 되지 않지만 단일 게임 서버에 하는 일이 몰린다면 심각한 문제가 야기될 가능성이 있다.
설계의 유연성이 부족하다
C++ 과 같은 네이티브 프로그래밍 환경이 주는 최대 장점은 설계의 유연성이다. 메모리 할당 및 해제 전략을 내 취미대로 고친다거나 무잠금 알고리즘을 적용한다던가(C#에서도 가능하지만, 그냥 해보면 안다) 초고성능을 추구하는 이에게 C# 환경은 답답한 면이 많다.
결론
여기까지 경험담을 정리했다. 잘 알고 잘 알아서 설계해서 알차게 살아보자. 어차피 내가 여러분의 프로젝트 책임자도 아니니 여기서부턴 나도 모르겠다.
NoSQL이라고 일컫는 분산 데이터베이스들이 요즘 트렌드다. 뛰어난 확장성과 가용성으로 각광을 받고 있다. 실제로 여러 소셜게임업체들이 NoSQL을 사용하며, 넷플릭스 또한 NoSQL인 Hbase와 Cassandra를 주요 저장소로 사용[1]한다. 그리고 페이스북의 메신저 시스템[2] 및 실시간 분석 시스템[3] 또한 HBase기반으로 만들어졌다. NoSQL을 사용하면 RDBMS에서의 불편한 것들이 모두 해결되고 높은 확장성을 가진 시스템을 구축할 수 있는 것 같지만 현실은 그렇지 못하다. 대부분의 서비스들은 NoSQL을 제대로 사용하지 못하고 있다.
대부분의 서비스는 RDBMS를 주요 저장소로 사용한다.
아직까지는 구글을 제외한 대부분의 다른 서비스들은 NoSQL을 제대로 사용하고 있지 못하다. 거의 대부분의 기업들은 주요 저장소로 RDBMS를 사용하고 있는 것이다. 대표적으로 몇 가지 사례를 들어보면 다음과 같다.
페이스북은 MySQL을 사용한다.
2012년 3월 기준으로, 페이스북의 MAU는 9억명[4]을 넘었다. 이 정도의 추세라면 2012년 중순에는 10억명을 돌파할 것이라고 한다. 이렇게 엄청난 수의 사용자 트래픽을 감당하기 위해서는 아주 특별한 방법을 통해 데이터를 저장해야 될 것 같지만, 실제로는 MySQL을 사용하여 저장 및 관리[5]한다. 심지어 최근에 적용된 기능인 타임라인도 MySQL을 사용하여 구현[6]되었다. 앞서 언급된 메세징 시스템이나 실시간 분석 시스템 등의 정도만 NoSQL을 이용하여 구현되었고, 대부분은 여전히 RDBMS를 쓰고 있는 것이다.
MySQL을 여러개의 논리적 DB와 여러 대의 물리적 서버에 나누어 운영된다. (Sharding)
데이터는 Key-Value 형태로 최대한 단순하게 저장된다.
각 데이터의 조인 연산은 Web Server에서 담당한다.
트위터도 MySQL을 사용한다.
트위터의 경우, 많이 들어오는 경우 초당 수 천건의 트윗이 들어온다.[7] 올해 초의 슈퍼볼 결승전 때는 초당 트윗이 만건을 넘기기도 하였다.[8] 이렇게 엄청난 양의 트래픽을 처리하는 트위터 또한 주요 저장소로 MySQL을 사용한다. 사실 처음에는 Cassandra로 바꾸려고 했었지만[9] 결국엔 MySQL 시스템을 유지하기로 결정하였다.[10] 트위터는 Gizzard를 통해 데이터 레이어를 추상화 하여 MySQL에 데이터를 저장한다.[11] 이렇게 엄청난 수의 트윗에 대한 아이디를 발급하기 위해 Snowflake를 사용[12]한다.
MySQL을 여러개의 논리적 DB와 여러 대의 물리적 서버에 나누어 운영된다. (Sharding)
Gizzard를 이용하여 데이터의 Sharding과 Replication을 추상화한다.
Tumblr도 아직은 MySQL가 주요 저장소다.
Tumblr는 엄격하게 말하면 블로깅 서비스이지만, 체류시간이 페이스북 다음으로 두번째로 긴 소셜 서비스로 소개된다. (물론 페이스북이 압도적으로 크다) Tumblr에서도 실제 데이터는 MySQL을 사용하여 저장하며, 제한적으로 NoSQL을 사용[13]한다.
MySQL에 데이터를 잘 쪼개 저장한다. (Sharding)
HBase같은 것들은 URL Shorter나 데이터 분석 등 제한적으로 사용되었다.
시간 순서대로 쪼개진 데이터 덕분에 특정 MySQL Shard에 로드가 집중되는건 Master-Slave구성으로 해결하였다.
Pinterest도 MySQL을 주요 저장소로 사용한다.
Pinterest는 특정 주제로 사진을 게시 및 공유 할 수 있는 서비스로, 단기간에 사용자 3000만명을 넘기며, 그것도 80%이상이 여성 사용자를 확보하면서 큰 주목을 받고 있다. Pinterest는 데이터 분석을 위해 Hadoop을 이용[14] 하긴 하지만, 실제 데이터는 MySQL에 저장[15]한다.
MySQL을 이용해 데이터를 저장한다.
다양한 방법으로 데이터를 캐싱한다.
인스타그램도 PostgreSQL을 사용한다.
인스타그램은 1500만명 이상이 사용하는 사진 공유 서비스이다. 그리고 페이스북에 인수되기도 하였다. 인스타그램에서는 RDBMS중 하나인 PostgreSQL을 사용[16]한다. 그리고
3명의 엔지니어가 초기 개발에 참여했다.
12개의 EC2 인스턴스를 이용하여 PostgreSQL을 돌린다.
PostgreSQL 인스턴스들은 오픈소스를 이용해 Master-Replica 형태로 운영된다.
시스템은 그 외 여러가지 오픈 소스를 이용하여 구성되어 있다.
에버노트도 MySQL을 사용한다.
에버노트는 클라우드 노트 서비스이다. 2011년 한해동안 600만명에서 2000만명으로 유저가 증가할 정도로 엄청난 속도로 성장하고 있는 서비스이며[17] 수 많은 노트들을 다양한 채널을 통해 관리할 수 있는 환경을 제공한다. 에버노트는 MySQL을 저장소로 사용하며, NoSQL이 아니라 SQL기반의 RDBMS를 사용하는 이유에 대해서도 블로그[18]에 올라왔었다.
MySQL을 사용한다. [Sharding]
RDBMS를 사용하는 이유는 ACID 때문이다.
이처럼 대규모 트렌젝션을 처리해야하는 서비스도 주요 저장소로 아직은 RDBMS를 사용한다. 페이스북의 메신저 시스템과 실시간 분석 시스템, 텀블러의 주소 길이 단축 시스템 정도만 HBase와 같은 NoSQL을 실험적으로 도입하는 단계이다. NoSQL을 전면적으로 도입하려다 그만 둔 트위터도 있고 심지어 처음부터 잘되어있는걸 가져다 쓰라는 Instagram도 있다. 에버노트는 NoSQL을 쓰지 않는 이유를 명확히 밝혔다. Scalability가 가장 중요한 이슈일 것 같은 많은 서비스들이 아직도 NoSQL을 사용하지 않는 이유는 자명하다.
NoSQL 기술은 아직은 걸음마 단계이다.
오픈소스로 공개되어 있는 NoSQL은 굉장히 많다.[19] 많은 기업들이 NoSQL을 도입하기 위해 여러가지 시도들을 하고 있다. 하지만 아직까지 주요 데이터 저장소로 RDBMS를 사용하는 경우가 거의 대부분인 것이 현실이다. 왜 그럴까? 많은 이유가 있을 수 있겠지만, 그 중 중요한 하나는 배포 중인 NoSQL들이 범용적으로 사용하기에는 아직 부족한점이 너무도 많다는 것이다.
서비스를 구현하는데 반드시 필요한 것들이 있다. 바로 Index와 Transaction이다. 이것들 없이도 어떻게든 잘 구현할 수 있는 특수목적의 시스템을 제외하면 이런 기능들은 제대로된 서비스를 만들기 위해서 반드시 필요하다. 이런 기능들이 제공되지 않으면 범용적인 사용이 불가능하며, 충분히 추상화되지 못한 상태에서 Concrete한 문제를 해결하기 위해 쓸데없는 시간을 보낼 것이다. 현재 배포되어 있는 NoSQL들은 이와 같은 기능이 아예 없거나 제한적이다. Transaction의 경우 NoSQL상에서 분산 트렌젝션을 구현하기 위한 Transaction을 구현하기 위한 시도 들이 있었다. 그것들이 바로 Elastras[20]와 CloudTPS[21]이다. 하지만 Eventually Constsitancy의 한계를 보여주며 완벽하게 망했다.
사실 HBase에는 TransactionalTable[22] 같은 트렌젝션을 제공하기 위한 API가 존재하기는 한다. 하지만 글쎄, 2011년 초에 사용하려고 써봤지만, 그닥 제대로 동작하는 것 같진 않았다.
단, 구글을 제외하고
Transaction과 관련하여 구글이 2010년에 논문을 내놓았다. Percolator[23]인데 BigTable구조의 스토어에서 분산트렌젝션을 구현하는 방법에 대해 기술해 놓았다. 아주 깔끔 명료하고 완벽하게 동작한다. 이미 구글에서 사용하는 시스템이다. 어떤 대학의 연구실에선 자기들이 독자적으로 개발한 분산트렌젝션 방법이 살짝 부족하긴 해도 알고봤더니 구글의 Percolator와 비슷한 방법이라고 자랑질[24]을 할 정도이니 더 이상 언급하지 않아도 될 것 같다. 그리고 이미 구글의 클라우드 서비스인 AppEngine에서는 BigTable을 기본 데이터 저장소로 사용할 수 있도록 해주며, Indexing과 Transaction을 완벽하게 제공한다. 너무 비싸긴 하지만.
결론
거의 대부분의 서비스에서는 NoSQL을 사용하지 않는다. 그리고 그 이유는 트렌젝션과 같은 일반적인 서비스 구현에 필요한 기능들이 전혀 준비되어 있지 않기 때문이다. 하지만 구글의 경우 모든 것을 해결한 시스템을 BigTable상에 구현했으며 이미 몇 년동안 서비스하고 있다. 내리고 싶은 결론은 두 가지다.
구글을 찬양하자.
바퀴를 만들지 말자.
서비스를 구현하는데 주된 데이터 저장소로 NoSQL 사용을 고려하고 있다면, 구글을 제외한 다른 업체에서 일반적인 서비스를 구현하는데 있어서 NoSQL을 주된 저장소로 사용하고 있지 않다는 사실을 알고 결정하자. 사실 현재 일하고 있는 VCNC에서 Between이라는 서비스를 돌리고 있는데, 주저장소로 HBase를 쓰고 있기는 하다.
먼저 지난 1기(멋대로 1기 타령... 한 쿨도 아닌 주제에ㅠㅠ)에 배운 것을 정리해볼까요?
1화 : 떡밥 투척 2화 : C/S와 P2P의 간략한 구조 2-1화 : 홀펀칭 좀 적다가 생략. 본진에도 업로드 안함. 3화 : ADO를 이용한 데이터베이스 연결 및 로긴 4화 : 로비 - 예제없음. 크윽 5화 : boost.serialize를 이용한 직렬화. 사실 5화를 보면 3, 4화를 바탕으로 셀프 제작 가능해야함.
돌아보니 주로 서버 엔진측에 대한 필수+기초만을 다룬 것 같습니다. 사실 연재를 못한 기간동안에도 대략 이런 일들과 플랫폼 서버쪽을 만들고 놀고 있었습니다. 실전에서도 언제나 이런 밑밥투척부터 잘 되어야 튼튼한 프로젝트가 되기 때문입니다.
그래서 연재방향도 자칫 미들웨어(middle ware) 제작 쪽으로 흘러갈뻔 하다가... 네, 마음대로 지난 1기를 종결하고 새롭게 2기를 시작해봅니다. 2기 때부터는 본격 컨텐츠 제작 이야기를 해보죠, 물론 제목대로 네트워크는 필수입니다. 이 모든게 소드 아트 온라인 때문입니다. 저두 서버측 밑밥 엔진 이야기만 하다보니 질린게 사실이고요.
그럼 2기도 떡밥 투척부터 시작하겠습니다.
1. 보통 프로그램팀의 인력구성은? 먼저 말씀드리고 싶은게 흔히 말하는 "프로그램팀"의 인력구성입니다. 라이브를 하지 않고 신규 개발만 하는 팀이라면 사실 10여명이면 왠만한 서버와 클라이언트등 게임에 필요한 애플리케이션들을 뽑아냅니다. 또한 실력은 보통 10명 중 3~4명은 고수, 5명은 중수, 1~2명은 뉴비 정도로 이뤄집니다. 제가 감히 실력을 구분짓는건 무언가 아니겠지만 보통 이렇게 이뤄지는게 사실입니다.
그리고 이 10명은 어떻게 일을 할까요? 10명이 개떼처럼 서버를 뚝딱 만들고 클라이언트를 뚝따 만들지는 않을 것입니다. 보통 서버파트와 클라이언트 파트로 나눠지며 혹은 서버 파트, 컨텐츠 파트, 클라이언트 파트로 구성되기도 합니다. (참고 : http://rhea.pe.kr/283)
흔히 말하는, 게임을 공부하는 분들이 가고 싶어하는 분야가 클라이언트 파트라고 생각합니다. 시중에 나와있는 책들의 대부분이 렌더러를 포함하여 클라이언트 기술들이죠. 그러나 실제 렌더러만 전담하는 개발자는 이 10명중 1, 2명이거나 아예 엔진팀이 별도로 있는 경우가 많습니다. 따라서 클라이언트 개발자는 절대 렌더러 개발자가 아닙니다. 서버 역시 마찬가지입니다. 이 10명 중, 제대로 소켓을 다룰수 있는 개발자는 2, 3명만 되어도 어떻게든 팀은 돌아갑니다. 그렇다면 렌더러도 아니고 서버도 아닌 5명은 무엇을 할까요? 가장 많은 수를 차지하는 것은 컨텐츠 개발자입니다. 라이브팀에는 90%가 컨텐츠 개발자로 구성된다고 봐도 무방할 정도입니다.
물론 가장 좋은 상황은 이 10명이 전부 렌더러, Win32 애플리케이션, 서버, 미들웨어, DB, 그리고 게임 컨텐츠를 다 할수 있는데, 자기가 하고 싶은 것에 따라 업무를 맡는 것일 겁니다. 그리고 프로그램팀의 리더는 이것들을 전부 경험해본 사람이 단연코 좋습니다. 나는 밑에 애들 잘시키면 되지, 기술적으론 잘몰라도돼~ 라는 개소리를 하시는 "실무 리더"분이 간혹 있는데, 대부분 오래 못가 운지합니다.
내가 바라는 개발팀
현실
경고!! 투자가, 사장님을 비롯한 높으신 분들이 혹시 이 글을 봤다면 절대 이 글을 따라 아는 체하며 인력구성을 하지말고 팀장이나 젤 똑똑한 애 요청대로 팀을 짭니다. 안그러다간, 아주 좆돼는 경우가 생깁니다.
2. 게임은 컨텐츠다 네, 따라서 게임 프로젝트는 컨텐츠 프로젝트입니다. 화려한 렌더링과 가공할 성능의 서버 시스템이 있어도 게임이 재미없으면 망합니다. 이 컨텐츠 프로그래밍을 하는데에는 렌더링도 서버도 처음에는 필요없습니다.
게임 개발을 꿈꾸는 분이라면 평소의 모든 현상을 게임 컨텐츠로 옮길수 있는 코딩 능력이 있으면 참 좋습니다. 애시당초 객체지향 프로그래밍이란 현실을 컴퓨터로 옮기는 작업 아니겠습니까?
혼자서, 혹은 아마츄어 팀으로 게임 프로젝트를 시작하며 망하는건, 무리하게 상용게임을 흉내낼려는 것에도 원인이 있습니다. 엄청난 자본과 시간과 인력이 투입된 게임에 비교하면 자신의 것은 초라해지고 의욕마저 상실합니다.
이 게시물은 오직 게임컨텐츠에 대한 설명입니다. 먼저 글상자 안에 있는 내용은 공격력에 대한 내용인데 필수적으로 공격의 주체와 공격을 받는 객체들의 판정에 대한 이야기입니다. 구조체, 아니 C언어로 사칙연산만 할수 있는 초보자라도 위의 공식을 프로그래밍 언어로 옮길 수가 있을 것입니다.
스타크래프트2는 물론 초당 몇십 프레임이 돌아가고 이동이 자유로운 게임입니다만, 공격이라는 한 순간을 구현하면 위와 같은 루틴으로만 끝내버릴수 있습니다. 이런게 바로 컨텐츠 안에서의 로직 부분에 해당합니다. 좀더 추가해 객체별 상성관계 역시 if 문과 숫자 증감으로 쉽게 구현 가능합니다. 아마 이 글을 읽고 계신 분들 중에 이 정도도 코딩 못하시는 분은 없을 것입니다.
그런데 설명을 읽어보니 컨트롤에 대한 이야기가 나오는군요. 컨트롤이라는 것은 앞서 적은대로 실시간으로 객체들이 계속 돌아가는 게임이기 때문에 생기는 현상입니다. 그래도 별것 없습니다. 객체들이 계속 돌아간다는건, 게임 프로그램이 윈도우 메시지를 처리하지 않는 Idle 타임중에 계속 로직과 화면을 뿌려주는 것에 불과하기 때문이죠. 아, 물론 키보드, 마우스, 네트워크 입력도 같이 받습니다.
간단하죠? 여기서 더 신경써야할 것은 각 객체들의 생성, 소멸, 함수간 전달 관리이며 입출력을 위한 Win32 애플리케이션, 3D, 네트워크 공부인 것입니다.
여기의 게임을 이루는 객체들의 관리가 결국 게임프로그래밍입니다. 비록 허술하다고 하더라도 이것이 게임 코딩의 본질입니다. 물론 사용자 경험을 만들어주는 렌더러의 중요성은 이 자리에서 언급하기 민망할 정도이지만 렌더러 만으로는 절대 게임이 되지 않습니다. 렌더러도 충돌이 들어가야지 비로소 게임틱해집니다 충돌이 들어갔다는 말도 단순히 렌더 타겟이 아니라 게임 객체가 되었다는 말입니다.
뜬금없는 이상적인 렌더러의 사례
3, 그래서 MUD를 만들어봅시다. 2기에서는 이제는 기억에서 잊어진 게임 쟝르인 MUD(multi user dungeon)를 만들어 볼 것입니다. (절대 그래픽 코딩하기 귀찮아서가 아님.)
마음만은 사실같은 그래픽으로 해드리고 싶네요...... .
사실 MUD에서 사용되는 기술은 현재의 MMORPG와 큰 차이가 없습니다. 단지 실시간 이동과 공격이라는 것을 지원하기 위해 데드리커닝(dead reckoning)이 추가되었을 뿐이며 3D가 추가되며 부분적으로 여기에 3D 연산이 들어갑니다. ...사실 서버에 3D 안써도 클라만 잘하면 깜쪽같이 자~알 됩니다. 사족을 달면 실제 서버 3D나 넌타게팅 같은 것보다 수십, 수백대의 서버 동기화나 빠른 DB처리가 같은 장비 영역와 섞인 부분이 훨씬 더 어렵습니다.
부활 신호탄은 여기까지 적고, 2화 부터 "소드 아트 온라인 MUD"을 구현해보도록 하겠습니다. 역시 개발환경은 C++과 Win32/64입니다. 그리고 다시 연재를 시작하게 되어 무척 기쁩니다. 이제 다른 멤버들에게 도망다니지 않을수 있게 되었어!!! ㅠㅠ
