There are 2 main architectures implemented in the game. An editing architecture is used to allow an author to create files. And then there is the architecture used within the game itself.
Editing Architecture
The editing architecture uses freely available components to create a suite of mechanisms for editing the data files. The architecture shown here is the very first draft. It will change.
The Sun Bean Box can be used to edit the underlying game data base objects as they have all been created as beans. This allows a graphical editing of the object and their relationships.
Otherwise, a simple text editor (or unicode editor) can be used to edit the underlying xml data files.
Game Architecture
The architecture of the game is driven by conflicting requirements. These requirements are: flexibility, scalability, performance, and development cost.
The general architecture of the game is shown below. Here we have a set of PC clients that communicate over the network to each-other and to the a central server. I expect this to be the final configuration.
Where possible I have used the standard Sun Java modules. This model of the game is quite simplified. The actual implementation can be seen by looking at the API pages.
The game has the following components:
Agent Processor
The agent processor is an AI style application, or just a simple scripter. It provides for interactions for NPCs and simpler interactive activities between the computer game and the user.
Command processor
The command process adapts the GUI control commands into game control commands. It also allows the GUI to determine the commands that can be processed in the current state.
Data communications unit
The data communications unit allows the transfer of data over the internet. This allows multiplayer operation and remote operation.
drama processor
The drama processor determines how the world will interact with the players action on a global basis to generate a drama of action within the game world. For example, the drama processor might decide that there is too little going on in the world and gave the NPCs in a particular city revolt against central rule.
Game database
The game core represents the objects in the game and their configuration.
Lock processor
The multiuser object lock module prevents 2 users trying to simultaneously access the same module by supplying object locks. It is required only for multiuser operation. It should be possible, though possibly risky, to use a PC playing in a game to provide this function.
Login processor
This processor manages the login process and provides broadcast actions to current and all users.
Personality processor
This is an AI processor to provide personality to the NPC style agents in the game.
Plot processor
This is a processor that manages the plot line and makes adjustments to the game database based on plot criteria.
Time processor
This is a processor that keeps track of the various time issues within the game. It is the clock for game time, but also tracks character time and real time.
User interface
The user interface processor runs all the screen, keyboard and mouse controls. It uses the swing interface and the new version of the AWT event model.
View processor
The view generator supplies the different views of the things display to the user interface processor. The intention here is to provide a simplest of views initially, but increasing in complexity at latter dates. The initial view will probably be a HTML view, followed by a 2D view, tree view and later a 3D view.
Missing
- mass inquiry processor (A thing that processes SQL style commands?)
For speed, initially all modules will interact directly with each other in a single client. This will result in a single player game.
As I develop a server, various functions will be hived off to the server. All inter-module interfaces will be able to work over the internet. For the duplication of the data-store, I will write a special module. For all other communications, I think they will either use the RMI functionality or info-bus. I have yet to determine which is more useful.
While the server functions in the above diagram are in the one server, there is no reason for each function to be on a different server.
22/11/99