There are two different game architectures which could be used to support distributed RoboTable games these are Client-Server and Peer-To-Peer. The game architecture of Zhao is a hybrid requiring a server to manage the user profiles and using a Peer-To-Peer game architecture implemented using Microsoft tools. The Peer-To-Peer component uses two technologies PNRP and PNMS. The PNRP and PNMS protocols are not available outside of Windows XP which impacts on their usefulness, however the concepts they employ to connect peers can be adapted
The design rationale of GroupKit provides clear steps for developing a robust network toolkit. Extensibility and flexibility are the two principal characters we need to consider when designing a solution for this project. Using the interface and abstract classes can provide polymorphism in object- oriented programming. This allows the game developers to extend the general functions for their own purpose.
The GT provides a design for a network toolkit and this design could be useful for developing a similar network toolkit to support the development of distributed multiplayer RoboTable games. GT is a groupware toolkit that contains a lot of features which are not necessary for the RoboTable game environment.
The possible RoboTable games will have different states need to be managed. Therefore, robust game state management to support the RoboTable games is an important consideration. The MIMESIS uses a story world planner that contains a number of states and uses story world planes to transition states. The story world plans define action sequences for the manager to execute and transition between states. Because a state of a RoboTable game might have some actions sequences such as reading input from users, setting up different components and waiting for commands, we can adapt ideas from MIMESIS to create a game state manager to manage all states and transition between states when some actions have been executed. The State Pattern discussed by Schuller (2005) provides a remarkably robust structure for implementing a state manager for the RoboTable games because the pattern provides extensibility and flexibility to the design of the game state management. We can create as many states as we want and transition between them easily. It is appropriate to employ design patterns as basis for the development of distributed multiplayer RoboTable games. This will allow the game developers to extend the general functions and not require them to modify the existing code. We will therefore make extensive use of abstract classes and interfaces.
Chapter 4
Toolkit-Design
The goal of the project is to investigate how to support the implementation of distributed
multiplayer games for a RoboTable environment; i.e. to support RoboTable game developers, so they do not have to implement multiplayer functionality from scratch for each new game.
We have studied background in chapter 2 about the use of games for learning, the development of the RoboTable, network communication technologies and multiplayer game architectures. We have also reviewed the literature in chapter 3 on existing game architectures, network toolkits,
multiplayer game state management, and design patterns. The project problem has been defined in section 2.5.
In order to understand the requirements of distributed multiplayer RoboTable game development and to comprehend what functionalities a distributed multiplayer RoboTable game requires, the following section discusses an investigation for supporting distributed multiplayer RoboTable game development.
4.1
Investigation for Supporting Distributed Multiplayer RoboTable Game
Development
The investigation involves interviews with potential RoboTable developers and an illustration of a distributed multiplayer RoboTable game.
4.1.1 Interviews
In order to understand the requirements of RoboTable game development, interviews were conducted with Alan McKinnon and Keith Unsworth who have been involved in the RoboTable project since it started in 2003. They were able to provide insights into the requirements of the system. The interviews were mainly focusing on the following areas (the question list can be found in Appendix A).
Usability of a RoboTable game
Interface for RoboTable game development Main data of RoboTable games
Table 4-1 highlights the main requirements for the RoboTable game developers that came out of the interviews.
Table 4-1 Developers’ Requirements
Technical requirements Distributed networked process
Provide robust network communication infrastructure Integrate text and audio communication
Avoid having a custom server Game management
Provide basic, but as close to real-time as possible, RoboTable tracking facilities
Manage game setup and game play Graphics model
Display local robot movement on remote tables
Following the interviews, it was concluded that RoboTable game developers need highly integrated working toolkits, so they do not have to implement multiplayer functionality from scratch for each new game and that the toolkits should simplify the process of RoboTable game development. In order to comprehend what functionalities a distributed multiplayer RoboTable game requires, the following section uses an example to illustrate a game scenario and how it may work.
4.1.2 Illustration of a Scenario
To illustrate how the RoboTable games could work, Figure 4-1 presents a scenario of a distributed multiplayer RoboTable game.
Figure 4-1 Scenario of a RoboTable Game
The game scenario shows a networked multiplayer RoboTable game (Race Track). There are two types of users in this scenario: administrator and game player. Table 4-2 gives examples of user types for RoboTable games.
Table 4-2 RoboTable User Type
Type of User Role
Administrator Lab administrator, Tutor, Teacher
Game Player School children, student
Before the game starts, the administrators (Figure 4-1) at each table need to explain the game rules and train the students how to assemble and program their robots. Once the robots are constructed and programmed, the players at both sites need to place their programmed robot at the starting
point. Players turn on their robots when the game starts and the robots run along a black track, which is displayed on each table. At each table, the position and orientation of the local robot is tracked, and the latest robot update is sent to all tables through a computer so that a virtual robot representing the robot from the other table is displayed. The score is determined by the duration that a robot remains on the black track. For example, if a robot runs along the black track and does not move off the track for one second, the robot will get one score. Both tables receive the same “game end” message in order to calculate the final score. When the game ends, the calculated final score will be reported, and the winning table determined.
4.1.3 Conclusion of the Investigation
According to the scenario, a distributed multiplayer RoboTable game involves four main
functionalities namely robot tracking, network communication, displaying local robot movement on remote tables and calculating game results. These four main functionalities are matched with the project requirements in section 4.1.1. Therefore, we need a solution that can handle robot tracking, network communication and game management on behalf of game developers and provide general interfaces to the game developers.
Currently, there are no general-purpose tools to support these main functionalities (as discussed in section 2.5). Hence developing a set of toolkits to provide real-time robot tracking facilities, deliver robust network communication infrastructure and manage game setup, display and play, is an appropriate solution for this project. The reasons we choose to develop toolkits as the solution are as follows.
A toolkit can provide a software framework that developers can use to create applications easily as they only need to work with general interfaces provided by the toolkit.
Each toolkit is independent of the other toolkits. Hence, if one toolkit needs updating, then we only need to replace the one toolkit and the whole system still works.
Without toolkit support, developers may have to create all functionalities repeatedly for each new application. If a major function of an application without toolkit support needs to be upgraded, it is impossible to change the function for all applications using the same function.
Therefore, the design goals of the solution to fulfill the goals of the project are outlined below. Flexible and extensible
Good performance Good functionality
The following section explains the design goals outlined above.