좀더 세분화 되지 않을까요?

예를들어 케스팅을 한다. 그럼 일단 해당 스킬에 대한 케스트를 한다는 메시지를 보내고
케스트가 완료되면 케스팅이 완료되었으니 공격한다 라는 메시지를 보내겠지요.

연타성 스킬의 경우 해당 스킬에 대한 데미지 분기점(?)을 지정해서 메시지를 보내는 형식이 아닐련지요.

1. 플레이어가 공격키를 누름
2. 클라이언트에서는 공격동작을 곧바로 시작함과 동시에 서버로 공격한다는 메세지를 보냄
3. 서버에서는 공격의 유효성을 검사후에 데미지만큼 HP를 감소시키고, 클라이언트로 정보를 곧바로 보냄
4. 메세지를 받은 클라이언트는 곧바로 HP를 깍는 것이 아니라, 타격시점에 맞추어 HP를 감소시키고 이펙트를 보여줌

클라이언트에서 행해지는 위와같은 처리를 '연출'이라고 부릅니다.
각각의 일반공격과 스킬들, 그리고 마법들은 모두 스크립트를 통하여 연출하게 됩니다.
공격동작, 타격시점(시간), 타격이펙트, 사운드등 모든 것이 연출됩니다.

서버에서는 이러한 연출에는 관심이 없으므로 클라이언트에 처리를 맡기게 됩니다.
다만, 서버에서는 해킹방지를 위한 처리를 해주면 됩니다.

서버에서 딜레이 체크후 데미지정보를 보내는 것은,
부하도 증가되고,
아무래도 네트워크상태에따라 정확한 시점을 맞추지 못할 것입니다.
타격감에서 가장 중요한 것은 정확힌 임팩트시점이지요.
이러한 것이 맞지 않다면 타격이 아니라, 춤을 추는 것처럼 느껴지게 됩니다.

그러므로 타격감을 위해서는 연출이 필수고,
타격시의 카메라흔들림, 배경의 효과, 이펙트의 조합, 사운드, 데미지숫자, 맞는 동작, 타격에의한 뒤로밀림,
날아가서 죽는것등 타격감 상승에 도움이되는 모든 것들을 클라이언트에서 제어하며,
정확한 시점에 표현하게 됩니다.

이러한 것들은 '기획'파트에서 스크립팅할 수 있도록, 외부 스크립트로 제작되며,
스크립팅한것을 툴로 실제로 확인하며 조금씩 수정을 거쳐서 완성하게 됩니다.

잡다한 글로 길어졌네요. --;
요점은,
데미지 부분은, 서버에서 시점을 조정하는 것이 아니고,
클라이언트 연출의 한부분이라는 것입니다.

마법의 경우 1ststory 님의 말씀은 너무 당연한 말이 됩니다. 캐스팅부터 벌서 공격되었다는 처리가 될리가 없으니까요.
질문의 요점을 제대로 파악하지 못하셨네요.

염동력님께서 하신 말씀은 공격키를 누르자마자 공격동작을 하게 되면 바로 옆에서 다른 유저가 게임을 하고 있다면 동기화가 되지 않아서 내 컴퓨터에서만 먼저 동작이 보여지게 됩니다. 이렇게 처리하는 게임이 몇 있습니다만 먼저 동작함으로 인해 문제가 생길 수 있습니다. (예를 들어 몬스터 스틸건으로 먼저 도착한 사람등의 시비가 붙는 경우)
타격 시점에 HP를 깎는 방식도 있다고 의례 생각할 수 있지만 어떤 방식으로 처리를 해야할런지 난감해서 물어본거였습니다.
가령 마법의 경우는 캐스팅이 끝나고 마법이 시전되었을 경우, 일반 공격이면 칼질이 되었을 즉시 HP변동을 알리는 패킷을 따로 보내지 않고 그 공격패킷 안에 HP가 깎였다는
내용이 포함되는지 궁금합니다. HP가 깎였다는 패킷을 따로 보낸 경우에 그 깎인 HP가 어떤 동작과 관계가 있는지 알아야 하겠죠.
염동력님 말씀대로 하면, 멀리서 달려가는 유저에게 파이어볼 마법이 발사되었다고 했을 때 파이어볼이 막 나가는 시점에 이미 HP는 닳아있습니다. 하지만 타격처리는 늦게 보여주는 형태죠. 이때 케릭터가 멀리서 달리고 있었는데 이미 서버상에서는 케릭터가 죽어있었다고 칩시다. 멀리서 날아오는 파이어볼을 본 유저는 도망치려고 하지만 엉뚱하게도 달려가다가 말고 멈추어서 움직여지지 않습니다. 왜냐.. 이미 죽어있었기 때문에 ㅡㅡ (넌.. 이미 죽어있다..)
그리고 또 웃긴것은 물약을 먹을때 즉각적으로 물약 효과가 보이는경우를 생각해봅시다. 위와같이 파이어볼이 멀리서 날아옵니다. 이때 HP는 줄지 않고 있습니다. 하지만 실제로는 줄어있죠. 이때 파이어볼에 맞기도 전에 물약을 먹습니다. 물약을 먹음으로서 오르는 체력이 바로 보여집니다. 그 후에 파이어볼을 맞으면.. 보통 서버에서 데미지의 변화에 대해서는
최소와 최대치를 한꺼번에 보이지 현재 체력에서 몇을 깎아라는 식으로 보내지 않기로.. 이런 경우에 체력이 확 깎였다가.. 갑자기 다시 올라가는.. 그러니까 데미지를 당했는데
체력이 오르는듯한 기이한 모션이 보여지지 않겠습니까?

