Print

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

[Tack]

However, with a whip, after the first initial strike, i.e. hand behind head, whip end striking target, there needs only the movement repeated to continue attacking, slightly different to real whip cracking, but all successive attacks after the first would definately be faster.

[Footkerchief]

However, with a whip, after the first initial strike, i.e. hand behind head, whip end striking target, there needs only the movement repeated to continue attacking, slightly different to real whip cracking, but all successive attacks after the first would definately be faster.

It depends whether you're lashing or cracking.  I'm not sure cracking has any combat practicality at all, but then again lashing might not either.

[bjlong]

Talked to my mechanics professor yesterday about whips. I'm putting this up not because it's especially useful, but because it might end up answering some questions.

The bullwhip's "crack" happens because initially the whip is given close to uniform acceleration, and the handle of the whip is turned over. The rest of the whip must move foreward at an acceleration that's always greater than the original constant acceleration. At the crack, if the bullwhip's bend is infinitely sharp, then the bullwhip's end will move infinitely fast.

The reason that you can crack the whip more than once is that the whip can be given another constant acceleration, which puts the angle at about half as much as the original angle.

[Neonivek]

Whips made to hurt people usually have something on the end, usually metal or bone which can flay right into someone's flesh! Not effective in battle mind you but it is more then a "Wimpy cut" it can actually rip muscle.

I don't know why the Bull Whip (Or rather Leather whip with leather tip) has COMPLETELY eliminated the other kind of whip out of people's minds.

Then again I have no real knowledge of the Combat whips... They weren't actually called whips to my knowledge but they functioned in similar ways.

[Mel_Vixen]

I blame Indiana Jones!

[Tack]

so if we assume that the whip is a typical flaying whip, i.e. snakes tounge, two heads of forked leather, good cutting, or cat'o'nine, multiple headed whip with knots or sharpened beads, then it'd be a simple cock back and flay, with the whip head going over the top. But if you were to integrate that into swordplay, then it blocking a whip strike would have a x% chance of a "tangle", whereupon both weapons are useless for a few turns. good time to get punches in.

[Mel_Vixen]

On the other hand blocking with an whip should be near impossible.

[Neonivek]

On the other hand blocking with an whip should be near impossible.

Well unless you adjust the whip to be capable of hand blocking.

Though I don't see why the whip is useless afterwords... Better to do some Binding while the opponent is all tied up!

[Mel_Vixen]

yeah why not. and you can stab your enemy with an dagger aslong (s)hes wrapped in the whip.

[Tack]

yup... just have them tangled and completely at your mercy...

ENTER DWARF FORTRESS PORN

for all your ascii fantasies.

YeNO!

Why don't you just make it so that if the sword and whip become tangled, attacks are hilt-only?

[Footkerchief]

One-handed weapons, shields, and punches.  I'll post something about blocks and binds a bit later, I needed to figure out shields first.  We also need to talk about how to bring all this stuff into tile space.

I realized that the ready stance for a one-handed weapon is still ambiguous, unlike a multigrasped weapon -- we originally specified a one-handed ready position, but that doesn't give you an unambiguous orientation for the weapon.  Having the hilt/haft always point straight back to the shoulder would be goofy, so we need to either have a separate pivot point for one-handed weapons, or reuse the multigrasp inactive pivot.  The latter is simpler and I think it's sufficient.

We need a separate pivot for shields, though.  While the weapon haft might point back toward your hip, the shield would point more toward your heart, or just below.  So each limb has a shield pivot as well.

So, in summary, the body raws would define four special positions for each limb or tentacle or whatever, in addition to the limb's "shoulder joint" position and maximum extension:

• One-handed ready
• Multigrasp active ready (for when this grasp is the active one in multigrasp)
• Weapon pivot (for when this hand is the inactive one in multigrasp, and for when this hand is holding a one-handed weapon)
• Shield pivot (generally just below the heart, I think)

Alright, weapon positions are now totally unambiguous (I think) and our control scheme is still reasonably elegant.  We can make shields unambiguous too.

As long as you describe shields as a 2D disc, this is pretty easy.  All you need to describe such a disc is 1) its center (the grasp holding it), 2) its radius (defined directly or indirectly by item raws), and 3) its orientation (a vector perpendicular to the disc).  We just handled orientation -- the shield always points away from the shield pivot.  Rectangular shields introduce the problem of rotation around the shield's central axis, which our control scheme can't easily accomodate, so let's not try to model those.

Maneuvering a shield (for offensive attacks, at least) will be exactly like maneuvering a very short weapon -- slashes, thrusts, etc. still apply.  Although fully extending your arm for a shield bash seems a little weird -- maybe shields could reduce maximum extension of the limb by 33% or something.  Details, details.

Incidentally, punching people will also be exactly like maneuvering a very short weapon.  "Thrust" to jab, "slash" for a haymaker, backhand, uppercut or hammer fist.  Note that the pivot is irrelevant with a very short weapon -- the pivot is not the center of the range-of-motion sphere, it just provides orientation for the weapon, and a fist doesn't need orientation per se.  We can just treat it as a small sphere.

A side note on non-linear weapons: as long as the weapon's handle is still linear (which is true for whips and flails), our control scheme doesn't have to change, even if the weapon's tip is moving in all kinds of complicated ways.  This is a good thing.

[bjlong]

