1. Defining the Game and Customization

Defining the Game

The intention is to create a game for personal computers based on the interaction of a single player with a virtual world environment in which they control the structure of settlements, the transportation of goods and individuals and the provision of other services. By its nature the game will lack a defined goal, which will instead be set by the player. This is a concept that has been exploited in older games such as the SimCity franchise to great effect.

In a sense, this game would be a refresh of that franchise, but with the ability to exploit an understanding of how players view such games and want to interact with them. The lack of a clear endpoint for games such as this is both a strength and a weakness. The lack of goal means that the game can be sufficiently compelling to be endlessly playable, but the potential for repetition and the accompanying lack of challenge and reward mean that the game needs to be able to adapt to remain fresh.

Providing such extensive and endless playability right out-of-the-box is difficult to the point of impossibility, simply because the possibilities are finite. The solution to this is in allowing players to directly customise the game: they should be able to design new structures, vehicles, etc. and also define their behaviour. It essential that the extent of possible customisation and the means by which it is implemented be built into the simulation early on.

The initial target platform will be Windows, simply for the practical reason that this is the development platform. The intention is to ultimately release this for all major computer operating systems and for the Macintosh platform. To that end, the technical choices must not preclude compilation of the code for these platforms.

In-Game Objects and Customisation

A city simulation requires simulation of several categories of object. These are:

• Buildings – including passive buildings that provide no specific service to the application, and the more active buildings such as police or fire stations that may have an extensive influence.
• Transport infrastructure – roads, railway networks, etc. as well as signal nodes and stations
• Vehicles – there are multiple types of vehicle, but the user should not be limited by developer choices, so scope must exist to allow exotic vehicles, including multi-terrain vehicles, to be defined by external users.
• People – for realistic simulation, the behaviour of individuals must be included. There are technical difficulties related to this, which will be discussed below

There are some commonalities between these categories, which is useful from a technical perspective. Buildings, infrastructure and vehicles can all have possession of vehicles and people, for example.

It has been fairly common within city-building gaming communities to view the graphical representation of the object as the most fundamental property. In reality, the graphics should be a property of the object in order to allow us to swap out or alter graphics for an otherwise identical object. By separating the graphical interface from the simulation in this way, many of the common complaints of existing products can be removed.

Customization

The intention is to allow external development of objects by defining their properties and behaviours using a combination of property files and scripts. The scripting language of choice will be Lua, details of which can be found here. This is a good scripting language, fit for the purpose of mathematically defining the behaviour of objects within the simulation, which can be made as complex as the language allows. The scripts will be able to influence the behaviour of objects by interacting with a specific interface between the simulation code and the script. In this, the Lua script developed externally will be expected to expose certain functions, and the simulation engine will in turn expose functions that scripts can call to get information about the simulation.

As a non-binding example, imagine we are defining a residential building. On a particular update cycle, the simulation will want to calculate the demand for that building. An external developer can define a Lua script to calculate that demand based on the building that they wish to produce. However, that demand may also be dependent on other factors such as local crime, the age of the building, etc. The simulation will therefore expose a function called GetProperty(propertyName) to the scripting system so that developers/modders can access this data without any additional work on their part.

Some features will not be modifiable by external developers in the initial version of the simulation engine. These are features that a) rely on many of the internal structures of the engine b) are called extremely often and c) are fairly complex. This means that using the proposed scripting language would negatively impact on the performance of the system. For the moment, this excludes aspects such as path-planning that are highly structure-dependent and performance-critical.

In order to implement these as modifiable structures, it would probably be best to implement a plug-in architecture, allowing more technically-minded modders to produce actual compiled machine code to replace these functions. This will not be implemented fully in the first version, but the code will be structured so as not to prevent its later implementation.

Next post: All about simulating the population of our game world to balance realism against performance...

Please comment on the above - these are only drafts and can be changed!

Fred