Combat Feedback Update: Readability, Controls & Target Lock

Combat Feedback Update: Readability, Controls & Target Lock

If you have been struggling to read enemy attacks, fighting the default keyboard layout, or losing your target mid-fight, you are not alone. One More Level’s official Steam post, “3 things we are working on to improve combat in Valor Mortis,” groups the three most common playtest complaints under exactly those headings: combat readability, controls, and target lock/camera behavior.

Important context before you read on: this is a developer update about planned improvements, not a confirmation that every change is already live in the demo you are playing. Nothing below should be treated as a finished patch note. Treat it as a roadmap of what to look for — and, where the wording is forward-looking, as unconfirmed until you can check the build directly.

1. Read the current build before judging the change

The first thing to do is establish what your build actually does right now, because the announcement describes intentions rather than shipped values. The post states that playtesters found combat — especially defensive actions and their cues — hard to read. The developer’s stated response is to:

• improve attack windups;
• add stronger pre-attack audio cues;
• improve the visual and audio distinction between blocks and parries.

Two things are deliberately absent from the post: parry-frame values, enemy-by-enemy timings, and any date for a specific demo build. So do not build a timing chart from this announcement. Watch for clearer windups, punchier pre-attack audio, and a stronger block-versus-parry signal once the changed build is available — and verify each one in-game rather than assuming it has landed.

2. Make the block-versus-parry distinction work for you

The most actionable takeaway is defensive: the update is explicitly aimed at making blocks and parries feel visually and audibly different. In practice, that means you should lean on two senses rather than one. Listen for the pre-attack audio cue as your early warning; human windups and animations can be masked in busy fights, while audio often cuts through. When you review a fight afterward, ask whether a failed defensive action was a timing error or a readability error — the developer’s planned changes only fix the second category.

3. Rework your control layout

Keyboard players told the team that blocking with Ctrl and using Alt felt uncomfortable, and the developer says it will revisit the default layout, highlight control rebinding, and ensure custom bindings save between sessions. It also floats side mouse buttons as a possible ergonomic option for blocking or dodging.

Two cautions here:

• The side-button tip is developer advice, not a universal best bind — what is ergonomic depends on your hand and mouse.
• The confirmed point is that the studio has named rebinding persistence as a target. Persistence saving between sessions is the thing to verify once a build lands.

Before assuming a specific key can be reassigned, open the in-game menu in the build you are playing and check what is actually remappable. If you cannot rebind something you rely on, that is a legitimately useful report.

4. Adapt your target-lock and camera habits

The third recurring concern was target lock during multi-enemy encounters and the boss fight. The developer’s announced work includes smoother camera tracking, smarter target prioritisation, and an extended target-lock range for melee and ranged combat.

Again, this is forward-looking language. It does not confirm that target choices, range values, or camera behavior are final in the demo or at launch. Until you can test the changed behavior, the practical move is to note when the lock fails you: is it during a crowd, during a boss transition, or when swapping between melee and ranged? Specifics are what turn a complaint into actionable feedback.

5. How to give a useful report

The free demo is the correct place to check current behavior. When a control, target-lock, or defensive-cue issue occurs, the guide recommends recording:

1. the demo build and platform;
2. keyboard/controller and the relevant binding;
3. the enemy or encounter type;
4. whether the issue involved a block, parry, target switch, or camera movement;
5. a short capture, if the official feedback channel accepts one.

Note that this is a reporting checklist from this guide, not an official support form. For confirmed current PC support, use the demo settings and known-issues page; for patch-specific performance work, use the demo performance and upscaling page.

Quick tips

• Distinguish announced from shipped: the Steam post is a statement of work, not a changelog. Re-test after each build.
• Fix readability errors and timing errors separately — they need different training.
• Check rebinding persistence by setting a custom bind, restarting, and confirming it survived.
• Enrich every report with build, platform, input device, and encounter type.