Conceptual Architecture and Rationale
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.
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.