그리고 염동력님 말씀에 조금 오류가 있는듯 싶습니다. 칼질같은 공격동작을 미리 보인후에 서버에 패킷을 보내고 유효성 검사후에 데미지 처리를 한다면, 실제로 공격 히트 시점에 대해서 네트워크 지연상황에 따라 핀트를 맞추기 힘들어 보통 그러한 류의 게임은 공격시점과 데미지타격 시점이 따로 있습니다. 염동력님의 말씀은 제가 위에 썼던 글에서 밝힌것처럼 동기화된 처리를 위해서 미리 서버에 패킷만 보내고 서버에서 그 패킷에 대해서 다시 결과를 반환할때 움직이는것이 그런 문제를 없애줍니다. 물론 즉각적인 반응은 나타나지 않기에
네트워크 지연 상황에 따라 약간의 답답함은 느껴집니다. 리니지2도 그렇고 라그나로크도 그렇게 동기화 되어있지요. 염동력님 말씀처럼 된 게임은 드뭅니다.
예를 들어 미르의전설 같은 게임이 그렇습니다. 그리고 동기화된 처리를 할때 HP는 미리 깎이더라도(즉 데미지처리와 관계 없이) 정확한 타격 시점에 타격 소리가 나고 불꽃이 튀고 케릭터가 뒤로 밀리고 이런 처리를 하는것은 당연합니다.

리니지2 게임의 경우 마법을 캐스팅하고 마법이 발사되고난 이후 마법이 대상에게 히트하기 바로 전에 나무뒤로 숨거나 할때 실제 마법이 히트하지 않습니다.
또 마법의 히트에 대해 데미지변화를 단순히 체력의 감소정보만 보내주거나 체력의 현재상황(최대 최소정보)을 보내주는 형태일 경우, 마법이 막 발사되어서 날아오고 있을때
그룹원이 몹을 잡아서 레벨업을 했고 체력이 완전히 회복되었을 경우 체력변화가 좀 웃기게 처리 될 수 있습니다. 아니면 이런 경우 예외적인 코드를 더 해야되는 상황이 생깁니다.
하지만 아예 마법의 발사 시점과 마법의 타격 시점에 대해 서버에서 관리를 하는 경우, 조금 더 정확한 데미지 처리와 회피등의 처리가 가능할 것 같습니다.

패키지게임이 아닌이상, 서버와의 통신시간에 따른 어색함은 어쩔 수가 없습니다. 얼마나 어색함을 줄이느냐가 관건이지요.

0.5초의 차이로 스틸건의 시비가 붙을지 의아하고, 설사 시비가 붙는다해도 큰 무리 없을 것 같습니다.
그러나, 공격키를 누른후 0.5초이후에 공격이 시작되는 것은, 직접해보시면 알겠지만 무지 답답하게 느껴집니다.
(약간이 아니라 무지답답합니다. 이는 타격감에 치명적입니다.)

