멀티게임에서 플레이어 공격을 구현할 때 어디까지 클라이언트가 담당하고 서버가 어디까지 처리해야 안정적인 공격환경을 만들 수 있을까? 가장 이상적인 방법은 클라이언트를 완전히 신뢰하고 클라이언트가 보낸 정보를 바탕으로 서버에서 처리하는 방법일 것이다.
하지만 서버는 클라이언트를 항상 의심해야 한다. 클라이언트가 보낸 정보(패킷)가 조작된것일수도 있다. 그렇기 때문에 서버는 플레이어들의 정보를 항상 가지고 있어야 하며 플레이어가 각자 가지고 있는 자신만의 정보와 동기화가 되어 있어야 한다.
플레이어의 공격을 구현할 때는 플레이어 이동을 구현할 때와 달리 서버에게 공격 요청을 보내고 서버가 공격을 허용하면 클라이언트가 공격 모션을 취하는 방식을 사용한다. 아래 그림은 PlayerA가 공격을 하는 상황을 나타낸 그림이며 PlayerA가 받는 OK응답에도 애니메이션을 재생하라는 정보가 포함되어 있다.

만약 공격에 쿨타임이 있다면 플레이어와 서버는 쿨타임을 측정하며 클라이언트에서 쿨타임이 지난 후에 공격 요청을 해도 서버는 정말로 쿨타임이 지났는지 확인한다. 물론 쿨타임외에도 플레이어가 정말 공격을 할 수 있는 상태인지에 대한 정보로 클라이언트와 서버가 가지고 있을수도 있고 플레이어가 시전할 수 있는 스킬(공격)인지도 판단할 수 있어야 한다.
플레이어의 상태변화는 언제 이뤄져야 할까? 물론 게임을 구현할 때 정해주어야 하지만 위의 구조에서는 클라이언트는 서버로부터 OK응답을 받을 때, 서버는 클라이언트에게 OK응답을 보낸 직후에 각자 가지고 있는 플레이어의 상태를 변화시키는 것이 바람직하다.
만약, 클라이언트와 서버사이의 네트워크환경이 좋지 않아 클라이언트의 연속적인 공격요청에 대해서는 서버쪽에서 임계구역을 형성함으로 두번째로 도착하는 공격요청은 '플레이어가 공격할 수 있는 상태가 아님'으로 공격 요청을 무시할 수 있어야 한다.
피격판정은 역시 서버가 하게 되는데 공격요청을 보낸 클라이언트에게 OK응답을 보낸 직후 바로 피격판정, 피격통보를 처리하게 된다. 피격과정을 나타낸 그림은 아래와 같다.

피격통보에는 HP감소와 같은 피격자의 상태변화(스턴, 그로기, 죽음)가 포함되며 공격이 아닌 힐과 같은 치유스킬도 피격판정에 포함될 것이다.
투사체의 공격방식과 피격판정은 플레이어가 공격하는 방식과 다르다. 그 이유는 발사(소환)된 투사체의 피격타이밍이 공격시도 직후라는 보장이 없기 때문이다. 몇초 뒤일수도 있고 수십초 뒤일수도 있다.
먼저 플레이어가 활을 쏘는 상황을 가정하자. 플레이어가 활을 쏜다는 공격요청이 들어오면 서버는 해당 플레이어가 활을 쏠 수 있는 상황인지 확인한다. 쏠 수 있다면 플레이어가 활을 쐈다는 사실을 맵에 있는 모든 플레이어에게 알림과 동시에 서버는 화살을 소환한다. 화살의 소환 역시 모든 플레이어에게 전달하며 화살 소환을 통보받은 클라이언트는 화면에 화살을 랜더링한다.
투사체의 피격판정을 위해 서버는 짧은 시간주기로 모든 투사체의 피격여부를 판정 해야한다. 시간간격이 짧을수록 플레이어에게 통보하기까지의 시간은 줄어들지만 그만큼 서버에 부담이 될 것이다.

피격판정이후에 서버가 취할 행동 역시 일반공격과는 다르다. 화살이 벽이나 누군가에 도달했다면 보통 화살이 사라진다. 화살이 사라진다는 것은 서버가 가지고 있는 화살을 삭제하고 맵의 모든 플레이어에게 화살을 삭제하라는 통보를 해야한다는 것이다.
화살을 삭제하는 상황이 발생하기 때문에 플레이어의 요청으로 소환한 화살을 구분할 수 있는 식별자가 필요하며 피격자에게 누가 쏘았는지에 대한 정보를 제공한다면 화살객체는 누가 활을 쏘았는지에 대한 정보를 가지고 있으면 좋다.