It does look like it has three legs from where I am sitting.

You could have aggressive flailing of arms, Aggresive waving of tenticles, and running towards player; perhaps casting a spell with adifferent motion...... 

I know, only the tentacle screw is hard to tend, because of the oppertunity to make them wail without getting crossed.

Also my usual three leg walk is a bit hard to lay hands on as I mostly experience this on drunk feet.

http://members.home.nl/gimli/zork4.gif 

So that's how you're figuring it out :) 

Convertion of the antlion to Quake1.
Rather a heavy model as it takes 1050verts / 2361tris.
Sad I have only the standpose with skin, so to make it worthwhile it needs a decent base frame.

http://members.home.nl/gimli/AntLion.gif

The original skintex is 256x256, as doom files.
And that was also much work to get in Qml 199 x 300.
I've been trying with odd shapes of the baseframe, but it only gives vertice loss. 

http://members.home.nl/gimli/AntLi0n.gif 

 

That Antlion is Excellent ! 

It has come to my conclusion following the response to A Roman Wilderness of Pain that it's best to just not have boss monsters at all. Personally I loved the end battle because it was immensely challenging and took me several goes to figure out, which is exactly what a boss battle SHOULD do. The whole idea of a boss is that the player has to figure out how to use all of the tools that he's been supplied with to engage in a battle that's probably five or ten times harder than anything that's come before. Tronyn's boss battle did just that -- had I not used the grappling hook to evade danger spots I would never have been able to recoup the ammo or gain the cover required to take out the final boss and win the game. Another crucial part of the strategy which I only figured out after two or three deaths was to conserve the Tome of Power until after I had activated most of the Boss moments, which thanks to the grappling hook was still reachable. To me, that's everything a boss battle should be. It required a very small amount of trial and error, but that only intensified the feeling of satisfaction at the end.

I think a lot of people are far too quick to turn on God mode as soon as they encounter a tricky situation that they don't immediately recognize, which is a shame.

There's a lot to be said for finishing an episode with an interesting or different combination of regular monsters, as it challenges those who enjoy being challenged but also doesn't scare off the people who don't. 

I think I'm repeating myself: Bosses should just provide peaks in difficulty and at most require mild variations of normal gameplay patterns. I hate when i have to figure out stuff specific to the boss battle. I love when there's several strategies to chose from and you can try to find the best. That doesn't work if there's only one that works and all other fail, though.

Recently played through metroid prime, and the boss fights kept pissing me off (mostly controls related "what buttons do I need to press in what moments to survive!?" moments though).

Good examples are the descent 1/2 bosses (except the final d2 boss, which you had to shoot in the back to kill). They have special powers like robot generation, invisibility, homing missiles, etc., but all those features also exist on other, normal robots, so there's nothing to figure out than the best way to do the most damage without getting hit. 

I agree somewhat with megaman above, but I take more of a middle stance: Boss fights should reuse and extend game mechanics that have already been established, true, but they should also be interesting and can have some puzzling elements to them. Puzzles fail when they are not foreshadowed by previous gameplay.

I think the chthon and shub bosses were good, the main problem is the game mechanics they rely on were never properly established beforehand.

However chthon was not that bad, players are already trained to look for buttons and see what they do. I think the main problem with chthon was that you can't immediately tell that he's invincible, because you will probably attack with rockets, which don't spawn blood even when they do damage. If i was attacking him with a shotgun or nailgun, it would have been much easier.... perhaps the rockets should have actually bounced off him, to make it clear.

Shub was harder because 1. telefragging is never introduced before that point, 2. the spikey ball's behavior is never introduced before that point, and 3. shub bleeds, implying that you can kill her with weapons. 

I like the Doom 3 boss battles. I'm probably dumb.

The seeker thing wasn't established before, and it seemed a bit ... "let's make this a novelty", but you are told what to do.

I like bosses like Sarge.

I like minibosses, too.

The Arwop boss battle was well thought out, I have nothing against the mechanics used. It was just over the top. In my opinion. 

Would it be a hard qc nut to refleckt the dmg of a shield back to the player, meanwhile protecting the monster? 

http://members.home.nl/gimli/hogre.gif 

AWESOME!!! :D 

a melee ogre only. 

... for a massacre :D 

a melee ogre only.

http://shub-hub.com/files/images/ogreb.gif ? 

The shield is from Dissolution of Eternity.
Seeing that double chainsaw makes me want slippery oil floors!

