 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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 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?
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 . . .
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 if(bearer.classname == "monster_ogre_melee")
return FALSE; should read if(bearer.classname != "monster_ogre_melee") return FALSE; But you all saw that, right? At this from more of a design POV, and the most intersting bit of the posts for me is the idea of the Ogre getting angry and bored blocking all the time.
I love putting in lots of logic to monster functions, of which the player only registers a tiny percentage, where the above would fall neatly. It makes me think of the Ogre getting pissed off enough to do a running charge with the sheild (still blocking) kind of like a L4D2 Charger. I need to stop playing that game - its affecting my thinking too much. That's more assambly on my plate then I can hatch, but I asked for it.
Not sure if I can understand it at once, but there's a clue how to estimate the given question. I'm not good with maths, and the only reason I'm still reading is that I feel there could be a logical scripting to make the monster do what it need. Hadn't expect that reaktion, but when I remade the Zdoom monsters I already had this feeling quake monsters could be made better. The animation frames for shielding are already there. Now screwing that grmrpf... I tried your code of 408, much further I can't follow due to errors. If I place it just after void()spike_touch in WEAPONS.QC the compiler keeps asking for a definition of the spike_touch_reflected.
void() spike_touch = { local float rand; if (other == self.owner) return; if (other.solid == SOLID_TRIGGER) return; // trigger field, do nothing if (pointcontents(self.origin) == CONTENT_SKY) { remove(self); return; } // hit something that bleeds if (other.takedamage) { spawn_touchblood (9); T_Damage (other, self, self.owner, 9); } if(other.classname == "monster_ogre_melee") { // all of our new reflection code goes here local vector I,N; I = self.velocity; N = normalize(self.origin - other.origin); self.velocity = 2*(N*I)*N - I; self.owner = other; self.touch = spike_touch_reflected; return; // all of our new reflection code end here } else { So I tried something like void(vector org, vector dir) spike_touch_reflected = { if (other.takedamage) { spawn_touchblood (9); T_Damage (other, self, self.owner, 5); } newmis = spawn (); newmis.owner = other; newmis.movetype = MOVETYPE_FLYMISSILE; newmis.solid = SOLID_BBOX; newmis.angles = vectoangles(dir); newmis.touch = spike_touch_reflected; newmis.classname = "spike"; newmis.think = SUB_Remove; newmis.nextthink = time + 6; setmodel (newmis, "progs/spike.mdl"); setsize (newmis, VEC_ORIGIN, VEC_ORIGIN); setorigin (newmis, org); newmis.velocity = dir * 1000; }; And then the compiler gives no error, only me. ^v^ It was worth reading.
Really don't have a clue where to start now. I keep trying to find a right scripture, but if I wonder where my reflected spike has gone.
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |