Yet more game development tips!

Are you sick of game development tips yet? Between the endless array of indie game blogs and the myriad of developers shooting their mouths off on Flash Mind Meld, you probably are by now. But in case you're not, I wrote some tips for Microsoft's Ubelly blog. You may read them. They also have a contest to make an HTML(5) game or creative app with some cash prizes etc. Please note -you may not use any plugins for the contest, not even VRML.

A 3 minute lesson in game design (my talk from Flash on the Beach 09)

Update: You can now watch the video here.

I'm back from Flash on the Beach in Brighton. There are loads of great write-ups of the conference coming out, so you don't need another from me, but here are my slides and notes from my 3 minute "elevator pitch". While I'm writing I will just say it was great to meet all my fellow pitchers, and I think we gave a rockin' session - in the main theatre no less, so probably about 600(?) people saw it. Here's my slides (click on slide to advance):

Here's what I said:

I'm Iain, I make Flash games. Here are my tips for making Flash games, but hopefully you can apply them to whatever it is you do.

Make it fun.

• When you're making games it's easy to get side-tracked by your awesome code framework or particle effect or whatever,
• but if you don't make a fun experience for players, what's the point?

Make it obvious.

• If you need to have an instructions screen on your game, you've already kinda failed.
• Talk to your players through the language of games.
• When you get the power-pill in PacMan, the ghosts go blue, their mouths go wobbly, they start running away.
• The player thinks – ah that's different, maybe I can eat ghosts now – ah yes I can. No instructions necessary.

You've got 10 seconds to sell your game.

• Players browse web games like they're flipping channels on cable TV.
• If they're on a site like Kongregate they've got the choice of 18 thousand games.
• So forget all the cut-scenes, menus and tutorials, get straight in to the action.

Match your control scheme to your audience.

• Try not to mix mouse and keys. Pick one.
• If you're making a casual puzzle game, just use the mouse.
• If it's a platform game, stick to just arrow keys and spacebar.
• Only if you're going for a pretty hardcore audience is it safe to use mouse and keys together.

Evolve your game.

• I've worked on far too many projects that had months of planning, emails to clients, design documents, wire frames, PhotoShop mock-ups.
• Not until two weeks before the deadline, you actually start developing.
• The day before the deadline you finally finish it and play it through. Is it fun? No. But it's too late change it.
• So throughout the process, make prototypes, iterate.

Stick a face on it.

• There aren't many games that can survive without characters,
• so even if you're making an abstract physics puzzle, you should be thinking about how you can make it feel human and approachable.

Playtest!

• While there's still time to make changes, put your game in front of real players.
• If you think you've got intuitive controls, players will be mashing the keyboard going “what do I do”?
• If you think it's too easy, to a new player it's probably impossibly hard.

Respect the medium.

• Don't just make games with Flash, make games for Flash.
• Flash games have there own genres, like physics puzzles and tower defence that have evolved to suit the medium.
• Don't copy other games, but work out what makes them fun.

Flash development - are you doing it wrong?

