(Coding)
Coding Your Game
Code flexibly. Changes happen, no matter how well you plan. If your game's structure is too rigid, you may find that a single oversight in the design phase could necessitate a re-write of some of your game's engine.
Prototype. Try to get your game to a quick-and-dirty playable state as soon as possible. The graphics need not be complete, and the bells-and-whistles need not be implemented, but it is important to get an early idea of how your game will play. It's possible that you'll try it and say, "Wow, this is no fun at all." Thankfully, if you've made this discovery early enough, you'll be able to re-work the gameplay and try again without much trouble. Seeing your game in action, even if in a rudimentary state, could also motivate you very effectively.
Don't optimize early. Spending your time optimizing code before you even know how the game as a whole will perform is pointless. Code flexibly, yes, such that future optimization will be possible, but early optimization can be a big time waster. You won't know where your bottlenecks will be until the game approaches its final state. If you spend days honing your blitting routines, only to find out later that your pathfinding routines are the bottleneck, you've wasted your time! (In the words of Donald Knuth, "Premature optimization is the root of all evil.")
Try not to throw away well tested code. The principle of code reuse is very important for large projects. You may think throwing away all of your code and starting from scratch is a good idea, but it may not be. Think of the weeks, months, and even years you have spent writing and testing that code. Read more on this philosophy at Joel On Software.
Deploying Your Game
So, your game is complete and ready for the masses, but how do you get it to them? That's where deployment comes in. Be sure to read our deployment page for a full description of the options you have.
Next : Selling
Coding Your Game
Code flexibly. Changes happen, no matter how well you plan. If your game's structure is too rigid, you may find that a single oversight in the design phase could necessitate a re-write of some of your game's engine.
Prototype. Try to get your game to a quick-and-dirty playable state as soon as possible. The graphics need not be complete, and the bells-and-whistles need not be implemented, but it is important to get an early idea of how your game will play. It's possible that you'll try it and say, "Wow, this is no fun at all." Thankfully, if you've made this discovery early enough, you'll be able to re-work the gameplay and try again without much trouble. Seeing your game in action, even if in a rudimentary state, could also motivate you very effectively.
Don't optimize early. Spending your time optimizing code before you even know how the game as a whole will perform is pointless. Code flexibly, yes, such that future optimization will be possible, but early optimization can be a big time waster. You won't know where your bottlenecks will be until the game approaches its final state. If you spend days honing your blitting routines, only to find out later that your pathfinding routines are the bottleneck, you've wasted your time! (In the words of Donald Knuth, "Premature optimization is the root of all evil.")
Try not to throw away well tested code. The principle of code reuse is very important for large projects. You may think throwing away all of your code and starting from scratch is a good idea, but it may not be. Think of the weeks, months, and even years you have spent writing and testing that code. Read more on this philosophy at Joel On Software.
Deploying Your Game
So, your game is complete and ready for the masses, but how do you get it to them? That's where deployment comes in. Be sure to read our deployment page for a full description of the options you have.
Next : Selling
