Conceptual Architecture and Rationale

Top-Level Conceptual Architecture


Our highest-level architecture is a simple client-server model, which primarily acts as a delivery method for the actual application. Before choosing the client-server approach, we also reviewed another comparable approach: the event-driven archicture. We chose client-server as it provides good abstraction for our components and provides a centralized place where computation and processing occurs. Client-Server also segues our design into better supporting scripting and AI modules. Though an event-driven approach was sought out for it's capability of supporting an architecture which "reacts" to behaviour of the system, the overhead to handle broadcasts was undesirable in an already complex system. Additionally, with the introduction of the AI scripting module which is composed of heavy system communication, we need to minimize "broadcast" behaviour and relax system performance concerns. Our requirements dictate that the application must be able to be opened in a web-browser as a Java applet. This suggests that the applet will reside on a web server, and most clients will be connecting to it through the Internet. The data repository is a component that allows for remote management of the applications settings and data, and the application will connect to it for information on an as-needed basis. Since users of the applet will either be administrating the system or playing the simulation, we decided upon having two kinds of user interface, one for administration and one for the simulation.

In implementing our system, we reviewed strategies of implementing how our server would communicate with the user's client. Two widely accepted methods exist which represent how much source code would be loaded on the end user's machine: thin client and a fat client approaches. A thin client would be a smaller program, at the expense of having to "talk" more to our server. We had considered a thinner client approach where there would be a separate server responsible for running the simulation aspect of the application, but that was ruled out because of potential network lag issues that would adversely affect the accuracy and use of the application. We also considered an even fatter client approach where all of the applet settings were packaged along with it, but that would require a repackaging of the applet at each settings change. Since we anticipate ongoing settings changes, repackaging becomes a hindrance to users who are unfamiliar with that process. A fat client approach is also optimal as it capitilizes on MVC extensibility, whereby a successful fat client software platform is well abstracted and components can be customized and swapped in and out to better satsify customer needs. Similarly, MVC structured systems can have view and control components updated while retaining a uniform model, thereby ensuring more linearity in installations.

The chosen architectural design resolves both these issues. Network lag is eliminated altogether because the applet does not have to communicate simulation data across a network. The data repository allows settings to be changed independently of the applet package and also allows for a smaller applet package by giving extra data, such as unused scenario, maps, a place to stay until it is needed.

Game UI: This module contains the simulation interface and is responsible for displaying a 3D environment and allowing the user to control a vehicle that exists within that environment.

Admin UI: This module contains the administration interface allowing an administrator to make changes to the settings within the data repository.

Data Repository: The data repository is a location where data can be stored and retrieved easily. We'll be considering the following implementations: SQL database, XML files on a web server, and a custom Java server application.

Applet: The applet is the main application. It is run within a web browser and provides the afore mentioned user interfaces along with 3D rendering and simulation functions.
Application Architecture

Since the applet is essentially the entire application, we thought it merits its own small discussion. The applet will follow an event-driven model-view-controller architecture where events are created by the controller interfaces. The controllers consist of the user's own input, the program's internal timer, and input from 'trap artificial intelligence' threads that control other vehicles in the simulation. The view consists of the rendered in-game display as well as any supporting screens such as 'level completed' or 'level failed' screens. The model is the simulator itself and all of its supporting data.

Web Browser: The web browser is responsible for connecting to the web server to retrieve and then run the application applet.

Web Server: The web server is responsible for making the application applet available on the Internet.