Purpose - create large regions of areas by re-using a variety of template areas linked by scripting.
Any area-node in a region may be either a template area or a specific and unique crafted area.
Provide a defined structure to regions as settings for plotted areas and other mods - i.e. the Bonewash always runs northeast from *here* and the Hearthwood is right over there. *Not* randomly generated areas whose only consistent feature is their blandness.
Provide a persistent upgrade path. As new areas are completed, the take the place of template area place-holders.
Allow a relatively few templates to represent hundreds or thousands of areas without hitting NwN resource limits.
Let me repeat part of that in a different way. My idea here is to create a setting within which to set the gems of your creations. The regional mod will be the surrounding areas of wilderness and set here and there within it will be the destination and plot areas. It will, ideally, link across module and server. The Region is the gold, the plot mods/areas are the jewels. Together they make stop that! ...a whole greater than their parts.
Example: I am writing the Forester mod now. It is set in Tieri Verd'n (The Walking Woods). The Walking Woods are not *needed* for Forester, but if you download Forester and you download Tieri Verd'n and other mods that the region links to, then you may take a break from sweet-talking the troll Matriarch to wander down toward the Vale of Tears or the forest town of Elfhaven. Then wander back and see what mischief the hedgewitch and her daughter have got up to while you've been gone.
An important part of this process will be saving, restoring and updating state info when moving between mods and servers. I lack a lot of experience, particularly with moving between servers. But I learn fast :-) And I am humble enough to accept help and give credit :-)
Oh, one more thing. State info will be saved by node, not area. So if someone changes something in a certain place, the change will only occur at that node, not in the area that node shares with uncounted other places. Similarly, state info will be weighted by activity. Active nodes will hold on to their state data longer, while neglected/never visited nodes will bottom out at default (unspawned/inactive).
Example (planned): If a rampaging monster of the catastrophic variety hits the south end of the Walking woods and it takes a month for anyone to hear about it, it will devastate a large number of areas (nodes). These state changes will be done by scripting and should have minimal impact on performance. But when the PC gets to the area, they will find devastation! Later, when they haven't been by the site of their great triumph for a month or so, they will return to find the place sylvan once more. But it won't happen overnight or with a server reset :-P
Some points:
It's not a 1:1 grid system. It's a *defined* topology (currently defined in the
regnode_.2da ). The possible transitions from any given node are stored in the regnode_ definition. They can be adjusted once, there, instead of editing oodles of WPs and Triggers... This includes *vertical* links, incidently, that Cestus will be using for the dwarven citadel of Fireholt and the Underways region.
It's flexible in that "template" nodes (drawn from a pool of generic-but-classed areas) can be replaced when feasible with crafted areas without disturbing the weave of the region.
It's consistent in that the path and landmarks to any given area remain the same (*not* random).
It lends itself to a certain "traveling" map idea (a hybrid of DoD and Tarot's map-tiles) I have that builds a dynamic "worldmap" type area based on the areas (drawn from the region definition in regnode_).
It lends itself to the Travel Builder system of assigning travel times and encounter probabilities between nodes.
It lends itself to "shortcuts"... when you reach an area edge you have a choice of transitioning directly to the next node or calling up the traveling map of the region and jumping (with appropriate travel times) to any node you've already travelled.
Release roadmap:
Travel:
Inter-module transitions working
Inter-server transitions working
Travel times and multi-level regions
---
Ecology:
Biomass interactions & resource harvesting systems working
Creature migration & territorial behavior.
DM tools
---
Maps:
Map directives and miniatures working
Multi-level, fluid mapping (3D layers)
Updates:
2012-12-05: Initial upload v1.0 to this project
2012-12-02: v1.0 contributed to 2012-11 CCC: Sea, Air, Land Travel
Site
