Last week I set myself the goal of trying to make a terrain test by today. Once I figured out what I need to do in order to get that far though, I realised it would be an unlikely target to meet. While theoretically I think I could have thrown something together by today, it would have been such a hack it would be a burned in a couple of months time.
Instead I have decided to a proper architecture plan before I start coding. Admittedly this goes against my original strategy of just throwing things together to see if they work, but there are at least four good reasons for planning:
Reason 1: I don't like coding
Yup, I finally realised this week that deep down I no longer like writing code. I like the other aspects of programming enough to make up for it; designing algorithms, solving problems and the like, but the actually tedious writing and debugging the code is more of a chore.
So designing the architecture on paper is actually more fun. It also means less time coding, because:
Reason 2: It saves time in the long run
Basic engineering rule says that problems become more expensive to fix the later in a project they are found. If I rush into the code now, I am almost guaranteed to have some annoying basic flaws in the architecture that will bog down development a month or two down the track. By running through an architecture design now, I can (hopefully) limit those by having a half-decent design from the beginning. This is becoming more of an issue now I'm entertaining making this a game for 4E5.
It also gets the tricky part of the coding down to begin with, so I just have to code up the design, which should be a breeze. This is important because:
Reason 3: I am so damned rusty at this!
Looking through my code, I realise that I'm pretty well stuck in a default mode of writing hacked together C. My code lately has been terrible. So I need a bit of time to hit the books, learn some good new programming techniques, and figure out how to put them into an architecture. Otherwise I'll stagnate as a programmer.
The final and most important reason stems a bit on from this:
Reason 4: I want to use message passing as a central part of the design
I had planned on using message passing in this game as a learning exercise, but after thinking this through I feel the best thing to do is to fully integrate message passing as the central core of the whole engine. I admit that this is probably overkill, but the best way for me to learn this is to fully embrace it as an architecture choice, rather than tacking it on as an afterthought.
However for this to work I need to be very careful as to how the whole thing is designed. This is especially true because I am unfamiliar with message passing. There are a whole bunch of easy pitfalls that I need to avoid (as OrangyTang mentioned in his reply to my last journal entry).
So for this week, I am going to continue with my architecture plan. I don't think this will take too long: given the message passing architecture I am planning will be designed to be good for prototyping I only need to fully plan out the core of the engine. However I'll also trace through a few messages from sample modules to see if the system works in my mind before implementing it, and also sketch out the design of the modules needed for the terrain test as a sample case.
I know there's a fair chance the whole thing will end up in a soggy heap of bad code in the end, but since I'm doing this as a learning exercise that isn't necessarily a bad thing. My gut instinct tells me there's a good chance that this engine design will be immensely useful for some of the weird things I want to try out later, so I might as well try to do this right.
