[img]{STEAM_CLAN_IMAGE}/40253309/a9e72f35033009c2c9cc76f4c83a64c3011383e4.jpg[/img][h3][b]Agile Game Development Part 3: Working Game vs GDD[/b][/h3] [b]1. Introduction[/b] 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. I’d like to elaborate on that. The third line of the [b]Agile Manifesto[/b] says: [i]“Working software over comprehensive documentation”[/i] [b]2. The struggles of communication[/b] [i]Communication is hard[/i]. 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. It’s just a first iteration and you already lost so much in the translation. [b]3. The Agile Way[/b] But if you have an agile mindset, you can turn this to your advantage. Your artist, who’s 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. Don’t start on a GDD that is meant for [b]EVERYONE[/b]. 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 rigorous bible with no room for changes. Treat it as a reminder of what you’ve discussed and the direction for the next couple of weeks. After a few weeks, you’ll 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. [b]4. Ownership[/b] You want to encourage your team to take [b]ownership[/b] of 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 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 setting’s direction. And sometimes they just might not want to be convinced. Others can’t 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 it’s 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 don’t 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 [i]specific[/i] target audience in mind, not trying to please everyone. That’s all for this post, thank you for your attention! Have a great day, Janusz Tarczykowski