This was originally posted on my Gamasutra blog.
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 of 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:
NOUS – This is an elevated, timeless plane of existence, both of ideas and the universe itself. This the place from where all ideas stem from – including game ideas!
PSYCHE – This is the world of symbols, which reflect the representation of the idea. In our context, ideas brought down from Nous are processed by the Psyche (the mind) through the filters of our own life experiences, our feelings, other media we have consumed, and so on.
SOMA – The physical world, where ideas are materialized.
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. Both 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:
Simple Systems (Group A)
Complicated Systems (Group B)
Complex Systems (Group C)
Chaotic Systems (Group D)
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 in 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 the 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.
“I think there are two types of writers, the architects and the gardeners. The architects plan everything ahead of time, like an architect building a house. They know how many rooms are going to be in the house, what kind of roof they're going to have, where the wires are going to run, what kind of plumbing there's going to be. They have the whole thing designed and blueprinted out before they even nail the first board up. The gardeners dig a hole, drop in a seed and water it. They kind of know what seed it is, they know if planted a fantasy seed or mystery seed or whatever. But as the plant comes up and they water it, they don't know how many branches it's going to have, they find out as it grows. And I'm much more a gardener than an 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 flexible with 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, in the second part of this article on Agile frameworks.
Out toolbox, now with a few extra options available
Comentários