Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Mel_Vixen]

(Two handed) Weapons: Binding, Parry, Blocks, attacks and how to simulate it proper was the maintheme  i think.

[Footkerchief]

Heph -- it's theoretically possible to model the wrist separately, but there's no good control scheme for it (cf. Jurassic Park Trespasser).  We're assuming that the main hand is always at full extension during an attack, and that the weapon points straight out from its center of rotation -- that is, it always lies on the line that passes through the center of rotation and the main hand.  These are not totally realistic assumptions, but without them the interface becomes absurdly complicated.  Believe me, a shoulder joint is the absolute maximum.

The 3x3 grid can't change size to match your opponent, ever, because it's a model of your range of motion regardless of your surroundings.  It extends outward based on a) how far your limb can extend and b) how far your weapon extends past your main hand, and therefore its maximum height can increase or decrease, but the maximum angles do not increase.  Remember, the grid is really just areas on the outer surface of the sphere that forms your range of motion.

Look back at the drawings I posted earlier with the dwarf and the titan, particularly the "max height" text.  That part still applies.

It's exam week here--I'm already insane.

Couldn't we have 3 concentric spheres for each arm, and try drawing a line from the slash's end to the pivot point, and have that act as the weapon? Then it'd be an inputting of lengths, and using the line to infer hand position.

Exam week here too.  Do you mean for one-handed or two-handed?  Why 3 for each arm?

The difficulty with two-handed swings basically arises because the pivot point is not at the center of either limb's range-of-motion sphere (contrast to one-handed swings, which always pivot at the center of that limb's range of motion).  This makes it difficult to figure out the maximum extension of the main hand -- once you know that, the off hand's position is easy to calculate.  In addition there are problems with a two-handed retracted position -- basically, the ready stance that works for a longsword doesn't work for a quarterstaff, because the quarterstaff would have to extend into your body.  I'm trying to take a step back and make some additional simplifications.

[Mel_Vixen]

Because the quarterstaff would have to extend into your body.

How would an Quarterstuff reach into your body? I cant visualize that.

And by the way i did understand the grid system. It is good  .

I just suggested an overhead row for things directly over you since this position is not normaly covered by how i did see it.

 However the 3x3 grid works fine enought after some thinking.

[Footkerchief]

How would an Quarterstuff reach into your body? I cant visualize that.

Never mind, it was a confusing example and I think I might have a partial solution worked out.

Each hand, in addition to its normal retracted position, has two special multigrasp positions -- the active ready position (the hand's retracted position while it's the active hand), and the inactive pivot position (the pivot point for the weapon when this hand is inactive).  The inactive hand always falls somewhere on a line between the active hand and its pivot point.  Ideally, for a humanoid, the left hand's inactive pivot would lie somewhere around the left hip.

We can then position the active ready position so that the angle of the weapon makes sense -- the right hand's active ready position would probably be central, or maybe even slightly left of center.  So, place your right hand 1.5 feet in front of your solar plexus, and imagine a line running from that point to the pivot point beside your left hip.  Your left hand MUST occupy a point somewhere along that line with any weapon -- either close to your right hand, for a sword, or down at your hip, for a staff.  Is this workable?  I really can't tell whether this would be an acceptable ready stance.

If that does work, we still have to figure out the active hand's new range of motion for multigrasp.  If the sphere centers on the pivot point, what should its radius be?  I don't have a good answer yet.

[bjlong]

Sorry about that, I died a few nights ago.

Anyways, this seems like it's an acceptable solution, but I think you can generalize this more. For each stance, you'd specify a pivot point, an active ready position, and the distance between your hands (d). Then you could easily generate (most) of the rest.

The range for the active hand could be the intersection of the sphere of radius (arm)+(d) centered on the inactive hand's shoulder and the sphere of radius (arm) centered on the active hand's shoulder. The system could then be taught to check only within certain positions--a 150 degree by 150 degree solid angle--for slashes, so we don't have to worry too much about the approximations made here.

We still need to come up with a system for dealing with thrusts with this, though.

[Neonivek]

We also need a system of acceptable breaks from reality due to the obvious epic state of the system.

