editing the combat system

[shaowei]

Hi,

 

I do not know Radiant, Q3 and I am not a programmer (work in marketing). On my free time I like to play games and I am interested in how to make better melee FPSes. Here is my newbish question then:)

 

>

To change lighsaber combat aspects like it is done in Promod (actually, more radical stuff), what resources and knowledge would I need?

>

 

I am not interested in mapping (environments) that much, more in editing things like how moves are initiated and how blocking and striking acts.

 

For example, to add more hitboxes to the character model (head, torso, legs etc), do I need to learn C++ or smth?

 

I need direction badly:) Please help me out.

[Ockniel]

sounds to what you need is a new game, lol:) OK I am a mapper not a "modder" so Im not sure but maybe you need GMAX and make completely new models.

but don't take my word as law here cause remember, I don't mod, I map.

[shaowei]

Thanks for your reply! Yes, I would like to play a new game, and I sincerely doubt they are going to make one that matches my expectations:)

I looked around the web yesterday and yes, I am gonna need C, and after that there are tutorials on Q3 modding. Maybe that won't be enough to make things like adding hitboxes, but I will definitely know where to turn to after that.

hello world:)

[Emon]

JO doesn't use hitboxes. Well, at least it does in SP, MP may be different. But you should be able to take advantage of the GHOUL2 system to put surface collision back in (razorace did this for some mod, dunno if he finished), and JO already has support for locational damage.

[shaowei]

Emon,

thanks for clarifying. How does blocking work (conceptually) in JO? Being an amateur I thought it had to be a hitbox with special properties (when lightsaber enters the "blocking hitbox", a blocking animation is played and damage nulified). Now that you say there are no hitboxes I don't know:)

[Lil Killa]

This should be in General editing......

 

 

*runs off to a mod*

[razorace]

Originally posted by gedassan

Emon,

thanks for clarifying. How does blocking work (conceptually) in JO? Being an amateur I thought it had to be a hitbox with special properties (when lightsaber enters the "blocking hitbox", a blocking animation is played and damage nulified). Now that you say there are no hitboxes I don't know:)

 

I have arrived.

 

Anyway, the default hit system for JO is pretty simple. It basically takes the impact point on a very large box around the player (the bounding box) and calculates it into a "hit location". However, it is very basic and doesn't account for the actual positions of the "hit locations" on the current player mod. IE you shoot and hit the "head" by aiming where the head is while standing even when the player's head is tucked in for a roll or other activity.

 

I spent a lot of time fixing it (for my mod MotF) by using Ghoul2 to calculate hitzones based on the surface area hit on the player model. It works pretty good actually.

 

As for saber blocking, it's two parted:

 

Bolt blocking is controlled by a simple vector check (is the attack in my "view"?) and a random number generator check on bolts that hit your player's bounding box.

 

Saber on Saber is a bit more complicated. You block saber attacks when the saber attack scan (which is a box trace that is sent thru the space the saber "occupies" several times per "server frame" when the saber is active.) hits:

 

1. The Saber Entity Bounding Box - an invisible big box that represents the saber's defensive area in the game world)

 

2. The Player Model - A Ghoul2 (per polygon-based) trace is used for this. Please note that the player must make a successful saber block check (another random number generator controlled by the player stats) to block in this situation. Otherwise, the player takes damage.

 

I did quite a bit of work on the subject. You might want to check out MotF to see a buggy version of what I was doing.

 

I understand that this is pretty confusing to new people so feel free to ask more questions.

[shaowei]

razorace, impressive knowledge you do have. If I may ask, was it gained by analyzing the source code of JO and comparing to gameplay? Or are there good online resources to be read before asking more newb questions?

 

For now I am feeling free with the questions as you said, here goes:

 

1. “Saber attack scan” – what kind of geometry does it have? Is it also something like a “saber bounding box”, but really tight around the saber?

2. Is the “server frame” a really short period of time?

