관심분야/게임 (15) 썸네일형 리스트형 시야관리 - 데이터 최적화 여기에서 말하고자 하는 것은 시야 범위내 객체의 이동으로 인해 주변 객체에 전달해야 하는 데이터를 최적화 하는 방식에 대해 논하고자 하는 것이다. 화면은 일반적으로 MMO 계열의 객체 관리 방식을 나타낸 것이다. 일반적으로 3x3 방식의 블럭을 통해 객체에 대한 시야를 관리하고 데이터를 관리(전송)하게 된다. 이 방식의 장점은 데이터 발생에 대한 처리를 범위내 객체에 제한 되어 데이터 처리의 효율성을 증가시킨다는 장점을 가지고 있고, 물론 현재 대부분의 MMO 계열에서 사용되고 있다. 그러나 해당 방식의 가장 큰 단점은 바로 객체가 해당 3x3 블럭에 모여 있을 경우 데이터에 대한 처리가 많아 진다는 것이다. 즉, 100개의 객체가 존재한다면 발생 데이터당 100번의 데이터 전송을 해야 한다는 내용이 된.. [기사] 정부, 온라인게임에 '피로도 시스템' 도입 의무화 정부, 온라인게임에 '피로도 시스템' 도입 의무화 http://news.naver.com/main/read.nhn?mode=LSD&mid=sec&sid1=105&sid2=&oid=031&aid=0000126727&iid= 게임을 몇시간 이상 못하게 하는 방식에 비해 좀더 지능화 한 방식이군요. 점점 규제가 가시화 되어 가는듯~ 한쪽에서는 온라인게임 분야에 대한 활성화를 논하고 한쪽에서는 규제방식을 논하고... 이러한 규제는 별 도움이 안될듯~ GPGStudy에 이에 대한 글이 떴네요. 링크: http://www.gpgstudy.com/forum/viewtopic.php?topic=18836 NPC/AI 처리 1) 각 NPC는 Hate List를 통해 분노도가 높은 객체(플레이어 또는 NPC)를 우선 공격하도록 구성 할수 있다. : 이러한 처리 만으로 NPC는 기본적인 AI만으로 플레이어에 대한 공격을 처리 할수 있다. 예를 들어, 몬스터를 직접 공격하는 플레이어와, 해당 플레이어에게 힐을 해주는 플레이어가 있다고 가정한다면 몬스터는 힐을 해주는 플레이어를 공격할수도 있게 된다. 2) 전략 및 전술을 위한, NPC간의 적대/우호 관계 및 상하 관계 리스트 구성 : 이러한 구성을 통해 몬스터가 전투중 도망가야 하는 상황이 발생될때, 자신의 시야에서 자신에게 유리한 방향을 선택할수 있으며 만약, 시야중에 자신과 상하 및 우호 관계에 있는 다른 몬스터에게 도움을 요청할 수 있도록 처리할수 있다. 3) NPC 지형 .. NPC의 이동 관리 1) MOVE를 통보(Notify)받는 NPC에 대한 Priority Queue 관리 : 해당 처리를 통해 NPC가 플레이어가 존재하는 블럭에서만 이동할수 있도록 할수 있다. - Priority Queue는 전체 NPC를 한번에 처리 하지 않는 구조에 적합하며, 전체 NPC를 한번에 처리해야 하는 구조에서는 일반 list 처리가 빠른 성능을 보인다. - 해당 방식을 사용하기 위해서는 전체 NPC의 처리가 특정 시간에 집중 되지 않도록 분포시키는 기법이 중요하다. : 예를 들어, 전투/선공 상태의 NPC를 우선 처리하는 기법이 사용될수 있다. : 또한 Priority Queue의 insert/remove 시간을 줄이기 위해 형태별 독립된 Queue의 구성도 고려될수 있다. : 이러한 처리를 통해, CPU로.. 객체 이동 관리 1) 이동된 경로를 레코딩하여 일정 주기로 서버에 전송 하는 방식은... : 해당 방식을 통해 서버는 사용자별 네트워크 트레픽을 예측할수 있다. : 예측이 포함되지 않으므로 정확한 이동에 대한 처리가 가능하다. : 이와는 반대되는 방식이 클라이언트에서 움직일 경로를 미리 서버에 전송하여 처리 하는 방식이 있는데, 해당 방식은 중간에 경로를 수정하고자 할때 서버의 연산 처리(거리 예측 계산 등)가 증가될수 있는 원인이 되며, 이로 인해 이동 패킷 이외의 보정 패킷이 필요하게 된다. - 그러나, 위에서 언급한 방식은 이러한 위치 연산을 최소화 할수 있다. : 이 방식의 단점은 바로 일정 시간 이후에 다른 플레이어가 내 화면에서 움직인다는 것이다. : 이동 방식의 정리 1. 일정 주기(시간)로 이동 경로를 레.. Lua 5.1.3 Released 5.1.2의 버그를 사정한 5.1.3이 2008년 1월 25일 릴리즈 되었다. 각 버젼별 버그에 대한 자세한 정보는 http://www.lua.org/bugs.html 에서 확인할수 있다. 홈페이지: http://www.lua.org/ 1:N 서버 프로그램의 오류 - 스트레스 테스트 대부분의 개발자는 네트워크 처리방식(epoll 또는 IOCP)이 얼마나 많은 접속을 처리할수 있느냐에만 관심을 갖는다. 그러나, 문제는 네트워크 처리방식이 얼마나 많은 처리를 하느냐 보다 프로그램에서 얼마나 빨리 처리를 할수 있느냐에 따라 동접자가 결정이 된다는 것이다. 실 예로, 개발자들은 스트레스 테스트를 통해 동접자(동시접속자)수가 5000개 이상 처리 가능한 구조라는 식의 테스트 결과를 말한다. 이 결과가 틀렸다는 것은 아니다. 그러나 여기에서 빠진 가장 중요한 값이 있다는 것이다. == "데이터를 처리하는데 소요된 시간"이 테스트에서는 빠져 있다. 나도 프로그램을 하면서 이런식의 오류를 많이 범했다. 예를 들어 계산을 해 보자, 하나의 클라이언트가 초당 1KB(1024B)의 데이터를 서버로 동시.. 이전 1 2 다음
