No build posted today. Been spending some time getting the task list for Daleth in order, and thinking about how to tackle the framework for combat encounters (henceforth likely referred to as simply “Battles”).
The Way Things Are
A bit of background on roughly how things are implemented at the moment. Aui is the custom UI system that all the screens and other interactive bits are built using. This has a bunch of generic widgets, like buttons, labels, scroll bars, etc. Within the Tako package, I have all the Tako custom widgets (for things like the agent icon buttons and the codex mantle list), as well as all the screens and popups, which themselves are just widgets.
The component which glues all of this together is the ScreenController. ScreenController does a bunch of unique stuff. It is the root widget in the widget family tree. The Tako game class (Slick-derived) calls ScreenController’s update(), render() and resize() methods directly. ScreenController also does a bunch of currently-pretty-nasty event handling such that any screen call do something like triggerEvent(widget, “screen MainMenu”) to open the main menu, or triggerEvent(widget, “popup mantleInfo <mantle Id>”). It’s a little bit gross, but it’s functional.
ScreenController allows a single screen to be visible, but maintains a popup stack. This means that while you’re in the Codex, for example, you can keep clicking on links that pop up more mantle info popups and it keeps something of a history as you keep hitting back. This will require a bit of reworking in the long run, because you can theoretically get into a situation where you’re running out of memory due to so many popups being in the stack.
The actual game logic is contained in a separate widget-derived component that exists outside of this system, Campaign. This Campaign widget is always rendered underneath the currently active screen and popup, and drives the game logic for things like the avatar traveling and triggering encounters, and also responds to events requesting mantle/party changes.
The Conundrum
This is all well and good, and everything is working quite well at the moment. However, it does pose a bit of a strange issue now that I’m starting to look at battles. See, the Campaign widget functions like the back-end for gameplay, and there’s another widget that functions as the front-end: the CampaignScreen widget. All of the user interaction happens within CampaignScreen. There are widgets in Campaign that are used for rendering encounters and parties and stuff, and their tooltip displaying is actually handled by CampaignScreen, but nothing on the world map is actually interactive.
So I’m stuck in a position where I still want to continue keeping the front-end/back-end separation in place — it actually looks great having the game render in behind the menus without the clutter of the game UI after all — but if the Battle component is going to be maintaining the queue of agent events, and BattleScreen is maintaining the graphical/interactive representation of that… Well, it just gets even uglier, I find. I have to end up doing a bunch of agent lookups to ensure that the visual timeline aligns with the actual timeline. Especially when you consider that some agents may from time-to-time disappear altogether from the timeline, it’s just especially ugly. Gross!
The Solution
Okay, so it’s really not that big of a deal. I’ll keep a queue of battle events in Battle, which will be a bunch of elements containing agent + event (command or action) + optional ability (for active wait or normal action). Since this queue only updates infrequently, I can make use of the “refresh” functionality I have in place with Aui — essentially I can allow Battle to trigger a ‘refresh’ event which will ultimately cause the visual timeline to repopulate. This will also allow the BattleScreen (which will be responsible for things like selecting abilities and targeting) to update based on whose action is available.
I’m not entirely sure why this was making my head spin so much, but it doesn’t matter! I have a plan of attack, and hopefully Tako will have some playable battles before too long. 🙂