I'm still plugging away at the architecture for my revamp of the engine. Above is a hacked together diagram in Inkscape showing where I presently am; click the image for the larger version. Most of those modules are unchanged from what I current have in Ice Slider, however I've added in a few new things into the graphics section based on some ideas spawned from the forums.

Important points to note:

Everything is weirdly spaced for a reason; I'm still thinking through the whole plan. I mainly built the diagram so I can easily shift things around and create new boxes. That's why there's so much empty space.

None of the names are final and the descriptions are very brief.

Audio is currently completely blank; I never got around to making any of the audio code for Ice Slider, and I haven't yet decided what to put here. I'm fairly sure whatever I do will communicate with messages or events, so it should be completely decoupled from the game code.

I'm still in two minds about the relationship between the kernel and the message passing system. In essence the kernel is a specific message passer, sending update signals to tasks. I could therefore wrap the two things together into a single class. However I'm also not too sure about having all messages passed in a single monster controller. It might be nice from a logging perspective (I can just plug in some debug code to see all the messages in the system), but it might be better to make a specific message passer for each type of message. I'm also not sure whether I should be calling them "messages", "events" or something else entirely.

Utility classes haven't been finalised yet. I'll probably add a whole heap more once I realise what I need.

"World" is just my name for the collection of data that describes the state of the game; not the graphics, sound or controls but the positions and internal state of the game actors. Most of this would be game specific but there's a few classes that are universal.


I'm going to try and step through a few procedures on paper to see if I have everything I need for the basics and then start making links. Once I have the basic arcitecture planned I'll flesh out the class interfaces. I don't see any reason to do this in UML form; I'll just write out the C++ headers and create doxygen docs.