Sie sind auf Seite 1von 68

Asset Management in Game

Development

Klemens Wallner

September 7, 2001
ii
Eidesstattliche Erklärung

Ich erkläre, dass ich die Diplomarbeit selbstständig verfasst, andere als die angegebenen
Quellen und Hilfsmittel nicht verwendet und mich auch sonst keiner unerlaubten Hilfe bedient
habe.

Ort, im Monat Jahr Name


iv
ABSTRACT v

Abstract

Since the upcome of computer games in the early Seventies computers improved dramatically
and computer game developers are able to put more and more artwork in their games.

Games with better graphical ability look more appealing to the customer and are therefore
better sold. The amount of audiovisual data included in computer games is only limited by
the available hardware.

To produce this artwork game development companies need an increasing number of artists.
These artists have to coordinate their work, which leads to various problems.

This thesis contains an analysis of these problems and presents a customized solution for the
JoWooD Game Development Studio in Ebensee (Austria).
vi
KURZFASSUNG vii

Kurzfassung

Seit dem Aufkommen der Computerspiele in den frühen siebziger Jahren hat sich die Leistung
der Computer drastisch verbessert. Spieleentwickler können daher immer mehr Grafiken in
ihre Spiele einbauen.

Grafisch hochwertigere Spiele sprechen den Anwender mehr an und verkaufen sich daher
besser. Die Anzahl an audiovisuellen Daten in Computerspielen ist nur durch die vorhandene
Hardware begrenzt.

Um diese Grafiken zu produzieren, benötigen Spielefirmen eine steigende Anzahl von Grafi-
kern. Die Grafiker müssen ihre Arbeit koordinieren, was zu verschiedenen (Software-) Pro-
blemen führt.

Diese Diplomarbeit analysiert jene Probleme und beschreibt eine spezifische Lösung für die
Firma JoWooD in Ebensee (Österreich).
viii
ACKNOWLEDGEMENTS ix

Acknowledgements

I want to thank my supervisor at JoWooD, Dipl.-Ing. Jari Saarhelo, for his contribution
towards my technical education and for giving me the opportunity to take a close look into
game development. In addition I want to thank all developers at JoWooD, Ebensee, who
helped me understanding the most difficult problems in the development of modern computer
games.

Of course, I want to thank the staff of the Polytechnical University of Software Engineering,
Hagenberg (Austria), especially my teacher Dipl.-Ing. Dr. Herwig Mayr, for making all this
possible.

Special thanks go to Thomas Abrahamson and Stephanie Pui-Mun Law for allowing me to
use their artwork as example data for presentations and screenshots.

Finally I want to thank my family and my friends who were encouraging me during writing
this thesis and for their understanding of my sometimes stressed behavior in the past half
year.

Klemens Wallner
x ACKNOWLEDGEMENTS
Contents

1 Introduction 1
1.1 Artwork in Game Development History . . . . . . . . . . . . . . . . . . . . . 1
1.2 Basic Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Game Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.3 GFX Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Configuration Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Localization Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.3 Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Present Workflow at JoWooD . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Artwork Production Chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Solution: Asset Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Requirements 7
2.1 Management of Huge and Numerous Files . . . . . . . . . . . . . . . . . . . . 7
2.2 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Version Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 User Friendliness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.9 Portability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.10 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Existing Solutions 11
3.1 Microsoft SourceSafe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 NxN Alienbrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Merant PVCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 The Need to Develop Our Own Solution . . . . . . . . . . . . . . . . . . . . . 13

4 System Design 15
4.1 Operating System and Tool Selection . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 System Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Interfaces to Other Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Handling of Multiple Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

xi
xii CONTENTS

4.5 Naming Convention and Templates . . . . . . . . . . . . . . . . . . . . . . . . 16


4.6 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1 Folder Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.2 Asset List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.3 Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.4 Stand-alone Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.5 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6.5.1 Folder Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.5.2 Asset Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.6.6 Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.6.1 Add Folder Dialog . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.6.2 Add Asset Dialog . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6.6.3 Template Browser Dialog . . . . . . . . . . . . . . . . . . . . 21
4.6.6.4 Add Template Dialog . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Entity Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7.1 Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7.2 AssetData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7.3 AssetStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.7.4 AssetType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7.5 Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.7.6 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Implementation 27
5.1 System Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1 Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2 Storing Huge Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.3 Storing Hierarchial Tree Structures . . . . . . . . . . . . . . . . . . . . 28
5.2.4 Database Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.4.1 Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.4.2 AssetData . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.4.3 AssetStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.4.4 AssetType . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.4.5 Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.4.6 Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.1 Client Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.2 Dialog Screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Parallel Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 Managing Huge Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6.1 CAssetViewerCtrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.6.2 CFolderTreeCtrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.3 CFolderTreeItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.4 CAssetListCtrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.5 CAssetListItem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.6 CThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6.7 CThreadQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
CONTENTS xiii

5.6.8 CTransaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.9 CCheckInTransaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.6.10 CCheckOutTransaction . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Testing and Evaluation 39


6.1 Validation Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Example 43
7.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Step 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7 Step 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8 Software Development Process 47


8.1 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.5 Testing and Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

9 Conclusion 49
9.1 Goal and Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2 Possible Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2.1 Asset Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2.2 Workflow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.2.3 Branching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.3 Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Literature 51
xiv CONTENTS
List of Figures

1.1 Project Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


1.2 Graphic Production Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.1 Sketch of Generic Client Module . . . . . . . . . . . . . . . . . . . . . . . . . 17


4.2 Sketch of Stand-alone Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Sketch of Add Folder Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Sketch of Add Asset Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Sketch of Template Browser Dialog . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6 Sketch of Add Template Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Entity Relationship Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8 GFX Tree Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Gorn Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


5.2 Stand-alone Client Screenshot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Stand-alone Client Screenshot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 ActiveX Component Screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5 Add Folder Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6 Add Asset Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.7 Class Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.1 Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.1 Example Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43


7.2 Example Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.3 Example Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Example Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.5 Example Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.6 Example Step 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.7 Example Step 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

xv
xvi LIST OF FIGURES
List of Tables

3.1 Overview of Existing Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.1 Performance Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

xvii
Chapter 1

Introduction

1.1 Artwork in Game Development History

In the early seventies the arcade game industry started, with games like Pong — and Pacman —,
a world-wide boom which initiated the pioneer time of the console era (e.g. Atari VCS 2600,
Spectrum and Nintendo) [Sawyer et al., 1998]. In these times games consisted of only a small
amount of graphic files, because computers were slow and had not much memory. With time,
computer hardware improved and so game developers added more and more artwork to their
computer games. Modern games like Age of Empires II: The Age of Kings — consist of more
than 40000 graphic files, sounds and other artwork [Marselas, 2000]. Another example is
Raven Software’s Soldiers of Fortune — which has more than 5000 textures in the final game
[Biessman and Johnson, 2000]. All in all we can say that the amount of artwork in computer
game development has increased dramatically since its beginning.

1.2 Basic Notions

1.2.1 Asset

In terms of computer game development an asset is a large block of data that may contain
almost any kind of information. Graphic files, sound files, or digital videos are typical types
of assets.

1.2.2 Game Objects

Objects that are part of the game and have therefore different values which indicate their
state are called game objects. Typical game objectes would be cars, buildings, or trees. Each
object has special properties; a car for example may have a maximum speed, a size and a
graphical representation. Programmers nowadays typically use object oriented programming
to model these game objects. Consequently the game objects are structured hierarchically
to make it easier to implement their classes. For example a “Shop” will be derived from
“Building” and will therefore inherit all its properties [Fischl, 2001].

1
2 CHAPTER 1. INTRODUCTION

