I immediately thought of the shark alien from half-life, that thing made you actually fear the water because it was faster than you, and having chunks taken out would completely disorient your view making it harder to escape. A monster like this in Quake would actually fit right in if used sparingly. It would obviously need a suitably dark design, maybe a giant relative of the rotfish with oversized head, eyes and jaws. 

A monster that spawns with and/or can create killer satellite objects that orbit the monster. These orbiting satellites can shoot at nearby players or possibly incoming fire, much like Chmmr zapsats from Star Control 2. The bloodcube from Zerstorer does this for the player, but it is overpowered.

Also, monsters with a special, glittering screen so that anytime the player hurts it, an energy missile is automatically shot back at the player. 

to choose one option from the list then wall/ceiling climbing would definitely get my vote. In fact I'd like to see that applied to Vores, or perhaps a variant. VoreLords?

This might involve a bit too much of a shift in Quake's AI, but what about a 'commander' style monster that organized the troops? As long as the commander is alive and in the vicinity of a battle there would be no infighting and he could maybe even have some defensive powers, such as summoning a shield around one of his soldiers. 

Yeah, or a monster that has no attack, but orbits another and heals it as it takes damage.

For a big underwater creature a cthulhoid monstrosity would be good, but a fucker to animate. 

As long as the commander is alive and in the vicinity of a battle there would be no infighting and he could maybe even have some defensive powers, such as summoning a shield around one of his soldiers.

If you also got the minions to instantly turn on one another in a spasm of violent power bidding, replay value would be added by simply seeing how many you could leave alive for the event. 

Ok, I'll leave that to you guys then.

Well, don't feel I'm trying to claim dibs on monster designs here. I'm just letting folks know that there's a ton of stuff that's been in potentia for a long time.

I will never allow Quoth to be dictated by popular opinion, but since certain monsters seem to be the biggest controversies or objections to Quoth I might as well pitch concepts into the conversation where it seems people are already thinking about them.


Bad explanation, but you know what I mean.

Indeed. I think the frequency of water deep enough to fight in might also have been a factor - the effort required to make a larger swim monster might not be well spent if deep water occurred only rarely in the game.


a suitably dark design, maybe a giant relative of the rotfish with oversized head, eyes and jaws.

I was planning a rotten, zombiesque version of a deep sea angler fish.


fear the water because it was faster than you, and having chunks taken out would completely disorient your view making it harder to escape.

I think Half-Life's water fogging also contributed to the appearance of ichthyosaurs. The second room in which you encounter them - after the initial debut with the shark cage - was a machine room flooded to great depth, and murky. There's a kind of vertigo one experiences when looking down into apparently bottomless water, and this room nailed it.
Couple that with the slidey breaky catwalk and narrow choke points for escape from the water and you have real phobia-like aversion to even getting into combat in the first place.

However, the plan for the Quoth equivelant was not for a monster that swims faster than the player, but rather something slower but with some sort of spitting ranged attack and a fearsome melee bite.
Would players prefer an icthy like monster instead? Why? 

For a big underwater creature a cthulhoid monstrosity would be good, but a fucker to animate.

not as hard as you'd think. i'm currently creating a bunch of marine type creatures with fins and tentacles and stuff and you can pretty much automate most of that with scripts. as long as you have a decent hierarchy, you can just use springs and never even have to touch those parts. 

as a variation on teleportation. Instead of popping in and out from one place to another, they achieve a state of semi transparency* with their movement increased by a factor of three. Nearly impossible to hit in this phase, but they are also unable to attack in it as well.

Transparency can't be done in the unmmodded Quake engine except for sprite. Perhaps switch to a Sprite entity for a phase out? Then again if sprites only use masking, it may still be a no go. 

Well, don't feel I'm trying to claim dibs on monster designs here.

Not at all. I'm going for more a of a rework of the original monsters anyway, and my ghoul idea was never a firm plan either - I'm still learning the qc.

Blinking - I'm thinking of this for the Scrags. 

Making attacks not register in one direction possible in the quake engine, although it would take some rewiring of the t_damage function to make it happen. The outline of what you need to do is:

1) Get the v_forward vector of the monster's facing angle(here we are assuming the shield faces straight forwards, feel free to substitute another angle when calculating v_forward)

2) Normalise the vector of the offset between where the damage is being taken and the origin of the monster. This step might be non trivial although the origin of the inflicter would probably work in lots of cases.

Note that for shotgun pellets that won't work too well, since it should matter where you aimed them, but this method would always find the vector from the player to the monster, rather than from the point of impact to the monster's origin. t_damage doesn't know anything about that, so you might have to rewire it with an extra parameter, which is a pain.

3) Take the dot product of these two vectors. If the result is less than, say 0.1, then don't do any damage. This effectively blocks attacks in a cone of angle arccos(0.1) in front of the monster. Increase this number to narrow the cone.

Doing a bit of a cone helps to make edge cases where you're directly above the monster go away. If you aren't too bothered about that, then you could reject if the dot product is negative, a full 180 degree frontal shield. If you do that, one advantage is that you can skip the normalisation.


