When in roam, movetogoal

[scar3crow]

This could probably go just as well in the Gameplay forum, as I consider them to be crucial aspects to one another. But here we go.

One of the key things in design is a monster's position. Ogres are best above you or on level ground, not below or at the bottom of staircases - fiends are best in clean areas with nothing to get hung up on, so on and so forth. However in positioning them so finely, you want them to stay in place - but this brings about stagnation in the game world, the monsters are always in the same place and the player remembers these positions and thus figures their way around them. The memorization gets to a ridiculous point sometimes - and it removes replayability as there is so little variation.

In comes monster roaming. And out it goes again. Because its roaming.

Monster roaming strips away a layer of the predictability, adding in chance of bumping into the monster somewhere ("Funny seeing you here - oh god your chainsaws stuck in my face!"). This can create unique scenarios as not all would necessarily roam and thus can join together in different combinations. Imagine in Doom2 if you started a map, played through it and in one hallway you encounter an arch vile, and 2 areas down, 4 barons of hell, or maybe some mancubi. Battles you dont ignore - now imagine the tension that could fill the player when on a later time playing the map he rounds the corner of that hallway and.... -doesnt see the arch vile. Because the archvile roamed this time, and is now in the room with the barons. A room full of barons with the ability to resurrect is a whole different gameplay component - and it surprised the player and made that some old map a new experience.

In Unreal sometimes monsters roam, and this can cause the situation of a Skaarj walking in on you, which is just contrary to most FPS games.

A way to do this in Quake is actually rather scripted - monsters never use the waypoints that they can technically follow in ai_walk. We dont see this used so much, examples would be grunts pacing left and right in e1m1, the zombies that patrol in e1m3, and the fiend walking away from you at the beginning of e1m4 (or was it 5? Palace of Hate regardless). However longer paths can be done... Monsters can have a larger range of scripted motion, large enough to not be an obvious pattern unless the player just stalks them for the duration of it. Just imagine in e1m2 if the Ogre you see at the beginning walking up the stairs keeps going - if he crosses the bridge, takes a right and enters the silver key door room, goes up those stairs, opens the gear door (with a flag allowing monsters to open it very short term) and comes back to the bridge through the spike trap path. If he no longer spawns in front of you but elsewhere in the level, depending on how fast you move through the map, he could be anywhere - and potentially surprise the player without resorting to Monster In Closet (this should read like the collision error "monster in wall" only as a gameplay error).

So we have scripted waypoints (what Quake could do with map editing), independent waypoints (Unreal) - now what of independent routines that dont rely on waypoints?

Yes, Im asking for code or pseudo code, to motivate you people to think about such. What are some methods to get a monster roaming semi-effectively in a map to where they will actually get somewhere rather than being found in the same room, only this time bouncing around - without using waypoints.

[Entar]

If you want to get it to work without any custom map changes (i.e. work with original Quake maps), you might just have certain monsters (maybe have some of them be more prone to roam than others, especially flying monsters) try to get to other monsters' spawnpoints, and use wall following and items as waypoints to get there. Of course, you'd put in checks and such so you don't have a bunch of enemies in the water on e1m2 trying to get to the armor. In fact, you could use those patrol points you mentioned as paths to advance. These would be best because they are definitely valid paths to follow, unless the mapper was rather crazy or stupid.

Here's how I see this theory developing in my mind:

The monster starts at his spawn point, and randomly picks another one to get to. Then he goes toward it using a method of priorities, where if the highest on the list is useable, go with it, else try the next one - something like this:

1: Existing monster patrol paths
2: Other monsters
3: Items
4: wall following
5: Figure he can't get there

I'm no QC expert, so there are probably a few other things you could add to that list. After the monster gets to his destination or decides he can't get there with the information he has, he starts going back the way he came. Perhaps once he gets back to the start, he can pick another spawnpoint to try to get to, and repeat. Keep in mind that the more monsters you have roaming around, the more they might get clogged up in smaller hallways, so some extra code to let others pass, avoid clogs, etc. would be helpful here. That, or just have a 10-20% chance to be roaming at all.

These are just a few thoughts that sprang forth in my mind both as I read scar3crow's post and as I wrote the beginning of this one.

[neg!ke]

longer routes can be done, but one has to watch out for not exceeding the maxentities limit. considering an average map has about 100 monsters, it's fairly easy to do so if all of them follow only 5 path_corners.

maybe it would be better if it was possible to have a path_corner with multiple targets, so a bunch of monsters could use the same waypoints in a different order. this is pretty close to the patrol points idea. a set of waypoints in important positions (halls, crossings, stairs) that monsters can use randomly - but as entar said, clogging will be an issue.

