…or how to create feature based iterations of your game.
When it comes to project management in general and prioritization in particular, many doubts arise among developers, especially in small teams and/or indies who don’t have the clear figure of a producer. This does not apply to game development only, it happens to other kinds of projects too, but it’s true that depending on the nature of what you are building it’s more or less intuitive to handle. I’m talking about the typical questions like “what do I build first?”, “do I need to have the game programmed before I put the final graphics on it?”, “how do I split the job into smaller tasks?”.
NOTE: This article doesn’t talk about the “vertical slice” as the common industry concept of generating a vertical demo to show to publishers or stakeholders, but as a continuous agile development concept for smart prioritization.
The problem
At this point, I assume most people create small tasks from their big task (the game) and keep track of them, hopefully with HacknPlan 😉 (if you don’t plan your work like this but you’d like to try, I recommend you to read this article). However, many people still don’t know which order to follow to assemble all these small pieces together. Classic software development (and games development too) using the waterfall model popularized the idea of splitting the work into technical pieces (engine programming, gameplay programming, graphics, sound…) and developing them independently based on a pre-written contract (the requirements document or GDD for game dev), with the idea of putting them together at some point when they are advanced enough. But, as you can imagine, this methodology has many and very important flaws:
- If you don’t put things to work together soon, you have a high chance of getting unexpected problems in the future. Placeholders and temporary stuff work fine for prototyping, but the longer you keep them in the development process, the later you will find issues derived from replacing them with the real thing.
- The later you have final (or semi-final) stuff working together as something “touchable”, the later you will really know what is the feel of the game, the user experience, what it transmits to the player. The sooner you have something close to the final result the better, because you can validate it works well as a whole.
- If you develop everything in parallel at a functional level (features) and one of these requirements changes or is even removed (and this happens all the time, especially with creative stuff), you already lost work. Having a fixed contract is never good because it assumes everything will be working at the end and this could lead to wrong decisions.
These problems could be even worse in really small teams or solo developers, where multitasking is so heavy. Imagine you are a lone wolf and you are designing the game, programming it and making the art too. You make a prototype of the core mechanics of the game with placeholder art and you validate is fun, so you go ahead. If your main skill is programming, you may have the temptation of implementing many features you have in mind, refactoring the code and building a great infrastructure, working on performance, on many mechanics that are not core… while keeping the placeholders. “The game is almost done, I only need to create all the content”. I’ve said this myself in the past and was a huge mistake. I went far on developing mechanics and technical stuff without working on graphics or level design (which was very important for the game as it was a puzzler), but I realized too late the ‘look and feel’ of the game was not the one I expected, and found design issues that I would have spotted before if I had created a full experience including real level design way earlier in the process. I ended up giving up on the project, unfortunately.
A solution
There is no silver bullet to make project management easy, but there are ways to organize your work that may be suitable for you if you already experienced problems like the ones I mentioned above (or you see them coming and want to avoid them). So, how can we get the look and feel of the game soon and at the same time be able to build the game step by step in an iterative way? By building what are called vertical slices of the game.
What I call vertical slice is similar to the concept of MVP (minimum viable product) from the lean startup method, where you create the most basic piece of software that gives some value to the user, in order to validate it, and you iterate over it again and again, getting feedback during the process. If you know about agile software development, this will sound familiar as it’s a similar concept applied from a high-level, functional point of view. But even if you use Kanban, Scrum or any other agile methodology at the moment, you may be building your iterations by making horizontal slices, grouping functionalities by technical topics instead of functional ones (frequent when the project is planned by technical people).
Does this mean we are talking about creating a basic version of the game to see if it’s fun? Isn’t that a prototype? Well, not exactly. A prototype helps you realize if your project is worth developing with the bare minimum, which doesn’t necessarily include many aspects of the game that would be important for an MVP. We are talking about the minimum stupidly simple game you could create (no matter how basic it seems), built with the quality of a final product. It doesn’t mean you need to create the final version of the main character of your game during the first iteration, but at least an acceptable one that could stay if there is no chance of improving it. Then, we do this again and again and again. We incrementally develop vertical slices of the game based on features and put them next to each other.
What are we doing here? We are validating these pieces and guaranteeing them. If we build a mechanic, with a player character, input, and a few other things, we are assuring that functionality is safe and is ready to get released. Could it be better? Ok, fine, everything could. You can improve it or polish it later on if you have the chance. You have something acceptable, something that, in case you spend all your budget or run out of time or whatever circumstance you may think of, you can deliver and is fine. Cutting features is so common when a project starts to have calendar/budget issues, but if you have 10 features ready and 10 to be done, is easier to decide what to cut than having 20 features at 50%.
A practical example
Let’s use an example to illustrate this. Imagine Super Mario Bros, which is a game I guess has never been used as an example for a game development-related article. In order to simplify the example, let’s say there are 3 devs, Laura the programmer, Matt the artist and Sven the level designer, creating this game for the first time.
In a technical-based iteration:
- Laura the programmer, with the prototype on one hand and the GDD on the other, starts building all the mechanics for the game: running, jumping, breaking blocks with the head, the star power up, the mushroom, the enemies… Matt doesn’t have the art ready yet, but she knows he eventually will as it is defined in the document, so she keeps going on by using placeholder art.
- Matt the artist, following the GDD too, starts creating all the sprites for the game. As it feels more natural, he starts with Mario, which consists of several animations: running, jumping, getting bigger, getting smaller, launching fireballs… After that is finished, he will go for the next asset in line, let’s say tiles for the levels and also some enemies and backgrounds.
- Sven the level designer, based on the design document, starts designing the levels using pen and paper. He knows he will have several tile types, interactive objects, and enemies to compound 4 fun levels per world.
- At some point, Matt has finished the Mario spritesheet, with all the animations and stuff. Now Laura can replace the ugly placeholder or provisional version of the sprite with the brand new one. She also developed all the logic for the enemies, but they are not ready yet, as Matt is also creating tiles in order to start building the levels Sven is creating. He has 8 levels designed on paper now by making use of all the elements he had available as stated in the GDD.
- Now, since life is tough and shit happens, the budget is cut and they need to cut on features to release something smaller in scope than what was beautifully designed in paper at the beginning. What to cut now? They decide to cut the feature that makes Mario launch fireballs, as it’s not as core as others, which means the animation Matt created is wasted. They also think that maybe the rotating fire bar and the bullet cannon could be removed too, and they haven’t started building that part yet so is not that painful! But guess what, Sven already designed several levels that make use of those elements, so cutting them would mean he has to redesign those levels making use of other elements. You get the point.
In a feature-based iteration:
- The team decides the first vertical slice of the game they are going to build is a level where there is only a flat ground with holes, so Mario can run, jump over them and get to the end of the stage.
- Laura implements (or refines, as that would probably have been implemented for the prototype) the mechanics of running and jumping. They are deeply tested and balanced to be good enough for a final game. Little functionality, but very polished.
- Matt, instead of building the whole Mario asset, only creates two animations: running and jumping. He also creates a background picture and some tiles for the ground.
- Sven doesn’t have great work to do in this iteration, but he creates a small level with holes that challenge the player on the different jumps they can make. This level will probably be discarded at the end, but it has been implemented with final production quality no matter how simple it is. It gives an early feeling about the jumps and how they can be used for more complex levels, and it could be included as a tutorial level if they’d want to.
- The team gets this small slice of the game, which looks good and feels good on their hands, even though is a very simple pseudo-game. They have guaranteed their game will have jumping functionality that works well and there will be challenges with holes.
- They keep going with more similar iterations: a vertical slice of the block breaking functionality with all the graphics involved and a level that uses it, then another one for the first enemy and the possibility of jumping on them… Once enough features are complete, some levels can get their final shape as normally these features and elements are introduced sequentially and step by step into the game.
- But hey, at some point shit happens too and the budget is cut. What would they cut now? Well, they are following the GDD too, but since they have been working on vertical slices and ensuring them, they already have something that, being better or worse, it’s in a ‘close to shippable’ state. If they want to cut on features like the fireball throwing or the bullet cannon, they can, as these vertical slices have not been started yet for any of the technical aspects of development, hence no work is wasted.
This example is oversimplified, but I guess you can see the benefits of this approach. Take each iteration or milestone as a reduced version of your game, instead of as an unfinished version of it, and you will reduce the chances of suffering the consequences of incidents during development, or at least minimize them. It’s important to remark that, for this process to work, iterations shouldn’t last very long, or they could have internally the same issues we described for the project (many things in parallel that are not yet assembled together).
Conclusion
As I said at the beginning there’s no silver bullet and probably this couldn’t (and shouldn’t) be applied 100% of the times, but iterative development is good on scenarios of uncertainty, as it embraces the possibilities of change as a natural part of the process. There are other interesting benefits of this approach:
- It’s the way to go for early access, as you shouldn’t ship an unfinished game, but one reduced in scope, so players can get a real grasp of the game.
- As you have your game in a ‘potentially shippable’ state from the beginning, you will have good looking stuff to show soon, what is good in order to start building a community, generate interest around the game or preparing a crowdfunding campaign.
- You can start QA soon in the development, so you distribute the load along the process and it does not become a bottleneck at the end. Each vertical slice should be tested as part of the iteration, you make sure it’s good enough for delivery.
That’s all, I hope you have enjoyed this article and got some ideas to improve your project management.
Happy planning!
Really interesting article, great insight. These points almost seem like common sense, but you can see how a different mindset might overlook it completely. Thank you, this is great advice as I make my first tentative steps in the field of game development. Much appreciated.