The game should be realistic to the point and then once a certain skill level gets reached the 360 "Swat everyone away with a single swordstroke" should be possible.

[Footkerchief]

Sorry about that, I died a few nights ago.

Hah, no problem, I figured it was something like that.  I just finished exams so it's a good thing I wasn't typing out a long-winded reply last night.

I think the game can infer 'd' as well -- with the system we're talking about, the only real changes in stance are 1) one-handed vs. multigrasp and 2) changing grip points, and 'd' is just the distance between the grip points, so it's under the player's direct control, mostly.  More on changing grip points later.

My initial reaction to a spherical intersection was "that's way too complicated" but now that I think about it, you're right, it should work.  For some reason I was thinking one of the spheres had to be centered on the pivot point, but that's not true -- the pivot point just pins down the orientation of the weapon. 

So we use a fast line-sphere intersection algorithm to project the centers of the grid areas onto the surface of our sphere intersection, and then treat all slashes, etc. as straight-line movement of the active hand (and further out, the weapon tip) between the projected points.  This makes it straightforward to interpolate weapon movement, and if the straight-line motion isn't accurate enough (i.e., the projected points on the sphere intersection are too far apart) then you can just project a few extra grid points in between.

Here's what a slash from ready position, followed by retraction to ready, looks like:

• Initial: active hand is at active ready position; inactive hand is distance 'd' from the active hand along the line connecting active ready to the inactive pivot.  'd' is simply computed by comparing the current grip points on the weapon.  Position of the weapon's active end is computed based on orientation (from pivot to active ready) and how far weapon extends past active grip.
• Active hand moves in a straight line to the slash-start projected grid point.  The inactive end always points back toward the pivot, and hands do not shift on the weapon, so weapon/hand positions can be calculated at any point during this motion.
• Active hand moves in straight line from slash-start to slash-finish (or in several straight lines between extra grid points dynamically projected to assist interpolation).  Meanwhile the weapon tip is doing the same thing further out.
• Retraction: active hand moves from its post-slash position back to active ready. 

So anyway, I think we've achieved an unambiguous model that allows arbitrarily precise calculation of weapon and hand positions!  Fuck yes!

Thrusts can be done exactly the same way as long as you maintain the pivot.  In this system, a slash from ready/retracted is a thrust plus a swing.  I guess the advantage of just doing a thrust (and not swinging afterward) is that it's faster and less likely to throw you off balance.

Crossblocks -- there are some slight complications, but I have a scheme worked out.  More on that and grip points in a bit.

Edit: clarified that the active hand always "leads" the weapon's active end, not the other way around.

[Neonivek]

Alright... Here is a checklist as I can BARELY understand that algorith

Does it include
A) Weapon in Mouth for a creature such as a wolf
B) Double handed weapons if the creature has arms differnet lengths
C) Tripple handed weapons!
D) Curvy weapons (Some Nunchuck like weapons can MORE then strike someone on your right even if you hold it in your left hand)
E) Arching your back

Alright I am really sleepy... just forget what I said

[Footkerchief]

No, those raise some good points -- those are helpful for understanding the limits of the system.

A) Yes, I think so (you'd have to treat the neck as a "shoulder" or something).  But the weapon has to point straight out, it can't be held sideways.
B) Yes, although there needs to be logic that prevents you from multigrasping if your arms are too short to both grip the weapon at once or something.
C) No.  You could have a squid wielding a spear with two of its tentacles, but three is just too hard, and not really worth it.
D) No.  Weapons have to be roughly straight-line.  We still have no idea how to manage whips and flails (which aren't really very practical weapons anyway)
E) No.  The "stance" here only takes your arms into account, although it could be incorporated into deeper stance support.

[Tack]

heh, now translate that to a spear.

Then, if two handed, you'd need a 5x5 at least, instead of the conventional 3x3 for swordplay, which also means that the spear wielder could stand back and jab. UNLESS, you put into the model for stave/glaive fighting, in which it would be 3x3, but with two attacking ends which move relative to eachother... following?

