Opinion: I Taught My Cache To Lie

[Blitz Games' technical manager Tom Gaulton points out the five factors that can increase your number of iterations, and how to avoid those problems, in this #altdevblogaday-reprinted opinion piece.] "Iteration means the act of repeating a process usually with the aim of approaching a desired goal or target or result." (wikipedia) In the game development business, if you've ever talked to anyone about "iteration", there's a good chance you were discussing iteration times – how long it takes to perform one iteration, i.e. the time it takes to get from making a change to seeing the effect of that change. Usually you'll be either moaning about how painfully long that iteration time is, or gushing about how amazingly fast it is, depending on the tools in question. I do, too, I think we all do. It's universally acknowledged that long iteration times are bad. Not only does it mean that tasks take longer, but there's a good chance that during all the waiting around you'll switch tasks to fill the time, and then get completely distracted and forget what you were doing in the first place. Hands up if you've ever waited a minute for your game to load then clicked straight past the thing you were meant to be testing... then rebooted and done it again. Yep, me too. What about staring at an empty e-mail on your screen and wondering why you clicked New Message in the first place? There must have been a reason, before you got sidetracked onto that other thing. I once read a study (I can't find the link now, so you'll have to take my word for it) which showed that women multi-task slightly more effectively than men, but that both women and men multi-task incredibly badly and should really just stick to doing one thing at a time. S,o if long iteration times are leading to more multi-tasking and less focus, that's just a double helping of lost productivity. There's plenty of documentation and discussion about reducing iteration times and optimising workflow, including some articles right here on #altdevblogaday (for example). These provide valuable insights, from optimising your C++ headers, to ensuring you can boot your game straight to any point in any level without having to click through 5 menus and fight a horde of enemies. But iteration time isn't the whole story, there's a forgotten variable in the iteration formula – and that's the number of iterations required. There's no point using method A, where the iteration time is 20 seconds and it takes 20 attempts to get the right result, when method B takes 1 minute per iteration but only 3 goes to get the result you desire. Method B is far from perfect, but clearly better in this case. The holy grail of development then, is a blisteringly fast iteration time, coupled with a low number of iterations. Which is why I encourage you to iterate better, not just faster.

So what factors lead to an increase in the number of iterations? And how can we tackle them? 1. Complicated processes. The more complex a process is, the more likely that a mistake will occur, and that's an iteration wasted. To be honest, this point applies just as much to iteration times (a more complicated process naturally takes longer) but I wanted to throw it out there anyway. The solution? Simplify your processes wherever possible. 2. Unreliable processes. If the tool you're using crashes 50% of the time, you'll have to make the change twice as many times to get it right. Demand the tools that you need to get your job done effectively. 3. Poor feedback. Not knowing why your change didn't give the desired result is a recipe for endless iteration and often, even when you do get to the result you wanted, you haven't really understood why – which means you'll be back again later when your change goes wrong (cue more iteration). Invest time in improving the feedback, or heckling the person that can. I came across this a while back when I switched from C++ to Python for a slice of my development, my iteration times went down massively but the number of iterations went up initially because I didn't have any debugging tools (printf doesn't count!). Investing time in finding good debugging aids paid dividends in the long run. 4. Infinite monkey syndrome. If your iteration time is really low, the incentive to think about the change you're making will drop. Why bother calculating the amount of memory you need to allocate when you can just try a few values until you hit the right one? In certain situations there is no right or wrong result and in these cases iterating fast and often is the best way to go, but for programmers and designers especially, making changes based purely on empirical evidence is asking for trouble. It seems quicker initially, but it rarely turns out that way. I'd wager that even the most dedicated and hard working amongst us will fall into this trap from time to time, so keep an eye out for it. If you need to, write "I am not a random monkey" on a post-it and attach it to your monitor :) 5. Multitasking. I said it before and I'll say it again, don't multitask if you can avoid it. Even if you're waiting for a build process to complete, try to keep focussed on the change you're making – consider ways in which the change might not give the desired result, so that when something does turn out wrong you might already know why. I regularly cancel a code build part way through when I realise I've overlooked something, which feels a lot more efficient than switching to my e-mail for a bit, then running the broken code and having to debug it when I've already started to lose focus. The conclusion that I've drawn from my experience, and hope you will too, is that the number iterations required to achieve a result is just as important as the speed of one iteration. Of course you should analyse your processes to find ways of speeding them up, but also step back for a moment and look for ways you can reduce the number of iterations you need to do in the first place. Aim to get things right first time – you won't always manage it, but if you set yourself that goal then you'll get things right in less time than you expect. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]