What parts should you implement first and last in your game?

What are the main parts of the game one generally finds in all games (user input, gra开发者_StackOverflow社区phics, AI, menus, collision detection, sound, cheats, levels, configuration, etc etc.) I should implement and focus on first and what should I leave for last?

The other answers are all good, but to some extent they don't really tell you what to write first.

Of course you need a gameplay design, or at least enough of an idea to explore that you know roughly what you need to to. And it is good to get a vertical slice going (a bit of everything working so you can actually play the game as early as possible and prove that you can overcome all the core challenges without any nasty surprises)

But I would say (to be a bit more specific) you actually need to write a framework first. Too many games are started with "I'll just start with some graphics" and then they try to bolt on things like game objects, collision and AI later. I worked on one triple-A game title where every sound effect in the game had to be attached to a tiny triangle hidden under the floor because the original coder's bolt-it-together-without-thinking-first design was that every object in the game was "a graphic"! Argh!

So a framework: That is, a data structure and communications architecture that supports your game's needs. For your suggested game, a very simple framework will suffice - the main thing is to think for a few minutes about what objects will be used in your game (e.g. perhaps two fighters, and a camera), and how you will store, connect together and use their graphics, audio, collision, and AI behaviours, and how you will pass them information (UI inputs to control them, and how they will query the world around them to make their gameplay decisions). As long as you consider all the elements of your final game, you won't trip over something obvious later on. Try to make it modular (so you could replace the 2D graphics with 3D graphics displayed in a 2D plane (i.e. a completely different renderer) without having to rewrite the collision and AI)

Even if you don't exactly know yet how you will do something, simply considering that you will need it can make your design much more flexible and save you massive headaches later.

So, sorry, you have to do a chunk of the boring stuff before you can add some fun pretty stuff.

And last? That is the gameplay polishing. Once you have a framework you can get a working prototype going with simple graphics, and get the basic gameplay (UI, collision, AI) right. Then you can spruce it up with better graphics, audio and menus, joystick support etc. But it is only towards the end of this process that you have the full look and feel to test. And that is when you need to play the game critically and get the gameplay balance right. You might find that over time you have added huge heads to your fighting creatures beause it looks cool, but that this has caused a cascade that has reduced the playability of the game. Or that once you add some audio, you feel you need a bit more animation in the graphics to make a hit feel really solid. So the final phase needs to be a good chunk of time dedicated to just tweaking the balance to achieve perfection.

If you do multiple levels, then when the whole game is finished, you need to play through the whole game to adjust the levels to form an interesting, challenging sequence. So it's still polishing that comes last, as you can't balance this stuff till erverything else is finished.

Remember that the graphics, audio, collision, AI and UI are all vitally important to the game, but the gameplay is more important than all of them added together. Asteroids is still one of the best games ever, and it was just a bunch of monochrome lines and some beeps - but with excellent gameplay. Most games these days forget that lesson.

You'll want to get all those systems up to a rudimentary functioning level as soon as possible.

One level. One character's AI. Minimal collision...

Then you can see if what you produced is any fun.

You'll appreciate the insight you get from actually trying your idea and you'll have no trouble knowing what to concentrate on next.

Also, you'll know as soon as possible whether your systems have a fundamental problem fitting together, before they've become unwieldy.

The order is very dependent on the type of game. Most games have a basic interaction that is repeated over and over. That is where your focus should be. You've got to build the simplest prototype that lets you explore the core idea for your game, so you can see if it works (and adjust it as necessary). Some examples with actual games:

• Shooters, like Gears of War: Ducking under cover, firing at enemies. Needs 3d, path finding and collisions, maps with various layouts and a bit of AI.
• RPGs, like Dragon Age: Here you need the rule system used to calculate skills, damages, and simulate combat. If the combat is not somewhat deep and enjoyable, no amount of 3d or even story is going to save it.
• Platform-based, like Mirrors Edge. The map layout and the input system are needed to see if you can actually do something.

So what I'm saying is that you should determine what is the stuff you absolutely need, and leave everything else for later. If the sound is not important to the gameplay, leave it. If the game is not text-heavy, leave the menus. And so on. If you are doing something that is 3d based, you will need the 3d engine fairly early, as it usually influences other parts of the game.

And another thing. Try not to be too ambitious. With every little thing you add, your game becomes harder to balance, more so if you want to do something with multiplayer. It's better to have something simple that can be played that something complicated that never was even usable.

Gameplay & story!

That's easy, you start with what is most important. The hard part is figuring out what that is.