공격패킷안에 HP가 깎여다는 내용이 포함됩니다.
그러나, 죽었다고 해서 달리는 것을 멈출 필요는 없습니다. HP가 깍임과 동시에 죽여주기만 하면됩니다.
그리고 물약을 먹는 효과일 경우 먹자마자 HP가 차게끔 해서는 안됩니다.
서버에서 유효성을 검사하고 메세지를 돌려받은후에 물약의 효과가 나타나야하며,
HP는 아직 있지만, 이미 죽어있는 경우엔 물약이 먹어지지 않게 해야합니다.

눈치채셨겠지만, 자연스러운 연출을 위해서는 공격시점과 타격시점과의 딜레이가 너무 크면 안됩니다.
공격동작이 아주 큰경우엔, 동작을 나누어, 앞부분은 시전동작으로 처리하는 방법을 사용합니다.
파이어볼도 느리게 날라가면 처리가 힘듭니다. 빠르게 날라가야 자연스럽게 됩니다.

느린 유도탄같은 파이어볼은 별도의 처리가 필요하겠죠.
서버에서도 유도탄의 경로를 계산해야하며,
일정거리로 좁혀들면, 그때는 반드시 맞았다고 HP를 깍으며 클라이언트로 데미지 정보를 보냅니다.
클라이언트에서는 파이어볼을 유저에게 명중시키며 연출을 해주면 되겠죠.

제가 이야기한것이 정답은 아닙니다.
요지는, 어떻게하면 서버간의 통신 딜레이를 자연스럽게 처리하느냐겠지요.
저의 관심사는 타격감이며,
타격감을 극대화 하기 위해서는 다른 것은 허용되는 범위내에서 조금 희생하는 것을 택하겠습니다.

동작을 시작해서 히트 시점까지 너무 짧아서도 안되겠지요.
최소한 서버와의 통신에 필요한 시간만큼은 공격동작에 들어가야합니다.
그 시간은 1초정도면 무리가 없을 듯하고,
가끔 생기는 렉에 의한 지연은 어쩔 수 없는 것입니다.
렉은 고려는 해야하지만, 일반적인 상황이 아니므로,
일반적인 상황에서 최적화된 연출을 하는 것이 좋다고 봅니다.

실제 이 방법을 적용해보았으며, 만족할 만한 결과를 얻었습니다.
좀더 보안해야 할 것은 보안하겠지만,
다음 차기 게임을 만든다해도 이 방법을 사용하게 될것 같습니다.

먼저 움직이는것은 0.5초의 차이밖에 없을것 같지만 미르의전설 같은 게임을 해보시면 컴퓨터의 성능에 따라 유저 사이간에 속도의 갭이 크게 벌어지는 경우가 많습니다.
그리고 작은 차이로도 싸우고 제3자가 중재해줘도 신뢰를 얻지 못합니다. 많은수의 게이머가 다 이런 상황에 대해서 알고 있지 않기 때문입니다. 게다가 많은 게임은
이렇게 미리 동작을 보이고 패킷을 보내는 경우가 거의 없습니다. 현재까지 제가 본 게임중에는 유일하게 미르의전설 이라는 게임만 염동력님의 말씀대로 처리합니다.
이런 게임을 먼저 시작한 사람은 즉각적인 반응이 나오지 않을때 답답함을 느끼지만 리니지2 같은 게임이나 라그나로크같은 게임을 먼저 시작한 유저는 잘 알지 못합니다.
그리고 실제로 서버에서 유효성을 검증한 후에 자신이 케릭터가 반응하더라도 그 지연시간이 연결상태에 따라 거의 느끼지 못할정도로 빠릅니다. 응답이 따르다는 얘깁니다.
물론 실제로 그렇기 때문에 그러한 방식을 더 널리 사용하고 있는것이겠죠. (물론 동기화된 전투화면은 현장감이나 기타등등 전략적인 전투가 가능해집니다. 리니지2 개발초기에 밝혔듯이)

죽었다고 해서 달리는것을 멈출 필요가 있습니다. 만약 죽은 상태에서도 이동이 가능하도록 설정하면 가령 핵 프로그램의 등장이 대두될 수 있습니다.
항상 프로그래머는 클라이언트를 믿지 말아야 합니다. 요즘 시대에는 게임의 통신 프로토콜도 분석해서 핵 프로그램등을 만드는 시대입니다. 또 거의 모든 게임이 서버에서 죽은 상태의 케릭터에 대한 이동 명령이 들어오는 경우 움직여주지 않습니다. 리니지도 그렇고 미르의전설도 그렇고 라그나로크도 그랬습니다. 실제로 그렇게 죽은 상태인데 움직이는 게임이 있는지도 싶네요.

