Dynamic Combat System
by Mikey Busch · in Jobs · 09/12/2007 (1:30 pm) · 6 replies
Were currently working on a 'dynamic' combat system as a project, were just pretty much seeing were it takes us for now, more of a 'dude this would be cool if it works' kinds of thing.
Were using variables and algorithms to create a midieval combat fighting system were when one player swings at another player, based on a random dice roll (for now) the player hits or misses. Using this we then factor in the percentage to block if a successfull block occurs then the game itself shows the block as an animation along with (simultaniously) the opposing or attacking characters weapon being block. Alongside of this your 'hotbar' will pop up with available counter attacks, such as kicking, legswipes, etc. Alowing for a fluid and very entertaining combat spectacle.
The basic goal of this really is just making combat entertaining instead of look, i can click a bunch of times and i do the same looking attack every time! To me thats not very entertaining. I myself understand that im going to spend long hours animating many a different moves and tweaking to make them right (yes im the 3d artist in the fiasco) but were looking for some other team members to join in.
So drop me a line if your interested. ferret_tk@yahoo.com
Or leave me some feedback on idea's, etc. Im really in dire need of a 2d artist / skinner.
Were using variables and algorithms to create a midieval combat fighting system were when one player swings at another player, based on a random dice roll (for now) the player hits or misses. Using this we then factor in the percentage to block if a successfull block occurs then the game itself shows the block as an animation along with (simultaniously) the opposing or attacking characters weapon being block. Alongside of this your 'hotbar' will pop up with available counter attacks, such as kicking, legswipes, etc. Alowing for a fluid and very entertaining combat spectacle.
The basic goal of this really is just making combat entertaining instead of look, i can click a bunch of times and i do the same looking attack every time! To me thats not very entertaining. I myself understand that im going to spend long hours animating many a different moves and tweaking to make them right (yes im the 3d artist in the fiasco) but were looking for some other team members to join in.
So drop me a line if your interested. ferret_tk@yahoo.com
Or leave me some feedback on idea's, etc. Im really in dire need of a 2d artist / skinner.
About the author
#2
From the technical side, you'll run into issues regarding timing of moves vs latency in any kind of "real time" based game with this mechanic. An average latency of 200 ms leads to a 600 ms "move to counter to result" communication, and that can be noticeable in a real time game.
09/12/2007 (1:37 pm)
I had every Lost World book that existed, and even made a couple of my own ;) Fun system, if limited to pre-defined books.From the technical side, you'll run into issues regarding timing of moves vs latency in any kind of "real time" based game with this mechanic. An average latency of 200 ms leads to a 600 ms "move to counter to result" communication, and that can be noticeable in a real time game.
#3
09/12/2007 (1:39 pm)
Well were thinking of keeping i on a 1v1 to 2v2 system in a battle arena type setting. So the MS strain shouldnt be too horrible. 
#4
09/12/2007 (2:37 pm)
Ping time isn't related to number of players.
#5
09/12/2007 (2:44 pm)
Well i understand the concept of how ping works, on packet size / in and out, etc. etc. but im ASSUMING (yes and i know most assumptions make an ass out of myself) has alot of what is thrown back and forth, but are you saying that regardless of how many players are on it wont relate to the ping?
#6
The reason why latency is an important factor in a situation like this however is that by nature of the game design, you have two players reacting to each other at a very fast rate--Player A starts to swing, Player B needs to know that Player A is swinging in time to block, and that input needs to make it back to Player A in time for the block to be effective, then the "blocked swing" event needs to be transmitted to both players before the swing animation would have finished playing.
Let's break it down into some number cases:
First, some assumptions:
it takes 500 milliseconds for a "swing" to occur, from start to finish.
it takes 300 milliseconds for a "block" to occur, again start to finish.
Player A is connected to server Z, with an average latency of 150 milliseconds
Player B is connected to server Z, with an average latency of 300 milliseconds
Humans can respond instantly (0 ms delay) to events (yeah right!)
Ok, now let's do a timing sequence:
Player A starts a swing at time 0, and will finish the swing at 500 ms
--it takes 150 ms for the swing event to be sent to the server, and another 300 milliseconds for the server to deliver the swing event to Player B resulting in 450 milliseconds before Player B even knows Player A started a swing.
Player B starts their block, which takes 300 milliseconds.
--block event is delivered to server, taking 300 milliseconds, and delivered to Player A, taking 150 milliseconds.
-----unfortunately, the total time for the block event from Player B to make it to Player A is a net of 900 milliseconds. The fact that the swing was blocked doesn't even arrive at Player A until 400 ms after the swing is finished!.
To summarize the issue, the speed of maneuvers each player can perform has to be (much) larger than the total network latency periods between two opponents to have enough "wiggle room" for players to actually interactively make swing/block/counterswing style combat work--and that means that it will be a pretty slow playing game, and almost certainly not 100% real time without a whole lot of design/implementation optimization.
09/12/2007 (5:45 pm)
Network latency is defined as the amount of time it takes for data to travel from the sender to the receiver, and is (mostly) independent of the number of total clients connected to a server, or what is going on in the simulation (until such time as you are CPU bound and driving 100% of your CPU to running the simulation, so very little is left over for network processing--a pretty rare occurrence).The reason why latency is an important factor in a situation like this however is that by nature of the game design, you have two players reacting to each other at a very fast rate--Player A starts to swing, Player B needs to know that Player A is swinging in time to block, and that input needs to make it back to Player A in time for the block to be effective, then the "blocked swing" event needs to be transmitted to both players before the swing animation would have finished playing.
Let's break it down into some number cases:
First, some assumptions:
it takes 500 milliseconds for a "swing" to occur, from start to finish.
it takes 300 milliseconds for a "block" to occur, again start to finish.
Player A is connected to server Z, with an average latency of 150 milliseconds
Player B is connected to server Z, with an average latency of 300 milliseconds
Humans can respond instantly (0 ms delay) to events (yeah right!)
Ok, now let's do a timing sequence:
Player A starts a swing at time 0, and will finish the swing at 500 ms
--it takes 150 ms for the swing event to be sent to the server, and another 300 milliseconds for the server to deliver the swing event to Player B resulting in 450 milliseconds before Player B even knows Player A started a swing.
Player B starts their block, which takes 300 milliseconds.
--block event is delivered to server, taking 300 milliseconds, and delivered to Player A, taking 150 milliseconds.
-----unfortunately, the total time for the block event from Player B to make it to Player A is a net of 900 milliseconds. The fact that the swing was blocked doesn't even arrive at Player A until 400 ms after the swing is finished!.
To summarize the issue, the speed of maneuvers each player can perform has to be (much) larger than the total network latency periods between two opponents to have enough "wiggle room" for players to actually interactively make swing/block/counterswing style combat work--and that means that it will be a pretty slow playing game, and almost certainly not 100% real time without a whole lot of design/implementation optimization.
Torque 3D Owner Pat Wilson