20 Aug, 2010, Rudha wrote in the 21st comment:
Votes: 0
I do like the idea of having a simulated weather system that seems real. I like the idea of having separate systems for two reasons - A) a monolithic single system trying to model all the variables and would be more difficult to diagnose when things go wrong and B) having the systems modeled separately makes it easier for us to have circumstances where one or more things aren't giving effects on a room, but the others are. Just about anywhere is going to have an ambient temperature that can change, but it might not necessarily be raining in a shop! Unless it was the shop of a particularly eccentric elementalist, perhaps!

I do agree is that the important thing is that the -output- seeming realistic is ultimately the important thing. Players aren't going to care if you accurately modeled all of the thousands of variables that go into a full weather simulation - they're just going to see the end result. The problem for me modelling things on statistics is weather can be unpredictable and statistics can be skewed. I'd need to find a fairly accurate set of numbers from a variety of climates for it to really work well in the system. Granted, though, Im in agreement that actually simulating all the variables involved is actually counterproductive here. Im in the field of making MUDs. Having realistic seeming weather is certainly a very neat selling point that helps my beloved sense of immersion. But again, players aren't going to care how you achieve that, usually.

Maya/Rudha
20 Aug, 2010, KaVir wrote in the 22nd comment:
Votes: 0
Runter said:
How about a magnitude of wetness or flame? I think it would take a reasonably heavy shower to extinguish a torch.

I do actually have magnitudes of wetness, but not of flame. However right now they remove each other - eg if you're on fire and leap into a river, the flames are extinguished, but if someone then casts an immolate spell on you, you'll instantly dry out, with a message about steam rising from your body.

Thus if the rain didn't extinguish the torch, the flame would turn the wetness into steam, meaning the torch would never go out. To get around that I'd need to have the possibility of items that are both wet and flaming - but that shouldn't prevent players from intentionally extinguishing torches by thrusting them into a pond, or from instantly drying off by transforming themselves into a fire elemental.

On the other hand I'm not sure I want torches to ever be extinguished by rain - realism aside, there are some situations where players need to inflict heat damage, and a lit torch may be their only non-magical option.


Anyway, back to the weather…

I have moving weather patterns, but the tides are handled globally. I tend to base things more on the season though: winter turns rain into snow and storms into blizzards (an oversimplification, but it suffices for my needs), and also freezes ponds and lakes (allowing you to walk over them). The nights also get longer as winter approaches and shorter as summer approaches. The season is also used in the dynamic descriptions, and determines what sort of mobs you encounter - even villagers load with different clothing depending on the season.

Another alternative: Some muds base their game weather on the real weather. This would work particularly well for a mud set in the real world, of course, but you could use it for other worlds with a little modification. This would allow you to have very realistic weather without needing to develop a complex weather system.
20 Aug, 2010, quixadhal wrote in the 23rd comment:
Votes: 0
KaVir said:
Another alternative: Some muds base their game weather on the real weather. This would work particularly well for a mud set in the real world, of course, but you could use it for other worlds with a little modification. This would allow you to have very realistic weather without needing to develop a complex weather system.


Certainly an option these days! Just map your geography onto fairly reliable weather data from places on Earth with similar climate and approximately the same kind of distance apart (to let systems flow as you'd expect). Very good idea if your map will allow it. :)
20 Aug, 2010, David Haley wrote in the 24th comment:
Votes: 0
Quote
A) a monolithic single system trying to model all the variables and would be more difficult to diagnose when things go wrong

I'm somewhat surprised that you say that a state transition system would be harder to diagnose than one that involves many moving parts with many different angles of interaction.

Quote
The problem for me modelling things on statistics is weather can be unpredictable and statistics can be skewed. I'd need to find a fairly accurate set of numbers from a variety of climates for it to really work well in the system.

