Weather

Design considerations

To goal was to have varying weather conditions that bring more variety to the game world. The system is not meant to be a realistic weather system, but it should not be obviously fake either. As such:

• Neighbouring zones should have either the same weather conditions, or they must not differ much.
• It should be possible to specify local conditions for zones, so that a zone can be more rainy than normal, for example.
• Weather changes should be gradual, so that a change from sunny to heavy rain should go through lighter rain states.
• The weather should follow the time of the year, so that for example it can snow during the winter, but not during summer.
• Zones should be able to specify a constant weather for special occasions. This was used to make snowfall for the Semos area during Christmas 2014 (That part of the weather system was completed first. And the request to have snowfall for Christmas was the inspiration for adding the weather system).

The first condition was most easily met by making the weather conditions same for all outsize zones. The second feature was implemented as local adjustments to the otherwise global weather. To keep the changes between zones small, the adjustments must not differ much from the neighbouring zones.

There's one existing exception to small adjustments rule: the Amazon area is significantly more rainy and warm than anything else in the game world. This can be done without problems, as there is no land road to the area - players must reach the island through a tunnel, or by using teleportation. So there is no obvious drastic change in weather type, when just walking from one outside map to another. An observant player can still notice that the island uses the same weather system as the rest of the game world - it always rains at Amazon, if it rains or snows elsewhere - the converse is not necessarily true.

Client side

The client draws the map layers using LayerRenderers. The weather is drawn as another layer above the normal map layers. For that purpose a new LayerRenderer implementation was added. The normal tile renderer was deemed inadequate for the task, as the small tile size would make the weather too obviously tiled. WeatherLayerRenderer is capable of using arbitrary sized square tiles, and can animate them if they have a specified animation sequence.

The data the client has about the weather, is just a weather state name. The client will look up an image by the weather state name to be used for the weather in data/sprites/weather/ and if found, create a WeatherLayerRenderer from that. Additionally, the client tries to look up a sound by the same name in data/sounds/weather/, and if one is found, keep playing it until the weather state changes. In other words, the client does not interpret the weather in any way, it just tries to draw and play whatever the server tells it to.

Communication between the server and the client

Weather state is included in the data layerof the zone. So when a player enters a zone, the weather data is immediately available. Weather changes are communicated as "fake" zone changes. That is, the server requests transferring zone data, despite the player has not changed zone. The client caches the normal layers, so only the data layer needs to be transferred. This is the same mechanism as is used by the daylight changes, and actually some of the code used by the daylight updater was moved to zone,now that there's more than one user for it.

Testing

Pretty pictures