FInishing a Game

This fellow, Derek Yu of Mossmouth, has written an article called Finishing a Game. It's a worthy 5-10 minute read for any potential game developer.

I liked it so much I've written a summary of his summary. Be sure to check his article for the neato drawings of which I have none. Also his is funny.

1. Finishing is a skill, just like programming, drawing, or music composition.
2. Make a game that you want to make, but also one that you're capable of making, even if it is slightly out of your comfort zone.
3. When you "start the game," this means you can play the game in some fashion. You don't just have a game engine, a fancy written spec, or art assets.
4. Avoid making your own technologies when something out there already exists and fits your needs just fine.
5. The sooner you get a "working game" which allows you to prototype various game mechanics, the sooner you find out which ones are good ideas, which ones are bad, and which ones that give you ideas for better mechanics.
6. Do not choose partners based on skill alone. Consider how your personalities mesh, his experience in game creation, and your mutual interest in seeing the game completed.
7. Making a game be fun does not mean that it will always be fun making the game. Keep pushing yourself.
8. Have a deadline, and do not base it on a purely arbitrary date. Base it on competition events, for example.
9. Care for your well-being first. Keep eating, sleeping, exercising, etc.
10. Do not keep starting over the project. Just because you've gained so much knowledge since you first started the project doesn't mean you should scrap all previous programming work and start over. Fix only parts of it as needed. 
11. You will always feel that you could have coded something better.
12. If you have an idea for the game radical enough that you'd need to re-implement the entire game, or would incur a lengthy deadline delay, save it for the next game.
13. If you're behind schedule, determine which components of the game are important so you can cut off whatever that would be nice to have, but is not necessary.
14. If you're at a point where everyone else has quit and it looks like the project will not be completed as designed, use this as an opportunity to strengthen your "finishing skill." Scale the game way, way back, even to the point that it is no longer anything like the original concept if need be, so that you can finish it.
15. The last 10% of a game, the polishing part, always takes longer than you expect, but can be extremely satisfying and is usually where the game starts really feeling like a game, instead of just some project.

Here's what I've learned that we should apply to our own game development efforts:

• We aren't to the level of Blizzard or other triple-A game studios that say "It'll be ready when it is ready." We should probably get a deadline going, and make it public. This will give us a goal to work toward, and will give us the ability to determine what we should implement for the current game and what we should throw out or save for the next game. Making it public will make us feel pressure to complete it that we normally do not feel otherwise.
• We should probably have a written spec. Those are always good.
• Even if a good portion of game development might not be fun, we should try to maximize the amount of fun as possible, even if it is at the expense of a complete written spec or solid unit tests.
• Progress, not perfection.