Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

lock other tasks, resulting in a far from constant rate. In discrete-event simulation mode, the rateis usually met exactly based on virtual time.The GameTask interface has only the one method int executeTask() which is called periodicallyto execute the task. The return value of executeTask() indicates whether the task was successful.A value of zero (the constant GAME_TASK_OK) means success, any other value (generallyGAME_TASK_FAIL) will abort the main loop (see run()).int run() Runs the main loop. This method does not return before the main loop is aborted, which canhappen for three reasons:• the executeTask() method of a GameTask returns a value different from GAME_TASK_OK inwhich case that return value is also the return value of int run(),• the abort() method is called in which case the return value is run() is GAME_TASK_OK, or• the loop is aborted for internal reasons (e.g., the Irrlicht device has been closed) in which casethe return value is GAME_TASK_ABORT.void abort() Aborts the main loop. The consequent return value of run() is GAME_TASK_OK.int getTime() Returns the current time in milliseconds. The time base is usually the start of the program,but this may depend on the timer implementation.Timer ImplementationsThere are currently two implementations of the GameTimer interface, IrrlichtTimer and BSTimer.IrrlichtTimer is the standalone game timer. Its timing source is the Irrlicht device which providesrealtime in millisecond resolution starting at zero when the application starts. But the time valueis only increased when a frame is rendered, which requires some special treatment. A GameTaskrendering frames must be scheduled with interval 0 so that the timer will continue running. Thisalso results in frames being rendered with a frequency that is only limited by the hardware. Anyother tasks are executed between the rendering of two frames, as in conventional single-threadedgames.BSTimer is the timer implementation for non-GUI and/or simulation mode. It uses the eventing mainloop from the BubbleStorm/CUSP library. Depending on the configuration of the linked library, theevent loop may either process events in real time using real sockets for communication, or it canrun in a purely simulated environment, processing events as fast as possible using a virtual time. Inboth cases, the BSTimer class does the same thing. Registered tasks are directly registered with thesimulator’s scheduler. The run() method just starts the main loop provided by the library whichin turn can be provided by the transport layer for realtime mode or by the simulator. Finally, thegetTime() method returns the time provided by the library which again may be either real time orvirtual time.The use of BSTimer has the advantage of running the game purely event-based and thus avoiding anybusy wait. But it depends on the BubbleStorm/CUSP library and thus cannot be used with other transportprotocols. IrrlichtTimer is necessary for achieving the conventional game behavior consuming thewhole computational power for rendering as many frames per second as possible.50 4.1 Game Architecture