Agile Game Development part 3: Working game vs GDD

You can read part 2 here:

https://gamasutra.com/blogs/JanuszTarczykowski/20200916/370253/Agile_Game_Development_part_2_Design_Pillars.php

In the last post I’ve mentioned how instead of spending time on creating a super comprehensive GDD in isolation we should include the team members into the process from day one. I’d like to elaborate on that.

Third line of Agile Manifesto says:

Communication is hard. Whatever amazing concept for the game you have, it has to go through many filters before it actually reaches “the screen” as a playable thing.

First you are trying to put your thoughts on the paper. What you have in your head will never be precisely what you will wirte in the GDD. Something will always be lost in translation.

Then people reading it absorb it through their own filters : their knowledge, experience, likes and dislikes, the mood they had when they were reading it and the last game they have been excited about. So what they think they just read is already pretty far away from what you intended.

Then there is another filter — they ability to turn what they think you want into code, art, level design etc. 

Their abilities and the tools they have will influence how it turns out. Games made with Unreal are a bit different to those made in Unity. Art made with Houdini might be a bit different to that made in Blender. And so on.

It’s just a first iteration and you already lost so much in the translation.

But if you have an agile mindset, you can turn this into your advantage.

You artist, who’s super creative and mastered Houdini, will create something different than you imagined for sure, but it might be something 10x more interesting!

Your programmer just had an amazing idea for using a cool algorithm to enhance the original concept. And so on.

So if we know this will happen why not own it from the day one. Don’t start on a GDD that is meant for EVERYONE.

Sit down with your artists (or at least with the Lead Artist), use the design pillars and a ref board to give them a direction, but also tune in to what they might think and ideas they might have. 

After this brainstorming session create a short document specifically for them. But don’t treat this document as a bible. Treat it as a reminder of what you discussed and the direction for next couple of weeks. 

After few weeks you’ll probably have another discussion, a lot of things will change and you might need to create a new one. 

Same with the other departments, engineering, level design, game designers. Probably each of them will need different answers and different documents.

You want to encourage them to take ownership for what they create. But to do that they have to have some room to be creative and to make decisions. They can’t own something they don’t have any influence on. 

After few iterations the team will build a momentum and everyone will be pretty familiar with the direction. Also having made a lot of decisions themselves and being a part of the process your teammates will be much more open to changes in the design when things turn out to not be as fun as expected.

So what are the downsides of this approach? As I said before: communication is hard. Some people confuse close collaboration and ownership with the “design by comitee” approach. 

They will expect you to debate every minute detail and convince them to the direction you are setting. And sometimes they just might not want to be convinced. Some people can’t differentiate between the genres they like and genres they make. So they will try to force different direction because their preferences as gamers lie elsewhere.

It’s really important to create a work culture where people are not afraid to speak their minds, but where they also understand that they are not making a game for themselves and that sometimes they just have to do something they don’t like. 

You are making games with the target audience in mind, not trying to please everyone.

That’s all for this post, thank you for attention and tune in for part 4!

Also check out our work here:

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

Janusz Tarczykowski

Rock Square Thunder