An excellent set of points, here. However, a slight problem with shields.

There are two general types of shields for our purposes--the ones that you strap to yourself (shield proper) or the ones that you hold by a central handle ("bucklers"). The shields are used to block by using the edge to take care of things that will just come over the sides, and using footwork to keep the sheild still while you move behind, beside, or around it. The trouble is here that moving around with the shield would cause stance changes. Other than that, your system would work.

Second, bucklers would often rotate around the z-axis, pointing straight up and down. This was to set aside blows as well as to deliver more effective shield strikes. Since they could be rotated and moved further out from the arm, they were used a lot more proactively.

Quick control scheme for bucklers: In addition to the jab-slash interface, add a rotation interface capable of rotating the buckler between three positions, say up, left, and right. You would use, let's say w, a, and d to specify the direction. So you could say [w] [a] [3] [1] to make the buckler change orientations from straight ahead to the left, and then "slice" as normal across your top arc.

This could be changed up somewhat to make the buckler something like its more flexible defense in real life. Say you're waiting for your opponent to strike. He does so along the line 2-8. You input for your buckler [2][2][w][a], and for your sword [6][4]. So you thrust your buckler at his face, then change its direction from straight ahead to the left. This would be a stop-block when it first connects, which quickly changes to setting the blade aside to the left, leaving you free to hack at his midsection. Yes, I see the correlation to binding with polearms in the middle, but have no idea how to bring it all together.

One further example: Up until now, all the rotations could technically be represented by one keystroke, but say I want to punch the guy with the buckler, and I want the far edge to be moving fast enough to do some real damage to the guy. (Also, say my buckler is already pointing to the left.) I would put in [a] [1] [3] [d] which tells the game I'm slashing from 1 to 3, while turning my buckler through the whole motion, which would add to the velocity of the attack, and, hopefully, the damage of the attack.

We still need to talk about the sheild proper, but that takes care of bucklers, IMO.

[Tack]

i say for both bucklers and shields we ditch the traditional shield usage and implement horizantal holding with two straps, i.e. one strap to hold the forearm to the shield, and the other strap to hold. This would also mean that the shield can pivot between two facings, forwards and sidewards, and can move up to cover the face, and down to cover the stomach.

[Footkerchief]

About the buckler control scheme -- why do you need to input both [w] and [a]?  Doesn't the buckler have a current orientation that it can use as a starting point?

Your idea about "queuing" multiple actions in a specific order is interesting.  That could apply to weapons as well, like queuing up multiple slashes or a series of punches -- you could get a slight bonus in speed, having planned out the movement in advance, but you'd be "locked into" the selected movements and your turn would take longer.

I'm still leery about the idea of wrist-level control, but if it can be done elegantly and without introducing ambiguity with regard to weapon position, I can't really oppose it.  Keeping to right angles, as you suggested, addresses both of those concerns.

If we're doing wrists, I would go a bit further and allow 5/6 orthogonal directions -- left, right, up, down, and "straight forward."  For clarity -- we're talking about orientation relative to the pivot-to-hand vector, not relative to the body per se, right?  This could be controlled by WASDX.  It would open up some very interesting possibilities, like stabbing enemies in the side or finishing off grounded enemies with a downward thrust.  It would also allow much more "natural" hilt-bashing (point sword upward, then thrust forward or slash down).  It will also allow much more careful control of stances -- you could run around with your sword held in all sorts of crazily threatening overhead guards.

Damn you for convincing me this is a good idea.  I do think, though, that wrist controls for multigrasp are still a Bad Idea, mostly because it revives the issue of "what works for a broadsword doesn't work for a quarterstaff" -- you can't rotate the weapon to point left if its butt protrudes back past yours.  But if you can come up with a way of handling it that doesn't involve directly modeling collision with the wielder's body, I"ll probably be forced to agree with you.  Again.  Our two-handed hilt-bashes still don't quite make sense, after all.

Now I need to figure out what our fancy new wrist controls mean for "active end" selection.  Perhaps the concept of an active end should only apply for multigrasped weapons, and only as the result of selecting an "active hand" to guide the weapon.

[Tack]

well, two handed swords, the hilt bash is both extremely complicated, and fun. i.e. one hand lets go, grabs other dwarf by shirt front and pulls in, the other has a sharp jab at the face.

But anyway, even a normal hilt bash should be a one handed jab, because even though the weapons may be too heavy to effectively have combat one handed, doesn't mean he cant just thrust the hilt forward, with the tip/clash-point of the sword as the pivot. Lever action demands jaw breaking action.

and no, all you need is to alternate shield and sword based combat. i.e. do not allow simultaneous use of shield and sword, but rather have it in quick succession. and with the shield, if you use the wasd keys, then you could have S, move shield downwards, D move shield upwards, A, move shield to side/disengage, W, move shield to front/shield bash.

If that were to happen you could have context based moves as well, especially if the move queuing happens. I.e. move shield to side, right-to-left slash (momentum bonus) + overextended - defence penalty. thrust, move shield to forward facing, shield bash, overhead swing.

A shield bash could be the basic shield bash, i.e. sword tip facing upwards, which would also give a momentum bonus. and could stun the enemy dwarf, but if dodged, or blocked, then would leave the attacking dwarf over-extended.

I'm just focusing on dwarf vs dwarf warfare btw, could be bothered with shield bashes to the nuts.