[module 1] demoville
Amsterdam and Rotterdam (the Netherlands)
January 2004 - April 2004
The main aims of the prototype software were to build a basic simulation system, and a rough version of the graphical look for the final game. These are two of the main test areas which needed to be explored through making a working game. The prototype comprised two main parts: the simulation system and a grahical client for it. the simulation system was built in Python and the client was made through re-engineering the graphics code of the Blender game engine.
The prototype system was named 'Demoville'. 'Demoville' shows a small section of housing similar to those in the Spring drawing along with a version of the Test Centre where the Milgram Obedience Test is carried out. There are characters representing male and female inhabitants, a child, a riot policeman and one of the 'dogmen' from the story. Inside one of the houses is a pirate radio set, as used in the story by the inhabitants.
The space can be explored in 'tourist' mode or by the user becoming one of the characters and following it through the space. Characters can talk to one another, take part in the Milgram Test or talk with others on the radio.
Outline of 'Demoville'
Development notes for 'Demoville'
Animation tests, walk cycles
Outline of 'Demoville'
'Demoville' is a small scale environment being created for the initial test version of spring_alpha.
It is based on a small set of features from the original Spring narrative. It has 2 houses, a version of the Obedience Testing Centre, some trees and a vegetable patch. One house will represent a standard domestic house, the second one will have the pirate radio station setup (in the original story this is housed in the school).
Figure 1. plan view of 'demoville' (click on image for enlarged version).
These relate to the following sections of the text:
It is spring. A high-density council estate is apparent ...We aim to build a basic navigatable version of 'Demoville' and then add interactive and gameplay components as the project develops.
Two years ago they decided to grow food on the land around their homes. Vegetables now thrive where there were roads ...
On completion of their final exams at school, young people are taken to a newly-constructed Obedience Testing Centre, where they undergo Milgram's Obedience Experiment. ...
The council estate forms the local base for operations in the locality, acting as field hospital and centre of communications. ...
The older children have used the resources of the school's electronics laboratory to monitor the airwaves and maintain radio contact with revolutionary groups throughout the country.
Development notes for 'Demoville'
The 'demoville' plan is broken down into a series of areas - figure 2. Each of these is represented by a domain object within the simulation (see spring_alpha.simulation.domain within the API documents). A domain is a spatial area within the simulation capable of exhibiting particular behaviours - such as weather events in the 'outdoor domain'.
Figure 2. 'domains' within demoville (click on image for enlarged version).
Figures 3 to 8 show a series of analyses of typical character behaviours over the course of a day. These are shown as UML Activity diagrams. These provide a starting point for developing a sereis of automated AI driven characters. The activities are related to time and location (matching the 'domains' described above). These are deliberately stereotypical in their characterisation. More 'accurate' and speicific characterisations will be developed through the public workshops, in which character development will be related to particpants' own experience.
Figure 3. 'woman' character (click on image for enlarged version).
Figure 4. 'man' character (click on image for enlarged version).
Figure 5. 'school girl' character (click on image for enlarged version).
Figure 6. 'school boy' character (click on image for enlarged version).
Figure 7. 'policeman' character (click on image for enlarged version).
Figure 8. 'dogman' character (click on image for enlarged version).
The spring_alpha system makes a clear dustinction between the simulation model and its graphical views and interfaces. This is to allow a variety of different viewer modules to be used to interface with the system, ranging from text-based console to 3D graphics.
The system is being developed primarily as a Python module containing various packages. There are two main groups of packages: "user packages" which articulate the main front-ends to the system that users will primarily interact with, and "functional packages" which provide encapsulations of the lower-level practical operation of the system.
figure 1: package structure (click on image for enlarged version).
There are four main sub-packages in the "user packages" representing the three main components of the system at a user level: "world", "player", and "view" and the generic class from which they inherit: "user" (see figure 1). These communicate with one another on a client-server basis: the "player" is a client to the "world", and the "view" is a "client" to the "player". A "world" may contain multiple "players" and these, in turn, may be represented by multiple "views". This structure will be referred to as a WPV (World - Player - View) architecture.
This provides common functionality for the "user packages".
A "world" maintains the overall state of a game simulation. A "world" contains "entities" and "domains" (which are components in the "simulation" package). "Entities" can be animate or inanimate, such as game characters or physical objects. "Domains" provide environments in which "entities" are placed and can interact.
Interaction with a "world" is provided by a "player". There can be various types of "player", ranging from a game character to a "tourist" (someone viewing but not interacting with the game), or an administrator (who has functional control over aspects of the system). On a functional basis, the "player" acts as a client to a "world" which provides itself through a server connection.
"Views" provide representations of activity within a "world". A "view" connects to the "world" via a "player" and only represents what the "player" sees. A "player" may have multiple views representing the activity it is engaged with in whatever form the view has been developed for, such as text output or graphical animation.
These provide all the practical func tionality which makes the system work. The "user packages" are effectively encapsulations of components from the "functional packages".
This provides the objects and engines required to represent and run the simulation encapsulated by the "world". This package contains objects such the the "entity" and "domain", as well as basic physics for the simulation.
The "network" package provides communication between the WPV components. It encapsulated both client and server functionality.
The "archive" package provides data persistence, such as reading and writing information to files and databases. Thye package includes classes which represent particular type sof document used by the system, such as "profiles" for users. The two main archive formats supported by the package are XML and relational database entries.
This packages provides handlers and managers for external media types which may be required by a "view" such as 3D models or audio files.
This provides encapsulations for different forms of user interface.
This provides a set of general purpose helper classes and functions used by other packages. Abstract communication patterns such as observer and broadcaster are provided from here.
The networking system in spring-alpha enables indirect communication between the simulation world (server) and clients through parallel proxy objects on both the server and client sides.
Clients may take a variety of forms, these include: Player, View, Helper, and Admin. each type of client may perform different kinds of interaction with the simulation world. Access to particular types of information is tailored to the different types of client. Player clients may link with entities or characters within a simulation and control their movements and actions. View clients can provide graphical dsiplays of activity within a simulation. They may link to a specific object, entity or character in the simulation and display the world from that object's point of view, but have no control over the actions of that object. Helper clients provide support for distributing the simulation across several servers. A Helper client may maintain the state of a simulation world, control a section of it, or provide management support, such as logging activities, or providing database facilities. Admin clients have the ability to control the server and simulation infrastructure. They may change current settings within an active simulation, setup or change client accounts, or restrict other live clients' access (such as Player clients for example). there are certain standard fucntions built into the spring-alpha system for each of these client types. Other functions, and/or access restrictions, may be defined and loaded from a network policy document.
Typical communication patterns
Figure 9 shows a sequence of typical communication patterns between a client and server. These relate primarily to a Player client but are reasonably generic for other client types as well.
Figure 9. communication between client and server (click on image for enlarged version).
There are three main stages to the communication sequence for a typical session between a client and server:
STAGE ONE: setup
The client connects to the server, is authenticated and then registered as a particular type of client. If appropriate, the client can also link to a specific object within the simulation world (it is also possible that a client may link to and unlink from a variety of obecjts within a single session).
STAGE TWO: play
During play, or an admin session, communication is restricted to a small set of generic methods. These transfer more detailed forms of information in the form of serialised objects (message packets) between the client and server. The objects are handled by appropriate classes on either side. These system enables dynamic alteration of data handling without having to change the basic exchange system itself. Figure 1 shows action, event and chat exchanges. Action exchange enables commands to be sent to directly control an object within the simulation. Event exchanges represent events occurring withint the simulation that are broadcast to clients, and chat exchanges represent text communication between clients.
STAGE THREE: end play
The client unlinks itself from any objects within the simulation and disconnects from the server.
Message packets are objects encapsulating information that can be accessed from named fields. The current version of spring_alpha implements them as serialised Python objects, but they may also be implemented as XML documents or Java objects provided appropriate translation exists for both clients and servers. Table 1 shows a standard packet structure:
|packet||identifier for type of packet, ie. request, result, chat|
|sender||sender(s) of packet|
|recipient||recipient(s) of packet|
|method||this carries a reference to the method of handling the packet, for example: a request packet will contain a reference to some form of method returning information from the simulation|
|data||additional information carried by packet such as arguments for an action, or results of request|
The fields and structures of specific message packets can be found in the spring_alpha API in: spring_alpha.network.packets.
Custom network access restrictions and methods may be loaded from a network policy document. This can enable new methods to be loaded from scripts or modules onto a server.
A graphical client is being developed for spring_alpha using the Blender real-time engine. This will implement a custom shader/rendering routine to create graphics in the style of Chad's original drawings. This document provides a draught outline of the user interface components and their basic functionality. The overall style of the interface is simple and functional, reflecting the informatics/utilitarian style of the original drawings. Interaction is primarily through the keyboard rather than the mouse.
Figure 10. main areas (click on image for enlarged version).
The screen has two main areas: the view and the control bar. The view provides a side-on rendering of the spring_alpha world. This can be swapped to a top-down aerial view of the world. The control bar provides an input area for chat communication and scene messages.
Figure 11. control bar.
The actual content of scene messages will depend on the specific gameworld running at the time but these may be labels showing you are within a particular area of the world or messages relating to significant events in the narrative and gameplay. There is also an optional inset aerial view showing the location of the player.
Character speech is shown in text areas close the the heads of the particular character. The text may either come from a chat message sent by another player, or generated by the AI engine for an automated character. A player enters their own chat messages in the input field of the control bar. Only the speech of other charactsres is displayed in the view.
Figure 12. speech (click on image for enlarged version).
List menus provide selection between options when necessary in a game. These are very simple, 'curses'-style, menus. Highlighted options are shown in white text against red whilst the main list is black text against grey. Options can be moved between using the UP and DOWN arrow keys. The RETURN and ENTER keys can be used to select a choice.
Figure 13. list menu (click on image for complete screen view).
The plan view provides a top-down aerial view of the world. A player's position is shown by a red circle with a dot in the middle. The dot indicating the coordinate points where the player current is. Menu lists can also be used in the plan view. Character speech will scroll down the left-hand side of the screen area in a standard IRC chat format
Figure 14. plan view (click on image for enlarged version).
The inset plan within the control bar provides a smaller aerial view showing the position of the player with a white circle containing a dot.
Figure 15. inset plan (click on image for complete screen view).
At startup, the application shows a loading screen in which the view is plain white. Information messages (either relating to application activities or acting as an introduction to the game) are scrolled down the left-hand side of the screen.
Figure 16. loading screen (click on image for enlarged version).
Font developed by Ricardo Creemers from the lettering used in Chad's Evolution is Not Over Yet drawings.
The font is available in TrueType and Postscript formats: springalphafonts.tgz.