Sunteți pe pagina 1din 11

Virtual metaphysics

Tilo Wiklund - IT-Gymnasiet Örebro

IT-Gymnasiet HT/VT-07/08
Contents
1 Aim 2

2 Games and game development 2

3 Method 2
3.1 Engines/Games . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4 Delta3D 3

5 Crystal Space/CEL 4

6 Existence and Knowledge 5


6.1 Object-oriented programming . . . . . . . . . . . . . . . . . . . 5

7 Comparison? 6

8 Connecting 7

9 Discussion 9

10 Concluding remarks 10

1
1 Aim
I intend to use this text to intruduce game engines as an object of study for phi-
losophy. And, by doing this, suggest that a philosophical type of analysis can be
used to find new ways of constructing the virtual reality in which computer games
are run.

2 Games and game development


The main object of study in this text are so called game engines which, as the
name implies, drive computer games. Game engine range from simple, [rather
technical] libraries for rendering computer graphics and efficiently sending data
over a network; to complex frameworks that not only handle the technical aspects
of the game, but also help with more abstract things such as defining game logic,
that is to say the rules/procedures of the game, and what is in the world.
Even though the distinction between game logic and the more technical aspects of
the engine is not always clear, it is mainly the first that is of interest to this text.
Above all I am interested in the terms used to construct the world in which the
game is running.

3 Method
By reading the documentation provided for the two game engines I intend to iden-
tify a number of, to the engine design, central concepts. By identifying these
concepts and analysing their relationships to each other, and possible other minor
concepts, I hope to be able to make a comparison between the different engines.
By doing this comparison I hope to create a clearer picture of the metaphysical
models in these engines, and a hint of the models in computer game engines in
general.

2
3.1 Engines/Games

Initially I had a number of possible engines to analyse. Due to time and space
limitations I had to narrow it down to two, chosen to represent as wide a spectrum
of design ideas as possible. The first engine I chose was Delta3D, an open source
game engine developed mainly by the naval postgraduate school. The main reason
for choosing this engine is that it is considered very well documented. The second
engine I chose was Crystal Space combined with the CEL extension, short for
Crystal Entity Layer. CS/CEL was mainly chosen for its popularity in the open
source community, but also for a decent amount of documentation.

4 Delta3D
To understand the the design of Delta3D it is essential to understand its concept of
the Actor. An actor is essentially an acting object in the game environment, that
is to say an objected in the world that in some way affects, and/or is affected by,
its environment.
There are two other ideas closely tied to the idea of the Actor; the Actor Property
and the Actor Proxy. An actor property is quite simply a property which an actor
can have, What properties an actor can have, depends on the actor in question.
Properties can range from something as simple as the position of a box, to some-
thing much more complex, like what training a thief in a role playing game has
had.
The second concept is probably harder to grasp to most people. Each Actor has
an Actor Proxy, which is the ”lens” through which the engine sees the Actor.
More concretely, the Actor Proxy provides the engine with a way to see any Actor
simply as a set of properties.
To enable interaction between these actors the programmer uses Messages. The
in the documentation proposed way to use messages is by broadcasting them at
the request of an Actor. The actor ”chooses” to broadcast a message to notify the
environment of some event, the environment can then act upon the information
and react accordingly.
This kind of communication usually does not happen on a direct actor to actor
level, but includes at least one level of indirection. Here another two important
concepts are actualised, the Game manager and the Component. As the second
depends on the first, it will be discussed later.

3
The Game manager, to reuse the metaphor of messages as a mode of communi-
cation, works as a postal service. It dispatches the messages sent from an actor
to the right parts, including actors, of the game. Thus in its simplest form it is
just responsible for passing on messages. Things get slightly more complex when
components get into the picture.
Components act on the messages sent through a Game manager. A Game manager
keeps a list of components to be notified each time a new message is dispatched.
A component defines a set of game rules and system behaviour rather than an
individual entity in the world, in the sense that actors do.

