BACHELOR THESIS
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 game-development
Sebastian Salonen
Lule˚ a University of Technology
Dept. of Computer Science and Electrical Engineering Div. of Systems and Interaction
June 5, 2012
A BSTRACT
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 flow of 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 effects 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 influence?
This thesis analyses, tests, and shows different implementations of tools for game de- velopment in order to find their significance in the game production pipe-line and what relationship tools have to the total production cost of a game project.
ii
S AMMANFATTNING
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 arbetsfl¨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 effekt? 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 finna verktygens vikt i spelproduktionens pipe-line och vad de har f¨or betydelse f¨or den totala produktionskostnaden i ett datorspelsprojekt.
iii
P REFACE
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
iv
C ONTENTS
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 Significance . . . 15
4.2 Environmental, Ethical and Social Considerations . . . 16
4.3 Conclusion . . . 16
Chapter 5 – References 17
Chapter 6 – Appendix 19
C HAPTER 1 Introduction
1.1 Background
Game production is a very costly process[1], improving its workflow 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 offer great benefits, but also problems.
The work has consisted of three different 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 significance in the game-development process? Is it worth investing valu- able time and money for quality tools? What’s the difference 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 benefits, problems and consequences of using tools.
1
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)
C HAPTER 2 Method and Materials
Since the project have consisted of three different 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
• Workflow
• 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.
3
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 offered 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 flexible way both from colleagues and users.
CMake was used for build management of the projects. CMake offered a great set of functionality to the project with features like generation of project files, ability to add custom build rules, settings and much more.
TortoiseSVN was used for project distribution and version control. SVN offered the project a flexible workflow 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 significant 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 first 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 from both 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 first. What was done the first 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 final position. Each step becomes smaller each time, which results in a effect of slowing down. This was the formula:
newP osition = currentP osition + (destination − currentP osition) ∗ 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 fixed 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 differently.
This may not look very difficult at first 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 specific 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 fit 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, different 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 first:
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 different 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 fixed 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.
C HAPTER 3 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 features.
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 orientation.
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.
9
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 different 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 workflow 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 fine tuned gameplay that was desired.
3.3. Evaluation of External Tools 11
Figure 3.2: The ’finished’ 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 specific tools as a character creator tool, everything was controlled by the settings manager through XML files. 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 efforts. This was the resulting workflow achieved with SVN:
Person A: Made changes to File1. Commits work.
Person B: Updates and receives the updated file with the changes.
Person B: Commits changes to File2. Commits work.
Person A: Updates and receives a conflict. Resolves conflict and commits.
3.3. Evaluation of External Tools 12 This example shows the usual workflow for the projects. A conflict may appear if the tool couldn’t merge the working copy of the file with the updated version. This can be solved by comparing the two versions and creating a new output file 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.
Pros
• 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...
Cons
• Merges may not always be successful even though it’s not conflicting. 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 files 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 better.
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 specified in a file called CMakeLists.txt. To learn how to use CMake properly can be a time consuming task but it saves even more time and effort in return.
3.4. Research Results 13
3.4 Research Results
The main research objects was Unity3D and version control tools. A very simple first- 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 workflow. 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 tools.
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 files.
• 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 different browser windows but also in the game window.
Unity3D has put a lot of effort 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 difference.
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 Mercurial.
The main difference 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 difference was that a centralized system was seeing everything as different versions and decentralized systems sees everything as changes and stores change sets. When merging, centralized systems do it from the outcome of the different version of each file when a decentralized system does it from only the changes itself.
Abstract results Many developers that have talked about distributed version con- trol systems have been doubtful about it at first but tested it anyway. Now they are talking about how good they are and recommend it highly. Joel Spolsky even created a ”from SVN 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 developers.
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.
C HAPTER 4 Discussion and Conclusion
4.1 Tools Significance
It is hard to find an absolute answer to the questions that were brought up in this the- sis, but looking at the results of all different parts in this thesis one might grasp some connections between the different results and findings.
Both the creation process and the research has confirmed 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 insignificant? 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 differ 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 benefits as presented in this thesis.
15
4.2. Environmental, Ethical and Social Considerations 16
4.2 Environmental, Ethical and Social Considerations
Software development tools have no direct influence on the environment or have any ethical relevant side effects. Tools can though have some social effects, 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 benefits 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 confirmed that its benefits 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 significant? 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.
C HAPTER 5 References
[1] - Game Industry Salary at Game Career Guide, 2007
http://www.gamecareerguide.com/features/416/the game industry salary survey .php (2012-05-29)
[2] - The Top 10 Game Engines at Develop Online, 2009
http://www.develop-online.net/features/516/THE-TOP-10-GAME-ENGINES-NO4-Unity-3D (2012-05-29)
[3] - Games Made With Unity at Unity3D, 2012
http://unity3d.com/gallery/made-with-unity/game-list (2012-05-29)
[4] - The Importance of Source Code Control in Custom Systems Integration Projects by Kevin Hiebert, 2006 http://www.smartcardinc.com/PICS Source Code Control White Paper.pdf (2012-05-29)
[5] - Purpose of Version Control at Bazaar Documentation, 2005
http://sourcefrog.net/projects/bazaar-ng/doc/purpose.html (2012-05-29)
[6] - Autodesk Maya, 2012
http://usa.autodesk.com/maya/ (2012-05-29)
[7] - Unity Documentation at Unity3D, 2012
http://unity3d.com/support/documentation/ (2012-05-29)
[8] - Distributed Version Control is here to stay by Joel Spolsky, 2010 http://joelonsoftware.com/items/2010/03/17.html (2012-05-29)
[9] - My GIT Workflow and Why You Should Use It by Greggman, 2011
http://games.greggman.com/game/my-git-workflow-and-why-you-should-use-git/ (2012-05-29)
[10] - Choosing a Distributed Version Control System by Dave Dribin, 2007 http://www.dribin.org/dave/blog/archives/2007/12/28/dvcs/ (2012-05-29)
[11] - Mercurial Tutorial by Joel Spolsky, 2007 http://hginit.com/ (2012-05-29)
[12] - Production Tool Round Up at Develop Online, 2009
http://www.develop-online.net/features/394/Production-tool-round-up (2012-05-29)
17
18
External Tools:
[14] - Redmine, Jean-Philippe Lang, 2006 http://www.redmine.org/ (2012-05-29)
[15] - CMake, 2012
http://http://www.cmake.org/ (2012-05-29)
[16] - TortoiseSVN: Subversion Interface Extension, 2012 http://tortoisesvn.tigris.org/ (2012-05-29)
[17] - Qt: A cross-platform application and UI framework, Nokia Corporations, 2008 http://qt.nokia.com/ (2012-05-29)
[18] - ZebNet, Sebastian Salonen, 2012
http://focus.gscept.com/2012ip17/ (2012-05-29) [19] - Nebula3, LTU Skelleftea, 2012
http://focus.gscept.com/nebula/ (2012-05-29)
C HAPTER 6 Appendix
Unity3D Tutorials by Tornadotwins:
Part 1: http://www.youtube.com/watch?v=5-X-Ebh1kYA (29-05-2012) Part 2: http://www.youtube.com/watch?v=5wxe1IUu5QA (29-05-2012) Part 3: http://www.youtube.com/watch?v=gUZOZP-sgng (29-05-2012)
19
