[img]{STEAM_CLAN_IMAGE}/40253309/5a9b75acdfebcef000913217d28d0eac1dec13b9.jpg[/img] Hello, Lightbringer Community My name is Janusz and I’m one of the developers of the game. I’ve been working on writing a dev diary for you, where I’ll share some tips and tricks throughout the process of developing a video game. If you have any specific topics you want me to bring up, or if you have any feedback on the posts, please let me know. I hope you’ll like it! [h3][b]Agile Game Development Part 1: How the sausage is made[/b][/h3] Let’s start with the Agile Manifesto: [i]Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan[/i] We will come back to that. But first, let’s talk about games. Typical game production looks like this: The company decides to make a game [b]X[/b]. Someone prepares a [b]GDD[/b], then the team starts building [b]The Prototype[/b]. Very often the majority of the team wants to have documentation of [b]EVERYTHING[/b]. They will tell you they can’t start building the feature until they receive documentation on the feature they are making, the documentation has to contain all possibilities, otherwise, they will throw a tantrum when they find an edge case that is not documented. So the countless pages of documentation are made by the designers. Engineers start building systems, artists create assets. Things start to shape up and it turns out the game is not fun so far. Or the designers see that what they planned simply won’t work. So the changes have to be made. Most of the documentation is now outdated. Designers try to update it all. Some of the team members now have nothing to do, they are waiting for updated docs. The amount of time and money wasted like this in game companies is ridiculously high. After some time [b]The Prototype[/b] is ready. Now usually it’s used to pitch a game to the publishers. In the meantime, the production is being planned. Based on the prototype [b]Leads[/b] prepare estimates of how many people with what skills they need. Less experienced teams will simply take the GDD and the prototype and come up with a precise (in their minds) plan, they think they know how much work will be needed. More experienced teams usually will add 30% to their precise plan, cause they know things can go wrong. The publisher [b]Y[/b] is interested. But they want a precise budget for the game. And a milestone plan with a precise number of assets etc. It’s impossible to accurately make something like this, but everyone pretends it isn’t. So they use their ‘precise’ estimates, do some hand waving to fit it with the team they are planning. They come up with some out-of-air numbers like 20 NPCs, 100 building assets, 5 levels, and so on. They send it to the publisher. If the publisher likes it, they sign a deal, and voila! Now everything will be great, they have a precise plan after all. You can probably guess what happens next. You have probably seen it happen time and time again. Games being delayed. Games released in a terrible state. Your Anthems and Fallout 76 releases. People crunching, sleeping on the floor in the office, divorces, bankruptcies, talented people looking for new work, AAA companies going down in flames. And it’s pretty much all down to the beautiful lie that the game industry still believes in: That games can be precisely planned, estimated, made on time, and being masterpieces on top of that. Some companies even pull it off. Usually by crunching, sometimes by having lots of cash to set longer milestones. The IT in general had the same ideas and the same problems. It’s called Waterfall software development. And boy, did it fail. Time and time again. So people got smarter and came up with Agile. To reduce costly and surprising failures. Some super smart people (including famous[b] Uncle Bob Martin[/b] — watch his talks on YouTube, cause he is [b]AMAZING[/b]) created Agile Manifesto to sum it up. Let’s quote it again: [i]Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan[/i] I think you can see how the typical game production is far from this manifesto. It’s the exact opposite of Agile. And it’s the reason it’s so problematic and toxic. I think it should be enough for one post. I want you to digest it all and think about what you think should change. How would you approach fixing this mess? And I will share my ideas in part 2 of this series. Have a great day, Janusz Tarczykowski