There is a very significant difference between a game mechanic (or collection thereof) and a finished game. It's not the quality of the game mechanic, or the way it plays, or the polish you apply to it. It's all the other stuff you just don't care about when you're prototyping or concentrating on The Next Great Idea.
As dull as it may feel in comparison, finishing a game makes a world of difference to the "game" play itself. Take, use and implement just one of the items on this list and then tell me your game isn't better off because of it. Seriously, the first time time I added a pause feature to a prototype I actually thought to myself, "Wow, it's like I made a real game!"
So - checklist, design input, verification or otherwise - if you want to make sure your game is finished, you need this list. I'm assuming the production of the Secret Sauce is under control.
Prepare each of the ingredients below, as soon as you possibly can. This recipe's all mise.
Simple - a button that when pressed pauses the game, wth a corresponding "resume" button. Ideally:
- It should pause immediately.
- The resume should resume gameplay immediately (expect for situations where it's awkward for the player to reconfigure their posture between the press of the resume button and normal gameplay - e.g. a console racer that uses the start button for pause/resume and a face button for gas).
- It should be located as per the norms of the platform (iPhone - in a corner; Xbox 360 - start button).
- Resume should be triggered by the same interaction (press start to resume, tap same corner etc).
- Audio and sound effects should pause immediately (no ambient noise or background music in pause screens please).
- Unless it provides an unwanted advantage, let the player see the frozen game screen in the background of the pause screen
Do this early. Avoid hacks and workarounds for accessing normally menu-driven features. It's easy to sketch out a layout of your menus and implement the navigation between them early on. Ideally:
- Menus should be immediately responsive to user interaction and load quickly (see almost any DVD or Blu-ray for an example of how not to do this).
- Menus should be easy and intuitive to use (that obscure setting might be quirky the first time, but it just gets irritating).
3. Save and load
Yes, this is hard. But liklihood is that you're going to need it. Get it in there early. Ideally:
- Saves should happen when you expect them to (Bungie's insistence on making the Halo player actually select "Save" despite having passed "checkpoints" since the last save is illogical and gets me every time -- it's still doing it in Reach).
- Saving should be quick - please don't make save game "names" mandatory on a console device, for example.
- It should be easy for the player to understand what the consequences of loading and saving are (i.e. do I lose current progress, can I resume from an earlier save etc). If Quantic Dream can do it for Heavy Rain, you can.
- There should be support for multiple save profiles. Some platforms provide for this briliantly (360). Some do not (I'm looking at you Steve). Worst case, Nintendo's model for most Mario games works pretty well.
4. Reset / restart
Unless you're specifically wanting to prevent it as part of the game's design, make it easy for the player to reset/restart since the last significant juncture (level, checkpoint, whatever). Ideally:
- Resets should be independent of the save/load feature - some players will want to reset a level regardless of where they loaded it from.
5. Platform-expected norms -- i.e. iOS resume / multitasking
This does apply to other platforms - but the iOS 4.0-introduced multi tasking has reinforced players' expectations around app switching and resume. If you've done (3.) this shouldn't be a problem.
6. Sound effects
I deliberated including music and art on this list -- but to be honest it's difficult to argue that they are really required to make a game a "game" as such. SFX are a different matter however: they provide one of the two primary/common sensory feedback mechanisms (visual being the other). Ideally:
- SFX should be optional - in most cases it should be possible to play the game without any SFX.
- SFX should enhance the experience, not distract from it.
- SFX should provide feedback to the player -- on a touch-screen device, for example, they help you compensate for the lack of tactile feedback on button/screen presses.
7. A title
This is all I'll say about marketing here -- and I'm not really including it for that reason, it just it normally gets lumped in "marketing". Your game needs a title. It doesn't matter what you call it -- you can change it later. You'll be amazed by how much easier it is to talk about your game when it has a name.
8. An indication of progress
The player has to understand what they have accomplished by playing the game. This is better explained by a list of what progress might look like:
- High sores
- Accessing a new level
- Unlocking an item
- Being rewarded with an achievement
9. Instructions and help
Think about a player picking this up for the first time - what do they need to know? Ideally:
- Controls should leverage the expectations of platform (left stick move; right stick look etc).
- Objectives should be clear when they need to be (it's okay if you want the player to figure this out -- but that has to be a core part of your game's design)
- There should be an easy fallback for players -- if they don't know what do where is the first place they're going to start looking? That's where you should put the help and instructions.
- Dynamic help is useful but it can get tiresome -- detect abnormal use (like the player hasn't jumped yet) and gracefully display non-intrusive instructions ("press A to jump")
- If you provide a structured training environment (whether this is a couple of dialogs or a training mode) make sure you clearly indicate length and relative progress.
10. The Secret Sauce
You did this already, right?