# Which game logic should run when doing prediction for PNP state updates

We are writing a multiplayer game, where each game client (player) is responsible for sending state updates regarding its "owned" objects to other players.

Each message that arrives to other (remote) clients is processed as such:

1. Figure out when the message was sent.
2. Create a diff between NOW and that time.
3. Run game specific logic to bring the received state to "current" time.

I am wondering which sort of logic should execute as part of step #3 ?

Our game is composed of a physical update (position, speed, acceleration, etc) and many other components that can update an object's state and occur regularly (locally).

There's a trade off here - Getting the new state quickly or remaining "faithful" to the true state representation and executing the whole thing to predict the "true" state when receiving state updates from remote clients.

Which one is recommended to be used? and why?

I think what you are asking here is whether to use authoritative servers or non-authoritative servers. Unity network documentation has a nice discussion about each mode. Also if I'm not wrong, some people call semi-authoritative to a mixed approach where some state is handled by the server and some by the client.

I think Unity discussion should give you a good grip of the pros and cons of each alternative. Regarding the implementation, the two alternatives are: calculating state deltas, sending them and reconciling the state, or either sending the whole state. What method is better depends on the state, so you will need to define it in an individual basis.

I suggest to have a compromise on frames delivered(fps), anyways without a strong server to handle and maintainance cost building up, you would consider switching to provide players with full functionality of game resources and less(relatively) attention to getting the state quickly.

[I suggest to compromise(slightly) and remain faithful to players]

Now for the developing part, you could keep two times (zones),

1.Depicting user time(this depends on user & may vary by location/zone)

2.Depicting server time to club all game related events (Universal time)

For this , you need to send state ,that is recently configured, just before the end of your update method() and set frames afterwards, or you may end up in loop. In main method, try to use dynamic variables and "store state and previous states in array.", alongwith updates for player position speed, accl, as mentioned by you.

Whenever a player acquires a object, only a variale boolean corresponding to it should be active, and sent to other clients whenever next update is called

You will have to figure out a rate that suits your game best, although both are important refrence: http://www.mmorpg.com/blogs/FaceOfMankind/052013/25185_A-Journey-Into-MMO-Server-Architecture

http://www.leebrimelow.com/actionscript-3-quicktip-4-dynamic-frame-rates/

And studying from open source MMO examples also...How should chat be transmitted and stored in an MMO? for an approach to store times for objects instead of messages in your case.