1.2.3 GFX Tree

A GFX tree is a file-based repository used to store assets on a central network drive. The
folder structure in such a tree often reflects the hierarchy of the game objects created by
the designers. When using such a directory it is mandatory that all developers use the same
naming convention to avoid duplicate or unclear filenames.

1.3 Project Environment

The JoWooD Game Development Studio in Ebensee employs currently eight artists, four
game programmers, three testers, one producer, and one designer. They created simulation
games like Traffic Giant — and Industry Giant —.

The computer game market is a hard competition and keeping up to release dates is, as in
every software development project, an important but extremely tough goal. To catch on
with other – even bigger – game development companies, JoWooD is always under pressure
to reduce development time to be able to release games earlier. Out of this reason Johannes
Schilcher, chief technology officer at JoWooD, decided that a set of tools is needed to make
the development of further games more efficient. These tools should assist the developers in
reducing several time-consuming tasks to a minimum.

These tools are the Configuration Editor, developed by Andreas Fischl (for more information
see [Fischl, 2001]), the Localization Tool, and the Asset Manager (described in this thesis).
Figure 1.3 shows how the different tools work together.

1.3.1 Configuration Editor

The configuration editor enables designers to create and edit the whole hierarchy of game
objects of different games. Each version of each game can be configured independently. With
the configuration editor the designer can edit any object in the game by assigning properties
to them which can then be given explicit values. An example for such a property could be
the cost of a car. Game objects can be structured hierarchically, which gives the designer the
option to derive an object from another one so that it gets all its properties automatically.
For example the designer could derive “convertible” and “van” from “car”. When he adds the
property “has airbag” in “car” with a value of “true”, all objects derived from “car” inherit
this property and have, therefore, now airbags. As graphical representations of objects are
typical properties of visible game objects, the configuration editor has to be able to access
the assets in the asset management system and link these assets as properties.
1.3. PROJECT ENVIRONMENT 3

1.3.2 Localization Tool

The localization tool exchanges all texts with texts in another language. This is needed when
creating game versions for foreign markets. The localization tool already exists at JoWooD.

1.3.3 Asset Manager

The asset manager is the system whose development is described in this thesis. Its purpose is
to help the developers to control the huge amount of assets and to avoid the current problems
with artwork versioning described in Section 1.5.

Figure 1.1: Project Environment


4 CHAPTER 1. INTRODUCTION

1.4 Present Workflow at JoWooD

When a new game is created the designer makes a list of game objects that have to be
produced. This list often changes a lot during development. Each time a new game object
is added, graphics have to be created for it. The games produced at JoWooD in Ebensee
represent the game world in an isometric perspective. Therefore all graphics of game objects
are created as 3D models with 3ds max — and are rendered afterwards from an isometric
perspective. The newly created pictures are then cut in Adobe Photoshop — to an appropriate
tile size and transparency is added. Then the graphics are included in a test version of the
game by the programmers. Working versions are reviewed by the producer and designer.
After a working version of the game is completed it is checked by the testers. In this five step
production chain every actor is allowed to send the graphics back to the previous one. This
can happen in many cases (e.g.: the 3D model was rendered from a too near perspective and
is therefore too big; the graphic is too big to be handled efficiently by the graphic engine;
it looks not well in the game and has to be colored differently or the 3D model has to be
changed). The final graphics which are in the game were produced and evaluated frequently
in more than a dozen steps.

Figure 1.2: Graphic Production Chain


1.5. ARTWORK PRODUCTION CHAOS 5

1.5 Artwork Production Chaos

Because hardware evolved quickly in the last years, the amount of assets that can be handled
by the computer has grown dramatically. To fit user needs game development companies
hired more artists to serve the players with tons of different audio-visual material. Due to
this reason managing the large amount of files became a problem. In earlier times, when
there were only few artists in a game development team, organizing resource files and other
artwork was not that much of a problem because every artist knew which material he had
created and where he had put it.
Today there are typically more than ten artists in a game development team and files are
spread over local hard drives and network shares. Locating the files becomes increasingly
difficult, especially when a developer has to produce so much art that he/she starts to forget
which files he/she has already created. When a file is located on a network share, it often
happens that more than one artist make changes on it simultaneously. A file system does
not prevent such access and so the last change is permanent and overwrites the changes of
all previous users. This results in a permanent loss of work and time. In a file system, when
a file is overwritten by a new version, the change cannot be made undone. Older versions
can only be restored by searching for backups of this file. If you need a further version of a
file it can become quite hard to recover it. So files are lost, overwritten, or available in an
incorrect version.

1.6 Solution: Asset Management

The problems addressed in the previous section can be solved by an asset management
software system. There are lots of different change control packages for source code, but only
a few that can handle bigger files as well. In Chapter 3 different existing solutions will be
compared and evaluated with respect to our specific requirements.
6 CHAPTER 1. INTRODUCTION
Chapter 2

Requirements

2.1 Management of Huge and Numerous Files

The eight artists at the JoWooD Game Development Studio in Ebensee produce sixty thou-
sand to eighty thousand game and production assets for each game. These files may vary
from some kilobytes to more than a hundred megabytes in size. This amount of data has
to be stored on a central server. The data must be available and consistent at any time,
even after a system crash. Therefore it is necessary to frequently make backups of this data.
There must be a fast and easy way to save all the data on a backup medium. Searching,
renaming, and deleting of files must be possible.

2.2 Access Control

Access to the files has to be restricted to registered users in order to avoid unlegitimated
changes. Files should not be overwritten by different users working on the same file, thus
only one person should be allowed to work on a specific file simultaneously. Deleting of a file
may be allowed only for the user who created it. Erasing a folder must not be possible as
long as there are any files in it. This way it can be prevented that users accidentally delete
the work of others.

2.3 Version Control

If the content of a file has changed in a standard file system, the old content is overwritten.
This makes sense in a file system because in most cases the old data is not needed any more.
If a file is changed multiple times during production, it may be necessary to undo changes
even after the file was saved. Especially in game development artwork is modified several
times by different artists before it is put into the final release. Consequently, all versions have
to be available at any time. Therefore it is essential to put all files under version control.

7
8 CHAPTER 2. REQUIREMENTS

2.4 User Friendliness

The graphical user interface should be intuitive, fast, and easy to use. There should be no
need to explain the artists how to use it. The best solution would be a user interface that is
similar to one they already use (like Microsoft Explorer — or ACDSee —).
The installation of the asset management should be done by an installation program so that
the artists are able to install it without advice.
An artist often edits a huge amount of files simultaneously (e.g. picture series for an animation
or video). Therefore it is necessary that he/she is able to add, store and retrieve multiple
files in one step.

2.5 Integration

During editing, files are typically read from and written to a file system. A file system
does not meet the requirements stated in Sections 2.2 and 2.3 so copying files from the
file system into the asset management and back is necessary. Getting files from the asset
management and putting them back into it should be possible from the used application.
Today’s artwork production applications like Adobe Photoshop — and 3ds max — provide the
possibility to integrate plug-ins that encapsulate this functionality.

2.6 Reliability

For a fast and stable workflow it is important that all used software systems work correctly
nearly 100% of the time. It is necessary that the users can rely on the system so that their
work is not interrupted by software crashes or data losses. This particularly holds for a
software configuration and versioning system.

2.7 Flexibility

It should be possible to use the program for any forseeable further development both by
JoWooD and other studios.

2.8 Performance

Lots of files will be stored in the asset management system. It is of importance that this does
not take too much time. So the usage of the system should be transparent to the normal
workflow of the artists. It is sufficient when the transfer speed is similar to file system access
on a network drive.
2.9. PORTABILITY 9

