Something very hard about giving the player perfect information about how a turn will play out is that enemies can go before you in their turn order. This has caused a lot of confusion for testers because you might need to target an ability where an enemy is going to be rather than where they are.
My new idea for communicating this is that if your ability is going to affect an enemy at a position other than where they begin the turn, it shows a ghost sliding into where your ability will affect them.
Edit: The Combat Mechanics Milestone Demo is over, if you'd like to be considered for future playtests, you can email me at britown.cohost@gmail.com
If you'd like to try out the Chronicles IV Combat Demo currently brewing, I made a little form where you can submit your info and receive a copy.
This demo is designed as a smaller game than the full vision. It exists to narrow my scope and also start iterating on feedback from the Big Complicated Combat System.
Still not 100% sure when these will go out (very soon!) but I promised it would be this year and so it shall be!
I wrote 3 months ago about how this is a particularly hard problem to solve.
For whatever reason I've been possessed to actually try implementing this over the last few days and I finally have something to show for it.
Here, the enemy has a teleport that has just enough range to cross the water and it has a long cooldown. Therefore the highest value path is to walk to the edge first, then teleport across to attack.
This is a dynamic use of the actor's abilities with no scripting!
Sat down tonight to actually try and write a more complete song instead of little test loops using the Chronicles Audio Engine (tldr: 3 square wave channels and a noise generator)
I feel like it went very well! But I'm also completely new to this so any constructive feedback is welcome!!!
Just completed the second major refactor of the actions system[1]. This time the end goal is being able to query the final game state for a lot of complex result data that I've been needing to display in previews but it's been too much of a pain to aggregate.
Because action lists are arbitrarily complex it's actually very hard to answer some specific questions like βwhat actors did I damage?β Or βwho pushed me?β You want to record some events as you iterate but you don't want to write special event code for every action type which is what I was doing and it scaled horribly.
Anyway the new system feels elegant and just works for all cases including future complex cases in my imagination.
This is the endgame I think of this system, it feels really complete now which is good because it's the primary focus of my demo and I'm tired of hacking at it. I'm honestly really proud of myself for making something that is extremely complex and also straightforward to maintain and upgrade. My code tidiness has really saved me from a lot of headaches.
The main result of this is that turn highlighting telling you what your choices are going to do is finally comprehensive and complete.
The exciting future that this enables, however, is that enemy AI behavior can now know things like βWill using this ability here damage my targetβ so I can build a system where enemies have behavior goals and can use their abilities and check the results against their goals. If you want to read me ranting about enemy behavior in the complex actions system, you can do so here.
I now have the popup system working! Simple popups like context menus or dropdowns will dismiss if you click away from them, and then modal popups will disable everything under them until they are dismissed.
βWhat parts of EGA are you emulating? Only the color space and (more or less) resolution, or do you do something deeper?β
Great question! It's actually been long enough that I had forgotten a lot of the work I did on EGA emulation. The original project stored the frame buffer data in bit-planes the way it was done on the hardware. The code for this is on a public github repo:
I cringe a little looking back at some of this because I didn't know what I was doing and definitely wasn't doing a lot of hardware-specific memory layout work which is what I would do on an emulation project now. I didn't know about ImGui back then and still wanted my dream of in-engine dev tools so I actually made EGA-compliant developer tools you could switch into for editing the map and writing lua, it was a little wild!
Drawing a bitplaned asset onto an existing framebuffer was a giant pain because you had to shift the asset to align to the correct place. It was actually a performance problem on modern hardware and I ended up needing to do it much smarter than I originally thought. I remember digging up a lot of old posts and articles about techniques people used like this for storing animations inside the bitplanes.
I can't find it now but I remember an article from a developer talking about storing 8 copies of their assets each one shifted by one so you could always just render the aligned asset and never have to do the shifting logic!
When I resurrected the old EGA project into the new engine now powering Chronicles, I vastly simplified the back-end for convenience. Now the frame buffer is just 1 byte per pixel which only stores the palette index. In the end the only restrictions on the current generation of the game is the palette and color logic because even the resolution is apocryphal and text rendering is now completely arbitrary :host-joy:
In the end it's purely an aesthetic restriction now but I did once upon a time aim to have a pure backend implementation!