while roaming monsters are a nice trait, it's often not desired to have them leave their position, e.g. when they are guarding a certain area or waiting for an ambush. so there had to be a flag which allowed them to roam or not, and possibly even something to control their roaming range (because it would suck if suddenly all monsters gathered in one area, while others were completely empty). for example, a monster with a range set to 1024 would only roam within a 1024 radius around its spawn location. or, with the global waypoint/patrol point thing, only use waypoints within this radius.

monsters opening simple doors might work, but they should not be allowed to open important doors, like ones that have to be triggered by a button or only open after a certain event. no key doors, either. the problem here would be the ability to exploit this feature. although, and this can also be easily done with regular means, this leads to a somewhat nice idea: the player can reach certain areas (quicker/earlier) when he stalks monsters, follows them secretly. if he is seen by this very (or another) monster, he has failed and can't pass the door, so he has to take the long route...

[Tei]

Idea. Maybe can be interesting to populate maps with waypoints, and a few monsters. And trigger the creation of more monsters on these waypoints, if the original one is killed.

No idea how to use this. Maybe you kill a dog, and fiend spawn elsewhere, you kill a fiend, and a shambler spawn somewhere. So the dificult of the map grown with you killing ability (better weapons, etc).

Yet another gadget is a "mother" or "monster generator" that you have to kill / stop. While the generator is active, more and more monsters spawn, a infinite num. Thats how these 4 players arcade game work.. heee... Gaunlet. You can even add a bit of RPG here (like on gaunlet).

I hate monsters that spawn randow, and feel like spawn randow. I am looking at you Doom3. So If some device is setup to spawn monsters on a random way, is better if the feel of randomness is negated and looks predictible. Simply randomizing what monster to spawn has this vomit effect on steroids. You know theres a monster on the next room, the original monster is a ogre, but you know is random now. And this is baaaaaad. You sould not know IF there are a monster, and what monster is.

Yet another gadget is .. as you kill monsters, spawn "friendly" units on the map. So the feel of "conquered ground" will be even stronger. Friendly units can provide ammo, health, even llimited (like the half-life pistol soldier guy Barman?)

[Sajt]

I kind of like your first idea. Although immediately my brain wants to go the extra mile, something akin to scar3crow's idea of monster hierarchies... where maybe a group of ogres is 'linked' to their commanding shalrath (who is currently away on business), who will teleport in 'reinforcements' and/or himself if he senses the ogres getting massacred. Of course this is all in the mapper's head, he just has to set up some monster spawners, not like you have to actually code in all these monster hierarchies. (Although you could... )

Monster spawners are in every game and its mother, but that doesn't mean they're bad.

However I don't like the idea of friendly units. I don't think they fit in with the Quake story (unless of course you're thinking of a PC/TC that doesn't take place in the Quake world). Quakeguys are the only folks who can survive five minutes in the bad dimensions, and an idle, NPC quakeguy is unthinkable! (Except for the guy at the bottom of Hurried Descent, he creeps me out to no end...)


Roaming is cool. I don't know how well it would work with the Quake maps, they may be too short and linear for it to work without getting monsters clumping and/or getting stuck in dumb places. Anyway, if someone (cough) went all-out and coded monster hierarchies, they could have higher-ups ordering their underlings around, using some semblance of reasoning to keep them in some sort of order (but I thought bad guys liked chaos?)

[Dr. Shadowborg]

However I don't like the idea of friendly units. I don't think they fit in with the Quake story (unless of course you're thinking of a PC/TC that doesn't take place in the Quake world). Quakeguys are the only folks who can survive five minutes in the bad dimensions, and an idle, NPC quakeguy is unthinkable! (Except for the guy at the bottom of Hurried Descent, he creeps me out to no end...)

Roaming is cool. I don't know how well it would work with the Quake maps, they may be too short and linear for it to work without getting monsters clumping and/or getting stuck in dumb places. Anyway, if someone (cough) went all-out and coded monster hierarchies, they could have higher-ups ordering their underlings around, using some semblance of reasoning to keep them in some sort of order (but I thought bad guys liked chaos?)

NPC's: Agreed.

Roaming: It's cool, but to a certain extent it takes control away from the mapper. Scripted waypoints and patrol paths are much better. Perchance the old frikbot .way file system for preexisting maps?

