In this entry I will explore the way we approached planning, the project backlog and the release plan.
Project backlog
As discussed in my previous entry, we did not make final decisions on everything from the start, and instead let the game evolve as we go along. This, by definition, means that our project backlog can not be complete and exhaustive, or, in more management-y terms, we do not have the full set of requirements to start with.
It would be really useful to have this though, as we would be able to plan for time more effectively. In a previous project I led during my bachelor’s degree, we started with gathering a full set of requirements, breaking them down into the project backlog and executing as we go along. This is something you could definitely define as being Wagile (Waterfall/Agile). And it is very useful too, as we can do some calculations based on the amount of people we have in the team, the number of tasks we need to do (and the dependencies between them) and the total time allocated for the project. We can derive the critical path based on requirement priority and estimate how much time we can allow for each task. This is useful because it gives you focus and a clear end-goal. However, this was the approach I took for a typical software system.
Games are more not as simple as that in my opinion. The fact that so many bad games come out regularly would probably support this. It is not easy to make a good game. It is even more difficult to make one when you have little/no experience in being successful at doing so. As mentioned in the previous entry, designing puzzles is one such challenge. Therefore how did we approach this? Or rather, how are we still approaching this?
I view the project backlog as a tool to keep us busy and to keep track of what needs to be done/what is in progress/what has been done. The keeping us busy is the important part in my eyes. If we have tasks that need to be done, we can occupy ourselves with those. If we only have tasks for the short term, this is fine until we finish all of them. Once we do finish all of them, we can look back at what we did, think about the new ideas our work has given us and create more tasks. By applying this principle, you will never run out of things to do, as implementing one thing gives you more and more ideas.
I found that taking such an approach worked really well for Module 1 because:
The Release Plan agrees with it. The Release Plan defines what we should achieve in the given amount of time. Going from pre-production, to production, to post-production, this ties in neatly with starting from the basics (mechanics-wise at least) and expanding on the basics as we go along to make our game bigger and better. The Release Plan coincides with this idea so far.
The game is a blurred out picture to start with. You kind of know what you’re doing from the start, but you can’t possibly picture how everything is going to work in the end. This picture becomes clearer and clearer with progression. Therefore populating the backlog after completing the previous one makes sense – we can make a more informed decision about how to expand on what we have already, since we, uh, already have it.
Great ideas have room to grow. If we had defined our project backlog in full and we have a great idea of how implemented mechanics could interact to form interesting gameplay, we would feel the gaze of the project backlog behind our backs. We already planned what we are doing next. We only have enough time to do what we said we would do from the start. So where does that leave us? We either sacrifice a feature that’s already planned to implement the new idea, or we throw away this new idea altogether. Firstly, this adds team arguing, as opinions can be split. Secondly, this serves against the purpose of making a great game. The backlog is not going to play your game, so why should you make full commitments to it?
This sort of summarises what I think are the key advantages of doing this the way we have done so far, and why we should be doing it going forwards. However, there this one big red flag that I mentioned in my previous entry – we need to actually release the game, and we have limited time until that deadline.
Therefore, while the Pre-Production stage was creative and experimental, we will need to put a sort of “leash” on it, as our current approach does not translate to a finished game. Fortunately (-ish), we can kind of do this. We know what separates a finished product from what we have right now. We can populate the backlog with things such as UI, Animations, Visual Effects, Title screens and menus, sound, etc. This all needs to be done. The question is how long would it take and what priority should it get.
On one hand, we would like to finish developing all gameplay as soon as possible, since that would give the level designers the full utility set to do their job. On the other hand, we don’t want to have all of the aforementioned tasks not finished in time. This is something we will need to discuss going forward. While I do think that our current approach worked really well, this approach is a common cause of a game never getting finished as well.
Estimating for greatness, not time
One thing that I reckon we did quite poorly is estimating the time it takes to do each individual task (on the programming side, that is). As in, we did not fuss too much about estimating times at all. This could have been useful for having more direction and for throwing out ideas that are out of our time frame, rather than getting too enthusiastic about what can be put in the game. It would also make the project easier to manage and keep track of progress.
Instead, we approached it in a different way, which is prioritising tasks. We figured that we would just go ahead and do the tasks (an example of a task is implementing the moving platforms) that we think are a must-have in our game first, and then implement ones that are less important. The end-goal strategy for this approach was to put in as much as we can, see what we have once we do that, and work with what he produced to try and make a good game. I think that worked well because the team performed great and we were more productive than we expected to be. If we weren’t, we would have seriously suffered from this loose form of planning.
Going forward, I think we will have to spend more time improving on this, as I think it will be even more important during the production phase.
Adding some slack
When we started off, no one knew the framework or the physics engine that we will be working with (well, I kind of knew a bit of the physics from prior experience, but nothing significant). This was clearly a risk we needed to mitigate. What if we promise to deliver X,Y,Z, but we spend so much time learning the framework/engine that we only end up with X? What if X is not enough and we desperately need Y and Z in there for the game to be fun?
Well, the first thing we did was break down the tasks to miniature independent pieces, such that we can implement the bare-bones of our game. We identified and prioritised these tasks, such that they should “theoretically” take less time than we have. When I saw the demo of Team B’s game, I thought that we might have been more successful at doing that. We made sure our core mechanics are as solid as they can be (well, almost), while the other team seems to have focused quite a bit on things such as Menus/UI, while the basic gameplay was lagging behind a bit.
We allocated the rest of the time for research purposes, or, generic slack. A phrase I keep hearing from programmers often is “Oh, that is easy, I can do it in no time at all!” or something along those lines. It always makes me smile hearing that, because I use the phrase myself a lot, and it never pans out the way that sentence goes. Especially when we aren’t experts in the engine, everything took a lot longer than expected, so dedicating time for “figuring out how to do this thing” was greatly successful in terms of not over-scoping too much.
As far as I know, one of the tasks during Production is developing the level-data loading pipeline. We will be working with a level-editor we don’t know. Applying this practice of under-planning and adding slack will definitely be a worthwhile thing to do once again.
Godsend Project Management #2: Planning and tasks
In this entry I will explore the way we approached planning, the project backlog and the release plan.
Project backlog
As discussed in my previous entry, we did not make final decisions on everything from the start, and instead let the game evolve as we go along. This, by definition, means that our project backlog can not be complete and exhaustive, or, in more management-y terms, we do not have the full set of requirements to start with.
It would be really useful to have this though, as we would be able to plan for time more effectively. In a previous project I led during my bachelor’s degree, we started with gathering a full set of requirements, breaking them down into the project backlog and executing as we go along. This is something you could definitely define as being Wagile (Waterfall/Agile). And it is very useful too, as we can do some calculations based on the amount of people we have in the team, the number of tasks we need to do (and the dependencies between them) and the total time allocated for the project. We can derive the critical path based on requirement priority and estimate how much time we can allow for each task. This is useful because it gives you focus and a clear end-goal. However, this was the approach I took for a typical software system.
Games are more not as simple as that in my opinion. The fact that so many bad games come out regularly would probably support this. It is not easy to make a good game. It is even more difficult to make one when you have little/no experience in being successful at doing so. As mentioned in the previous entry, designing puzzles is one such challenge. Therefore how did we approach this? Or rather, how are we still approaching this?
I view the project backlog as a tool to keep us busy and to keep track of what needs to be done/what is in progress/what has been done. The keeping us busy is the important part in my eyes. If we have tasks that need to be done, we can occupy ourselves with those. If we only have tasks for the short term, this is fine until we finish all of them. Once we do finish all of them, we can look back at what we did, think about the new ideas our work has given us and create more tasks. By applying this principle, you will never run out of things to do, as implementing one thing gives you more and more ideas.
I found that taking such an approach worked really well for Module 1 because:
This sort of summarises what I think are the key advantages of doing this the way we have done so far, and why we should be doing it going forwards. However, there this one big red flag that I mentioned in my previous entry – we need to actually release the game, and we have limited time until that deadline.
Therefore, while the Pre-Production stage was creative and experimental, we will need to put a sort of “leash” on it, as our current approach does not translate to a finished game. Fortunately (-ish), we can kind of do this. We know what separates a finished product from what we have right now. We can populate the backlog with things such as UI, Animations, Visual Effects, Title screens and menus, sound, etc. This all needs to be done. The question is how long would it take and what priority should it get.
On one hand, we would like to finish developing all gameplay as soon as possible, since that would give the level designers the full utility set to do their job. On the other hand, we don’t want to have all of the aforementioned tasks not finished in time. This is something we will need to discuss going forward. While I do think that our current approach worked really well, this approach is a common cause of a game never getting finished as well.
Estimating for greatness, not time
One thing that I reckon we did quite poorly is estimating the time it takes to do each individual task (on the programming side, that is). As in, we did not fuss too much about estimating times at all. This could have been useful for having more direction and for throwing out ideas that are out of our time frame, rather than getting too enthusiastic about what can be put in the game. It would also make the project easier to manage and keep track of progress.
Instead, we approached it in a different way, which is prioritising tasks. We figured that we would just go ahead and do the tasks (an example of a task is implementing the moving platforms) that we think are a must-have in our game first, and then implement ones that are less important. The end-goal strategy for this approach was to put in as much as we can, see what we have once we do that, and work with what he produced to try and make a good game. I think that worked well because the team performed great and we were more productive than we expected to be. If we weren’t, we would have seriously suffered from this loose form of planning.
Going forward, I think we will have to spend more time improving on this, as I think it will be even more important during the production phase.
Adding some slack
When we started off, no one knew the framework or the physics engine that we will be working with (well, I kind of knew a bit of the physics from prior experience, but nothing significant). This was clearly a risk we needed to mitigate. What if we promise to deliver X,Y,Z, but we spend so much time learning the framework/engine that we only end up with X? What if X is not enough and we desperately need Y and Z in there for the game to be fun?
Well, the first thing we did was break down the tasks to miniature independent pieces, such that we can implement the bare-bones of our game. We identified and prioritised these tasks, such that they should “theoretically” take less time than we have. When I saw the demo of Team B’s game, I thought that we might have been more successful at doing that. We made sure our core mechanics are as solid as they can be (well, almost), while the other team seems to have focused quite a bit on things such as Menus/UI, while the basic gameplay was lagging behind a bit.
We allocated the rest of the time for research purposes, or, generic slack. A phrase I keep hearing from programmers often is “Oh, that is easy, I can do it in no time at all!” or something along those lines. It always makes me smile hearing that, because I use the phrase myself a lot, and it never pans out the way that sentence goes. Especially when we aren’t experts in the engine, everything took a lot longer than expected, so dedicating time for “figuring out how to do this thing” was greatly successful in terms of not over-scoping too much.
As far as I know, one of the tasks during Production is developing the level-data loading pipeline. We will be working with a level-editor we don’t know. Applying this practice of under-planning and adding slack will definitely be a worthwhile thing to do once again.