Jump to content

Home

Enhanced Brainstorming: Saber System


razorace

Recommended Posts

ok so blocking is covered, great now about my new force powers, I have an idea for Force Levitate and for Force Blast.

 

Force levitate will allow you to levitate and obejct (if possible) or yourself (not fly but allow you to jump from very high places and not get hurt at all (unless you run out of force energy) and for other things, the Force Blast can be like a big bubble or force energy that pushes everything around you away like a massive force push to all around you, and than the level of it (1-3) can change how powerful of a puch it is and the radius of effect :) and ofcourse it should take like 80-100 force energy to use. (I say 100 but less is ok too) So if those are good ideas I can try and work on code for it and the animations (I think I can get the animations done) Also razorace you have a IM so we can talk about stuff I can do for the OJP?

 

btw this is what you say on the site:

Mouse Sabering:

 

Use your mouse to perform standard, special, and defensive moves and combos from all 3 stances at once! This will include several HUD additions including a fading crosshair trail and new crosshairs to make this as fun as possible. For traditional players, you can still do things the old fashion way with the addition of a defensive position system.

 

soo what you saying is that you move the saber with the mouse to attack and block? hows that supposed to work ?

Link to comment
Share on other sites

  • Replies 208
  • Created
  • Last Reply

We will see, it depends on someone actually working on it and then submitting it to OJP.

 

Anyway, I've added in the head lock grapple move of kyle's to the game but I'm not sure how I should handle things.

 

Should the grapple/kick/melee moves be availible when the saber is turned off or sure there be quick commands that directly do certain moves? I'm concerned about balance, realism, and the possibility that the quick commands will lag the game/be too slow to respond. Any feedback on this would be great.

 

Also, I think I have an idea on how to make melee moves vs sabers realistic and balanced. I'm thinking that the defender's saber (even in idle or a block) should cause damage to the attacker if he touches it at all. Is should force the attacker to dodge, take damage, fall down ("ARGH! I just burned my foot!"), etc. Since this will be based on the actual position of the defender's blade, an attacker can still make melee attacks if he's careful.

 

Plus, to make this worth it for the attacker, I'm thinking that melee damage should bypass Dodge (assuming that the defender is using a saber; melee vs melee should probably have Dodging) and/or cause knockback/Fatigue.

Link to comment
Share on other sites

Sounds good to me.

 

But, how about shortening the headlock move and making it only work if hit from behind? Lower the damage and have the attacker drop his saber? And really, is the grabbing the foot and swinging them around realistic? Maybe if done by a Jedi.

Link to comment
Share on other sites

Oh yeah, I'm also thinking that everyone should have melee as a "weapon" that is linked to some Force skill (I'm not sure which yet).

 

Pressing your weapon 1 button would switch between saber on and melee mode (instead of just turning the saber off) and using the buttons without the saber on will do melee moves instead of saber moves.

Link to comment
Share on other sites

Originally posted by keshire

Sounds good to me.

 

But, how about shortening the headlock move and making it only work if hit from behind? Lower the damage and have the attacker drop his saber? And really, is the grabbing the foot and swinging them around realistic? Maybe if done by a Jedi.

 

I beleive the animation is set up to be entered from the front.

 

Yes, the possibility of the defender dropping their saber is exactly the sort of thing I'm talking about. :)

 

And the move you describe would require new animations. Doable, but I'm not going to do them personally. :D If someone does the animations, I'll put them in the game as long as they were reasonable and don't suck.

Link to comment
Share on other sites

Originally posted by keshire

I also think Melee damage should scale inversly with saber attack level? But thats just me.

 

Why? The point isn't to allow mercs to beat the living crap out of Jedi. :)

 

How about applying it to an acrobatics force level, with selectable flips, and cart wheels based on level?

 

Well, I consider new force skills/player attributes to be a seperate part of the project, I can mess with them laster. I just need something quick and dirty to link it to.

Link to comment
Share on other sites

Originally posted by keshire

I also think Melee damage should scale inversly with saber attack level? But thats just me.

 

Why? The point isn't to allow mercs to beat the living crap out of Jedi. :)

 

How about applying it to an acrobatics force level, with selectable flips, and cart wheels based on level?

 

Well, I consider new force skills/player attributes to be a seperate part of the project, I can mess with them later. I just need something quick and dirty to link it to.

Link to comment
Share on other sites

And the move you describe would require new animations. Doable, but I'm not going to do them personally. If someone does the animations, I'll put them in the game as long as they were reasonable and don't suck.

 

Some fiddling with the animation.cfg should do the trick. start it at the point where the victim gets turned around?

 

 

Why? The point isn't to allow mercs to beat the living crap out of Jedi

 

Very true. But it shouldn't be tied to sabering. I'm thinking poeple specialized in martial arts here.

Link to comment
Share on other sites

Originally posted by keshire

Some fiddling with the animation.cfg should do the trick. start it at the point where the victim gets turned around?

 

That might work, but there's a concern over animation skipping.

 

Very true. But it shouldn't be tied to sabering. I'm thinking poeple specialized in martial arts here.

 

I think so too. Maybe Force Push/Pull?

Link to comment
Share on other sites

looking at the anims the grab can be left the same. Skip the first few frames of the being grabbed in the animation.cfg and can you code it so it starts a little late to sync them up? Not to mention adding if attacking from behind? Is that even possible? Haven't seen it done yet anywhere in the code.

Link to comment
Share on other sites

I'd like to follow up on the idea I proposed about making saber throw single use.

 

I found this saber flag that isn't helpful. since ALL the code related to it was taken out. q_shared.h

 

//#define SFL_STICK_ON_IMPACT (1<<?)//if set, the saber will stick in the wall when thrown and hits solid architecture (good for sabers that are meant to be thrown).

 

But I'm sure it can be re-implemented. Is it possible to also make it stick "in" players ala the AOTC cartoon? Then have force pull bring it back? And add some of that expensive physics mentioned in the source ;)

 

Also while I'm on the subject of sticking in players. What about the rolling stabs? can we do the same. stick in player, lose saber.

 

expanded use of the force powers (pull in this case) are always a good thing.

Link to comment
Share on other sites

Would this be helpful for bolt detection? Its located in the expensive physics source. g_exphysics.c Obviously I'm not a coder but I have taken a few classes here and there.

 

if (hasFirstCollision)

{ //at least one bolt collided

//We'll get the offset between the collided bolt and endpos, then trace there

//from the origin so that our desired position becomes that point.

VectorSubtract(collisionRootPos, bestCollision.endpos, trajDif);

 

VectorAdd(ent->r.currentOrigin, trajDif, projectedOrigin);

}

}

 

//If we didn't collide with any bolts projectedOrigin will still be the original desired

//projected position so all is well. If we did then projectedOrigin will be modified

//to provide us with a relative position which does not place the bolt in a solid.

trap_Trace(&tr, ent->r.currentOrigin, ent->r.mins, ent->r.maxs, projectedOrigin, ent->s.number, ent->clipmask);

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...