Single Combat with the Sword: A Prototype

I’ve been working on a video game mechanic that revolves around sword-fighting, and have reached a point in that project at which I could use an external perspective on it, and would like to ask for feedback on the small prototype that I’ve put together.

Bear in mind that it is a very basic prototype at the moment: the graphics are terrible, there are bugs, the win/loss conditions are bare-bones, etc.

Speaking of bugs and the like:

• There’s a minor feature that isn’t mentioned in the on-screen instructions: press “=” and “-” on your keyboard to increase and decrease the resolution, respectively.
• If the game doesn’t start in full-screen, try one of the above to change the resolution and hopefully force full-screen.

(It’s a good idea to play the game in full-screen, as the mechanics involve swiping the mouse around a fair bit, and having the mouse escape the window can be problematic, I find.)

Regarding feedback, I’m interested in any impressions, but I have a few specific questions listed below. However, I’d appreciate it if anyone inclined to try the prototype read them ‘‘after’’ playing, simply to reduce any bias that they might introduce if they’re in mind during play; to that end I’m hiding them somewhat via blue text; highlight the text to show it clearly.

Feedback questions:
How intuitive did you find the control method?
Was the combat fun?
How challenging was it to beat the enemy character?

The download is a Windows installer about 22MB in size. (It should work on both 7 and XP; I don’t know about 8, I’m afraid.)

You should be able to download the prototype via this link.

I’m not sure how to control attacks, for me it’s not intuitive at all.
I would expect that if I move the mouse to the left side and then holding down the attack button move it to the right, the character should perform a horizontal slash.
Moving the mouse to the upper edge, then moving it down (while holding the attack button) should result in an overhead attack.
Moving it from the center up should make the character perform a thrust .

The more advanced option could be:
-moving from center down - lowering the weapon to ‘taunt’ an opponent to force him to make an attack
-using the attack button when parring could allow to push the enemies weapon aside and make a counter strike

Parring works most of the time, but some of the attacks connects when I think they shouldn’t. Sometimes the arm of my fighter gets locked - I move the mouse as if to block, but the character never makes a move and gets hit, but I’m not 100% sure, maybe I get hit before I make the move. It’s hard to tell.

Sound are a must-have, it’s hard to tell if a attack hit, missed or got parried.

Still better then combat in Skyrim, even at this stage.

I only managed to beat the opponent once, using the ancient Chinese fencing technique called BuTon Ma Shing

First of all, thank you for trying it!

Hmm, that’s curious, because that should be exactly how it does work. How quickly were you moving the mouse? Were you using quick motions or slow?

For the moment thrusting attacks have been intentionally excluded–only cuts are available.

(I do have some thoughts on how to implement thrusts, should I decide to include them. Your idea should work, but what I have in mind would allow the player to aim the thrust a little more precisely, which might open up some gameplay opportunities.)

Hmm… Interesting. Both of those are less… direct, I suppose, in terms of input mechanism, than I’m aiming for at the moment. I’m not sure that taunts would fit tonally, but a beat–what you’re more or less describing in your second suggestion, I believe–could be useful.

All problems indeed, I feel, and thank you for reporting them. In the last case–the possibility of being hit before your parry gets into place–the fact that you’re not managing to read whether that’s the case or not is itself an issue with the current design, I feel.

Heh, a good point; I tried to use some very basic particles to do that job, but sound might well do a rather better job. ^^;

Hah, thank you!

Oh dear–and here I was worrying that it was too easy! XD;

Well, that does nicely illustrate one of the reasons for getting new eyes on a project: the person who created it likely knows it–including its weak points–rather better than a newcomer.

You… you know the ancient art?! If I had known- My paltry game was never meant for such masters!

Same - I felt like my character was lunging before I even swiped.

My expectations were:
mouse-down > swipe from left to right > mouse-up (Then attacks)

But maybe that was wrong. (I might be used to the sword play in Mount & Blade, which does it quite well, although ends up turning into a strafing battle)

Defensively, I thought it worked pretty well. There were a few cases that it seemed a bit clunky, eg, was able to block a vertical swing when my sword was vertical.

For some reason these sorts of mechanics remind me of Die by the sword
youtube.com/watch?v=0z1HWiTv5Yk

Which tended it dissolve into flailing your sword around until you connect

Sort of intuitive. Using the mouse I could see my arm moving, so could guess what was going on. The attacking left me confused. Was I doing it correctly? I just seem to be stepping forwards?

Hmm, I can definitely see it becoming fun. But at this point I can’t really plan my attack. Usually I love seeing an opponent start a move and then quickly dash in with an attack of my own.

First two battles I lost, but third was able to beat the enemy fairly convincingly. Tried a forth time and got slaughtered. Seems a bit random - so not sure what I’m doing right or wrong.

