Agile Game Development Part 3: Working Game vs GDD

1. Introduction In the last post, I mentioned how we should include the team members in the process of creating the game from day one. No waiting for GDD updates for weeks. Id like to elaborate on that. The third line of the Agile Manifesto says: Working software over comprehensive documentation 2. The struggles of communication Communication is hard. Whatever amazing concept for the game you have, it has to go through many filters before it reaches the screen as a playable thing. First, you are trying to put your thoughts on paper. What you have in your head will never be precisely what you will write in the GDD. Something will always be lost in translation. Then people reading it absorb it through their own filters: knowledge, experience, likes and dislikes, what mood they are in, and the last game that captured their heart. So what they think they just read is pretty far away from what you intended. Then there is another filter the ability to turn what they think you want into code, art, level design, etc. Its just a first iteration and you already lost so much in the translation. 3. The Agile Way But if you have an agile mindset, you can turn this to your advantage. Your artist, whos super creative and a mastered Houdini, will create something different than you imagined for sure, but it might be something 10 times more interesting. And 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 day one. Dont 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 dont treat this document as a rigorous bible with no room for changes. Treat it as a reminder of what youve discussed and the direction for the next couple of weeks. After a few weeks, youll have another discussion. A lot of things have probably changed by then and you might need to create a new one anyway. Same with the other departments, engineering, level design, game designers. Each of them will need different answers and different documents. But those documents are just a write-up of your discussion, when in doubt the team should just talk to you. 4. Ownership You want to encourage your team to take ownership of what they create. But to do that, they have to have some room to be creative and to make decisions. They cant own something they dont have any influence on. After a few iterations, the team will build momentum. Having made a lot of decisions themselves your teammates will be much more open to changes in the design. 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 committee approach. And some people will expect you to debate every minute detail and convince them of the settings direction. And sometimes they just might not want to be convinced. Others cant differentiate between the genres they like and the genres they make. So they will try to force different directions because their preferences as gamers lie elsewhere. These are all very tricky cases. That's why its really important to create a work culture where people not only dare to speak their minds but where they also understand that they are not making a game for themselves. Sometimes they have to do something they dont like. And that there is a point when debates have to stop, even if not everyone is convinced. Agendas for meetings and not exceeding meetings time are very important. Remember you are making games with a specific target audience in mind, not trying to please everyone. Thats all for this post, thank you for your attention! Have a great day, Janusz Tarczykowski

[ 2021-05-31 16:00:14 CET ] [ Original post ]