그리고 실제로 리니지2 같은 게임에서 일반 마법은 마법의 시전동작과 함께 별도의 개체가(파이어볼 같은) 몬스터에게 작렬하는 마법도 있지만, (이런류의 마법은 위처럼 처리가 까다롭죠) 마법이펙트가 마법시전동작과 함께 시전대상에게 나타나는 마법이 있습니다. (가령 회복마법을 사용하면 회복대상에게 빛기둥이 바로 솟아오르는 등) 이런 마법의 경우 즉각적인 회복처리를 해도 되며 또 공격이라고 해도 데미지 처리등이 쉽습니다. 가령 특정 케릭터에게 마법이 히트했다는 메시지를 따로 두어서 연산하면 되니까요.

염동력님 말씀대로 정답이 애초부터 없었던 질문을 한건지도 모르겠습니다. ^^;
어떤 방식이 널리사용되어지고 코드화 하기가 간단한지 궁금했는데 역시 품질을 높이자니 성능을 희생해야 되고 성능을 높이자니 품질이 희생되고.. 양날의 검이라는 생각이 드네요.
답변해주셔서 감사합니다. ^^

죽은상태에서 움직이는 게임있습니다.. (저희 게임이 그렇습니다.)
실제로 클라이언트에서는 죽지 않아 움직이지만, 서버에서는 이미 죽은 상태입니다.
그러므로 해킹에대한 우려는 없습니다.

이동도 패킷을 되돌려 받은 후 움직이고,
공격도 패킷을 되돌려 받은 후 공격하는... 그러한 게임을 하다가,

이동도 바로되고, 공격도 바로되는 게임을 접하게 되었을 때, 시원한 느낌을 받게됩니다.
특히, 키보드를 지원하는 경우엔 '필수'입니다.
가능 하면 바로 이동되고 공격되는 것이 좋지요.
클라이언트와 클라이언트 사이의 약간의 동기화 차이는 희생하더라도 말이죠.

에밀리님이 생각하시는 것보다, 공격을 시작하며 패킷을 동시에 보내는 게임은 아주 많습니다.
특히 최근에 출시되는 게임의 경우는 더더욱 그러하며,
앞으로 더욱 늘지 않을까 생각합니다.

학규님이 '전투프로그래머'란 것을 거론하셨었지요.
손맛을 살리는 것이 중요하며,
그러기 위해선 컨트롤상의 딜레이는 치명적입니다.

(논의의 시작은 '데미지의 시점처리' 였는데, '공격동작의 시점'으로 끝나네요 ^^;;)

먼저 움직이는것이 시원하다는것은 맞는 말씀입니다. 저도 미르의전설2 게임을 해봐서 압니다. ^^*
하지만 죽은 이후에 움직이는경우는, 만약 죽은 이후에 부활시켜주는 마법같은것을 사용할때 사용 이후에 화면을 어둡게 했다가 다시 밝게 해서 소생하는 트릭을 쓰면 괜찮을지도 모르겠네요. 또 어딘가에서 비명횡사 했을때 부활마법을 부탁할때도 좌표가 실제로 조금 다르긴 해도 근접한 좌표를 불러주게되니 역시 크게 상관은 없을듯싶네요.

하지만 손맛을 살리는 부분은 리니지2 게임만 봐도 실제로 타격이 이루어질때 타격시점에 이펙트와 데미지처리는 염동력님께서 말씀하시는 그 비동기적인 처리와 큰 차이가 없습니다. 단순히 타격감이 아니라 "즉각반응" 문제입니다만, 어느 경우를 선택하더라도 네트워크 게임이다보니 지연에 따른 문제점은 근본적으로 남기 마련입니다.
즉각적인 처리의 문제점은 가령 이런것도 생각해 볼 수 있습니다.
비동기적인 처리를 할때 미리 공격을 보여줬을때 화면상으로는 공격을 당했을 위치인데 서버에서 유효성 검사를 할 시점에서 보니 타격이 될 상황이 아닌 경우가 생깁니다.
가령 좌표를 대상으로 공격을 행하는 경우가 더욱이 그렇게 되겠습니다. 또 타격에 대해서도 그러한데 타격에 대해서 달리기가 바로 되지 않거나 움직임이 일시적으로 멈추어질때도 내 화면에 옆 컴퓨터 화면이 달라서, 가령 B유저를 공격했는데 공격당할때는 달려다니더니 공격당한 잠시후에 걷거나 약간 딜레이를 보인후에 갑자기 다시 달린다든가.
미르의전설2 게임에서도 이런 상황이 자주 연출됩니다. 공격당한 유저의 컴퓨터 처리속도나 네트워크 지연에 대해서 그런 상황이 뚜렷하게 연출되죠.
아까도 말씀 드렷다시피 양칼의 칼이라서 어느쪽을 선택하건 각각 장점이 있고 문제점 또한 생겨나는 것 같습니다. ^^;

