| |
Games with Wireless Dynamically Changing Input/Output Units
by Anthony Savidis and Constantine Stephanidis
In the context of the European Information Society Technology Project 2WEAR the Voyager development framework has been developed to implement interactive pervasive applications with dynamically composed User Interfaces. The focus of the work is on pervasive games using handheld devices.
Our work considers the following scenario: a user carries a very small processing unit, eg the size of a credit card, with an embedded operating system (eg Linux) and wireless short-range radio networking (eg BlueTooth™). Additionally, the user may optionally collect any number of wearable wireless gadgets. Once the processing unit is switched on, the system boots and seeks in-range devices capable of hosting interaction. When such devices are detected, they are appropriately employed to support interaction. If at some point some devices move out of range (ie are lost), the system attempts to use the remaining available devices to maintain interaction. If this does not suffice, the dialogue is considered as 'stalled'. Alternatively, as new devices come into range (ie are discovered), the system attempts to engage those devices either to revive the dialogue from a 'stalled' state, or to optimise it further by offering a better interaction alternative.
 |
| Figure 1: Alternative output configurations for the Break Out game board display. Below centre: the textual display of the MASC Ltd. Wristwatch, a wearable Voyager-enabled ambient device. |
To support the previous scenario, ambient devices embed and run special-purpose Voyager software that allows clients remotely and dynamically to discover, recognise, grant, control, and release such devices 'on the fly'. Through the Voyager development framework, we have implemented the ambient Break Out game, a variant of the famous 'break out' game developed in the early 60s, known to be the first ever action-based computer game. We have chosen this game partly because of its simplicity, but mainly because its graphical stages can be easily translated to textual alternatives. Its implementation as a Voyager application has resulted in the delivery of a user interface that is dynamically reconfigurable, either automatically or on user demand, for both the main game board and typical non-game dialogues. In Figure 1, snapshots and photos of alternative output configurations for the game board are shown. Transitions between such configurations are either automatic (ie Voyager tries to revive or optimise the dialogue) or manual (ie the user updates the configuration preferences and requests explicit re-configuration). The game configuration dialogue allows the user to choose the most preferable input and output game styles. Where the available ambient devices allow multiple game styles, the user may easily switch among the viable alternatives, using the dialogue illustrated in Figure 2.
 |
| Figure 2: The game input/output style configuration dialogue. Once the 'Back to game' option is chosen, Voyager will try to activate the preferred pair of input and output control styles. |
The run-time performance of the Break Out game is very slow due to the severe run-time overhead of wireless communication. To avoid buffer overflows, explicit flow control had to be implemented within event posting (from ambient input devices to the Break Out client) and output requests (from the Break Out client to the ambient output devices). This flow control introduced a significant communication overhead, although users can still play the game normally, since the animation speed of the game is adapted dynamically to the total time it takes to remotely display and receive the event-processing acknowledgement. This communication overhead is naturally expected to diminish as new generations of BT chipsets are manufactured.
 |
| Figure 3: The run-time architecture of the Break Out game: the various software components of the Break Out application running on the user pocket machine (left), and the software structure of remote I/O services (right). |
Finally, in Figure 3, the run-time architecture of the Break Out application set-up is illustrated. The Break Out application is split into three key packages: (i) The I/O service library, delivered as a collection of C++ proxy APIs for remote-device I/O services; (ii) the dynamic I/O control package, which implements logical I/O control (eg left, right and textual platform display) while enabling the particular employed I/O services to change on the fly; and (iii) the main game control, implementing the main loop and animation control, while relying upon logical I/O control.
Please contact:
Anthony Savidis, FORTH-ICS
Tel: +30 2810 391749
E-mail: as ics.forth.gr
|
