Also, come to find peace with the fact that much of the stuff you do may fail. You'll do your best to match the vision of someone else's idea, but it just won't quite get there. Or you'll do something awesome, but it'll fail to make a compelling business-case for inclusion. Or you may just try out an idea which sounds brilliant, but ends up sucking BAD. Use every failure as an exercise in learning to fail quicker and better; minimising wasted work, and learning something beneficial no matter the outcome. Do Your Prep The counterpoint to working quickly, is to ensure that you have done your preparation fully before diving in. You want to get your code to a point where you can decide if the idea has legs or not. To do this, you have to know exactly what to test for; what the criterion for success is. If you haven't nailed this aspect of the design before you start, your prototype could drag on and on, way past the point in which it should have been put to bed. Also, consider researching potential solutions for a problem that already exist out there in the wild already. Recently, while developing a game idea heavy on motion controls, I spent over two months doing little else but reading academic papers on the subject to get a handle on how things worked, with little actual coding being achieved in that time. An entire game mode resulted from that research that would never have occurred if I'd jumped in with my Level 20 Hammer of Code and started bashing buttons. Don't Be Sloppy, Soldier Writing code quickly does not give you carte blanche to write sloppy code. In fact, prototype code has a nasty habit of becoming production code, so make sure anything you write is production quality. A kick-ass coder can nail production-quality code, quickly, at the first time of asking, rather than having to re-factor it all later on. That's not to say that re-factoring is never required – sometimes a feature morphs from its original idea into quite a different beast, and will naturally require large-scale re-engineering – but there is no place in the Rulebook of Awesome for going back and tidying up the prototype code once it's been signed off. That's just sloppiness. Go Be Awesome Whether you work in a hundred-strong AAA studio, a six person startup or a single dev indie project, whether you are a specialist gameplay programmer or wear one of many different hats – there are simple things you can do to be even more awesome: Stay positive, prepare fully, always code to production quality and accept that you may fail, and if you do, fail quickly! Go get 'em, tiger. (Got some tips of your own? Hit me up on Twitter or share them here.) [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.]
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." – Samuel Beckett
5 min read
Opinion: How To Be A Kick-Ass Gameplay Coder
In this reprinted #altdevblogaday-opinion piece, FreeStyleGames' Andy Bastable offers advice on how good gameplay programmers can transform themselves into "kick-ass gameplay coding ninjas".