I have a dark secret. I almost never finish any of the project I work on. I get them working to a somewhat degree. Often it's just to the point where I can say I learned something from programming that or when I solved the problem I wanted to solve. Never do I polish the interfaces or add the cherry-on-top features that would make give so much more value to the program. Once it's "okey" I tend to seize all development and continue on the next project. This is a terrible thing for a developer.

There are a few things to help one accomplish ones goals and finish the projects. Keeping TODOs up to date are an excellent tool. That way you can motivate yourself to pick off the items on the list one bye one and when the list is empty, you are by definition done. The problem here of course making the TODO and keeping up up to date. One even bigger problem however is formulating the items on the list. The goal should always be to make them as small as possible. By making the items smaller it is magnitudes easier to handle them. It's impossible to tackle something like "Create a game logics engine". (Which actually was/is a TODO point on my MiRPG-project) Something in the lines of "Add ability to disable GUI rendering via command line input" is much easier. However this line fails to define what should happen when the GUI is not rendered. So more clarity is needed still. By working out every little twitch and turn of the program, making TODO items and creating small and reasonable bit sized tasks for the developers is the key to Sprint Planning in the Scrum Developement Methodology, which I think help explains it's success. Divide and Conquer, simply put.

Another good, but dangerous trick as I have found out is to imagine and design the (graphical) interfaces first - and simply fill in the blanks with functionality afterwards. This makes it easier to understand how the software is going to be used, and it reveals what features are going to be needed. However, this is an extremely inflexible method of developing and should be used with caution. It does certainly help with getting things done. It most certainly does not however, help you get things done right. If you develop like this make sure think things through thoroughly before committing to implement it, or you will find yourself stuck in a corner when you get a brilliant idea for a feature or similar. Remember to apply your design patterns.

My current pitfall of coding horror is the graphical engine for the MiDungeon project, and I have been pondering it for several weeks the little spare time I can find. It boils down to the data structure called a Scene Graph. Which contains information on how to draw just about anything. However I've yet to obtain information how to implement this properly. Will I be stuck using OpenGL? How will it handle multiple light sources? How do I reduce the number of rendering passes I will have to make? The answer to those questions are just a few of the ones that seem to elude me. However after thoughtful consideration I have made great progress on the window and event handling part of the human view as well as the event managing system within the game engine. My plan is to get started on the logic as soon as I can display simple scenes on the screen and perform just basic movement.