Your idea has merit, but there are a few potential problems I can see that might be difficult to surmount.

First of all, a mouse is very two dimentional, and you are using it to discribe a weapon traveling in a very three dimentional way. You may be able to control the arc of the swing, but how deep is the slash? This could probably be overcome with some creative uses of WASD with the mouse drag option.

The second problem is one that has plagued many games using similar (but less sophisticated) methods for controlling a weapon. Dragging a mouse is not a very precise motion. Have you ever tried to draw a perfectly horisontal line in a paint program using only the mouse cursor? It is very difficult and awkward. I'm not saying your design requires such precision, but controlling exactly where your sword is going to go will still be very difficult in a heated battle, and I would think it would be easy to swing wide or create a rather jagged path for the sword to follow that the physics system would have to smooth over to make a convincing sword slash.

The third potential issue is control. Mice are difficult to "wield" effectively. The hand motions require to move a mouse in a way that would drag a sword arc accross the screen are not very natural, and would probably induce some fatigue after playing for a while. The only way I can think of to deal with this would be to require very small mouse movements for large swings (i.e. high mouse sensitivity). This would reduce the precision of the swing somewhat, but it would allow for much faster control.

Please keep in mind that I am not trying to shoot down your idea. This is meant as constructive criticism.

I think the reason that Oni's controls worked so well was that even though all the attack animations were canned, there were so many possible motions to choose from that the user still had a fine level of control over what he wanted to do. The motions ceased to be keypresses and button clicks and became extentions of the player's thoughts.

Good luck (and give Oni a try, if only for some inspiration).

[Edited by - hatch22 on March 3, 2005 11:33:49 AM]

Quote:

Original post by hatch22 Personally, my all time favorite control interface for hand-to-hand combat on a PC is the one found in Bungie's Oni.

I also enjoyed this game immensely. I whole-heartedly agree with you about the quality of the melee combat in Oni. It is part of what influenced me and got me thinking about just how fun a fast-action, melee combat game could be.
All the combat moves in Oni where what I called ‘type one’ in my earlier post. By that I mean that the punch, kick, throw and even gunfire attacks in Oni could be well-defined by a point and click control scheme. What you don’t do in Oni is actually wield a weapon that you would SWING. Swinging could be fundamentally different.

Quote:

Original post by hatch22 ….a mouse is very two dimensional, and you are using it to describe a weapon traveling in a very three dimensional way.

This is exactly right. I ran into this problem almost immediately. My current solution is to have an “active target” enemy and its distance from the player character defines the depth. This also helps me with another, unrelated, challenge posed by the third-person perspective. It might not be the best answer, but it’s working for now...

Quote:

Original post by hatch22 The second problem is …. Dragging a mouse is not a very precise motion. .... controlling exactly where your sword is going to go will still be very difficult in a heated battle.

This is also true. My hope is that even if you can’t swing precisely, it will still be easy to swing in the right general direction, and the better you got at it the more likely you will be to miss the shield and hit the weak spot.

Quote:

Original post by hatch22 The hand motions required to move a mouse in a way that would drag a sword arc across the screen are not very natural, and would probably induce some fatigue after playing for a while.

You’re right about this as well, thus the mouse motion cannot be required to correspond directly to the sword arc. The click and drag motion would simply facilitate the definition of a line. When a user points and clicks, he defines a point in space. When a user clicks and drags, even a short distance, he defines a line, and that line could be used to extrapolate an arc. So the controls would be no more physically demanding then FPS or Oni, except that when you’re ready to swing you just hold down the click and move the mouse some distance to define that trajectory. Neither the length of the mouse movement nor the speed at which you make the motion would have an impact on the effectiveness of the attack. (although I guess you better not take to long drawing your line or your enemy will take you out, but this is no different than the decision you make about the amount of time you will aim before firing a gun)
Does it make sense to define the trajectory of a swing by dragging a short line with the mouse?

Quote:

