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!
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.
...sounding great Razor :)
...I'm looking forward to checking this stuff out...
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!
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?
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.
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...
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.
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...
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.
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.
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.
Nah, not insulted. :)
And if you look above, it's NOT a simple "hold for manual block" button. It's a directional block. You use the button to set and hold a blocking position instead of just activating a manual block.
Oh, right, I missed that. o_O
I apologise, my mistake.
*slaps own forehead for that*
- Fixed the animation timer code so that saber animation speeds other than 1.0 work correctly.
- Added Movement locking.
It's shaping up nicely now. You can just feel the potential starting to show. :)
- Sabers now bounces off players (and other damageable objects) when the saber does non-lethal damage. Layman translation: NO MORE GROSS SABER PASSTHRU.
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).
I'm making all my changes using it. Since my stuff is so directly tied to yours.
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...
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.
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...
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.
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?
Originally posted by razorace
Have you talked to TCK yet about the RGB saber stuff?
Not yet. Like I said I've been horribly busy.
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...
Some thoughts.
seven directional blocking:
I think this may be a bit much. In the heat of battle I have problems choosing which way is the best block. Having just left/right would narrow it down a lot bit. Then have the code choose which one to use from there. Up/down/diagonal. And slowing down the transition from direction to direction would give it a better feel.
I see you slowed down swings.
The slow down is disproportionate. Evening them out would be better. Also, crouch+forward attack, jump+forward attack, and specials are unchanged. I'm sure you'll get around to it but I thought I'd point it out. ;) Also it may be a bit too slow. Even on blue.
Excuse me... but i think both of are are missing a very important point... attaking should keep you from running as well.
You see jedi running and attacking? Sure you see, if it's a quick side swiipe to quickly finish off non saber users like the battle droids, but on a duel they will run up, indeed make a slash as they approach but then everything is just a bit of leg work and not running.
If the attacker is allowed to run and the defender isn't.. then you got an almost stationary target with a hammering oppoenent straf running around in and out of it.
On the other hand if both are allowed to run, then things wont be much diferent that they are now.
That said, you code boys do as your hearts tell you to. ;)
Cheers all.
I think that was a given. :)
Run and strafing need to be limited in some way. Like a sprint button or stamina. ;)
If the attacker is allowed to run and the defender isn't.. then you got an almost stationary target with a hammering oppoenent straf running around in and out of it.
If you've played Movie Battles recently, you'd know this isn't the case. With blocking ability significantly enhanced over any blocking ability you have when running, straf running around in and out isn't an effective tactic - at all - period. You quickly die.
To have a decent chance, BOTH players need to block, and attack each-other from close range, trying to find a gap in the others defenses. With directional blocking, this gameplay dynamic will be enhanced all the more.
I don't need to discuss this in a theoretical manner - I know this is the case.
...but in anycase, Razor is free to do as he likes for the OJP system, and I'll be modifying it somewhat for MB...
Yes but you also incorporated a sprint button did you not?
One where you have to rest an equal amount of time once let go.
Well, before I talk about sprint, it's worth saying that I'm not sure whether I will be including the sprint button into MB II anymore. I'm thinking about it at the moment.
But anyway, yes - the sprint button allows you to defend and run (slower than normal run btw) for a few seconds, then you have to rest. In MBII, this would mean you can't attack, only defend.
...so it's a viable tactic if you want to use it, but it has serious drawbacks - it gives your enemy several seconds of time where he knows you can't counter-attack OR run anywhere (even if he let's go of block), and they REALLY CAN pound on you without fear of getting hurt themsevles.
As I say though, might not be in anwyay.
I don't really think an additional run button is nessicary. I think it would be easier on players to just use run as if it is sprint.
Assuming that you can automatically deflect bolts at lesser rate while running and that you can Dodge the undeflected ones, you should be able to run down gunners without too many problems.
Yeap - I think I agree...
I'm leaning more and more towards not including the sprint button into MB II
I also agree... also with Stamina... normal run WILL work as a bit of a sprint as well.
maybe its just my game or is the sabers going at like the slowest speed imaginable, it takes about 3-5 seconds for a swing to finish, please make the block auto block, i understand that there will be less skill involved for that happening, but slowing down the sabers to a minute crawl isnt the answer, maybe its just me, but if the sabers are supposed to attack for 5 seconds then please change, otherwise tell me what i must do to fix the problem.
Adjust g_saberanimspeed
1 is the game's default but I'd adjust it .75
I think razor has it set to .25 for testing purposes.
Well, I originally set it to .25 because I figured that novices would need that sort of speed to be comfortable doing manual blocking. However, it turns out that it's pretty easy to manually block with .5 so I have changed the default to .5 for the next beta release.
i think that directional blocking should be changed to some degree, sometimes its somewhat difficult to actually determine which attack your opponent is using all the time. the block button should auto block and doing the right direction with the block should grant you a parry. blcoking aganst duals and staffs will be a little tricky otherwise. id also like to test the system with another person, if anyone is up for it tell me.
yep, left/right and up should do fine. the diagonals need to go.
But then I'd definately put in the feint attack you were talking about to even it back up on the side of skill versus arcade.
I basically agree but unfortunately, those are the only parry/block animations we have. If we ever get to the point of creating new animations, there's a LOT of stuff that could be done to enhance the saber system.
There's already an autoblock system set up, it just doesn't work very well yet. I think I need to increase the number of situations where it works. Unfortunately, I haven't been able to come up with a thought process on how exactly I'll get the autoblocking to drain points from the dodge system.
In addition, how much should it cost in terms of dodge? I think it should definitely cost less than the body dodges since you have to be not attacking to autoblock.
Secondly, I'm pretty sure that autoblocking should be automatic as long as you're not attacking or doing something special. it's much easier that way and then we don't have to have seperate autoblock and manual block buttons.
Are you planning on doing a one-or-the-other kind of thing with the auto-parries when the button is down and actual manual blocking, or are you planning on doing a combination of the system? Personally, I like manual blocking better than the system with the v.b4 where it's pretty much a "hold-down-the-button and you'll be fine" deal. I know it doesn't get the parry bonus after one second, but it doesn't seem to matter very much.
Having to manually block (a) looked cooler, (b) was actually more skill-requiring, and (c) was actually more fun to play with. How are you planning on breaking it up? Don't get me wrong, I'll like it either way, but I think it takes a lot less skill with the almost automatic system of blocking in the parries...
Also, are there further things that are coming as far as the "bouncing off instead of gross passthru" code, b/c unless it's only my and Soruss' PC's, we're still having that problem (at least I think it's him).
in my opinion, Autoblocking should only work when idle or walking/running. It should consume less dodge yes.
It should work on all types of weapons (ranged and saber) in all situations. i'd limit it's effectiveness to make people not rely on it fully. Like Idle = 90% defense while there is enough dodge points, Walking = 75% and running =50% for instance.
I'd definetly keep it as a safeguard NOT as an active autobloking defense that can last quite a while.
The problem with the automatic autoblock was that it screwed up your ability to attack effectively.
Also, I'm trying to make blocking skill based, not just some random chance.
The problem with the automatic autoblock was that it screwed up your ability to attack effectively.
Also, I'm trying to make blocking skill based, not just some random chance.
Maybe some way to reduce the autoblock probability is all I can think of. I personally think the parry working as an autoblock button requires considerably less skill than the manual blocking did. What if you made is so that the autoparry was only enabled for projectile weapons that you couldn't manually block in time?
Another question for you: what are you planning on doing with the specials/katas?
My suggestion would be to leave them exactly as they are except for two points. First, (and this really clears up the second one) make the probability of dropped sabers with them way higher, just as it would be in real life doing that kind of move. Second, get rid of the view locking. Since there's a higher probability of dropping it, it balances this out and makes it worthwhile to use.
Maybe some way to reduce the autoblock probability is all I can think of. I personally think the parry working as an autoblock button requires considerably less skill than the manual blocking did. What if you made is so that the autoparry was only enabled for projectile weapons that you couldn't manually block in time?
Well, the main problem is that almost everyone that has play tested the mod wants to play with the saber animation speed up near normal base jka speed. At anything remotely that fast, manual blocking becomes too difficult.
Another question for you: what are you planning on doing with the specials/katas?
So far, I've removed the katas (will possibly re-add them later) and will replace their button combo (primary + secondary) with a counter attack system.
The idea being that you can parry an opponent into a knockaway and then use a counter attack on them to either knock them off their feet or knock them away so you can engage another target.
Ah. Okay. See, personally, I found that having it at about .75 worked well even with the manual blocking, but there's not much way at full speed to use it, obviously. That's too bad; I think it required a great deal more skill and ability; certainly one had to modify one's tactics more from JA base...
I like the counterattack idea; I look forward to getting to play with that at some point in the future. I'll be interested to see what you do with the katas if and when you put them back in.
Well... after talking to razor i've been meaning to do some testing of my own. I just didn't find the time (or enough hard disk space to re-install JA for that matter).
But I will, and I'll probably be more helpful after that. I could dish out several opinions...but they would all be conjecture and theories, while most of you already have the feel of what OJP is really like right now.
One thing is for certain tho, If manual blocking can be done with some practice but not requiring an elite powergammer to be able to manage in a fight... then autoblocking should be kept to a minimum... since it seems likely that it will only serve to drag a fight and cause more trouble than it's porbably worth.
The only real doubt I have is how does one block blaster fire? This is probably the only type of autoblocking I find worthy of implementing.
I've been a lil out of the community so plz bear with me if i'm way behind on the subject.
Cheers
Ok, well, I just came up with an idea that might make manual blocking more managable.
What if we made the manual blocking based on simple up/down left right quadrants? Basically instead of having to handle the 8+ quadrants of the current system, you'd have to worry about 4 positions. From there, the autoblock system would pick the correct quadrant from the availible quadrants.
If you do it correctly, you'll parry the attack. If not, you'll take a fatigue or dodge hit and simply block the attack.
It's skill based and not totally impossible to do ingame or code wise.
That sounds great!:)
It sounds like it could be a good balance of manual blocking and automatic without making it overly complicated, difficult, and unnatural. I'd definately try it out.
You mention the 4 quadrants for blocking. Does this include blocking on the sides and the back with the new animations keshire is making or are you just starting off with blocking in the front for simplicities sake to see how it plays out? (Just Curious)
Is this only for saber combat blocking? (That's my recommendation since I think it would be too difficult and too much of a hassle to have to block lasers manually in the quadrants. Predicting where they'll be and blocking a succession of lasers would be hard...)