neg: interesting, but i don't know how you could get it to work in both SP and MP.

if you provide an out in SP to avoid the chthon ball, other players in MP will just let you use the SP out. you'd have to specifically disallow the SP out in MP and then you've got a mechanic that behaves different, which is ok, but not great. :( 

I meant it more as an attack the boss uses only in coop mode. If that's possible.. 

oh yeah, the coding side of it is quite simple. you just check if a var 'coop' is set to 1.

mechanics that are different in sp and mp are ok, i guess. in WoW, you can opt to run a dungeon in a 'heroic mode' and bosses and mobs are significantly harder with different abilities. a fair comparison if you were doing alternate mechanics for q1sp/q1coop.

for me, that's more of a plan b. ideally, the mechanic should somehow scale with the players on it's own without requiring alternate abilities.

the key then, i would say, is focusing on the players and not the monster's attacks. or at the very least, giving it an attack like a chain lightning that is technically active in SP mode, but you would just never see it unless a monster was nearby. and then that might even be a viable strategy to take out extra monsters. 

just was thinking of this...

it might be interesting to give the player access to an infinite supply of quads and pents.

then have the boss have the ability to 'steal' the powerup off you and use it himself.

would be an interesting risk/reward where grabbing a quad would let you take him down real quickly, but at the risk of being on shotted.

pent would be more annoying though... it would just take longer to kill. 

...in one of Tronyn's episodes I think...

You had to grab the pwoerups before the boss or he took you to pieces. 

no, the boss has the ability to absorb the powerup off of you. you would have the option to not pick up the item and take him out the long way, or risk picking it up and then have him absorb it a little later and one shot you.

of course, if you were amazing at dodging whatever attacks it had, then you'd be home free. 

If the boss had a homing attack, launched an attack at each player simultaneously and each hiding spaces was only big enough for one player, that would at least make things more stressful with more players? Might work? 

That's interesting. Maybe allow multiple quads - each one affects you both, so if you're very fast you can pick up all 6 (?) and one shot the boss - but one hit from him and you're splattered as well. 

might be cool, but i wouldn't want to change how the quad damage functions.

maybe make a new powerup that can have a cumulative effect and use that instead. 

i kind of like that. the thought of all those players scrambling for the same cover makes me smile. :P~~ 

what it would be like if a boss was balanced around it fighting another monster (or monsters) while it fought you?

say you made a gimmick monster like the one i talked about where you have to kill both at once or they return to full health. or even an anti-boss monster that has special abilities solely for fighting the boss.

a special aggro system would need to be written for the boss to handle this type of combat of course, and the 'helping' monsters would need a special ai as well, so they would go back to attacking the boss after being attacked by the player (so that one missed shot wouldn't mess up the whole thing).

then you could either weaken or remove the monster in coop without affecting the boss itself. if the helping monster was accomplishing a role, it would let you know what other players need to do in coop when it is not present. 

I'm 'working' on my own progs, and was thinking about implementing something like threat from WoW for coop. It obviously wouldn't be as complex (it's not complex to begin with, but I can't think of another adjective) as threat in WoW. Any thoughts? 

that idea was already being discussed. I should have read before posting. 

i've done this for an unreleased coop mod.

it didn't function exactly like WoW's threat, mostly in that it wasn't cumulative.

in WoW, threat is a number that always goes up.
in quake, this doesn't make much sense because multiple players aren't going to engage a monster all at once, one may start and another player may join in later.

so you need a system that will allow for random players jumping in, yet it can't be too finicky such that a player can fire just one shotgun blast and pull aggro off another player who's been firing nails for the last 6 seconds.

what i ended up doing was having threat decay over time based on a few factors such as distance to the player, time since the monster was last able to attack and visibility of the player.
monsters with melee had special modifiers for melee range so that if you walked near a melee monster who was fighting another player at range, he would change to you. 

I've played with this sort of thing but haven't yet arrived at an adequate 'anger' meter for monsters. I was trying to use it for scaling attacks and combining too few variables.

Health (being low on), attacks received recently and skill level. This could be applied to each player, or even all potential targets to define not only the attack used and its relative strength, but who to attack.

Means rewriting a large part of ai.qc though.

I can imagine a finished version allowing the coder (or mapper in the case of our NPC's) a personality profile that would control its fighting style.

Probably overkill, but it would allow for more complex behaviours, like retreating. 

I was thinking of doing this: if the player gets within a certain viewing distance, the monster gets aggro'd by the player. That would give the player some threat, lets say +1, with the player starting with 0. Then if the player starts attacking the player, add some more threat, +x. If the player doesn't attack, and runs away, the monster does what they do now, and if they can't catch the player, they go 'home' and reset threat to 0.

If you have multiple monsters, they can pull each other, attacking whoever has the most threat. I'll think this over more tomorrow. 

i came to the conclusion that it's really not necessary.

first of all, most monsters never live long enough for threat to matter.

second, since there are no classes (and thus, no tanks vs dps) there's really no need to worry about who is being attacked.

the only important thing is to create an intelligent system to prevent ping ponging monsters when being attacked by more than 1 player.

after that, a simple secondary targetting system to spice things up every once in a while is all that's needed.

the only place where i'd see a true aggro system being worth it is for a boss fight. in that case, you should be designing the boss around the aggro system, and not the other way around. 

I forgot to mention that I was mainly thinking about bosses when I wrote my previous post. I know I said 'monster' a lot, but I was thinking of bosses. 

i wanted to mention because there was some talk a while ago regarding quake's shotguns and how they suck.

there's a pretty serious bug with all shotgun type attacks involving the method id uses to combine all the individual pellet damage calls into one big call.

in case you're wondering, this is what id did: (heh)

when a shotgun is fired, a loop runs where it traces each shotgun pellet.
however, instead of dealing damage each time in the loop, the progs starts up a counter (which is always reset when a new shotgun shot is fired).
each time it compares the target it hit last time with the new one. if the target is the same, then it just adds the damage to the counter and moves on. if it hit a different target (your shotgun blast hit two targets), then it dumps the current damage into the old target and starts a new count with the new target.
this keeps going until all pellets are accounted for.
note that, because shotgun spread is random, it's actually possible for pellets to hit two targets in such a way that each pellet is forced to dump damage individually anyway.

anyway, the bug is that there is no check to see if the current target is going to die from the next pellet.
what this means in game is that, if there are two grunts, one in the back at full HP and one in front of that one with 1 HP, even if you blast the nearly dead grunt with the SSG, all the pellets will hit that grunt and none at all will hit the grunt behind it.

this has the effect of giving the SSG the ability to gib enemies, but at the same time, seriously nerfs the damage that it can cause.

in doom, you can line up 3 or even 4 zombies and take them ALL out with a single SSG shot. in quake, you can even take out 2. :(

so yeah, while the quake SSG *is* indeed weak, this bug further gimps the weapon by not allowing pellets to pass through dead targets.

this is also why mods that have included more powerful shotguns still feel weak. even if you made a 20barrel shotgun, a single monster with 1 HP would stop all pellets.
note that the riot controller from zerstorer sort of got around this problem by delivering two separate shots.

the fix is actually really easy, and it bothers me that id didn't notice it. it does require creating a new helper get function.

here's the original code:

void(entity hit, float damage) AddMultiDamage =
{
if (!hit)
return;

if (hit != multi_ent)
{
ApplyMultiDamage ();
multi_damage = damage;
multi_ent = hit;
}
else
multi_damage = multi_damage + damage;
};

note the last else statement. this is what we need to change.
first we need to make a new function to find the effective health of a target:

float(entity e) getEffectiveHealth =
{
return e.health + (e.armortype * e.armorvalue);
};

this function takes into account any armor the target has and translates that into health.

now, we change the last else statement from this:
else
multi_damage = multi_damage + damage;

to this:

else
{
multi_damage = multi_damage + damage;

if (multi_damage > getEffectiveHealth(multi_ent)) //this hit would kill the current multi_ent. apply the damage now and start a new count.
{
ApplyMultiDamage ();
multi_damage = 0; //reset accumulation count.
multi_ent = world;
}
}


now, instead of just continuing to add damage to the multi_damage counter, first is checks if the current damage pool + the incoming damage would kill the target, if true, then it goes ahead and does the damage and then resets the counter and the entity container so the next time addMultiDamage is called, it will start a new tally. note that this does mean it will cause a dummy ApplyMultiDamage with 0 damage on the world, but there's a check in T_Damage that will stop that call right away before it causes any trouble.

the only unfortunate side effect is that you don't sometimes gib low health targets. but the plus is that the SSG is now a little more effective.
note: quadded SSG shots still do gib zombies. 

This could be real improvement to add this code part ! Let's think about put this in Quoth 3 ;) 

Our SSG is more Q2 in style (slower firing, heavier damage, wider spread), but that bug got past us as well.

Railgun style shotguns were considered, but abandoned.

Seems like we missed an important piece of the puzzle. 

> in doom, you can line up 3 or even 4 zombies and take them ALL out with a single SSG shot.

That is just overpowered, IMO. The result is that you'll rarely use another weapon anymore.

Regarding the 'bug', hmm, needs some testing I guess. 

But when this is done well it makes the weapon very satisfying to use.

The shotgun in L4D1 for example was great, the power being offset by its slow reloading.

Shame they consoled all the weapons for L4D2. 

This was brought to my attention today; however, the more I look at the code, the more I'm sure that it doesn't do what you want it to do.

The mess that is the shotgun code originally does this: For each pellet in turn, if the pellet didn't hit the same thing as the previous pellet, the previous thing hit gets all of its damage applied to it now.

This ensures that all of the damage goes to the right victims, but often in small chunks instead of a larger chunk. Which means that enemies that should (in theory) gib sometimes won't.

This can be demonstrated by lining up a quad SSG shot at 2 zombies standing right next to each other, and aiming directly between them. 38% of the time, neither will gib. (It needs 4 pellets in a row landing on the same target, to do the 60 damage needed to gib).

Assuming no changes elsewhere to the code, all your code will do is apply the damage needed to kill before processing the other pellets. Which will prevent that monster from accumulating enough damage to be gibbed, as the check to gib only happens when the monster takes lethal damage (and after that, Killed(), which calls .th_die sets .takedamage to DAMAGE_NO). Meaning that they won't gib unless the damage from that pellet is enough to take them below gib health.

What it won't do, is prevent all future pellets in this attack from hitting it. They still will. At least, not without changes elsewhere...

If you want future pellets to hit whatever is behind, you need to have the monsters become SOLID_NOT in their .th_die functions.

If you want Doom-style damage passthrough of the remain damage within a pellet (Doom does this for all bullet attacks, and the shotguns fire multiple bullets), then it's a little more complicated, but having the pellet traceline after every point of damage almost gets you there.

If you want future pellets to not be aimed at that monster, it's much more complicated. You're on your own on this one, because of the potential for runaway loops.

If you weren't trying to do any of that, then what were you trying to do?

Also, your implementation of getEffectiveHealth() is incorrect, as it doesn't account for health running out before armor does. Not an issue for most monsters, of course... 

It could be that getEffectiveHealth could account for zombies and make it so that their effective health was considered to the level which would gib them rather than kill them - a special case. The function would need to consider armor correctly as you say, so returns false if either armor+health> damage or health*(1-armortype)>damage (this may have an off by one bug if the rounding is not done correctly, not bothered to work that through). Also in Quoth there's the case of the 50% damage reducing shields - you can see why the decision gets delegated to a function.

None of this fixes the existing zombie bug. The way to do that would be to have each entity accumulate damage on fields, and add a new field like .chain to create a linked list of everything that took damage from the shotgun shells processed so far. Then until something passes the effective health test, you just accumulate things in the linked list. Finally, you work through the whole list applying damage which wasn't taken. Now your only problem is that monsters often aren't non-solid in the first frame of their death sequence...