2.9 Portability

The asset management system will only be used on Microsoft Windows — platforms and does
not need to be portable to any other operating systems.

2.10 Maintenance

The product will be maintained by the programmers at JoWooD, Ebensee. For this reason
only programming languages and libraries can be used which are available and well known
to them. For the same reason the programmers will have to be familiar with all third party
software that is used.
10 CHAPTER 2. REQUIREMENTS
Chapter 3

Existing Solutions

3.1 Microsoft SourceSafe


The Microsoft Visual SourceSafe 6.0 version control system is the latest
edition of Microsoft’s award-winning version control system for managing
software and Web site development. Fully integrated with the Visual Basic,
Visual C++, Visual J++, Visual InterDev, and Visual FoxPro development
environments, as well as with Microsoft Office applications, it provides easy-
to-use, project-oriented version control [Microsoft, 2001].

Microsoft SourceSafe is one of the most frequently used source code version control man-
agement solutions. It is included in Microsoft Visual Studio and is integrated in Visual
C++. One of its best features is the really user-friendly interface. Its worst disadvantage is
its file-based storage which leads to some terrible problems: Its performance and consistency
problems with big files lead to long maintenance and recovery times. Its repository has a size
limit of four gigabytes which is acceptable for source code but ridiculously low when talking
about assets. It uses delta compression what works well on uncompressed files. The delta
compression finds out the differences (delta) between the new version and the old one. This
delta is generally smaller (in the worst case exactly the same size) than the bigger version.
Especially when editing source code little changes are often made and so delta compression
saves a lot of space. Most assets are already in a compressed format (e.g.: jpeg, mpeg), which
makes delta compression ineffective and slow.

11
12 CHAPTER 3. EXISTING SOLUTIONS

3.2 NxN Alienbrain


Alienbrain is a client/server solution for digital media management and team
collaboration in computer game projects. It combines file management, ver-
sion control, process automation and project tracking facilities to improve the
productivity, security and transparency of content development, at a fraction
of the cost of in-house solutions. Alienbrain allows artists, level designers,
programmers and project managers to work together from a secure central
database [NxN, 2001].

Alienbrain is a commercial asset management solution that is widely used on the game
developer market. Lots of big game developer studios like Infogrames, Electronic Arts, Sony
Online Entertainment, Sega and Kalisto use Alienbrain. As it was planned as an asset man-
agement system right from the start, it has some advantages over most other change control
solutions which mostly come from the source code version control sector. Alienbrain’s best
features are its seamless integration in the most common development tools like: 3ds max,
Photoshop, Maya, Visual Studio and of course Windows Explorer. For special in-house tools
programmers can implement their own integration with the included software development
kit (SDK). Alienbrain uses a relational database to store the data which has the advantage
that security, backup, and recovery become relatively easy tasks. However, there are two dis-
advantages which have to be mentioned. The SDKs large application programming interface
(API) may be overwhelming and writing an integration for a proprietory development tool
will need a detailed study of the API and might therefore take quite a long time. The price
of Alienbrain is also relatively high. For a twenty head development team, fifty thousand
dollars is a sum that must be considered. Erik Simon of JoWooD, Ebensee, had previously
worked for BlueByte where he used Alienbrain for some time. He reported some database
problems which caused the team a lot of time for maintenance and recovery.

3.3 Merant PVCS


MERANT PVCS is the industry standard enterprise change manager. PVCS
is unique with its 3D approach to change management. The Broadest Cover-
age of digital assets, Unsurpassed Scalability, and End-to-End Change Man-
agement combine to create the most comprehensive change management plat-
form in the market today [Merant, 2001].

Merant PVCS has similar shortcomings as SourceSafe. It is a good tool for managing source
code but has problems with big files (bigger than about ten megabytes) and even with some
types of Visual C++ projects. There is no integration in any development tool besides Visual
Studio. Its poor graphical user interface (GUI) is its severest disadvantage.
3.4. OVERVIEW 13

3.4 Overview

Table 3.1 summarizes the characteristics of the presented existing solutions.

SourceSafe Alienbrain PVCS


Company Microsoft NxN Merant
Designed for Source code Assets Source code
Integration Visual Studio Visual Studio, Visual Studio
Photoshop,
Maya,
Windows Explorer,
3ds max
Performance Slow with big files Acceptable Slow with big files
Repository File-based Relational DB Proprietary DB
GUI Easy-to-use Acceptable Not friendly or intuitive
API Yes Yes, maybe too big Yes
Known Problems 4GB size limit DB errors Visual C++ project bugs
Price (for 20 users) $10,000 $54,000 $16,000

Table 3.1: Overview of Existing Solutions

3.5 The Need to Develop Our Own Solution

None of the existing solutions satisfies all requirements. Therefore, Johann Schilcher, chief
technology officer at JoWooD, decided that a custom solution, which meets all requirements
perfectly, has to be implemented in-house.
14 CHAPTER 3. EXISTING SOLUTIONS
Chapter 4

System Design

This chapter provides an overview of the system’s functionality, its different parts, and how
they work together.

4.1 Operating System and Tool Selection

All the artists at JoWooD in Ebensee use Microsoft Windows —, hence the front-end is im-
plemented for this platform. The source code of the clients has to be maintained by the
programmers at JoWooD (as defined in Section 2.10). The front-end is implemented using
Microsoft Visual C++ — and MFC (Microsoft Foundation Classes —) because the program-
mers are familiar with this library.

4.2 System Segmentation

The assets the artists create have to be stored at a central point where all team members can
access them according to their access privileges. For this reason a central server is neccessary.
The security, stability, and consistancy needed can be easily achieved by using a commercial
database. Access to the data on the server is possible through different clients. There have
to be at least three different types of clients: A stand-alone version, a Photoshop plug-in and
a 3ds max plug-in. Additionally the client has to be included in the JoWooD Configuration
Manager [Fischl, 2001] which will use it in a view-only mode. For this reason a generic client
module has to be created and encapsulated in a component which can then be used by the
different clients.

15
16 CHAPTER 4. SYSTEM DESIGN

4.3 Interfaces to Other Modules

The generic client module has three methods which can be called by the program it is
embedded in.

GetFolderMenu()
The different clients must have their own program menus, although the menus which
contain the specific functionalities are encapsulated in the generic client module. They
have to be imported from there and then added to the client’s menu. The GetFolder-
Menu() function returns the folder menu, described in Section 4.6.5.1, to the caller.

GetAssetMenu()
The GetAssetMenu() function is similar to the GetFolderMenu() function, but returns
the asset menu, described in Section 4.6.5.2, to the caller.

SetEditMode(int mode)
The Game Configuration System, which also uses the module, is only allowed to view
the folder structure and the assets but is not allowed to do any changes on them. For
this purpose the module needs a method to be enabled or disabled for editing. Valid
values for “mode” are VIEWONLY or EDIT.

4.4 Handling of Multiple Files

Many production steps are performed on lots of different files simultaneously (like blurring
images or changing brightness or contrast). So one of the most important features is the
possibility to perform transactions on multiple files at once. This means it is possible to
check in, check out, add, and delete any number of selected files or a whole folder even
recursively with all its subfolders.

4.5 Naming Convention and Templates

