Planning a project, especially when considering Agile practices, within a games development cycle can be the trickiest part of the whole process yet an incredibly important one. Agile in its nature tries to spread the planning of a product or the work that it entails across the life time of the project. Traditionally games development planning applied a more Waterfall based method.
As you can see from the figure above the biggest difference with the two methods is the need to have a mapped out design or product vision at the start of the project for the traditional methods, whereas the Agile method focuses more on the customers needs and creates an iterative process around this in order to establish the requirements for the product.
Application to Games
Looking back game development has usually began its process with the creation of a Game Design Document (GDD), this would traditionally be a huge document that detailed and described all the features and aspects of the video game product and how these would work both individually and in combination with each other. This process was long and time consuming, and ultimately utilised a lot of resources that would go unused within the final iteration of the product.
As detailed by Sweatman (2014) the old style game design documents made too many assumptions, were always out of date, often went unread, were too rigid and did not allow for failure. Having written a few myself I can agree completely with these statements and their more descriptive content within his article.
So an Agile approach allows us to be able to eliminate some of these aspects when you consider the methods that can be used. The Scrum approach for example can be used to spread the planning across the lifetime of the project, Clinton (2010) describes this as “Agile planning does not call for a complete plan up front but spread the work of planning throughout the entire project”. He continues to describe the benefits of using the methodology as it allows teams to deliver potentially shippable features in value-first order, allows to plan by feature which creates cross-discipline behaviour, allows working to clear objectives and furthermore prioritises scope to control the budget and delivery date.
So with this in mind you can see why Agile methodology has been taken up so widely within the games development industry.
Sticking Point
As I have mentioned I have written a few GDD’s in my time and one of the things that has always stuck in my mind when it comes to applying Agile to game development is the need for an extensive product backlog at the start of the project in order to fully understand what it is you are trying to create.
This product backlog needs to ensure that it contains all of the features and requirements for the project in order for the Agile methods to be applied, but how can you do this with an Agile planning thought process? If you are not detailing all of the aspects of the game at the start how can you develop it in an Agile way without the details or what you need to create?
Well perhaps we need a better definition of the word ‘detail’ at this point. From my experience the word detail, especially when it comes to GDD documents, means extensiveness and decisiveness. You have to think of every possible situation and ensure there is a solution to any problem. But this really is not needed when you apply an Agile approach, these things can be discussed and detailed when required. Really all you need is a description of the feature and how it works with other features.
Romanos (2014) explains that the real requirements for a GDD are to “Define your goals for the game, and the experience that you want people to have.” and she continues to explain “In practice this means that your GDD should map out the overall flow of the game and what the user can do. What you don’t need to map out, at least initially, are all the little details of that.”
She also mentions that a GDD should allow a reader easy access to the information and that a GDD should have enough room for the larger details to be refined later on. This is a really useful way to think about writing a GDD and allowing it to be part of the Agile method.
And it reminds me of a type of document I used to construct when I was working in the industry.
Game Pitches
A game pitch, as described by Wright (2020) is “a concise description of your game, meant to sell the experience to a specific audience.” This aligns with some of the thinking from Romanos (2014) as it continues to demonstrate utilising the basic mechanics and features, with examples, as a way to best describe what you are trying to make.
Game pitches have been used since the inception of game publishers in order to help secure funding for development of products. There is a lot of discussion surrounding what makes a good pitch and some extremely useful resources explaining how to construct a game pitch, one of the more accessible resources was a talk by Upton (2017) at GDC that details a lot of what you should not put in to your game pitches
This further reinforces the usefulness of creating a Game Pitch at the start of project, in order to help define your Agile product backlog and to envisage your product completely enough to enable the Agile process and development to begin. Additionally it allows for exploration of funding methods for your product as these will likely require some kind of pitch based aspect in order for you to be successful.
References
Kanban Software for Agile Project Management. 2021. The Complete Beginners Guide to Agile Project Planning. [online] Available at: <https://kanbanize.com/agile/project-management/planning> [Accessed 8 August 2021].
Sweatman, J., 2014. Death of the game design document | MCV/DEVELOP. [online] MCV/DEVELOP. Available at: <https://www.mcvuk.com/development-news/death-of-the-game-design-document/> [Accessed 8 August 2021].
Clinton, K., 2010. Agile Game Development with Scrum. Pearson India.
Romanos, E., 2014. How to write a useful game design document | MCV/DEVELOP. [online] MCV/DEVELOP. Available at: <https://www.mcvuk.com/development-news/how-to-write-a-useful-game-design-document/> [Accessed 8 August 2021].
Wright, W., 2020. How to Pitch a Video Game: 7 Tips for Pitching Games. [online] Available at: <https://www.masterclass.com/articles/how-to-pitch-a-video-game> [Accessed 8 August 2021].
Upton, B., 2017. 30 Things I Hate About Your Game Pitch. [online] Youtube.com. Available at: <https://www.youtube.com/watch?v=4LTtr45y7P0> [Accessed 8 August 2021].
Figures
Feature Image: Photo by Katrina Berban on Unsplash
Kanbanize, n.d. Differences between Traditional and Agile Planning. [image] Available at: <https://kanbanize.com/wp-content/uploads/website-images/Agile/traditional_vs_agile_planning.png> [Accessed 8 August 2021].
0 Comments