3. Following from the above: by saber being active, you are saying that the player is pressing “attack”, right? Then some kind of “saber passive scan” (saber ignited but not attacking) also has to be run. Assuming that, is the “saber passive scan” run less frequently (less times per server frame) than the “saber attack scan”? (because it has the frequency of ~ 5 damage per second on an unarmed opponent, while many attacks don't even last a second)

4. Does the “saber attack scan” frequency have anything to do with saber attacks sometimes not connecting, even though in-game it looks as if the saber passed through the opponent? Meaning, can the saber pass the player bounding box fast enough to miss the saber attack scan? Was that ever a problem in JO standard multiplayer game?

5. What hardware resources are used when increasing saber attack scan frequency? Main processor, I believe?

 

Ok enough questions for now:). I am aware of the fact that I cannot learn everything by simply asking questions here, but you guys are making the search for info easier for me. Thanks.

[razorace]

Originally posted by gedassan

razorace, impressive knowledge you do have. If I may ask, was it gained by analyzing the source code of JO and comparing to gameplay? Or are there good online resources to be read before asking more newb questions?

Thanks. Most of it was from checking the code out. The rest you can get from code3arena (your coding god), Quake 3 Syscalls, and A Complete Rundown of the Server Side Game Logic. Please note that all those sites are for Quake 3 (Q3). JK2 is based on the Q3 engine so most of the stuff used for Q3 still applies.

 

For JK2 specific data, you can try scanning thru this board (everything that has been discussed publicly is here) or check out Wudan's JK2 coding site. However, remember that very little of JK2 is actually documented on paper. Most of the important stuff is stored in the brains of the Power Coders, either at Raven or in the modding community.

 

1. “Saber attack scan” – what kind of geometry does it have? Is it also something like a “saber bounding box”, but really tight around the saber?

It's a small square box about the width of the blade. To do a saber attack scan, this virtual box is basically "launched" (or "traced") thru the space occupied by the blade until it impacts something or reaches the end of the blade. Since this occurred between game world updates (IE no game time passes during the travel time of the square) the trace is effectively simulates the blade.

2. Is the “server frame” a really short period of time?

Yes, the the server frames are defaulted to occur 20 times per sec. While this is very fast, there are some issues if you try to do something that needs to be updated even faster than that. For example, @ 20fps, blade collision scans don't update fast enough to allow really accurate blade-on-blade impacts (since blades travel thru space very quickly).

3. Following from the above: by saber being active, you are saying that the player is pressing “attack”, right? Then some kind of “saber passive scan” (saber ignited but not attacking) also has to be run. Assuming that, is the “saber passive scan” run less frequently (less times per server frame) than the “saber attack scan”? (because it has the frequency of ~ 5 damage per second on an unarmed opponent, while many attacks don't even last a second)

I meant active as in "turned on". The saber attack scans happen whenever the blade is turned on. This is done so idle saber damage can be calculated. However, you are partially correct. While the saber attack scans happen at the same rate for actual attacks and for idle saber damage, the damage "debounce" is different. A "debounce" is the amount of time before an action can reoccur. In this case, the I believe the debounce for idle saber damage is longer than the saber swing damage debounce.

4. Does the “saber attack scan” frequency have anything to do with saber attacks sometimes not connecting, even though in-game it looks as if the saber passed through the opponent? Meaning, can the saber pass the player bounding box fast enough to miss the saber attack scan? Was that ever a problem in JO standard multiplayer game?

Yes and yes. That's why it's critical for the saber attack scans to be done as often as possible. I've already experimented at length with it. You can boost the server fps with the "sv_fps" command but it does increase the CPU horsepower requirements and there are sideeffects (the game wasn't set up for anything other than 20 fps for the server side). Namely, the computer AI becomes unstoppable in saberlocks and there might be some networking issues. It's all fixable, of course, but of the issues might internal engine stuff (we don't have access to that code)

 