To avoid duplicate names the game developers at JoWooD use naming shemes which have to
be followed by the artists when creating assets for the game. This naming conventions help
to identify files by name and to find files inside the huge GFX tree containing all the assets.
Most of the images created at JoWooD, Ebensee, are pictures of 3D objects. The names of
these pictures are mostly followed by a rotation angle. In some cases there additionally is the
number of the picture in an animation added. A train for example has animated smoke and
turning wheels. The reason for such a naming sheme is not only that files are easier found
and uniquely identified but a good naming convention makes it easier to create an algorithm
which loads the files by name.
Occasionally, it happens that artists give incorrect names to files, which causes difficulties
and delays. To avoid such incorrect names the system has to check the naming conventions.
This is in practice rather difficult because the naming depends on the object which is to be
modelled. It is necessary to know the number of rotations and/or pictures per animation of
the object. Often objects have the same definition because they are similar, which makes the
4.6. USER INTERFACE 17

use of templates interesting (for instance, cars always have sixteen rotations). So if a user
tries to finalize a folder that has a car template assigned to it, the system checks whether
there are sixteen files inside the folder that are named correctly.

4.6 User Interface

In order to create a good GUI it is essential that all users intuitively know how to use it,
without any explanation. As a consequence GUI prototypes were created to give the users
a better feeling of how the user interface might look like. These prototypes were created in
Java with NetBeans — because it is a free, fast, and easy Java development tool perfect for
this purpose. The graphical user interface which was chosen is similar to Microsoft Explorer —
or ACDSee — and consists of a tree where the folders are displayed, a list where the assets in
the selected folder are shown, and a preview of the newest version of the selected asset. The
information on who has currently checked out the file and when he/she did it is displayed
together with the file’s name, type, status, and comment. The tree, list, and preview have to
be separated by splitters which gives the user the possibility to resize the three components
as he wishes. The preview always shows the newest version of the asset. Older versions can
be accessed over a separate dialog to keep the user interface as simple as possible.

Figure 4.1: Sketch of Generic Client Module

4.6.1 Folder Tree

The folder tree contains different folders like a directory structure in a file system. Each
folder in this tree can contain different assets which are listed in the asset list.
18 CHAPTER 4. SYSTEM DESIGN

4.6.2 Asset List

The asset list contains all assets inside the selected folder. These assets have different pa-
rameters like their filename, type, status, comment, etc. which are displayed next to the
asset.

4.6.3 Preview

The preview shows a thumbnail of the newest version of the selected asset. Some file formats
cannot be previewed approprietly with a thumbnail (e.g. 3D models, videos and sound files).
For these files an empty thumbnail is displayed. This is quite useful when searching for a
specific asset.

4.6.4 Stand-alone Client

The stand-alone client is a standard Windows application. It has two components, its menu
and the generic client module. Therefore looks like depicted in Figure 4.2.

Figure 4.2: Sketch of Stand-alone Client

4.6.5 Menu

The menu of the stand-alone client consists of three different sub-menus: the program menu,
the folder menu, and the asset menu (which are loaded from the generic client module).
When no object is selected, all but the add command, are grayed out. Each time an object
is selected the items in the appropriate sub-menu are enabled or disabled depending on their
functionality (e.g. when an asset that is currently checked out is selected, the “Check Out”
item is disabled, if the user who has checked it out is the current user, the “Check In”
4.6. USER INTERFACE 19

menu item is enabled, otherwise it is diabled). Removing all items which cannot be used at
the current time from the menu instead of graying them out would confuse the user and is
therefore not appropriate [Johnson, 2000].

4.6.5.1 Folder Menu

The following operations can be selected in the folder menu:

ˆ Open, expands the selected folder


ˆ Search, searches for an asset recursively in the selected folder
ˆ Refresh, refreshes the asset list
ˆ Copy, copies the selected folder
ˆ Cut, cuts the selected folder
ˆ Paste, pastes the copied folder into the selected folder
ˆ Add, opens the add folder dialog to add a new folder into the selected folder
ˆ Delete, deletes the selected folder
ˆ Rename, renames the selected folder
ˆ Properties, changes the properties of the selected folder.

4.6.5.2 Asset Menu

The following operations can be selected in the asset menu:

ˆ Check In, checks out the selected asset


ˆ Check Out, checks in the selected asset
ˆ Get Latest Version, gets the latest version of the selected asset
ˆ Copy, copies the selected asset
ˆ Cut, cuts the selected asset
ˆ Paste, pastes the copied asset into the selected folder
ˆ Add, opens the add asset dialog to add a new asset into the selected folder
ˆ Delete, deletes the selected asset
ˆ Rename, renames the selected asset
ˆ Properties, changes the properties of the selected asset.
20 CHAPTER 4. SYSTEM DESIGN

4.6.6 Dialogs

All dialogs have an OK button and a Cancel button. With OK the desired task is performed,
Cancel aborts and the task is not performed.

4.6.6.1 Add Folder Dialog

Figure 4.3: Sketch of Add Folder Dialog

The Add Folder dialog contains a text area where the name of the new folder can be entered.
A template can be selected in the template combo box.

4.6.6.2 Add Asset Dialog

Figure 4.4: Sketch of Add Asset Dialog

The Add Asset dialog contains a text area where the name(s) of the file(s) has/have to be
entered. The file(s) can also be selected by pressing the ‘‘...’’ button which opens a stan-
dard Windows file dialog. After choosing the file(s) to add, the file types are automatically
selected by comparing the extension(s) of the file(s). The status the file(s) shall get can be
selected in the “Status” combo box. Last but not least the asset can get a comment which
is very useful to inform the next developer in the artwork production chain about special
details on this asset. Sometimes it might also be necessary to add the whole creation path
(all steps that are needed to produce the file, like used filters in Photoshop) as a comment.
4.6. USER INTERFACE 21

4.6.6.3 Template Browser Dialog

Figure 4.5: Sketch of Template Browser Dialog

The Template Browser contains a list of all templates and a menu with operations to edit
the list. These operations are: Add, Edit and Delete. The Delete operation will simply
erase the template if it is not used. Add and Edit will open the Add Template dialog.

4.6.6.4 Add Template Dialog

Figure 4.6: Sketch of Add Template Dialog

The Add Template dialog contains two text areas, one for the name of the template and
another one for the naming convention.
22 CHAPTER 4. SYSTEM DESIGN

4.7 Entity Relationship Model

Figure 4.7: Entity Relationship Model

4.7.1 Asset

The Asset is the entity which defines a logical object that can exist in different versions of
files. Each asset has a name which is equal to the name of the file it was created from. The
type of the asset is generated by searching for the file’s extension in the AssetType lookup
table.
Another important information is the status the asset currently has. The different possible
types of status information are stored in a separate table called AssetStatus.
In some cases it is useful to add some additional information to an asset. For example some
artists want to save the creation path (a complete list with all steps done to produce it)
together with the asset. For this reason it is necessary to be able to store an extensive
description, called comment.
Last but not least the user who has currently checked out the asset and the time when he
did have also to be stored for each Asset.

4.7.2 AssetData

The AssetData reflects a specific version of an asset. It contains a version number, the binary
data of the file’s content, the user who created it and the time when he did. Whenever a
user checks in the corresponding asset a new version of the asset is created. To store a huge
amount of binary data a BLOB (Binary Large OBject) is used.
4.7. ENTITY RELATIONSHIP MODEL 23

4.7.3 AssetStatus

The AssetStatus is the current production status of the asset. It can have different values
depending on the state it is in and the department that sets the status. Each of the depart-
ments (3D, 2D, Art, Test, and Sound) are allowed to change the status of an asset.
Valid values are:

ˆ 3D - Temporary

ˆ 3D - Ready

ˆ 3D - Check

ˆ 2D - Temporary

ˆ 2D - Back to 3D

ˆ 2D - Back to Art