The click and drag motion would simply facilitate the definition of a line. When a user points and clicks, he defines a point in space. When a user clicks and drags, even a short distance, he defines a line, and that line could be used to extrapolate an arc. So the controls would be no more physically demanding then FPS or Oni, except that when you’re ready to swing you just hold down the click and move the mouse some distance to define that trajectory. Neither the length of the mouse movement nor the speed at which you make the motion would have an impact on the effectiveness of the attack. (although I guess you better not take to long drawing your line or your enemy will take you out, but this is no different than the decision you make about the amount of time you will aim before firing a gun) Does it make sense to define the trajectory of a swing by dragging a short line with the mouse?

I see what you're getting at here. This strategy would allow the player to define the motion but not directly control the motion (i.e. the mouse does not directly control the motion of the sword, but only difines the direction in which the sword will move. The only problem I see with this is speed which you alluded to. Not only do you have to take very little time to drag your mouse, if you want to do any kind of quick slashing you are going to have to press, drag, and release the mouse several times in quick succession, changing direction each time. This would be tricky because you run the risk of having motions that were intended as clicks being interpreted as click-drags. Often when we click the mouse, it moves slightly. If you have some kind of very small distance threshold causing any mouse movements while clicking to be interpreted as just clicks when under the threshold and as click-drags over the threshold, then you could avoid accidental moves, but if your threshold is too high, then performing a click-drag would take to long, making swordplay sluggish. There may be some threshold value that works well, but it still seems to me that such a system requires a fairly high degree of control over the mouse. Granted, such control is definitely achievable (just look at the mouse-wielding skills of many die-hard FPS players), but recognize that such a system may up the learning curve and frustrate less experienced players.

Even with a threshold, speed may still be an issue. A click-and-drag, no matter how small, is never going to be as fast as a click. The near-instantaneous response from button/key pressing is very helpful when fighting is fast and furious. Perhaps this is not an issue for the kinds of game you want to use this system with, but if it were an action game like Oni, any latency between the input and my characters response would frustrate me if I was under attack by several enemies who were about to clobber me and I had only a split second to cut a wide arc in front of me and interrupt three at once. If I get hammered and then beaten to a pulp because my drag caused a tiny delay I wouldn't be to happy. Thinking about it some more, this might be fixable by starting the sword moving as soon as the mouse button was pressed and setting the movement direction as soon as the mouse was moved, or performing a stab if the button is released instead.

If the mouse movement is so integral to control, how easy will it be to rapidly face a new enemy after just knocking down another one and then perform a slash? For example, in Oni, Konoko can knock down a Tanker with a triple haymaker, spin around and throw the other Tanker that was about to hit her from behind and toss the new enemy on top of the one she just knocked down, doing furthur damage. She can also change direction in the middle of some move combos. Although this is not always implemented in the most realistic way possible, it is still essential to the gameplay because it is possible to attack so many different oppenents so quickly. This is the advantage of keeping mouse motion separate from attack moves, and is an issue you will have to address if you want the blinding speed of martial arts. When you're out-numbered and surrounded, increadible speed is much more important then great strength or high damage weapons.

Reading back over my comments, I get the feeling I'm being harsh. I really am curous to see if your system could be implemented well, I just like for good ideas to be well thought out. Being an engineer, I tend to look for potential problems everywhere to nip them in the bud. Sorry if this seems a bit discouraging. To answer your question, yes, I think it makes sense to define a swing with a line drawn by a mouse, but I think a good implementation will be very tricky and may not work as well as a large selection of pre-done moves (ala traditional arcade fighting game series like Street Fighter, Tekken, or Soul Calibur).

For a good example of simple rock-paper-scissors combat with good use of range and pre-emption, take a look at Dragonball Z: Budokai 3. You can go a long time in that game without landing a blow, or you can decimate (or be decimated by) your opponent in short order, depending on the compatibility of your tactics. It reminds me of nothing so much as a game of StarCraft. If I go for the early rush, and he escapes it, then he's got more ki power and can hit me back with much greater force, but if I "turtle up" and wait for a juice-up, he might be able to pre-empt me and take the advantage. Against an equal, it's a blast, but if you're fighting someone better than you, you quickly feel like a witness at your own execution.

So perhaps if you let the actual maneuvers be scripted actions--thus preserving the intuitive methods of a highly trained fighter--and have the player enter in at a level one step higher--that of tactics and maneuvering--you could preserve the control and the depth of combat in your game. Something like Star Ocean might be another good example of a way to do it, although it's a little more basic than what you seem to be after.

