[07주차] TEST & 시야처리

 

 

- TEST

 : Test의 필요성 

 1) 버그 없는 프로그램을 만들기 위해

 2) MMORPG 게임 고유의 Test → 부하 테스트(Stress Test), 성능 측정 (동접)

 

 : Test의 단계

 1) 작성자 테스트 / QA 테스트

 2) 알파 테스트 (비 관계자를 동원, 같은 회사, 개발자의 가족/친구)

 3) 클로즈드 베타 테스트 (불특정 다수 동원, 실제 부하 테스트의 시작)

 4) 오픈 베타 테스트 (모든 사람 상대로 테스트)

 

 : Stree Test

 - 많은 인원이 동시에 접속해 테스트 진행, 적은 인원이었을 때 보이지 않은 버그들을 발견 가능 (멀티쓰레드!)

 - 서버 프로그램의 bottle-neck을 발견 가능 (DB, Network Overhead, Memory allocation Overhead, NPC AI Overhead)

 - 문제 ) 많은 인원의 동원 쉽지 않음, 원하는 시간 테스트 힘듦, 통제 힘듦

 

→ 따라서 자동 테스트 프로그램 

 - Dummy Client라고도 불림, No visual (부하 감소)

 - 하나의 프로그램에서 여러 개 캐릭터로 동시 접속 (테스트 비용 감소, ID 미리 만들어 놓기)

 - 아바타 행동 모방 프로그램을 이용 (이동, 전투)

 - 한계 ) AI의 한계 - 복잡한 작업 수행 힘듦, 실제 인간의 행동과는 차이 존재

 - 구조 ) IOCP, Test_Thread에서 플레이어 컨트롤 (단순 랜덤 이동, MAX_TEXT에 맞춰 접속 추가)

 

 : 서버 성능의 확인

 - 부하를 주고 서버가 견디는지, 랙이 있는지 확인 

 - 부하 : 동접 / HoySpot

 - 랙 측정 = 클라에서 보낸 신호가 서버에 갔다가 되돌아 올 때까지의 시간 측정 

 

struct sc_packet_move {
 	char size;
 	char type;
 	int id;
	short x, y;
 	unsigned move_time;   // millisecond 값
};

struct cs_packet_move {
 	char size;
 	char type;
 	char direction;
 	unsigned move_time;
};

 

 - 가장 많은 방법 → Move Packet에 전송 시간을 추가해서 측정

 

 : 현재 우리가 만든 프로그램의 가장 큰 원인 → Move 함수 (WSASend)

 : 해결방안 → 시야처리

 

 

 

- 시야처리

 : Standalone 게임과는 다르게 동접이 중요하며, 각각의 플레이어 행동이 다른 플레이어에게 전달되어야 함 (BroadCasting)

 : 클라이언트에서 게임 월드의 상황을 보려면 다른 Object들의 상태도 볼 수 있어야 함

 : 하나의 Object의 상태가 변경 → 서버에 존재하는 모든 플레이어에게 변경 내용 전송 필요 (비용!!)

 

 : Broadcasting 최적화

시야 - 정내훈 교수님 강의 자료

 

 → WSASend의 횟수 감소 → 나를 보고 있는 플레이어에게만 알리면 됨 (시야)

 → 그래서 검색은 어떻게 해?

 

 : 효율적인 검색 (최적화) - 용어는 게임마다 다름

 1) Zone

  - 효율적인 검색의 기본

  - 전체 월드를 큰 논리적 단위로 쪼갬

  - 대륙,월드, 인던 (서로 볼일 없음)

 

 2) Sector

  - Zone보다 작은 개념

  - 서버 내부에서 검색 효율성을 위해 도입

  - 자신과 인접한 Sector만 검색 (크기는 적절해야 함)

  - 섹터마다 섹터에 존재하는 옵젝 목록을 관리하는 자료구조 필요

  - 모든 옵젝의 이동/생성/소멸 시 자신이 속한 섹터의 옵젝 목록을 업데이트

 

 : 시야 처리 – 시야 밖의 object에 대한 정보는 클라이언트에 전송되지 않음

  - 좀비 : 시야에서 사라졌는데 클라이언트에 계속 존재
  – 유령 : 비주얼 정보를 받지 않은 객체가 이동, 보이지 않는 객체가 다른 객체들과 상호작용

 

 → 클라이언트에 표시되는 객체들의 리스트를 서버에 저장
 → 이동 시 이 리스트를 기반으로 시야 처리
    – 유령 배제 : 리스트에 없으면 무조건 비주얼 정보 전송
    – 좀비 최소화 : 두 번째 이동에서는 무조건 삭제, 일정 시야 내에서는 좀비가 절대 존재하지 않음.

 

 

 

- 시야리스트

 : 클라이언트에서 보여주고 있는 객체의 리스트

 : 이동 시 업데이트 필요

 

 : ViewList의 Copy (최적화)

 - 뷰리스트의 업데이트를 직접 하는 것이 아니라 복사하여 사용한 후 새 뷰리스트로 교체
 - lock이 걸려 있는 시간을 최소화 하여 lock으로 인한 성능 저하 최소화

 ( 주의 - Dead Lock : 나의 뷰리스트와 상대의 뷰리스트를 동시에 Locking할 때 ) 

 

 

constexpr int VIEW_RANGE = 5;  // 클라이언트 시야보다 약간 작게 (확인용)

class SESSION {
	OVER_EXP _recv_over;

public:
	mutex _s_lock;
	S_STATE _state;
	int _id;
	SOCKET _socket;
	short	x, y;
	char	_name[NAME_SIZE];
	unordered_set<int> viewlist;
	mutex	_vl_list;

	int		_prev_remain;
	int		_last_move_time;
	
// ....
};

bool can_see(int a, int b)
{
	int dist = (clients[a].x - clients[b].x) * (clients[a].x - clients[b].x) +
		(clients[a].y - clients[b].y) * (clients[a].y - clients[b].y);

	return dist <= VIEW_RANGE * VIEW_RANGE;
}


// Process_packet 함수
// case CS_MOVE

		clients[c_id]._vl_list.lock();
		unordered_set<int> old_viewlist = clients[c_id].viewlist;
		clients[c_id]._vl_list.unlock();
		unordered_set<int> new_viewlist;

		for (auto& pl : clients) {
			if (pl._state != ST_INGAME)	continue;
			if (false == can_see(c_id, pl._id)) continue;
			if (pl._id == c_id) continue;
			new_viewlist.insert(pl._id);
		}
		clients[c_id].send_move_packet(c_id);

		for (int p_id : new_viewlist) {
			if (0 == old_viewlist.count(p_id)) {	// 새로 들어옴
				clients[c_id].send_add_player_packet(p_id);
				clients[p_id].send_add_player_packet(c_id);
			}
			else {
				clients[p_id].send_move_packet(c_id);
			}
		}

		for (int p_id : old_viewlist) {
			if (0 == new_viewlist.count(p_id)) {
				clients[c_id].send_remove_player_packet(p_id);
				clients[p_id].send_remove_player_packet(c_id);
			}
		}