I''m currently working on a game best compared to Diablo. For an attack these are the steps I take:

Click with mouse on enemy.

Do picking.

Get object ID.

Procotol->RequestAttack(ObjectID)

Packet send (packettype = requestattack, objectID) 5 bytes. (keep this as small as possible)

OnRequestAttack on server triggered.

Find player attached to connection, check if player logged in

Get player pos, validate and find enemy and get enemy pos.

Build path using an adjusted kind of A* pathfinding.

Attach path to the player object

When every object on the server is animated: walk a path node, and calculate new time for next movement. To walk a path-node, send a packet to every client in this area: Protocol->Move(ObjectID, x, y);

When end of path reached, do attack, or enter door, or pick up object, or read sign, ...

To enter a door for example, delete player object from current area. Send packet to all clients still in there: Protocol->DelObject(playerID); Attach player to new area, and notify all clients currently active in that area: Protocol->NewObject(playerID, x, y, ...properties...), send new area information to player, and populate with objects.

...this is where I''m currently at...now implementing an attack on an enemy, taking a swing, enemy pain, enemy death...life/strength/armor...blabla...

I''m thinking about sending complete paths to every client in the same area, but this needs stop packets...still work in progress...

As long as the client can only send requests - no cheating possible.

I hope this is usefull...

Oh - i forgot to say:

Using C++ OOP, I''ve implemented events.
For example:
If an objects moves, all other objects in the same area get an event like OnMove(objectID);
This may seem like overdoing it, but now objects that are attacking you (TargetID == MovingObjectID) can re-calculate their path, and can keep attacking you when you move.
Same counts for you, attacking a moving enemy.

I''ve added all kinds of events. Enemies may want to take notice when a new player enters an area. Maybe enemies want to alarm fellow enemies when they see you. Maybe you want an enemy to laugh when they killed a player dying next to you. Maybe you want ...

All server-side.

My client only has a user-interface, 3D graphics, animations, picking, setup, sound, ...more than enough

I can go on and on about this, so I better get back to programming now

Prediction algorithms can be found in numerous articles here and at gamasutra.com. Search the sites for them and the article should be able to give you enough information about the topic. How fast you update the client is entirely up to you. Many people suggest that you update the client at some rate that increases for all objects as you get closer to the object in 3d space. Since you have to do the collision detection anyway, it is not a large jump to determine the distance from the player and adjust the update rate based upon that distance.

Everquest suffers from a bad implementation of prediction. From what I know Quake is a much much better example. Your prediction algorithm at the very least should be able to predict the AI ''you'' wrote with exceptional accuracy. Predicting player movement and such is a more complicated task, but you know when your AI makes decisions and it is not difficult to replicate some of this on the client side to prevent things like ''warping'' NPCs. Typically, you will flag certain packets as important and handshake those packets to ensure that they arrive at the client machine. IMHO movement of anything in picking range should be an important packet and be resent to the client in the case of packet loss. Once LAG sets in the problem is out of your hands and there is little you can do to improve the conditions so plan for a reasonable latency and build your networking code/update interval around that latency. Be sure to use the packet sizing in your networking code efficiently and don''t send tuns of small packets when you can consolidate a few and send it in a single packet.(requires less handshaking) The www.internethealthreport.com considers any latency under 120ms to be stable and is a decent place to plan your network code around. In my experience, after 250ms latency you may see artifacts in your prediction algorithm and it severly breaks down in the 500 - 750ms latency levels.



Derek Licciardi (Kressilac)
Elysian Productions Inc.