5 Crystal Space/CEL
The CEL, and thus in our case Crystal space, revolves around the notion of the
entity. And entity is, simply put, an object; anything differentiated from the rest,
something discrete. To understand the entity one must understand two other con-
cepts from CEL, that of the property class and that of behaviour.
A property class defines a type of property that an entity can possess. Here a
property does not only mean things such as the texture or colour of an object, but
also things like the ability too sense its environment. Each entity will probably
have a number of properties, each defined through a property class, and together;
these properties define the way an entity can interact with the world.
To make use of these property classes the entity has a behaviour which defines how
the properties are interpreted. It is important to understand that the behaviour of
the entity understands property classes rather than specific properties. Two prop-
erties defined by the same property class do not have to be exactly ”the same” in
any technical sense, but must have the same interface/function, or in other words
they have to be isomorphic.
To create a communication between the behaviour and the property classes of
an entity a message passing system similar to the one in Delta3D is used. An
interesting difference here though is that CEL has messaging on two levels; intra-
and inter-entity. The internal messaging system is used by the properties and
the behaviour to communicate while inter-entity messaging is used to implement
communication between different entities.
The behaviours and properties are provided by plug-ins. A plug-in defines a num-
ber of behaviours and properties, belonging to property classes. This means that
while entities with behaviours and properties define the game world in an abstract

4
sense, the plug-ins define the technical aspects of the game. While an entity with
a behaviour define how, for example, a sense of smell is used, the plug-ins pro-
vide the definitions of the algorithms that search the surrounding environment for
smells to sense.

6 Existence and Knowledge


Before a comparison is made some of my terminology, or rather my somewhat
unorthodox usage of a number of terms, needs to be clarified.
To keep things simple, a rather basic definition of existence will be used. As
all programming is done according to some programming paradigm, and almost
exclusively in one or a few of the established ones, I will use central concepts of
the paradigm in which these game engines were developed. As it happens both of
the engines studied were written in more or less the same paradigm, namely the
class-based, object-oriented programming paradigm. This will not be a rigorous
explanation of the object-oriented paradigm, neither in its class-based or in any
other incarnation, but it will hopefully serve as an introduction to concepts vital
to rest of the text.

6.1 Object-oriented programming

Object-oriented programming is centred around the idea of an object. An object


being a combination of data and possible operations on that data. There are a
number of flavours of object-oriented programming and a lot of good literature
that introduce the different versions. In this text only the class-based, imperative
one will be introduced, quite simply because it is the paradigm according to which
both the game engines are written. The term imperative in this case means that the
objects’ data can be mutable (not static/constant). That is to say; the data carried
by an object can change while the game is running. The idea of a class is slightly
more complicated.
A class defines a type (class) of objects that share a similar structure. It is an
abstraction of concrete objects in the running programme. When writing an class-
based object oriented system, one would solve the problem of representing ratio-
nal numbers by creating the abstract idea of a rational number, its class, and a
number of rational numbers of the class, the objects.

5
The idea of inheritance is also central to a lot of object oriented systems. In-
heritance proposes that each class can have base and/or child classes. The base
classes can be though of as abstractions or subsets of the class in question, while
child classes can be thought of as supersets or realisations. For example, the class
of natural numbers would be a base class of rational number (all natural numbers
can be described as rational but not the other way around) and the class of com-
plex numbers would be a child class of rational numbers (all rational numbers can
be described as complex but not vice verse).
When studying these engines I have used a definition of existence that Existence,
the way I will use it, is something that is defined natively, that is not reducible to
something smaller within the programming paradigm and is not an abstraction of
one or more other things. Basically what this means is that existence is anything
that has been defined through an object.