Well, how were you going to do it when tracking all the various components? Surely your numbers need to change at some point: how were you planning on introducing change in the numbers such that everything in the world kept moving? It's not like building a weather simulator is a terribly easy prospect, either, nor is it not going to involve any randomness of its own. Besides, even if the statistics are not quite right, players are relatively unlikely to notice, and it's a lot easier to change a state transition scheme than it is to go in and tweak all the interactions between moving parts.

Also, you still have to create the state output model from the moving parts: at what levels of temperate, humidity and wind (etc.) do you go from cloudy to raining to stormy? It's not sufficient to track the components individually; weather results from interaction between them all.
20 Aug, 2010, chrisd wrote in the 25th comment:
Votes: 0
I pulled the numbers for my weather system out of thin air and it works quite well. You just need to pick numbers that will produce the effect you want when put into your system.
20 Aug, 2010, Rudha wrote in the 26th comment:
Votes: 0
KaVir said:
Another alternative: Some muds base their game weather on the real weather. This would work particularly well for a mud set in the real world, of course, but you could use it for other worlds with a little modification. This would allow you to have very realistic weather without needing to develop a complex weather system.


A consideration for Elvenblade with its weather module is that I have some weather that's not real. This comes through a few ways. First of all there's magical ash storms that's basically a manifestation of the more malevolent side of magic, secondly there's going to be areas of exceedingly odd weather in areas of magical surges, and thirdly there's always the possibility of an Elementalist tooling around with the local weather.

Nonetheless that could work, if done well - I think it is worth considering however, that the more real I make the weather seem, the more incongruous any discrepancies will seem.

KaVir said:
The season is also used in the dynamic descriptions, and determines what sort of mobs you encounter - even villagers load with different clothing depending on the season.


What sort of mobs occur would be interesting but not entirely feasible in my MUD since its going to be a mostly persistent world. I could model migratory patterns, though, and that would actually be as easy as just changing the schedule locations based on month, or season.

Different clothing would be very neat, though, I think I'll do that. We'd want NPCs to do that anyways if I added in the clothing heat/cold effects for being over or under dressed anyways.

quixadhal said:
Certainly an option these days! Just map your geography onto fairly reliable weather data from places on Earth with similar climate and approximately the same kind of distance apart (to let systems flow as you'd expect). Very good idea if your map will allow it. :)


Certainly something that would be easy to do. I could just make a file with "climate data" and and map a handful of variables that are important to each "climate" The question then becomes deciding which variables I think are important to the accurate modelling of weather.

David Haley said:
I'm somewhat surprised that you say that a state transition system would be harder to diagnose than one that involves many moving parts with many different angles of interaction.


When I have separate modules for - say - wind, precipitation, and temperature - if its just one of those not working properly, I can much more easily isolate that variable.

That said they'd not be completely independent any more than say - my stamina system is separate from my health system, or either are seperate from my stats system. Things always have overlap. But if I model all three in the same function, it's more difficult to isolate the variables. That's what Im saying (and all I'm saying.)

Maya/Rudha
20 Aug, 2010, David Haley wrote in the 27th comment:
Votes: 0
Rudha said:
When I have separate modules for - say - wind, precipitation, and temperature - if its just one of those not working properly, I can much more easily isolate that variable.

That said they'd not be completely independent any more than say - my stamina system is separate from my health system, or either are seperate from my stats system. Things always have overlap. But if I model all three in the same function, it's more difficult to isolate the variables. That's what Im saying (and all I'm saying.)

I don't really understand this, though. In order to figure out what the current weather is, you need to look at how all three of those are interacting. Furthermore, in order to know how each one changes individually, you need to look at the others. For example, wind and temperature are pretty clearly linked (wind moving cloud cover, wind moving warm/cool air, differences in temperature affecting wind/pressure, etc.). Unlike stamina/health/etc., which have some degree of overlap, in this case the variables seem far more deeply intertwined.