just a small note, have you considered how the length of the swing will be controlled. For example, if when you click and drag this mearly identifies a line in space which the swing will follow, where will this swing stop. If each swing is a set length then the character is going to look very uncontrolled as he advances with the sword swinging fully from side to side unless contact is made. Also this will lead to a level of clumsyness about the control system if the player wants to make a quick block and the sword moves to make a full swing.

Something has been overlooked: speed

As I see it, this system would work, but only for games where the combat isn't furiously fast. Medieval Europe swordfights weren't really fast, since the whole armor and swords were really heavy, they were more tactic (and not all about keeping the sword in front, thats too simple). Your opponent blocks, you open him up and take a swing. If instead of blocking he dodges, you cannot take a swing because that opens you up, etc etc. Speed and momentum are the name of the game.

So, for oriental-style fast and light swordplay, i'd ditch the line method. But for medieval fights, you gotta lower the pace of the fight and let it be a little more cerebral. Allow control of strength/speed as well as direction.

for the line, you could take the initial click point and sample at regular time intervals inside, including the last click. After that ditch points that are too close (not including start/end points) to end with a smooth curve.

about controlling speed/momentum... the jury is still out. But keep in mind this system will not be for a fast fight, but for a much more technical one. Easy opponents would be poor blockers, and would be unable to string movements together, making it easy to combo them. On the other hand, tough opponents would chain everything together, by picking the right direction, moment and strength to swing. Localised damage and proper animation would make this very interesting.

The trespasser fiasco was because there was no abstraction in the hands. In Half Life 2 you can grab something and have scenery block it as you move around, and it falls just like in Trespasser. But unlike it, you don't have to tilt your hands manually.

Quote:

As I see it, this system would work, but only for games where the combat isn't furiously fast.

This is what I tried to explain in more detail in my last post (and perhaps I didn't do a good job of making it clear).

So basically, if you can address the speed issue somehow, or if combat doesn't have to be fast, you have a workable system.

Quote:

Original post by Madster ...this system would work, but only for games where the combat isn't furiously fast. Original post by hatch22 ...if combat doesn't have to be fast, you have a workable system.

I strongly agree with both of you on this point. The pacing and speed of the action is an important consideration with any control scheme, but with what’s being discussed here it is particularly important that the pace of the action allows the controls to work. I especially connect to what Madster says about the scheme working best for medieval fights, where the pace is slow and methodical enough to allow user enough time control of the details of the swing.
Consider the pace of the game Rune. I dislike how the characters in Rune are always sprinting around at 100 miles an hour and jumping 3 feet in the air without effort. I’ve never been in a swordfight, but I’m guessing if I were I wouldn’t do much sprinting or jumping. The actual attacks in Rune also happen much faster than they should IMO.

Let’s expound upon the control scheme discussed above to include elements for controlling speed. When the user clicks and holds the attack button to begin drawing the line, the character would immediately begin cocking back its arm in preparation for the swing. The longer you hold the attack button longer your character’s arm has to complete its backward motion, and when the user lets up on the button, the forward part of the swing immediately begins. Both the preparation for the swing and the swing itself are the result of forces in the physics simulation, so if you hold the button long enough, the result will be a slow, powerful attack. (Slow as in slow to execute, the weapon will be moving fast) Conversely, if you just click and let up real fast, the arm will have no time to cock back, and the result will be a quick, weak attack. Pushing attack or block mid-swing could interrupt the swing, causing the joints to do their best to counter the momentum and move toward the position of the chosen action. So the speed of the actions in the game are essentially upper-bound by the strength of the joints in the physics simulation, (which could get stronger as your character progresses) but the timing and momentum is controlled by the user.
Does this timing control concept make sense? Does it begin to accomplish some of the points made by doorstop, Madster and hatch22 above?

Quote:

Original post by Madster about controlling speed/momentum...

I’m intrigued by the points you make in this paragraph. Could you elaborate on, what would it mean to “string movements together” and “combo them [opponents].” Could the controls I outlined above accomplish that to some degree by the user choosing a second swing that begins close to the place were the first swing concluded? Is there more to this that can’t be accomplished by the control scheme I describe?