7 Comparison?
Perhaps most striking similarity between the two engines is that they both con-
stitute/construct the game world in terms of discrete objects in an environment.
Both engines define a concept of some kind of object that is distinct and separate
from other objects. These objects sense and react to change in its environment in
some more or less predefined ways and are able tocommunicate their reactions.
Even though the engines might seem very similar at first, considerable differences
appear when one considers how these objects are represented and positioned in
relation to other concepts in the game engine. In Delta3D these objects are repre-
sented by the actor, while in CS/CEL it is implemented though the entity.
One obvious but interesting observation is that the actor is, in a sense, layered.
An upper layer, constituted by the actor proxy and the actor property, presents
the actor as a coherent/distinct object with properties. This is the way an actor is
exposed to the high level game logic. This upper layer can be said to abstract the
lower layer, consiting of components handling for example graphics, sound and
networking.
In CS/CEL a similar layering is apperent, although it might be less obvious. The
entity has a clear structure; it is built from behaviour and properties. This structure
is known from the part of the engine that implements game logic. What is hidden
here is the implementation of the properties.
Another interesting similarity is that both engines use a message dispatching sys-

6
tem for communication, although they use it in slightly different ways. Delta3Ds
actors use messages to notify the world of some, often to the actor internal, event.
The messages are not only used to communicate with other entities, but also to
implement game logic through the component.
CS/CEL uses messages in a way similar to Delta3D when communicating be-
tween entities, but lacks any concept similar to Delta3D’s components. On the
other hand CS/CEL uses message passing on a level that is, in a sense, nonexis-
tent in Delta3D, namely] inside the individual entities.
It is also worth noting the differences between what Delta3D and CEL call prop-
erties. While Delta3D uses properties to summarise an actor CS/CEL uses its
properties to construct an entity, and define what abilities or functions it has. So
one could say that while Delta3D would describe a red curtain as ”an actor with
a colour property that is red”, CS/CEL would describe it as ”an entity with the
ability to have a (red) colour”.

8 Connecting
The construction of reality in terms of discrete objects and their properties is by
no means exclusive to this context, nor is it a very new idea. It, as so often is the
case, goes all the way back to the ancient Greeks; predominantly Socrates, Plato
and Aristotle. In the context of philosophy this discrete object is often referred
to as substance. This idea has been developed further by a number of, mainly
western, philosophers throughout history; some of whom will be discussed later.
In the context of philosophy this substance is often spoken about as what is left
when all particularities are removed, that which makes something an object. Plato
constitutes the world in terms of universal forms of which there are material in-
stances, or manifestations. Plato’s ideas might have been suitable for discussing
the philosophical foundations of class based object-oriented programming, since
they seem to bear many similarities. Avoiding the concept of universals, Aristotle
uses other concepts to construct reality. Due to the fact that both engines seemed
to lack the concept of a universal, I considered Aristotle a more appropriate start-
ing point than Socrates and Plato.
Aristotle speaks about the substance in terms of form and matter. Matter be-
ing what constitutes the substance, the so called substratum, and form being the
substance as a coherent entity. This idea fits rather well with the way Delta3D
constitutes its worlds; the proxy presents the actor as a coherent entity, by stating

