This preliminary document is the first try at the game design document for Dreams Eternal. It is unfinished at the moment but it is a first draft so that it can be examined.

History:

Table of Contents

Dreams and Levels
Players Dream
The players dream is basicly the main entrance point for our player. It is also the point he will often come back too in order to continue with the rest of the game. Since this dreams comes from the subconscious of the player himself so it can possibly contain many things that are comforting for the player (personal items or people that he knows).

The level should not be too nightmare like. Basicly the feeling of this level will be a bit surrealistic with very symbolic and strange things.

Areas

Goals

Inside Connections

Outside Connections

Items

Journalist Dream
The journalist dream represents the dream of the journalist that made the news item that the player saw in the first cutscene. This dream is a nightmare based on a photography theme.

You start in a very dark room with only a small button visible. This is a light-switch. When you turn on the light the rooms is lit red (it is a photographic dark room). There is a lot of rubbish in the room but nothing of that matters much. You can go outside to the rest of the flat of the journalist. The journalist is there in his nightmare. He is blind and running around wildly. When you come too close he will scratch and attack you. So be careful! You have to engage him in some conversation so that he quiets down and talks to you. He says: 'If only I 'm no more blind! I will show you, I will!' So you have to find his eyes. In the kitchen there is a fridge. If you open the fridge there is a staircase down into a strange labyrinth full of items related to photography (but larger). Some examples: a giant diaphragm as a door, pools full of chemical liquids, flash lights, photos, a giant lens, mirrors, ... The journalists eyes are on a horror like robot. You have to try to catch the robot to get the eyes. After getting the eyes you give them to the journalist. He will then show you some pictures of the building. This is the first Mental Item in order to solve the rest of the game.

Areas

Goals

Inside Connections

Outside Connections

Items

Drugged Scientist Dream
A kingdom. Not the bright cheery kind, but one composed of twisted structures, statues of demonic faces and creatures, paintings reflecting a man being dragged down into a hole by something or evil consuming that same man. The residents roaming around (possibly people in the patient's life) appear as they do in the real world at first, but when they notice an intruision (you), they morph into how the patient viewed them in the real world.. a stuck-up rich and pretty girl becomes hugely deformed, and ugley.

As you go deeper into the madness, more clues are revealed what exactly happened here. To solve the major puzzle, you must find the scientist, wake him and free him from his cage (surrounding his imprisonment are the demons, which will later be revealed to be the scientists who brought him to this madness. Before that, you'll find several versions(clones) of himself, the kings of this place, who you might have to stop. There will be puzzle-like ways to kill each of them, and doing so will probably unlock the place where you can find the patient.

Once you finally free him, and get him to realize he's still in a dream, the world changes and becomes bright and cheery, the people roaming the hallways are locked away or something. There's still a certain eeriness due to the scientist, but overall calmer. The scientist then reveals that he was the first, one of those the scientists experimented on to create their machine. When he threatened to expose them, they drugged him, which caused his dreamworld to warp into what you found it as, trapping him deep inside..

Areas

Goals

Inside Connections

Outside Connections

Items

Skeleton Plain Dream
A big infinite plain with towers here and there. To every tower there is a skeleton attached. See the concept art on the Dreams Eternal page. In this dream the person who is dreaming this is unknown (and not important to the game). This dream has two purposes depending on the scenario. The towers are arranged in a regular fashion. However there are two towers that stands out in some way. The first tower is the one you start in. This tower contains the portal back to the players dream. To distinguish this tower there is a light (with a halo) above this tower. The other tower contains the item and is different because there is a creature guarding it.
When you enter this dream you are inside one of the towers. There is an open doorway to the plain.

Areas

Goals

Inside Connections

Outside Connections

Items

Scenarios
To make the game richer there will be several alternative paths. Every alternative path is called a scenario. A scenario has a name and a number. The name indicates a scenario setting while the number indicates which of the scenario options is chosen:

Cutscenes
Cutscenes will be made by using the Crystal Space engine itself. So in many cases we'll be able to reuse the levels from the dreams for them. Here is a list of all the cutscenes that we have:

Items
In this section we summarize all the possible items to be found in the game and their effect:

Creatures
Here is a summary of all creatures and characters in the game and what they can do:

Environmental Effects
Here we describe various environmental effects that can occur in the game. Environmental effects can be local to some area (like water or draft) or occur depending on some event (a fireball for example):

Dreamer Powers
Every dreamer (the player and cooperative/non cooperative other AI based dreamers) have the capability to perform certain powers. Here is a list of all the powers in the game. The use of any of these powers decreases the mental strength of the dreamer. The ability to use one of these powers is also dependent on the mental agility of the dreamer. Every power will have an associated mental agility that is needed to be able to perform that power.

Dreamer Statistics
Every dreamer has a number of characteristics. Some are dynamic. Some are more static. Items can influence these statistics temporarily or permanently:

User Interface Specifications
In general the game should be as immersive as possible. This means that status bars, inventory slots, menu selections, ... should be either very small and non-obstrusive or else optional.

We will avoid right mouse click so that we can run on Macintosh too. But right click can be defined to some action by the player if he/she wants it. The default binding for Right click on systems that support it will be the same action as Double click.

It will be possible to bind keys to actions. That's why there are no specific keys mentioned in the text below. In general we have the following keys and their default binding:

In addition it will be possible to assign hotkeys to invoking dream powers, items in the inventory, ...

In general we have the following user interface elements:

Entity System
This is a very technical section that explains how the Dreams Eternal entity system works on both the Python and C++ side and how both sides interact with each other.

General Concepts
Every object in the game is represented by an entity. The entity system allows the Dreams Eternal game programmer to speak to game objects in a consistant manner. Examples of entities are: the player, the world itself, creatures, a candle, objects in general, mental items, ...

Every entity has a C++ representation and a Python representation. The C++ representation controls the general characteristics and attributes of every entity while the Python representation controls the behaviour.

Attached to every entity we have a list of property classes. A property class describes a specific kind of behaviour or attribute set for an entity. All the property classes together define what the entity really is. This will become clearer if we give a list of all current property classes:

This is only the beginning. More property classes will follow as the game system is further refined. The property class system is a very dynamic and flexible system which allows us to dynamically change properties of entities on the fly. It is possible to add/remove any of the above property classes at any time. This is something that is very hard to do if we were to use the traditional inheritance based entity system.

C++ Entity System
On the C++ side we basicly have two kinds of classes. Classes beginning with the 'de' prefix are classes that are only accessed from within C++ itself and not (directly) usable from within Python. Classes (or rather interfaces) that start with the 'i' prefix are meant for communication between Python and C++. In src/python/dreams.i the relation between those interfaces and Python is defined. The SWIG program reads that file and generates corresponding wrappers from that.

Note that most 'de' classes also implement the corresponding 'i' interface.

In the C++ entity system the base class for all entities is deEntity (src/entity/eentity.h). There is only one subclass which is deWorld. The reason for this is that there is special code attached to deWorld for controlling and loading the world. Aside from the world itself all other entities are just instances of deEntity. iEntity is the interface for Python.

As explained above the behaviour and appearance of every entity is controlled by the list of associated property classes. Every entity has an instance of the class dePropertyClassList (and associated interface iPropertyClassList) which controls this list of entities. This list contains property classes.

iPropertyClass is the basic interface for a property class. In addition there are also interfaces describing the specific property classes:


For example dePhysicalPClass is the implementation of the physical property class. dePhysicalPClass implements both iPropertyClass (because it is a property class) and iPhysicalPClass (because it is a physical property class).

Python Entity System
On the python side the situation is different. For every entity there is both a C++ instance of deEntity and a Python instance of BasicEntity (BasicEntity inherits from the Python version of iEntity).

As explained above the C++ side of every entity is responsible for controlling the attributes (through the property classes) of every entity. Property classes also define some basic behaviour. An example of this is the 'movable' property class. An object with this property class will automatically (by the game system in C++) be moved according to semi-realistic physics rules.

The Python side of every entity controls the rest. Every entity is created blank on the C++ side. It is the responsibility of the associated Python script to attach the needed property class instances and initialize them to the required settings.

On the Python side every entity will inherit from BasicEntity. BasicEntity controls default behaviour for all the possible events that can occur from within the game system (more on events later). An important fact here is that while we don't use inheritance on the C++ entity system but instead describe entities using property classes this is not the case for the Python entity system. Python entities inherit from super classes that control more general behaviour. For example we could make a ContainerEntity which subclasses BasicEntity and is responsible for all containers in the game (i.e. boxes, sacks, belts, ...). Every specific container can then again subclass from ContainerEntity.

Events are used to communicate from C++ to Python. Every event corresponds to a Python method in the corresponding script. Most events are actually generated by attached property classes. If you don't attach a property class generating some event then that event cannot occur. The following table lists all current events grouped by the property class by which they are generated:

More events will of course follow. This is only the beginning. Entities which inherit from BasicEntity need to implement Init. The other events have default implementations (which do nothing).