Jump to content

Home

Enhanced WIP: Saber System


razorace

Recommended Posts

Ok, getting started on stuff, this is what I got done right now:

 

- Teammates' Sabers now collide with each other even if friendly fire damage is turned off.

 

- Teammate NPC blades now collide with other teammate blades.

 

Yeah, it's not much but I'm just studying things at the moment.

 

The biggie I've found so far that there's no currently set up left or right block positions/animations! We have Top Left, Top, Top Right, Bottom Right, and Bottom Left but no pure left/right blocks! Ack!

Link to comment
Share on other sites

  • Replies 166
  • Created
  • Last Reply

New Features:

 

- saberthrow is now binded to button12 (+button12 for binding purposes) and/or selectable thru the force menu. Either will still operate the kicks with the saber staff.

 

- Turning off g_saberBladeFaces will result in poor viewlocking on saber impacts so don't do that.

 

- changed d_saberSPStyleDamage to 0 for the default. It was causing problems with viewlocking with idle saber damage.

 

- Viewlocking!

 

- Manual Blocking. Hold down secondary fire and use your movement keys to set a direction. The current controls are inverted (backwards for upper positions, forwards for lower) The availible positions are Lower Left, Lower Right, Upper Right,Upper Left, Top.

 

- Hilt bash should in theory work now.

 

In addition, there's now a new branch (SaberSys) specifically for the saber system I'm working on. This is so people can play with/test the system before we put it in the game proper.

Link to comment
Share on other sites

Just a minor update today. I'm hooked on Splinter Cell. :)

 

- Fixed issue with the double/dual saber animation spazing while standing still and holding block position. It was due to the block animation trying to restart each time the block position was refreshed. Since this is no longer the case, blocking will now take up less bandwidth. Yeah!

Link to comment
Share on other sites

Also, from actual game play testing I'm finding that manual blocking is still pretty tricky even with slowed down saber animations. I'm thinking that we're going to have to offset this by giving blocking some nice advantages. Maybe have parries occur automatically (with some random factor) when manual blocking is used?

Link to comment
Share on other sites

I know I'm not part of the team (just been following all of this quietly) so I begin by apologising if I offend anyone with my following words, it's not my intention.

 

Manual saber blocking, with or without slowed down saber animations will become a problem and a big gambling routine if the player trying to block has a ping higher than 100/150.

 

The system you're developing, while very interesting, is really only useful in a LAN or low ping (read: under 50/100) envirognment.

 

Slowing down is "ok" since it can give a chance to better block the incoming attacks, but high pingers will still have to predict, which instantly breaks the system.

 

I consider this manual blocking a bit like "dodges" in fighting games nowadays; you need reflexes since these dodges are (most of the time) performed at the last few ticks of the opposing attack animation right before it connects with your character.

 

What I'm trying to say is, slowing down the animations could potentially become redundant since it won't acomplish that much in a high ping situation and might make things a bit more frustrating for low pingers who would like things to be a bit faster than they will/might eventually be.

 

Player reflexes and prediction of the incoming attack would be the way things should be done in my opinion; it would reward those with good reflexes/prediction ability much like in fighting games nowadays while giving others some room for improvement.

 

Note that in this solution I'm not even mentioning ping since the animation slowdown wouldn't fix things anyway, leaving the speed the way it is should be better (IMO).

 

Another thing to note is that the Staff Kata doesn't like to be slowed down, it causes a "bump" in the animation process.

 

Just my two cents on the subject.

I once again apologise if I offended anyone.

Link to comment
Share on other sites

I don't take offense, and thanks for your input. I understand your viewpoint, but I disagree.

 

Concerning the lag issue, I'll quote what I posted in the brainstorming thread:

 

The other main arguments I hear against a block button are:

 

"It will make saber combat more lag dependant"

I dont' see this as that valid an argument. Any feature which adds more twitch-skill based gameplay to a game will make the game more lag dependant - that's inevitable and unavoidable.