7
it as something discrete with properties. Identifying a substratum in Delta3D’s
design is slightly more difficult, as there are two different ideas competing for that
position. Firstly there are the properties and secondly there are the underlying
technical components for sound, graphics, networking e.t.c. both of which could
be said to constitute the actor.
Many of Aristotle’s ideas can be generalised into his concept of potentiality and
actuality. Matter, for example, can be thought of the potential substance. Another
idea of Aristotle’s that is often generalised into the idea of potentiality/actuality is
his notion of the end. An end is, simply put, a goal for a substance; the state which
it tries to reach. Albeit both the presented ideas can be thought of as part of the
idea of potentiality and actuality, I will treat them as separate. This because the
second idea is easily comparable with CEL’s concept of a behaviour, which could
be said to make the entity think or maybe rather; keep it going towards a goal.
A philosopher who later reintroduced the idea of substance and form into phi-
losophy was Gottfried Leibniz. He divides reality into two, what refers to as,
spheres; the universe on a metaphysical level and on a phenomenal level. On the
metaphysical level, there is the complete concept; an idea that is probably best
summarised as an object as everything that can be said about it, without which
the whole concept is lost, in a sense a; complete, logical representation of some-
thing . A substance, to Leibniz, is the way weperceive these total ideas; which
can only be perceived in their totality by his idea of god. Also, the substances we
experience are compounds of these indivisible individual substances. It is on the
phenomenal level, the perceived level of substances, that we construct concepts
such as causality, extension in time and space and the idea of something having
properties1 .
If we apply Leibniz’s ideas to Delta3D’s design we can find a number of dif-
ferences from when we applied Aristotles’. The idea of a coherent substance
remains, and can be applied in more or less the same way. The actor proxy can
still be seen as mirroring the substance by making the actor coherent. It is when
Leibniz’s ideas are applied to the concept of the actor that things become interest-
ing. This actor is, as discussed earlier, in a sense unknown to us, and is constituted
by interdependent components for handling graphics, sound, networking and the
like. All the actors become similar first when they are presented through actor
proxies that present them as entities (substances) with properties.
To apply Leibniz’s philosophy to CEL, one has to take another angle. Leibinz’s
idea that concepts such as extension are, in a sense, explanatory devices used to
explain the universe, fits rather well with CELs design. If we choose to see CELs
1
Observe that it is not the logical concept of predicate that isreferred to.

8
entities as, at least in a very general sense, sentient (they have a behaviour) and
consider them as having the ability to experience the world, then CELs properties
appear rather similar to Leibniz’s idea of these explanatory devices. The entities
thus become; sentient substances that explain the complex reality of the property
implementation, that is to say, the part of the engine that handles graphics, sound
and networking.
It is interesting to note here that I have discussed both engines as extending from
some point of observation to some point of hidden software implementation of
things like graphics rendering. When one considers this and looks at the design of
both engines, they could be said to have very similar but, in lack of better words,
inverted conceptions of reality. CEL has a clearly defined thinking entity that
experiences a hidden reality, while Delta3D has a clearly defined world of actors,
who are constituted by these hidden pieces of computer reality.

9 Discussion
When studying the two engines we found a number of similarities and a number
of differences. Even though all these would have been interesting objects of study,
one in particular got stuck in my mind, namely that both engines model their world
in terms of more or less clearly defined objects that expose some kind of properties
that differentiate them from the rest. This highlights a very basic assumption on
the nature on how reality is to be constructed, one that adds interesting limitations
on what kinds of worlds can easily be constructed within the ”languages” defined
by these engines.
Modern role playing games have to, for instance, model complex social interaction
not only between the player and citizens in different towns, but also between the
towns or even different countries. While the design provided by these engines
might be well suited for explaining the visual/aural experience the player has of
the world, the question one must ask is if thisalmost physical method of modelling
reality is suited for creating these kinds of games, or if one needs to allow new
ways to create the game world.
One can also find influences from contexts outside of philosophy. A lot of games
show similarities to movies and drama, so one approach could be to construct the
virtual reality in terms of scenes, props, storyline and actors2 .
2
Actors notnecessarily in the sense Delta3D presents them

9
The fact that the model of reality discussed works decently for modelling experi-
ence does not mean that this is not also an area where experimentation could be
done. One could, for example, try applying a phenomenological approach, and
discuss what implications such an approach has/would have. One could also use
other approaches to analyse the game engines. One could ask what conclusions
someone following a more deconstructive, discourse theoretical or maybe even
Marxist approach would reach.

10 Concluding remarks
By giving an example how game engines are used to model realities, I hope to
have shown why game engines can be an interesting object of study for those
interested in philosophy. I also hope to have shown how game engines reactualise
seemingly archaic philosophical models for explaining reality by trying them out
in a universe where they are, in lack of a better term, true. I also hope to have
risen interest in the study of philosophy for those involved in game and game
engine development, by showing how philosophy can be used to find radically
new models in which to develop game worlds.

10

S-ar putea să vă placă și