Prototype: Single Combat Against AI Foes

Showcase
1

I’m looking for feedback, please!

https://www.dropbox.com/s/buvnz2xl8ztotbz/exchangeOfAttacks_wide.gif?raw=1(image larger than 3072KB)

What Is It?

In short: Single combat, the player against a foe; and a reworking of the combat mechanic for A Door to the Mists.

This mechanic includes no attrition of health between encounters: a given enemy either kills you, or they don’t. But conversely, each encounter is intended to stand by itself: there are no trash-mobs here!

In the full game, these enemies would be encountered while exploring and traversing a level; on entering a certain range of the foe, the game would switch to the “combat world” shown in this prototype. For the sake of the prototype, however, only the “combat world” is present.

Download Links:

Linux 64-Bit Build | Windows 64-Bit Build

Details:

enemies.png?raw=1974×477

This is a major reworking of the combat mechanic for A Door to the Mists, in response to feedback given on that game’s demo. While the fundamental concept remains the same, the control-system and AI have both been significantly overhauled, and the mechanic slightly streamlined overall.

Full instructions on how to play are included in-game, but the basic idea is:

  • Indicate defence/attack direction via WASD or arrow-keys
  • Attack with space or left mouse-button
  • Dodge with control or right mouse-button

While the full game is intended to include controller support, I’m afraid that this prototype only supports keyboard-and/or-mouse.

The prototype provides two enemies: one easy, representing an early-game encounter, and one hard, representing a late-game encounter.

This does admittedly mean that the prototype lacks a build-up of difficulty, somewhat throwing one into the deep-end with the harder foe. Still, this can perhaps be ameliorated somewhat using the accessibility options mentioned below.

And as is intended for the full game, there are a number of accessibility options, available from the “options” menu. These include options for limiting the enemy AI, having enemies give the player more time to react (or less! ;)), disabling certain motion effects, and more. It even includes “Explorer Mode”, which has the computer handle combat in place of the player!

Screenshot%20from%202019-09-25%2018-32-09.png?raw=11280×750

Feedback Requested:

I’m primarily looking for critique on the mechanic itself, the AI, and the controls. However, other thoughts are also welcome!

Do please note, however, that most of the assets are stand-ins; they should not be taken to be indicative of the final quality or style of the full game!

Known Issues:

  • On some systems, walking animations may run too quickly.
  • There is no proper tutorial.
    • This is intended to be present in the full game, but is omitted in the prototype. Instead, the prototype just includes a simple text-based “how to play” screen.

System Requirements:

Uncertain. However, it runs well on the following spec, so it seems likely that it’ll be fine on something better, and perhaps even something a little worse:

  • CPU: Core i5 2.5GHz x 4
  • RAM: 4GB
  • Graphics: GeForce GT 525M

Screenshot%20from%202019-09-25%2018-37-10.png?raw=11280×750

PS: If you’re curious to see some of the AI data in action, press “” while the prototype is running. The game should now display an overlay during combat that presents various pieces of data used by the AI system. Fair warning, however: it’s all unlabelled!

2

I found the controls less intuitive than your earlier swordplay prototype mechanics from an earlier thread:

Single Combat with the Sword: A Prototype

With the new mechanics, it is a bit challenging controlling the sword with the keyboard rather than the mouse. The “bullet time” pauses of the enemy and player characters that happen during striking also throws off the rhythm of the fighting a bit. How to prevent the headbutting attack from the revenant eluded me.

You should probably take my feedback with a grain of salt though, as I have very minimal experience with this genre of fighting game and am likely not the target audience. I am quite a fanboy for your earlier fencing prototype, in fact it is the best swordplay experience I have encountered in a game to date. But that real time, reflex based action that I love may be what most puzzle gamers would despise.

3

Thank you very much for trying the new prototype! :smiley:

Ah, that’s interesting!

I did really really like that old prototype–but I reached a point at which it seemed that a significant investment in the physics of the thing might be called for, and I didn’t want to sink into as much time as I feared it would take, and didn’t feel that I had the resources to be comfortable looking for another programmer to handle it for me.

That said, the new mechanic was also controlled via the mouse up until the demo of A Door to the Mists–I only changed it to rely on the keyboard as seen here due to feedback.

If I may ask, did you ever try the demo of A Door to the Mists? I’d be interested to know how you felt about the mechanic used there.

Hmm… I may give that some thought. I do want there to be pauses in order to provide feedback to the player and openings for attack, but I may give some more thought to the flow of it.