That's the basic idea, but two other complications spring to mind. One is that you've also got to worry about not spawning blood when you hit the shield - since that isn't decided by t_damage but just by the entity's takedamage type. It would be a lot easier if t_damage returned TRUE when damage is done and FALSE otherwise, but that's another one of those big rewiring changes.

The other problem is that quake monsters are fairly relentless in their attempts to turn and face you, which makes an invulnerable shield to the front quite a formidable obstacle. Once you've got a rocket launcher you can start splashing them from behind, but with weaker weapons you might struggle. You could give the monster greatly reduced yaw_speed, so that a player could out-turn them long enough to fire.

A possibly better alternative would be to give the monster some kind of attack where they stay facing the same way for a number of frames. A straight line melee charge would be the most natural example. That way, if you succeed in avoiding the charge, there's a moment to return fire before they recover to turn and face again. 

The chop attack might be slow and avoidable but that's somewhat compensated for by the guard not actually needing to hit you, nor scarcely get near you, to do damage.

Same with the Drole or whatever it's called. I'd rather that got fixed before new monsters were introduced. 

I thought of that approach, but the thing I don't like about it is that if you're looking at the monster from the side he could have plenty of exposed meat, but since you're still inside the cone none of the shots do damage. You'd need to be able to fire past the shield.

I want to go overboard and, say, for every frame of his animation define a point and vector for the center and orientation of the shield (so he could lift it when defending and hold it to the side when attacking). Assume the shield has a certain radius, and when a damage trace hits it, do a further comparison to see if it goes through the circle. If so, bullet puff, else, blood.

Yes I'm mad and it would take tons of rewiring, and the math might be beyond quakeC, but nothing ventured, nothing gained, right? 

I'm a QC nub so this is probably an atrocious suggestion, but couldn't a separate, impenetrable entity be attached to the front [or wherever] of the monster? 

Wolf3D's spirit-hitlers fired a dense chain of little fireballs that moved really really slowly but were very very nasty to touch. You can almost look at Quake as being like a 3D shmup like Contra, where it's all about finding the non-lethal places to be standing at any given instant. When you look at it that way, there's a whole range of attacks waiting to be tried.

an Ogre that pisses on the player after killing them (thanks Romero).

I just want to say I'm glad they didn't put that in. 

All collision in quake is based on bounding boxes, so unless the monster held his shield perfectly vertical and axial and also it was a rectangle you couldn't really make that work. 