However, the ideal situation (which we can't do) would be to seperate the saber hit detection from the other server frame code and make it update at a much fast fps, say 60 fps. This is what is most engines do for stuff that requires more percision, like tires on a car, but JK2 doesn't do that.

5. What hardware resources are used when increasing saber attack scan frequency? Main processor, I believe?

CPU and some RAM I suppose. According to Raven, the Ghoul2 scans used to do the saber attack scans are very CPU intensive. While I believe them, I was able to use Ghoul2 trace scans for basically everything and my game performance wasn't visually affected by the increased load. Thank god for the ghz class CPUs.

 

And no worries. It's actually fun to answer reasonable/thoughtful questions. I'm impressed, you seem to understand a lot for a dude without programming experience. I was way more clueless at that stage.

 

Now, I have a question. Why are you interested in this information? Are you interested in improving the saber gameplay? I'm in the same boat if you are.

 

And, before you ask, the reason why I'm not actively working on it anymore because of some hardcore engine limitations that blocked my progress. To really improve the saber combat, I needed to have a way to control animation positions/speeds dynamically (for dynamic saber locks and other stuff). Unfortunately, my rewrite of the animation system can't work without a few more data slots for the player entities and we simply don't have access to the code nessicary to add more data slots.

 

However, I've been told by Raven that is issue has been fixed in JKA. It's very likely that I'll continue my work then.

[shaowei]

>>

Now, I have a question. Why are you interested in this information? Are you interested in improving the saber gameplay? I'm in the same boat if you are.

>>

I guess, ahoi then, although I might be in that little boat where it says "no programming knowledge":) I am interested in improving the saber gameplay.

I have many ideas on paper (gameplay, move initiation), but without being able to check how they would work in-game they remain just that:) That's why I started to also think how the programmers would go about implementing them and here I am, asking questions. It would be fun to test the ideas in practice, but for that I will be doing the C++ tutorials at http://www.cprogramming.com/tutorial.html first I guess:) And it would be fun to follow the progress of your work when you pick it up again.

 

_________________________

My motivation

Having done martial arts before, I love the Virtua Fighter line of games combat (melee, combos, variations, balance) and I like the immersive feel of FPSes. To combine those aspects, plus add combat against multiple opponents in one game would be a dream come true.

JK and JK2 were among the best FPSes with melee combat (yes I have heard of Severance, but unfortunately did not have the opportunity to see it), I like Star Wars. I have thoughts of joining the industry to ultimately get to design games.

 

Some features that I believe would add depth and immersion into pure saber combat would be:

- no bots running backwards (thus reduce movement speed backwards - has been done)

- not being able to change movement/strike direction when executing a strike (would look and feel more powerful, while allowing for simultaneous counterattacks)

- combos of three strikes with a cooldown period to allow for interception

- blocking four strikes in a row results in the defending blade knocked away

- possible location damage to the head (1hit kill), arms (slowed down attack), legs (slowed down movement and turning)

- special moves initiated depending on where on the enemy body you are aiming

- two blocking positions (horizontal, vertical)

 

I guess most of that would require slowing down the movement in the game (or relatively speeding up the actions).

etc etc

________________________

[razorace]

- not being able to change movement/strike direction when executing a strike (would look and feel more powerful, while allowing for simultaneous counterattacks)

Interesting, I had been considering doing something about the foot movement during saber combat but not actually locking it. But how is that justified? Don't most sword combat styles allow for dynamic footwork? As for gameplay terms, wouldn't there be issues with the defender always outrunning the attacker? Personally, I was thinking more alongs the lines of a accuracy/power relationship. IE, swinging better with less chance of a defense breaking counter when moving slower. Meaning you could still attack while running (like Mace in E2) but your combat skills would be reduced.

- combos of three strikes with a cooldown period to allow for interception

- blocking four strikes in a row results in the defending blade knocked away

Personally, I'm more in favor of experimenting with a more realistic action->reaction system (he attacks to my left, I attempt to block left, he bounces into a right roundhouse, I block right, etc) than a combo system but combos are still fun.

 

- possible location damage to the head (1hit kill), arms (slowed down attack), legs (slowed down movement and turning)

No arguements there, but remember that aiming with the current saber control system is tricky. It's possible, but it's mainly of the "breaking left/right and roundhousing his head off" variety.

- special moves initiated depending on where on the enemy body you are aiming

Explain please.

- two blocking positions (horizontal, vertical)

