Quartz
Day 3: Events
Panic?
I'd hoped to have finished enemy types and AI by the end of day three, but while adding the second enemy type I ran into a small bug in the drawing system that led me to a big bug in the AI system that took me most of the evening to find and solve. And I had to redo the entire movement system to allow the player to attack. This led to not much actual progress being made, but the systems are a lot more solid and flexible right now. Hopefully, this will allow me to catch up on day 4.
And while it initially caused some headaches to implement, I'm really starting to see the benefits of using the event-driven approach. Having a clear overview of events turned out to be amazing for debugging the AI.
Comments
Log in with itch.io to leave a comment.
Heh. The mid-7DRL slump! I've hit that in just about every 7DRL I've participated in, where you initially start out making a lot of progress and then you realize you've painted yourself into a corner somewhere and have to step back and refactor a few things. Luckily, you do usually make up the time, but it can be concerning for sure!
That action system you're talking about sounds interesting. Is that based on something you read about somewhere, or is it something of your own design?
In my everyday life I'm working at a company that enables event-driven software. The basic idea is that you don't save the state of an object, but all the events that led up to that point. This way you can easily rewind and check things. The obvious use case is finance where you have to audit everything, but there's a lot of other applications as well.
I'm not actually a developer, so I only caught some of the theory and I'm trying to figure out how to implement it by myself. Instead of the high-level magic my colleagues use to store the events, I just put them all in a JavaScript array. Which is not the right approach for a big project, but a small-scale thing like this will probably manage just fine.
Hm. Sounds like it would get kinda inefficient to understand the current state of an element that's undergone a lot of changes, but I imagine that could be easily solved by caching the current state and only referring to the history when you really need to.
I can definitely see its utility for making a time-travel roguelike like you're making, since it means you can unroll the activity back in time. I had an idea for a heist-planning roguelike a while back that would let you "scrub" forward and backward in time to let you let one character do their thing, then go back and define what another character does simultaneously, but what I ran up against was how to handle things when those two characters would interact; it would "void" things after. But if you just have a list of "things they're going to try to do" instead of trying to save the state at each time point, the characters could adjust, I think. This sort of idea would really assist with that!
Cool, looking forward to checking out your game.
It's also supposed to be used with a specialised event store, which is very efficient in getting the current state of an object. I don't know the exact black magic behind it, but it seems to work.
Also: your heist roguelike idea sounds really cool, I hope you'll pick it up again later.
If you're interested in deeper reading about it (which I maybe should've done before embarking on this project), my colleagues recommend martinfowler.com
Cool thanks