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. 

he's in a giant wooden badger

trigger_centerprint_pythonquote 

that big motherfucking fish in HL1?
when you first met in in a crossbow cage, then again by the dam... 

see posts 32 and 38 

Bosses are best left customized by the designer to whatever he's building, yes. We see fewer bosses that way, but not every map needs one (some have them anyway!) and the ones we do are usually better for it. 

hmmm - spitting underwater?

Something scarier would be a squid or octopus, with tentacles that whip or grab, maybe a trilobite? 

the quake engine wouldn't be able to do it convincingly. heck, even modern engines would have a hell of a time with it. i guess it would be a mixture of standard animation, IK and some of the procedurally generated stuff that's starting to see some use in games these days.