본문 바로가기

관심분야/게임

(15)
게임 컨텐츠 구현을 위한 V8 Javascript엔진.. 저는 현재, 타이틀과 마찬가지로, Google의 V8 Javascript엔진을 게임개발에 사용하고 있습니다. 이러한 방식으로, 서비스를 만들고, 클라이언트와 통신을 합니다. var wsaio = new WSAIO();var l = wsaio.listen(8080, 10); l.onreceive = function (fd, bson) { print("RECV: " + process.id + " " + fd);}; l.onconnection = function (fd, addr) { print("CONNECTION: " + process.id + " " + JSON.stringify(addr)); l.forEach(function (fd, o) { print("FOREACH: " + fd + " => " +..
데이터 변경에 대한 로깅 대부분의 서비스는 데이터베이스를 통해서, 데이터를 관리하고 그에 대한 변경 내용을 일일이 관리합니다. 이러한 데이터는 이후 서비스의 유지 보수와 사용자 응대에 사용되기 마련입니다.그러다 보니, 개발자 입장에서 이러한 데이터를 저장하고, 처리하는 업무가 중요할수 밖에 없습니다.나름, 이러한 처리를 저 또한 많이 하고, 단순화 시키기 위해서 많은 노력을 합니다. 그래서 사용하는 방법이 Observer 형태의 개발 패턴을 사용하였습니다. 이러한 패턴을 사용하기 위해 다음과 같은 접근 방식을 택하였습니다. - 쿼리를 통해, 데이터는 Map형태로 정규화 시킨다.- Map형태로 저장된 데이터의 변경을 로깅 관리한다.- 변경된 내용을 기록하는 함수를 통해 데이터베이스에 반영한다.- 데이터베이스에 정상적으로 반영이 되..
아마추어(?) 개발팀?~ 게임 개발이란.. 참으로 묘한 매력을 가지고 있습니다.. 하기 싫다고 떠난 사람들이 게임쪽을 못 떠나는걸 보면 말입니다.. 다른, IT도 마찬가지 겠지만 이직에 좀더 활동 범위에 제한적인것 같이 느껴 질때가 많습니다. 저는 지금 게임을 개발하고 있지는 않지만.. (한 5년동안 있었던 게임에서 멀리 떨어져서 보고 있습니다~)_ 저는 서버개발자 입니다.. 게임에서 많은걸 배웠지만.. 그러면서 만들어진 라이브러리를 정리할때면.. 언제 다시 써봐야지 하는 마음이 드니 말입니다^^; 그래도 게임사이트는 모니터링하게 되는^^~ 프로그래머에게는 새로운 기술에 대한 이해가 많이 필요할때가 있습니다. 그러나, 이해가 실전에 도입되는 사례가 많지는 않은게 현실입니다. 그 만큼 대규모의 자금력이 동원되어 개발되는 프로젝트라..
게임서버의 지형관리 방식에 대한 생각~ GPGStudy를 보다가 보면, 서버에서 지형관리 방식에 대한 논의가 자주 일어나는 것을 볼수 있습니다~ 예전과 다른 점이라면, 예전에는 구현 방식에 대한 논의가 많았다면 요즘은 어떻게 구현할것인가에 대한 논의라는 점일 것입니다~ 그도 그럴것이 2D에서 3D로 넘어 오면서 기존 2D 방식에 z 좌표를 적극적으로 활용하고 싶어하는 개발자가 많아 지면서 부터가 아닐까 생각이 됩니다. 그러다 보니, http://www.gpgstudy.com/forum/viewtopic.php?t=18890 처럼 쿼드트리 또는 옥트리를 사용한 지형 관리 구조를 논하게 되죠~ 필자는 아직까지 이러한 z 좌표를 사용하는 지형관리 구조에 익숙하지가 않습니다. 구조가 나빠서가 아니라, 필자가 고민하는 CPU 부하의 차이를 줄여줄 방법..
객체 이동 방식에 대한 반전!!! 온라인 게임을 논하는 중에 이동 처리 방식에 대한 다양한 의견들이 제시되고 시험되고 있다. 지금 이 시간에도 이러한 논의를 계속 하고 있는 개발자 들이 상당히 있을 것이다. 그럼, 왜 이에 대한 논의가 많은 것일까? 객체 이동은 게임의 기본적인 동작의 표현이자, 서버에게는 데이터 처리를 위해 가장 많은 시간을 사용하게 되는 처리이기 때문이다. -- 그리고, 서버 부하의 주된 원인이 이동 때문에 발생된다고 해도 될 만큼의 부하가 존재하기 때문이다. 그럼, 몇가지 객체 이동 방식에 대해 알아 보자. 1. 현재 위치를 일정 조건에 서버로 전송하는 방식 : 위치의 변화 또는 일정 시간(예를 들어 0.5초) 경과후 현재 위치를 서버로 전송 하는 방식 - 장점 * 위치 이동 응답성이 빠르다 * 비교적 개발이 간단하..
NPC 처리의 구성에서... 온라인 게임에서 NPC의 비중은 최소 최대 예상 PC의 5배수 이상인 경우가 많다. 그만큼 많은 NPC의 처리가 발생하게 된다. 이러한 상황에서 고려해야 할 상황을 정리해 보자~ 1. 이동 - 특징: 주기성을 가지게 되어, 부하 분산 처리에 용의하다. * 일정 주기 단위로(수초 이상) 이동 - 처리 부하 분산 목적 * 이동을 마친후 해당 위치에서 일정 시간 이상 대기 하도록 처리 - 처리 부하 분산 목적 - 이동 중 공격 발생에 대한 처리 상황 - 사용 가능 알고리즘 : 이동해야 할 객체를 판단하기 위해, 3x3 블럭별 Priority Queue 구성 - 이동전 블럭의 PQ에서 이동해야할 NPC를 얻어 이동할 블럭의 PQ로 저장 * 제한: 블럭당 최대 NPC갯수 지정을 통해, NPC가 한곳으로 모이는 것..
시야관리 - 또 다른 관리 방식: Viewport~ 온라인 게임에서 시야란.. 데이터 처리를 위한 것과, 처리된 데이터를 받아야 하는 객체를 관리하는데 가장 큰 목적이 있다. 그런데 문제는 데이터를 받아야 하는 객체의 수가 증가 한다는 것이고, 이를 위해, 시야를 근거리~원거리로 분리하여 관리하는 방법을 소개 하였다. 이번에 고민하는 부분은 데이터를 받아야 하는 객체가 실제로 필요로 하는 데이터를 걸러내기 위한 방법이다. 기존 방식의 객체가 View(보고 있는)하는 범위의 객체 뿐만 아니라 보고 있지 않는 음영에 존재하는 객체에게 까지 데이터를 전달한다는 것이다. 만약, O 라는 객체의 Viewport가 B' 방향으로 향하고 있다면 음영(뒷쪽)에 있는 객체의 정보 중요성은 낮아지게 된다. 다른 객체로 부터 데이터가 발생이 될때 O 객체의 뒷쪽에 존재한다면..
객체 이동 경로 관리 여기에서 말하고자 하는 것은 앞으로 이동할 경로에 대한 예측이 아닌, 현재 객체가 이동한 경로를 관리하고 처리하는 방식에 대해 논의해 보고자 한다. 어떻게 보면 이미 지난 데이터라 의미없을지 모르지만 예측이 아닌 객체(A)의 이동 처리 방식에서는 타 객체(B)의 현재 위치는 예전 위치이기 때문에 만약, 타 객체(B)가 객체(A)를 공격할때 이에 대한 정확한 판단이 필요하게 된다. == 이를 위해 다음과 같은 객체의 처리가 필요하게 된다. 다음과 같이 객체의 이동이 발생 되었다고 가정하다. 객체(A)는 이동을 하지만, 객체(A)를 보고 있는 다른 객체(B)는 일정 시간 이후에 객체(A)의 이동을 보게 된다. 이러한 시점에서 객체(B)가 객체(A)를 공격한다면? 서버에서는 객체(A)가 객체(B)가 보고 있는..