Dodging back is the intended response there. However, without a tutorial, I can very much see that feature going unnoticed.

(The full game has a tutorial point that actually requires the player to dodge in order to continue.)

That’s really heartening to read! Thank you for that! :slight_smile:

Yeah–in addition to the issue mentioned above, I do fear that the mechanic used in that old prototype probably wouldn’t be a great fit for the rest of the game.

Thank you for all of the feedback! It’s very much appreciated. :slight_smile:

4

I remember this conversation in another thread, in fact, I suggested using the mouse vector, rather than scrolling from the center to the cursor stop. As previously suggested, restricting the mouse closer to the center is the best solution. Simply put, you need to consider the direction of the mouse, also with the deduction of errors in hand tremors.

In this case, it is desirable that the mouse does not need to be returned to the center of the screen. Just track movements with the help of math.

There is simply no time to return and follow the cursor position during the battle.

5

I did consider this, but it encounters the problem that there’s no obvious and intuitive way that I see to then “zero” the indicated parry/attack direction.

I don’t want parrying to be about acting at exactly the right moment–that is, if you parry too early, you fail as though you’d parried too late. I’m not a fan of that mechanic, I think. And I don’t want the player to have to press a button to zero the indicated direction, or something like that.

On the other hand, keypresses work well, I feel: zeroing happens naturally as a result of releasing the keys.

(The idea of using the keyboard alone came from another forum, on which at least one respondent felt that it might be preferable.)

As I recall, I did experiment with constraining the mouse to a small part of the screen, and while it worked, somehow I felt like I was getting the mouse into the wrong position to indicate an attack more often, rather than less.

6

I think the implementation is simple, I need to track speed and vector. Speed ​​can be tracked relative to the new position and the old. If the speed is large enough, then this is a sharp movement, which may mean a block. Then calculate the vector and determine how to make the block. Previously, I programmed character movement control, I remember how I used a simple formula to determine speed, I think it can be applied to the mouse.

7

If very simple, then you can use the Delta value :slight_smile:

8

But how would you have the player return to the “zero pose”?

9

Delta Zero = Starting position.
But you need to configure the dead zone. And speed analysis doesn’t hurt.

10

But then you can’t hold a parry–you’d parry for just a moment, and then reset. Unless you keep moving the mouse for the duration of the parry, of course.

11

In particular, the storage of the block may be further determined by the key. You can use the mouse button in a held state, and the block will hold in place until the mouse button is released. This will be faster than moving the mouse to the center of the screen.

12

Hmm… That might slow down blocking a bit, and it adds complexity to the controls, and intuitively it feels a bit clunky, but it might be worth thinking about.

I still think that the key-based controls are likely in general more intuitive and responsive, however.

I’ll think further on it–thank you for the suggestion. :slight_smile:

13

I do not think that it is difficult and will slow down the lock. Note in some shooters, aiming uses the mouse in two versions, pressed - pressed or pressed - released. And the guys play cyber sports with such mechanics. :slight_smile:

14

Yeah, but if they could somehow perform the same actions with just a button-press, and with the same degree of precision, I daresay that they’d be faster still. Pressing a key is faster than moving the mouse, after all.

But first-person shooters require precise aiming, which the mouse provides; this mechanic doesn’t require that precision–just the selection of one of three directions.

[edit]
One thing that I will say is that the gamepad controls are almost a combination of what you’re suggesting and what I already have: there, the sticks replace the keyboard keys, allowing the player to just tilt a stick in the desired direction, much like moving a mouse.

15

I was also struck by the thought that you can use the reverse short movement to return to the starting position. I think this can also be solved mathematically. But you need to think about it.

16

I have given it a fair bit of thought before today. I really wanted to keep mouse-based controls, as I had in the demo, but I’ve yet to find a way that seems to me to work. (Well, aside from the cursor-based controls that I originally had–and that everyone else disliked.)

Reversing the movement works, theoretically. I can see two ways in which it might be done:

  1. By making a sharp movement in the direction opposite to the current parry/attack-direction
  2. By simply moving the mouse the appropriate distance in the direction opposite to the current parry/attack-direction

For (1), it doesn’t make much sense to me to attach “zeroing” to so concerted a movement; “zeroing” is a return to a rest position, rather than something active, I feel. It also means that one has to act twice to parry or attack in that opposite direction, which seems very clunky.

For (2), the system would essentially be a mouse-cursor-based system–but with an invisible mouse-pointer, which sounds rather frustrating.

17

