[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".]
In my last article I blogged about how awesome gameplay programmers can be and, indeed, how vital they can be to a creative industry like ours. But what makes a good gameplay programmer? And how do you go from being a good gameplay programmer to a kick-ass gameplay coding ninja? Here are some tips I've picked up over the years.
Don't Be "That" Programmer
We all know AngryProgrammer™: the ultra cynical technician who pours scorn on anything that doesn't fit into the tidy box they like to work in. Rule one of being kick-ass? Don't be that programmer.
AngryProgrammer™ is angry.
Being an awesome gameplay coder means leaving that cynical attitude by the door. Yes, you may not like the feature you are tasked with all that much – and you may not even think it'll work that well, but keep an open mind and you may be surprised by how it develops.
Work with designers and artists, and not against them. That doesn't mean not speaking up when something is wildly unrealistic, or bound to contradict several TRCs – but it does mean being willing to try out things that don't get all your creative juices flowing at first glance.
Also, admit when you are wrong. It'll make you much more humble and nicer to work with in the future if you do. It'll also make FloatyCreativeDesigner™ much more likely to trust you in the future when you kick up a stink about something that really won't work.
Fail Quickly
Speed is one of the greatest assets of the gameplay programmer, particularly when prototyping and refining new features.
It involves getting to grips with the essence of the design quickly. In many cases, this may mean helping to shape the design with the help of whoever holds the vision for the feature until it's in a form that you can run with.
It also involves turning code around quickly, doing the least amount of work necessary to get a feature in a playable state to be tested and reviewed. Then being prepared to iterate on feedback as requested.
"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." – Samuel Beckett
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.]
I agree that there is never a time when sloppy code is appropriate, but refactoring doesn't mean fixing something that is broken or written sloppily, it means revising something later when the problem is better understood. No programmer can put forth perfect code every time, because the requirements and limitations aren't fully understood. Example: space vs. speed is a constant trade off in programming, and until it's determined which one is more important (later in the project) optimizing either is not necessarily better.
