The Triangle of Game Development Speed

Posted by Rampant Coyote on April 1, 2016

Rachel Aaron – author, geek, and gamer – once figured out a way to drastically improve her writing speed, by a factor of 5, with some tweaks to her process. I’m always reading these kinds of things with an eye towards optimizing both of my passions — writing and game development — and I noted that the three factors that she mentioned have also been factors for me when I’ve been “on a roll” with game development. I can’t point to massive sustained and measurable productivity changes in the long run like she can (for one thing, measuring game development productivity is a bit harder…), but I can see some similarities.

As an aside: For writers, I definitely recommend her book, 2k to 10k: Writing Faster, Writing Better, and Writing More of What You Love. It’s short but cheap and packed with good practical advice in addition to an expanded version of the article linked above.

Aaron identifies three factors that were in many ways a “silver bullet” to improving her productivity: Knowledge (by far the most significant factor), Time, and Enthusiasm. All three apply to game development, with particular emphasis on the first two.

Knowledge: What this really means is planning and preparation, and this has been HUGE for me in game development. For most people, I think our brains prefer to operate in one mode at a time, and shifting between creative, planning, and problem-solving modes takes a not-insignificant amount of time. Trying to be creative while planning and problem-solving at the same time can be extremely frustrating. Aaron found that when she took a mere five minutes before starting her writing session to really make sure she was set, and to come armed with an outline and an understanding of exactly where she needed to go and what points she needed to hit made a tremendous difference in her writing speed… more than 2x all by itself!

I have found this to be 100% applicable in game development (and non-game software development!) as well. And not only applicable, but critical. Having tasks, goals, and a general plan-of-action before jumping into coding or building things makes a huge difference in productivity for me. It’s what allows me to focus and hit the coveted “zone” in development.  When I go in less prepared, then I stall out badly between tasks. Even just the act of deciding which task I should work on next can really slow me down, knock me out of the “zone,” and impact my productivity. Worse, I may end up “puttering.” Gold-plating. Tinkering. And worst of all, browsing the web. But that’s a point for the next section.

Bottom line: Go in with a plan of a attack. What exactly this consists of may be up to your own process, but at the very least, set goals and have a list of tasks in excess of what you expect to be able to complete for the development session. Have a solid idea of what you expect to see and have done when you are complete. Plan out the order that you are going to do things. This does NOT mean you must execute exactly according to the plan… not at all! No plan survives contact with implementation. But if the next step or task doesn’t come naturally and or organically during a development session, you have that default to fall back on.

Time: This really comes down to quality of time. For Aaron, she found that it worked best as contiguous blocks away from distractions (like the Internet). She also found that the first hour was the least productive (the time it took to get into the “zone” I guess), and that productivity started dropping off after 6 hours.

Now, when doing software development, sometimes the Internet is more important as a resource than it is a source of distractions. And I found that when I’m in the middle of level design and modeling, I can actually listen to podcasts without a problem… but I absolutely cannot do so while coding! However, discipline must be fierce to avoid turning it into a distraction. Otherwise a quick 10-minute check as a reward for finishing a task can turn into a 40-minute time-waster way too easily.

The point Aaron makes is that this is something that should be measured an optimized on a personal level, something I think is absolutely applicable in game development. We all have optimal rhythms, although I think most of us respond better to larger chunks of time (at least up to about 4 hours) without interruptions. We should try to arrange our software development time appropriately. It can be really tough with family, kids, social life, etc. Some folks I know resolve this by either staying up late or waking up early to have at least a couple of uninterrupted hours dedicated to development or writing.

Enthusiasm: This is a tough one. Aaron’s approach is a bit less straightforward here, but makes sense: If you aren’t enthusiastic writing it, how do you expect the reader to be enthusiastic reading it? Her solution was “stupidly simple.” If she couldn’t find the hook or elements to be excited about, it means that she had screwed up on the outline and was writing something boring that had to be removed or changed to be made exciting. That makes sense, right?

Well, that doesn’t map so well into game development. Writing is more of a 1:1 direct approach for the reader experience, but game development has many, many layers that have to be built into the system to provide the player an experience that is going to be different for each player. While things are getting far, far better with modern game engines, there’s still a crapload of work that is less-than-sexy that has to be done to make the game work. Like preserving game state and making it save and load, and providing an interface that does this that works with the rest of the game UI. Fixing collision issues.

One solution that worked really well for me on one project was to divide my tasks into three categories: Things that I was excited to do, things that would make a big playable / visual / audible difference in the game, and things that were needed but were not particularly exciting or noticeable. I think I labeled them, “Fun”, “Cool”, and “Other”  For example, working on the combat AI would be fun for me, but while it would make an impact on the game, it wouldn’t be something immediately noticeable. A cool new particle effect might be fun, but it would be in the “cool” category because it makes an obvious improvement to the game visuals. Hunting down an intermittent crash bug would probably be in the “Other” category. While it might be a huge relief to fix it, and sometimes bug-hunts can be kind of fun on their own, it’s not something I look forward to jumping into.

Anyway, once I made up these lists, and prioritized things a bit, I’d take one task from each category and lump them all together as a group. The idea was that I couldn’t move on to another “triplet” until I’d finished all the tasks in the current one, but I could do any of the current triplet of tasks in any order. It helped my motivation in two ways… I’d look forward to being able to work on the next ‘fun’ task, and then when I was done, I had a slightly cooler game to show for it.

That worked until I ran out of the fun and cool tasks. 🙂

I’m not entirely sure of the best approach to maintaining enthusiasm for an entire project, or even if that’s possible. Even for the coolest, most amazing game ever, there’s going to be a lot of butt-in-chair time that really just comes down to loving what you are doing and having the internal motivation to plow through some of the grunt work. But I think the lack of enthusiasm may be a huge reason why many game projects “stall out” before completion.

While there is no such thing as a “silver bullet” in game development to solve all the woes and difficulties, I think that variations on Rachel Aaron’s triangle may at least help us optimize so we’re not under-performing.

 

Filed Under: Production, Writing - Comments: 3 Comments to Read



top