1. Do NOT end work on something that is halfway finished. When you're figuring out how to implement a system, the code and systems architecture is fresh in your mind. If you stop halfway, it's harder to dive back in and begin where you left off. This becomes a source of procrastination and can lead to project failure.
2. With #1 in mind, this means you NEED to take your project on in bite sized chunks! How long can you work for this day? Only take on what you can complete today!
3. Don't develop the next chunk in your main game project. Create a NEW project and develop the chunk in there. This does a few awesome things for you:
- Your modules are very loosely coupled
- Loosely coupled modules can easily be reused in any project
- Coding and testing a module is fast and simple because there isn't irrelevant junk to interfere or distract you
- You begin to see your architectural dependencies
- Allows for rapid prototyping
- Progress is fast and tangible which is more motivating.
5. Have long term plans. Why are you working on project XYZ? Are you trying to learn something new? Trying an experiment? Selling it to an audience? What are the criteria for project success? Reflect on how your day to day work brings you closer to accomplishing your long term goal. What progress have you made towards project success? If you have the perception of no progress, it's demotivating even if you actually made progress.
Example: I wrote an application to simulate gravitational effects in our solar system using newtonian physics. Everything was to scale and used real data. I abandoned the project after realizing just how freaking HUGE the universe really is. Even though I abandoned the project, it was a success because I learned a bit more about gravity and became completely puzzled as to how accretion disks actually form out of a particle cloud.
6. Sometimes when I'm coding up a solution, I realize that I need to solve something else first. (ie, a particle engine can't be implemented before you can render primitives or textures to the screen). Sometimes these tangential rabbit holes can go many layers down and you'll forget what you're trying to do and/or why you're trying to do it. Sometimes the problem you're trying to solve won't help you solve the bigger problem. Sometimes it doesn't even need to be solved. I like to keep Notepad++ open and write down a quick note on what I'm currently working on and why. When its done, I throw away my note. Anyways, the point is that its easy to get lost and the fastest problems to solve are the problems you don't have to solve.
7. Feature Creep can be a project killer. So can over-engineering a simple solution. Learn to recognize when you're doing this. Then stop it. Code for your current requirements, not possible future requirements (note that there's a fine line between rigidity and robustness here).
8. Pace yourself. Take breaks. Projects are a marathon, not a sprint. You don't want to burn yourself out by doing 16+ hours/day, 7 days/week and lasting for 2 weeks. It's a painfully excruciating pace. When you burn out, the marathon runner will pass you by because he's plodding along at a comfortably maintainable pace. He'll finish his project and yours will remain unfinished and useless. The initial passion you have for a project can be lengthened if you take it slower from the beginning instead of churning ahead at full steam, yielding longer levels of motivation and higher productivity.
9. Have fun. That's why we do this, right? Game development is the marriage of the right side of the brain with the left side. If the developer isn't having fun anymore, chances are that the game won't end up being much fun either (emotions are contagious & emotions are embedded into artforms).
If you manage yourself and your project right, it can be the most interesting thing you want to do from all the things there are to do (play games, watch videos, chat, browse web, etc). I hope this helps & good luck!