If you see this as a real problem, then you will undoubedly want to start making guns auto-aim to fight lag too...

 

If you want to play a game which is unaffected by lag, then play Online Chess. Otherwise, lag is simply something that has to be endured. But I really don't think you should start limiting your game design because of it.

 

Of course lag has to be taken into account and efforts should be made to cater for it. But things are moving on. Average pings for the average online gamer are getting lower and lower as each year passes. The games have to start moving on too...

Link to comment
Share on other sites

Good point, but maybe I wasn't clear about what I was against.

 

I'm not against the block button, I'm all for it; what I said was, I'm against the animation slowdown to compensate for the lag when using the block feature, that's the "no no" in my point of view.

 

Keeping the speed the way it is while adding the block button will reward those who start adapting to their opponent style, considering slowing the attacks down won't really help much in the long run when it comes to lag prevention for the exact same reasons you mentioned.

It would be a crutch, not a solution in my opinion.

 

I apologise if I wasn't clear before.

Link to comment
Share on other sites

Ahh - k.

Sorry, I did misunderstand you - I apologise.

 

But I don't think the anim slowdowns were meant to combat lag, I think it was simply because - for example - blue attacks would simply be too quick to manually defend - unless you had literally super-human reflexes.

...so therefore, assuming we want the defender to at least have a half-decent chance of defending these attacks, the attacks have to be slowed down a bit. i.e. no attacks of blue speed, and possibly even slowing down yellow-type attacks a tad.

...I haven't had a chance to look at Razor's stuff yet - but I believe this is what he has done / is planning to do.

 

But anyway, this doesn't have anything to do with lag. This problem would still exist on a super-fast LAN...

Link to comment
Share on other sites

Good points.

 

I'll have to find a compiler and compile what Razor put in the repository regarding his Saber System so I can test it myself and further comment on it.

 

Although, if the block button is the sort of "keep it pressed and all incoming attacks are autoblocked" would make some of those points null since you could easilly block everything no matter how fast it comes at you, even a simple command could bind the block button to a toggle to spare people's fingers.

 

But I'm going ahead of myself, I'll first try to compile it and test it before I further comment about this.

 

Again, I apologise for anything and thanks for the replies.

I really want OJP to work out as much as you all do.

Link to comment
Share on other sites

Why add a button to autoblock if there's no advantage to selectively autoblock in the first place? All you would be doing is just holding the button down all the time. That's not exactly an increase in the dynamics of the gameplay.

 

As for lag issues, I don't think it's much of a problem because the game becomes unplayable at about 150 ping anyway.

Link to comment
Share on other sites

Originally posted by razorace

Why add a button to autoblock if there's no advantage to selectively autoblock in the first place? All you would be doing is just holding the button down all the time. That's not exactly an increase in the dynamics of the gameplay.

 

That's exactly what I said if you read carefully.

I'll rephrase: I said there's no point in slowing it down if the block button can work like an autoblock; then I proceeded to say it was a mere guess since I don't know how the block button is implemented and had to try it out first to be sure, it was a mere hypothesis.

 

I apologise if you felt insulted by what I said, it wasn't my intention.

Link to comment
Share on other sites

Has anyone actually tried the system or am I just wasting time by having the saber system be a seperate branch on the Enhanced distro?

 

If noone actually wants to check it out on the repository, things would be better served if I just merged everything into the Enhanced branch and then allowed people to betatest with the Enhanced releases.

 

Anyway, I'm to the point where I'm starting to need to make some serious design issues. The primary issue is how we should handle damage calculations and how the saber should act in saber on saber combat. (when should damage occur, when should knockbacks and dropped sabers happen, etc).

Link to comment
Share on other sites

I've tried the new saber system. It's definetly worth keeping it in a seperate branch - for now...

 

