Progress isn’t made by early risers. It’s made by lazy men trying to find easier ways to do something.

The Art of Daydreaming

Posted: October 20th, 2010 | Author: | Filed under: Tutorials | 1 Comment »
20070118_daydream

Daydreaming helps!

So for the past week or so, I’ve been feverishly working on Darwena. I got my platform-specific code up for the PC and OSX, got my OpenGL contexts working, integrated FreeImage and FreeType. And then I stopped. For the past day and a half, I have been doing nothing but dreaming and conceptualizing. Professionals would call this design, but no, it’s all in the head. It is something that very few novice programmers engage in.

So what was I daydreaming about? It was how to implement my material system. Give this task to any graphics programming student, and they’d be right at it. How hard can it be? All you need are textures, maybe color and alpha bias. That and throw in some shader support if you’re ambitious enough, right? So why am I sitting here thinking about it instead of going straight to implementation, like I would do for any school assignment?

The reason is that I have hit a critical section. No, I’m not talking about multithreading. What I mean is that any functionality I implement at this point is going to change the whole texture of my entire engine. It is going to affect its capabilities, ease of use, and generally the whole design philosophy. Yes, I have set down the design philosophy ahead of the whole project, but subtle nuances at this stage of development can heavily influence the interpretation of this philosophy. This makes it worth a taking the time to put a little thought into it, no?

So how do you go about this daydreaming process? First thing I do is clarify all the design objectives of this particular subsystem, and how it will affect the texture of the whole engine. What do I want from it both now and in the future? My first milestone is a 2D engine, so it seems rather trivial. But when I want to extend to 3D and beyond later, I had better have a system that can either be extended or is already capable of that, yes? Also, there is a reason why I chose a 2D engine as my first milestone. I want to have a very dynamic fluid organic material system. If we focus on 3D straight away, this is usually glossed over. In a 2D game however, you do pay attention to animated textures, sprite systems and other things that will make your overall material system more robust.

That done, I start of with the most obvious solutions. Step through each one in my head, and weight the advantages, disadvantages and perceived problems. I also envision how this implementation will affect the design of other systems. It can be a bit much, but it is a system of thinking that I have developed over the years. Visualizing the code running in my head and seeing what leads to what. Then you start tweaking. How different are the results from what you can achieve? Can you make subtle changes to make things go the way you want them to?

Finally, after doing all that, it’s time to do some research. Hit the web and the periodicals to see how everybody else tackled these design issues. Note that this is done only after running through things myself. Most fresh programmers would go straight to the altar of the Google God, pick the first feasible solution they come across, and copy-paste the code, massaging it into their own code base. They then end up with the ideal solution for somebody else’s project. At the very worst, they have a piece of code that they do not understand and just seems to work like a magical black box. This is not good. Not good at all. Instead, what I do is see what others have done, and what benefits they get from doing it their way. Then I look at my own original solution, and fit together ingredients from the ideas I gathered from the wild till I am happy with the concept, and how it will fit in with the rest of my codebase.

And then after all that, I finally start writing code. This is actually the easy part because you already know what to do. All you are doing is translating the ideas into a language that the computer understands, like C++. If you have been doing this long enough, it’s a fairly relaxed and enjoyable process. You don’t have weird design bugs popping up because everything was thought of and conceptualized beforehand.

And that my friends, is what the art of programming is all about!


One Comment on “The Art of Daydreaming”

  1. 1 Alex said at 10:48 am on October 26th, 2010:

    I agree with that. I noticed that I spend only about 10-15% of the overall development time for the coding state. The rest is thinking and documentation reading 🙂
    Good article.


Leave a Reply