1. 세션 매니저(유저 매니저)

세션을 관리하는 매니저 클래스.

 

 

2. 멀티 스레드 환경에서 발생하는 여러가지 상황들

(1) 상황 - 플레이어의 피격

인게임에서 플레이어 캐릭터(10번) 주위에 몬스터(5)와 다른 플레이어가 있다고 생각해보자.

그 몬스터에게 피격당한 플레이어의 정보를 어디로 보내야 할까?

 

->10번 캐릭터가 5번 몬스터에게 피격당했다는 정보를 해당 캐릭터 '주위'의 캐릭터도 받아야 한다.

(브로드캐스팅 한다 <-> TCP의 브로드캐스팅과는 다름)

이럴 때에는 세션 매니저에서 10번 캐릭터의 정보에 접근해 정보를 수정하고 외부의 클라이언트와 통신하면 된다.

 

 

(2) 상황 - 플레이어에게 귓속말

각 스레드를 부여받은 클라이언트들이 모두 동시에 10번 플레이어에게 귓속말을 날리고 싶다.

이 때, 유저 매니저는 Thread-Safe 할까? 아니면 락을 걸어 관리해줘야 할까?

 

-> 멀티 스레드가 유저 매니저에 접근해 정보를 동시에 수정하려 할 것이므로, 락을 걸어 관리해야 한다.

 

 

(3) 상황 - 필드 상에서 몬스터를 관리하는 스레드

필드 상에서 여러가지 몬스터를 관리하는 스레드 하나를 배치했다면 이것은 싱글 스레드 환경이다.

그렇다면 해당 필드에 플레이어를 배치하여 스킬을 사용하는 상황을 생각해보자.

이 상황에서는 플레이어가 스킬을 사용했다는 것을 어떻게 통신할 것인가?

 

-> 스킬을 사용하는 작업(일감)을 큐에 저장하여 해당 스레드가 나중에 실행한다.

ㄴ> 그렇다면 큐는 동시에 접근할 수 있으므로 Thread-Safe 하지 않으므로 락을 처리해줘야 한다.

 

 

(4) 상황 - 필드가 하나로 합쳐졌을 때 멀티 스레드 관리

각 필드와 스레드가 1:1으로 관리되고 있었다.

그 때 사양이 변경되여 어떤 두 개의 필드가 하나로 합쳐지는 상황이다.

이럴 때 어떤 스레드가 해당 필드를 담당해야 하는가?

 

-> 락을 걸어서 두 스레드가 각각 처리한다. 

-> 모든 액터들에 큐를 두고 각 액터마다 스레드가 왔다갔다하며 처리하게 한다.

=> 사실 싱글 스레드로 만들어 처리하는게 더 편할 수도 있다..

 

 

3. 커맨드 패턴(Command Pattern)

디자인 패턴 중 하나이다.

각 작업 요청(Job, Task)을 객체로 만들어 관리한다. 이후에 큐에 저장하고 불러와서 작업을 처리한다.

몬스터의 이동, 공격 등의 작업도 해당 큐에 넣어 처리하게 된다.