Windows 8.1 user here - works a treat.

Thank you for the feedback, Maikeru!

nods That does seem to be misleading players–I’ve changed the mechanic such that the character only lunges foward when an actual attack has begun.

Interesting–I think that I may have miscommunicated the controls (again, I’ve had other feedback that supports this idea). From your description it doesn’t seem as though you were controlling the attacks correctly, no.

Heh, yes, that’s something that I’m trying to fix! ^^;

(I’m struggling a little with coming up with good normals for my collisions.)

laughs That’s very appropriate: Die by the Sword was in fact one of the inspirations for this! (Others were the old Quest for Glory games–particularly 1 through 3–and Infinity Blade.)

I think that one of the big problems that Die by the Sword had was that the player was asked to not only control their sword-arm, but also move around as normal at the same time, which I recall being somewhat overwhelming, and which is something that I’ve tried to avoid.

Ah, that’s good to read, and thank you!

I’ll hopefully have a new version ready soon, depending on how my battles with the physics system fare.

It took me a number of tries to figure out how to slash while side stepping. I needed to input slashes relative to the white dot in the center of the screen, but I ‘instinctively’ tried to slash directly at the opponent who ends up off to the side of the screen when you are moving.

I also had some difficulty with with a left click only being good for one slash. I found myself trying to hold down the LMB and make several of the slash gestures in quick succession.

It is, once you get down how to combine slashing and stepping.

It feels like it would be quite a lot more fun though if you had direct control over your sword while slashing, much like the control scheme you already have for parries.

Not hard at all with liberal use of side stepping but quite difficult when standing still.

Thank you, Deus!

One thing that I’m noting with interest is the variation in which elements people find easy or difficult: for example, you mention having a lot of success delivering attacks while side-stepping, while someone on another forum had trouble doing so and gave up on side-steps.

(Honestly, side-stepping might be a little overpowered at the moment–as you seem to have found, the AI doesn’t really have much defence against attacks made while side-stepping. That’s something that might call for fixing–perhaps prompting the AI to side-step as well if it detects the player attempting to flank that way…)

Hmm… I’m not sure of what to do about that at the moment, but I’ve made a note of it for further thought.

nods Indeed, I think that the “cursor dot” misleads players a bit; I’ll hopefully post a new version soon, which should lack that cursor dot and thus, effectively, produce that direct control. I’ve already had positive results from a version that lacked the cursor (posted on another forum), if I recall correctly.

New version!

Again, feedback would be appreciated.

Changes:

[]Various alterations to the AI; it should hopefully provide a greater challenge now.[/]
[]Improvements to the physics system; while still not perfect, it should be rather better than it was.[/]
[]Increased the damage done by hits to the head or body.
[list]
[]It was suggested that I reduce the health of the characters. I chose instead to increase damage done in order that damage done to the head or torso be significantly more dangerous than to the arm: as it now stands (and if one were attacking just one type of body part), winning takes just three blows to the head, five to the torso and a full fifteen to the arm.[/*]

[/]
[]The mechanism that recognises slashes for attacks should be improved.[/]
[]Miscellaneous other changes.[/*]
[/list:u]

Between various of the above changes:

[]Turtling should no longer be as easy as it was.[/]
[]Spamming attacks should no longer be as useful as it was.[/]
[]A somewhat overpowered side-step-and-attack manoeuvre should no longer work.[/]

Known issues:

[]The graphics and sounds remain horrible! [/]
[]The full-screen bug remains. Again, use the in-game resolution-change controls to force fullscreen. (And again, I do strongly recommend playing in full-screen.)[/]
[]There are still a few “cheap” ways to win, I think.[/]
[]The mouse is still not constrained to the window.[/]
[]It’s till possible to manoeuvre out of the circle of visible floor.[/]

It would be hard to say what exactly changed if you didn’t say, but somehow it feels more responsive. That’s good.

For me the movement of the sword when you attack is kind of slow (or I’m not moving my mouse fast enough or too fast- I’m using a trackball).

I’ve managed to win a few fights by making a thrust to the upper right corner and then moving the saber sideways to hit the opponent on the head.

For learning or debugging leaving the cursor visible wouldn’t be that bad.

Ah, I’m glad to read it–thank you.

Oh wow, I’ll confess that I don’t think that the possibility of someone using a trackball occurred to me at all! I’m not at all sure of how this would work with a trackball… ^^;

(I think that I’ve barely ever used a trackball; I really don’t have much experience of them, I fear. ^^; )

Hmm…

Oddly, I actually contemplated making the sword-arm slower, since I find it rather quick most of the time. I think that I should strike off that idea for now. ^^;

Perhaps it’s a matter of controller sensitivity? That would make a lot of sense, actually: if your trackball is set to a higher sensitivity than my mouse, and thus produces smaller motions for (more or less) the same movement, the in game cursor might be moving much more slowly than I expected.

(It could also be a matter of personal perception, of course: what is fast for one person might be slow for another. However, since you don’t indicate that the enemy is similarly slow, it seems more likely to me to be an issue in my implementation.)

A version with a “mouse sensitivity” feature might be in order…

(Come to that, I feel a little silly for not having included such a thing previously, especially since another prototype of mine–not posted here, as far as I recall–did have a “mouse sensitivity” slider, I believe. :/)

Hmm… The problem is that when I did have a cursor, it seemed to mislead people; in particular, I got the impression that people tended to expect attacks to move at the speed of the mouse, unlike the parries, the “direct” control of which seems to be better intuited.

However, you do say that the sword-arm still feels a bit slow for you, so it may be that it is still a little laggy. I’m not sure at the moment…

AARGH! I do apologise: it would seem that I’ve made a very silly mistake: the version posted above isn’t the new version, but an older version (albeit one more recent than the previous version posted here). >_<;;;

In short, what seems to have happened was this: I use a separate directory for building the version that I’m going to post, allowing me to leave out files not relevant to the prototype, but which are in the main directory for other purposes (such as prototypes of other gameplay elements). When I went to build the new version, I simply forgot to copy over the new files, and so simply rebuilt the last version.

I’ll hopefully post the actual new version a little later on…

On the plus side, the version that I intend to post tonight should have an options menu that allows one to set the mouse sensitivity…

I very much apologise. ^^;

The real new version!

The list of changes given above should still stand, with the addition that there is now a simple options screen on which you should be able to adjust the mouse sensitivity.

I think the sensitivity slider did it. I feel I’m in control (90% of the time) but now it’s a bit too easy

…and I can play in window mode, the mouse is glued to the window well.

Ah, I’m glad that the sensitivity slider did help.

As to the controls now working in windowed mode, I actually hadn’t thought of it but that’s likely a pleasant side-effect of the change that allowed for alterable mouse sensitivity: where before I was using the MouseWatcher-reported mouse position, I’m now using relative mouse movements to control a “virtual mouse position”. Since this involves resetting the mouse position each input update, the mouse has less opportunity to escape the window. Unexpected, but far from unwelcome.

As to it being too easy… I’m a little worried that there may be a conflict there: I found a similar result myself when I turned the sensitivity up to its maximum–likely simply a result of the AI having less time in which to respond–and so have installed a maximum speed for the movement of the “virtual mouse cursor”. We’ll have to see whether it calls for adjustment or not…

The latest version feels like a big improvement.

It might be fun to add another slider to control the average delay time between proactive strikes made by the AI. Essentially a difficulty slider.

Also it could now make a big difference having some percentage of the strikes be randomly oriented rather than predictably striking always where the player has left itself most open. You can bait the AI into using a particular attack by holding your guard in the opposite direction and get an easy win.

Thank you! I’m very glad that it is indeed improving so.

I’ve actually given some thought to difficulty levels, and do intend to have them for the final version. Indeed, since much of the main gameplay of my game is not combat- or reflex- oriented, I mean to provide the means to scale the combat difficulty down to a very easy version for those who either find fast-paced gameplay too difficult or who simply don’t like it, but who do want to experience the rest of the game.

The scaling that I have in mind will probably touch on more than just the delay times–although that delay is, I think, one of the elements that I have in mind.

Indeed, reducing the predictability of the AI is something that I’m working on, and mean to work on further.

New version!

Note that, due to some of the changes that I’ve made (in particular work on integrating this mechanic with the main game), the prototype no longer waits for you to press space in order to start; however, the AI shouldn’t attack immediately (unless you do), so you should have a moment in which to find your bearings.

Changes:

[]Various improvements to the AI–for one, the “universal parry” should no longer work.[/]
[]A maximum “mouse speed” has been instituted.
[list]
[]I was concerned about people with fast controllers being able to push the sensitivity to maximum, and thus be able to attack fast enough that the AI has insufficient time in which to react.[/]
[]Please let me know if this maximum is too low![/*]

[/]
[]“Small” attacks–those started too close to the centre-line, more or less–now do no damage.[/]
[]The game now defaults (more or less intentionally, that is) to windowed mode, but should be more playable that way. However, see the next point.[/]
[]Changes to the options menu:

[]Fullscreen may be toggled and the resolution set (from a set of only three options at the moment, I’m afraid) in the “graphics” tab.[/]
[]Mouse sensitivity may be set in the “combat” tab.[/]
[]Key-bindings may be changed in the “controls” tab.[/]

[/]
[]Some additional sounds, and some changes to which sounds are played and when.[/]
[]Minor “flinch” animations; I should likely make their motions slightly larger, however.[/]
[]Miscellaneous other changes.[/*]
[/list:u]
Known issues:

[]There’s at least one type of attack which–if successfully pulled off–the AI has little answer for.[/]
[]Some physics issues remain.[/]
[]Game options are not stored between sessions–with the possible exception of the key bindings, which might successfully store.[/]

The new prototype aside, I have a more general concern regarding which I could use advice: I’m uncertain of how well this mechanic is going to fit into the game for which I’m creating it.

The game flow that I’m trying to create for my “levels” is one of exploration and some puzzle-solving, involving first-person exploration of the game environments, punctuated at times by dangerous combat encounters. In a single level the player might have, say, one to five combat encounters.

If you’ve played the old combat-inclusive gamebooks–Fighting Fantasy or Lone Wolf, for example–think of those: such gamebooks are one of the inspirations for this project.

This brings me to my two main problems: First, since combat doesn’t happen often, this mechanic is somewhat fast-paced and unusual, and the main gameplay moves somewhat more slowly, I’m worried that players won’t manage to gain proficiency with this mechanic, and thus founder against tougher encounters. Second, I’m concerned that it will feel out of place, and damage the flow of the game.

I’ve considered putting together something more puzzle- or turn- based, but thus far am having trouble coming up with something satisfying; in particular, turn- or puzzle- based mechanics seem to me to tend to lack the sense of urgency and danger that I’d like combat to have.

(There is one mechanic that I’m aware of that would likely work–and indeed which was an inspiration for this mechanic–that being the mechanic used by the Quest for Glory games. However, I’m very hesitant to simply copy that. :/)

The combat feels more dynamic still, excellent work.

Regarding puzzle versus action, I think we have seen these two balanced before by games using three methods.

Method 1: The phased approach.

This was very popular with early shooters like Doom, Descent and Marathon that included quite a lot of puzzle solving. Basically there are numerous enemies throughout each section that do not respawn. So the player first wipes them out (phase 1) before focusing on solving the puzzle (phase 2) that is blocking passage to the next section of the game.

Method 2: The Onslaught.

This is the same as above except enemies respawn at some rate. This puts pressure on the player to solve the puzzle quickly in order to escape endless peril. The aforementioned shooter/puzzler Marathon had exactly one level like this (G4 Sunbathing) that was very memorable as a result. Using this for every part of your game might get a little too hectic though.

Method 3: The Choice.

You offer two strategies to get through a section, one involves a lot of combat, the other involves puzzle solving. It could be there are two pathways through a section, one heavily guarded, the other blocked off by the puzzle. Or solving a puzzle might kill the enemies guarding the pathway so the player may pass without conflict. Or even convert those enemies into allies that help fight through the enemies of the next section.

Thank you very much.

Regarding your suggestions towards the puzzle/action issue:
Hmm… I’m not sure that (1) and (2) will likely fit into my game: I don’t mean to have a large number of enemies (nor respawning enemies), and I’m aiming for puzzles of greater depth than games like Doom offered, as I recall. That last point in particular leads me to worry about players finding it jarring to move from serious puzzle-solving to action, then back again shortly afterwards.

… Not that that’s entirely inappropriate to the experience, I suppose…

Suggestion (3) is something that I’ve considered, and am still considering. It means making sure to always offer a way around an enemy–at least for enemies that block the route to continuing the main story. I could always have enemies that cannot be bypassed blocking optional paths… However, for some reason something doesn’t sit well in my mind with implementing this in this game.

Thank you for your thoughts–they’re appreciated, and have given me more to think on.

Doom might be a bad example, my memory of it is very fuzzy. But Descent had brain-damagingly complex 3D labyrinths and Marathon had arcane and more varied types of puzzles with sometimes harsh consequences for incorrect solutions.

As for how jarring it might be going between puzzling and action, perhaps this depends on the nature of the puzzles? Your combat demo, like most action games is about spacial thinking and timing. So if many of your puzzles are spacial in nature (i.e. platforming puzzles) and/or have time limits, then they may mesh well with combat.

Not that all puzzles would need to be that way to blend with combat, imho. Some older primarily-puzzle games, like The Journeyman Project and Star Trek: 25th Anniversary, had a mixture of combat, spacial puzzles, time sensitive puzzles and purely abstract timeless puzzles of brutal complexity.

On the other hand, for a game with mostly abstract and always very complex puzzles that have clues and solutions spread out over the whole game world, like Myst or especially its merciless sequel, Riven, adding combat would probably be overwhelming.

You can also approach integration from the opposite direction, of making combat more like a puzzle. This too was popular in older games, especially with ‘boss fights’, where defeating each type of opponent was mostly about discovering, through some combination of reasoning and experimentation, what sequence of actions it was vulnerable to. Reflexes and hand-eye coordination were secondary.