Fascinating discussion. Only thought at this time of night is re: the giant underwater enemy. Would it not make more sense to add something like this as a boss entity rather than a standard monster (given the somewhat specialised environment required and the gigantic nature of such a beast). Something kinda like Shubby, but bigger and with actual attacks (although I'm unsure whether making it mobile would be good or bad).

Hell, for that matter, why not start adding a range of original bosses? While I agree there are still some gaps in the monster load out, there comes a point where you're just adding gimmicks and the modelling/coding time is better spent on something else (hence, bosses).


Oh, and slow swimmer + ranged attack seems a better idea tbh, altho alternate skins and some simple ai changes would allow both fairly easily... 

If it's all implemented right, then it really should be about the intersection of that cone with the surface of the hitbox of the monster. So you could be inside the cone yourself but aim a shotgun shot into the back half of the hitbox and it would register. You just need to make sure that you use the impact spot not the player origin, which the standard QC isn't set up to deal with but can be written if you're willing to change t_damage. That's only a big deal because you'll have to change dozens of references throughout the code to it(!).

If the shield angle is going to change each frame, then it's probably best to have a vector field on the monster storing the normal vector of the shield. Each animation frame you can update it with a function that adds the monster's yaw to the known angle from the corresponding frame, and runs that through makevectors, into the storage field. That's also much faster for computation, it saves you doing makevectors for each call to t_damage in any frame, shotguns might generate multiple hits.

This does remind me a little bit of a quake mod I made back in the day where you hunted vampires. You had to actually aim for their heart with the stake in order to blow them up into dust, and it used a similar trick. Although in that case it was more checking if the point of impact was within a certain radius of the heart. The heart was located simply by doing a quick offset from the monster origin to the left and up a bit. It worked pretty well as I remember, especially considering quake has such crude boxes to start. One thing that made it work was that relative to the origin the heart didn't really move, a mobile shield might be more exposed. 

he's in a giant wooden badger 

i think the shield idea isn't worth it considering all the hackery involved.

personally, i don't even think it's that great an idea anyway. painkiller had monsters like that where you couldn't hit them if their shield was blocking you, and they were just annoying. i know, weak argument, but look at it this way, you'd only ever be able to use them in large areas. if you had them in a corridor, they'd be impossible to kill. 

I was thinking more along the lines of plaer death cams, like in Undying. Every enemy had its own little kill sequence. The skeleton sticks in the mind for ripping the player's heart out.

HL1 had these to a degree as well, the alien grunt feeding on the player's corpse.

So maybe when the player is killed by a zombie instead of (just) the message we'd see the player's corpse gibbing and leaving behind a zombie. 

 

loved the way that the monsters ran across the ceiling (and flanked you) 

The chop attack might be slow and avoidable but <...> Same with the Drole or whatever it's called. I'd rather that got fixed before new monsters were introduced.

Both of these have been changed in Quoth part 2. We shortened the melee ranges, reduced the runspeed of the dguard and the dmg of the drole tentacles too iirc.

Sorry to be a tad blunt, but you can blame necros for the earlier versions :P He had an almost relentless drive to make every monster a death machine, partly because he is so good at SP himself and partly because of inexperience. He'll have to forgive Preach and I for nerfing his creations for the sake of us mere mortals.


the Drole or whatever it's called

What is it with learning the names? It's written on the webpage. It's printed on the screen if one kills you. It's only five letters, and one syllable. Anyone would think you're trying to not learn them. 

couldn't a separate, impenetrable entity be attached to the front [or wherever] of the monster?

The SoA scorpion has an invisible bbox in front of it that, when damaged, triggers the monster to strafe. Preach brought this to my attention working on the Quoth base content, and fixed some issues the feature had. Maybe he can elaborate on its relevance to your suggestion.

All collision in quake is based on bounding boxes, so unless the monster held his shield perfectly vertical and axial and also it was a rectangle you couldn't really make that work.

The box only has to reasonably approximate the model. After all, the monsters themselves are only boxes when it come to weapon impacts, but we're all used to exactly whereabouts we need to shoot them, and don't seem to mind that it doesn't line up exactly with the polygons.


The design for this 'shield' business should, imo, be monster_juggernaut. A creature similar in appearance to the D3 pinky, also perhaps like the GW juggernauts of khorne. A brutish quadruped like an armoured bull/rhino, an organic tank-on-legs. Like the uruk-hai berserkers from LotR, they would be heavily armoured at the front only. Their behaviour fiend-like in that they would charge ( though not leap ) causing dmg and even pushback on contact, but very slow at rotating to change facing. A successful dodge by the player allows them to shoot at the sides or rear of the juggernaut while it slowly wheels around for another charge. The shield is not invulnerable, but perhaps reduces dmg by half and negates splash dmg, a la the cross of deflection.
There must be monsters of this sort in other games, surely...?

I thought of that approach, but the thing I don't like about it is that if you're looking at the monster from the side he could have plenty of exposed meat, but since you're still inside the cone none of the shots do damage. You'd need to be able to fire past the shield.

But the cone doesn't have to be 90� does it? Can't it be narrower, as narrow as the model implies?
I think you're thinking too literally about a 'shield' - just make the monster armoured at the front. Actual wood/metal shields would be too difficult to line up with quake's collision detection and tbh I think they're too medieval and not quakey enough. We have the death knight and reskins, isn't that enough generic medieval? :/ 

Only thought at this time of night is re: the giant underwater enemy. Would it not make more sense to add something like this as a boss entity rather than a standard monster (given the somewhat specialised environment required and the gigantic nature of such a beast).

Why would it have to be any larger than an ogre? Who said it had to be that big?
And no, making it a boss monster only reduces its use further.

What I intend is a monster that can be used to make a single underwater area dangerous to enter, but safe once that single enemy has been defeated. See the watery areas of e2m5rmx. A single 'bigfish' in one of those areas, patrolling back and forth in anticipation of feeding time, would make falling or diving in of greater consequence, but solved with a single combat of around fiend -> shambler difficulty.

Another location would be in a remix of e1m4, inhabiting the main pool and guarding the cavemouth that leads to the silver door.

At present, the only option for areas such as these is a shoal of rotfish, which is a totally different type of combat. Less dramatic and arguably less fun.
Why would an ogre sized fish in these locations need to be a boss monster?


Hell, for that matter, why not start adding a range of original bosses?

Well necros and I would like to have added other boss monsters to Quoth. Some obstacles though:

1. Making new models, and especially animating and skinning them, is a lot of work. Really, until you've tried it yourself you have no idea how much work it is. For comparison, making the gug was as much work as building red777, and necros was doing some of it too.
The vermis was actually easier - 6 days plus a weekend of feedback from RPG - but it is a noticeably simple design.
You want more complex than that, and we're going to need a good incentive and a long time to achieve it.
It's on the cards, but it sure isn't top of the deck.

2. Limited useage. Boss monsters do not have as much fun to be extracted as normal monsters. The vermis is supposed to solve the problem with chthon and shub in that it has no special method to kill, so there's more a mapper can do to make their use of the vermis different in their map. But it's still limited.
Boss monsters are only really going to be used as a one-off climax. Considering the above mentioned workload, it isn't an attractive ratio of work/usage.

3. Mappers want boss monsters that fit their personal epic vision. We could end up pouring time and effort into a boss monster that everyone promptly turns their nose up at. Time and effort that could be spent on other monsters or content.