Blocking incoming damage is one shield purpose.
Aiming the ame damage back to the player are two.
I think it has much to do with arguementing all weapons again. 

Unfortunately the gif that someone (Lunaran?) posted a while back I have saved on another machine . . . 

Reflecting attacks is one of those things that's difficult to do in a "nicely coded" way. You can't deal with projectiles in the same way as you do traceline attacks. That breaks it into two cases, which is managable. However, my instinct would be to reduce damage from player attacks so that a reflected player grenade was no more damaging than a regular ogre grenade. This pretty quickly leads you to adding a little bit of code to each of the player attacks. Although that's not too much work, the problem is every time you need to change something, you have to make 6 or 7 identical changes all over the code. Just imagine how hard it would be to get monster attacks reflected too!

I'll try and describe all the things I'd do to get regular nails reflected correctly, which would probably be enough to get any other projectiles working. If you've understood all of the nails code, you can probably go on to do shotguns and lightning too.

So the most important bit of maths we need to do is to calculate the angle that things reflect at. We could just have the ogre send all attacks directly at the player, but not only does that make it highly dangerous, but a little bit dull to watch. I want to see a storm of nails ricochet everywhere when I spray the ogre. So we imagine that the ogre presents a sphere that the nail has collided against, centred on the origin of the ogre, and that we use the standard law of reflection:

R = 2(I.N)N - I

where R is the velocity the nail leaves with, I is the velocity it arrives with, and N is the surface normal. We find the surface normal by normalising the difference between the point of impact and the origin of the ogre. In qc this will look like:

//REFLECT CODE BEGINS
local vector I,N;
I = self.velocity;
N = normalize(self.origin - other.origin);
self.velocity = 2*(N*I)*N - I;


The next question is where to inject this code, and when to run it. I think the easiest way is to isolate the points where you are about to call t_damage, and reflect instead. So we need to modify spike_touch, within the block

if (other.takedamage)
�{
�}

In there, we detect if we have hit an ogre with a shield with something like

if(other.classname == "monster_ogre_melee")
�{
�//all of our new reflection code goes here
�}
else
�{
�//all of the original code goes here
�}

The new reflection code starts with the bit of vector maths described above(//REFLECT CODE BEGINS). We do need to think about a few other things though. We need to add self.owner = other; so that the nail will collide with the player, and not the ogre. We need to set self.touch = spike_touch_reflected, where spike_touch_reflected is a new touch function which does reduced damage - say 4 per hit. We might want to add a sound showing that the shot got reflected. We need to return; at the end, so that we don't remove the entity.

Join us for post two where I post less practical things, and instead just some possible designs... 

looking forward to post 2 :) 

Ok, so the first post was how to make projectile reflect, but I've got one bigger idea, which I'll talk about after a few one line thoughts:

� When reflecting a lightning bolt, make sure that the entire length of the bolt does not exceed 600 units. Where the original attack sends out a trace of length 600, the reflection should be 600 * (1 - trace_fraction) in length.
� If you don't add any other visual reflection effect, you ought to add impact effects for shotgun attacks, as there's no visible trace.
� There's a risk that the shield ogre will end up infighting a great deal when reflecting projectiles, so it might be worth inserting an exception for them initiating an fight. Especially useful if you don't implement reflecting monster attacks, as infighting might expose that.
� When it comes to the axe you could have the shield only parry, rather than reverse the damage.

So far, we have created a monster which is almost impervious to damage and can turn our own attacks against us to boot(splash damage from rockets and grenades will probably still kill them unless you were really thorough). So maybe it's time to put back some vulnerability, while also giving it some reaction animation which could build into interesting play dynamics.

What I have in mind is twofold: firstly adding a short "blocking" animation which triggers when a projectile gets reflected - or even better multiple interchangeable animations to provide variety. Each one would only have to be 3 or 4 frames long, starting with the shield held centrally in a defensive stance, and then a quick transition back to the default combat pose.

While taking rocket or shotgun fire, the ogre would play the animation in full, showing it deflect a single shot and then have it take a step forward before the next attack. Continuous attacks would leave the ogre unable to advance. Here, having multiple block animations would be valuable here so that it does continue to animate while under nail fire, moving from the first frame in one block animation to the next as if reacting to block each nail.

