Agile Game Development Part 2: Design Pillars
In part 2 of my “Agile in Gamedev” series, I want to discuss the first line of the Agile Manifesto and how it applies to game development.
“Individuals and interactions over processes and tools”
Let’s look at some real-world example – the story of BioWare.
For many years it was a company making the best RPGs on the market. But as Jason Schreier described in his book “Blood and Pixels” – after BioWare was acquired by Electronic Arts, this experienced company (consisting of some of the best people in the industry) had problem after problem. Their next 3 games came out in horrible pain.
The biggest issue that caused this was forcing the team to use the Frostbite engine. Up until that time, BioWare had used its own engine, Aurora. It was made specifically for the kind of games they were making and the team knew it well. Frostbite was made for Shooters, not RPGs, and lacked many core features they needed, which resulted in slow development and a huge loss of motivation inside the team.
Instead of focusing on the team and the product, they focused on the tools and forced people to use them.
I want to give you not only anecdotes but also solutions. So let’s assume we’re making a new game. How should we start?
We should start with the Design Pillars. A great example is in the GDC talk “The Design Of Subnautica” by Charlie Cleveland, you can watch it here.
Those pillars should emphasize emotions, what players will experience. They usually shouldn’t be concrete features. But this is not a strict rule – e.g. on Last Of Us Naughty Dog used:
- Crafting: Ammo is scarce, so to distract or cause a higher amount of damage to one’s foes it is better to use items populating the world. This works in unison with the environmental storytelling of how there are not many resources left in this world.
- Story: Last of Us is a linear game that is heavily narrative lead, they want everything to tie in with the story as mentioned with crafting. The game focuses on the story of the two main characters rather than the player’s own story.
- AI partners: The game is all about building a relationship between the player’s character with the AI partner Ellie and other partners you meet throughout your journey.
- Stealth: Combat is used in this game, but if you were to run and gun, then the game would make your life extremely difficult. So the player is encouraged to play more stealthily.
The pillars you create should be the Lighthouse that leads your team to a safe shore. Whenever there is a decision to make, it’s important to remember them.
Once you’ve set those pillars up it’s time to start making a prototype. You don’t have to create a Game Design Document detailing the whole game beforehand. Instead of being the bottleneck of the team, making them wait for the GDD and later for updates and answers to every burning question, make them part of the process. Individuals and interactions over processes and tools.
The team should take ownership of what they are doing. Don’t become a parent that tells them what to do. Instead, treat them like the adults they are: together you will work to bring the vision to life.
Now you can have the team brainstorm some ideas on how to bring those pillars to life – coders should start thinking about what technologies and tools to use, how to set up the architecture of main systems. Artists should be looking for an art style that will not only fit the vision but actually enhance it. The marketing team should start analyzing the market for what you want to build.
In the next part, I will dive deeper into this phase, but for now, I want you to think about the Design Pillars of the games that you love and the games that you’ve made in the past. Can you figure them out?
Any thoughts? Comment and share this story!
Have a great day,
Janusz Tarczykowski