A Door to the Mists Windows, Linux game

Greetings and salutations!

This week's screenshot shows a glimpse of some changes being made to the combat mechanic, via related changes in the options menu:

As I believe that I mentioned last week, the period up until Thursday of the week just past was a partial rest-week for me; I only returned to focussing primarily on A Door to the Mists on Thursday. As a result, it wasn't a very busy week--but it did make for a nice change of pace for a while!

Still, some things did get done:

Something that seems to have been causing some trouble in the demo has been the rope-climbing found in the prologue level.

Those ropes are a little inexplicable: they're unmentioned before they suddenly appear out of nowhere, and are never mentioned or used again thereafter. Worse, I've had a report of a difficult-to-reproduce crash that occurred when using one of them, and possibly a case of a player ending up in a wall, as I recall.

So, I've decided to remove them. In their place, I intend to have the lift within the pyramid convey the player back up to the top.

I've begun implementing this: the ropes are gone, and the lift is partially functional in its new behaviour, I believe. It's a little awkward, as the lift's object-type wasn't designed with multiple destinations in mind. Still, I think that it's coming along.

But perhaps the biggest news this week is that I'm reworking the combat mechanic.

This, again, is something that demo-players have reported having trouble with. For one, respondents seem to have had trouble with the controls, finding the use of the mouse unintuitive. And in general, I have the impression that some have been finding the mechanic over-difficult, in a few ways.

So, I've set about reworking it.

To start with, I've removed the left- and right- dodge actions, leaving only a backwards dodge. Aside from reducing the number of actions involved, this removes the element of relative orientation from combat, leaving all motion to occur on a single line. Overall, this should hopefully simplify things somewhat.

Furthermore, with only one dodge-action, only one button-input is required for dodging, and it needn't be a directional one. (Specifically, it's now the "crouch" button.)

This frees up the directional movement-buttons for use in specifying a defence/attack direction, as at least one demo-player suggested, I believe. (The "looking" buttons (which are now defined even in the default keyboard-and-mouse button-bindings) can also be used for the same purpose, providing players a choice of whichever they find more comfortable.)

And with so much input done on the keyboard, I've implemented the use of the "jump" button as an alternative input for attacking, alongside the previously-extant use of the "action" button.

(I would like to keep the mouse as an option for inputting defence/attack directions, but with players disliking the cursor-based approach to that, I don't see a good way of doing so right now.)

I think that this new control scheme works. Is it better than the old? I don't know--I quite liked the old scheme. But it is simpler and quite intuitive, I think. We'll hopefully see what players say!

And I've taken a step further: For a while now, I've been a little dissatisfied with the combat AI. It was fine, I think--but it wasn't as good as I might have liked, and the code was a byzantine mess of arcane variables and equations.

So, with some trepidation, I've ripped out a good chunk of it, and built a new version.

This system essentially works by counting how often the AI's opponent performs a given action, and then treating that count as an "expectation". The more often the opponent does something, the more it's expected that they'll do it again--and the less it's expected that they'll do something else.

What's more, it keeps track of the opponent's previous action, too. This allows it to somewhat associate actions: if the opponent always follows a left-attack with a right, then the AI's expectation of a right-attack is higher after a left-attack.

Actions that are expected are then more-easily defended, while unexpected ones are less well-handled.

I've also brought to greater prominence the AI's ability to "make mistakes"--that is, to occasionally recover slowly from an action, giving the player an opening in which to attack.

(This system takes inspiration from both the old Quest for Glory games, and from sport-fencing, as I recall.)

I'll confess that I am a little sad about so reducing the mechanic--I quite liked the previous version. But, as they say, sometimes it's called for to "kill your darlings".

All that said, this new system is as-yet untested.

To that end, I've begun work on a new combat prototype, which I hope will both allow me to test the AI and, once ready, get some feedback on the new systems.

This prototype is very much a work-in-progress, but I hope to have it ready soon!

In the meanwhile, here's a screenshot of the prototype's player-model (seen from behind), and one enemy-model (possibly work-in-progress). I'm keeping the art-style very simple and slap-dash: it is, after all, just a prototype. (I haven't yet decided whether I'll light the models, or leave them flat.)

And finally, along with the changes to the AI, I've made some changes to the accessibility options available for combat. Instead of a single "difficulty level", there are now several separate changes that can be made. (And of course, "explorer mode" remains available.)

That then is all for this week--stay well, and thank you for reading! ^_^