ˆ 2D - Ready

ˆ 2D - Okay

ˆ 2D - Hold

ˆ 2D - Old

ˆ 2D - Check

ˆ Art - Temporary

ˆ Art - Back to 3D

ˆ Art - Ready

ˆ Art - Back to 2D

ˆ Art - Hold

ˆ Art - Check

ˆ Test - Back to 2D

ˆ Sound - Temporary

ˆ Sound - Back to Art

ˆ Sound - Ready

ˆ Sound - Okay

ˆ Sound - Old

ˆ Sound - Check
24 CHAPTER 4. SYSTEM DESIGN

4.7.4 AssetType

Assets can have different types of content (e.g. 3D model, 2D graphic, sound). The Type
consists of the name or description of the type and a list of extensions for identifying files of
this type. Some example types are:

ˆ *.3ds 3ds max model,

ˆ *.psd Photoshop image,

ˆ *.tga targa graphic image,

ˆ *.jpg, *.jpeg jpeg graphic image,

ˆ *.bmp Windows bitmap,

ˆ *.wmf Windows meta file,

ˆ *.tiff tag image file format,

ˆ *.avi, *.mpg movieclip,

ˆ *.gif CompuServe GIF,

ˆ *.* unknown file type.

4.7.5 Folder

Assets are grouped in Folders which in turn are hierarchically organized just like in a common
file system. This folder structure will in fact resemble the original GFX tree which is already
used at JoWooD, Ebensee. Each folder has a name and a template.
An example folder tree is shown in Figure 4.8.

Figure 4.8: GFX Tree Example


4.7. ENTITY RELATIONSHIP MODEL 25

4.7.6 Template

Templates define how many assets have to be in the folder and how they will have to be
named to be able to set their state to final. This forces the users to obey the naming con-
ventions and prevents them from setting objects partially final. With a naming convention
of “<name> <rotation(16)>” the folder must contain sixteen files and they have to have an
underscore and a number from zero to fifteen appended (e.g.: “s-mart 0”. . . “s-mart 15”).
Some example templates are:

ˆ Building <name> <rotation(16)>

ˆ Tree <name> <rotation(16)> <animation(4)>

ˆ Car <name> <rotation(16)> <animation(8)>

ˆ Train <name> <rotation(16)> <animation(32)>

ˆ Video <name> <frame(800)>


26 CHAPTER 4. SYSTEM DESIGN
Chapter 5

Implementation

“What are you crazy?” said Zaphod.


“Without proper programming anything could happen.”
- Douglas Adams

This chapter describes the implementation of the system by explaining the explicit solutions
for all major problems.

5.1 System Construction

As mentioned in Section 4.2, there have to be different types of clients which all share the
same functionality. For this reason the client functionality and the user interface have to be
encapsulated in a component to make re-use easier and to avoid code duplication.
There are lots of possibilities to encapsulate functionality in a component. Microsoft’s COM
(Component Object Model) technology provides a very effective way to create such compo-
nents. According to [LaMothe, 1999], “COM was invented many years back as a simple white
paper on a new software paradigm, which was similar to how computer chips or Lego blocks
work. You simply plug them together and they work”.
Deriving a COM component from the IDispatch interface enables programs to determine
the control’s functionality and use it without code changes. COM components derived from
IDispatch are called ActiveX components.
This possibility is exactly what is needed to embed the client functionality and user inter-
face in the different clients. The ActiveX component will be called “AssetViewer Control”
and will be implemented with Visual C++ using MFC. For more information on COM and
ActiveX see [Rogerson, 1997], [Platt, 1997], or [Swanke, 2000].

27
28 CHAPTER 5. IMPLEMENTATION

5.2 Database

5.2.1 Database Access

Because all the data is stored in a database an interface is needed to access it. The Open
DataBase Connectivity, short ODBC, from Microsoft — is a common interface which provides
the functionality needed. The easiest way to exchange data with our database, using MFC, is
to model the most frequently used data objects by deriving them from a generic recordset and
giving them all data members to store their specific content. A recordset object represents
a set of records selected from a data source [Microsoft Corporation, 2001a]. In our case the
most frequently used data objects are: Folder, Asset, AssetData, and User. On creation the
AssetViewer Control reads the folders from the database and fills the TreeView with this
data. Whenever a folder is selected in the TreeView the content of the ListView is refreshed
from the database.

5.2.2 Storing Huge Binary Data

The data of each version of an asset is stored in the AssetData table. The content of a file
is a block of binary data of variable size. Its size varies from under one kilobyte to hundreds
of megabytes. Storing these data in a numeric or varchar is insufficient and slow. Common
relational database systems provide a special data type for this kind of data, called BLOB
(Binary Large OBject).

5.2.3 Storing Hierarchial Tree Structures

Storing a tree structure (like the folder tree) in a relational database can be easily done by
adding a relation to the database table which references to the same table. This way every
node is given a link to its parent. The tree can be exactly defined with a minimum of extra
space in the database. But this solution has a severe disadvantage: creating the complete
tree structure from the database table in memory needs quite a lot of time because for each
node its children (the nodes which have the current node as parent) have to be searched.
A better way to read the structure from the database would be a Gorn tree [Gorn, 1967].
It can be read from the database in only one step but needs a little bit more memory in
the database: In a Gorn tree each node is identified by a special index which is a composite
of several indices. For each level the tree should be able to grow to, an additional index is
needed. So a Gorn tree of depth four would have to have a composite index of four different
indices.
5.2. DATABASE 29

Figure 5.1: Gorn Tree

Figure 5.1 shows a Gorn tree of depth four. On each level of the tree the indices which are
higher than the level are set to zero. The indices which are lower or equal are defined by the
indices of the parent and the number of the child. So a Gorn tree index can be split into
three different parts {index},{child number}, and {zeroes}. The index is the parent’s index
plus the parent’s child number.
By iterating through the Gorn tree, ordered by its indices, the whole tree can be build just
by comparing the current node and its parent [Gorn, 1967].

5.2.4 Database Tables

This section provides a list of all necessary database tables. For each table its columns are
listed using the following structure:

ˆ P. Key If the mark is checked the column is or is part of the table’s primary key.

ˆ F. Key If the mark is checked the column is a foreign key which was created by adding
a relation form one table to another. The related table can be found in the References
column.

ˆ Name The name specifies the name of the column in the database table.

ˆ Type The type specifies the datatype associated with the column.

ˆ NULL If the mark is checked NULL values are allowed in the column.

ˆ References The “References” column contains the database table and the specific
column that is referenced by the foreign key.
30 CHAPTER 5. IMPLEMENTATION

5.2.4.1 Asset

The exact realization of the Asset entity described in Section 4.7.1:

P. Key F. Key Name Type NULL References


X
  ID numeric 
 X
 Folder numeric  Folder.ID
 X
 Type int  AssetType.ID
  Filename varchar 
 X
 Status int X
 AssetStatus.ID
 X
 LockedBy int X
 AssetUser.ID
  LockedAt datetime X

  Comment varchar X


5.2.4.2 AssetData

The exact realization of the AssetData entity described in Section 4.7.2:

P. Key F. Key Name Type NULL References


X
 X
 Asset numeric  Asset.ID
X
  Version int 
 X
 CreatedBy int X
 AssetUser.ID
  CreatedAt datetime X

  Data image 

5.2.4.3 AssetStatus

The exact realization of the AssetStatus entity described in Section 4.7.3:

P. Key F. Key Name Type NULL References


X
  ID int 
  Status varchar 

5.2.4.4 AssetType

The exact realization of the AssetType entity described in Section 4.7.4:

P. Key F. Key Name Type NULL References


X
  ID int 
  Name varchar 
  Extensions varchar 
5.2. DATABASE 31

5.2.4.5 Folder

The exact realization of the Folder entity described in Section 4.7.5:

P. Key F. Key Name Type NULL References


X
  ID numeric 
 X
 Template int  Template.ID
  Name varchar 
  Gorn00 int 
  Gorn01 int 
  Gorn02 int 
  Gorn03 int 
  Gorn04 int 
  Gorn05 int 
  Gorn06 int 
  Gorn07 int 
  Gorn08 int 
  Gorn09 int 
  Gorn10 int 
  Gorn11 int 
  Gorn12 int 
  Gorn13 int 
  Gorn14 int 
  Gorn15 int 
  Gorn16 int 
  Gorn17 int 
  Gorn18 int 
  Gorn19 int 

5.2.4.6 Template

The exact realization of the Template entity described in Section 4.7.6:

P. Key F. Key Name Type NULL References


X
  ID int 
  Name varchar 
  NamingConvention varchar 
32 CHAPTER 5. IMPLEMENTATION

5.3 GUI

The GUI is implemented in the AssetViewer control and consists of a tree control, a list
control and a HTML view which are separated by splitters. The list control has to contain
additional information and is therefore set to report style. All the controls have popup menus
attached to them which makes their use faster. The content of this popup menus is loaded
from a menu resource which is linked into the ActiveX control. The AssetViewer provides
two methods, GetAssetMenu() and GetFolderMenu(), which return the corresponding sub-
menus to the caller. This is needed if the window in which the AssetViewer is embedded
wants to add these sub-menus to its own menu.

5.3.1 Client Screenshots

Figure 5.2 and 5.3 shows the stand-alone client. Figure 5.4 shows the client component loaded
in the Microsoft ActiveX Test-Container —.

Figure 5.2: Stand-alone Client Screenshot 1


5.3. GUI 33

Figure 5.3: Stand-alone Client Screenshot 2

Figure 5.4: ActiveX Component Screenshot


34 CHAPTER 5. IMPLEMENTATION

5.3.2 Dialog Screenshots

If a system consists of more than one dialog box it is useful to have all dialog boxes follow a
common look. They should never take too much space and contain only vital information.
All unnecessary information is useless and confuses the user [Cooper, 1995].

Figure 5.5: Add Folder Dialog

Figure 5.6: Add Asset Dialog

5.4 Parallel Transactions

To make parallel processing possible, all transactions with the database are derived from a
generic thread class and a thread queue in the main component manages the running and
waiting threads. All these transactions need to access the database. They cannot use one
common connection because only one thread can use a database connection at a time. If every
transaction would open its own database connection, opening and closing the connections
would waste a lot of time. To avoid such a performance loss a connection pool is implemented.
It contains at least ten open database connections which can be used by different threads.
When all of the database connections are used, another ten are created. The transactions do
not need to open or close the connections, they just need to get an open one from the pool.
This way connections are reused by different threads. The pool removes ten unused open
connections, if there are more than fifteen unused ones in the pool.
5.5. MANAGING HUGE BINARY DATA 35

5.5 Managing Huge Binary Data

For reading and writing of the asset data values a CLongBinary is used because it can be
read from and written to a file with a global memory handle in one step. A custom recordset
(derived from CRecordset) would look like this:

class CAssetData : public CRecordset