손맛이라는것은 공격동작, 공격유형, 이펙트와 타격음 등에 의해 결정된다고 봅니다. 예를 들어보면..

공격동작(자세) => 동작이 허접하거나 오랫동안 봤을때 지겨울만큼 길거나 동작 자체가 처음에는 멋지나 나중에 보면 볼수록 오바같은 자세라든가.. 이런걸 조심해야 하겠네요.
또 같은 칼질 동작도 리니지2에서도 그랬듯이 조금 다양한 모션으로 휘둘러주면 단순한 느낌이 덜하죠.
타격시의 이펙트, 타격음 => 간과하는 경우가 많다고 생각하지만 매우 중요한듯 싶습니다, 써걱써걱 썰어버리는 느낌과 리니지2처럼 탱! 탱! 하고 금속음을 내는것은 재미가 다르더군요, 그리고 타격시의 이펙트의 경우 단순한 불꽃튀기는 정도라든가, 케릭터가 뒤로 약간씩 젖혀진다든가 그랬을때 더 현실감이 더해지고 손맛도 늘어나죠.
그리고 공격유형 => 큼직큼직한 셀로 격자형식의 맵일때 앞으로 2칸을 벤다든가, 주변을 공격한다거나, 일반공격과 강타기의 구분등

실제로 통신 프로토콜상의 처리와 크게 관계가 없는 부분들이 손맛으로 작용합니다. 나중에 손맛에 대해 질문을 한번 더 던지고 싶네요. ^^;

렉의 정도가 문제겠네요.
서버가 충분히 효율있게 동작한다면 렉은 일반적인 것이 아니라 특별한 경우라는 것입니다.

렉이 없다는 가정하에,
아무리 길어도 0.5~1초라는 시간동안 두 클라이언트상에, 또는 클라이언트와 서버상에
완전히 동떨어진 상황이 연출되지는 않으리라 생각합니다.
즉, 허용할 수 있는 정도라는 것이지요.
(미르는 제가 안해봤지만, 에밀리님이 말씀하신 상황이 매우 자주 발생하는 것이라면 아마도 처리가 완전치 않은가봅니다. )

실제로, 클라이언트상의 동기화가 매우 중요한 스타크레프트의 경우에도,
클라이언트 간에 유닛의 위치가 상당히 차이가 나는 경우가 종종 발생합니다.
다만, 이는 렉이 심한 특별한 경우며,
일반적으로는 허용될 수 있는 수준이라는 것입니다.

말씀하신대로, 각각의 장점과 단점이 존재하는 것이라,
각각의 게임이 추구하는 것과 성격에 따라, 적당한 것을 사용하면 그것이 정답이겠네요. ^^

손맛을 살리는 것 중, 가장 중요한 것은 정확한 임팩트(이펙트및데미지)라고 생각하며,
그밖에 양념같지만 중요한 것 몇가지를 나열하자면,

땅을 흔드는 카메라 연출효과,
공격동작과 다음 공격동작 사이에 딜레이없이 자연스러운 연결,
짧은 시간에 다다다다 때리는 동작(매타격마다 정확한 이펙트와 데미지숫자)
이동하며 공격하기(찌르며 관통한다던가, 한발 나아가며 베기, 뒤로 물러나며 공격하기등 )
타격받은 오브젝트가 뒤로 밀리는 효과,
큰타격으로 죽을시에 멀리 날아가 떨어지는 것..

그밖에 여러가지가 있겠지만,
사냥위주의 게임이라면, 타격감은 그 무엇보다도 중요하며,
어느하나 빠뜨릴게 없다고 생각되고,
이러한 것을 구현하는데 드는 노력은 아무리 많이 들여도 아깝지 않다는 생각입니다.