[Scrymud] Change idears?

[Justin Piper]

On 2002.02.13 05:50 gingon at wanfear.com wrote:
> While the current combat system is simple, and allows for little
> variation,
> it is easy to learn and easy to use. The expensive of making the
> combat code
> more complex is greater than simply writing more code, or making
> combat take
> longer over all. The real expensive is in whether or not a new user
> can
> function in combat with little much undersanding of the more complex
> options.
> The more difficult it is, the less likely that a new player will
> continue to
> play.

Actually, that wouldn't really be an issue.  If you just stand there 
and look confused, the computer moves on your behalf.  It's intended to 
give lagged and link-dead players at least half a chance, but it'd also 
have the side effect of protecting clueless newbies from getting their 
asses kicked by bunny rabbits.

Basicly, if you don't take any action for whatever reason, the computer 
would fall back on your melee attack automatically.

> Having a definite limit to what and how you can do per round is fine.
> It's
> more of a question of how to implement that limitation. My idea is a
> relatively simple modification to the existing system.
> 
> Each combat command that a player may use has a cost in number of
> attacks.
> It would allow a command to use several rounds worth of attacks. Cost
> in
> attacks comes in 2 form, delay and post delay, delay is the number of
> attacks needed before the skill effects occur, and psot delay is the
> number
> of attacks used before another command can be used.

Unless I'm misunderstanding your idea, this is basicly the same thing 
I'm proposing, attacks with varying speeds and recovery times (poses 
under my system).  The main difference I see is that yours is 
asynchronous, and mine has defined rounds.

I think there's advantages either way.  I deliberately avoided 
asynchronous combat because I think it will cut down on the lag 
experienced by modem users, and because it provides a convenient way 
for the server to decide when to intervene on your behalf.  Your idea 
lends itself much better to giving players the opportunity to react to 
their opponent's attacks (and, consequently, opens it up to abuse via 
triggers).

> Another possiblity lies within special if-else commands. For example a
> fighter decides to use block, if the opponent does not attack that
> round,
> the block becomes a weaker normal attack. Of course, there may be some
> attacks that can not be blocked, but may still use up the block
> command.
> 
> The reasoning for this is simple, if you decide to block, but your
> opponent
> does not attack, then you should be able to recognize this and attack
> instead,
> though not as effectively.

Hmm... how about instead of putting a bunch of special checks all over, 
you let people break off whatever they were doing and switch to a 
different course of action instead.  In addition to the effectiveness 
penalty, you'd want to have a configurable recovery time for doing 
that, since you can switch from guarding to combat easily, but you'd 
have to drasticly shift gears to switch from bodyslamming to guarding.

> > In addition to the inherent speed of an attack, each attack would
> have
> > both a set of valid starting poses and an ending pose, which are
> used
> > to chain attacks so they can be performed quicker.  If your last
> attack
> > left you in a pose that your next attack can start in, you can
> smoothly
> > move into your next attack without any delay.  If you need to assume
> a
> > different pose to begin the next attack you've chosen, that
> negatively
> > affects the speed of your attack.
> 
> Interesting ideas, but it would be difficult for players to use
> effectively for 2 reasons. Number one is the amount that has to be
> typed in
> per round, increasing the amount of input required could penalize
> players who
> type slowly, or are somewhat lagged.

I think you're misunderstanding my idea of a chained attack.  You'd 
still only get one attack per round (unless, I suppose, your attacks 
stat were increased), but the next round you could chain into another 
attack that would be slightly faster because you were already in the 
right position.

> Number 2 is the amount of battle state that the user needs to be aware
> of in
> order to make the best use of the system. There are 2 options here,
> either
> display it as part of the prompt, or force the player to remember not
> only
> what position they are in,  Also, the player would need to know the
> position
> requirements of the skills they intend to use, as well as the ending
> position.
> 
> That's alot of information for the player to handle in either case.
> However, it should be noted that players use a relativly small number
> of skills in combat, making knowing the positions far easier.

I expect players to remember these more like combos in fighting games.  
Poses are just how I suggest we keep track of things in the server.  
Players don't even need to know that they exist, just that they can 
chain some attacks into others and get a speed boost.  In PvP combat, 
this could be a crucial OOC skill when you factor in the ability to 
counter and interrupt attacks.  Maybe bash is easy to deflect, but if 
the move you were going to use to deflect it is too slow, then you're 
SOL.

> > The first-come, first-serve tank system would be replaced by a two
> row
> > formation for each side.  Combatants can stand in either the front
> or
> > the rear line.  It takes an additional round to attack a target in
> the
> > rear line (during this round your intentions are made obvious to the
> 
> > other fighters, which allows guards to rescue their charges before
> the
> > attack), unless there are no combatants in your opposition's front
> > line.  If you are in the front line, but are not being attacked by
> an
> > opponent, you may flank one of your opponents.  You must be in the
> > flank position to execute certain attacks, such as backstab or
> critical
> > strike.
> 
> Not to sure on this idea, so I'll just say that it has interesting
> possiblities, but is it worth implementing?

I think it is.  Right now, Scry combat is like the anti-Ninja movie.  
Everyone attacks the same guy, all at once, untill he dies.  Then they 
attack the next guy.  And if the next guy happens to be your cleric, oh 
well.  His number was just up.

> One thing I would like to see added is an aggro list. Essentially,
> this is
> a list of aggressiveness towards attackers. It works like this: an
> event
> increases the aggressiveness towards a particular target, this is
> rated
> numerically. once every round, there is a chance to switch targets and
> it
> works like this in psuedo-code:
> 
> 
> 1. the aggression rating for all attacks is added up
> 2. result = d(1,aggresion total);
> 3. use result to index a distributed probablity matrix.
> that could work something like this(in pseudo code):
> 
> do{
>    if(result <= self.attacker[i].aggresion_rating)
>    {
>       self.target = self.attacker[i];
>       break;
>    }
>    result -= self.attacker[i].aggresion_rating;
>    i++;
> } while(i <= number_of_attackers);
> (A little confusing, but it works quite nicely. Not exactly a
> distributed
> probabilty matrix, but this is far more efficient by a hell of a lot.
> Mainly
> avoids creating a huge new array and populating it through several
> thousand
> iterations of an expensive loop each round.)
> 
> the main problem is that in a big battle, we could get into some
> really huge
> numbers and overflow an int, so it might be best to use an average per
> round,
> or something like that.


Hmm... I would assume you'd want to use the ammount of damage delt by 
any given player for the agression rating.  That'd actually be a fairly 
good indicator of the threat of the target.  As for overflowing an int, 
how many mobs have 32,000 HP now?  Can mobs even /have/ 32,000 HP?