So that puts some kind of trade off on having the shield - you can't move while using it. If you were extremely clever in how you designed your animations (coupled with similarly careful code to back them up), you could make an ogre that slowly advanced even while blocking nail fire. Cool as it sounds, I'm not sure the effort expended to make it work would pay off, as the player would rarely see it happen - you've just reduced the effectiveness of the already weak tactic of expending nails to pin the ogre down.

The second part of the twofold plan is thus: once you have a blocking animation - don't block all of the time! Make it so that the blocking animation is not allowed to interrupt certain other animations. This way the player has a means to defeat the ogre - lure it into letting the guard down, and then hitting it.

So what animations do we select. Preventing them from interrupting pain animations seems wise - they're meant to be involuntary. Making melee attacks uninterruptable sounds sensible too, from the point of view of creating a smooth animation as well as a risk/reward trade off - the ogre only becomes vulnerable to damage once you've let them get close enough to attack you back!

I'd also make idle animations uninterruptable - the reasoning being that the ogre won't block attacks that they aren't expecting. This also gives you a kind of justification for not blocking other monsters' attacks - that kind of backstabbing doesn't cross the ogre's mind. it certainly gives you a large combat advantage if you can sneak up on one - between the idle and the pain animation you can probably get two attacks in before blocking comes back up!

I can think of one other way the ogre could give up blocking - if it chooses to! You might decide to write some sophisticated ai whereby the ogre decides "I've been pinned down by nail fire for long enough - I'm just going to make a charge for a second or so before I block again". The trick would be to make that decision process smart enough to be distinguishable from the ogre just forgetting to block due to really bad ai if you keep shooting them long enough - that quote about how hard it is to make enemies appear smart in the 3 seconds before they die springs to mind...

I've written more than I expected to, next post... 

 

As I was about to say, technical details on how I'd handle this:

I presented the two ideas together because they both interact, and because they can both be handled by the same system. We go back to the line

if(other.classname == "monster_ogre_melee")

and change it to

if(BlockOnRequest(other))

This is calling a new function, which does two things. It checks if the other is able to block (so if it's a monster_ogre_melee and has the opportunity to shield) and returns false if not. Otherwise, it triggers a random block animation on the monster, and returns true. So it would look something like


float (entity bearer) BlockOnRequest =
{
local entity oself
if(bearer.classname == "monster_ogre_melee")
�return FALSE;
if(bearer.guarded = FALSE)
�return FALSE;
oself = self;
self = bearer;
//select a random block animation and play it here
self = oself;
return TRUE;
}


The part crucial to the second idea (some animations don't block) is the new field we have added: .guarded. This field is set to TRUE if the ogre is ready to block a shot, and FALSE if not. In the monster_ogre_melee spawn function, we need to set it to FALSE (to prevent mappers turning it on and allowing idle ogres to block!). Then at the start of the run animation sequence, we need to set it to TRUE. At the start of a pain or melee attack animation, we set it to FALSE. We can set it back to TRUE towards the end of the attack/pain, or simply wait until we jump to the first running frame, which will activate it then. It should suffice to change it at the start of each sequence, rather than every frame, unless you have some animations which jump to run4 or the like.

And that should wrap things up. Once you get to that stage the monster should be playable, so the fun part of creating interesting behaviour starts. One way of creating that ai behaviour where the ogre eventually tires of blocking shots and charges for a bit would be to have blocking as a scalar quantity rather than a boolean value. Hitting the start of the run animation increments the .guarded value, while blocking an attack reduces .guarded to min(10, .guarded - 1). If .guarded drops below zero because of that, set it to (say) -3. Then make it so the BlockOnRequest tests bearer.guarded <= 0 . Pain and attack animations should reset .guarded to a reasonable positive value at the end.

Even without that, you should have an unusual melee monster once the player gets to grips with them. I'd love it if they had some kind of charging ability, dangerous enough to give the player real incentive to shoot them and force them to block. That might be making them a bit too complex though, it's easy to overwork a monster when you post 17 paragraphs of text... 

I was going to mention something about co-op behaviour in the paragraph where unaware monsters don't block attacks. If you have fixed monsters constantly switching enemies when attacked by two co-op players(that old exploit), you could make it so that the ogre only blocks attacks from self.enemy. As long as you pass the attacker as a parameter to BlockOnRequest, it's a easy check to make there. This would make them much easier to kill in coop though.

The other thing I just though of leaves an exercise for anyone who spent half an hour reading all that guff: What would happen if you set .guarded to FALSE for the first two frames during a block animation? Is that likely to improve gameplay given the current method of reflection?