{
public:
CAssetData(CDatabase* pDatabase = NULL);
DECLARE DYNAMIC(CAssetData);

//Field-/Parameterdata
//{{AFX FIELD(CAssetData, CRecordset)
CString m Asset;
long m Version;
CString m Creator;
CTime m CreateTime;
CLongBinary m Data;
//}}AFX FIELD
...

When reading data into the CLongBinary data member of the custom recordset with ODBC
it is important to set the FieldDirty and FieldNull flags [Microsoft Corporation, 2001b] :

assetdata->SetFieldDirty(&assetdata->m Data, true);


assetdata->SetFieldNull (&assetdata->m Data, false);

This short code example explains how to write a CLongBinary with a global memory handle
into a file on the hard drive:

CFile file(m sPath + m sFilename, CFile::modeCreate |


CFile::modeWrite |
CFile::typeBinary);
void* pt = GlobalLock(assetdata->m Data.m hData);
file.WriteHuge(pt, assetdata->m Data.m dwDataLength);
file.Close();
GlobalUnlock(assetdata->m Data.m hData);
36 CHAPTER 5. IMPLEMENTATION

5.6 Class Hierarchy

Figure 5.7: Class Hierarchy

5.6.1 CAssetViewerCtrl

The CAssetViewerCtrl is the ActiveX control that encapsulates all the client functionallity
and the user interface. It consists of a folder tree (CTreeCtrl), an asset list (CListCtrl)
and a preview (CHtmlView). When the CAssetViewerCtrl has to refresh the content of
the folder tree it produces the needed special recordsets (CFolder) and creates tree items
(CFolderTreeItem) from them. These items are then used to rebuild the folder tree. When-
ever a folder is selected the asset list has to be refreshed. The asset viewer creates recordsets
(CAsset) and produces list items (CAssetListItem) from them. The asset list is then cleared
and refilled with these list items.

All database operations which transfer BLOBs to or from the server are encapsulated in
special transactions (CTransaction). The transaction class is derived from a custom made
thread class (CThread) so that multiple transactions can be executed simultaneously. When-
ever a file is added, checked in, or checked out a corresponding transaction is generated. A
5.6. CLASS HIERARCHY 37

thread queue (CThreadQueue) is used to control running and waiting threads because execut-
ing more than ten transactions at a time would create too much network traffic. Whenever
the asset viewer creates a transaction it enqueues it in the thread queue which is then re-
sponsible for starting it.

5.6.2 CFolderTreeCtrl

The CFolderTreeCtrl is derived from CTreeCtrl. It contains the graphical representation


of the folder tree from the database. It has a popup menu which menu-items are dynamically
enabled or disabled depending on the selected folder(s). Each tree item in the tree control
has an object of class CFolderTreeItem as data member.

5.6.3 CFolderTreeItem

The CFolderTreeItem contains all data members a typical folder has: id, name, template,
and Gorn indices. It can be inserted into the database or recursively added into a tree control.
Each folder tree item contains a list of all its assets. This list can be added into a list control.
The folder tree item has a recursive method to get the path from the current folder up to
the root folder. This is needed when an asset is checked out because it has to be stored in
the correct directory. All folders know their parent folder, their first child, and their next
sibling. This information is needed when doing operations on the whole folder tree.

5.6.4 CAssetListCtrl

The CAssetListCtrl is derived from CListCtrl. It contains the graphical representation


of the assets in the selected folder. It has a popup menu which menu-items are dynamically
enabled or disabled depending on the selected asset(s). Each list item in the list control has
an object of class CAssetListItem as data member.

5.6.5 CAssetListItem

The CAssetListItem contains all information which have to be displayed in the asset list
(id, filename, type, status, comment, the user who currently works on it, and when he/she
checked it out and even its current process). Each asset knows in which folder it is and it
can be inserted or updated into a list control. The asset can be inserted into the database
or refreshed from there by its identificiation “id”.

5.6.6 CThread

The CThread class is a generic thread class. To implement a thread which has a special
functionality one can derive a new class from it. The code which has to be executed by the
new thread has to be written into its overloaded virtual run method. The MFC provides
a thread class (CWinThread) which has mostly the same functionality but it has two major
disadvantages: first it uses windows messages to communicate which are slower than normal
38 CHAPTER 5. IMPLEMENTATION

function calls, second it is MFC specific which restricts its use to MFC applications [Prosise,
1999]. The CThread uses only the Win32 API thread functions and is therefore also usable
in non MFC applications [Calvert, 1996]. Its definition is similar to the generic Java thread
class which makes the CThread re-usable for almost any other C++ project.

5.6.7 CThreadQueue

The CThreadQueue class contains two vectors of threads: one with running threads and one
with waiting ones. Whenever a thread is enqueued it is put into the waiting thread vector.
When a thread is put into the waiting thread vector or when a running thread is finished
and therefore removed from the running thread vector the thread queue checks the amount
of threads in each vector. If there are fewer than ten threads in the running thread vector
and at least one in the waiting thread vector, the running thread vector is filled with waiting
threads until it is either full or there are no more waiting threads. All threads which are
enqueued in the running thread vector are started automatically. This way only a maximum
of ten threads are processed at a time independently from the amount of threads enqueued.
Otherwise performance could decrease considerably, and the database may be slowed by too
many parallel transactions.

5.6.8 CTransaction

A CTransaction is a special CThread. It has a database connection it works on, which is


taken from a connection pool, a user who performs the transaction (which is normally set
by the client application to the user who logged on), and a pointer to the CWnd it sends a
windows message when it is finished.

5.6.9 CCheckInTransaction

The CCheckInTransaction gets an asset list item on construction and the working directory
the application uses. When it is started it searches for the highest version of its asset and
reads the file from the hard disk. Then a new assetdata entry is created and the data from
the file is written into the database. Finally the asset itself is updated because it is no longer
checked out.

5.6.10 CCheckOutTransaction

The CCheckOutTransaction gets an asset list item and the working directory. It constructs
the whole path of the file which is to be checked out by concatenating the filename, the
recursive folder path, and the working directory. Then it recursively checks whether the
directory exists and creates it if necessary. When the path is valid the file is created and the
asset data is written into the file. After that the LockedBy and LockedAt values of the asset
are updated.
Chapter 6

Testing and Evaluation

The stand-alone client was tested with different file sizes and several file types. The results
of these tests are described in this chapter.

6.1 Validation Test

According to [Boehm, 1984], validation in software testing means “to establish the fitness
or worth of a software product for its operational mission”. Consequently the system was
tested how well it fits the users’ needs. The validation test was performed with multiple clients
working simultaneously and included all functionality implemented until then. This included:

ˆ adding folders,

ˆ browsing folders,

ˆ adding assets,

ˆ browsing assets,

ˆ checking in assets,

ˆ checking out assets.

First of all a folder hierarchy was created. It resembled the two lowest levels of JoWooD’s
current GFX tree. It consisted of eight folders with four to six subfolders each. All of
them got a template assigned to it. After that the folders were refreshed, closed and opened
several times while other folders were added from another client. Then assets had to be
added. Images, videos, sounds, and other binary data of different size and shape were added
into the folders. Each folder was changed several times refreshing its content to view changes
of other users. Many of the assets were then checked out to the local hard drive and their
content was examined. With another client the assets were browsed again to ensure that it
was not possible to tamper with them while they were checked out. The assets were then
modified and checked in again. Checking them out again showed that the modified content

39
40 CHAPTER 6. TESTING AND EVALUATION

was now the newest version. Finally multiple assets were checked in and out to test the
thread queue. During the execution of a check in process the program was quited on purpose
to test its behavior. The program opened a dialog box, asking the user if he/she wanted to
wait for the asset to be checked in or just cancel the transaction.

The test produced the following results:

ˆ Adding and browsing of folders works correctly.

ˆ Assets which are bigger than the amount of memory on the client computer cannot be
checked in or out.

ˆ Assets which are smaller than that work fine.

ˆ Changes are transparent to other users.

ˆ Working with multiple assets simultaneously works as defined.

ˆ When quitting unfinished transactions can be completed or canceled.

6.2 Performance Test

The performance was tested on an AMD Athlon 800 Mhz with 128 MB RAM as client
connected to the server, a Dual Intel PentiumII 266 Mhz with 196 MB RAM, over a 100Mbit
LAN. All times are in milliseconds and are averages from twenty independent test cycles.

Figure 6.1: Performance Test

As expected the FTP transfer was much faster than the ODBC data transfer. Files that are
bigger than the amount of RAM in the client computer cannot be transfered with ODBC
6.2. PERFORMANCE TEST 41

File Size Transfer Time (ms)


ODBC FTP
10 MB 11807 4392
20 MB 12619 6735
30 MB 17468 9931
40 MB 30164 17867
50 MB 46870 18110
60 MB 63985 18879
70 MB 100845 17606
80 MB 140116 23067
90 MB 164052 27946
100 MB 203896 22243

Table 6.1: Performance Test Results

because the files are not split up before sending. As described in Section 9.2 a server module
on the same machine the database is installed on could solve this problem.

The bigger the file the slower the ODBC transfer gets compared to an FTP transfer. At
JoWooD most files are smaller than 100 megabytes in size and therefore this is currently not
considered as a problem but will have to be solved in the future.
42 CHAPTER 6. TESTING AND EVALUATION
Chapter 7

Example

This chapter contains an example how the program can be used. It shows how a folder is
created and assets are added to the folder, checked out, and checked in again.

7.1 Step 1

First of all the program is started. In this example the folder and asset tables in the database
are empty, so we have a plain, clean system.

Figure 7.1: Example Step 1

43
44 CHAPTER 7. EXAMPLE

7.2 Step 2

Then the folder in which the new folder shall be created is selected. In this example the new
folder is added directly under the root node. When the folder is selected the “Folder” menu
is opened and the menu item “Add Folder” is selected.

Figure 7.2: Example Step 2

7.3 Step 3

This opens the “Add Folder” dialog where the folder can be given a name and a template
can be selected.

Figure 7.3: Example Step 3


7.4. STEP 4 45

7.4 Step 4

Now that the folder is created assets will be added into it. Therefore the “Asset” menu is
opened and the menu item “Add Asset” is selected.

Figure 7.4: Example Step 4

7.5 Step 5

Adding assets can be done with the “Add Asset” dialog. One or more files can be selected
and a status and comment is defined. The type is selected automatically but can be changed
if necessary.

Figure 7.5: Example Step 5


46 CHAPTER 7. EXAMPLE

7.6 Step 6

After the assets have been added they can be checked out and in again. The asset that shall
be checked out is selected, which loads its preview automatically. Checking out the asset
can be done using the “Asset” menu. The “Check Out” menu item is selected and the file is
copied to the hard drive.

Figure 7.6: Example Step 6

7.7 Step 7

After making the desired changes the asset is checked in. This can be done with the menu
item “Check In” in the “Asset” menu. The system now adds the new version of the file into
the database.

Figure 7.7: Example Step 7


Chapter 8

Software Development Process

The project which is described in this thesis was an internal project which was realized using
a step-by-step approach. This procedure demands that all steps are clearly separated from
each other. In each step an output is produced which is defined exactly for each step. This
output consists in most cases of documents generated with specific tools. The most important
point in the step-by-step approach is that each step is clearly defined and each task has to
provide the next one with all necessary information/documents it needs [Mayr, 2001].
A specific description of the performed steps follows.

8.1 Research

In this phase the global goals had to be defined together with the production team at JoWooD.
These goals were considered essential for the project to be completed successfully. As the
general requirements now were defined, the make-or-buy decision had to be made. Different
products were compared in consideration of how well they can satisfy the requirements. Three
of these products are mentioned in Chapter 3. Seeing that none of the examined existing
products would suffice their needs, Johann Schilcher, chief technology officer at JoWooD,
decided that a new product had to be developed in-house.

8.2 Requirements Analysis

The first step was to create a complete list of detailed requirements for an asset manage-
ment system, customized for game development. Then the technical feasibility had to be
researched. The most critical problem was to find out if the different development tools’
APIs would make an integration possible. So the SDKs for 3ds max and Photoshop were
downloaded and examined. The research for technical feasibility was positively completed.

Created documents were:


ˆ list of requirements,

ˆ list of whished features,

ˆ product comparison.

47
48 CHAPTER 8. SOFTWARE DEVELOPMENT PROCESS

8.3 Design

The design phase started with the creation of GUI prototypes to find out the personal prefer-
ences of the users. These prototypes had no functionality at all but showed the users different
possible user interfaces. The next task was to create a data model for the product. After
deciding for Microsoft SQL-Server as database, the entity relationship model was designed.
Visual Studio and MFC were chosen as development environment and library. To ensure the
system would meet the requirements tests were designed.

Created documents were:

ˆ GUI sketch,

ˆ entity relationship diagram,

ˆ test plan.

8.4 Implementation

In the implementation phase the first task was to gather all necessary tools and subsystems
needed. The Microsoft SQL-Server was installed and the database tables and relations were
created. The programming environment was set up and the classes were coded.

Created documents were:

ˆ source code,

ˆ database tables,

ˆ class hierarchy.

8.5 Testing and Evaluation

Using the test plan created during the design phase the system was tested. The system
passed the validation and performance tests positively. Considering the test results different
possible improvements were discussed and evaluated.

Created documents were:

ˆ test results,

ˆ list of possible improvements.


Chapter 9

Conclusion

This chapter contains a short review of the project and what it solved.

9.1 Goal and Solution

The goal of the project was to deliver an asset management solution which could be used
immediately by JoWooD. First, existing solutions were searched to avoid wasting time and
money on re-inventing the wheel. The research for commercial solutions was completed and
no acceptable solution was found. So implementing a customized solution which meets all
game developers needs became necessary.

The implemented solution described in this thesis would suffice all needs but could not
be completed in the short time period of a diploma thesis. The parts which are still to be
completed contain the template and delete functionality for folders, including its dialogs. The
property edit and delete functionality for assets and the dialog to select different versions is
also not yet included. Other missing but important parts are the integration for Photoshop
and 3ds max. All these features will be completed in the near future.

9.2 Possible Improvements

This section describes improvements which would be useful but not necessary.

9.2.1 Asset Server

As seen in Section 6.2, the data transfer over a local area network with, for example, FTP is
much faster than the network data transfer by ODBC. If the raw data would be transferred
to the server by a fast transfer protocol and then inserted there with ODBC into the local
database speed could be increased significantly. Besides ODBC has to have the whole binary
block in memory when checking it in. This means the maximum size a file can have when
trying to check it in is limited by the amount of memory on the client computer. Sending
the file in blocks over the network to an asset server module which would then assemble the

49
50 CHAPTER 9. CONCLUSION

blocks and check the file in without network transfer would limit the maximum file size only
by the amount of memory on the server.

9.2.2 Workflow Management

Another possible improvement would be a workflow management system where a manager


could define in which order assets have to be edited by which developers. This system could
then disable all other users the access to these files and automatically inform artists when
new work has to be done. Currently there is no workflow management at JoWooD and artists
inform each other orally when they have finished their work.

9.2.3 Branching

A useful functionality in version control systems is branching. Sometimes it is necessary to


duplicate a current version and make different changes on them to see which one is better.
This feature would make it possible to create several versions of an asset which can be
developed independently even by different users. The versions can then be evaluated and the
best one can be chosen.

9.3 Unsolved Problems

Files bigger than the amount of memory on the client computer cannot be checked in, because
ODBC needs to have the whole data block in memory when starting the transaction. This
means that users who want to check in/out rather big files will need an appropriate amount
of RAM. This problem could be solved with an asset server as described in Section 9.2.1.

At JoWooD assets are smaller than the main memory of the computers (usually 128 MB) and
therefore this is not considered as a severe problem. Nevertheless this must be considered as
a problem for the future, because computer hardware improves steadily and nobody knows
which amount of data will have to be managed tomorrow.
Literature

[Biessman and Johnson, 2000] Eric Biessman and Rick Johnson. Post Mortem: Raven Software’s Soldier of
Fortune. Game Developer, 9 2000.
[Boehm, 1984] Barry W. Boehm. Verifying and Validating Software Requirements and Design Specifications.
IEEE Software, 1984.
[Calvert, 1996] Charles Calvert. Windows 95 Programmierung in 21 Tagen. SAMS, 1996.
[Cooper, 1995] Alan Cooper. The Essentials of User Interface Design. IDG Books Worldwide, 1995.
[Fischl, 2001] Andreas Fischl. A System for Game Configuration at JoWooD. Master’s thesis, Upper Austrian
Polytechnical University, Department of Software Engineering, Hauptstrasse 117, 4232 Hagenberg, 2001.
[Gorn, 1967] Saul Gorn. Systems and Computer Science, chapter Explicit definitions and linguistic dominoes,
pages 77–115. University of Toronto Press, Toronto, Canada, 1967.
[Johnson, 2000] Jeff Johnson. GUI Bloopers. Academic Press, 525 B Street, Suite 1900, San Diego, CA
92101-4495, USA, 2000.
[LaMothe, 1999] Andre LaMothe. Tricks of the Windows Game Programming Gurus. Sams, 1999.
[Marselas, 2000] Herb Marselas. Where’d It Go? It Was Just Here! Game Developer, 11 2000.
[Mayr, 2001] Herwig Mayr. Project Engineering. Ingenieursmäßige Software- Entwicklung in Projektgruppen.
Fachbuchverlag Leipzig, 2001.
[Microsoft Corporation, 2001a] Microsoft Corporation. Recordset (ODBC). .
http://msdn.microsoft.com/library/default.asp, 2001. [Accessed April 23, 2001].
[Microsoft Corporation, 2001b] Microsoft Corporation. TN045: MFC/Database Support for Long Var-
char/Varbinary. http://msdn.microsoft.com/library/default.asp, 2001. [Accessed April 25, 2001].
[Merant, 2001] Merant. PVCS Product Family Overview. http://www.merant.com/products/pvcs/, 2001.
[Accessed August 1, 2001].
[Microsoft, 2001] Microsoft. Visual SourceSave 6.0. http://www.microsoft.com/catalog/display.asp, 2001.
[Accessed August 1, 2001].
[NxN, 2001] NxN. Alienbrain 4.0 Feature Overview. http://www.nxn-software.com/7.0/main.html, 2001.
[Accessed August 1, 2001].
[Platt, 1997] David S. Platt. Essence of COM and ActiveX. Prentice Hall PTR, December 1997.
[Prosise, 1999] Jeff Prosise. Programming Windows with MFC. Microsoft Press, 2nd edition, 1999.
[Rogerson, 1997] Dale Rogerson. Inside COM. Microsoft Press, February 1997.
[Sawyer et al., 1998] Ben Sawyer, Alex Dunne, and Tor Berg. Game Developer’s Marketplace. The Coriolis
Group, Inc., 14455 N. Hayden Road, Suite 220, Scottsdale, Arizona 85260, 1998.
[Swanke, 2000] John E. Swanke. COM Programming by Example: Using MFC, ActiveX, ATL, ADO, and
COM+. CMP Books, January 2000.

51