Sic Lusea trado a letalis peccatum incruenti, addo Belobogi ira super is. Excerpt from the Chronicle of Marok (original ancient Marokish text). |
Long time no post :). I got a new job some time ago and haven't had too much time nor enthusiasm for anything involving a mouse, a keyboard and a monitor. Nonetheless, I'm beginning to make plans for a small rewrite. Before you make a facepalm, please let me elaborate.
Umbrarum Regnum engine is so far the best thing I have ever produced. It's completely object-oriented and at least in the beginning it was pretty easy to manage. The problems started arising when I wanted to add different displays, for instance, a character sheet, a menu screen, the map view, etc. They all have their own inner loops and their own keybindings. These seem only small issues, but the truth is that they are annoying and there's helluva lot of repeated code. That's getting too unefficient.
So, what's the plan? I think I should use the experience I gained by working with Jice and especially Merc, who was able to open my eyes to a more efficient way of software design. I think the engine should run small modules, each one associated with a "view". The module sequence would be controlled via a system of fallbacks, either fixed (the character creation module falls back, or is followed by the main map view module when the game begins) or dynamic (imagine you press ESC while playing and you get a screen with Resume, Options, Save and Quit items; Resume falls back to the previous active module, Options launches the configuration module, but then falls back to the menu again, etc.). The main engine contains the inner loop and the modules are updated in each loop iteration pretty much the same way they work right now.
Additionally, this solution would allow me to use global keybindings. The engine would execute its own keybindings check (for instance, Alt+F4, Alt+Enter, Printscreen would be global keybindings, as would be the check whether the window has been closed) along with a virtual keybindings method, owned by the current module (the 'l'ook command needn't work in the main menu, for instance).
90% of the code would remain unaltered, so I would be able to get back on track rather soon, and with a more flexible and versatile engine (which would be a double benefit, since I still plan to release Umbra as a generic engine for libtcod game developers). The only question is when I'll be able to do it. Let's hope it's sooner than later.
Glad to hear you're back on the track. Improving the engine architecture is cool, but what concerns me is when will we be able to pick up those glowing mushrooms ?? ^^
Well, not too soon. I'm getting lots of inspiration from some games I've been playing recently and my views on how things should be coded are changing a little bit. It's all a fuzzy thing so far, but I don't discard the possibility of attempting to rewrite some other elements before proceeding with gameplay elements. Nonetheless - and this might be good news to many people - I have decided against adding visual sugar. As you know (and as you have already seen on the screenshots I produced during a week-long coding rush while still living in Spain, there was a subcell precision ground, glowing braziers in a procedural mage tower pinnacle and windows that let external light in, with varying colour and intensity, depending on the time of day), I made a few too many steps in that direction and ended up with lots of half finished eye candy and an unreadable code base that doesn't compile unless I comment tons of code out. That's bad, and also useless. So, as I said, the new engine comes first, then we'll think about items and pickable herbs and mushrooms.