Benutzer:Amogorkon/PiLife/Time

Time is crucial in all international MMOs. Therefor it is required to put extra thought into it.

To provide a reliable base for calculations, an NTPd should be included to calculate an offset between global time and system time, without modifying the system settings.

Then the Unix time can be used as base and converted to many different formats, like internet-time, UTC, sun/moon circles and calendars, like the muslem one, or any other, also random phantasy systems.

The message system also can make use of a reliable time system, as all types of ingame events can be executed in the correct order, at the right time.

As for interaction ingame, a fixed artificial minimum delay of 30 ms or more should be considered. Especially IPv6 has higher ping delays than IPv4 yet, which means that there will be perceivable delay differences between users that are near and those who are far away. Such delays are most annoying when they are not predictable. Slowing down the interaction can make the world more steady and thus more usable, as long as the delays are not too big.

Unix time also provides a simple yet powerful and ressource-saving means to queue ingame events. For this a simple python dictionary is required which uses timestamps as key and a list of events as content. Every millisecond the dict is queried whether an event is registered for this timeslot and executed accordingly. This way, even long-term events can be scheduled easily, without using more ressources and even surviving server- and clientcrashes. Magic spells can make use of this as well as delayed message delivery or changing the day/night-pattern on the fly in private dungeons, economy management, AI-behaviour or system administration.

Having a local time offset also can be utilized to detect advanced sandboxes and manipulation of CPU-timings. On the other hand, it is a means to provide reliable and correct time, also on fast moving mobile devices, which can be quite a hassle on travels.

Movement

A possible way to implement movement as time-critical thing is to use a second port for UDP, independant from the TCP port used for the general XMPP communication and then deploy a simple, numbered packet vector-based dead-reconing system like PS does. An alternative could be a slightly more complex algorithm, using the established, slightly slower, XMPP gateway with a smart movement prediction. This could work as following.

The weight and center of gravity of every observable object is known to all clients involved. To accelerate the avatar of Alice when she hits the key, the client immediately sends a message to the server containing the (NTP-corrected) timestamp of the message, the direction and strength of the force and the flag "active". If she releases the key, another message is sent, telling the server this force has now stopped. As there is always a delay in the message delivery, a minimum response delay is applied, which is well provided by the inertia of the objects. With the mass, direction and velocity of objects known, Bobs client can well predict the movement of Alice's avatar within the next moment, which suffices to provide a smooth and realistic gaming experience. However, there is a little problem within this concept. As timestamps are used to order actions, the client can theoretically "undo" decisions by sending messages with modified timestamps. This requires the server to drop "impossible" packets intelligently and also to drop packets with timestamps from the future. Unlike other concepts using vectors to describe motions, this force-acceleration based concept handles rotation very well, since rotation can be described as a composite of at least two vectors that are applied constantly within the time they become active and inactive. Acceleration and inertia as base for motions provide not only an alibi for message delays but also a smart way for other clients to predict motions independant from the server, yet realistically.