Saber Combat System revised...

[Jellybelly]

Hi all

 

I put together this suggestion for saber combat system with emphasis on achieving overall balance, a thing that I feel although being good now...might still be made even better in an already great game.

 

Even though I think my following overall concept is in many respects identical to the way saber combat was intended by Raven (judging from in game behaviour and notes in the game manual), it might still add some new points to it's functionality.

 

This concept is based on the basic layout of the saber combat system as it is now, and on the assumption that blocks are performed automatically as long as You are facing in the right direction in game.

 

Although one might still utilize most of this system even if using a manual block function...I've chosen to focus on the autoblock alternative for now.

 

Apologies if my suggestions do not contribute with that many new ideas, I just put this down as a quick take on what an optimal saber combat system might be within reasonable technical game limitations.

 

Thus, this should rather be viewed upon as a slightly revised version of the existing saber combat system than a completely new one.

 

Anyways...considering above factors, here's my take on how I think the saber combat should work:

 

-----------------------------------------------------------------------------------

 

When attacking using...

 

Light stance (blue) - Low probability for opponent to autoblock but little damage made if hit. Low resistance against parry/knockback if autoblocked by opponent. High execution speed, short attack range.

 

Medium stance (yellow) - Medium probability for opponent to autoblock and medium damage made if hit. Low resistance against parry/knockback if autoblocked by opponent. Medium execution speed, medium attack range.

 

Heavy stance (red) - High probability for opponent to autoblock but high damage made if hit. High resistance against parry/knockback if autoblocked by opponent. Slow execution speed, long attack range.

 

Idle stance (i.e. no active attack, just holding saber, touching opponent) - Equal moderate damage made regardless of combat stance (red, yellow or blue) if hit.

 

When defending using...

 

Light stance (blue) - High probability to make autoblock but weak in blocking/parry power (high self knockback and/or damage risk). High execution speed.

 

Medium stance (yellow) - Medium probability to make autoblock and medium strenght blocking/parry power (medium self knockback and/or damage risk). Medium execution speed.

 

Heavy stance (red) - Low probability to make autoblock but strong in blocking/parry power (low self knockback and/or damage risk). Slow execution speed.

 

Idle stance - Defence according to selected stance (see above).

 

Definition of terms

 

Attack damage and blocking/parry power is to be viewed as a direct effect of the force and weight put behind the move by the character/player.

 

Autoblock function is to be viewed as a simulation of the characters/players reflexes.

 

Parry and/or knockback power is to be viewed as the force deflected when defending an attack.

 

Execution speed & attack range is pretty self explanatory.

 

Using equal stances

 

If two players are fighting using the same stance all attacks and blocks/parries would result in none (or minor but equal) parry/knockback for both players.

 

Attack vs attack

 

* If two combatants attack each other at the same time and sabers clash without making any block/parries...the attack strengths of the stances should be pitched against each other.

 

* I.e. the one with the weaker attack strenght in a situation like this will be parried/knockbacked. In the case of two identical stances attacking each other...please see Using equal stances above.

 

Saber throws

 

* Saber throws should be subject to the same principles (of speed, attack and defence) with regards to the stance used...as regular saber combat is (see above).

 

* However, the attack speed would now translate to the speed of flight of the thrown saber.

 

* Also, the parry/knockpack strength of the defender in relation to attack strenght of the thrower would translate into how great the risk is of the thrown saber to be deflected away from the thrower (i.e. drop to the ground)...resulting in him/her having to pull it back manually or pick it up.

 

Execution of moves

 

* An executed attack should only be fully effective for the duration of it's active movement. As soon as an attack has been followed through, it's ability to inflict damage should not be more than that of an idle blade.

 

* For example...a slash should only make attack damage from the point the slash starts until the arc of the slash is completed.

 

* Equally, a stab should only make attack damage from the point the stab starts until the blade reaches it's full extended point.

 

This is where the current red stance fails, making full attack damage long after the actual attack move is completed...only requiring the slightest touch (by a seemingly idle blade) to inflict damage equal to that of a perfect hit by a slash or stab.

 

The heavy stance finishing move

 

This one hit - one kill (finishing) move of the current red stance is also questionable as it kills regardless of what the opponent does when hit.

 

Considering that both combatants have the same tool (sabers) and these tools are equally durable...this also makes the total inability to block unreasonable.

 

A sword cutting through a stick is one thing, but a saber vs saber situation should be pretty equal in this regard.

 

* There should still be some possibility for the opponent to block, but it could be made dependent of the blocking power of his/hers current stance (see my suggestions above) when atacked with it.

 

* It could also result in a certain knockback with certain damage to the point that it could indeed be fatal. This is quite reasonable as You actually have an opponent plunging towards You with the force of his/hers full bodywheight. However, the damage should still be depending on what blocking power (see my above suggestion) the opponent has at that point.

 

Example:

 

Executing finishing move on an opponent who is using...

 

...blue stance (low blocking power) - death or major damage.

 

...yellow stance (medium blocking power) - major damage or medium damage.

 

...red stance (high blocking power) - minor damage or no damage.

 

-----------------------------------------------------------------------------------

 

I made the above suggestions based on my own humble knowledge of physics (combined with the use of relevant martial arts tools like sword, staff etc), and what seemed reasonable to me within the given limitations of this game.

 

If You consider all of the above carefully, I hope You'll find that the result of such a system would be balanced advantages and disadvantages both within the individual stances as well as between them all in a whole...which is something I think is desirable.

 

This would put more emphasis on the players skill and tactics...and less on exploiting any inbalances in the combat system (for example the current red stance).

 

I also believe that reducing the packpedal (running backwards) speed would equalize the combat sytem, bringing out the balance within the sytem even more...forcing players to use and evolve skill and tactics on a level more true to the actual saber combat seen in the Star Wars movies.

 

Finally, please note that I've used the word "should" in many places. This is of course my personal opinion only, and based on the context and balance of this specific system.

 

It is in no way meant as an insinuation by me that my opinion is the only right one...or more worth than anyone elses.

 

Anyways...please tell me what You think, and sorry for the very long text.

 

Many thank's to Raven for making this great game!

 

Take care all

 

Jellybelly

[NewBJedi]

How about it being optional?

 

Say the saber was changed to this, it could be:

 

g_oldsaber 1 = original out of the box cd style

 

g_oldsaber 0 = new saber style that you suggest

 

This way it can be server size optional, and filterable by clients?