In general I don’t tend to spend a lot of time planning things before coding them. I find that more often than not you can sit around and plan something so much that nothing ever gets done. There are a couple of side effects to this approach. I tend to get a lot done initially very quickly. Then I tend to stall out a little. The reason for the first part is pretty obvious. If you don’t waste time planning you have all that extra time to get things done. The second part is probably equally obvious but it’s just that unplanned code tends to require a fair bit of nudging around to correct for issues that arise from not planning it.
Amusingly there is another pattern that produces a similar set of results. It’s called a learning curve, and that’s both a problem I’m having and something that you can’t plan your way around. As I attempt to learn more about how the graphics pipeline operates I also need to constantly rewrite bits of code because of new things I’ve learned. I call this process “slow evolution.”
I didn’t want to bury my learning curve alive in the extra bits that make up a game so I started by creating a “Geometry Practice” program. I’ve already explained the difficulties I had with getting a single triangle on the screen so I won’t rehash that here, but this practice program is where that original piece of code lives.
The evolution so far as gone a bit like this… Start with the fight of getting a triangle on the screen, and do so with everything you need hard coded into the program. Next decide that you want your shader programs to live in files on the disk instead of being hard coded and write the code to allow that to happen. After that, get frustrated with hard coded geometry and realize that it might be a good idea to get those off the disk as well. So stop and craft a file format for conveying the informational bits that make up geometry and write a parser to load them. Next realize that you’ve got a few things coming flexibly off of the disk, but that which file being loaded is hard coded. That means crafting something that allows your files to be selected from the command line. Now that you can do fun things with the command line, make sure you allow that same system to tell the program about which shader files to load and which texture to load. Now that you can provide information about which mesh file to load, add proper paths that let different types of geometry to be loaded (without breaking types you already had working, oops). And so on…
You get the idea. I’m plugging along slowly evolving my practice program into the beginnings of the underlying graphics engine. From hard coded to flexible to encapsulated modular flexibility.