Been reading about component-based design and thinking about playing around with it in a project of my own. My idea is to rewrite Magnetica to (a)use a component-based model, (b)have a cleaner design overall, (c)use some more advanced graphics effects, (d)allow for easier modification, and (e)allow for more variety in the levels. I say rewrite as opposed to modify because the current codebase is criminal; I tried previously to create a Magnetica 2.0 which would incorporate better graphics and cleaner enemy movement and quickly found that it was impossible to pinpoint where certain things were happening. This was immediately traceable to the inheritance tree - things had hardened to the point where modifying a single enemy was a not insignificant task. Given the size/scope of the game, this is inexcusable.

Interestingly, the component-based scheme seems similar to my process management scheme, but a little more controllable. Something I definitely have to look into is a signal-slot approach to event handling (as opposed to my monolithic event manager). I’m starting to think that my approach of “everything is an event” leaves something to be desired in terms of event ordering/determinism, and although this could be helped with a process priority scheme, it might be preferable to simply explicitly call things when they need to be called. I’m not entirely sold on this; I think I have some prototyping to do before I settle.

Component-based models seem to have a skew toward entirely scripted systems, which I’m not prepared to incorporate quite yet. It’s an area for future work. I still want to create a flexible 2D RPG system with a swappable battle system that could facilitate Parodica or the Guardian Sagas series.

On a related note, I think some more research into procedural content generation is in order. Here’s what I know how to generate: dungeons, terrain, simple textures, buildings, and trees. That’s close to enough to procedurally generate a large portion of a bad looking game.

Break the Chain.