This article isn’t going to teach you how to make a game.
It won’t hold any super-duper scripting tricks.
What I want to cover is the basic thought and planning process I use to design a game.

Now in all honesty, I am FAR from traditional in my work habits. I juggle more designs then I am actually capable of building, I drink while I work and I cut a lot of corners. But I do have some traditional habits that I think are always good to abide by.

First and foremost is the idea.

If you don’t have a good idea for a game, you won’t get very far. And an idea isn’t “I’m going to make a platform game.” An idea is more like, “I am going to make a platform game where you can destroy EVERYTHING in a level.”

Deciding on a genre is definitely a good place to start fleshing out an idea, but if you limit it to that you won’t end up with anything special. A clone of an existing game at best, a boring game at worst.

Hold on a second? Aren’t I the guy who has made a living cloning popular games?

Yes, at first glance, it appears I have a few games that are just clones of oldschool games, but that isn’t why people actually enjoy playing them.

Let’s take Ravage as an example.

At first glance, Ravage appears to be a rehash of Rampage. Was my idea for the game to simply clone Rampage? While rampage was the obvious starting point, my idea was to make a game where you could take on an entire solar system and see several unique landscapes and races. I wanted to make it play like rampage, but feel like a game where you were also exploring as you progress. And I wanted to make a game with a number of levels that was unheard of at the time.

Because of the idea behind Ravage and the similarities to Rampage it attracted fans of the old game, and new fans who didn’t have any sentimental attachment to the classic arcade game.

With all that said, Ravage is a rather dated flash game nowadays and perhaps not the best example of originality, but I felt the point of cloning needed to be addressed.

While using an existing game as the basis of your idea isn’t necessarily bad, it can also become too much of a crutch.

Other things that can become crutches are 3D effects, physics engines, shapeflag hitTests and yes, pretty art.

These are all things that make the game LOOK really hot, and add more realism to the visual presentation, but if there’s no substance to it you lose a lot of playability.

If you have kept up with the trends n flash games you will notice there are a lot of these crutch games that feel very gimmicky, and while the first few times you see these gimmicks they are impressive, especially at the technical level, they do not really make a fun game.

Do not take that as discouragement from using those elements, just remember not to base your entire game on them without adding some substance.

Think of these ‘crutches’ as building blocks. If you just slap on some paint, en the end all you have is a pretty block. If you add more blocks, the initial idea can be prominent, but also have a much more rewarding form.

Pick an audience

While it is always possible to make that one game that transcends boundaries and is appealing to everyone, it is always good to consider a specific audience.

When I make a game, I try to make a game I would like to play. Then I think about people I know, and what they would find appealing. Usually I get a set audience in mind, even if I can’t really put a label on them.

Mini-Putt was designed for what I like to call, the ‘casual gamer’. You can play it for 10 minutes, or you can play for hours. Anyone can play it, but it’s far from “hardcore”.

Knowing that I was making this game for a specific audience not only helped with the overall design of the game, but also helped in the post release period when I would filter through the reviews.

No matter how good your game is, half of the reviews are going to be bad. What I look for is the substance. Did the review touch on any of my goals for the game, and was the reviewer in my initial audience choice? If the answer is no and the review is bad, I pretty much ignore it. Those people would hate the game regardless of any trivial changes I made, it’s not in their area of preference.
Sometimes I am pleased to find great reviews from people who don’t usually fit into my target audience and that’s always a sign I made a great game.

Many times I hear from my peers and they are upset that their creations are getting bad reviews. This is because they didn’t have an audience in mind when they started. After the game launches, they inevitably tap into a specific group of people, but they often fail to realize that is the group they should be looking to for support and constructive criticism.

Know how much time you want to spend on your game

On of the biggest mistakes I’ve made in a lot of projects was not setting any goal for a time line. I always figured, I have all the time in the world to do this, so I can just get to it whenever.

I experienced a few notable results from that line of thinking. I would wait so long to get beyond the concepting stage that I would just lose interest. IF I ever decided to go back to the idea, I usually had learned a lot of new tricks, or a new version of Flash was out and I found myself starting over from scratch. Sometimes I would have these great ideas just sitting in limbo and because I never set a time line to work by, somebody else came up with the same idea and DID produce on it.

Nothing makes me more angry at myself then seeing an idea that someone else had getting acclaim and knowing that it could have been me.

Sometimes when you sit down and think about a time line for your idea, you will realize it may be too big for your current goals. If you are not in the position where you can spend 4 months on a game, write down your idea and store it away. With any luck you will find the time later, or your skills will grow to the point you can do it in less time.

If you know you can do the game in a time line that is within your ability, you can start looking at benchmarks.

To collab or not to collab, that is the question

One of the most difficult decisions to make is whether or not to collaborate with an artist or programmer. The obvious pros is it’ll cut your work-load in half, and you will potentially get done in far less time. The cons to collabs is you end up basing your work on other people’s timetables. If you decide to collab, don’t be afraid to take a bit of a management role and ask for frequent updates. Sure you may annoy the artist, but if they are THAT bothered by it, chances are it’s because they aren’t being very productive. If it gets so bad that they never want to work with you again, you are better off.

Make a list of benchmarks to guage your production time

While this starts getting into micromanaging yourself, it can be VERY helpful when you are working on a time line The key is knowing in advance how your game is going to work and being able to break it up into parts.

Depending on the game’s genre you may want to start with some visual planning. If you flush out your character sizes, level sizes etc before you really get coding, you will have far fewer adjustments to make later in your development.

If you are making the game yourself, there’s nothing wrong with just making boxes to fill the space used by sprites and tiles, but if you are working with an artist it is often helpful to sketch out a rough shape of the character, or have them provide you with some still art samples.

When you have your sizing planned out, your coding will go a lot smoother.

If this is a logical place to start, then set a date for yourself to have a final visual plan in effect.

For most people, the next logical step is to begin coding. Typically the coding starts with whatever element the player controls, be it a character or a series of tiles. This coding will involve any movement, animation display, interaction with the level, etc.

If you were making a platform game, you would probably want this step to include basic player movement and platform/wall collision. Set a date for when you want to get that done by.

Next is usually interaction with other elements, be it enemies, events, etc. In a platform game I would start coding in basic enemy properties and have it so they can be killed, do damage, etc. This may also involve flushing out the player sprite more to include attacks and reactions.

Again, set a date for this component.

And just keep setting dates for your benchmarks. Just remember to make time for testing and tweaking, especially if you have a real deadline, like a contest entry date or a contract date of some kind.

Save time: Reduce Reuse Recycle

This is where you start looking at efficiency and “corner cutting”. Efficiency is important because it not only keeps your files smaller, it keeps the render time in flash down as well. Reusing elements saves on additional work and keeps things optimized, and recycling saves a ton of time. The more time you can save, the more productive you can be. Just don’t cut TOO many corners.

What can you reduce? Do you have some code that’s really inefficient? Make a note of it and rewrite it as time permits. Do you have duplicate symbols in your library? Take some time and clean that up. Sound compression? VERY important to keep your sounds clipped up and compressed at a good rate, otherwise your file size gets huge, and the render time in flash is annoyingly long.

What can you re-use? Can you reuse symbols anywhere to save some bytes? Can you break up your code into class files that may be reused in future games?

What can you recycle? Do you have some explosion animations from an older game that would fit in nice? Sound effects that aren’t too obviously reused? If you got it, use it!

Account for possible mid-production ideas

A lot of time you will be making your game and you will think to yourself, “wouldn’t it be cool if the sprite did this when it landed” or “what if you could grab that.”

These ideas are the ones that make games great. They are the small touches that take your initial idea and allow it to blossom. I always try to plan my time line with the knowledge I will have additional ideas as I get into the game development. If you don’t make time for these ideas you will probably regret it later.

Leak some demos

I know a lot of people feel the need to be all crazy secretive with their games, but I find it helps a lot to leak a few demos here and there. You get feedback from people who aren’t your friends, and won’t sugar-coat their impressions. Granted you will get a lot of annoying comments on areas that aren’t finished, but if that’s the only complaint you hear, you know you are on track.

Leaking the demos can also get you a lot of pre-release hype, so when you finally do launch you may have a group of people ready to support your work and have a much more positive launch then you may otherwise have.

Show your peers, show people on a BBS you frequent, link your game in IRC, do whatever you can to get a decent sized test audience. They may have feedback and ideas you overlooked that can take your work up a notch.

DO NOT LET YOUR EGO PREVENT YOU FROM TAKING CRITICISM. The biggest gripe I have with a lot of artists is their ego is so big they honestly think their work is perfect and don’t take ANY criticism well. On occasion there are people who show me a demo. I make a suggestion and they tear me a new ass hole. And in a few of those cases they use my suggestion anyway which is doubly annoying.

When you get good ideas from people, the last thing you should do is lash out and get defensive. If it’s a bad idea, politely explain that you probably won’t use it, because that person may still have some valuable ideas later.

Isn’t using other people’s ideas stealing? Doesn’t it make the overall game partly theirs?

No, it’s not stealing. The idea is volunteered, and we aren’t working in a paranoid industry like TV or Movies where you get sued for using non-contracted ideas. As for making the game partly theirs…. I think that is a good thing. You should be making games for people to play, not to boost your own ego and self worth. So if you make it for ‘them’, they should feel like they have some small claim to it.

Polish makes perfect

One of the last things people do in their games is build menus and instruction pages. Nine times out of Ten these pages are informative, but are OBVIOUSLY thrown together last minute. You need to spend a bit of time on these screens. Polish them and any in-game HUDs and your game will feel more professional all the way through. You don’t need to be a good artist, just clever enough to set up appealing frames and use appropriate fonts. Sometimes a nice font is all it takes.

And so, there you have it. This is how I work. Is it the right way to work? Who knows, but it seems to be working pretty good for me. With a good amount of thought, I can get a decent idea into a final product in a month or two. And as I said earlier, I juggle a lot of things, so if I ever get THAT skill sorted I may even be faster than I think.

As far as all the ideas I’ve let go because they were too big, I am starting to revisit a lot of them because they no longer feel like monstrous challenges that I won’t have time for. I literally have a file drawer FULL of simple ideas, concept art, etc. I plan on leaking some of them on this very blog in the future if interest peaks up.