INTRODUCTION

  For some time now, I have dedicated myself to a new phase of my professional life –– that of the game producer. I have taken the most of this opportunity to improve my knowledge of project management and what impacts management has on game production. I have also focused on improving my understanding of Agile frameworks, such as Scrum, Kanban and Lean.

  It is important for developers of all fields, be they engineers or artists, to have a grasp on the basics of such tools so they can apply their concepts to whatever project they have at hand, better adapt to changes and demands, and help projects to evolve. The benefits of such tools are too many to be left restricted only to the producers.

  I wish to share my experiences, knowledge and insights acquired from using these tools, focusing on game development. I will go through the process, from ideation to conclusion, tools used, what results were obtained and what could be improved on a new development round.

  I hope that, by the end of this series of articles, I will have increased the number of tools at your disposal to conduct your own projects.

This is our current toolbox

THE THREE GREEK WORLDS

  First of all, let's approach the process of idea conception through the lenses of the three Greek worlds, Nous, Psyche and Soma. This constitution was proposed by Pythagoras, and can be briefly be explained as such: 

  Following this line of thought, we can better understand the old adage that says everything comes from the mind –– ideas are first born as a concept (Nous), from where we "capture them" (Psyche) and, through work, allow them to manifest in the physical world (Soma).

The three Greek worlds. Ex.: Hollow Knight conceptualization

  Using Hollow Knight as an example of this process, we can say that first there was an idea of the game. Then, an iterative process of going through references and accumulated experience in games of similar design and intention, which finally led to Hollow Knight being a concrete creation we can now play and enjoy.

  The process of idea conceptualization through these three worlds/lenses is a rich process if completed, but a sad affair if interrupted and abandoned. By not having a clear view of the idea, such as establishing pillars to guide the entire process, we can lose control of it and have the game become something that it was never intended to be. We can also end up lacking the necessary tools to finish the project. The idea gets corrupted and, consequently, so does the game.

COMPLEXITY THEORY

  When do we know our idea is concrete enough to be worked on? The Complexity Theory is a very simple tool that assists us in better understanding the process of game development.

Graphic exemplifying Complexity Theory

  In Complexity Theory, we have two axis: X Axis shows us our Technology or Certainty, and Y Axis shows us our Requirements or Agreement. Borth start at "Defined," reaching towards "Undefined." According to the difference between these two axis, we can classify the idea in groups and use different processes to refine it.

  We have the following groups:

  Depending on the project, it may be necessary to classify it in a specific group in order to start. As an example, a Civil Construction project must be well classified both in "Requirements" and "Technology" –– in other words, the planning must be complete, with a designed floor plan, purchased materials and time and cost estimates. If the house project does not meet these requirements it cannot be started, as the risk of completion not happening is extremely high.

  When talking about software, however, it is not necessary to have "Requirements" and "Technology" completely defined to start the production phase. In game development, we can start the Development Phase in Group C, and, according to the production's progress, redirect towards Group B and, finally, Group A.

Complexity Theory applied to Games

  When looking at this graphic, it may seem obvious to start on Group C, but that doesn't happen on every case. Many times, we spend a long period of time using the traditional model.

THE TRADITIONAL (or LINEAR) MODEL

  The traditional model, (also known as linear model) is based on civil construction, which itself has already existed for a long time. In terms of process, this area already benefits from a solid structure born from accumulated experience. If we look at civil construction as an adult person, then game and software development is still growing through the stages of adolescence.

  It is common to use the traditional model and the advances of mass production industries as a reference, but let us take a look from another perspective.

  Following traditional methods, we can see the known Waterfall model tied to the Gantt Chart in all sequences and dependencies between all areas, functionalities, tasks and activities until the end of the project, considering a buffer of 15% to 25% to deal with unforeseen events. It is also necessary to document the "Design Bible Trinity" –– that is, Game Design Document (GDD), Technical Design Document (TDD) and Art Style Guide (ASG) –– in order to ensure the development team is always on the same page.

The design bible trinity and our known Gantt

  At the end of the 1990s, it was common to use the traditional model, as game development took longer and there was a necessity of assuring the game would be perfect, with no bugs, at the time of release. That meant the game had to be placed on Group A, or very close to it, on the Complexity Theory chart. As technology increased and we gained access to the Internet, better equipment and an evolution of the creative process itself happened, the traditional model stopped covering this type of development and, consequently, game development. The need for a new model arose, a model that could integrate change with increased frequency.

  It was in the search for new ways of assuring satisfied demands and quality deliveries, while maintaining essential values of performance and communication, that Agile frameworks, tools and movements came to be (eXtreme Programming, Scrum, Kanban, Lean, etc). Through these new emergent practices, it became possible to start projects in Complicated System Groups (B) and Complex System Groups (C), according to Complexity Theory. In game development, you can collect data and feedback from players since the initial stages of a project via the MVGs (Minimum Viable Game), potentializing the experience and discarding features that do not aggregate value to the project. That can be done via early access, a soft launch or a playtest, depending on your target audience, platform and marketing strategy. The documentation (GDD, TDD, ASG) becomes organic, changing and evolving as the project advances. 

Minimum Viable Game deliveries

  What's the most important value added to the game through these new strategies? Time. Time is one of the most important elements in our lives, both professionally and personally. Time to develop new games, to spend with loved ones, to learn new things and, last but not least, time saved in a game that may not be a success. In the past, we would take five years to find out a if game will not be well-received, or even worse, that it will not even be released. Today, using Agile tools, we can avoid these prospects by discarding a bad idea and investing in another, more promising one, sooner.

Let's enjoy life too!

  With Agile frameworks, having the Agile Manifest as a foundation for software development, a step was taken towards our own definition of processes and methods. We will take a deeper look at this on the second part of this article.

THE GARDENER AND THE ARCHITECT

  To finish this first part of the article, I'd like to recall an example George R. R. Martin used when describing two different types of writers, which I feel also applies well to the Traditional and Agile models: the gardener and the architect.

  In the traditional model, the architect must have all the information defined before starting a new project, in a waterfall format that's defined and well structured, with all the necessary documentation ready (GDD, TDD, ASG, ADD, etc), ensuring that the project can be started with no major issues.

  On Agile, the gardener plants the seed (the idea) and watches it grow along the iterations and increments of the MVG. The team can then better see what's best for the project, nurturing the features that work and adding to the whole while snipping off features that do the opposite.

A gardener project and an architect project with MoSCoW method

  It should be noted that things can never be too rigid, so if the traditional model works for your team and fits the reality you live in, allowing for good results, there's no need to force a new framework on your project. However, just like traditional models are flexibilizing their methodologies, it is recommended to try out a few new tools to validate their results. At the end of the day, our objective, be it using the traditional or Agile models, is to learn how to extract the best of each tool in order to mitigate negative aspects while potentializing the positive ones.

  I hope that this text has helped you gather some extra tools for your development box. Let's see each other again soon, on the second part of this article on Agile frameworks.

Our toolbox, now with a few extra options available