Agile Game Development part 2: Design Pillars

You can read part 1 here:
https://gamasutra.com/blogs/JanuszTarczykowski/1034748/

In the part 2 of my “Agile in Gamedev” series I want to discuss the first line of Agile Manifesto and how it applies to the 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 made of the best people in the industry had problem after problem. Their next 3 games came out in horrible pains.

The biggest issue that caused this was forcing the team to use the Frostbite engine. Up until that time the BioWare used their 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 huge loss of motivation inside the team.

Instead of focusing on the the team and the product they focused on the tools and forced the 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. (great example is in the GDC talk “The Design Of Subnautica” by Charlie Cleveland, you can watch it here:
https://youtu.be/7R-x9NSBS2Y?t=565 )

Those pillars should emphasize emotions, what players will experience. They usually shouldn’t be concrete features. But this not a strict rule — e.g. on Last Of Use Naughty Dog used :

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 the part of the process. Individuals and interactions over processes and tools.

The team should take ownership for 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 what technologies and tools to use, how to setup the architecture of main systems. Aritsts should be looking for an artstyle that will not only fit the vision, but actually enhance it. Marketing team should start analysing 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!

And check out our work here:

https://www.facebook.com/rocksquarethunder
https://twitter.com/thunder_square
https://www.instagram.com/rocksquarethunder/

Have a great day!

Janusz Tarczykowski