For example, I don’t feel the need for a cursor during a battle, it is completely useless.

18

It’s useful if you’re using the mouse-position to determine the player’s action, I feel.

For example, I have an old game called Die by the Sword that did something very similar to the prototype that was linked to above: the player has direct control over the character’s sword-arm via the mouse.

The problem, I found, was that I all too easily lost track of quite what my character’s arm was going to do, because I couldn’t see where the system thought that the invisible mouse-cursor was.

Hence, introducing a mouse-cursor to a mechanic like that provides the player with a means of keeping track of the cursor’s position, and thus how to move the mouse in order to achieve what they want.

Right now, I’m not convinced that mouse-based control is likely to work with the mechanic that I have here–not without a cursor to provide that reference point. And even that has been reported to be clunky.

The keyboard controls, however, I do think work.

And for that matter, I might point out that the keyboard-only controls don’t have a cursor. :stuck_out_tongue_winking_eye:

19

Huh, I remembered the physics being quite solid and without serious issues, But it was some time ago so perhaps I misremember.

Found some time to try it out just tonight… For me, it feels still quite far from the intuitive, responsive original combat prototype. The dot cursor is a bit distracting since I find myself relying on the sword position to tell where I am blocking/striking.

Partly the issue might be that, indeed, they do look open to attack when winding up, but then a swift attack from the player in another direction does not cancel their slow attack. If the enemy did not pause and leave themselves open but swiftly attacked, the player might be much more inclined to parry first before counter attacking.

Also, does the player’s sword blocking speed become slowed when out of stamina?

In this case especially, I found it odd that a quick swipe from the sword did not disrupt the headbutt attack or do more damage to him than he could to the player character, since he looks so exposed to harm with his axe by his side.

I might have to walk back this statement of mine after having played the wider game demo. I was imagining something like Myst combined with a combat element, but in fact, there is quite challenging reflex oriented platforming game play. So reflex-challenging combat is not at all out of place.

I will try to post feedback about the non-combat elements of the demo to the relevant thread.

20

As I recall, the physics were fairly solid–as far as they went.

The problem was that I had feedback that indicated, I think, that the experience of the character automatically recovering from an attack was at odds with a mechanic which was otherwise very directly controlled by the player.

However, leaving recovery up to the player meant the possibility of the player continuing to press their sword against the enemy’s weapon–a physics state that wasn’t well-handled at the time, I believe.

That’s interesting. (And a slightly different perspective than I’ve heard thus far, I think.) I’ve had quite a bit of feedback against the version in that demo–hence this new prototype. Thank you for your feedback, and for trying the demo for that matter! :slight_smile:

That’s a possibility–but it seems likely that doing so would significantly increase the difficulty of the encounters, and my feedback has thus far indicated that they were already too difficult. :/

If I recall correctly, blocking isn’t slowed–it’s the only thing that isn’t. My intention is that it’s the player’s one recourse when low on stamina, allowing them to turtle and recover. (As long as the enemy doesn’t use unblockable attacks, of course…)

I’ve thought about having successful hits interrupt incoming attacks, as I recall–but the problem there is that, with the player’s attacks being so much faster than the enemies’, a counter attack would almost always stop an incoming attack. Even if the enemy anticipated and parried, their attack would be stopped. As a result, there would be little danger to the player, and little reason for defensive actions.

I could slow the player down–but that sounds to me likely to be frustrating and annoying.

Still, I think that the pace of the main game is a little slower and more thoughtful than a high-pace action game.

(Indeed, I even have a setting available that automates combat, for those who want to explore and puzzle-solve, but not get involved in reflex-heavy combat.)

Did you ever play any of the first three Quest for Glory games? The combat there is pretty close to what I’m aiming for now, if perhaps just a little more action-y, and with (I hope) better controls.

In a sense, what I’m going for here is something like “Thief: The Dark Project” + “Quest for Glory” + extra lore/collectibles. The movement, route-discovery, and exploration of Thief; the combat and inclusion of puzzling from Quest for Glory; and, as mentioned, more collectible things to find.

That old prototype would, I think, have been a better fit for the game that I originally designed it for–a larger, more sprawling thing that I eventually set aside due to its scope.

Thank you for that–it’s appreciated! :slight_smile:

Do note that I want to put out a new version of the demo sometime in the future, one that incorporates a number of changes in response to feedback. Elements of traversal have been changed, the new combat mechanic is there, a few elements of levels have been changed, quite a few bugs have been fixed, and more besides!