A persistent world set in the Frozen North of The Forgotten Realms


You are not connected. Please login or register

Custom Content by Amun Quoi

Go down  Message [Page 1 of 1]

1 Custom Content by Amun Quoi on Mon Oct 25, 2010 11:08 am


Something to keep in mind when suggesting new additions. I'm not looking to shoot down all requests for additions (as a player, I like new stuff! Smile), but I'm hoping that this post will help in understanding why some requests are turned down as "too much work".

Also, this post is made purely from a technical standpoint. Even if something is easy to implement, there may be other reasons not to include it.

I will break down the different types of content, and describe three aspects of each: Implementation, or how easy it is to get the content into the module; maintenance, or how much work the content will continue to require from the developers; and consequences for the players.

PC customizations
Examples: new heads and hairstyles, wings, racial appearances

Implementation: Easy. Add the new models and a modified 2DA into the hak. The 2DA is a file that links the 3D model resources with the toolset and the module. If new content is added from multiple authors, there's a good chance that there will be 2DA conflicts, such as the ID of a new head from Package A conflicting with the ID of a different head from Package B. In this case, the devs must manually modify the 2DAs and remove conflicts, which is very time-consuming.

Maintenance: Usually low. Official game patches usually don't modify the way graphics are handled, and there's little chance of breakage. However, if there were 2DA conflicts and the original packages get updated, the manual 2DA editing has to be done all over again.

Consequences: The size of the HAK file grows, and whenever new content is added, everyone must re-download the HAK.

3D models for items and creatures
Examples: weapons, clothing, holy symbols, monsters

Implementation: Medium. Same as with PC customizations, but in addition, all new models for items require the actual item blueprints to be created into the module. For example, a new longsword model isn't much good by itself, unless the builders create templates for Longsword, Longsword +1, Longsword +2 and so on that actually use that model. The items also need to be added to vendors and/or monster loot packages.

With creatures, the blueprints must also be made, and the creatures must be created with the proper abilities and challenge ratings to fit into the module. By extension, areas that are populated with said monsters also need to be built.

Sometimes, authors of models have pre-created blueprints, sometimes not.

Maintenance: Low. Once the items are in-game, you don't need to do much to them, and as with PC customizations, patches are unlikely to break anything.

Consequences: Again, the HAK size increases.

Scenery, tilesets etc.
Examples: buildings, trees, dungeons, Menzoberranzan

Implementation: Fairly difficult. All the troubles of 3D models, but with the addition of new ways for the toolset to crash and generally misbehave. Especially tilesets are complex pieces of work that include not only graphics, but also walkmeshes and logic on fitting pieces together.

Maintenance: Anything from low to high. If everything goes smoothly, there's little to do once the content is in place, but there are many things that can break during building. The worst part is that once the new content is added, getting it out again cleanly can be painful, or even impossible. So, adding stuff into the module is a risk that may end up causing a whole lot of work if it doesn't cooperate.

Consequences: You've probably seen the graphical glitches in High Hold and Quaervarr. From what I've been told, they are caused by custom scenery, so unexpected issues like these may crop up without warning.

Examples: Anything that doesn't fall into the categories above, like crafting systems, bleeding systems, monster spawning systems, ruleset changes, changes to spells, skills and feats, new races and classes, languages, etc.

Implementation: Anything between easy and extremely difficult. Scripts are the most fickle of all custom content. Scripts are essentially pieces of program code that usually rely on other scripts and the game to work in a certain way. A seemingly innocent script can break something quite unrelated due to programmatic dependencies.

For example, a script that gives creatures random weapons on spawning may not work at all if the spawning script itself has been modified for some other reason.

In NWN1, an extremely simple script that automatically closed doors some time after opening them used to warp a random player in the area to the door when it closed, because the game wanted to think that doors are always closed by creatures.

And here's an even more convoluted example. Let's say we have a script for keeping track of a custom skill, like fishing, that saves the skill in a local variable on the PC. Then we take a completely different script, like a dungeon that keeps track of how many statues the PC has clicked on to open a door at the end - and naturally, the statue count is saved in a local variable on the PC. If the dungeon script accidentally deletes all local variables, the fishing skill will reset. Without knowing how the two scripts work, there's absolutely no way of making the connection.

Since every script has a theoretical chance of breaking any other script, they must be playtested thoroughly before they can be added. Even so, unseen consequences may arise.

Maintenance: Very high. Because scripts rely on the game to work in a certain way, every official game patch has a high chance of breaking a script. So, every time a new patch arrives, the scripters must go through each and every script to check if they still work. Add to that the fact that a patch may cause two previously unrelated scripts to break each other only in certain circumstances, and you have a nightmare on your hands.

In the case of third-party scripts (not written by this server's scripters, but the ones you find on NWVault), maintenance becomes even more difficult. For every patch, the devs have to rely on the script's author to update them to be compatible with the latest patch. If the author goes missing, the only choices are not patching at all, trying to fix it internally (making sense of someone else's code is difficult), or removing that functionality from the module (which may not even be possible if it's highly integrated).

Consequences: Every patch will cause a lot of work for the devs, which means that patching will have to be delayed until the module has been tested to work at least somehow. Naturally, many bugs will remain to be discovered unexpectedly by players, causing a lot of bug reports.

Now, I may sound a bit pessimistic here with scripts, but what I'm getting at is that even a simple script can have complex consequences that are in no way related to what the script does. So, even if it's easy to write a script to make you bleed to -10 hit points instead of dying, it can break so many other unrelated things that the whole process of implementation becomes a lot of work.

View user profile

Back to top  Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum