before i start i want to make something clear. i am aware that there is already a sword/melee combat thread, as that is where the seeds of this idea were sown.

onwards!

this proto deals in the concept of "non-state mechanics", which i will now explain (check out the alternate for a greater depth explanation). non-state physics is a theory and practice meant to replace fixed animations on almost much everything that has one. compare your player in starforge to your character in a game like say, team fortress, minecraft or call of duty. all of these games utilize what's called state-based player physics, while starforge uses non-state.

full explanation:
http://www.forgeforums.com/viewtopic.php?f=6&t=1706

now, a non state sword is, in it's most basic essence, a sword that doesn't swing. now, when i say that it doesn't swing i mean it doesn't have a swing animation. instead it's every movement is controlled by the player; both location and velocity.

the thing about non-state movement is that it has to be measured in entirely unconventional ways. since i'm assuming there are going to be some kind of noncollider energy weapons, as well as noncollider slicing and piercing weapons (E.G. sword-tips, daggers) i'll start with those, because they will be hardest. whenever an objects moves in-game it doesn't actually travel, it just changes location very quickly and repetedly, at a set interval of time. it is possible for the computer to draw lines between one point and the past point, and this line can be measured. it is this measurement that can be used to assign damage and force of impact. for collider weapons it's a little simpler. the force of impact can be measured by the computer in the way i described before, but the weapon won't need the force-impartion value. the damage and force-dealing algorithims will have to be exponential in proportion to the length of the line. this is because something that is noncolliding can allways travel the same depth, no matter the speed.

[TECHNICAL ADDENDUM 6/29]: there is an alternative method to the one proposed previously. because the sword is non-state it is constantly trying to reach a base animation through application of forces. when the sword is swung it can (and will) bounce and grate upon impacting objects. therefore if the base animation that the sword is trying to reach is a location controlled by the player the damage values can be measured by force-of-impact and not by the line-measure system proposed previously, reducing both workload for the code}{atch team and processor load for the client. [END]

now that the technical section is over, there is the matter of player-based control. there is the simple matter of the blade's orientation and movement control which will be based entirely around the mouse. but to get to the state where this can occur the mouse has to temporarily change functions from looking to controlling the blade. this can be done by, when the weapon is equipped, having mouse1 engage a view lock and change from looking to slicing.

[ADDENDUM 7/15] one very big problem with aforesaid control scheme is that it's very easy to exploit. many people are able to write up a piece of code that could cause the mouse to "jitter", thus exploiting the player-driven mechanic of mouse movement and generating huge DPS. but by implementing code where, if the mouse moves in an especially erratic or un-realistic fashion (E.G. going an insane distance in-between locational updates, bouncing back-and-forth without any visible parabolic arc, or repeating a single pattern flawlessly) your sword would fly out of your hand and you can cripple your arm or cause damage to your base health.[END]

[SECONDARY ADDENDUM 7/15] view locking works well with small, precision weapons that don't require a wide swing, but is horrible with large weapons that would make larger swings in any other game. starforge has a mechanic where the base camera view doesn't begin to rotate until the cursor reaches a certain portion of the screen. but before you reach that point the camera still moves slightly in accordance with cursor location. if one replaces the cursor with the location of the blade (in swing mode) and accentuates the latter type of camera movement you can have a far larger swing radious. the degree of accentuation for the camera movement could be a user-controlled options preference.[END]

[ADDENDUM 7/11] this style of control seems to work fine for having a blade, but where there's blades, there's shields. the manner of control for a shield as opposed to a sword has to be drastically different because of the two different uses. a shield cannot have a view lock because it needs to be able to track an opponent to effectively act as a shield, but it is still concieveble to have some kind of "shield bash" that can be used. so this is what i propose; if you have both sword and shield equipped and you hit mouse2 you'll hold up your shield (no view lock) and it is held in some kind of defensive position. if both mouse1 and 2 are pressed then the shield acts as your sword would, moving around in tandem with the mouse with a view/camera lock. [END]

now, ideas can always be improved, so i'd love some suggestions.

This idea is truely awesome, reminds me of the good ol' madness interactive flash game. Only downside I can imagine would be getting used to switching from view to swing so quickly. Also, I dont really think that sword combat will be utilised very often, unless one (I would) enjoys charging around with a sword, then the replay value of this is massive, and definitly worth the effort in coding. I guess this also allows people to be more personalised in the way they play, and can develop strategies...

You could really be onto something here.

yeah, madness is where i actually got inspiration from, i just forgot the name of the thing

[ADDENDUM] as for it not getting used often? i think that there are probably going to be whole melee classes, i'm just seeing where we can take this

This sure is a great idea, though I believe without a control for swinging and looking at the same time it would become extremely irritating. Imagine moving into combat with someone, sword drawn, you slash, they move out of view. Now from this point (If I actually understand this correctly) you would have to release mouse1 and look in they're direction, press mouse1 and slash at which point they will likely move and the whole process will repeat. In my opinion this would be extremely under-powered as you would not only likely die before reaching your opponent but if you were to reach them they would probably just gun you down before you land a hit. I still think this is a great idea with many possibilities... even chopping down trees?
My suggestion would be that when mouse1 is pressed and you swing your weapon in a certain direction the camera could turn to keep you target in sights. Though the camera should only start turning once your weapon is nearing the edge of vision as to not disorient players.

firstly, the camera view can be engaged instantly, and the swing very near so. even so, this concept lends itself more to a more realistic style where any sword blow with any kind of force has the capacity to cripple or kill the player but blows are harder to come by. also, it's called leading a shot, and while the term is sniper specific i think the concept still applies.

[ADDENDUM] also, if the camera were to follow the weapon then it would jitter from side-to-side in a rediculous manner because of the possible rate at which a player can "slash"

[SECONDARY ADDENDUM] also, judging by your response you may not be actually able to tell that the actual slashing motion of the blade is also controlled by the mouse (no specific keymap or animation for the motion)

I thought It would run on a hotkey based system, lets just use cntrl {control}... so while your not holding control, everything is normal, you run around, look around, but you can't swing you weapon. but when you hold cntrl, the camera locks, and your mouse swings the weapon. The benefit of this is that you can quickly switch to and from melee, and with a tad of practice, it should be fluent, and could actually be a really effective system.

Okay I understand your point that a blow should be crippling if not lethal though I still believe my point stands. Sure the camera movement and swing can be activated almost right after each other but I personally think it would be difficult to master and still under-powered in the end. Maybe when you are holding mouse1 you can still move with W A S D but instead of strafing with A and D you would just be turning the camera left and right... I feel this would be a lot easier to master though it does of course limit movement. Maybe an option for whichever way you prefer?

well, what you are saying generally correct. the the camera-lock function could be re-keymapped in the future to something like cntrl or "E". this should actually answer your question dan-paul.

I actually understood your concept fully I just personally thought that it would be difficult transitioning from slashing to camera movement fluidly and effectively. For example if a target was to start circling around you whilst you desire to decapitate them, at such close range they could be out of your view in an instant if your camera was locked. My problem was that I couldn't imagine becoming very effective at this since in my experience at playing other games in first person when your close it gets quite hectic... players jump around and you may find yourself rapidly turning camera direction. Also if for example a player started moving to the left of your screen and you had to move the camera left and re-engage the slashing mode you would have to pick up your mouse and move it to the right of your mouse pad and then make a left swing which takes only a second... but a second you may not have at such close range.

if you have somone dancing circles around you then you have a very big problem no matter what game you're in. you also have to take into account that the other person will also have the same conditions, which means that dancing circles around somone will actually be quite hard. as such it will actually cause melee combat be just as intense without being quite so disorienting.