263
16
GameTuningInfrastructure
Wessam Bahnassi
Electronic Arts, Inc.
16.1Introduction
Every game has to go through a continuous cycle of tuning and tweaking during
its development. To support that, many of today’s game engines provide some
means for editing and tuning “objects” (or “entities”) and other settings in the
game world. This article provides food for thought on implementing tuning capa-
bilities in a game engine. We cover the infrastructure options available and dis-
cuss their particularities and the scenarios that would benefit from each one of
them. Finally, we conclude with case studies from a published game and a com-
mercial engine.
16.2TheNeedforTweak
Implementing a tuning system is a challenge not to be underestimated, and mak-
ing it really convenient and productive is even more challenging. Games involve
a lot of data besides textures and 3D geometry: logical data such as the move
speed of a tank, reload rate of a weapon, sun position, unit view radius, etc. Such
data is obviously better not kept in hard-coded values in the game’s executable.
As executable build times continuously increase, tuning such values would be-
come a very time-consuming task. A method for accessing, modifying, storing,
and managing such data must be put in place. This is one aspect of why editors
are needed in modern game engines.
Editors have the advantage of being able to offer powerful and convenient
user interfaces to view and modify values for the various entities and parameters
in the game. This article focuses only on the back-end facet of engine editors
264 16.GameTuningInfrastructure
within the context of tuning, as user-interface discussions are a very big topic on
their own and are outside the scope of this book.
For a while, editors had to provide only the means to modify game data and
build this data to become ready for use by the game run-time code. However, a
situation similar to executable build times has risen. Level build times have also
become increasingly lengthy, making the turnaround time of visualizing data
modifications too long and less productive. The need for a faster method for vis-
ualizing changes has thus become necessary, and a new breed of the so-called
what-you-see-is-what-you-get (WYSIWYG) editors has also become available.
However, it is important to not get caught up in industry frenzy. Indeed, not
all projects need or have the opportunity to utilize an engine with a full-scale edi-
tor. Except in the case of using a licensed engine, the game team might not have
the time to build anything but the most primitive tool to do data editing and tun-
ing. For such cases, this article also considers approaches that lack the presence
of a separate editor application.
16.3DesignConsiderations
Since the task of implementing a tuning system can be highly involved, it is im-
portant to take a step back and think about the expected goals of such a system
within the context of the situation at hand. Considering the following points
should help avoid underestimating or overshooting features for the system:
■ Acceptable turnaround time for each class of tunable parameters. This is the
time wasted between the user making the modification and seeing its effect.
■ Convenience and ease of use with regard to the target system users and fre-
quency of usage. A system that is going to be used daily should receive more
focus than a system used rarely.
■ Amount of development work involved and how intrusive code changes are
allowed to be. The engine’s code base is a primary factor in this area.
■ Potential for system reuse in other projects, or in other words, generality. For
example, is it needed to serve one game only? Or games of similar genre? Or
any game project in general?
■ Type of data to be tuned and its level of sophistication, complexity, and mul-
tiplicity (e.g., global settings, per-entity, per-level).
■ Cross-platform tuning support—certain parameters are platform-specific and
require tuning on the target platform directly.
16.4TheTuningTool 265
One additional point that was taken out from the list above is stability and
data safety. This should not be a “consideration,” but rather a strict requirement.
An editor that crashes in the middle of work is not considered a valid piece of
software.
Next, we go into detail about the available options for implementing a tuning
infrastructure in a game engine. The options are categorized into four main sec-
tions: The Tuning Tool, Data Exchange, Schema and Exposure, and Data Stor-
age. A choice from each section can be made and then mixed and matched with
choices from the other sections to finally form the definition of the tuning system
that would best serve the team’s needs. The list of considerations above should
be kept in mind when reading through the following sections in order to help
make the right decisions.
16.4TheTuningTool
The choice of the tuning tool is not limited to building an editor application from
scratch. In fact, there is good potential for reuse in this area. The four options we
discuss here range from the lowest-tech approach of using the debugger, all the
way to implementing a dedicated editor application.
UsingtheDebugger
We start with the most basic case. A game has a number of values controlling a
few aspects, like player walk speed, total health, or camera settings. As pro-
grammers who hopefully follow good coding habits, it is expected that such val-
ues are at least hard-coded in named preprocessor defines or in constants that
reflect the nature of the value, as opposed to inlining the value directly where it’s
used.
The lowest-level method of tuning such values is to first convert them to
global variables with initial values, as shown in Listing 16.1, and then run the
game. To tune a value, one can add its global variable to the debugger’s Watch
window and change it directly in there (some debuggers allow doing this without
even halting program execution).
The results are immediate, and the amount of code change is minimal. How-
ever, this is limited to people with access to a debugger. For artists and game de-
signers, this would be an issue of convenience. Furthermore, the final values
have to be noted and hard-coded again after the tuning session ends, which can
be annoying if there are many modified values or if their values are lengthy.
266 16.GameTuningInfrastructure
#define MAX_PLAYER_HEALTH 100 // This is obviously not tunable.
const float kPlayerWalkSpeed = 2.5F; // Not tunable either.
float g_CameraDistance = 15.0F; // This can be tuned at run time.
void Player::Update(bool isShot)
{
...
if (isShot)
this->health -= 5; // This is bad! Move to a named value.
...
}
Listing 16.1. Pseudo C++ code showing the proper setup for interactive global variable tuning.
UsingaConsoleWindow
A system similar to that presented by Jensen [2001] can be used to allow team
members to tune values on the fly by typing name-value pairs in a console win-
dow attached to the game (e.g., see Figure 16.1). Compared to the previous
method, a certain additional amount of coding is now necessary to implement the
console window.
If the console window is implemented inside the game, then this approach
(and the one before) can be conducted on any platform the game targets. This can
be quite valuable when tuning values particular to a certain platform (e.g., tuning
color correction or mipmap level selection). Console windows are commonly
used for debugging and cheating purposes (toggling rendering modes, hiding
characters, killing all enemies, etc.), but they could be considered a tuning tool as
well.
IntegratingwithanExistingDCC
1
Tool
Bahnassi [2004] and Woo [2007] provide good examples of DCC tool integra-
tion. This can be quite convenient for artists and level designers who spend the
majority of their time on the project modeling, texturing, and laying out levels for
the game. Instead of forcing those team members to generate assets and then wait
1
Digital content creation tool is a term used to refer to programs such as Softimage, 3DS
Max, Maya, etc.
16.4TheTuning
T
Fi
gu
the
g
for
t
this
D
leve
l
Ho
w
tim
a
T
men
and
to s
e
to t
h
ing
s
too.
co
m
De
d
Ano
wor
k
ool
u
re 16.1. Tuni
n
g
ame Quraish,
t
he pipeline t
o
approach off
e
D
CC tools c
o
l
and art exa
c
w
ever, the pr
o
a
ted.
T
here are tw
o
t
the game r
e
the other is t
o
e
nd it update
s
h
e user. In thi
s
s
o changes t
o
The storage
es the role o
f
d
icatedEdi
t
ther sophisti
k
s with the
g
n
g exposed v
a
courtesy of D
a
o
build them
e
rs them inst
a
o
me with a l
a
c
tly as one w
a
o
gramming e
f
o
methods o
f
e
nderer insid
e
o
have the to
s
about chan
g
s
venue, an e
n
o
models an
d
of tuned dat
a
f
the DCC to
o
t
orApplica
cated metho
d
g
ame. Such
a
a
riables using
t
a
r Al-
F
ikr Pub
l
in order to v
i
a
nt visualizat
i
a
rge palette
o
a
nts, thus pr
o
f
fort required
f
approachin
g
e
the DCC t
o
ol communi
c
g
es happenin
g
n
gine can go
d
textures co
u
a
(models, l
e
o
l.
tion
d
is to buil
d
a
method p
u
t
he game’s co
n
lishing.)
i
ew the resul
t
i
on, which c
a
o
f utilities th
a
o
viding an ex
c
by this tech
n
g
this option.
o
ol (possible
c
ate with the
g
in the DCC
as far as im
p
u
ld be directl
y
e
vels, and cu
s
d
a dedicate
d
u
ts total cont
r
n
sole window
.
t
s in the ga
m
a
n boost prod
u
a
t can be use
d
c
ellent tunin
g
n
ique is not t
o
One metho
d
in Autodes
k
game execut
a
tool to direc
t
p
lementing a
s
y
visualized
i
s
tom propert
i
d
editor app
r
ol and flex
i
.
(
I
mage from
m
e’s renderer,
u
ctivity.
d
to layout a
g
experience.
o
be underes-
d
is to imple-
k
Softimage),
a
ble in order
t
ly display it
s
set hot load-
i
n the game,
i
es) then be-
lication
t
hat
i
bility in the
267
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.