Could need some advice here, i wanted to implement basic mob movement into my game. My current approach is that i basically just pick random points in a certain radius to my mobs position and move it towards that point... however this has an issue. Since my world is chunk based, mobs sometimes choose and move to a point which is NOT in the loaded chunks anymore which results into them moving into "uncharted" territory and becoming lost forever basically.

I could solve this by just checking the choosen point ( if its inside a loaded chunk ) and regenerate a new point till it is in loaded territory, however im not sure if this is a nice approach... its also kinda blocking. Steering behaviours however sounds pretty cpu intensive. Are there other wandering techniques which can be easy implemented ?

Why not just load chunks within an active mob's wander radius? That way you avoid any weird biasing of mob behaviour near the edges of loaded areas.

You'd separate the concepts of loading the chunk level geometry vs populating it with mobs to ensure you don't get an infinite recursion that forces you to load everything. Effectively terrain gets loaded within radius A and populated with mobs within radius B, for B < (A + wander radius)

This video gives an example of an infinite world that's stratified into layers - content in layer 1 can depend on content in layer 0, but not vice-versa. That means you can generate layer 0 content for all tiles independently, out to a margin around your area of interest. Then you can generate layer 1 content for the interior of that area, and it has access to all adjacent layer 0 tiles already-generated/loaded.

> and becoming lost forever basically.

If the mob wanders too far, why not either move it or remove/respawn it somewhere less lost?

@DMGregory Well i thought about this... but this would mean that each mob becomes a "chunk loader" and could basically travel the world forever because it would never "deload". I only use this mechanic for players currently. Okay i just watched the video and it really could help that issue by making mobs spawn in the green area and the wander radius is covered by the grey area. However this looks incredible difficult to implement and would probably require a whole rework :/

@Pikalek That could work of course, i just hoped for somwhat more natural... like an easy algorithm which chooses a point inside loaded territory within a certain radius to the current mob position ^^ that would already solve that issue

Alternatively, don't use random - bias the movement toward the region you want

Or use some pre-calculated routes / destination points.

Some of it depends on what your design goals are.

@Pikalek You mean like detecting if its close to the edge and then just choose a point which points towards the middle of the chunk to make it move back inside ? My design goals are pretty simple... i just want to choose a point within a certain radius to the mobs current position which is inside the chunk ^^

pastebin.com/qST7FueZ thats my current approach which is kinda blocking for mobs close to the border because i try to generate a position over and over again till its inside the chunk.

I don't think you want your mobs roaming the world indefinitely. Players will generally expect to be able to find certain mobs in certain regions, and it will look to them like a bug if a mob from one region wanders into a very distant region without being kited there deliberately.

^ Also, if the player can't see it, does it matter? In some games w/ heavy simulation, it might. But usually the answer is no.

So, you'll likely want to define a neighbourhood the mob is allowed to wander. Load all neighbourhoods that are near players (layer 1), and load all terrain touched by those neighbourhoods (layer 0). Then you have a guarantee that all wandering mobs are always on valid terrain.

I was playing Diablo Immortal recently and I noticed if you kite enemies too far away from their spawn point, they'll go into a "seek home" state like chomped ghosts in Pac-Man, maintaining the invariant that every mob is always within a certain zone. This probably also helps avoid certain exploits, or performance breakdown if too many mobs get kited into one area.

Yes thats right, so mobs should usally stick to the chunks where they were generated i guess ^^ so i will probably just go with picking a random position inside its chunk and moving it there for the first

By design goal, I meant "why is the mob moving?" If the answer is basic / limited, then you probably don't need to reach for sophisticated solution. But if you're trying to mimic something more complex (guarding a graveyard, hunting prey) then it makes sense to consider those things when solving technical problems like staying on chunk.

Biasing can mean a hard stop at the boarder. But it also can mean, "the closer I get to the border, the more likely I am to head away from it".

You might need to widen that to one adjacent chunk - otherwise mobs whose spawn points are right on the edge/corner of a chunk will be much more constrained than mobs in the middle of the chunk, and that could impact gameplay.

^ Sure. I should have selected better terms / words.

For instance, players may discover it's easiest to farm in certain corners of the grid, because mobs get trapped there. That exposes something that you probably want to be a hidden implementation detail as meta-game knowledge players need to be aware of to excel.

I was thinking in terms of "area of interest". Which would probably work best as some sort of "meta-chunk".

Totally, so i guess theres no real way around the layer chunk approach, i currently just load 9 chunks for each player, 8 around his own chunk. However this requires a lot of work ^^

^ Do you mean the 1 chunk the player is on & the 8 adjacent chunks on a grid?

Yes ^^

Not necessarily. You can just choose to load mobs only within a half-chunk radius of the player. So mobs near the edges of that 9-chunk block don't spawn until the player moves close enough that the mob's chunk is now in the center.

Yeah. If a mob is on the edge of that 9 chunk zone, it's going to be at least 1 chunk width away from the player. Does it matter what happens that far away?

I mean, it could matter. But if not, a more just-in-time solution like @DMGregory suggested seems like it avoids the issue & also lowers the simulation expense.

@DMGregory That could work, however i currently have mob spawning implemented on a chunk level. Like everytime a chunk generates, mobs are generated aswell and loaded. So i need to base this on the player instead, i need to get like all surrounding chunks, its blocks/tiles and check which ones are in distance right ?

That's what I told you an hour ago: "You'd separate the concepts of loading the chunk level geometry vs populating it with mobs" 😉

But you can also subdivide your chunks and load more of them. Then a chunk can exist in three states: not loaded, loaded terrain only, loaded terrain and all mobs. It saves you from managing a state where a chunk is loaded but only some of its bobs are spawned.

Yes ^^ im already thinking about this, but the concept is kinda messy in my mind. For example... we somehow need to mark the chunk wether it has generated mobs or not... however we dont generate mobs for each chunk, just for those tiles in range. Which makes this a bit harder, do we mark each tile once a mob was generated ? Its the architecture with i still need to clarify ^^

Myself, I'd lean toward making the chunks smaller, and loading a 5x5 window instead of a 3x3. When a chunk enters the outer ring, load its terrain. When it enters the inner 3x3, load all its mobs. You can track its mob-loaded state with a single boolean per chunk, or infer it from its position in the loading ring if you have only a single player.

Great news! We got our community bump throttling enabled, so those bumps should not take over the top questions feed so aggressively during lulls in activity.

That does mean we'll have to take a more active role in seeking out those bumpable questions and resolving them if we can, since they won't be churned to the top as readily.

Catija has shared a like to a SEDE query to find bumpable questions.

It also helps to remind new users to mark an answer that worked for them as Accepted, even if it's their own, so that these don't add more to the bumpable pool down the line. ;)