Monster Hierarchies: Unless you're using multiple variants of the same monster, I can't see it really making all that much sense. I picture most of the monsters as being loosely tied together in mutual hatred for the player. Grunts for example are insane. No commanders there. Enforcers, Ogres, Knights, and Death Knights would fall under some sort of command structure, but they would hardly be commanding more feral beast like monsters such as Fiends, Vores, and Shamblers. (Translation: I won't do it for Faerie Journal or DGtM.)

[Urre]

...What are some methods to get a monster roaming semi-effectively in a map to where they will actually get somewhere rather than being found in the same room, only this time bouncing around - without using waypoints.

Do dynamicly spawned waypoints count?

[frag.machine]

My 0.02$ (put your currency here)

I understand that the goal here is to add some replay value to maps. And monster roaming is not the only solution, and not even the easiest to achieve. There's another simple but powerful way to give new life to old maps: randomness.

Some time ago I wrote some QC code to create a func_remove entity to standard progs.dat. Basically, you add a .removename field to the entities, and one (or more) func_remove to the end of the map. When this func_remove spawns it removes (or not) any entity which .removename = target (a variant func_remove I wrote later had two string fields - remove1 and remove2 - and randomly removed either one of the entities group). Thus, every time the map is loaded a different scenario is brought to the player: for example, you could spawn in a room with one, two, or no ogres at all. The same being applied to items, health, func_walls - any entity. Later I will dig my dusty .qc test files and post it here, maybe as a complete tutorial with a sample .map (no batteries included though).

[Lardarse]

I understand that the goal here is to add some replay value to maps. And monster roaming is not the only solution, and not even the easiest to achieve. There's another simple but powerful way to give new life to old maps: randomness.

There's an issue with saved games unless you do it correctly...

[frag.machine]

I understand that the goal here is to add some replay value to maps. And monster roaming is not the only solution, and not even the easiest to achieve. There's another simple but powerful way to give new life to old maps: randomness.

There's an issue with saved games unless you do it correctly...

Really ? I confess I did not tested this. I'll check it.

[Lardarse]

The problem occurs when after you load the saved game, it loads the precches in a different order, and that causes the models to be completely wrong.

[scar3crow]

Urre; Dynamically spawned waypoints are different to me, since theyre placed automatically and by the game logic, and not a human individually placing them.

[Entar]

The problem occurs when after you load the saved game, it loads the precches in a different order, and that causes the models to be completely wrong.

One technique I've used in vr2mod is that certain monsters have a small chance to be altered (grunts, enforcers), giving them different weapons, slightly more health and an altered .colormod. This seems to work just fine (tested it earlier when I saw your comments).

While I'm posting here, I might as well mention some work that frag.machine and I have been tinkering with, concerning roaming. We opted for a simpler technique than what I suggested before, mostly because I'm just a noob QC coder. Basically, what I've done (frag.machine may have taken things a different way i his code) is in ai_stand, if the monster does not have a target (used for path_corner), and if self.roaming == 1 (which has a chance to be set to 1 in walkmonster_start), then just sorta... walk. Straight. And of course, there's like a 1/3 chance to change direction. From time to time, you may find a grunt doing something stupid, but for the most part, it works pretty well, and you find monsters in places you normally wouldn't see them, which throws the player off. I also gave each monster a different chance to roam, somewhat based on their personality (dogs have a much higher chance to roam than, say, fiends or shamblers). All of this will be included in the next release of vr2mod, whenever that is, so you can try it out for yourselves.

[frag.machine]

BTW, here's my last version: (tested with plain vanilla QC code):
http://www.inside3d.com/pastebin.php?action=show&id=138

Now monsters randomly start to walk for a bit, then stop for a while, then start to walk in another direction... in E1M1, dogs wander for really long distances, but the grunt nearby the megahealth always goes for a swim (I could fix it, but I am really lazy, and TBH I don't think it's worth the effort). Entar: If you want to improve it, try to make some check before moving for water and walls, changing yaw if needed. Overall, a good trick with relatively small code changes.

[Urre]

Urre; Dynamically spawned waypoints are different to me, since theyre placed automatically and by the game logic, and not a human individually placing them.

Aye. You also said something very interesting there, which is "by the game logic". One common misconception I hate is that people think "dynamically placed waypoints" means "player running around the map dropping breadcrumbs". That's just one way to do it. It has its benefits, but generally speaking it's a bad way to do it. It often spawns too many waypoints, and sometimes drops in bad locations, since almost all implementations I've seen of it are rather bad. I can't think of a single implementation of dynamic waypoint spawning which doesn't remove redundant waypoints (in an intelligent manner). Before I started working on my current stuff, I was working on just that, intelligent redundant waypoint removal. It was coming along fairly well. That part was in fact done. What was missing was waypoints re-aligning themselves in hopes to reduce travel distance and perhaps finding more links

I mostly stopped working on it cause I was doubting anyone but me using it, qc modders seem to like doing things themselves, their own way, unless it's a super-advanced ready-to-use plugin thing like FrikBots.