quote: Original post by Taco
ok the styles make sense to me now, somewhat, I still don''t see how similar styles should cancel each other out though... if you both fight with a shield, you both have a harder timing hitting the other, no?

The idea is that knowing how to fight with a shield also gives you an insight into the disadvantages of doing so, therefore allowing you to exploit that. It is, admittedly, an abstraction.

quote: And on the note of RPG 10 out of 10 wins... would you really want a game to be that way? Is it really fun to have the combat victory depend on all your preperations and still require you to do it yourself? I''m not saying preperation and skill shouldn''t have effect, but I''m getting tired of it being the factor that decides victory.

You misunderstood what I meant; most games are already this way, in that the higher level character will almost never lose. By putting more of the skill back in the hands of the player, I hope to change this a little. But to change it a lot would move the game too far from being based on character skill, and that is unacceptable for my design.


[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Lol, yeah it''s DBZ-related but there is no website to my knowledge. It''s not even an open MUD. It''s basically a guy that loved FE so much he wanted to recode the whole game since the original creator took it down.

It basically runs like this:

You have 9 basic commands:

Parry High, Parry Low, Punch Right, Punch Left, Sweep, Roundhouse, Dodge Right, Dodge Left, Deflect.

When you type the command punch right Jimmy (aliases available), a 3 second counter starts allowing Jimmy to react. He may decided to attack (punch right John) or defend (Parry High). Dodging requires less timing but is purely defensive and only drains your energy.

On the other hand if you parry the blow there''s a chance you can stun your target allowing for a break, chance to run, or possibly a combo attack.

Combos allow you to make a series of rapid attacks against a helpess target. They are pretty rare occurances but they happen.

Basically your timing attacks, dodging, and parrying the whole time. Energy beams are deflects and piercing/cutting ones are dodged.

Then you have ranged strikes because the actual world is a grid map.

It''s a pretty interesting system. Unfortunatly a lag spike can throw you off terribly seeing as one mistake and cause many of your future blocks/attacks to be ill timed. It''s pretty fun otherwise. Just though it''d be interesting for you to read.

Personally if I was making a MUD I wouldn''t use this method seeing as it is heavily dependant on a good connection (I tried it on my 28.8k connection and I would get whooped by people half as strong as me.)

Dauntless - I'm not 100% sure I follow the system you describe. I'll use a diagram to show how I picture it, and perhaps you can correct me as appropriate?

Numbers mark when actions are due   Time |--------------------------->FastPlr |....1....2....3....4....5...SlowPlr |.......1........2........3..  

So, both players execute one action each. If SlowPlayer's 1st action gives him -2DCV, that will apply during FastPlayer's actions 2 and 3, right? Then, when SlowPlayer launches an attack with their 2nd action, FastPlayer can choose to forfeit action 4 in order to be able to use a reactive technique, which can alter FastPlayers stats (like DCV) until his next action. These altered stats will be used when resolving SlowPlayer's 2nd action. FastPlayer may then get an attack himself, if it's a hybrid offense/defense action, and then will attack next with action 5.

This seems reasonable, except for a couple of details (relating to my system). Firstly, combat has to be resolved in something like real-time, the best CRPG approximation being the Active Time Battle system in earlier Final Fantasy games. I suppose you could look at it as bounded turn-based. Yet any system requiring a response for each and every attack could cause problems due to the notorious problem of lag over MUDs. You could miss the chance to react to 3 or 4 attacks and lose a battle that way. This might be acceptable in many online games but not in MUDs because they are traditionally designed to compensate for this. The delay between an opponent starting to perform an attack and actually completing that attack would be 2-3 seconds at the most. (It's usually instant on most MUDs, but not mine.) So this is quite a narrow window to choose a response in.

Regarding the historical details, I'm sure there are some well-documented combat methods for sword-fighting and maybe axe-fighting, but what about for maces, daggers, chains/whips, quarterstaffs, spears/pikes, etc? I think the amount of research I would have to do would be staggering. This is another reason why I wanted to make it more abstract. Weapon variety will be important to my players and therefore each kind will need to be fleshed out.


PSWind - Thanks for the details. Lag spikes are the main reason why I didn't want a blow-by-blow system, because as you say, all it takes is 1 bit of lag and someone dies horribly. I may even have permadeath on my game, so I don't want anyone punished severely for being unable to react. Although there is a reactive element to the styles system I am considering, it's more about preparation and anticipation.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

[edited by - Kylotan on April 16, 2003 9:22:20 AM]

Kylotan, maybe to handle lag spike issue you could have the user play through an interface/passthrough program which would heartbeat with the server so that if they did lag the server wouldn''t allow the opponent to kill them. Of course then you have the problem with people who disconnect to avoid dying in combat. You''d have the heartbeat overhead as well.

RandomTask

quote: Original post by RandomTask
Kylotan, maybe to handle lag spike issue you could have the user play through an interface/passthrough program which would heartbeat with the server so that if they did lag the server wouldn''t allow the opponent to kill them.

I''m not quite sure what you mean. There''s no way (short of monitoring the entire internet in real-time) of knowing whether it''s genuine lag or whether the player''s gone to the fridge to make a snack.



[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]