[Scrymud] Change idears?

[gingon at WANfear.com]

Quoting Justin Piper <justin at wanfear.com>:
> > 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).

Perhaps I wasn't clear on this. My system is more of an exetension of 
the existing combat system to improve the tatical possiblities. 

Take the existing system, change number of attacks per round to 
number of command slots per round. Define commands as taking a varying
number of command slots before the effects occur and/or after the effects
occur. That would be my system.

> > 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.


That could also work, but depending on the amount of battle spam, it could
be hard to see what's going on, and miss the chance to change to a new 
attack.

Also, if there are other commands in the command buffer, they would be
executed instead, which would mean you couldn't use your pose system as 
effectively in those situations.

One other thing to note, in my system all of the commands executed for a 
round are in before the begining of the round. It seems like in your system, 
the command input may occur in the middle of a round.


> 
> > > 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.


Ah, ok, that would be cool, could easily work in either of our systems too.

 
> 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.


Hmm, if you think of them as combos, I suppose that would work. But I'm still
not sure about it. On thing you didn't mention is if they fail to hit with an
attack, is the ending position the same?

> 
> > > 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.

Having thought about it more, I think this would be a good idea.

> 
> > 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?

The agresion rating for an attacker could be raised/lowered by a number of 
factors. A few examples to explain this:

#1:
critter A hates race B, so any aggro increase to b would be multiplied by some 
amount.

#2:
critter A is fighting players B and C. B is tanking and gets low on health,
so C heals B, that would make A more agressive towards C, based on amount
healed.

last example:
critter A is fighting players B and C. B is tanking. C casts a spell which
indirectly harms A, for instance a necro curse. A's aggression towards C 
increases. 

It is possible, but unlikely to overflow an int on our system and with our
mobs using this system. But there are other people and other systems out 
there.

That's all for now.

   --Gingon