TWiki Home Tharsis . Design . ChangingRooms Tharsis webs:
Design | Guilds | Combat | Website
Design . { Home | Changes | Index | Search | Go }
I've been thinking about how to code weather and night/day so I thought I'd better write them down before I forget


At this time we are going for world-wide weather, not localised weather. It's feasible that we will in the future go with areas of the world with their own weather - even in this case the design below is expandable to suit.


We don't want to update the entire world every time the weather changes - IE the sun comes out from behind the clouds.

Most updates will just be textual messages to players - and can be delivered to players as such.

We do not include weather descriptions in the room description - we add it at the time someone does a look - thus adding a short amount of processing each "look" but not enough to make it considerable.

For changes altering light level see the stuff below regarding night/day.

For changes to the room which alter functionality - eg the ability to make snowballs - we probably have to provide the command at all times and only accept it during the right weather condition.

For changes which make gross alterations to the room, eg the room filling with water during a storm, there must be hooks to the weather daemon.


Optimise by providing 2 base classes for rooms - inside and outside. Weather code can then just be included in outdoor rooms, as a module to enable it to be added to indoor rooms as necessary.



I figure a range of light levels from -10 to 10 indicating "night with no moon" -> "midday" is probably going to provide enough range to keep us happy. We don't have to do anything different for each level in that range at this time - we can handle -10 as dark, 10 as light and 0 as "lit enough to see vaguely shapes" to get us to the point of release.

Note: torches are currently light level "1" - this seems to fit into the scale I have listed above.


Presume a time daemon that tells us when day/night/sunrise/etc occur - this might handle the binary-star system as per other topics or might be a single star system, it doesn't matter - we just need to be able to tell what the current ambient light level for the world is.

We further presume that we have just 1 light level across the whole world - although this might change in the future by adding time zones - highly unlikely.

The light level in a room is the ambient level + the level returned by the current query_light() call. For rooms which currently set_light(1) this will not have enough effect to screw things up on a scale of -10 to 10 if we break it up as -10->-4 is pitch dark, -3 to 3 is dimly lit and 4+ is daylight.

Presume for the first release that the time daemon just moves between -8, 0, 8 at different times of the day.

We should probably jack up torches to provide 3 light and provide lanterns with 8 light. This means in total dark you can see somewhat with a lantern and normally if you have a torch as well. In all times except total dark you can see normally if you have a torch.

By incorporating the ambient light level into the result returned by query_all_light() we make the change to room light levels very easily. All that then remains is updating /std/modules/living/m_sight to make query_can_see capable of returning the appropriate range of values rather than just 0 or 1 and then using those values appropriately in commands such as look.

If we return 0 = can't see, 1 = can see outline, 2 = can see detail then any usages of query_can_see will continue to work as they do now as they check by doing "if ( query_can_see(..) )". All that means is that commands treat objects as completely visible even if they are only visible as an outline.

Over time as commands are converted to support "outline only" and you do a look in a room and see "5 somethings" rather than "2 soldiers, a pram and Fantom" we will need to upgrade player.locate_object() to handle id checking properly - for you should not be able to do a "look at pram" unless you can see a pram and you should be able to do "look at something 2" - of course that opens a whole new can of worms relating to how we present a "something" when you look at it.

The concept of items being of varying visibility is currently ignored - you either see something or you don't ubt even if you don't and it talks you still see "Fantom says hi!". We have survived with this level of sophistication to date and there is no reason to use this as a sticking point now. We are aware that there is a large amount of effort required to use locate_object() everywhere it should be, to integrate it into verb handling and to integrate varying levels of visibility per viewer into the messaging code. This should not be seen as a reason not to press ahead with this coding as it's not going to be any worse under this system.

-- FantoM

Comments by FreD.

First I'll tackle night/day

We (Fred/Ranma) have determined two ways of doing this.
1) We add a second long description to every room that describes the room at night. This set_night_long would only be viewed when the "time module" determines that it is "night time" If a room is indoors, or lit by something, we can avoid adding a night description. The downfalls for this is a lot of work, adding descriptions to over 3000 inplay rooms

2) We make up several generic descriptions for every terrain type "coniferous forest, plains, beach" etc. We then give every outdoors room some extra code that would detail what type of terrain type it is. When night fell, the long description would change to suit what type it was. For instance if it was a forest room, a night description could read "The outlines of trees cut a stark constrast to the darkened sky"

Perhaps a combination of these two would help us quickly fix generic rooms (backbone rooms) and allow us to go into detail on specific rooms

A problem I see is that some current descriptions describe actions and mobs in their descriptions. The idea was that you'd get the night message, if you had no light source. But if suddenly you bring a light source and you see all of these people wandering around (see Tolnedra's market) it makes these methods that I've described useless.

now if we fixed all inplay room descriptions so that they just describe the environment we could have seperate day_chats and night_chats to describe the action

day_chat:Throngs of people wander the marketplace night_chat:A solitary figure darts out of the market

We could also add code that would allow us to add monsters during certain times of the day add_monster("/file/name/man.c", "2", "DAY"); <--add two of this monster file only during the day.

Weather is easier I feel. It involves adding appropirate chats to outdoor rooms and another line to what a person sees when they type look. Both of which would detail the weather

The weather module would determine what the weather is like, then each room would get weather_chats (room_chats that are specific to the weather)

So you'l see...
Several tall trees dot the edge of the road. The road itself is made of cobblestones and heads north and south.A sign is here.
(Hail pours from the sky)
exits (north, south)
many hailstones are here

then the occasional chat, Hail pours from the sky..

With a system like this we could again add weather specific mobs, only come out in good weather, or during bad weather.

Problems, weather over distances. Is the weather in the north the say as it is to the south? No, how do we fix this?

Also, using both systems we could have weather dependant objects, and we can keep the dark descriptions seperate from the weather.

Ranma 12 Nov 2003 21:02 - FreD 12 Nov 2003 21:02

I'd say that we can get away with chats for 90% of the stuff at this time - with the option (possibly player-based-preference) of turning on weather and light-level descriptions for rooms in the future. Like the time daemon the weather daemon provides hooks for weather alteration thus you can code weather-reactive items/rooms/mosnters.

This topic is about how to code it - there are other topics regarding what happens in rooms as time and weather changes.

-- FantoM - 12 Nov 2003

Perhaps we would need a tool that makes local weather changes and override night/day/time cycles to the current room only. For testing purposes. Might come in handy depending on how the whole thing is done -- FreD - 21 Nov 2003 15:46

Topic ChangingRooms . { Edit | Attach | Ref-By | Printable | Diffs | r1.9 | > | r1.8 | > | r1.7 | More }
Revision r1.9 - 20 Nov 2003 - 14:46 GMT - FreD
Parents: WebHome
Copyright © 2001 by the contributing authors. All material on this collaboration tool is the property of the contributing authors.
Ideas, requests, problems regarding Tharsis? Send feedback.