Writing functional specifications for games

I've been reading Joel on Software recently and so I've become pretty sold on the idea of writing functional specifications before getting too involved in development.

I'm about to have a go at creating a simple 2D game (not too simple mind), and I can really see the gain - in the past I've just jumped开发者_开发技巧 into writing extremely simple games and I've found myself getting stuck or rewriting the same bits over and over again as I suddenly realise I have no idea how my level should be defined, or I realise that I want to be able to jump but that means completely re-thinking my collision detection.

Anyway, so I've started coming up with a functional specification but I'm struggling a little - I can see and understand the point of it, but I've not really written many functional specifications before and so I don't really know how to start. The examples that I've found on the internet are great, but they are mostly process-based (user submits form A, then form B) etc... which doesn't really apply much to the structure of a game.

Does anyone have any advice /examples on how to strucutre / write specifications for games?

---

It's quite simple at the basic level. You just have to spell out your features each in terms of a specification. Given a certain situation or event, what should the system do?

Game developers are notorious for having a feature in some other game as their mental specification (eg. I want to be able to jump like Mario, or rotate blocks like in Tetris) but those specs are only as good as your own understanding of the system you're copying. (This reminds me of the browser wars where people would say that Firefox was rendering something wrongly because it didn't do it the way that Internet Explorer did - Mozilla couldn't formulate a spec for their IE emulation mode that was better than "look like IE" because nobody outside of Microsoft could possibly know the exact rules IE was using.) So you should try and make sure that your specifications for a feature would make sense to someone who's never played a game similar to yours, and therefore stand alone. That will force you to dig deeper into the detail and find the sort of corner cases that Joel is suggesting you'll find.

---

Make you sure that each point specified is empirically verifiable.

For example, in a 2D shooting game, don't just specify "Weapons". This can mean a lot of things. Explicitly specify "Player can shoot weapons", or "Player can pick up weapons", etc.

This means you can easily put down concrete objectives, and then make sure you accomplished them.