Advertisement

Designing a 3D melee system

Started by May 26, 2021 07:20 AM
7 comments, last by Tom Sloper 3 years ago

I'd like to have a combat system that simulates pseudo-medieval combat in a somewhat realistic manner, while still being learnable (though difficult to master). The big design challenge for me is the melee combat. I've gotten to some kind of a proof-of-concept level in interpreting mouse information and applying it to a weapon:

An example game with a more finished implementation of mostly just free-form slashing movements: Die by the Sword. Possibly not good enough for me.

If a shield is added with some key assigned to block with it, aside from just movng around there's a new possible decision for defending yourself; parrying with slashing controls seems so difficult I wouldn't really count it. The Legend of Zelda: Skyward Sword is kind of what it would be like, except the weapon controls weren't as free-form there. Motion controls were something I played around with in my own game as well and could be something to readd in the future when I have more proper equipment, but mouse controls sound pretty important to get right to me.

The Mount & Blade series had even less free-form attacking, but parrying was even kind of doable in it. I think the possibility of parrying is an important feature to have, since of course I'm not going to have every character have a shield.

Possibly restricted ways of delivering blows just… works from playability standpoint. But it's also kind of an unsatisfying answer for how to simulate pseudo-medieval combat to me. Unless you really complicate how many buttons are devoted to choosing just how to deliver a blow, you might not be able to have a body part system where it matters where hits landed. But I do think it matters.

So I'm opening this up for a discussion. I've had some of my own ideas, of course, for controls and other combat mechanics but it's still a little bit up in the air.

I haven't tried any of those (will eventually, I hope), but take a look at how Kingdom Come: Deliverance does it. It maps the mouse to one of 5 segments based on the angle between the mouse and the center of the screen. The view orients(locks) on the target until the mouse is yanked way off, the character backpedals or is otherwise invalidated. Very little mouse movement to be concerned with here. The rest is footing and changing between the segments (and stabbing)

Advertisement

I suppose Kingdom Come: Deliverance's melee is achieving the objectives I had laid out. The big takeaway from looking at that for me was locking onto the opponent might be the way to go. The game is then able to somehow calculate how a block/parry should be made and it would thus only require pressing a singular button at the right moment. And the other mouse button could be used for setting up a stab while it's being pressed and doing the stab when it's released, and the height at which it's being aimed depends on the mouse's Y position at the time of release.

I do, though, feel like I can retain my free-form slashing. It does need more adjusting so the weapon's movement takes longer to change directions, and also actually hitting the target with slashes should be made easier.

There are still some things about locking on that remain open questions in this possible plan. Locking on and changing targets could be done with the mouse wheel, but I'm not quite sure how the breaking of the lock-on should be done. Mouse movement is already mapped to free-form slashing, and I could see dodging being used with the movement keys so those aren't necessarily that great of an option either. Breaking the lock-on via turning with Q or E could be an option, but...

I'm not quite convinced that the player should instantly be turning toward the opponent the moment they move. Nobody has reflexes like that. So how should it behave, then? The turning could automatically happen at a delay but a player could theoretically play without ever locking onto anything and gain an advantage by anticipating better than the default auto-reflexes. This led me to a train of thought that even during a locking-on the player could press Q or E to turn slightly that way, anticipating the opponent being there in a moment. Is this overly complicated, though?

Then again, doing a block with just a button press doesn't sit all that right with me either (except with a shield). It removes a lot of skill from the equation and also I've thought of another way with which to allow more complicated maneuvres of a deflection followed up with a specialized attack if the fighter is skilled enough. Since blocks were the primary reason for having the target lock and it also gives rise to questions about how to simulate reaction times, it should be re-evaluated whether to implement those at all.

Anyway, my idea regarding manual parries was that the player presses a parry button on their mouse and their whole arm will freeze in place relative to their body. Instead, while holding that button they'll be instead rotate their weapon with mouse movement. It shouldn't take a huge amount of mouse movement to put the weapon into a parry-position. Now if a weapon hits that sword, physics will make the hitting sword lose a lot of its momentum and push the blocking sword into motion that can be harnessed by a skilled enough fighter to some kind of a retaliatory strike, possibly still while holding the parry button. If they did release the parry button, however, the weapon would go to its default orientation and the arm would resume trying to orient itself according to the mouse position.

Of course I had to also think about what happens if the player also presses the “stab” button at the same time as the parry button. I think in this situation it would retain the sword's orientation but move the arm according to the mouse cursor's position. It starts getting a bit complicated at that point, though, and maybe this could be omitted and it just wouldn't do anything. It could require playtesting to see how to best handle those situations.

But I'm quite happy with the idea of having just one stab button; in a previous plan of mine there were three stabbing modes, for high, medium and low stabs and the cursor position would determine the top-down perspective location of the weapon. What I said previously does have to be amended, though, in that the X position of the mouse cursor also matters where it's being aimed at since that can't be a given if the target lock is removed. Maybe there could be a visual indicator for where it's being aimed at?

If you look at traditional Western sword fighting styles, like say, fencing, then there aren't really more than four distinct parry positions, based on the standard quadrant:

In practice there are several parries for each quadrant, but those are mostly differentiated by the orientation of your hand at the time you initiate the parry, which probably makes them irrelevant to the input scheme.

One of the reasons to simplify the control scheme like this, is that unlike with a slash or thrust, the precise angle of the parry doesn't really need to be adapted on the fly. No matter what angle the attacker's blade is approaching from within the given quadrant, you would parry it with a fixed angle of your own blade (and this is kind of essential, because parries need to be reflexive - you don't have time to choose a precise angle when an opponent's blade is flying at you).

Also worth mentioning that you seem to be focusing on slashes in your current scheme, but slashing attacks are really uncommon in sword combat, for a variety of reasons. Armour was sufficiently advanced that all you'd really accomplish with slashes against an armoured opponent was dulling your own blade (typical approach here would be to disorient your opponent with a blunt-force weapon, and then slip the tip of the blade in a joint/neck/other soft spot). Against an unarmoured opponent slashes are of course more effective, but they require you to be much closer to your opponent than you would need to be for a thrust with the point, so they aren't feasible unless the opponent's own weapon is out of the picture.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Okay, if the controls can be simplified to just four parries that worked by pressing the parry button and moving the mouse in the corresponding direction, we would get some more player skill involved than just “press the button at the right moment” but it would probably reduce the learning curve significantly compared to what I suggested. It might just be worth it.

Advertisement

I started making something akin to this once, but ended up abandoning it.

As to parrying, I think that I had an offset mouse-position automatically enact a parry. This way there's still player-skill in choosing the correct parry, and indeed with a sufficiently free-form system it would be possible for the player to have a near miss, but without requiring an extra set of controls.

One thing perhaps worth noting is that I took the “Quest for Glory I-IV” approach to encounters: instead of asking the player to manage terrain and the possibility of new enemies arriving during an encounter, I drop the player into a separate “combat world” in which they face their foe one-on-one.

MWAHAHAHAHAHAHA!!!

My Twitter Account: @EbornIan

If you do make a melee system, just remember this: real life melee combat is quick!

A lot of games make the mistake of adding artificial slowness (like chivalry) and it is really unrealistic, annoying from a player's point of view, and feels sluggish.

-Corrosion

Thread locked. Please don't necro!

-- Tom Sloper -- sloperama.com

This topic is closed to new replies.

Advertisement