Let's talk about engine architecture

In my last post, I might have said some thing about "getting back to making games". As you can clearly see, I've yet to do anything of the sort. In fact, I've now missed the Global Game Jam for the second year in a row, which was a tad disappointing. In fact, I couldn't blame you if you were to think "What gives, Hugues? What on earth are you doing?"

Now I could just say that I've been swamped with schoolwork, and I wouldn't be wrong, but that's not a very honest answer. In truth I am..... *drum roll* .....rewriting DFEngine. Yes, again.
I know what you're thinking, and I know rewrites aren't usually worth doing and waste lots of time and resources, but I think this one's a bit different from my usual follies. To explain why, though, I'll need to give a bit of background.

On the subject of Software Architecture

When designing software, most devs like to throw around the word architecture around a lot. But what is architecture, in the context of software development? The meaning is much closer to its origins than you might think. To sum it up neatly, software architecture refers to the general layout and structure of the code. This is a higher-level concept, meaning that it deals more with the overarching design rather than the specifics of each implementation. In other words, the architecture is the frame that any given program is built around.

If your architecture is bad, you might not necessarily notice or care at first. Your program will run fine, and it'll do what you want. However, the problems will begin to emerge as you try to expand and maintain your code. It's a little like building a house where the foundation and supports aren't well placed: Just because it doesn't immediately turn into a pile of toothpicks doesn't mean it's safe, as you'll realize when you start building an extension to it. If an application's architecture is well designed from start to finish, then fixing bugs and adding new features is much simpler.

There is a way to fix bad architecture, at least in theory. Through a process called refactoring, you can move around and rewrite smaller sections of code to match a new design without breaking existing features. It's still a difficult and time-consuming process, but it's generally way simpler than a full rewrite. However, refactoring is only at its most effective as a preventative measure, where you fix the problems before they become serious. The goal is to gradually make things run smoother, not turn the entire structure upside-down.

Back to DFEngine

As you might have already guessed, the current design of DFEngine was not well put together. It has some kind of structure, unlike the abomination that was AMAZE's original engine, but it's inherently flawed in several ways. To return to the house-building metaphor, AMAZE's engine is a pile of rotten planks and rusty nails that someone has arranged in a vaguely shelter-like fashion, and current DFEngine is a house that looks okay on the outside but secretly violates about 13 different safety regulations. You could go in and try to sort things out, but the problems are so deep-rooted that it may be cheaper just to demolish it and make a new one. I'm still at a point in DFEngine's development where I can afford to do that, so I think it's the wisest decision. After all, if the engine already has issues and it's not even finished yet, things will no doubt only get worse from here. On top of that, I had several game ideas floating around that required certain features that simply didn't exist in DFEngine, and wouldn't have fit with the existing structure of the code.

So far, things have been going fairly well. It's been a slow process, because I am loathe to make the same mistake twice in a row, but things are pretty solid so far. I would post some screenshots, but I haven't finished the rendering code yet so there won't be much to show for a few weeks.

Next time, I'll talk about the new engine and how it works.