Perhaps my suggestion wasn't formulated very clearly, because (for me at least) dealing with one transition model seems a lot easier than having to look at three separate modules, each of which has its own internals, in addition to interactions between all three modules, not just pair-wise but triplet-wise, and finally synthesizing some kind of current weather state based on the values of all three (is it raining, snowing, drizzling, clear, cloudy, …).

For the sake of clarity, here is a very simple example of what I had in mind:
- Sunny
- 60% probability of staying sunny
- 35% probability of going cloudy
- 5% probability of rain
- Cloudy
- 25% probability of staying cloudy
- 25% probability of sun
- 25% probability of rain
- 25% probability of storms
etc.

and you could tweak the probabilities depending on high-level factors like climate ("hot", "cold", "temperate"), humidity ("wet", "dry", "normal"), etc.

As far as I can tell, the only hard part here is coming up with a probability set that is plausible (it doesn't have to be realistically accurate, just plausible). I don't understand what variables you need to isolate here. If you observe that it rains too much when it's sunny, you only need to change the probability of going to rain from sun.

On the other hand, with a weather simulator, if you note that it rains too much when it's sunny, what do you have to do? Well, you have to figure out what sets of conditions make sunny weather and what sets of conditions make rain. Then you have to figure out how each individual variable goes from one set of conditions to the other. But you also need to make sure that interactions among those variables don't cause confusion along the way.

Maybe I'm not seeing something from your description, or maybe I haven't been clear, but I earnestly do not understand why the multi-variable system is supposed to be simpler to create or debug.
20 Aug, 2010, Rudha wrote in the 28th comment:
Votes: 0
I think I didn't really understand what you were getting at. I thought you were saying to have all these variables in one big thing as opposed to seperate things, whereas seeing that example now, you seem to be speaking to the difference between modelling a statistical simulation against modelling the various variables behind weather.

Maya/Rudha
20 Aug, 2010, David Haley wrote in the 29th comment:
Votes: 0
Yes: my suggestion is to model only the changes in output, not the changes in the factors that a 'proper' simulator would use. Put another way, model only the first degree, not the second degree that drives the first degree. Or put yet another way, for the mathematically inclined perhaps, model the output function but not the first (or second) derivatives of the output function.
20 Aug, 2010, Rudha wrote in the 30th comment:
Votes: 0
I think, for the initial implementation at least, that's what I'll do. After I have that working sufficiently well, I can decide if that feels like it's "enough" for me, and the world, or if I feel we need to go "deeper" with our model and start getting more complex. There is still, however, the question of having meaningful variables (or rather, meaningful "chances" or however you choose to describe it), beyond the obvious - for example it becomes a matter of design deciding when and where I want magic surges to affect (effect? affect? not sure) the weather.

Maya/Rudha
20 Aug, 2010, David Haley wrote in the 31st comment:
Votes: 0
Quote
(effect? affect? not sure)

Well… since you asked :tongue: it's affect. The magic effects affect the weather, but the simulator effects the weather output.
affect, noun: an emotion, feeling
affect, verb: to create an impact on something, or act upon
effect, noun: a result, consequence
effect, verb: to make happen

So to get technical, if you are changing the weather, you're affecting it… but, if you are actually the root cause of the weather, you're effecting it. The difference between effecting and affecting something is that the former influences whereas the latter causes.

(Sorry, but… you asked! :smile: )
20 Aug, 2010, Rudha wrote in the 32nd comment:
Votes: 0
Heh, as long as we don't go all grammar nazi on me! Sprachen ze einglish!

For me looking at it from a developer point of view, it would be easy to add in extra variables to it if I decided anyways: I could make a central table where I have different percentage chances of different weather in a central function, then I could have separate functions that could further modify it by different variables, for example, a central function that computes the percentages for weather in a given room, area, or whatever unit I compartmentalise weather into, and then I could possibly add additional functions onto it that say for example, change that based on the weather in surrounding areas. This is where I was going earlier with that, if I know the central function works, it helps me mitigate the problems of debugging it by having that additional consideration in a separate function or module or whatever.

Maya/Rudha
20.0/32