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. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