It's looking good so far. The first thing I'm gonna do though is slow down movement while holding down block. Not only does it look a bit silly imo atm, it's also very difficult to actually try and use or appreciate this cool new blocking system while both Jedi are still constantly running around like madmen.

 

If your worried about saber v guns balance because of this change - I know how to get round these kinds of issues. I've learnt a lot from working on MB about how to handle this..

 

Anyway, don't worry - I won't submit anything to the repository just yet. Instead I'll send you the occasional .pk3 demo and see what you think of my changes...

Link to comment
Share on other sites

I don't think that's a good idea. Slowing down defender while he is blocking is only going to cause him to get overrun/trapped by an attacker.

 

However, I agree that the this constant running is a problem. I have some ideas on how to balance it:

 

1. Cause running characters to take full attack damage from an idle saber (by adding his velocity to damage calculations?) Running onto someone's sword/saber is very bad. This is also how I think the melee combat can be balanced.

 

2. Cause running to vastly increase your chances of getting knocked off balance (knockdowns or knockback parries).

 

3. Increase the walk speed to more of a combat walk and majorly slow down the backward run speeds and the pure run strafe speeds.

Link to comment
Share on other sites

I don't think that's a good idea. Slowing down defender while he is blocking is only going to cause him to get overrun/trapped by an attacker.

 

I don't know where you are coming from with this at all. I think you are creating a problem where there is none..

 

Slowing down movement while blocking will not cause the defender to be overrun or trapped . What it WILL do is make your blocking system useful and useable - since you will actually be able to see where the strike is coming from and where to block it...

Link to comment
Share on other sites

I think we should make walking on by default. And possibly make running a stamina issue (You've all talked about stamina). We should also lower the strafe speed.

 

BTW, sorry for not being around, I've been working and I've had no chance to do any coding. I've talked to the freepository guy and the reason I can get access to our CVS via TortoiseCVS is because he disable remote access (or something like that). He might have a solution but he hasn't emailed me in a while. I still intend to add my work to your Enhanced version of OJP when I get that chance.

Link to comment
Share on other sites

Originally posted by RenegadeOfPhunk

I don't know where you are coming from with this at all. I think you are creating a problem where there is none..

 

Slowing down movement while blocking will not cause the defender to be overrun or trapped . What it WILL do is make your blocking system useful and useable - since you will actually be able to see where the strike is coming from and where to block it...

 

And how so? If the defender even moves slightly slower than the attacker, the attacker will be able to have a clear advantage at footwork manveoring and the attacks will still come at the exact same speed. Are you sure you don't mean making the attacker move slower?

 

I still intend to add my work to your Enhanced version of OJP when I get that chance.

 

That's great. :) I was a bit worried when you suddenly disappeared. Have you talked to TCK yet about the RGB saber stuff?

Link to comment
Share on other sites

And how so? If the defender even moves slightly slower than the attacker, the attacker will be able to have a clear advantage at footwork manveoring and the attacks will still come at the exact same speed. Are you sure you don't mean making the attacker move slower?

 

Ok, I guess I am making an assumption here.

I'm assuming that the plan is that when not holding the block button, you will not actively block incoming saber attacks (regardless of whether your saber happens to be in the right place or not. (This is easiely rationalised - if your not braced to block an attack, you saber is relatively easiely knocked aside...).

 

If this isn't the plan, then sure, you'd be correct in the attacker having too much of an advantage.

...but, if the attacker hasn't got a proper blocking ability, then constantly running around taking random swipes will leave you dead VERY quickly -regardless of difference in speed.

i.e. both players will need to make appropiate use of block. One may go on the attack more than the other, but not blocking at all will almost certainly lead to a quick decapitation...

 

..and anyway, you've said yourself that you want to encourage to not run during duels. So basically, you expect the player to use the walk button AND the block button at the same time (or if the player does not run by default, they'll have to hold down the walk / run button to run anywhere..), when there is actually no need to have to use two different buttons. The block button can do both, ending up with a simpler, more consise system...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...