Player bot
More AI this week, towards and reaching a workable state of the QA bot! The QA bot uses a basic behaviour system that runs a number of prioritised behaviours, like moving between dungeons, gathering visible loot, exploring the level, delving up and down, and exhibiting other behaviours that regular enemy AI uses, like combat and awareness.
It worked ok, but after a bit of playtime eventually I got oscillating movement. This means that at one turn, based on decisions, we choose e.g. west, and next turn, based on new state, we choose east. Of course the simplest and ultimately pointless way to try to solve it is to say "don't go where you were before", but of course this results in cycles of 3 tiles or above, e.g. A->B->C->A etc. For such a systemic problem a better solution was needed.
A few of the behaviours run Dijkstra based on player position and some goals for that turn (nothing is cached). E.g. "gather loot" runs Dijkstra with loot and chests as goals, and autoexplore runs with unknown tiles as goals. I knew that in the original article that I read about the method, the author suggested using Dijkstra with all goals together, and the only thing that prevented me was frankly the fuss of allowing each goal to lead to a different action and checks if we're e.g. close enough or not. Long story short, I did implement a general "GoalSeeker" behaviour with an arbitrary number of "GoalProviders" where a goal provider can be loot gathering, another can be explore, etc. These are the ones that I use for now, but it's expandable to more behaviours, as at the end of the day, we can either execute an action from where we are, or we need to go to a position to execute that action, and getting to that position means setting it as one of the goals. But rewriting the other behaviours to this single "GoalSeeker" behaviour is not something I'll do now, as so far the bot is stable enough and I got new things to do!
There's a local event next week, mainly for student game developers, but there are some showcases for local developers. And since I'm mesmerised by the bot even at its current infant stage, I thought it might be an interesting opportunity to set up a laptop and show it. And apparently that's going to happen, so of course the next prudent thing to do is to ensure that it actually runs reasonably on my laptop. Lo and behold, all sorts of "fun" stuff occured. Release mode occasionally crashes without any information, so debug mode it will be. Also, there's performance degradation over time, so that was an excuse to fire the profiler and see what to optimise next. And I found a few things: from reflection, to getting mouse position from godot a bit too frequently, and disconnecting/reconnecting signals entirely the wrong way. So, currently fixing these and try to think what to show at the event.