*Shrug* I've been build my concept on a 4 (or 8) position defensive system. I figure if Mouse Sabering is going to give you that level of control, you might as well use it.

 

I guess most of that would require slowing down the movement in the game (or relatively speeding up the actions).

etc etc

Maybe, I think it's the sort of something you gotta playtest to be sure. You never know, it might be so slow. Seriously, as far as I got in my testing, %50 normal speed the saber attacks seems to be fast AND still blockable.

 

Well, I'm interested in any other ideas you got, if you don't mind share ideas of course. Are you on a IM service so we can chat about it sometime? PM your address if you want to. I'm basically on all of them with trillian. Maybe we could do some sort of melee weapon mod together.

[shaowei]

"special moves initiated depending on where on the enemy body you are aiming": (pretty long)

 

Special moves - "scripted attacks"?

(assuming it is possible to change existing controls) the character bounding box could have areas defining arm, leg and head areas, which, when aimed at with your crosshair (+ pressing LMB/RMB for direction) would initiate a move aimed at the central part of the bounding box area; the move would aim for the place where it is at the moment of strike initiation.

The main feature here was to make move initiation easier, not having to run forward/backward to make a slash you wanted.

 

The problem with such a system is that it eliminates the JO standard "anticipation" (generic, probing) attacks against flying/rolling/strafing opponents (you don't have to aim to slash).

 

To keep this nice anticipation aspect of the game I thought that certain "anticipation" attacks (horizontal and vertical) could be left, but they would have a weakness: if blocked while standing, the attacking saber would be knocked away ("parried", let's call it), temporarily shutting off the "saber defense bounding box" giving the initiative to the defender.

 

Trying to block a "comitted" attack would result in the defending saber knocked away, giving the attacker a time window for striking (if you don't move out of danger).

 

So players would be encouraged to make "comitted" attacks against standing opponents and "anticipation" (probing) attacks against moving opponents. Defense against "comitted" attacks would be dodging, while defense against "anticipation" attacks would be blocking (with in-built auto parrying).

 

That way there would be no best defense and no best offense. You can't always stay and block, but if you move, you are subject to the "anticipation" attacks.

 

Have committed strikes come with a certain characteristic "force = 100", idle saber "force = 50" and probing saber "force = 20". Since force = 100>force = 50, the block is knocked away; force = 20<force = 50, the attack is knocked away.

 

That is what I meant. It kind of makes the combo system obsolete, because it already takes care of "standing and blocking forever".

________________________________________________

With mouse sabering, do you mean the ability to simultaneously mouselook and strike?

Even so, what would be the 4-8 blocking positions (if that is a shareware idea:))?

I was charting a bit and came to an interesting conclusion - simply positioning a horizontal saber against vertical slashes at the right height (or analogically, the vertical saber against horizontal slashes) would mean that you could perhaps leave the blocking solely to collision detection (don't need the saber defense bounding box). Blocking would require just positioning you saber between you and the incoming saber (the sabers do have collision boxes, right?).

 

Am I expressing myself clearly here? If not, I can try and put it down in Word with pictures and stuff:)

[razorace]

I like a lot of those concepts. Especially the "aimmed strike" control system.

With mouse sabering, do you mean the ability to simultaneously mouselook and strike?

Yeah, basically. What you do is move the mouse around while either holding down the attack to select the type of move you want. For example, to make a light swing to the left, move your mouse slightly to the left while holding down the attack button.

Even so, what would be the 4-8 blocking positions (if that is a shareware idea)?

I was charting a bit and came to an interesting conclusion - simply positioning a horizontal saber against vertical slashes at the right height (or analogically, the vertical saber against horizontal slashes) would mean that you could perhaps leave the blocking solely to collision detection (don't need the saber defense bounding box). Blocking would require just positioning you saber between you and the incoming saber (the sabers do have collision boxes, right?).

Right, that's basically the plan. However, to make it so you can continue to fight when you miss a block, your player would automatically correct for the error and lose some fatigue. This would translate into longer saber fights with realistic damage (basically one hit kills) and mean that very good players could fight for a long time.

[shaowei]

Originally posted by razorace

Right, that's basically the plan. However, to make it so you can continue to fight when you miss a block, your player would automatically correct for the error and lose some fatigue. This would translate into longer saber fights with realistic damage (basically one hit kills) and mean that very good players could fight for a long time.

 

Sounds like a good plan.

 

Automatically correcting for the error would probably be: when the saber bypassses the block and collides with the player character bounding box, the saber is brought to the right position.

 

Fatigue, then, would be what? Are you thinking in this direction:

1. There would be a set number of errors allowed during a time period (1 minute, would have to be tested); the critical time period would be reset after the character runs out of fatigue, or does not attack/autocorrect errors for 5 seconds.

2. After each automatic error correction, the character could be getting slower in attack and movement (I guess it is possible to count those events and bind some character properties to that) ~ just a bonus idea.

3. After a set number of automatic error corrections (during 1 minute), the player character bounding box would loose it's defensive properties, and let through the death blow?

 

___________________________

Mouse sabering sounds like it could be the ultimate fun, but would it be possible (for the modder) to bind certain current animations to the mouse moves?

[razorace]

Automatically correcting for the error would probably be: when the saber bypassses the block and collides with the player character bounding box, the saber is brought to the right position.

Something like that, yeah.

Fatigue, then, would be what? Are you thinking in this direction:

1. There would be a set number of errors allowed during a time period (1 minute, would have to be tested); the critical time period would be reset after the character runs out of fatigue, or does not attack/autocorrect errors for 5 seconds.

2. After each automatic error correction, the character could be getting slower in attack and movement (I guess it is possible to count those events and bind some character properties to that) ~ just a bonus idea.

3. After a set number of automatic error corrections (during 1 minute), the player character bounding box would loose it's defensive properties, and let through the death blow?

Well, the current concept involved a rechargable fatigue meter that depletes when you get hit or do tiring moves. There was some discussion about what to do as the player gets tired. Your slower attacking/blocking idea is good. But I'd say that you'd have to have depleted your fatigue to some degree (say 50%) before you'd start to see ability reductions. It's more realistic that way and it would prevent a possible "Whoever got the first "hit" in wins" situation.

 

Mouse sabering sounds like it could be the ultimate fun, but would it be possible (for the modder) to bind certain current animations to the mouse moves?

In the way I'm thinking, yes. In fact, I already did a early prototype for MotF some time ago.

 

However, the way I'm thinking of doing it isn't a direct mouse to blade control. That has tried before and it didn't really work. Unfortunately, the amount of space a tip of a blade has to travel makes it challenging to make such a system both accurate (like fencing) and without too big of mouse swing (for power attacks).

 

Instead of that, Mouse Sabering selects the approprate move from the traditional selection of saber moves. IE, you're just using the mouse to select moves instead of using the keyboard (like normal JK2). This frees up the keyboard keys for exclusive foot movement while allowing the mouse to do both mouselook and saber attack control. Plus, this adds rythm / "comboing" to the combat by naturally places your viewpoint in the current stop point for the saber. Swing left and your view naturally ends up left of your target due to the Mouse Saber command.

[KaiaSowapit]

I'm a complete layman in terms of coding, so please forgive any ignorance I'm demonstrating in posting here. I'm curious about a couple issues however, and if anyone would be kind enough to indulge me I'd be greatful.

 

Hitzones - they are presumably body part or region specific? In other words, torso, head, right leg, left arm, etc.?

 

If so, would it be possible to design a mod wherein players could specify and perhaps even lock their attacks to specific body regions. Eg: player A focuses his crosshair on player B's abdomen and clicks a button - now all player A's subsequent attacks will be focused specifically on player B's torso.

 

If body part/region specific targeting isn't possible (or practical) what about the possibility of assigning a lock to a specific opponent? (Similar to Merr Sonn locking, except for other weapons like sabers.)

 

In particular this could be useful in balancing gameplay with players of varying scale (Yoda for example). I believe it also could be interesting if it granted a certain degree of freedom in POV - allowing combatants to still scan their surroundings for additional threats while engaging in PvP combat.

 

Of course care would have to be given in how it was implemented so as not to give an unskilled player an advantage over a well-seasoned veteran. A lock should not assure or guarantee a successful strike.

 

Lastly, there was some brief mention in this thread regarding slowing down movement, speed or perhaps time. On occasion I've found a slight (0.65-0.75) alteration of timescale to be quite enjoyable, in SP and local MP games. Saber duels especially tend to take on a more dramatic, movie-like quality when slightly slowed down.

 

Unfortunately trying to reproduce this effect on an online server appears to have a very negative side-effect: motion stutters and staggers in a way similar to lag or packet-loss issues. Upon suggestion, I attempted to use g_synchronousClients to smooth out the motion, however this only made matters worse.

 

Is there a trick to the successful enabling of reduced timescale on an online server, or is it simply a lost cause?

[shaowei]

>KaiaSowapit

If it is possible to script moves by making a "character bounding box" area + player aim (crosshair) match = the condition, and then a mouse button = execution, "locking" should be possible.

 

Locking on a body part

Basically, what I described was a kind of "locking" - launch the attack towards the place where the aim is (depending on whether it is head/arm/leg, different attacks would be issued); however after the attack is launched, I think it should commit to that direction and not follow the opponent dynamically, allowing a dodge counter. The idea is to issue a special attack depending on where you are aiming, that's it.

 

Locking on an opponent

Totally locking on an opponent would probably be more bad than good in a multiplayer fight, since the specific enemy could evade all the time, while his buddy slashes the single-minded, determined terminator-padawan:)

 

I personally did not particularly like combat locking on an opponent in NWN, it prevents free movement, and is not active unlike all FPSes/fighters (meaning you don't have to aim).

 

>razorace

I agree about the fatigue feature, if there are penalties, these should not active at once (maybe at 50%), so as not to give an overwhelming lead to the guy who hits first.

 

Mouse sabering rules.

[KaiaSowapit]

Okay, scrap all that (well 'cept for timescale, I'd still really like to get that to work decently ).

 

How 'bout a handicapping system for differences in ping?

 

In my experience, a player with a ping of 50 has a tremendous advantage over players with a ping of 200+ regardless of skill. The more sophisticated you get with saber combat, the more I fear this will become an issue.

[shaowei]

Tell me about it. We have pretty good dsl lines inside Lithuania (where everybody and their brother plays CS and no JK),

and really bad connections to international servers unless you are a business client or a dude willing to pay your average salary each month just for connection.

People can still have fun on LANs and guys with good connections can enjoy it all. Or play against bots:)

 

Your idea of a handicapping system for those with good connections woudl impose a balance of sorts; I am just more interested in how saber combat could be made cooler than it is and not looking that much at connection issues.

 

About timescale - medium style moves in JK2 v.1.00 offer a nice pace I think. I wanted to slow down movement relative to combat actions: if a player commits to a direction with a rather slow swing, the enemy has an overwhelming countering potential bu just moving to the side and slashing. Other than that, I don't see a need for slowing everything. Running around to meet bots gets long enough as it is already:)

[razorace]

Well, it is possible to do code changes to make the animations, gameplay, etc play at different speeds but it's nothing as easy as changing the timescale. Sorry, it's just a general issue with the game engine.

 

A handicapping system based on ping, eh? That's an interesting idea. However, I'd be concerned that it would be abused. Ping varies so much that you'd either have to check it at respawn (which would be way too easy to cheat at. People would lag their game on respawn to get the handicap) or constantly monitor the average ping for each player (doable). Maybe a handicap based on score would be more efficient. Either way, it's something to keep in mind.

 

I'm for having some sort of targeting assist to use with Mouse Saber so people can use it if they want to. Probably something simple like ztargeting (like in Zelda 64) with a little "slop" to allow the player to use Mouse Sabering. It would free up the controls so the player would only have to worry about foot work (with the keyboard) and saber control (with the mouse) while in melee combat. Obviously we'd have to keep a tight lid on what the targeting can and can not do (like not being able to track people behind walls and such).