minedesertΛογισμικό & κατασκευή λογ/κού

31 Οκτ 2013 (πριν από 3 χρόνια και 5 μήνες)

64 εμφανίσεις

Tools' significance in game-development
Sebastian Salonen
Bachelor of Science in Engineering Technology
Computer Game Programming
Luleå University of Technology
Department of Computer Science, Electrical and Space Engineering

Tools significance in
Sebastian Salonen
Lulea University of Technology
Dept.of Computer Science and Electrical Engineering
Div.of Systems and Interaction
June 5,2012
The amount of computer games produced has increased drastically over the last ten years
and so has the production costs within game development.Many game developers spend
a lot of time creating intuitive tools to improve the work owof the game creation process.
An example of these tools is a level editor which serves the purpose of creating content
faster,easier and with minor or no programming experience at all.How important are
tools when it comes to game development?What positive eects may tools have on a
project?What is the impact of quality and complexity of the tools on a game project?
Does quality and complexity have any major in uence?
This thesis analyses,tests,and shows dierent implementations of tools for game de-
velopment in order to nd their signicance in the game production pipe-line and what
relationship tools have to the total production cost of a game project.
Antalet datorspel som utvecklas har okat drastiskt over de senaste tio aren vilket aven
produktionskostnaden for spelutveckling har.Manga spelutvecklare spenderar mycket tid
med att skapa intuitiva verktyg for att oka arbets odet av spelskapandet.Ett exempel
av dessa verktyg ar en level editor vars syfte ar att skapa innehall snabbare,lattare och
med smarre eller ingen programmeringserfarenhet alls.Hur viktigt ar det med verktyg
nar det kommer till spelutveckling?Vilken positiv inverkan kan verktyg ha pa projektet?
Vad har verktygens kvalite och komplexitet for eekt?Gor kvaliten och komplexiteten
pa verktygen nagon storre skillnad?
I detta arbete analyseras,testas och implementeras olika verktyg for spelutveckling for
att nna verktygens vikt i spelproduktionens pipe-line och vad de har for betydelse for
den totala produktionskostnaden i ett datorspelsprojekt.
I have been working on a project for a Swedish game company called Frostware AB.This
project consisted of 2 programmers,2 graphical artists and 1 game designer.My role in
the project has been to create and improve current tools for the game prototype that was
to be produced in this project but also to be a part of the creation of the game prototype.
To investigate and implement tools for game development has been very interesting and
I would like to thank Johannes Hirche for the opportunity to use and work with the game
engine Nebula3 and also Frostware AB who made this project possible.
Sebastian Salonen
Chapter 1 { Introduction 1
1.1 Background..................................1
1.2 Purpose and Goal...............................1
1.3 Terms and Abbrevations...........................2
Chapter 2 { Method and Materials 3
2.1 Investigation..................................3
2.2 External Tools.................................4
2.3 Tool Implementation.............................5
2.3.1 Preparations..............................5
2.3.2 Camera Improvement.........................5
2.3.3 Entity Grouping...........................6
2.4 Test of Concept................................7
2.4.1 Preparations..............................7
2.4.2 The Game Prototype.........................7
Chapter 3 { Results and Future Work 9
3.1 The Created Tools..............................9
3.2 The Prototype.................................10
3.3 Evaluation of External Tools.........................11
3.4 Research Results...............................13
3.5 Future Work..................................14
Chapter 4 { Discussion and Conclusion 15
4.1 Tools Signicance...............................15
4.2 Environmental,Ethical and Social Considerations.............16
4.3 Conclusion...................................16
Chapter 5 { References 17
Chapter 6 { Appendix 19
1.1 Background
Game production is a very costly process[1],improving its work ow and decreasing its
cost is a highly prioritized matter.There are many game companies that are either buy-
ing game development tools or creating them themselves.Either way may oer great
benets,but also problems.
The work has consisted of three dierent parts:Investigate,implement,and test game
development tools.As for the last part,a game prototype was to be made both for
testing purposes but also for the evocation of the game itself.The game prototype and
the documentation was to be made for the Swedish game company Frostware AB.The
project was conducted over a time of about 10 weeks.
1.2 Purpose and Goal
What is tools signicance in the game-development process?Is it worth investing valu-
able time and money for quality tools?What's the dierence between tools and their
quality?These are main questions that will be answered in this thesis.
The purpose of this thesis is to investigate how,as game developer,to invest in game
development tools and to document possible benets,problems and consequences of using
1.3.Terms and Abbrevations 2
1.3 Terms and Abbrevations
GUI Graphical User Interface
LTU Lulea University of Technology
SVN Subversion (software)
MOBA Multiplayer Online Battle Arena (game genre)
DOTA Defense of the ancients (game mod)
Method and Materials
Since the project have consisted of three dierent but related parts each process has been
divided into separate sections.
2.1 Investigation
To have something to compare to,articles and comparisons on the internet were read
together with some tests using one of the latest and most popular[2][3] game engines,
Unity3D.The test was to make something really simple,like a character that could move
around on a surface.Things that were to be documented during this process were:
 The learning curve
 Work ow
 Customizability
To create this simple scene with a moving character,tutorials were used to achieve the
previously described requirements (links to the tutorials can be found in the appendix).
These tutorials covered most of the basics such as UI navigation,asset managing,editor
navigation and how to apply scripts to components while creating a simple game.
Beside the Unity3D tests,the subject of version control was being investigated.Systems
that somehow connect and manage everyone's work are extremely important,especially
when working in bigger projects[4].Version control was being investigated due to its
importance and many purposes[5] in software development.
2.2.External Tools 4
2.2 External Tools
The external tools that were used during this process were RedMine[14],CMake[15],
TortoiseSVN[16],Qt[17],ZebNet[18] and Nebula[19].Microsoft Visual Studio 2008 was
the IDE used for the project.
Redmine was used for structuring,planning and project overview.Redmine oered a
way to keep track of tasks,bugs and overall progress.During the progress of the project,
feedback could be received in a simple and exible way both from colleagues and users.
CMake was used for build management of the projects.CMake oered a great set of
functionality to the project with features like generation of project les,ability to add
custom build rules,settings and much more.
TortoiseSVN was used for project distribution and version control.SVN oered the
project a exible work ow and made the whole process of sharing work easier.
Qt Framework Qt is a cross-platform application framework used for creating the
graphical user interfaces of the tools.The use of Qt was mostly GUI related,but other
features was used as well such as XML parsing and network communication.
ZebNet was the networking solution for the game prototype and was also created by
the author.ZebNet was still in development during the prototype process.
Nebula3 were the game engine the tools were created for and were also the engine
used for the game prototype.Nebula3 could be considered an internal tool since LTU
Skelleftea has made its own branch of the prototype version of the Nebula3 engine.
2.3.Tool Implementation 5
2.3 Tool Implementation
In this process,an improved camera was implemented for the level editor and also an
implementation of entity grouping was made.All other work on the level editor was less
signicant and were excluded from this paper.
2.3.1 Preparations
Since the tools were already in development when this project started,there was a re-
search phase before starting implementing any new features.The rst thing that had to
be done was to organize all the tasks that had to be done since the amount of develop-
ers had increased.Following that a shorter investigation was made on the systems that
concerned the tasks.
During the whole tool implementation process,constant feedback was received fromboth
the prototype game level designer and two other groups which were participating in the
game project course here at LTU.
2.3.2 Camera Improvement
The existing camera implementation already had many features and was divided into
two parts.A property class and a camera utility class.The utility class had most of the
functionality needed,only minor changes were made to it.The property class was were
the major work and changes took place.
Features implemented
 Set camera focus to entity (zooms in to entity)
 Set camera focus to entity (keeps current zoom level)
 Support multiple entities for the features above.
 Zoom beyond center of interest.
The camera focus feature was quite easy to implement if you only would like to switch
focus to a new entity in an instant,though something more user friendly was desired,
which was in this case a camera that interpolates smoothly to its new center of interest.
Switching camera focus quickly may confuse the user,but by doing interpolation the user
can maintain his orientation easier.
To achieve this result,a very simple interpolation method was used at rst.What was
done the rst time was that the camera took a small step every frame towards the goal
until it was reached.This small step was dependent on the distance between current
2.3.Tool Implementation 6
position and the nal position.Each step becomes smaller each time,which results in a
eect of slowing down.This was the formula:
newPosition = currentPosition +(destination currentPosition)  timestep
A problem occurred when the application was performing poorly,in other words had a
very low FPS,that the goal could be"missed"which resulted in a camera swinging back
and forth until it reached the threshold of the goal.This could easily be xed by checking
the cameras position and see if it was moving away from the target,but since there was
a feedback loop class in Nebula3 already it was decided that it would result in better and
easier to read code if that utility was used instead.
With this,the camera could move smoothly to new positions and set focus to entities.
When doing the other function where the camera zooms in to the entity,a further step
was required.The position of where to focus was known,but not where to focus from.
A simple but working solution to this problem was to take the diagonal of the entities
bounding box and then zoom in to the object until the camera had the same distance as
the length of the diagonal to the object.The distance was measured against the objects
center.This technique worked fairly well but did not take the entities and cameras
rotation to consideration as Autodesk Maya[6] does for example.
2.3.3 Entity Grouping
This feature lets the user group selected entities temporarily which enables editing multi-
ple attributes at the same time and also rotation of the entities.Normally entities rotate
around their own axis when not grouped.The goal was to speed up repetitive tasks.
This was probably the most time consuming task since there was a lot that had to be
learnt about the level editor code design.The bounding box was to be extended over
all entities,the placement utility should be shown in the center of the new bounding
box and,the most important part,the entities rotation should be handled dierently.
This may not look very dicult at rst glance,but since it was to be implemented in a
more or less unfamiliar environment (code and structure) it can take some time.It was
important to know how the structure was meant to work,else it's a big risk you make
bad solutions that never was meant to be and the structure will loose more or less of its
consistency which in turn may result in code that is harder to understand.
2.4.Test of Concept 7
2.4 Test of Concept
The test was to create a game prototype designed by Marcus Sundqvist for Frostware
AB.The game created was a MOBA game which can be compared with famous games
like DOTA,League of Legends and Heroes of Newerth.
2.4.1 Preparations
First the environment has to be set up,which in this case was a new Nebula3 project.
This involves a CMake setup specic for Nebula,SVN setup and a basic mockup level.
2.4.2 The Game Prototype
This game was going to work as a prototype and therefore the design and implementation
was adapted to t thereafter.Parts of the prototype that the author was not involved in
will not be explained in further detail.
Design To start with the basics,dierent game states were needed.Since no fancy
GUI and other states were needed,a basic state of the game was made called PlayState
were the user could simply play the game.Since this was a network based game,it was
decided to create internal network states containing states such as host game,join game,
playing,and failed to connect states.
Figure 2.1:The simple start screen.
2.4.Test of Concept 8
These elements were decided for the prototype:
 At least 1 playable character.
 At least 1 enemy character.
 At least 1 playable level (created with the level editor).
 A simple networked environment.
Figure 2.2:The test level used during development.
Implementation Implementation was started with the most important elements rst:
A character for each player was needed with the ability to collide,handle input,show
graphics and a camera attached to it.The game is all about the characters and their
skills.Two dierent types of character entities were being used:One for the local player
and also another type for enemy characters that is being updated through the network.
Only the local player needs to record input and have the camera attached.The camera
has a xed and slightly tilted position that can't be rotated or manipulated except for
zoom possibilities,it only follows the local player.
The network implementation was made with ZebNet together with a network manager
class.The network manager handles events like when someone connects,disconnects and
also manages all the entities'states and actions.To keep it short,player entities are
created when a user connects,while disconnects deletes the entity corresponding to the
disconnected player.
Results and Future Work
In this chapter,the results of the created content are presented together with an evalua-
tion on the external tools used during the process.Finally research material are presented
from the separate tool investigation.
3.1 The Created Tools
The results of the tool creation process was mainly the work done on the level editor.
The resulting main features in the level editor was the improved camera functionalities
and the entity grouping system.Here is a list of the most interesting results of these
Results of the improved camera
 Improved controls - The camera behaves more like Autodesk Maya than before,
which was the desired result.
 Improved focus abilities - The two created functions provides possibility to set focus
on objects with either preserved zoom level or a close zoom level.
 Improved orientation - Smooth camera transitions improves the users experience of
Results of the entity grouping system
 Multiple attribute editing - Enables the user to edit multiple entities at the same
time,decreases repetitive tasks.
 Multiple rotation - Enables the user to rotate multiple entities on a shared axis,
decreases repetitive tasks.
 Shared bounding box - A visual bounding box surrounding all grouped entities
appears when in group mode.
3.2.The Prototype 10
Figure 3.1:The level editor in action.
Abstract results Apart from the more concrete results of the level editor a lot of
feedback was received during and after the process.From the very beginning,there
were a lot of bugs and there was no way of setting camera focus on an object.The
possibilities to move around with the camera worked for looking at dierent entities,but
the focus functionality was highly desired.It made working with the level editor less
frustrating and added a nicer feel to the whole work process.The possibility to change
multiple attributes at the same time was also a very appreciated feature,even though its
existence wasn't known to the users until much later of the implementation due to lacking
documentation.Together with the other work on the level editor its overall work ow has
improved in a very promising way.
3.2 The Prototype
The resulting game prototype met all the requirements that had been set up.It con-
tained many of the planned elements and functionalities that were desired and,most
important of all,served its main purpose of testing the created tools.In total,3 levels
were created including a test level with the level editor tool.The game itself contained a
playable character and environmental obstacles.The characters have the ability to walk,
jump,dodge and attack.All this in a networked environment with the usual host and
join functionalities.A settings manager was also created for the level designer,where
the user could adjust important values and attributes in the game to get the ne tuned
gameplay that was desired.
3.3.Evaluation of External Tools 11
Figure 3.2:The'nished'state of the prototype.
Abstract results This process was to test the tools created and the main tool to test
was the level editor.Some problems and bugs were found which had to be taken care of
immediately.These kind of problems delayed the prototype implementation enough to
be of concern.Other than the level editor,several smaller tools were planned but weren't
implemented due to the lack of time.Instead of creating specic tools as a character
creator tool,everything was controlled by the settings manager through XML les.This
wasn't really a sophisticated/optimal solution for the user,but since the time span was
short and the solution fully functional,that was the way it was decided to be done.
3.3 Evaluation of External Tools
These are the results of the external tool usage during the projects and their outcome.
Frameworks and libraries are excluded from this section.
SVN By using SVN it was managed to save a lot of distribution eorts.This was the
resulting work ow achieved with SVN:
Person A:Made changes to File1.Commits work.
Person B:Updates and receives the updated le with the changes.
Person B:Commits changes to File2.Commits work.
Person A:Updates and receives a con ict.Resolves con ict and commits.
3.3.Evaluation of External Tools 12
This example shows the usual work ow for the projects.A con ict may appear if the
tool couldn't merge the working copy of the le with the updated version.This can be
solved by comparing the two versions and creating a new output le manually.For this
project there was a tool called WinMerge that was used and that allows the user to easily
compare and merge the code.
 Makes it easy to share and distribute a project to all of it's members.
 Possibility to revert to older versions.
 Possibility to branch project.
 Logging and much more...
 Merges may not always be successful even though it's not con icting.Bugs may
appear this way,both run-time and compile errors.
 Merge branches can be time consuming.
 Easy to commit code that doesn't work or miss les resulting in non working builds.
Can be time consuming.
Redmine Redmine created structure to the projects through its managed tasks.With
its management there was a clear overview of all tasks with their progress,priority and
other relevant information regarding the tasks.There was also a possibility to see which
tasks were assigned to whom and which tasks were free.This tool has resulted in better
overview and management of the projects even though it may suite bigger projects even
CMake Use of CMake resulted in saved time for the projects.CMake creates a build
of the project with all the right settings,libraries,paths etc.This has however to be
specied in a le called CMakeLists.txt.To learn how to use CMake properly can be a
time consuming task but it saves even more time and eort in return.
3.4.Research Results 13
3.4 Research Results
The main research objects was Unity3D and version control tools.A very simple rst-
look comparison between Unity3D and Nebula3 was made and a comparison between
two main approaches to version control.
Unity3D Comparison
This comparison is mainly on tools regarding the level editor but also on parts that im-
prove the work ow.Since Nebula3 doesn't have many development tools yet,the results
of this comparison was meant to show what can be achieved with a well developed set of
What made the process with Unity3D faster?
 No tool switching - Everything can be created inside the editor.
 Applies immediately - All changes take action immediately which also applies to
textures,models and other loaded les.
 No compiling - The game can always be executed directly in the editor in an instant.
It's fast and easy to test new content.
 Drag and Drop - Possible to drag and drop components and graphics both in the
dierent browser windows but also in the game window.
Unity3D has put a lot of eort to make their system as fail proof as possible.It's really
hard to do any major mistakes in Unity3D since it will tell you right away when you do.
This together with a well written documentation[7] made the learning process very fast.
The result of this comparison shows clearly that a complex tool with high quality makes
a noticeable dierence.
Version Control Comparison
During the project,SVN,a centralized version control system was used.However,there
exists another type of version control that is distributed or decentralized.Lately,many
developers are arguing for these systems and describe distributed systems as the future
of version control[8][9][10].Examples of distributed version controls software are Git and
The main dierence between these two systems is that on a centralized system you
have a main repository on the server and use a client/server model when it comes to
communication.A decentralized/distributed system on the other hand has a repository
for each individual contributor.Each individual can commit to its own repository and
later push his/her changes to the main repository (if there exist such a repository).A
3.5.Future Work 14
decentralized system uses a peer-to-peer model were each individual can share his/her
changes with another individual without the need to commit the work to be shared on
the main repository.Another big dierence was that a centralized system was seeing
everything as dierent versions and decentralized systems sees everything as changes and
stores change sets.When merging,centralized systems do it from the outcome of the
dierent version of each le when a decentralized system does it from only the changes
Abstract results Many developers that have talked about distributed version con-
trol systems have been doubtful about it at rst but tested it anyway.Now they are
talking about how good they are and recommend it highly.Joel Spolsky even created
a"fromSVN to Mercurial"guide in his excitement of this new way of version control[11].
Sometimes testing new ways of working with new tools may be a great risk.This often
involves time loss during the learning process and even worse if it appears that the tool
isn't working as intended.Being brave sometimes and bringing new ways of working
to the table may result in very positive results though,which was the case for these
3.5 Future Work
There is still much to learn about tools and how to use them for best results.When
it comes to the work itself,Nebula3 is still in need of tools and the work will probably
continue for the goal of an intuitive environment while challenging the students in other
things than struggling with tools.
Decisions on what will be done with the game prototype made for Frostware AB are
unclear at this state.The company might continue working on it if they see potential in
the game.If they do,it is for the goal of pitching the game to a publisher that could
support the development.
Discussion and Conclusion
4.1 Tools Significance
It is hard to nd an absolute answer to the questions that were brought up in this the-
sis,but looking at the results of all dierent parts in this thesis one might grasp some
connections between the dierent results and ndings.
Both the creation process and the research has conrmed that well produced tools with
high quality results in great improvements.With this,the user can concentrate more on
his actual work and creativity instead of unnecessary and time consuming problem solv-
ing.This seems to be really obvious,tools that save time and money,why are they not
used as much as possible?As the results show,creating the tools takes time.Learning
to use external tools also takes time.What if the created tools took much time to create
and the usage of it was small or insignicant?What if the external tool turns out,after
some days of learning to use the tool,to be completely useless to the intended usage?
In this case,time and money will be lost as well.In order to gain time and money from
tools you have to invest with time and money.It is like any other investment.How do
you decide when and how to invest?This is something that is learnt with experience and
research.There are no clear answers since there are too many variables that dier in this
case.Tools need to be designed and implemented depending on the need and purpose.
When it comes to external tools,one must be sure to learn if it's applicable.One way
to be sure of the tool's quality is to look at its client base.Many companies for instance
are using Perforce and Hansoft[12].
When investing in tools,one might rather be conservative and rely on tools that always
have been used within the company.This may be a safe decision,but one should not be
afraid to try new software and tools that have received good critics.To invest in what
may be the future can have its benets as presented in this thesis.
4.2.Environmental,Ethical and Social Considerations 16
4.2 Environmental,Ethical and Social Considerations
Software development tools have no direct in uence on the environment or have any
ethical relevant side eects.Tools can though have some social eects,which has also
been experienced during the tool development phase of this project.Version control
systems are very handy tools,but when someone else makes a mistake and shares it,it
can lead to discussion and blaming of others.This could also be caused by merges and
it's easy for two people to blame each other for the produced error,which in some cases
may create a negative atmosphere.
4.3 Conclusion
Investing in tools has its risks and benets but it's clear that it's often not a matter of
investing or not,it's rather a question of how to invest.There is no absolute answer to
that,but one way of making decisions about such investments is by using experience and
research,but also by copying other successful companies tool set-up.
Quality does improve and the work in this thesis has conrmed that its benets are
worth it in the long run.For shorter projects,one may consider to have lower priority
on quality and most of all complexity.
Are tools signicant?Yes,they are one of the main elements for saving time and money.
As long as the awareness of their possible time consuming risks exists,the chances of
successful use are high.
[1] - Game Industry Salary at Game Career Guide,2007
.php (2012-05-29)
[2] - The Top 10 Game Engines at Develop Online,2009 (2012-05-29)
[3] - Games Made With Unity at Unity3D,2012 (2012-05-29)
[4] - The Importance of Source Code Control in Custom Systems Integration Projects by Kevin Hiebert,2006
Paper.pdf (2012-05-29)
[5] - Purpose of Version Control at Bazaar Documentation,2005 (2012-05-29)
[6] - Autodesk Maya,2012
[7] - Unity Documentation at Unity3D,2012
[8] - Distributed Version Control is here to stay by Joel Spolsky,2010 (2012-05-29)
[9] - My GIT Work ow and Why You Should Use It by Greggman,2011 ow-and-why-you-should-use-git/(2012-05-29)
[10] - Choosing a Distributed Version Control System by Dave Dribin,2007
[11] - Mercurial Tutorial by Joel Spolsky,2007
[12] - Production Tool Round Up at Develop Online,2009 (2012-05-29)
External Tools:
[14] - Redmine,Jean-Philippe Lang,2006
[15] - CMake,2012
[16] - TortoiseSVN:Subversion Interface Extension,2012
[17] - Qt:A cross-platform application and UI framework,Nokia Corporations,2008
[18] - ZebNet,Sebastian Salonen,2012
[19] - Nebula3,LTU Skelleftea,2012
Unity3D Tutorials by Tornadotwins:
Part 1: (29-05-2012)
Part 2: (29-05-2012)
Part 3: (29-05-2012)