The art of flash game production (with some baggage bowling fun thrown in)
Friday, January 15th, 2010We’ve not yet blogged about our latest game D’oh! It’s a neat little spin (you’ll see what I did there) on standard web bowling games put together by the dream team – a Thought Den / Team Rubber reunion with our star Flasher Corin and Team Rubber’s Dave doing the hard graft. You’ll need to play it a few times to get the hang of it, but that was the point…
As ever, we all got very excited with the brief, came up with some amazing game-play mechanics, tried to cram them all into one game, moved the goalposts a few of times and almost threw the baby out with the bathwater, but eventually ended up with a tight piece of work. Tear’s were shed but lessons were learned and here are our golden rules:
Team buy-in from the beginning
The sooner everyone involved can understand the underlying aim of the game the better. This means the client’s aims too. If the creative vision for the project ultimately only exists in one person’s head, an awful lot of management time will have to be committed down the line to ensure everyone is gunning for the same target. When the goals, creative vision and problems are shared from the beginning there less links in the communication chain and each member of the team has more understanding and ownership of the project.
Use the right documentation at the right time
There are client-facing docs, internal docs, technical specifications, flow diagrams, testing feedback and wireframes, all with their own valuable role to play. But we’re here to build the game, not make a million documents explaining why and how we’re going to do it. The documents are there to ensure everyone is on the same page, all boxes are ticked and limit nasty surprises along the way. Be strict on what information you are representing in which document. How much of it is really relevant at that stage, and what important details are being left out? Early input from the team and a shared understanding of the challenge at hand makes the documentation the best it can be but also means it is not the only resource to rely on.
Rapid prototyping and play-testing
The sooner a game can be played, the better, no matter what state the graphics are in. Forget splash screens, buttons, highscores and preloaders, we need to play it, get a feel for it, discover the fun bits and reveal any potential trip-ups down the line. In fact, a prototype is the best form of documentation in terms of game-play and what is a game if it’s not about playability? Cynics might say brand engagement or data capture, but the best way to achieve these is by rewarding the user with quality interaction.
Keep talking
The management process is a thousand times easier when you’re not left in the dark. And in the engine room too, it is essential the production team keep talking so that the pieces of the puzzle join seamlessly at the end. No matter how tight the production process, there will always be a desire to improve and innovate the output. In all likelihood the goalposts won’t stop moving until the 11th hour and the only way to prevent nasty surprises is to make sure people are talking to each other. Of course, it’s possible to over-talk, which is why development cycles and milestones are so important as checkpoints at which information is exchanged, keeping everyone up to speed.
Manage the feedback
The game should be played but the feedback must be collected, filtered and distributed correctly. The target audience are your most important motivator (besides the client I imagine) and it will be someone’s responsibility to make sure the game serves its purpose. With prototype feedback coming in from all angles, inevitably some of it will not be relevant and the build team need to be drip fed only the most pertinent information, organised so they can tackle it efficiently.
The War Room
As a project nears completion the loose strands need to be tucked in, the stodgy bits stripped away. This requires executive decision making from the project leaders and quick turn around from the technical team. If the shit hits the fan, this is where the team needs to be – all in one place for the final hurdle.
Make it good
Finessing a project and showing it some love when the build is essentially finished is the stage that so often goes by the wayside. This is when it can become something beautiful! Finishing touches like improving the user feedback, splash screen layout, calls to action and sound effects add the gloss and shine to a project that makes it something to be proud of. Unless, of course, you’re massively over budget and desperate to get the damn thing out the door. And then it’s for the seeding team to worry about!
