Post by kalbaern on Oct 30, 2013 12:17:27 GMT -5
An important thing to consider is the scope of any module. If you're creating an Single Player or even Co Op Module, you can likely ignore adding DM Tools and you might not even require Area Cleaners. If you're building a Persistant World however, you'll need those and a ton more.
Scope or Scale of a Module
Whether your module focuses on a single town and adventures within and nearby or you seek to create vast regions as we do here, keep in mind that as "realistic" as it might initially seem, most players won't visit for long if they are required to traverse area after area with little to do before reaching a destination.
I'll use this place as an example of Scope and Scale. Our over all Scope is to one day have a PW that encompasses most of "The Savage Frontier" and "The High Forest" along with parts of the "Anauroch", "The Western Heartlands" and "The Sword Coast". With such a large set of regions to duplicate, scaling is important. Our starting town, Orlbar, is a town of roughly 400 folks in source materials. That's roughly 100 homes with half or more of those scattered outside the gates of the town and used as small farms and sheep/goat ranches. If we actually built Orlbar to scale, we'd need around 20 areas/maps to represent it properly. Just how many "goat quests" would players tolerate before reaching the wilderness areas?
So, here on The Savage Frontier and Surrounds, we build using "approximate" and "representative" scaling instead. Our start town and surrounding areas provide a taste, some flavor to set the tone and things are scaled back. Major sites and NPCs from source books are integrated, but we avoided creating 400+ unique NPCs just to populate the area.
Using representative scaling, we later built a region to the west of Orlbar known as "The Gray Wilds". In sources, this is a fairly open penninsula of land bordered by two major rivers and a mountain range. Had we used the same ratios as with Orlbar, this region would've been over 100 maps before any actual dungeons/lairs were added in. Instead, we built it using two dozen exterior maps with a variety of encounters, dungeons and lairs added to represent the general theme or flavor of the area.
Since our PW here is inspired by source materials for PnP (pencil and paper/table top D&D) games, we've built it similar to running that type of a campaign. Travelling great distances in a PnP session is rarely to scale, but rather its representative. I.e., the DM (Dungeon Master) will provide distractions in the way of hostile encounters or interactions with various NPCs as you make your way to a destination. Using NWN, we represent this by creating X number of areas and adding encounters suitable to the region or theme.
Some players insist on continuity of areas. Its up to each builder to decide how much that'll come into play. If you use a representative map, then every little stream from map "A" needn't continue on maps "B" or "C". Myself, major features like hills, actual rivers, forests, mountains and lakes are fairly contiguous in that you can walk their borders and see IG that the mountain/hills/lake begin on your right while the plains extend off to your left. Not every stream, hillock or copse is contiguous however.
There's a system used in a few modules that more than a few players have asked to have here. Its known as Seamless Transitions and can be found on the NWN Vault. Link: Seamless Transitions While its a pretty optimized system script-wise, it does add abit to lag, especially if your module will exceed more than a few hundred areas. It also requires a builder to keep all of their map sizes the exact same dimensions. I.e., all maps using the system have to be equal squares of 8x8, 10x10, 15x15, etc... . While most of my own areas (exteriors) are 10x10, I break up the rigidness with a smattering of 8x12, 9x11 and 6x14 maps as well. For anyone desiring though and not minding making all their exteriors the same dimensions, its a worthwhile system to play with. Just know that over 300 or so areas and it does begin to have a slight though noticeable CPU hit to your server if used for a PW.
If your module will include large towns, make sure they aren't too large. If your main town is 24 exterior maps, just make sure to have enough shops, inns, taverns and adventures to support your map total. While several neighborhoods full of houses and NPCs wandering the streets may help set the mood of a large town, players get bored quickly if there's little adventure to be found there and can even resent having to trudge through several areas just to find something they can actually do*. (Do* = stuff to kill or other means of getting loot and XP.)
Planning your module using graph paper can help alot. Decide on the extent to which your module will cover areas, regions, nations, etc... and draw a simple chart of major divisions. As an example here, we divided our initial regions as; the High Forest, the High Moors, The Graypeak Mountains, the towns of Orlbar, Llorkh, Loudwater and Secomber, the Serpent Hills, etc...
Later, render each division as a chart of their individual maps. Use these detailed region maps to note features like planned dungeons, links/transitions to each other and to other adjoining regions and any other notes you might find helpful.
Balancing Changes
One thing most builders change without realising at first how it affects the game is how fast time passes in game. NWN was balanced and encounters scaled based on 2 minutes of real time equalling 1 hour of in game time. So in the original campaigns, a Barkskin potion only lasted 6 minutes. Summoned Creatures, which last 24 hours game time would last only 48 minutes in real time. So when how fast in game time passes is modified, as many are want to do, it immediately has a profound impact on game play. Module builders change the default passage of time for any number of reasons, generally they relate to RPing so that during a half hour to an hour long real time event by players, they don't see the sun rise and fall a few times.
What is often not considered by builders is how upsetting to balance that slowing (or quickening later) the passage of in game time can be. Most PWs seem to settle on 10 minutes real time equalling 1 hour game time. Pause and consider this. Suddenly, the barkskin that lasts just 6 minutes of playing time now lasts a half hour. Thats protection for 5 times the original design by Bioware. Your summons with a 24 hour duration now last a full 4 hours of playing time.
Bioware originally set in game time passage to corrolate roughly to the passage of game time in a PnP session. The original campaign modules where designed with encounters and XP set as if it were a DM'd PnP session as well. If you're just designing a Single Player or Co Op Module that players are expected to finish in 10 or even 20 hours of game play, then altering the passage rate of game time isn't likely warranted and hence not an issue. If you're designing an arena module or a hack-n-slash romp where hitting max level easilly is desired, again, the passage of game time can likely be ignored and left as defaulted.
10 minutes per hour vs 2 minutes per hour is a vast difference, especially on a PW. If you make such a change, but don't additionally alter some if not most spell and effect durations, then suddenly, casters become over powered and the preferred build choice. Its hard to offer or promote unique and diverse characters when a select few classes are much more powerful than the rest.
If you plan to alter time passage, you next have to consider what if any changes or restrictions you'll make to resting. Will resting be allowed everywhere? Will there be a minimum amount of time lapsed between rests? Will resting be restricted to select areas only? Can you rest in dungeons? Changes to resting can help balance casters due to spell durations lasting longer if you change time passage in game. Too severe and suddenly non-casters become the preferred classes to play though.
Finding balance with any changes is never a clear cut path. With so many PWs and Modules available to peruse, I suggest builders look around, test the waters here and there and make a concise list of things they both like and dislike about changes and tweaks found elsewhere before they settle on their own.
Adding Haks
I'm not going to delve into how to add haks to your modules as the "how" varies from hak to hak most often. Anyone wishing to adopt the haks used here, either whole or partially, I'll do my best to help determine the proper hak orders for. In general though, I heavilly support the use of haks in any new module. After all, its the new cool features ranging from tilesets to creatures to armors and much more that have kept this game alive for 11+ years now.
There's nothing wrong with making a "vanilla" module and skipping haks entirely. However, when you do use haks, you'll find that your building options are expanded a hundred fold.
Haks can also have a major impact on overall efficiency. The fewer placeables you use in each area/map, the smaller it'll be in shear size (memory) and the better pathfinding will generally be. There'll also be far fewer "objects" for scripts to search through when needed.
Scripts that do searches, of either an area or the whole module can be a problem when used too often or improperly. Even when efficiently coded and used sparingly, they can have noticeable impacts on performance. A script with a function to "GetNearest" or "GetObjectByTag" will search the entire area and check each object looking for a match. So a map with 100+ placeables, triggers, creatures, etc... causes all those objects to be compared before the script finds what it needs (or not) and finishes running. So simply put, the less you place in an area/map the smoother your module will run. Areas where PvP is unlikely or not allowed can tolerate far more objects than your average dungeon.
So haks, especially those that expand tileset options go along ways to making your modules lean and unique.
Scope or Scale of a Module
Whether your module focuses on a single town and adventures within and nearby or you seek to create vast regions as we do here, keep in mind that as "realistic" as it might initially seem, most players won't visit for long if they are required to traverse area after area with little to do before reaching a destination.
I'll use this place as an example of Scope and Scale. Our over all Scope is to one day have a PW that encompasses most of "The Savage Frontier" and "The High Forest" along with parts of the "Anauroch", "The Western Heartlands" and "The Sword Coast". With such a large set of regions to duplicate, scaling is important. Our starting town, Orlbar, is a town of roughly 400 folks in source materials. That's roughly 100 homes with half or more of those scattered outside the gates of the town and used as small farms and sheep/goat ranches. If we actually built Orlbar to scale, we'd need around 20 areas/maps to represent it properly. Just how many "goat quests" would players tolerate before reaching the wilderness areas?
So, here on The Savage Frontier and Surrounds, we build using "approximate" and "representative" scaling instead. Our start town and surrounding areas provide a taste, some flavor to set the tone and things are scaled back. Major sites and NPCs from source books are integrated, but we avoided creating 400+ unique NPCs just to populate the area.
Using representative scaling, we later built a region to the west of Orlbar known as "The Gray Wilds". In sources, this is a fairly open penninsula of land bordered by two major rivers and a mountain range. Had we used the same ratios as with Orlbar, this region would've been over 100 maps before any actual dungeons/lairs were added in. Instead, we built it using two dozen exterior maps with a variety of encounters, dungeons and lairs added to represent the general theme or flavor of the area.
Since our PW here is inspired by source materials for PnP (pencil and paper/table top D&D) games, we've built it similar to running that type of a campaign. Travelling great distances in a PnP session is rarely to scale, but rather its representative. I.e., the DM (Dungeon Master) will provide distractions in the way of hostile encounters or interactions with various NPCs as you make your way to a destination. Using NWN, we represent this by creating X number of areas and adding encounters suitable to the region or theme.
Some players insist on continuity of areas. Its up to each builder to decide how much that'll come into play. If you use a representative map, then every little stream from map "A" needn't continue on maps "B" or "C". Myself, major features like hills, actual rivers, forests, mountains and lakes are fairly contiguous in that you can walk their borders and see IG that the mountain/hills/lake begin on your right while the plains extend off to your left. Not every stream, hillock or copse is contiguous however.
There's a system used in a few modules that more than a few players have asked to have here. Its known as Seamless Transitions and can be found on the NWN Vault. Link: Seamless Transitions While its a pretty optimized system script-wise, it does add abit to lag, especially if your module will exceed more than a few hundred areas. It also requires a builder to keep all of their map sizes the exact same dimensions. I.e., all maps using the system have to be equal squares of 8x8, 10x10, 15x15, etc... . While most of my own areas (exteriors) are 10x10, I break up the rigidness with a smattering of 8x12, 9x11 and 6x14 maps as well. For anyone desiring though and not minding making all their exteriors the same dimensions, its a worthwhile system to play with. Just know that over 300 or so areas and it does begin to have a slight though noticeable CPU hit to your server if used for a PW.
If your module will include large towns, make sure they aren't too large. If your main town is 24 exterior maps, just make sure to have enough shops, inns, taverns and adventures to support your map total. While several neighborhoods full of houses and NPCs wandering the streets may help set the mood of a large town, players get bored quickly if there's little adventure to be found there and can even resent having to trudge through several areas just to find something they can actually do*. (Do* = stuff to kill or other means of getting loot and XP.)
Planning your module using graph paper can help alot. Decide on the extent to which your module will cover areas, regions, nations, etc... and draw a simple chart of major divisions. As an example here, we divided our initial regions as; the High Forest, the High Moors, The Graypeak Mountains, the towns of Orlbar, Llorkh, Loudwater and Secomber, the Serpent Hills, etc...
Later, render each division as a chart of their individual maps. Use these detailed region maps to note features like planned dungeons, links/transitions to each other and to other adjoining regions and any other notes you might find helpful.
Balancing Changes
One thing most builders change without realising at first how it affects the game is how fast time passes in game. NWN was balanced and encounters scaled based on 2 minutes of real time equalling 1 hour of in game time. So in the original campaigns, a Barkskin potion only lasted 6 minutes. Summoned Creatures, which last 24 hours game time would last only 48 minutes in real time. So when how fast in game time passes is modified, as many are want to do, it immediately has a profound impact on game play. Module builders change the default passage of time for any number of reasons, generally they relate to RPing so that during a half hour to an hour long real time event by players, they don't see the sun rise and fall a few times.
What is often not considered by builders is how upsetting to balance that slowing (or quickening later) the passage of in game time can be. Most PWs seem to settle on 10 minutes real time equalling 1 hour game time. Pause and consider this. Suddenly, the barkskin that lasts just 6 minutes of playing time now lasts a half hour. Thats protection for 5 times the original design by Bioware. Your summons with a 24 hour duration now last a full 4 hours of playing time.
Bioware originally set in game time passage to corrolate roughly to the passage of game time in a PnP session. The original campaign modules where designed with encounters and XP set as if it were a DM'd PnP session as well. If you're just designing a Single Player or Co Op Module that players are expected to finish in 10 or even 20 hours of game play, then altering the passage rate of game time isn't likely warranted and hence not an issue. If you're designing an arena module or a hack-n-slash romp where hitting max level easilly is desired, again, the passage of game time can likely be ignored and left as defaulted.
10 minutes per hour vs 2 minutes per hour is a vast difference, especially on a PW. If you make such a change, but don't additionally alter some if not most spell and effect durations, then suddenly, casters become over powered and the preferred build choice. Its hard to offer or promote unique and diverse characters when a select few classes are much more powerful than the rest.
If you plan to alter time passage, you next have to consider what if any changes or restrictions you'll make to resting. Will resting be allowed everywhere? Will there be a minimum amount of time lapsed between rests? Will resting be restricted to select areas only? Can you rest in dungeons? Changes to resting can help balance casters due to spell durations lasting longer if you change time passage in game. Too severe and suddenly non-casters become the preferred classes to play though.
Finding balance with any changes is never a clear cut path. With so many PWs and Modules available to peruse, I suggest builders look around, test the waters here and there and make a concise list of things they both like and dislike about changes and tweaks found elsewhere before they settle on their own.
Adding Haks
I'm not going to delve into how to add haks to your modules as the "how" varies from hak to hak most often. Anyone wishing to adopt the haks used here, either whole or partially, I'll do my best to help determine the proper hak orders for. In general though, I heavilly support the use of haks in any new module. After all, its the new cool features ranging from tilesets to creatures to armors and much more that have kept this game alive for 11+ years now.
There's nothing wrong with making a "vanilla" module and skipping haks entirely. However, when you do use haks, you'll find that your building options are expanded a hundred fold.
Haks can also have a major impact on overall efficiency. The fewer placeables you use in each area/map, the smaller it'll be in shear size (memory) and the better pathfinding will generally be. There'll also be far fewer "objects" for scripts to search through when needed.
Scripts that do searches, of either an area or the whole module can be a problem when used too often or improperly. Even when efficiently coded and used sparingly, they can have noticeable impacts on performance. A script with a function to "GetNearest" or "GetObjectByTag" will search the entire area and check each object looking for a match. So a map with 100+ placeables, triggers, creatures, etc... causes all those objects to be compared before the script finds what it needs (or not) and finishes running. So simply put, the less you place in an area/map the smoother your module will run. Areas where PvP is unlikely or not allowed can tolerate far more objects than your average dungeon.
So haks, especially those that expand tileset options go along ways to making your modules lean and unique.