Wilderness encounters
Goto page 1, 2  Next
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Tue Aug 30, 2005 12:09 pm    Post subject: Wilderness encounters Reply with quote

Rather than having mobs wandering around the world, I spawn them on the fly as needed. The mud does this by checking the terrain type upon which the mob is going to appear, and picking one of the mobs appropriate to that particular terrain - for example if the terrain is mountain you might get a hill giant or a mountain troll, while forest terrain might net you a dire bear or a treant. Each piece of terrain has a monster list, often with quite a large selection of mobs to pick from.

The drawback with this is that is seriously discourages exploration to find specific mobs, because every patch of forest, ocean, desert, etc, has the same chance of spawning each mob type. Thus I've been trying to think up ways to divide the mobs up, much like most muds do with areas, so that different monsters can be found in different parts of the world.

One idea would be to assign each 'zone' (which is a 2x2 mile section of world) its own mini list of mobs. This could either include a list for each terrain category (ocean, lake, river, volcano, marsh, plain, forest, mountain, desert and city) or perhaps just a subset - or maybe even have just a single list, but make it only available for 1 or more terrain categories (eg nagas might appear in lakes, rivers and forest), although that might be a bit limiting (the plains and mountains in that zone, if any, would be noticably empty).

My concerns with this are that it breaks up the population rather artificially (i.e., no continuity between bordering zones), and also results in a huge amount of repetitive data (hundreds if not thousands of zones containing potentially the same lists, just reorganised a bit differently).

Another idea would be to specify coordinate-based 'boxes' within which mobs of the specified type could spawn. I'm a little concerned about the efficiency though (the random encounter check is done rather frequently, and with a large world there could end up with hundreds of potential overlaps to go through while assembling the random encounter list).

A third option would be to have a sort of 'population map' which fitted over the existing world, and which kept track of different mob populations (effectively a counter of how many mobs exist at each location). This would be particularly cool from a dynamic world perspective, as certain mob types could expand and fight each other, while others could be wiped out in certain geographical locations.

I'm not sure how well this idea extends to such a combat-oriented mud design though - I wouldn't want certain species of mob to be destroyed entirely. But perhaps certain zone locations could be designated as 'home turf' while others could be expanded into, allowing a sort of compromise. Still, this approach could get out of hand with large numbers of mob types, and an alternative would still need to be found for the on-the-fly generated world.

A fourth option would be to create dozens/hundreds of different monster lists, and pick one psuedo-randomly based on the x/y position (but not the type) of the zone. Thus each list would be used at multiple locations around the world, although the monster types available might still vary (for example the 'troll encounter list' would only give you sea trolls if it was used for a pure ocean zone, and only forest trolls if it was used for a pure forest zone, but if the zone contained both forest and ocean then both troll types could be encountered).

The drawback with this is that each time a new list is added, the location of the mobs would shift around. It would also make it infeasible to intentionally position certain mob types in certain locations, thus you might end up with a mountain range packed of extremely powerful storm giants right beside the starting location (unless each encounter list was actually a set of lists of varying power level, with the one used being based on how far from the starting point it's actually being used - but that's starting to become a LOT of work). Or perhaps the lists could be stored in difficulty order, with a subrange selected based on how many zones out from the centre you are - eg generate a number in the range 1-100, add a difficulty factor (0-100) based on how far out the zone is, then use that to pick which of the 200 lists are used...

Any thoughts or suggestions?
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Tue Aug 30, 2005 7:02 pm    Post subject: Reply with quote

In my to-be-built world, the 'civilized' races have built up towns that naturally begin destroying the local population of 'truly dangerous beasties', much like the real world. Either all your nearby dragons die, or you do.