That would be really complicated, because although it allows for better flow in attacks, it also puts you at a disadvantage with blocking, and offers a REAL issue when compared against realistic stave fighting, i.e. the side block is performed with both ends in the 4, or 5 quadrants, held vertically. Also, having a spear against, say, an axe also brings in the durability issue, i.e. metal chops wood. der.

So if we were to use the first design with the spear travelling in straight lines away from the user, i.e. spear head goes 5,8 on a horizantal grid, (not going to complicate things further by swapping numbers around to accomidate a 5x5 grid, try to keep up) then the basic attacks could allow for inter spear and spear vs sword attack and defence, however, if the person comes closer, then would they change fighting styles to accommadate the new reach? or would it magically grow shorter?

Also!
Could we use this ideal then to allow stabbing through fortiffications, or down a z level?



i've thought about the whip problem, not much, but i've thought on it.

if we're thinking of a simple bullwhip, i.e. completely impractical, then simple backswing and forward swing would work. say it moving from 5,5 (by your side) to 1,2 or something i dunno, the air above and behind, i can't calculate the grids in my sleepy state. and then forward swing which creates the attack point, like a stab, but the attack is delayed.

with a cat o nine or something, which splayes as it attacks, there the problem arrives.

[Footkerchief]

heh, now translate that to a spear.

Then, if two handed, you'd need a 5x5 at least, instead of the conventional 3x3 for swordplay, which also means that the spear wielder could stand back and jab. UNLESS, you put into the model for stave/glaive fighting, in which it would be 3x3, but with two attacking ends which move relative to eachother... following?

I know this has gotten extremely complicated, but check the pictures I posted on the last page -- they illustrate that the "grid" is not actually a flat plane in front of you, it's sectors of a sphere.  So the greater reach of a spear is already accounted for.

[Neonivek]

I guess the last would be.. If the weapon is held in two hands... Both Left!

[Footkerchief]

Some side thoughts -- there's no reason why you should have to return to a retracted position before moving.  So you can slash your sword upward into a high guard, and then move around while maintaining that stance.

You could also thrust a spear into an extended position and then charge with the weapon still extended.

Crossblocks: okay, the "thrust with both hands" idea from earlier still applies, although the distance between your grips might not be wide enough to thrust your left hand to 1 and your right hand to 9.  So the active hand will always thrust to the selected point, and the inactive hand will use its selected point as a guideline, i.e. it draws a line from 9 to 1 and goes as far toward 1 as the grip permits.  The pivot has to be ignored, of course, but since the hands are moving to two different destinations (unlike a thrust or slash, where they both move toward essentially the same destination), the weapon's position is still unambiguous.  The only necessary restriction is that you can't slash while you have both hands extended.

Changing grip: a slider display would be enough, and it can easily be done in ASCII.  Something like this:

Code: [Select]

-L--R----->
L being the left hand, R the right hand, and > the active end of the weapon (R is the active hand here, since it's closer to the active end).  Plus four keys to move each hand up and down the shaft.

[Tack]

right, but wouldn't it be easier to use sword mechanics for a spear, except with a longer reach?

which would suck.

I want it attacking people two squares away.

also, having it stab based, people can attack while in a high ready position, which allows for dodge & skewer with a spear.

[Footkerchief]

right, but wouldn't it be easier to use sword mechanics for a spear, except with a longer reach?

which would suck.

I want it attacking people two squares away.

This system could permit the "two squares away" thing.  It all depends how the range-of-motion spheres get translated into tile space and mapped against the body models -- this system just ensures that hands and weapons move unambiguously and realistically inside accurately sized spheres of motion, which is an extremely important first step.

i've thought about the whip problem, not much, but i've thought on it.

if we're thinking of a simple bullwhip, i.e. completely impractical, then simple backswing and forward swing would work. say it moving from 5,5 (by your side) to 1,2 or something i dunno, the air above and behind, i can't calculate the grids in my sleepy state. and then forward swing which creates the attack point, like a stab, but the attack is delayed.

with a cat o nine or something, which splayes as it attacks, there the problem arrives.

Didn't see this part earlier, but it's a very good idea.  The concept of a "delayed" hit, like the active end of the weapon lagging a second behind the position a linear weapon would occupy, might be an adequate quick-and-dirty model for nonlinear weapons.