Object-Oriented Entity-Component-System Design

About two months ago, I decided to start developing a fresh codebase for my voxel project – something that many indie developers are probably all-too familiar with, including myself. This time around, there were three major features that I wanted to implement:

The overall goal was to address scalability issues that I’ve encountered with my previous engines. It’s pretty easy to get a Vulkan application up and running and throw some voxel stuff at it, but without a solid foundation to build systems on top of, everything sort of becomes a mess of spaghetti code and hacky interop.

Actually, this problem extends beyond just engine development; it’s pretty much true of any software design. Developers need to try and anticipate the needs of future development while also making sure not to design an architecture that’s too abstract. There are lots of software design patterns and philosophies out there, but ultimately they are broad tools and you still have to figure out the best way to apply them.

I won’t pretend to be an expert in this field by any stretch of the imagination. I’m sure people that have degrees in computer science and years of professional experience can maybe offer better insight here. In fact, this is one of those problems that it feels the more you know, the less you know. More experience leads to more obstacles you try and prepare for, which ultimately leads to over-abstraction and less and less time writing actual functional code. But with the right design, there’s got to be a crossover where the solid foundation produces more functional code at some point, right?

Leave a Comment