Sami Krouvi
IMPLEMENTATION OF
A VIDEO GAME COLLECTION Games for Educational Use
Bachelor’s thesis Information Technology / Game Programming
2019
Author (authors) Degree Time
Sami Krouvi Bachelor of October 2019 Engineering Thesis title 37 pages Implementation of a video game collection 2 pages of appendices Games for educational use Commissioned by
South-Eastern Finland University of Applied Sciences Ltd Supervisor
Niina Mässeli, Senior Lecturer Abstract
The objective of this thesis was to design and implement a video game collection for educational use, to be used as an educational tool at GameLab, a learning environment of South-Eastern Finland University of Applied Sciences, in the education in game programming.
The thesis was conducted focusing on the implementation. The primary tools used in implementing the video game collection were the Unity 3D game engine along with the Microsoft Visual Studio integrated development environment.
This thesis details the design and implementation process of the video game collection as a whole. Instead of describing the development process of each individual game included in the collection, this thesis aims to describe the process of creating a video game collection and which factors need to be taken into consideration when making one, by providing a detailed description of the implementation process.
The video game collection was developed as a result of this thesis. During its development, numerous changes occurred affecting the structure of the games included in the collection. The resulting video game collection should provide to be a capable educational tool and to be able to serve as a platform for future development. However, its capabilities are only known once it has been adapted into its intended use.
Keywords game development, programming, modularity, Unity 3D
CONTENTS
ABBREVIATIONS & GLOSSARY ...... 5
1 INTRODUCTION ...... 6
1.1 Purpose of this thesis ...... 6
1.2 Approach to the subject ...... 7
1.3 Commissioner ...... 8
2 DESIGN ...... 8
2.1 Types of games ...... 9
2.2 Modularity & shared components ...... 11
2.3 Game design documents ...... 14
3 IMPLEMENTATION ...... 15
3.1 Tools & software used ...... 15
3.1.1 Unity 3D ...... 15
3.1.2 Microsoft Visual Studio ...... 16
3.1.3 Doxygen ...... 17
3.1.4 Blender ...... 20
3.1.5 Graphical software ...... 21
3.2 The games ...... 23
3.2.1 General structure ...... 23
3.2.2 Common components ...... 25
3.3 Code ...... 28
3.3.1 Core classes ...... 29
3.3.2 Commenting conventions ...... 30
4 CONCLUSIONS ...... 31
REFERENCES ...... 34
LIST OF FIGURES ...... 37
APPENDICES
Appendix 1. Table of elements included in types of games Appendix 2. Code commenting guidelines
5
ABBREVIATIONS & GLOSSARY
API Application programming interface, is an interface intended to simplify the building of software or extensions
Class A class is an extensible program-code-template for creating objects in object-oriented programming
CPU Central processing unit, is the electronic circuitry within a computer that carries out the instructions of a computer program
Debugging The process of finding and resolving defects within a computer program
Despawning The deletion of an entity from the game world
Gameobject An entity within the game world in Unity 3D
Inheritance The mechanism of basing an object or class upon another object or class
Instance A copy or an occurrence of any object or class
Instantiation The creation of an instance or instances
Method A code block that provides functionality
Prefab A template of an entity in Unity 3D
Respawning The recreation of an entity after its death or destruction
Rigging The preparation of a 3D model for skeletal animation
Scene A level in Unity 3D
Solution A project in Microsoft Visual Studio
Spawning The creation of an entity into the game world
UI User interface, enables user interaction
UV map The surfaces of a 3D model projected as a 2D image
UV mapping The act of creating a UV map or UV unwrapping
Variable A storage location for storing a value in programming
6
1 INTRODUCTION
Ever since video games became widespread in the 1980s, their usefulness in education has been studied, but only in the recent years have video games truly began seeing use as a serious educational tool rather than just being made for children alone. Video games used as such often focus on simulation, hence being called simulators, and enable training for various tasks in a safe way. What has not been studied, yet, is whether video games can be utilized in education in more ways than by just playing them, by examining their inner workings and through the process of re-creating them for instance.
1.1 Purpose of this thesis
This thesis was commissioned as a part of a project of larger scale. The goal of the project was to design and develop a video game collection, consisting of various games of different types, using Unity 3D as the primary development environment and to produce extensive enough documentation, along with instructions for each game, in order to allow the games to be recreated with the help of the instructions and some premade assets. Additionally, the goal was to also experiment with using the Git version-control tool and to include instructions for its usage in addition to the instructions for recreating the games. The purpose this video game collection, and the rest of the documentation, was to be developed for was educational use, with the intention of the end product being utilized as an educational tool in the education of future bachelor of engineering students at Xamk GameLab, for this reason, all the documentation produced for the end users were to be written in Finnish.
This thesis focuses on the implementation of the games included in the video game collection that was developed. Due to the scale of the project, theses of the same subject, though of different aspects of the project, with a different focus and approach, have been written, or are being written at the time of writing this thesis, by Juho Koponen (see Koponen 2019) and Jari Tervo, who made up the rest of the development team involved in the project.
7
The purpose of this thesis is to provide insight of the process of creating a video game collection, consisting of multiple relatively simple games, as opposed to just one, broader and more extensive game, by going through the design and implementation process of the video game collection that was developed step by step, providing a detailed description of what was done in each step. The aim of this thesis is not to serve as a guideline for making a video game collection but rather to demonstrate what needs to be considered when creating one and which kind of tools to use in addition to presenting some useful practices.
1.2 Approach to the subject
The development team consisted of three individuals, who had prior experience in working closely together, as the team had cooperated on multiple projects in the past, including a prototype of a training simulator and several smaller video game projects. Even though developing video games was nothing new to the members of the development team, this was a project of completely different scale, presenting new challenges. The approach to implementing the video game collection involved all the members of the development team drafting its general design first and then implementing the collection game by game. The implementation of the first game were to include all of the development team and the latter games were to be made by separate members of the team on their own.
The subject was approached with some prior experience in video game development with Unity 3D, although that experience being limited to only a couple of projects at the time. Extensive knowledge of C++ provided to be extremely helpful in using C# as the programming language. Additionally, experience in the creation of graphical assets existed already. However, very limited prior experience, or none at all, had been acquired in the usage of the Git version-control system and the Doxygen documentation generator.
8
1.3 Commissioner
South-Eastern Finland University of Applied Sciences, Xamk for short, was established in early 2017 when Kymenlaakso and Mikkeli universities of applied sciences merged. As a result, Xamk is the 5th largest university of applied sciences in Finland, and second largest in terms of budget, with 9400 students and 750 employees. Xamk has four campuses spread throughout the regions of Kymenlaakso and Southern Savonia in the cities of Kotka, Kouvola, Mikkeli and Savonlinna.
Xamk GameLab, located at the Kotka campus, is a learning environment for the education in game programming operating under the Information Technology unit of Xamk. GameLab operates in close cooperation with the local video game industry, which provides many possibilities in the form of projects and internships. GameLab is always utilizing the latest tools and methods in learning, providing the students with up to date information and knowledge, it is a place of unlimited learning as is the motto of Xamk.
2 DESIGN
Planning is an important part of any work as it guides the implementation, ensuring that the work can proceed smoothly and in the right direction. It defines the goals and sets the objectives and the directions needed to achieve those. (Akampurira 2014, 4-6.)
The design phase of the thesis work that took place can be broken down into three separate stages. In the first stage, a list of the types of games the video game collection were to include was to be established. In the second stage, a table was compiled that listed all the major components and functionalities of the games included in the collection. Finally, in the third stage of the design phase, a game design document was made for each game individually.
9
2.1 Types of games
The first course of action in designing the video game collection was to determine which types of games were to be included. The plan was to include ten different type of games from a varying selection of genres. What follows is a list of all the types of games that were to be implemented in the initial design with brief descriptions of their type and given genre.
Fighting game is a game which typically focuses on player versus player, or player versus computer, combat. Games of this genre often feature fast-paced action in the form of martial arts. It is also common for such games to contain a large roster of playable characters to choose from, each with varying moves and abilities. Typically, victory is achieved by depleting the opponent’s health or by knocking them out. (Matthews 2018; Racketboy 2019.)
First-person shooter game, or FPS for short, is a game that is depicted and therefore also played from a first-person point of view instead of a third-person perspective. Games of this genre almost exclusively center on gun- or projectile weapon based combat, hence called shooter, depicted through the eyes of a protagonist. (Fagerholt & Lorentzon 2009; Matthews 2018.)
Endless runner is a sub-genre of the platformer genre, described below, and games of this genre are linear in design with continuous gameplay without an end point. This type of games often do not consist of levels or stages nor do they feature any pauses or resting points. It is characteristic for games of this genre to keep getting faster and more difficult over the course of play eventually resulting the game being too difficult for the player. (Momoda 2015.)
Platformer game is a game in which the player avatar interacts with platforms throughout the game. The gameplay in this type of game mainly consists of running, jumping and falling. Games of this genre are usually played from a third- person perspective. (Matthews 2018.)
10
Racing game is a type of game in which the player, or players, race against an opponent, or opponents, either computer or player controlled, or against the clock (Matthews 2018).
Real-time strategy game, or RTS for short, is a game played from a top-down perspective that requires the player to manage units and collect resources. Traditionally this type of game involves the player building a base, managing the gathering of resources by assigning units to do so, spending the gathered resources to create units of varying cost and abilities and to research different technologies that boost the units and structures, and commanding units in battle against the opposing forces. (Adams 2012; Dobrowolski et al. 2014; Matthews 2018.)
Shoot ‘em up, also known as shoot-em-up, or shmup for short, is a sub-genre of the shooter genre and games of this genre typically focus on the player destroying overwhelming numbers of enemies. These games are played from a third-person perspective viewed from the top or the side. While the player can move his or her player avatar freely on the screen, the orientation of the player avatar is always fixed to that of the primary scrolling axis as in games of this genre the player is unable to control the camera movement as this is dictated by the game which usually moves the camera along the primary scrolling axis at a constant pace for the most of the game. (McMillan 2013.)
Survival horror game is a game that uses mature themes to portray grisly and gruesome setting that most often involves considerable amounts of blood and gore. The gameplay is designed to keep the player on his or her toes constantly through game mechanics. The most usual game mechanic to be used for this is having only limited resources, such as ammunitions or energy. This type of game is usually intended only for mature audiences. (Matthews 2018.)
Top-down twin-stick shooter game is a game that falls under the shooter genre and, as the name suggests, is played from a top-down perspective with a controller or a gamepad that has two analog joysticks for input. Games of top- 11 down shooter genre are most often based on a set of lives instead of what would generally be called hit points and after the player has spent all the lives the game ends. (Matthews 2018.)
Tower defense game is a game in which the player must defend a target point from waves of enemies, which usually move along a pre-defined path, by placing down towers that try to stop the enemies from advancing. The towers usually have varying abilities ranging from slowing the enemies down to completely eliminating them in a single shot depending on the game. In most games of the genre, towers are bought with credits awarded by surviving waves or stopping enemies. (Matthews 2018.)
2.2 Modularity & shared components
Once a list of all the types of games to be made was established, it was essential to analyze the types of games and determine the components and functionalities each type of game would contain. In order to do so, a table of said components and functionalities was compiled. However, before going into the details of that process, one must define what modularity is when it comes to video games.
Modularity, in video games, is the concept of using reusable and interlinkable modules to form larger entireties. Correct implementation enables the creation of diverse structures and environments by using only a limited number of modules. (Modular concepts for game and virtual reality assets 2018.) Modularity can exist on multiple levels and in many forms. Code blocks, scripts, assets or entire components of a game can be modular and reusable. (Mader 2005; Burgess & Purkeypile 2013; Coss 2015; Modular concepts for game and virtual reality assets 2018.)
Achieving modularity requires one to look for alternative methods of development. One such method, programming wise, is a design pattern known as the object/component model as opposed to the more commonly used inheritance based models in object-oriented programming. In the object/component model each object, that a game consists of, is an instance of 12 the same class unlike in the inheritance based models where multiple separate classes exist. What makes each object unique, are the components attached, instead of the class of the instanced object. The components are used to house attributes and functionalities, and to define the behaviors of the object a component is attached to. (Coss 2015.)
When it comes to graphical assets, be it 2D or 3D, achieving modularity requires setting up certain conventions. The primary convention is the unit system being used for the assets, or in other words, the scale. The unit system used can either be bound to a real life unit of measure, like meters, or use a completely imaginary unit, often simply called unit, with no relation to any real life unit of measure. Grid systems based on these unit systems are used in different editors, modelling software and level editors, used to work with the assets. With the use of meters, a standard grid step would be exactly one meter, or in multiples of ten, whereas with imaginary units this is not always the case. While working with imaginary units, a grid step bound to multiples of a value other than ten may be used, multiples of two, or the power of two, being the most common (Table 1). (Mader 2005.)
Table 1. Some powers of two and their corresponding grid step values (Mader 2005) 2x = Grid step 20 = 1 Unit 21 = 2 Units 22 = 4 Units 23 = 8 Units 28 = 256 Units 210 = 1024 Units
Multiples of two are commonly used in computing, as that is the basis of binary, and in things like texture resolutions for video games. Using a grid bound to the power of two means that a scale must be established, as the grid units are not directly bound to any real life unit of measure, before any assets are created. Usually, this is done by determining the size of a player character to be used as a reference point for everything else. Even though it may seem bizarre to use a 13 system like this for measurement, using power of two can actually be very beneficial when it comes to creating modular and interlocking assets because doing so enables the assets to tile well with each other even when the assets are of different size or have a different footprint for as long as all are in power of two. (Mader 2005; Burgess & Purkeypile 2013.)
Modularity affects the development and the final outcome of a product, in this case a video game, in many ways. Utilizing modularity can provide flexibility and make the work flow faster by streamlining production. It allows to save memory and improve load times, hence being memory efficient, as work is reused where applicable. Modularity also enables a small development team to work on a more sizable product while keeping the development time reasonable. However, there are some drawbacks. Utilizing modularity means that additional time is needed for planning at the beginning of the development cycle. Development conventions set during planning may be restrictive and can make the end product contain repetitive, boxy or mechanically aligned elements that make the end product less appealing. In addition, setting up development conventions means that each member of the development team has to familiarize themselves with the said conventions in order to work and utilize them efficiently. (Mader 2005; Burgess & Purkeypile 2013; Modular concepts for game and virtual reality assets 2018.)
As stated previously, a table was compiled showing all the major components and functionalities, or elements, of each game included in the video game collection (Appendix 1). The table was used to determine which elements were only present in a single game and which were present in multiple, thus having the need to be made modular in order to avoid making an excessive number of elements with very similar or even exact same behavior. Observing the table shows that systems like health and damage along with hit detection and spawning, respawning and despawning, are present in virtually every game, whereas camera rotation control or follow movement systems are present only in a few games.
14
2.3 Game design documents
A game design document is a written document drafted during the early stages of a video game’s development cycle. The aim of the document is to list every aspect of the game being developed in enough detail. The document generally consist of written descriptions, lists, images, graphs and charts conveying sufficient information of each aspect. The purpose of a game design document is to serve as the instructions for the whole development team involved in a game’s development, detailing what each aspect is, how it should work and what it should look and feel like, thus it is essential that the language used in the document is clear enough to avoid any misinterpretation. Thea idea is to utilize the document throughout the development cycle, not just at the start, and update the document as the development progresses forward. Even though the document is meant to serve the development team as a whole, it may be ideal to have just one person in charge of maintaining it to preserve the integrity of document. (Freeman 1997; New York Film Academy 2014; Sayenko 2015; Nuclino 2018.)
A game design document primarily answers the questions what and why. It is used to identify the core of the game being developed, what the game is about and why is it worth making. The document should contain information of every aspect of the game, from the story, if it has one, down to the gameplay mechanics. It should map out the overall flow of the game and define the main goals in sufficient enough detail for the features to be implemented but not in too much detail to allow tweaking and refining the features over time. Typically a game design document includes at least an overview of the game, a description of the game and a list of all the different elements present in the game along with details. (New York Film Academy 2014; Sayenko 2015; Nuclino 2018.)
In the third, and final, stage of the design phase of the video game collection, a game design document was made for each game individually, as stated previously. The documents were utilized, first and foremost, to have a clear understanding of what each game was about and what features it would include, serving as a guideline during the implementation of the game. 15
3 IMPLEMENTATION
What followed the design phase of the thesis work was the actual implementation of the video game collection. The implementation phase consisted of creating the video games designed earlier and producing comprehensive enough documentation to go along said games, which involved the use of several different pieces of software.
3.1 Tools & software used
The implementation phase involved the use of several different pieces of software, for various different tasks. These tasks consisted of such as piecing the games together within a software development environment, writing code within an integrated development environment and creating 3D models through the use of 3D modelling software.
3.1.1 Unity 3D
Unity 3D is a cross-platform real-time development environment and a game engine that supports both 2D and 3D development offered by Unity Technologies. The game engine, called Unity Engine, has an extensive multiplatform support that extends over 25 different platforms ranging from traditional desktop platforms and home consoles to mobile and web applications. The development environment, called Unity Editor, is available on Windows and Mac OS X operating systems with Linux support being in a preview stage, as of 2019. (Unity Technologies 2019.)
The Unity Editor is feature-rich and highly flexible editor that covers many aspects of game development. It offers integrated Microsoft Visual Studio scripting support as well as tools for animating and easy user interface creation along with flexible graphics and a powerful physics engine. In addition to all this, the Unity Editor supports various source file formats, again providing flexibility. (Unity Technologies 2019.)
16
Unity 3D was used in the implementation phase of the thesis work as it was deemed most suitable out of all the available game engines for its availability and capabilities. Another close alternative was the Unreal Engine 4 from Epic Games. However, Unity 3D was preferred, as working with it was already somewhat familiar and the overall usability of its user interface had been found more to liking over the user interface of the Unreal Engine 4. Unity 3D was also chosen especially due to its integrated Microsoft Visual Studio scripting support and C# language support.
The Unity Editor was used to construct and piece together the video games of the video game collection and served as the backbone of development. Within the Unity Editor, scripts and graphical assets produced in other software were combined into functioning gameobjects that the games consisted of. It was also used to build and compile the finished games at the end of the development cycle.
3.1.2 Microsoft Visual Studio
Microsoft Visual Studio is an integrated development environment, or IDE for short, developed by Microsoft. It is a versatile tool used to develop computer programs, websites and other types of applications that require any type of coding. Microsoft Visual Studio supports coding in a wide variety of languages, including, but not limited to, C#, Visual Basic, C++, HTML and JavaScript. The primary application of Microsoft Visual Studio is the writing of code, however, it can also be used for debugging, refactoring and analyzing code. Coding with Microsoft Visual Studio is made easier through the aid of features such as the IntelliSense intelligent code completion that aims to speed up the coding process by reducing typos and errors in the syntax through the use of auto completion popups and hints. Microsoft Visual Studio features a built-in compiler, and as such, allows one to build and compile source code written, in order for it to be deployed for use in applications. (Microsoft 2019.)
Microsoft Visual Studio was chosen as the primary coding tool for the thesis work for its excellent compatibility with Unity 3D, despite another IDE, MonoDevelop, 17 being directly shipped with Unity 3D at that time. Later versions of Unity 3D shipped with Microsoft Visual Studio Community instead. (Unity Technologies 2019.) Microsoft Visual Studio was favored as there had been a substantial amount of experience in using it in the past making it an ideal tool to be used in terms of efficiency and practicality as learning to use another IDE would have taken its time getting adjusted to.
The implementation of code relied heavily on the use of Microsoft Visual Studio as all the source code written for the games of the video game collection was produced with it. Used in conjunction with Unity 3D, serving as the scripting editor of choice, made the use of Microsoft Visual Studio extremely streamlined. Any script present in the games could simply be clicked within the Unity Editor and Microsoft Visual Studio would start up with the entire solution open, allowing one to edit any script that was part of the solution with ease through the use of the integrated Solution Explorer.
3.1.3 Doxygen
Doxygen is a tool for writing software reference documentation, hence being called a documentation generator, developed by Dimitri van Heesch. According to Van Heesch (2018), “Doxygen is the de facto standard tool for generating documentation from annotated C++ sources”. In addition, Doxygen also supports other popular programming languages such as C#, Java and Python. Doxygen can generate documentation in HTML format, for online use, and in LATEX format, for offline use, or generate an output as RTF, PostScript, hyperlinked PDF, compressed HTML or Unix man pages. The documentation is created from a set of source files from which it is extracted directly by Doxygen. This involves the use of some special formatting within the source files (Figure 1). (Van Heesch 2018.)
18
Figure 1. An example of code containing Doxygen comment blocks with special formatting
Doxygen can be configured in numerous ways, even to extract the code structure from undocumented source files if required. However, in its default configuration Doxygen searches the source files and extracts all variables, methods and comment blocks, formatted in a special way, and uses the extracted data in generating the documentation. The special formatting required for the comment blocks is entirely dependent on the configuration used but typically involves using special symbols. A Doxygen comment block, in a C# source file for example, may consist of a standard C++ style comment, consisting of two forward slashes, followed by an additional forward slash or an exclamation mark. These comment blocks must be placed directly above the member variable or method they describe. Certain keywords are used within the Doxygen comment blocks to determine the type of the data contained and how said data is displayed in the output (Figure 2). (Van Heesch 2018.)
19
Figure 2. An example of documentation output generated with Doxygen
Without any data from specially formatted comment blocks, Doxygen is able to generate basic documentation that displays the name, type and class of any given member variable or method. Doxygen also generates dependency graphs, inheritance diagrams and collaboration diagrams automatically that help to visualize the relations between different classes and their members. However, in order for the documentation output to include more extensive information, Doxygen comment blocks shall be used. This is where the keywords come in, as they are used to format the data into clear and understandable, human-readable format. The keywords can also be used to exclude data from the documentation output for the purpose of code only comments, or tooltips used in the IDE. (Van Heesch 2018.)
Doxygen was utilized in the thesis work in the creation of extensive documentation of the video game collection’s code base. Every member variable, method and class alike was documented well. Descriptions were written in the form of Doxygen comments using the details keyword and the brief keyword as well in the case of classes. For all methods that were of type other than void, possible return values were detailed for the documentation through the use of the return keyword. All this was done to ensure that the end users of the video game collection would have a better understanding of what each bit of the code does, or what it should do.
20
3.1.4 Blender
Blender is a 3D computer graphics software distributed and maintained by the Blender Foundation. The Blender software is provided free of charge and as open-source under the GNU General Public License making it a highly popular software with 6.5 million total downloads in the year 2017 alone. OpenGL is used for rendering Blender’s interface thus making Blender cross-platform compatible allowing it to be used on Windows, Linux and Mac OS X alike. (Blender Foundation 2019.)
Blender contains all the tools necessary for the entirety of the 3D pipeline. It includes tools for modelling, UV mapping, rigging, animation, simulation, rendering, compositing and motion tracking. Additionally, Blender also includes a video editor called Video Sequencer Editor, or VSE for short, providing basic, yet powerful tools for video editing. A game engine was also included but this feature was removed in Blender version 2.80. Blender also includes its own API for Python scripting allowing advanced users to customize the application to their liking and implement new functionalities. (Blender Foundation 2019.)
Blender was selected over other similar, yet commercial, alternatives, like the Autodesk 3ds Max for instance, primarily for its availability as free software and its compatibility with the Unity Editor. Having Blender installed on a machine along with Unity 3D allows 3D models to be imported into the Unity Editor in Blender’s native file format, as blend-files, without the need to export the models in FBX format first. Among other factors that contributed to Blender being used was existing proficiency in using the software. Despite Autodesk 3ds Max being used in the past as well, proficiency in using it was not quite at the level of proficiency reached with Blender, making Blender quicker and far easier to use.
The main usage of Blender in the thesis work revolved around 3D modelling, despite Blender being capable for various other uses as well. Every 3D asset used was created with Blender and no assets were used from other sources. Blender was used for the creation of the 3D models by means of both conventional box modelling and digital sculpting. After a model’s geometry was 21 completed it was UV unwrapped and a UV map was created for it and exported as an image to be used for texturing the model with the help of other graphical software. This was done to all models created. Additionally, some of the models had animations made for through the use of Blender’s animation tools.
3.1.5 Graphical software
In addition to using Blender for the creation of 3D models, the process of creating graphical assets for the video game collection required the use of some additional pieces of software. Two pieces of software, different in many aspects, were employed for this purpose, Krita, a painting program and Paint.NET, an image and photo editing software.
Krita is a professional-level free and open source painting program. It is designed for the creation of digital art, focusing on the creation of illustrations, concept art, matte paintings, textures, comics and animations. It is primarily intended for concept artists, illustrators, matte and texture artists, and the VFX industry but also for the amateur users alike. Krita is cross-platform compatible and available for Windows, Mac OS X and Unix-like operating systems. (Krita Foundation s.a.)
As a tool for creating digital art, Krita allows creating art files completely from scratch. It is optimized for frequent and prolonged use and as an application, it is designed to support the workflow and needs of an artist using it by supporting open standards and interoperating with other applications. Krita is a highly versatile program as its user interface can be customized entirely to suit the user’s preference. The main feature of Krita are the brush engines that enable the user to create his or her own brush presets along with the pre-existing brushes. These brushes are the primary tools of the vast toolset provided by Krita, used for the actual painting, whereas the rest of the tools are primarily used for making finer adjustments and to assist in the painting process. Other important, and at the same time major, feature of Krita is the ability to use layers and layer masks employed in non-destructive editing. (Krita Foundation s.a.)
22
Paint.NET is an image and photo editing software developed by Rick Brewster and maintained by him as the dotPDN LLC. Unlike Krita, Paint.NET is primarily designed for image and photo manipulation and is available only for Windows operating systems. It provides a simple, yet capable, set of tools for editing and creating images ranging from simple drawing tools to more complicated special effects. Paint.NET features support for layers and includes an unlimited undo, and redo, feature limited only by available disk space. Additionally, community made plugins are supported, providing more tools and features. Despite being a capable software, Paint.NET is lightweight and its user interface is intuitive enough for new users to learn in a short amount of time. (Brewster s.a.)
Krita and Paint.NET were selected as free alternatives to the more widely used commercial software, namely the Adobe Photoshop. These two pieces of software were deemed to collectively contain all the tools needed in the development of the video game collection, hence replacing the need for software like the Adobe Photoshop. Paint.NET was used as it was a piece of software that was already familiar and there had been experience in using it before at the beginning of the development. Its capabilities were well known and it being available only for Windows was not an issue as the development happened entirely in a Windows environment. To provide capabilities that Paint.NET lacked, Krita was used. Paint.NET does, for instance, include layers, but it does not allow non-destructive editing through the use of layer masks whereas Krita does.
Krita and Paint.NET were both employed in the process of creating 2D graphical assets, textures, for the video game collection. Paint.NET was used in creating less complex textures that did not require much detail or surface variation, textures used for vehicles and structures for example. Krita was used for the more complex texturing tasks, such as for creating textures for character models. Most of the texturing work consisted of creating textures for the 3D models, made with Blender, by employing UV maps created with Blender as overlays, thus allowing one to directly see how a model is mapped on the texture space. This technique also allows tracing the contours of a model with great accuracy. Additionally, some textures were created for use in the game’s user interfaces, 23 which required the use of transparency and alpha channels, along with some miscellaneous textures used for varying purposes, as scene backgrounds for instance.
3.2 The games
Implementation of the video game collection was started by solely focusing on creating the game that was deemed the most complex, out of all the games of the initial design, first. This was done for multiple reasons. Firstly, to have one game to serve as a template for the rest that were to follow in order to have a similar, uniform, structure for all the games. Secondly, to establish proper code and commenting conventions that were to be followed through the entirety of the work. Lastly, to ensure that what was being created met the criteria set for the video game collection by the commissioner. Once the first game was fully implemented and documentation created for it, the focus of the development was broadened and individual members of the development team began implementing a game each. Out of the ten games that were initially designed, nine had a member of the development team assigned as being responsible for that game’s development. This was to speed up development as the progress on an individual game was not directly connected to that of any other game that was part of the collection.
3.2.1 General structure
Initially, all the games were to be made out of a set of highly modular pieces, components. By rearranging and combining said components in a different way, like pieces of a puzzle, it would have been possible to create a completely new game. However, this fully modular approach was dropped early in the development as it was deemed unfitting for the purpose the end product were to be utilized in. Instead, each game was made as standalone, yet following the same general structure and utilizing some common components to reduce redundancy and to avoid having two or more different components with almost, or even exactly the same functionality.
24
Despite the games being made as standalone, they were still implemented within a single Unity project, as separate scenes. This approach called for a carefully organized file structure (Figure 3) that was flexible enough to support multiple games, yet simple enough for practical and easy use.
Figure 3. The file structure of the video game collection in the Unity Editor
In the Unity Editor, all assets used in a project are stored in a folder called Assets. This folder served as the root folder for the file structure of the video game collection. Four main folders were created and some were further divided into sub-folders. All scenes were placed in one of the main folders, called _Scenes, with the underscore added for sorting to have the scenes quickly accessible. A folder called Prefabs was used to store all the various prefabs and 25 all scripts were stored in a folder called Scripts. Both of these folders contain a sub-folder for each game, used to store prefabs or scripts that were especially created for that game only. The Resources folder was divided into three sub- folders for easy categorization. 3D models were stored in the Models sub-folder, sound effects and music tracks were stored in the Sounds sub-folder and 2D art assets were stored in the Textures sub-folder. Each of these sub-folders were further divided into sub-folders where required, eventually containing a folder for each game, again, to store assets that were specific to that game.
Having all the games within a single Unity project enabled the use of common components shared between the games and even the use of the same assets, if needed, without the need of creating duplicates or copies. It also made it possible to have one main menu scene that serves all the games included in the collection, thus allowing all the games to be built into a single executable.
3.2.2 Common components
In addition to built-in components provided by Unity 3D, the common components shared between the games mainly included prefabs and scripts. However, other types of components, assets, could also be shared. Out of a total of 72 scripts made for the video game collection, 16 were utilized in more than one game. That counts as 22 % of all the scripts. The number of prefabs utilized in more than one game was drastically lower due to each game being of different type and having its own theme and setting. An example of such prefab that was used in various games of the video game collection is a prefab called AudioManager (Figure 4).
26
Figure 4. The AudioManager prefab as shown in the Inspector window of the Unity Editor
The AudioManager is made out of three smaller components. The Transform component, stores the object’s positional and rotational values as well as its scale and the Audio Source component is used for audio playback. These two components, which are built-in components of Unity 3D, are complemented by a specifically created script component that contains the functionalities of the AudioManager prefab and controls the other two components. Once the AudioManager is placed within a scene, a reference to it can be provided to other scripts allowing those scripts to play a sound effect they have a reference to by passing that reference to the AudioManager, thus eliminating the need to have an Audio Source component in each gameobject that needs to play sound effects.
Another component that was widely used is a script component called ObjectPooler, which provided the functionalities of a concept known as object 27 pooling. The basic principle of object pooling is quite simple (Figure 5). A certain amount of copies, instances, of an object are created and a record of each instance, reference, is added to a list, known as a pool. Thus the pool serves as a repository of ready-made objects that can be fetched for use from the pool. (Nystrom 2014; Pal 2019; Technopedia 2019.) Objects that were pooled, using object pooling, in the games made, ranged from small objects, like projectiles, to as large as whole sections of a level, or scene.
Figure 5. The basic flow of object pooling at runtime. In this case the pool is configured to be expanded if no pooled instance is available for use.
In Unity 3D, instantiating, or creating an object, is a CPU intensive operation. This is where object pooling comes in. Instead of instantiating a prefab when needed, 28 multiple instances of said prefab can be created and added to a pool at start. The instances are disabled the moment they are instantiated and kept that way as they await being utilized. This instantiating is handled by a single script known as an object pooler. When an object from the pool is needed, the object pooler is used for fetching an available object from the pool and then activating it, making it available for use. If the pool size, the amount of objects stored in the pool, is insufficient, meaning no object is available for use as all the objects are already in use, the object pooler cannot retrieve an object for use. In such cases the pool may be expanded during runtime by the object pooler. However, sometimes it may be better to have a fixed limit to the size of the pool, depending on the usage, preventing the instantiation of additional pooled objects. Once an object is no longer in use, it is returned to the pool for later use and disabled, instead of being destroyed. (Izzo 2018.)
There are several benefits in utilizing object pooling. Most importantly, utilizing object pooling can boost the performance of a game, or any application in general, greatly. The higher the cost of initializing an instance of an object, or class, and the higher the rate of instantiation, the greater the benefit obtained by the use of object pooling. In addition, a more optimized resource usage may be achieved by utilizing object pooling as it can reduce memory fragmentation. As instances are created, or instantiated, at the start, instead of at runtime, memory is allocated for all the pooled objects already, meaning there is no need to allocate more memory at runtime, except in situations where the pool size is insufficient and more pooled objects need to be instantiated at runtime. Additionally, memory is only freed once the game has been quit as deactivating any instances will still keep them in memory allowing the instances to be used as many times as needed without loss in performance. (Nystrom 2014; Kowalski 2018; Object Pool Design Pattern 2019; Pal 2019; Technopedia 2019.)
3.3 Code
The writing of code, or scripting, was an essential, if not the most essential, part of the development process of the video game collection, and was carried out with C# serving as the primary scripting language. Due to the video game 29 collection’s planned use, certain conventions were established concerning the structure and look of the code that was being written. The code was to be clear in structure, readable and easy to understand, thus any obscure code was to be avoided. In addition, all classes, variables and methods were to be named aptly, the name describing the use or function of the element.
3.3.1 Core classes
The most important, or widely used, of all the classes present in the video game collection could be referred to as the core classes. The AudioManager, GameObjectGroup and ObjectPooler classes are prime examples of this type of classes, in addition to the GameManager class of each individual game of the video game collection.
The AudioManager class contains all the functionality within the AudioManager script, whose operation was detailed in chapter 3.2.2. The class simply contains a reference to an AudioSource component and two overloads of a method, with varying parameters, for playing audio files through the AudioSource.
The GameObjectGroup class is a data class whose primary purpose is to act as a group of gameobjects and to allow a series of operations to be performed to that group or its members. The class contains a list for storing the gameobjects included in the group along with a matching list of weights, a member variable for an active, or selected, member of the group and a member variable for storing a distance. Additionally, methods for fetching a specific, nearest or a random member of the group, adding a member or removing a member from the group and for various clean up procedures, such as checking if the group is empty, and clearing the group in its entirety. This class was essentially used to keep track of gameobjects such as enemies or power-ups, as well as being utilized in their spawning processes.
The ObjectPooler class provides the ObjectPooler script all its functionality, containing everything needed for object pooling. The concept of object pooling and how it works was detailed in chapter 3.2.2. The ObjectPooler class contains 30 member variables for a reference to the pooled object, the pool size and for determining whether the pool size can be increased dynamically, or not. In addition, the class includes a list of all the pooled instances, for accessing them, and methods for initialization, fetching an instance from the pool, or creating a new instance if needed and allowed, fetching a list of all the pooled instances and for activating an instance.
The GameManager classes serve as the master classes of their respective games, managing the flow of the game, hence being called a game manager. What sets the GameManager classes apart from the rest of the core classes, is that instead of there being a single class used for all the games, there is in fact a separate class for each game, whose name is made up of the game’s unique three letter code followed by an underscore and the name GameManager, for easy identification. In the case of the Endless Runner game for example, the GameManager is called RUN_GameManager. This uniform naming scheme not only makes the classes easy to identify but it also signifies the purpose and functionality of the classes, managing the games. Due to the differences in the types of games included in the video game collection, the functionalities included in each GameManager class can vary drastically. These functionalities include, but are not limited to, spawning enemies and upgrades, managing the score, keeping count of checkpoints and time, spawning obstacles and communicating with the UI. Additionally, the core functionality, managing the flow and progression of the game, is essentially included in every GameManager class although being different in each.
3.3.2 Commenting conventions
Documenting the code well was essential due to the intended use of the video game collection. For this reason, and for the sake of consistency, code commenting guidelines were established (Appendix 2). This was important, especially as there were multiple people involved in implementing the video game collection. However, the guidelines only covered the syntax that needed to be followed in order for Doxygen to be able to produce correct documentation. To 31 complement the guidelines, additional conventions were set regarding the content of the comments.
The content of a comment depended on the element the comment was written for, of course. However, the common conventions were that the comments were to be written in Finnish and proper punctuation was to be followed. Terms that lacked a Finnish translation were not translated and were written in English instead. Comments written for classes were to include a short description of what the class was and what functionality it contained. The formula was nearly the same for member variables, as comments written for them were to include what the variable was, or its type, and optionally, what it did, or what it was used for (Figure 6). The content of the comments written for methods varied more greatly, depending on the type of the method, whether it was of void type or not, and the arguments and the number of them. However, the function of the method was to be described with each method.
Figure 6. An example of a member variable with a comment describing what the variable represents and what it is used for
These conventions resulted in the code being documented with overabundance of information. In most cases, this would have been deemed too much. However, detailing as much information of the code as possible was essential in this particular case, once again, due to the intended use of the end product. This was intended to help a person, with no prior experience in programming, to understand how the code functions and what each line of code does.
4 CONCLUSIONS
It is difficult to determine whether the end product, the video game collection, fulfills the purpose it was created for, that is, to be used as a tool in education and to function as a platform for learning programming through the creation of video 32 games, yet. This remains to be seen once the video game collection has been adapted into actual use in a real environment and not just in a test environment.
According to the original specification, the video game collection were to be highly modular, consisting of pieces that could be mixed in different ways in order to create different games and to include ten different premade games as templates. Due to numerous changes to the specifications during the implementation of the video game collection, especially during the creation of the first game, where major changes were made, the end product contained six premade games, each well documented along with a tutorial that details every step needed to remake that game. Perhaps the most significant change to the specifications was about the focus on modularity, which was dropped early in the development and the games were made more or less standalone instead. The reason for this was as making the code components modular also made them complicated, which would have made the components easier to combine but the code itself harder to interpret and understand for a person new to programming, thus it was deemed that the code would not serve as a good example as such, which was one of the requirements set for it.
Despite the end product not matching the initial specifications set for it, it should still fill the same purpose, though in a slightly different way. This should not be regarded as failure, as it is not such in any way, but as evolution, or refinement, of an idea, during the process of implementation. At the end, a product was made for a purpose, and on time, a product that didn’t exist before for that specific purpose.
During the implementation and throughout the whole development cycle of the video game collection a lot was learned, ranging from the use of new software to the refinement of skills previously learned. Working on the video game collection taught many new functions of and ways of working with the Unity Editor, introduced new ways of using Blender and introduced new concepts in programming, object pooling for instance, that were previously unfamiliar. It also presented the chance to explore the use of software like the Doxygen 33 documentation generator and Git version-control system, which weren’t familiar at the time the development began but became essential tools during the development.
In the future, whether the video game collection did fulfill its purpose, or not, shall be seen. Even though it has been deemed ready for use, whether it is finished cannot be said for sure. There is potential for future expansion of the video game collection as more games and tutorials could be created for it if deemed necessary to complement the six games included. After all, not all the games initially designed were implemented, which means that development could be picked up from there without the need of coming up with ideas for new games.
34
REFERENCES
Adams, D. 2012. The state of the RTS. Blog. Updated 17 June 2012. Available at: https://www.ign.com/articles/2006/04/08/the-state-of-the-rts [Accessed 29 July 2019].
Akampurira, A. 2014. Project planning and management: an aspect of development. Ebook. Hamburg: Anchor Academic Publishing. Available at: https://www.proquest.com/products-services/ebooks/ebooks-main.html [Accessed 25 July 2019].
Blender Foundation. 2019. Website. Available at: https://www.blender.org/ [Accessed 22 August 2019].
Brewster, R. No date. Paint.NET. Website. Available at: https://www.getpaint.net/ [Accessed 27 August 2019].
Burgess, J. & Purkeypile, N. 2013. Skyrim’s modular level design – GDC 2013 transcript. Blog. Updated 19 April 2013. Available at: http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html [Accessed 5 August 2019].
Coss, D. 2015. Making modular videogames. Code Words. Vol. 3 (2). WWW document. Available at: https://codewords.recurse.com/issues/three/making- modular-videogames [Accessed 5 August 2019].
Dobrowolski, P., Hanusz, K., Sobczyk, B., Skorko, M. & Wiatrow, A. 2014. Cognitive enhancement in video game players: the role of video game genre. Computers in Human Behavior. Vol. 44 (3), 59-63. PDF document. Available at: https://doi.org/10.1016/j.chb.2014.11.051 [Accessed 29 July 2019].
Fagerholt, E. & Lorentzon, M. 2009. Beyond the HUD – user interfaces for increased player immersion in FPS games. Chalmers University of Technology / Department of Computer Science and Engineering (Chalmers). Degree program in Computer science and engineering. Master’s thesis. PDF document. Available at: https://hdl.handle.net/20.500.12380/111921 [Accessed 26 July 2019].
Freeman, T. 1997. Creating a great design document. Blog. Updated 12 September 1997. Available at: https://www.gamasutra.com/view/feature/131632/creating_a_great_design_docu ment.php [Accessed 9 August 2019].
Izzo, S. 2018. Type-safe object pool for Unity. Blog. Updated 9 June 2018. Available at: https://www.horsedrawngames.com/type-safe-object-pool-for-unity/ [Accessed 17 September 2019].
Koponen, J. 2019. Documentation of modular game collection. South-Eastern Finland University of Applied Sciences. Degree program in Information 35 technology. Bachelor’s thesis. PDF document. Available at: http://urn.fi/URN:NBN:fi:amk-2019051710442 [Accessed 27 September 2019].
Kowalski, S. 2018. Design patterns: object pool. Blog. Updated 1 May 2018. Available at: https://medium.com/@sawomirkowalski/design-patterns-object-pool- e8269fd45e10 [Accessed 18 September 2019].
Krita Foundation. No date. Website. Available at: https://krita.org/en/ [Accessed 26 August 2019].
Mader, P. 2005. Creating modular game art for fast level design. Blog. Updated 2 December 2005. Available at: https://www.gamasutra.com/view/feature/130885/creating_modular_game_art_fo r_fast_.php [Accessed 5 August 2019].
Matthews, V. 2018. The many different types of video games & their subgenres. Blog. Updated 12 April 2018. Available at: https://www.idtech.com/blog/different- types-of-video-game-genres [Accessed 29 July 2019].
McMillan, L. 2013. The origin of the ‘Shmup’ genre: a historical study. Blog. Updated 6 February 2013. Available at: https://www.gamasutra.com/blogs/LukeMcMillan/20130206/186184/The_Origin_o f_The_Shmup_Genre_A_Historical_Study.php [Accessed 30 July 2019].
Microsoft. 2019. Visual Studio. Website. Available at: https://visualstudio.microsoft.com/ [Accessed 15 August 2019].
Modular concepts for game and virtual reality assets. 2018. Intel Corporation. WWW document. Updated 16 March 2018. Available at: https://software.intel.com/en-us/articles/modular-concepts-for-game-and-virtual- reality-assets [Accessed 5 August 2019].
Momoda, J. 2015. Endless runner games: evolution and future. Blog. Updated 5 December 2015. Available at: http://jerrymomoda.com/analysis-endless-runners/ [Accessed 30 July 2019].
New York Film Academy. 2014. How to write your first game design document. WWW document. Updated 14 November 2014. Available at: https://www.nyfa.edu/student-resources/how-to-write-a-game-design-document/ [Accessed 9 August 2019].
Nuclino. 2018. How to create a modern game design document (GDD) in Nuclino. WWW document. Updated 15 August 2018. Available at: https://blog.nuclino.com/how-to-create-a-modern-game-design-document-gdd-in- nuclino [Accessed 9 August 2019].
Nystrom, R. 2014. Game programming patterns. Ebook. Genever Benning. Available at: https://gameprogrammingpatterns.com/ [Accessed 17 September 2019].
36
Object pool design pattern. 2019. SourceMaking. WWW document. Available at: https://sourcemaking.com/design_patterns/object_pool [Accessed 18 September 2019].
Pal, T. 2019. Object pooling in C#. Blog. Updated 22 January 2019. Available at: https://www.codeguru.com/csharp/csharp/cs_misc/object-pooling-in-c.html [Accessed 17 September 2019].
Racketboy. 2019. Fighting games 101: all you need to know to battle. WWW document. Updated 3 January 2019. Available at: http://www.racketboy.com/retro/fighting-games-101-all-you-need-to-know-to- battle [Accessed 30 July 2019].
Sayenko, A. 2015. How (and why) to write a great game design document. Blog. Updated 24 April 2015. Available at: https://gamedevelopment.tutsplus.com/articles/how-and-why-to-write-a-great- game-design-document--cms-23545 [Accessed 9 August 2019].
Technopedia. 2019. Object pooling. WWW document. Available at: https://www.techopedia.com/definition/24293/object-pooling [Accessed 17 September 2019].
Unity Technologies. 2019. Website. Available at: https://unity.com/ [Accessed 14 August 2019].
Van Heesch, D. 2018. Doxygen. Website. Available at: http://www.doxygen.nl/ [Accessed 16 August 2019].
37
LIST OF FIGURES
Figure 1. An example of code containing Doxygen comment blocks with special formatting Figure 2. An example of documentation output generated with Doxygen Figure 3. The file structure of the video game collection in the Unity Editor Figure 4. The AudioManager prefab as shown in the Inspector window of the Unity Editor Figure 5. The basic flow of object pooling at runtime. In this case the pool is configured to be expanded if no pooled instance is available for use. Figure 6. An example of a member variable with a comment describing what the variable represents and what it is used for
Appendix 1 TABLE OF ELEMENTS INCLUDED IN TYPES OF GAMES
TOP-DOWN TWIN-STICK TOP-DOWN SHOOTERTWIN-STICK
FIRST-PERSON SHOOTERFIRST-PERSON
REAL-TIME STRATEGY
SURVIVAL HORROR SURVIVAL
ENDLESS RUNNER
TOWER DEFENSE
FIGHTING GAME
SHOOT 'EM UP
RACING RACING GAME
PLATFORMER
GAMES/ELEMENTS CHARACTERS Player Y Y Y Y Y Y Y N Y Y NPC Y Y Y N ? Y Y Y Y Y OBJECTS Spawner Y Y Y Y Y Y Y Y ? Y Projectile Y Y Y N Y Y Y Y N Y Collectible Y ? Y Y Y Y N N Y N Props (physics) N N Y N N Y N N N N MOVEMENT TYPES Movement on 2 axes Y Y Y N N N Y Y Y Y Movement on 1 axis N N Y Y Y Y N N N N Rotation control N Y Y N Y Y N N Y N Waypoints Y N N N N Y Y Y N N Follow N Y N N N N ? N Y N CAMERA TYPES Static N Y N Y Y N N Y N Y Follow player Y N N N N N Y N N N Rotation camera (3rd person) N N N N N Y N N N N Rotation (1st person) N N Y N N N N N Y N ACTIONS Jump Y N N Y Y N N N ? N Look at target N Y Y N N Y Y Y Y N Attack Y Y Y N Y Y Y Y Y Y SYSTEMS Health & Damage Y Y Y Y Y Y Y Y Y Y Hitbox/Hurtbox Y Y Y Y Y Y Y Y Y Y Spawn/Respawn/Despawn Y Y Y Y Y Y Y Y ? Y Resource/Currency ? Y Y Y Y Y Y Y Y Y Timer N Y Y Y Y Y Y Y ? Y UI (resource, button) ? Y Y Y Y Y Y Y N Y Animations Y N Y Y Y Y Y N Y ? Pathfinding N N N N ? Y Y N Y ?
Appendix 2 CODE COMMENTING GUIDELINES
/// @brief Description /// @details Detailed description class Example { /// @details Description int integer1;
/// @details Description struct Structure { int integer2; ///< @details Description int integer3; ///< @details Description }
/// @details Description /// @n Previous continues on a new line /// @param i description /// @return Returnee’s description /// @cond DEV ///