Inspired by years of working with Flash and with other Flash developers (ninjas and newbies), here is my checklist of how to do things "the right way" in Flash and ActionScript (don't really know about Flex - you crazy guys do whatever you like!). I really want your comments on this one. Am I way off the mark? Do I go too far, or not far enough? Leave a comment please! Here they are:

1. Don't use code for layout. If you are setting the position of all your visual elements with code, rather than using the Flash IDE, you are doing it wrong. Designers like to "nudge", "align" and "tweak" layouts, and if you have to change a number in your code and republish the swf for every nudge, then you're probably in for a long night. If you have a data-driven site (e.g. with a variable number of menu items), you may have to do some dynamic positioning, but keep it to a minimum.
   
2. Don't write code on the timeline. Why? Because you can't search it, open it in an external code editor, version control it or merge it, that's why! Version control and a decent editor (ie. Flexbuilder, FDT or FlashDevelop) will save you many hours of development. These editors have great auto-completion features, and a version control system such as subversion may just save your job one day - when Flash corrupts your FLA or you accidentally overwrite your whole day's work. The only good reason to write timeline code is calling functions or dispatching events during timeline animations (e.g. dispatchEvent(KICK_BALL) when the animation of the foot reaches the ball), but again, keep it to a minimum.
3. Write lots of small classes. When transitioning from timeline scripting to OOP, a classic mistake is to make one or two big "god" classes that control most of the functionality. If you're doing this you haven't really transitioned to object-oriented code at all. Each class should do only ONE thing, or to put it another way, there should only ever be one reason to change any of your classes. This seemed very prescriptive to me at first, and I still find it difficult, but I've learned to love it! How long should a class be? Well anything more than about 500 lines seems like it could be broken down more. In any particular project I normally have at least a few classes that are only 5-10 lines long. Think about your project as a set of self-contained components that you could re-use if you wanted to.
   
4. Use ActionScript3 whenever possible! I've met a couple of people who are still defaulting to AS2 for "simple" stuff. Er, why? Better to get your head into AS3 mode as much as possible, especially on the easy stuff. How else are you going to learn? AS2 is rubbish! You may still have to use it for some banner-ad networks, etc though :(
   
5. Don't use the main timeline to organise the "flow" of your site. I used to swear by this method as a way to organise my sections - creating a separate class for each screen, and putting each screen on a different frame. Move to a different frame and Flash will automatically destroy the old section and create the new one. Easy! Only problem: doesn't work in AS3! It will remove the section from the display list, but it will stay in memory, running its ENTER_FRAME, probably throwing errors, and generally doing the naughty. The solution? Create and destroy all your screens / sections from code - e.g. mainMenu = addChild(new MainMenu()); removeChild(mainMenu); mainMenu.destroy(); etc.
   
6. Tidy up after yourself. Keep your FLA tidy. Name your layers, name library items sensibly and keep them organised. Delete empty/guide layers. At the end of the project, delete all your traces, unused code, and any commented out code -they will only confuse you later.
   
7. Test extensively. Test driven development for a Flash developer should mean running your swf and clicking on everything really fast until it breaks, then fixing it and doing it again. The more complex the application, the more ways there are to make it do something unexpected, throw and error, or generally crap-out.
   
8. Know how good you are. This one goes a few different ways. On the one hand, don't be cocky and let your ego write checks your body can't cash. Don't commit to mad schedules or deadlines. Make sure there's contingency time built into every project, because you can pretty much guarantee something will go wrong at some point. On the other hand, don't be lazy or complacent. Don't look for excuses not to change your code or design. If a colleague suggests an improvement, don't just go "No, it doesn't work like that", but think seriously about the cost/benefit of the idea. Keep improving your knowledge and learning new technologies, because if you don't, the industry will eventually leave you behind. Know what you're worth. If your boss is driving round in a sports car while you do all the hard work, you're probably doing it wrong.
   
9. Don't use anything obscure. Sometimes I'll make an update to a project that was created by another developer, and I'll experience some weird behaviour, missing files or unexpected errors, and it will because the developer has chosen to use some obscure feature of ActionScript or the Flash IDE. In Flash CS3, it might be menu settings like changing the view preview quality and everything on the stage looking weird, or turning off "export hidden layers" and half your site unexpectedly disappearing. Everyone SHOULD turn OFF "Automatically declare stage instances" though, as it's very confusing to not have all your variables explicitly declared. Try not to use weird language features and optimisations, like backwards loops unless they're completely necessary. Name your functions and variables with full English words please! That includes writing "event:Event" instead of just "e:Event". How can you search through text for a one-letter variable?!
   
10. Sweat the details. Polish counts for a lot in Flash sites, so the more time you can devote to little finishing touches, the better. Consider things like: fading in-and-out on page transitions rather than just jump-cutting from one page to another, adding custom options to the right-click menu, disabling the Tab key, optimising the file size and creating a decent preloader.

Hope you found something useful here - trust me, I've learnt these lessons the hard way! Leave a comment if you agree or disagree with any of them, I want to know what you guys think.