The Elusive "Quick Iteration": Tips for Indie Devs
From agile and scrum to extreme programming, everyone's trying to nail down what it takes to iterate on products quickly and efficiently. There are a lot of methodologies that you can employ to guide you through shipping products. But today, I'll be talking specifically about video games and how, as a developer, you can use a loose process and follow some basic rules in order to get quality games quickly out the door. You might argue that in today's day and age, with the Valves and Blizzards of the world, that taking your time speaks volumes for the quality of a game. Well, yes and no. For big AAA companies with a reserve of cash, that might make sense but as an indie developer you live and die off of shipping. The importance of quality and fun has not changed. However, the games industry is much more accessible and now developers utilizing fast iteration can make ridiculously high quality games in very short amounts of time. It's one of the few things we can do better than big developers.
Now, there is a fine line between making quick iteration a focus and getting bogged down in process. Every game and every team is unique. So, take these and mold them according to you or your team's style for the best results.
Make measurable steps every time you sit down to work
Did your mom notice that something changed with that last check-in? If not, then you may be caught in a common trap. When you sit down for an 8 hour workday and you don't make steps towards improving gameplay some things can happen: 1) You stall. You get too caught up on adding an animation pipeline to your engine. You spend all day refactoring your draw calls. This doesn't just eat up one day but multiple days spanning weeks of work. You're so heads down that you haven't come up for air and when you finally do: 2) Your morale drops. You realize that you just spent a week of valuable work time (or in many indie dev cases, valuable free time) working on something that made no noticeable improvements in your game. Sure, you're set on glorious animations for the next 3 games but in the meantime you're stuck with 98 levels left to create.
I'm not saying that those refactors or pipelines aren't important. Or that you don't enjoy getting in there and mucking around. But try to couple every systems task with a more visible task, usually art or gameplay. Take a break to put in some quick UI. Implement that restart button you've been putting off because you can just kill the process and rerun. At the very least, you have a new iteration of your game every day and you're one step closer to getting it out the door.
Someone should always be playing your game
As soon as your game is playable, others should be playing it. There have been a lot of great articles on this blog recently about the merits of playtesting. The very successful Spry Fox team tries to achieve their version of daily iteration. This means a designer is looking at the latest build and the developers are iterating on that feedback that day.
Whether it's a game designer with 20+ years of experience or your 12 year old brother taking a look at your latest build, you need feedback to iterate on. This is quite possibly the most critical step towards a fun and successful game and you shouldn't leave it to the end of the project when everything is set in stone. Not to mention hearing feedback on your game boosts morale. Even negative feedback allows you the opportunity to change something before it tanks your game. And higher morale is definitely what you'll need to push anything out the door quicker.
No matter what you might think, that extra particle effect is not what will tip your game from the dumps to a hit. Ship it and add it later. As indie devs, we need to break ourselves out of the mentality that the ship date is an all or nothing push. One thing that social games have learned is that majority of your dev time is best spent on post launch work. This is where you boil down what users like/dislike and what works and what doesn't. Even with all the playtesting in the world, you're never going to know how successful your game will be until you ship it. So ignore the fact that your UI takes an extra split second to show on screen, and trust that if your core gameplay mechanics and game's aesthetics did well in the previous step that it's enough to ship.
And finally, fail
The final piece of advice I leave with you is don't be afraid to fail. As long as you're failing quickly and often, switching things up and trying again, you can't help but learn. There was a great case study done where CEOs, business students, and children were brought into a room. Each group was told to build a structure as high as they could out of popsicle sticks. Guess who got the highest? The children. Examining what the children did differently they found that the children built up structures as quickly as they could, watched it fall, and then immediately started building again where as everyone else spent meticulous time planning and creating. So be like a child and build quickly. Whether it's failing or succeeding, you're moving in the right direction.