Individual game development with open- source software A case study with guidelines for programmers and game designers Master’s Thesis in Computer Science and Engineering Axel Ljungdahl Department of Computer Science and Engineering Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2020 Master’s thesis 2020 Individual game development with open-source software A case study with guidelines for programmers and game designers Axel Ljungdahl Department of Computer Science and Engineering Division of Interaction Design Chalmers University of Technology University of Gothenburg Gothenburg, Sweden 2020 ii Individual game development with open-source software A case study with guidelines for programmers and game designers Axel Ljungdahl © Axel Ljungdahl, 2020. Supervisor: Michael Heron, Department of Computer Science and Engineering Examiner: Staffan Björk, Department of Computer Science and Engineering Master’s Thesis 2020 Department of Computer Science and Engineering Division of Interaction Design Chalmers University of Technology and University of Gothenburg SE-412 96 Gothenburg Telephone +46 31 772 1000 iii Individual game development with open-source software A case study with guidelines for programmers and game designers Axel Ljungdahl Department of Computer Science and Engineering Chalmers University of Technology and University of Gothenburg Abstract The focus of this project is individual (i.e., single-person) game development using open-source tools; specifically, the development of a side-scrolling, 2D platform game with a focus on players’ enjoyment, and the creation of this thesis, which is intended to serve as a case study of individual, open-source game development and a limited guide for future developers, especially those working alone. This report describes the development process for the aforementioned game (titled CheckerSphere), which includes both single-person game development and devel- opment using strictly open-source tools (aside from low-level proprietary software such as drivers for the graphics card used during development as well as proprietary hardware). Additionally, as a guide, this thesis contains items such as a list of personally recommended study material, mostly consisting of recorded lectures and video essays; a brief analysis of the movement systems of three 2D platformers; information regarding how to legally use existing assets and where to find them; in what ways CheckerSphere is designed for accessibility; and several lists of open-source tools that may be of use for a game developer. Open-source distribution of games may not always be considered feasible, but it brings new possibilities, such as potentially causing volunteers to contribute to the game for free, encouraging players to create problem descriptions when they find apparent bugs, allowing those who are unwilling to install closed-source software on their computers to play the game, increasing the amount of trust and good will towards the developers, and helping future game development projects by contributing to the open-source community. Additionally, using only open-source tools brings benefits such as being able to trust software to not infringe on one’s privacy or be otherwise malicious; being able to suggest, or personally implement, desired changes in a piece of software; being able to remove undesired parts of software; and having access to all software without payment, facilitating lower-budget development. This project has personally strengthened the view that open-source game devel- opment is entirely feasible when extreme graphical fidelity is not required, both in terms of using only open-source tools and in terms of distributing the game under an open-source license; the latter does not prevent the developer from releasing the game commercially, since non-code assets may remain proprietary. Keywords: interaction design, video game design, independent video game develop- ment, open-source software iv Acknowledgements I would like to thank my supervisor, Michael Heron, for his support throughout this project; my examiner, Staffan Björk; the three individuals who helped improve the game by testing it at various stages of development; the opponent for my thesis; and everyone who downloaded the game from itch.io and provided feedback. Axel Ljungdahl, Gothenburg, June 2020 v vi Contents List of Figures xi 1 Introduction1 1.1 Background...............................1 1.1.1 Video games...........................1 1.1.2 Platform games.........................1 1.1.3 Game development.......................3 1.1.4 Individual game development.................3 1.1.5 Open-source development....................5 1.2 Thesis..................................5 1.2.1 Premise.............................5 1.2.2 Goals...............................6 1.2.3 Limitations...........................6 2 Theory9 2.1 Game development...........................9 2.1.1 Individual game development.................9 2.1.2 Open-source game development................ 10 2.1.3 Accessibility........................... 11 2.2 Open-source tools............................ 12 2.2.1 Operating systems....................... 13 2.2.2 Game engines, frameworks and libraries............ 13 2.2.3 Tools for creating and editing visuals............. 14 2.2.4 Tools for creating and editing audio.............. 14 2.2.5 Coding tools........................... 14 2.2.6 Level editors........................... 15 3 Methodology 17 3.1 Software development.......................... 17 3.2 General interaction design....................... 17 3.3 Game development........................... 19 4 Planning 21 4.1 Concept................................. 21 4.2 Software development methodology.................. 23 4.3 Interaction design methodology.................... 26 4.4 Tools................................... 27 vii Contents 4.5 Time plan................................ 28 4.6 Success criteria............................. 29 5 Execution and Process 33 5.1 General process............................. 33 5.2 Game design............................... 33 5.3 Programming.............................. 34 5.4 Creating visuals............................. 34 5.5 Creating audio.............................. 35 5.6 Testing.................................. 35 6 Results 39 6.1 The game................................ 39 6.1.1 Accessibility........................... 43 6.2 Guidelines................................ 44 6.2.1 Overcoming individual difficulties............... 45 6.2.2 Analyzing existing games.................... 45 6.2.3 Using open-source code and other free assets......... 46 6.2.4 Direct or indirect use of 3D models.............. 47 6.2.5 Visual effects and sound effects................ 48 7 Discussion 49 7.1 Process.................................. 49 7.1.1 Goals............................... 49 7.1.2 Methodology........................... 49 7.1.3 Design.............................. 50 7.2 Open-source development........................ 51 7.2.1 This project........................... 51 7.2.2 General open-source game development............ 52 7.3 Ethical issues.............................. 53 7.3.1 Accessibility........................... 53 7.3.2 Privacy.............................. 54 7.3.3 Digital rights management................... 55 7.3.4 Availability of source code................... 55 7.3.5 Miscellaneous.......................... 55 8 Conclusion 57 8.1 The game................................ 57 8.2 Research questions........................... 58 8.3 Contribution of knowledge....................... 58 Bibliography 61 A ResourcesI A.1 Study material..............................I A.2 Free assets................................ III B Notes from the game analysesV viii Contents B.1 Mega Man X...............................V B.2 Super Meat Boy.............................V B.3 New Super Mario Bros. 2........................VI ix Contents x List of Figures 4.1 A state machine diagram describing the PCC’s intended main actions, without accounting for dashing, power-ups or the direction in which the PCC is facing............................. 24 4.2 A state machine diagram describing the PCC’s intended main actions, accounting for dashing but not for power-ups or the direction in which the PCC is facing. As shown, adding just four states causes a significant increase in complexity, as would adding a single power-up; each power-up would cause the size of the state machine to expand greatly, especially if multiple power-ups can be active at once..... 25 4.3 The intended core gameplay loop for an experienced player, based on short levels and fast reactions to obstacles................ 26 4.4 A diagram summarizing the time plan, excluding the work which will be done continuously during the project................. 30 5.1 The initial frames of the two portals used in the game – the left is used as each level’s goal, and the right is used as an emitter of moving sawblades. Each contains a particle system which causes a circular pattern to form within it......................... 36 5.2 A side view (left) and front view (right) of the central obstacle in the sixth level. Its model was created entirely in Blender.......... 36 6.1 A state machine diagram describing the PCC’s main actions. Unlike in the plans, dashing is handled by separate code (equivalent to a two-state FSM) and power-ups are handled by another FSM; the three systems communicate through a central Player class; this class is also used to store variables such as the direction