Escritura con Haz de Protones (PBW) Ventajas específicas.

Normally, a real-time virtual world is implemented using an update loop where the operating system triggers the world state update several times per second without giving any guarantees about the exact times. When the update is started, the current real-world wall time is read and the virtual world state is updated to that time.

A discrete event or event-based simulation models a system to perform state changes only at discrete points in time whenever an event occurs. Internally, an event-based simulator maintains an event queue containing all future events to be processed. It performs a loop dequeuing the first event from the queue, updating the state of the system, and adding any events generated during the update to the event queue. Since the simulated system is a physical system using wall time, each event has an associated timestamp signalling the time it will be executed to change the state in the system. The simulator always maintains a current virtual time [73] which is always equal to the timestamp of the event executed last.

3.1 Basic Idea 41

If multiple nodes have the same system state and the same events, they will perform the same simulation creating the same result state. Therefore, implementing a real-time virtual world simulation using an event-based simulation can be used to synchronize the state on different nodes without exchanging the state itself.

However, the impression of real-time interaction is normally created using the fast- running continuous update loop. Therefore, we have implemented a hybrid virtual world simulation using a continuous update loop to internally perform an event- based simulation as proposed in [46]. On every update triggered by the continuous update loop, the simulator processes all events that have occurred since the last update applying their change to the world state timed to their respective execution times. However, there are also continuous changes in the world state as objects move. Therefore, before executing the event, the simulator first updates the state of all objects to the execution time of the event before applying the state change by executing the event. Finally, a throw-away copy of the world is updated to the current wall time and rendered on screen so the user always sees the current world state even when no events have occurred. Although performing multiple state updates in one invocation of the world update functions makes it much more expensive depending on the number of events to be processed since the last update, the effort is still negligible compared to the rendering of the world.

Using this hybrid model, actions of players are processed as events. A player starting to move would be realized by creating an event with the current time as timestamp and adding it to the event queue. Upon executing the event, the simulator will first update all objects including their current positions to the event’s execution time and then change the movement vector of the player character. Upon execution of the next event, the player character position will be updated according to the movement vector and the time passed since the last updating of the player character. Its movement will continue with its position being updated until another event of the same player changes the movement vector again.

All other state changes have to be implemented using events, too. The collision detection has to be triggered by an event to stop moving objects colliding with other objects. Depending on the maximum movement speed, the detection events have to be executed several times per second to detect collisions reliably. The AI controlling NPCs has to inspect the virtual world and take decisions as a result of executing an AI event. If a player executes an action that has a certain cast time, the beginning of the cast will be an event. When the event is executed, it creates another event signalling the completion of the cast. Upon executing the completion

42 Chapter 3 A Cheat-Resistant MMVE Architecture

event, its effect will be applied. It could also create more events each applying their own effect or creating even further events. This way an action can cause multiple effects at certain times during its execution.

In our hybrid approach, the continuous update loop performs a kind of sampling of the event-based simulation. No matter how often or at which times the continuous update function is called, the updated state at all event times will always be the same. By exchanging events only and receiving them in time, all nodes in a network would be able to calculate the same state of the world. Luckily, events like the AI event, collision detection events, or events created as a result of executing another event do not have to be exchanged between nodes. Collision detection and AI events can just be scheduled at fixed intervals while events created by other events do not have to be exchanged as long as the root cause event is exchanged. In general, it is sufficient to only exchange events signalling the execution of an action by a player to realize a consistent distributed simulation.