[crossfire] Reimplementing seasonal weather.

[Mark Wedel]

Andrew Fuchs wrote:
> I just had a conversation on IRC with Raphaël Quinet, relating to
> seasonal changes to the world. I was thinking about making an ice
> dungeon in the middle of a lake, that, by using the existing scripts
> relating to time, would only 'exist' during winter when the lake freezes
> over.
> Raphaël brought up the point, that if such a dungeon existed, it would
> make sense to have most of the world change to visually indicate the
> current season to players. Think about trees loosing their leaves, snow
> appearing on the ground, and lakes freezing over.
> 
> A few ways for this to be implemented came up:
>   * Allow the scripts that replace objects based on time to be attached
> to regions. However, this could affect indoor maps unless they are
> excluded by the code.
>   * Create (or modify) archetypes that would change, based on the
> season. This could be done with C code or by attaching scripts.
>   * Have attributes that specify how such objects change.

  I think the third point (attributes that dictate changes) is the best way to 
go.  We should have learned by now that hard coding object attributes just don't 
work.

  Also, having it an archetype type attribute probably makes it easier to non 
coders to do updates - they just update the archetypes, they don't have to worry 
about modifying code, be that scripts or C code.

  The other advantage relates to your point below - by it being an object 
attribute, that attribute can be set/cleared in a map.  Have an object you don't 
want changed on a map?  Easy to do.

  That attribute could really just be a list of archetypes that dictate what 
archetype to use for different seasons.  Something sort of like how animations 
are done.  If one supposes you have 4 tree archetypes that dictate the 4 
seasons, all of those different archetypes would still use that same seasonal 
information.  and like animations, the size of that list wouldn't need to be a 
fixed number.  A simple object maybe has 4 such seasonal archetypes.  A more 
complex one could have 12 (one for each month).

  An advantage of this referring to different archetypes is each archetype still 
has full archetype abilities (meaning animation, as well as block and slow 
move).  Moving over snow covered grass is perhaps slower than moving over dry 
grass in the fall.  Likewise, frozen swamp is probably faster than non frozen 
swamp.

> 
> A few things should be considered if this is done:
>   * It would also be nice to allow various 'climates' to be specified by
> region.

  Yes - perhaps instead of it being based on region (which could involve a fair 
number of climates), just another attribute in the map header - climate - could 
be added.

  A reasonable number of standard climates would need to be decided on - if the 
list is too big, it then could become too hard cover all the different climates. 
  I'd rather have just a few climates which all the relevant archetypes are 
updated for, vs a lot of climates, of which coverage is spotty.

  In fact, it could make sense to just make one climate to start out with, do 
all the updates for that, and when that is done, add the next climate, and 
repeat.  But probably still a good idea to have a roadmap of what the list of 
climates are so you don't do three of those and then say 'oops  - this one is a 
lot like the first one, but not quite', and you have to go and fix up the first one.

>   * Regardless of the implementation, special care should probably be
> taken to preserve special attributes of the objects being replaced or
> modified. If this is not done, exits and other objects can break.

  True.  It might be easiest/best to decouple special attributes from the 
'scenery' objects.  For example, that tree that is also an exit?  Make that tree 
just a tree and put in a separate exit object.

>   * If lakes and rivers are to freeze over, attention should be paid to
> areas where water is used to block players (such as the lake south of
> Brest). However, if we solve these issues, it also allows us to give
> pilot-able boats to players. Possible solutions include, not freezing
> certain parts of lakes, or the creation blocking tiles such as slush or
> very thin ice.

  And not all lakes/rivers necessary have to freeze over - there are lots of 
likes and rivers in the world that don't do so.

  There are a few ways one could handle this - simplest would be for objects 
that always need to block passage, just put in some invisible blocking object 
(simple to do, may be time consuming to update the maps).

  If the seasonal changes are an object attribute, it then does become possible 
to have those rivers just not freeze over (clear the appropriate attributes), or 
have a different list which says something like 'impassable river', etc.  all 
the graphics could be the same, just object attribute is different.

  It'd perhaps be fun even for the normal rivers that do freeze over to have 
different levels of thickness - in dead winter, anyone can walk over them, but 
in fall/spring, maybe the weight of the character indicates some chance to break 
through the ice and take damage.

  I'd also be nice to add objects that only show up in certain seasons - that 
could be done by that seasonal loop also including a bunch of invisible objects 
that do nothing - in seasons you don't want it, the code just puts that 
invisible object there - in seasons it is supposed to show up, the real object 
would be there.

  One other consideration here is when/how these seasonal changes take place, 
code wise.  There are 2 main ways it could be handled:

1) When map is loaded, seasonal changes are applied.  This may be the simplest, 
and has an added bonus that this logic could still get applied to those 
temporary maps that got swapped out.  The only real downside is that map loading 
can be one of the slower operations right now.  If this seasonal code is kept 
pretty simple, not a big deal - lots of processing already happens when a map 
loads, and updating the object at load time wouldn't add much.  But this does 
limit long term complexibility.

2) Doing it as a separate task/process - has the advantage that things could be 
made very complex with little impact on the game itself.  It does add some extra 
work to synchronize with the server itself (but even that would be pretty 
simple).  I'd only go this way if it is believed it would become pretty complex.