Introduction
7.1. Motivation.
This chapter contains the translation of Chapter 1.
When one decides to develop a game, there are certain steps that you must go through and, without a doubt, the most important one is the design phase. During this phase ideas are written on paper, and then simple prototypes are made to see if it’s fun to play. Afterward, analyse, and repeat the process changing whatever is necessary to find something entertaining to play. Apart from the game’s main objective, one must design the obstacles or challenges that will be introduced to the player to test them.
There are several tools that can help developers and improve their work. These exist to aid developers in many fields such as sound processing, rendering and also graphic programming but there is yet to exist one catalogue of components that helps design some basic enemies, none that a designer can use by themselves with no programming knowledge, or without the aid of a programmer that deals with the programming to create such basic game elements as simple enemies that provides an obstacle for the player to achieve the game’s objective.
Video game’s NPCs are entities that make believe that the game is “alive“, since this characters are generally used to introduce mechanics to the game in a more humanizing way: Instead of having a plain menu with a shop, you have an NPC that looks like a merchant and sells you in-game objects, with dialogues that enrich the game. Enemy NPCs in 2D video games usually have behaviours that provides then with a certain degree of realism and serve as obstacles to test the player. For the given reasons, this tool is made for prototyping video games, for the use of developers or anyone that wishes to make a 2D video game but that does not necessarily knows how to code. This tool aims to provide all the facilities that should be necessary in order to cover a game’s enemies with a customizable enemies for 2D video games, a tool that it is powerful but simple to use, easy to pick up and useful so that it can be used by anyone. With this tool, the process of making ones enemies designs into a game without having to code one single line of code, as to save development time, end up having functional as well as customizable enemies without programming being an obstacle, so that everyone can make a 2D video game.
7.2 Objectives
The main objective of this project is to design and create a tool to be used in the Unity game engine with the main purpose of providing a catalogue of C sharp components for making enemy behaviours. This tool should be easy to pick up for any kind of person that wishes to make a 2D video-game, no matter their programming experience. The components of this catalogue shall be customizable, easily addable and even mixable together to create brand new behaviours. Thus, to achieve that goal the components must follow the principles of code abstraction, as well as object oriented programming.
To create this catalogue of components, the techniques of NPC creation were studied, as well as the tools that offer easy ways of implementing them such as game engines that are oriented to developers with little to no experience in programming. After this analysis, the component catalogue will be designed and justified by creating certain enemies with the designed components. Afterwards, these components will be implemented into a practical version and then, finally, the catalogue will be tested with users in testing sessions that should be useful to collect data and commentaries about this catalogue, as to identify what works and what does not.
7.3 Works plan.
To develop this project, we established an agile methodology from the start, during the first few meetings. The chosen methodology was studied in the subject Metodologías Ágiles de Producción, and used in quite a few other subjects such as Proyecto. My director would take the role of client, and we would have meetings every two weeks in order to show him my progress, listen to his feedback and criticism, resolve any doubts I might have and finally define the route of action for the following two weeks. This methodology is called Scrum, and it’s quite simple: Scrum is based on frequent reunions, which should be quick ones in order to define objectives in short term commonly called «sprints». The scrum methodology relies on the auto-managed organisation to deal with the unpredictability of the development of any application, and manage before it gets out of control with said short «sprints». When a «sprint» ends, the team must make and analysis of it and schedule the objectives for the next one. Also, it was decided that all the code that is going to be produced shall be entirely in English, so that the language does not become a barrier in case any user decides to read through the code and study it.
The component catalogue is designed in a incremental manner during the development months. The chapters that make this memory describe each part of the process that is going to be followed for this implementation. First of all, a study of the State of Art (Chapter 2) will be made in which techniques of enemy behaviour creation will be explained. Furthermore, we will explore the tools that are commonly used that implement these techniques, as well as, the game engines that are suited for novel developers, extracting the positive aspects of them to be implemented in this tool.
After this study, the 3rd Chapter will be dedicated to define and justify the design of this tool. In this chapter the design will be explained, it is going to talk about the main inspirations for this project and the component’s design will be listed, justifying the existence of these components by theorically making enemies with them. After this is explained and properly justified, then these components can be implemented.
As will be explained in the 4rd Chapter, the implementation of this catalogue is going to be made in the Unity game engine, and this chapter will define the structure of the components that will be implemented. It is important to define the basic architecture of this catalogue, and to explain both the internal implementation as well as the personalization that each component offers. These implementations and the internal details will be covered in this implementation chapter, in which some forms of component combination will be explained.
Once that the catalogue is implemented, it will be tested with tester users as to value its usefulness and extract some possible improvements for this project. As is explained in the 5th Chapter, a document regarding the design of the trials will be designed, taking into consideration what was learnt in the subject Usabilidad y Análisis en Videojuegos, regarding how to identify the objectives of the testing, and how to make questions that provide information about these objectives, as well as design some light tests that the testers must solve. The users needed to create enemies with this catalogue of components, so a basic knowledge of game development was desirable, but these users must not have used the tool beforehand as to know how easy this catalogue is to use as a first timer. These result are to be collected, analysed and some conclusions will be extracted in order to make a critic of what need changing and the functionalities that are missing.
Finally, the 8th Chapter gathers the conclusions of this project in which the final implementation process will be resumed, and it will analyse the positive and the negative aspects of this catalogue of components. Afterwards, it will define the future work that can be done for this catalogue and it will justify the possible changes and extensions that could be made.