So while each terrain type has a set of possible mobs that can spawn near it (I allow circular terrain overlap, except for land-based onto water-based) the spawning is primarily modified by how distant the room is from any major civilization (using a global coordinate system made this easy, it'd work easily for your system too, IIRC). So within a 1 mile radius of the town, you're fairly likely to find squirrels, birds, and rats. Between 1-5 miles, you're fairly likely to find squirrels, birds, wolves, and rats. Between 5-15 miles, you're fairly likely to find birds, wolves, and some moderately dangerous monsters. Outside of 15 miles from any town, there really aren't any limits on what could be there. Some spawnings require their own domains however - a dragon's lair cuts down the local population of wolves too (they count as a civilization for those purposes, though only affecting a limited distance). Finally, a couple monsters must be at least x miles from town (the most dangerous of monsters can not be found near town, but rather 60 miles away or some such).

I like this method because it gradually changes the spawn chances, rather than abruptly. There is a central spawn listing for each terrain type, then each town has its modifying list. I can fake a town too, that allows regions more likely to have monster X. It also simulates the generic area of influence idea extending out from the town, while allowing dynamic town influences (one town may not weed out the wolves, another may weed out rats, etc). Of course, your system doesn't have 'towns' per se, so I'm not quite sure how to apply it quite right. Out in the deep forest, I imagine there aren't too many limitations on encounters.

One problem I have had is quick lookup. Given that there are hundreds, potentially, of monster types that may spawn...there needs to be an efficient method of figuring out IF one spawns then pick the beastie(s. The "if it spawns" is an easy initial check, though I'd rather add it as a monster spawn and have it simply not do anything. Two spawnings could fall under this idea as well, but this still leaves us with the problem of designing an algorithm that can select these. I was imagining a sparse array could handle this nicely (have 10,000 'entries' in it to account for .01% chance of spawn)...but it'd still have to be filled out each time. This means assigning the chances to each 'spawn section' of the array each time we check, O(n). Of course, picking one is O(1), but that still sucks. We could also go down the list checking if the modified spawn chance matches our random roll, but still O(n). I'll likely wind up just taking the spawn list from the terrain then modifying all the chances and selecting one, but it's certainly an area for improvement.

I'd also like to base the spawn chances off the mobs themselves (the timber wolf mob has a 0% spawn in forest, 5% in high mountains...etc), but I'm at a loss for an efficient mechanism for running through them all. Perhaps the encounter table could initialize it's data off all mobs at start-up or run-time. That handles the creating/deleting of mobs more effectively than searching through a million encounter tables.

- Kelson


Last edited by Kelson on Tue Aug 30, 2005 10:23 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Ashon



Joined: 11 May 2005
Posts: 86
Location: Seattle

PostPosted: Tue Aug 30, 2005 7:13 pm    Post subject: Reply with quote

The Easiest I think would be to use the coordinate box approach. But as you say it is going not going to be an elegant solution. To extrapolate on that though, if you go beyond just tracking the terrain, and actually track the biome of the 'area' then you can get a better dispersal of the NPC's.

Of course, my preferred method is to use the Population Map. You can brute force the no extermination into the population Map, and just make sure that no race actually goes extinct. And I don't see the issue with Dynamically Created Worlds, when the world is being generated, why can't the Map be populated and run through a couple of iterations of growth/expansion before the World is finished? It would mean perhaps adding some preferred climate/terrain tracking mechanism to the Mob's, but that shouldn't be too big of a problem.
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Tue Aug 30, 2005 11:34 pm    Post subject: Reply with quote

We've all heard this word probably N^1,000,000 times... but I'm going to say it again... Encapsulation.

First, we start out with our "Forest Creatures List"

Deer, Wolf, Squirrel, Boar...

Then we localize a bit for a particular forest with our "Elfy Forest List"

Treant, Dryad, Elf Ranger...

And so on, so basically, when you create your world, and this can be done dynamically I believe, and if not, with only minor headaches, you label "neighborhoods" within the world, much like we do in real life, with "The Rocky Mountains" or "The Alps", "The Black Forest", etc...

Just because it was generated dynamically doesn't mean that it can't have a name, heck, throw in a random name generator and you don't even have to exert the effort to come up with the name of your forests and whatnot.

Any area of trees > 4 mi sq = "The " randomname " Forest". Problem solved.

Anyway I think that was half-way helpful, something to chew on anyway.

Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
Huri



Joined: 18 Jun 2005
Posts: 8

PostPosted: Tue Aug 30, 2005 11:45 pm    Post subject: Reply with quote

I'd go for room-for-room based "areas", that is, a grouping of a number of coordinates with some kind of name to identify it. The grouping would have to be done atleast semi-manually, unfortunatly. For example, a number of mountain tiles might be grouped under the name "Mount Doom". Then you can say stuff like "Mount Doom is infested with doom apes!", and actually implement that as random encounters in code. These kinds of areas could be useful for other things as well, for example generating dynamic descriptions. Some sort of "center" tile might be useful for several things, like line-of-sight calculations, but it could also be used to implement stuff like "The doom apes of Mount Doom sometimes raid the surrounding countryside!" by making a check for distance to the "center" tile.
Back to top
View user's profile Send private message
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Tue Aug 30, 2005 11:52 pm    Post subject: Reply with quote

I'm pretty sure, at least in KaVir's Godwars II codebase, that "original" areas and points of interest can be added to the map as an afterthought to the dynamic generation of the world. However, this is a good idea, allowing you to also centerally locate big baddies like "Apezilla! King of the Apes of Mount Doom!"(sounds ominous I know! I'm shaking!). Anyway, this would in no way discourage the use of encapsulation and localization for generally containing certain mobs to areas of the mud that they belong and make sure that they don't spawn somewhere where they do not logically fit in.
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Wed Aug 31, 2005 9:06 am    Post subject: Reply with quote

Kelson wrote:
So while each terrain type has a set of possible mobs that can spawn near it (I allow circular terrain overlap, except for land-based onto water-based) the spawning is primarily modified by how distant the room is from any major civilization (using a global coordinate system made this easy, it'd work easily for your system too, IIRC).


That's actually a bit similar to my original design, whereby the strength of mobs was based on how far they spawned from the centre of the world (the mob types themselves didn't actually change, just their stats).

On its own, however, such a solution would group mobs based purely on strength, while I'd like to also group them based on type. I suppose your solution could handle this by defining certain mobs as allies (thus you might have forest trolls, mountain trolls and cave trolls living in near proximity, while the hill giants and treants have been wiped out), but that's going to get quite complex for on-the-fly generated content.

Ashon wrote:
I don't see the issue with Dynamically Created Worlds, when the world is being generated, why can't the Map be populated and run through a couple of iterations of growth/expansion before the World is finished?


Because the world isn't generated and stored - it's generated on the fly, using pseudo-random numbers to achieve a persistent world layout.

Right now (because the main world is still very basic due to only having a handful of zones for it to assemble the landscape out of) I've also got a hand-built central location. I'm now considering expanding that so that the centre of the world is more detailed - that way I could use some of the nicer approaches described previously, such as the population map.

Combined with the aforementioned scaling of mob strength, this would also allow me to use the centre part of the world for all of the fixed-strength mob types, perhaps even hand-placed, while also having a range of scalable-strength mob types for the on-the-fly generated outer part of the world.

In effect, there'd be two parts to the game world - the inner part that most people play in, with a range of mobs of various strength grouped together in reasonable locations, and an outer part for high-powered characters, with monsters that scale in strength based on how far out they've spawned.

Huri wrote:
I'd go for room-for-room based "areas", that is, a grouping of a number of coordinates with some kind of name to identify it.


I did that in the past, for my old mud, by defining a coordinate range (from x/y to x/y) and a terrain type (eg forest, mountain, river, etc). Thus you might say "all forest terrain between 0,0 and 500,500 is the Black Forest" or "all river between 0,50 and 500,100 is the Isar" - and as a result you'd have the Isar running through the Black Forest. You could even define city names the same way.

Obviously this wouldn't work for the generated locations, but if those were treated as wild unexplored lands then perhaps the solution could be applied purely to the central hand-build world. However I would still have some concerns with efficiency, as there could potentially be a huge number of named locations to check through. Of course it could be made pretty cpu efficient at the expense of extra memory, which might be viable as long as the central world is kept quite small. Perhaps store a few 'name index' values (each for a different terrain type) and use those to look up the appropriate name - although that would prevent having more than one river or forest in the same zone, which might be awkward...perhaps it might be better to stick to the original approach and just store them in a hash table to cut down the number of searches (maybe with some caching of names to avoid too many repeat searches).

That could also be tied in with Vopisk's idea of neighborhoods, with each named terrain storing its own encounter list. For example you might have:

Name: The Black Forest
Covers: From 0,0 to 500,500
Terrain type: Forest
Encounters: treant, forest troll, dryad

Name: The Isar
Covers: From 0,50 to 500,100
Terrain type: River
Encounters: blue naga, young blue dragon


Of course it may be desirable to break the encounters up further - perhaps some mobs only spawn within forest clearings in the Black Forest, while others might appear on the bank on the Isar rather than within the water itself. You might also have some which appeared on the outskirts of the forest, rather than having to be literally within it, which goes back to Kelson's idea of simply differentiating between land and water.

Each entry could also store population levels, and even maintain coordinate positions of important mobs (eg the troll king). In theory you could even store all mobs this way (just an x and y position), and only load them up if they encounter a player - it would certainly get around the problem of players walking back and forth until a mob appears. If two mobs encountered each other you could just do a quick check to see the battle result, rather than loading them into memory and making them literally fight (although a fight duration would also be nice, so that players could encounter two mobs fighting it out).

Of course this doesn't help much with the outer part of the world, but if the centre is the main focus of gameplay then I don't think it's so important if the outer part isn't an interesting and varied. Perhaps I could just keep expanding the centre over time, so that the outer part would be mainly for the players who had advanced faster than I could develop...
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Thu Sep 01, 2005 1:38 am    Post subject: Reply with quote

Vopisk wrote:
And so on, so basically, when you create your world, and this can be done dynamically I believe, and if not, with only minor headaches, you label "neighborhoods" within the world, much like we do in real life, with "The Rocky Mountains" or "The Alps", "The Black Forest", etc...


Not to discount you, but how do we dynamically create these monster encounter tables? I'd actually like to do this, since as I'll talk more about later I dyamically create a lot of the information the system uses down the line. Perhaps by increasing the amount of information required in monster creation? Dunno, but it's a step in the right direction in my mind.

KaVir wrote:
On its own, however, such a solution (mob strength proportional to distance) would group mobs based purely on strength, while I'd like to also group them based on type. I suppose your solution could handle this by defining certain mobs as allies (thus you might have forest trolls, mountain trolls and cave trolls living in near proximity, while the hill giants and treants have been wiped out)

...but that's going to get quite complex for on-the-fly generated content.


I recall discussing this previously, though perhaps you were not in the discussion. In the real world, social creatures appear in groups (not often by themselves). While I find it useful to delineate in many cases between the type of monster that spawns, a larger bonus (from the player perspective...though they prefer single monsters consciously) is to spawn social groupings. For example, a group of orcs spawns rather than a single orc. This group, if large enough, has a chance of having a mountain troll escort or dire wolves. Perhaps one social 'group' in your system would be a cave/forest/mountain troll pack wandering in the wilderness.

I suppose our views on the complexity involved is different, I don't really see it as complex yet. I'll agree though that extending all these ideas to fully integrate with the system borders on some complex problems though. For example, it is relatively trivial to take into account 20 "influence points" for each encounter check, but if we have dynamic influence points or - more interestingly - semi-static 'randomly' generated influence points...then we may move from 20 to 2000 and suddenly have a much more challenging optimization problem.

KaVir wrote:
Because the world isn't generated and stored - it's generated on the fly, using pseudo-random numbers to achieve a persistent world layout.

...

Combined with the aforementioned scaling of mob strength, this would also allow me to use the centre part of the world for all of the fixed-strength mob types, perhaps even hand-placed, while also having a range of scalable-strength mob types for the on-the-fly generated outer part of the world.

In effect, there'd be two parts to the game world - the inner part that most people play in, with a range of mobs of various strength grouped together in reasonable locations, and an outer part for high-powered characters, with monsters that scale in strength based on how far out they've spawned.


But there is a lot of leeway in modulators to the pseudo-random generating algorithm, thus the influence points and history impact (if 500 trolls have been killed here lately, trolls are less likely - though wolves are more likely due to excess food and fewer trolls to hunt them).

I'm personally a fan of using both systems at the same time. The wilderness takes into account the "stuff going on" in the wilderness (perhaps there are too many local monsters to allow any others to spawn - the hand picked mobs prevent others from spawning). This is where stuff like players building in the wilderness comes into play. Players may build up homes (though really, I'm only allowing the computer to build towns and players to 'assist' them...same effect) that begin influencing the region and are semi-permanent. The line between a real town and a built town may never be firmly established, since I think it a vital part of the world history that some towns stop existing from time to time.

KaVir wrote:
I did that in the past, for my old mud, by defining a coordinate range (from x/y to x/y) and a terrain type (eg forest, mountain, river, etc). Thus you might say "all forest terrain between 0,0 and 500,500 is the Black Forest" or "all river between 0,50 and 500,100 is the Isar" - and as a result you'd have the Isar running through the Black Forest. You could even define city names the same way.


I'm more of a fan of terrain modifiers - a river modifier might add a river to a region by pseudo-randomly assigning rooms to be rivers instead of the normally generated content. That prevents the block world issue of everything existing as a box; now every room is part of an area (perhaps within an area). Our river now only exists on river 'tiles'. The named location efficiency is still my problem, as mentioned above. Localization seems key to solving it; I'm currently imagining the game engine will initialize with all data then determine region maps on the fly that will speed up this process. This way the engine can use establish the hierarchy required for spatial searching.

KaVir wrote:
Of course it may be desirable to break the encounters up further - perhaps some mobs only spawn within forest clearings in the Black Forest, while others might appear on the bank on the Isar rather than within the water itself. You might also have some which appeared on the outskirts of the forest, rather than having to be literally within it, which goes back to Kelson's idea of simply differentiating between land and water.


Just wanted to clear up that all land regions overlap all others (mountain tiles overlap forest and vice versa to produce fuzzy terrains (30% forest, 70% mountain)). The forest doesn't overlap much with the water though, because there are a number of things that may exist 'in' the water that can not exist 'in' the forest. I feel the idea still needs some polishing, but I'm not sure how else to model it without making river depths factors in the monster generators and then further extending the room description generators to take into account water depths to check for encounters....ugh.

KaVir wrote:
Each entry could also store population levels, and even maintain coordinate positions of important mobs (eg the troll king). In theory you could even store all mobs this way (just an x and y position), and only load them up if they encounter a player - it would certainly get around the problem of players walking back and forth until a mob appears. If two mobs encountered each other you could just do a quick check to see the battle result, rather than loading them into memory and making them literally fight (although a fight duration would also be nice, so that players could encounter two mobs fighting it out).


If one did this, they could also simulate actual population cycles by having mob reproduction and such...not a place I want to toy with, though interesting. Troll King ==> Society Leader ==> Society has influence over region, must be tracked. Interesting idea on the mob encounters...wouldn't want to do it unless a player were near though - wasting cpu / memory Smile

KaVir wrote:
Of course this doesn't help much with the outer part of the world, but if the centre is the main focus of gameplay then I don't think it's so important if the outer part isn't an interesting and varied. Perhaps I could just keep expanding the centre over time, so that the outer part would be mainly for the players who had advanced faster than I could develop...


Or just let your encounter generator GENERATE monsters and place them way out there. That greatly enhances the player possibilities out in that region while giving you that 'catch up time'. I would also think it pivotal that you make the outer regions interesting though - players wouldn't much fancy "beating the inner region" then going after the outer region to find it lacked anything worthwhile.

- Kelson

Working on the Fourth Iteration of AdequiseMUD
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Sep 01, 2005 8:30 am    Post subject: Reply with quote

Kelson wrote:
In the real world, social creatures appear in groups (not often by themselves). While I find it useful to delineate in many cases between the type of monster that spawns, a larger bonus (from the player perspective...though they prefer single monsters consciously) is to spawn social groupings. For example, a group of orcs spawns rather than a single orc. This group, if large enough, has a chance of having a mountain troll escort or dire wolves. Perhaps one social 'group' in your system would be a cave/forest/mountain troll pack wandering in the wilderness.


You could do that, yes, but that's not really what I'm trying to achieve - what I'm after is a situation whereby a group of related creatures are scattered throughout a particular location, in much the same way as an 'area' in most muds has thematically related mobs. Thus rather than spawning a group of orcs or a pack of wolves at the same time, wandering around a few square miles of terrain would result in you encountering orcs and wolves, which would be spawned on-the-fly, and then quietly destroyed if there are no players nearby for a certain period of time.

Spawning a squad of orcs with a troll escort would be pretty cool for a single encounter result, but I wouldn't want it spawning right next to group of elves, unless the spawn location was a border between orc and elf settlements.

The complexity issue I was referring to was the concept of defining certain mobs as allies so as to dynamically generate a believable encounter list on-the-fly based on the encounter lists for the surrounding locations (which would also be generated on-the-fly) - I imagine this could be done by generating the encounter list for your current location and all encounter lists for the surrounding locations, then adjusting the former based on the latter using lookup tables to determine the outcome of each particular species living in close proximity (with 'close' being a variable dependant upon the species type).

Note that I don't mean "complex" as in difficult to implement, but rather something which would require a fair bit of overhead to generate on-the-fly. For something used as frequently as an encounter list, I'd prefer to keep the calculations as simple as possible. If the world was generated initially then it would be okay, but I need a solution that can be calculated repeatedly (although I suppose it might work with careful caching).

Kelson wrote:
I'm more of a fan of terrain modifiers - a river modifier might add a river to a region by pseudo-randomly assigning rooms to be rivers instead of the normally generated content.


I don't see how you can do that, unless rivers are pseudo-randomly generated objects which are laid on top of the world...and even then, how do you avoid circular rivers or crossed rivers? Unless you just have a selection of predefined river layouts (i.e.,for an entire river, from its source to where it exits into a lake/ocean/bog) and explicitly prevent overlap?

Kelson wrote:
Interesting idea on the mob encounters...wouldn't want to do it unless a player were near though - wasting cpu / memory


Which is why I suggested doing a quick check to see the battle result, rather than loading the mobs into memory. You could just use some sort of lookup table to compare the strengths of the two mobs against each other (the strength could be based on mob type, or quickly generated from a handful of core criteria).

Kelson wrote:
Or just let your encounter generator GENERATE monsters and place them way out there.


I can't have it just placing the monsters down initially - the world is too big. But it could certainly spawn mobs of scaled strength, as per my original design.
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Thu Sep 01, 2005 9:27 am    Post subject: Reply with quote

Rather than using a single-dimension, discrete factor to calculate monster probabilities, use multiple, continuous factors: rather than being "forest", "hills", "mountain", etc. a piece of terrain might have an elevation, level of irregularity (flat or bumpy), degree of forestation, level of natural irrigation, etc.

As a first pass, define template combinations of these values based on your existing terrain types.

The chances of any particular monster appearing is then a formula derived from as many of these numbers as you wish. Hill giants might have a higher probability with higher elevation, and perhaps with more broken terrain, etc. Each time round you'd work out the relative probabilities of all types of monster, cull all the ones with zero or less, and then pick from the remainder based on their weighted scores.

You can then add in arbitrary new terrain-describing numbers to mean anything you want - proximity to a city, proximity to an orc fortess, etc. - and set up the formulae in such a way that certain monster types always have a zero or less probability of appearing unless one of these specialised quantities has a significant positive value.
Back to top
View user's profile Send private message
Author Message
KaVir



Joined: 11 May 2005
Posts: 565
Location: Munich

PostPosted: Thu Sep 01, 2005 12:15 pm    Post subject: Reply with quote

shasarak wrote:
Rather than using a single-dimension, discrete factor to calculate monster probabilities, use multiple, continuous factors: rather than being "forest", "hills", "mountain", etc. a piece of terrain might have an elevation, level of irregularity (flat or bumpy), degree of forestation, level of natural irrigation, etc.


Might be an interesting way to design a world, but I don't think you'd get very good quality results with on-the-fly generation (you'd probably need to do several passes to get a decent world). And if anything, it would make wilderness encounters even harder to design well, because there would be no clear way to define what sort of terrain a particular location was.

Quote:
The chances of any particular monster appearing is then a formula derived from as many of these numbers as you wish. Hill giants might have a higher probability with higher elevation, and perhaps with more broken terrain, etc.


Nice idea, but it would still leave me with exactly the same problem I've got now - hill giants would appear in all hills, when in fact I only want them to appear on hill ranges X, Y and Z.
Back to top
View user's profile Send private message Visit poster's website
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Thu Sep 01, 2005 2:45 pm    Post subject: Reply with quote

Quote:
Might be an interesting way to design a world, but I don't think you'd get very good quality results with on-the-fly generation (you'd probably need to do several passes to get a decent world).

Use some of those psuedo-random but smoothly varying noise functions.

Quote:
And if anything, it would make wilderness encounters even harder to design well, because there would be no clear way to define what sort of terrain a particular location was.

You've already got each terrain tile labeled as "hill", "mountain", "forest", etc. So simply translate each terrain type to a set of numbers. "Mountain" might be height 20, terrain brokenness 10. Forest might be height 0, woodedness 10. And so on.

Quote:
Nice idea, but it would still leave me with exactly the same problem I've got now - hill giants would appear in all hills, when in fact I only want them to appear on hill ranges X, Y and Z.

No, 'cos you can specify your own custom parameters - as many as are needed.

Let's say you have a particular evil fortress in the Mountains of Gnaarg that attracts hill giants, trolls and orcs. So you add a terrain attribute which is defined simply as "proximity to Gnaarg Castle".

Terrain tiles right next to the castle have a ptGC value of 3, tiles beyond that have a value of 2, tiles beyond that have a value of 1, and all other terrain tiles have no defined value, which is regarded as 0.

The formula for determining the probability of encountering a hill giant might then be something like "10h - 17w - 8t + 5b + 30ptGC - 100". In other words, you're more likely to get hill giants in high areas, and broken areas (although that's less significant), less likely to get them in wet areas, less likely in areas with trees, and more likely to get them in "proximity to Gnaarg Castle" tiles.

What you then have to do is tweak the numbers so as to get the right balance. If the final -100 gets too negative you'll never see hill giants anywhere. If it's not significant enough, you'll get them everywhere. Careful tuning would result in getting hill giants only in hilly, broken, dry, non-wooded areas that are close to Castle Gnaarg, and nowhere else.

By contrast, trolls might be common in mountainous areas (but not hills) and more common around the castle. Orcs might generally dislike hills, but nonetheless be common around Castle Gnaarg (-20h + 50ptCG).

You can then add as many arbitrary terrain attributes as you like to control the probabilities as finely as you need to. And those attributes could be based on absolutely anything, and/or calculated by formula rather than stored on the tile. (ptGC, for example, could be calculated on the fly from the coordinates of the tile rather than stored. A more general "proximity to evil fortress" would probably have to be calculated in advance and stored for each tile as there would be more than one evil fortress, and the influence of each one would be of variable intensity and range.)
Back to top
View user's profile Send private message
Author Message
Kelson



Joined: 18 May 2005
Posts: 71
Location: SC

PostPosted: Thu Sep 01, 2005 5:44 pm    Post subject: Reply with quote

While I like the location-attribute percentages, my disagreement for using them is more that they're a headache for proper implementation. A builder can easily tell me that their monster is common in woods, uncommon in hills, and will not live on mountains or in rivers. That gives me a fairly general idea of where to find the monster. On the other hand, neither a builder nor myself is going to see a difference between a 39 and 38 in spawn probabilities near a hill. And 30% spawn likelihood is quite large...encountering one monster practically every third room.

KaVir wrote:
You could do that, yes, but that's not really what I'm trying to achieve - what I'm after is a situation whereby a group of related creatures are scattered throughout a particular location, in much the same way as an 'area' in most muds has thematically related mobs. Thus rather than spawning a group of orcs or a pack of wolves at the same time, wandering around a few square miles of terrain would result in you encountering orcs and wolves, which would be spawned on-the-fly, and then quietly destroyed if there are no players nearby for a certain period of time.


Never said the monster had to spawn within a 5 foot radius. To take back to my other example of a large group of orcs 'causing' a troll to spawn - I'm not a fan of over 4-6 mobs in a room, so if there were 20 orcs...I'd spread them out over 5-8 rooms. Perhaps you'd rather spawn several packs of 4-10 orcs spread out over a much larger area. Now you've dynamically created this local orc population density that ensures most of a player's encounters will be orc in nature. I'm sure there are better ideas, but the overhead you spoke of is my biggest concern with the idea. Creating too many local points of interest causes slower encounter table resolution...which may require hitting up a profiler to check the speed and perhaps some addition data structures to allow for quick resolution.

Provided it wouldn't slow down the system too much, it is possible to have mobs and items affect the encounter table spawns too. Hitting even more on that time crunch though - if a group of 10 players runs through the wilderness it cuts down significantly on 'weak' spawn creatures (squirrels, birds), but increases the likelihood of 'strong' spawn creatures (trolls, ogres) that are attracted by the noise.

Of course, for that last part we're really starting to leave the zone of player caring about what our code is doing. To the player, it provides a minutely richer experience of fighting more ogres with their group and less squirrels...but the players themselves don't much notice or care about that greater level of complexity. I think it rather important that we keep that in mind, since the discussion seems to be heading more towards full blown simulation than "what is necessary to have a fun and interesting game"

- Kelson
Back to top
View user's profile Send private message Send e-mail AIM Address
Author Message
Vopisk



Joined: 22 Aug 2005
Posts: 99
Location: Golden Valley, Arizona, USA

PostPosted: Fri Sep 02, 2005 2:35 am    Post subject: Reply with quote

Quote:
Not to discount you, but how do we dynamically create these monster encounter tables?


I personally am a fan of simulation, and the finer nuances of what the world is doing underneath the surface. I am a huge fan of global "events" that actually have an impact on a global scale, and at the same time, I'm too lazy to do any emoting. With that being said, my approach would be to have at least a semi-persistent game world. I believe it is possible to feed a .bmp image through a program and using the values of each individual pixel to set certain parameters. I might be wrong about this, but a friend of mine and I talked about it once.

This would give you a method of applying the "over-all layout" of your game world, while the finer details could still be generated dynamically. To expand on Shasarak's idea, you could feed in multiple map/images through different parsers to set things like general elevation and other factors that would add a vibrance to the game world because of quite varied and pseudo-realistic terrain changes.

However, in the case of generating "neighborhoods", we can define certain values to look for that will create these areas for us. Say perhaps that this equation makes a forest: (annual rainfall average of > 10") + (Sea Level < Elevation < 10,000) + (area >= 5000 units sq).

So, we look through the randomly "generated" world and define block (50,100) through (175, 246) as a forest, generate a name (The Black Forest) and then we assign the value of "forest" to all of the terrain tiles within that area and further based upon elevation and whatnot, determine what types of trees are likely to be predominate there.

The same can be applied to monsters if we give them a "preferred habitat". And say we have 40 monsters that like the forest, but perhaps we limit the "encounter list" to only 10 and thereby roll a random list of monsters that will be encountered.

Therefore, we now have a new neighborhood that has been made dynamically by the game without us defining anything but the "generic" game world layout. In addition, we have given a name and created a hash table of which mobs will be found in that general vicinity.

Anyway, so this works at "the moment of creation" but as we said, we wanted pseudo-randomness of the game world at the very least with semi-permanence. So we store in some sort of format, lists of x,y coordinates that hold values that let us reference these little bits.

So... where does this get us? Well, first I think we should get a little deeper into the idea.

Now, we have generated a game world, but this is all wilderness. Let's add on top of it a "random dungeon generator" that will create dungeon areas for our vigilant adventurers to explore the depths of. These (channel Diablo) could be generated randomly upon each instance of the player being in the area so that it's never the same twice, and could also change location so it's never QUITE in the same place twice. Thereby, we never let anyone get familiar or comfortable with the layout of the world and there's always something new to explore.

Now, this dungeon needs at least one entrance upon the main game world for the player to enter, so we determine an X,Y coordinate for this entrance to be placed upon (along with perhaps second or even third entrances or special exits*) on the game world.

The placing of these randomly created dungeons (think "find the eq piece" quests randomly popping complete dungeons into the world that only the player on the quest can see*), would also bring with it certain baddies that are likely to be wandering around the outside (or perhaps baddies that are scared away by what's inside*).

So now, when player Bob goes wandering out in the "Black Forest" as it's called on his map, to find the lair of "Amalgamus the Mad" in search of the "Rod of Antiquities"(all generated randomly on the fly), we simply scry their X,Y coordinate location from our large storage object containing world coordinates, determine what is nearby, what terrain type it is, what description to display along with the hash table of what possible monsters they are likely to encounter, etc.. etc... ad infinitum.

Anyway, I think that describes my general idea of a "random"ly created game world pretty well, please feel free to pester me with any further questions or comments because it all helps me to further refine my theorii.

Something to chew on,
Vopisk
Back to top
View user's profile Send private message AIM Address MSN Messenger
Author Message
shasarak



Joined: 29 Jun 2005
Posts: 134
Location: Emily's Shop

PostPosted: Fri Sep 02, 2005 9:35 am    Post subject: Reply with quote

Kelson wrote:
And 30% spawn likelihood is quite large...encountering one monster practically every third room.

The way I had imagined that working is that there would first be a roll to determine if there is going to be a monster there (5% chance, perhaps, depending on terrain), and then, if there is, a second roll to determine which monster it is.

In the system I was outlining the probabilities are not necessarily percentages, either. The unit is arbitrary. You might end up (in one particular type of tile) with chances like this:

Hill giant: 10
Orc: 6
Warg: 12
Troll: 4
Wild man: 8
Everything else: 0 or less.

In that instance, if there's a monster, the chances of it being a hill giant is 10 out of 40, or 25%. If the chances were:

Hill giant: 10
Warg: 12
Wild man: 8
Everything else: 0 or less.

Then that would mean a 50% chance of a hill giant.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign