Bethesda Softworks Forces Website to Pull Modding Tool

[Naked Ninja]

Except the first unreal engine used in Unreal and UT'99. The only fog those support is volumetric lighting, which allows for some impressive eyecandy, but it's a resource hog when used in any large quantites, and, as such, completely unsuitable for the role of distance fog.

Erm, what? Fog isn't the same as volumetric lighting, and any system with volumetric lighting can handle distance fog. If they didn't have it then they simply forgot to expose it to script, distance fog has been in both opengl and directx since before I started looking at graphics at all. I suggest checking the Opengl Red Book or basic directX documentation.



...talking about SoW is much more interesting so....

How about changing formulae, rather than just coefficients? E.g. say that maximum encumbrance is currently X*Strength + Y, and you wanted to change it to say X*(Strength^2 + Endurance) + Y. Does that kind of change have you ferreting around in source code / data files / a GUI...?

At the moment, script files, but not those DB scripts I talked about. The actual torque script files...but we are talking 1 function in 1 file which is trivial to understand for anyone with a basic understanding of code. I could move it to the DB without too much trouble but I kind of like it where it is, centralized in 1 point, for readability. I'll see if I leave it there or move it, either way, it'll be exposed to modders. If it's in the torque script file it will mean you edit it in a text editor instead of in the engine, in a gui. You see screwing that up could have a lot of negative knock on effects, I may leave it as something more advanced modders can get their hands on if they want but your casuals can't just easily bone.

If it means changing the source, is that cumbersome? Would it be cumbersome if you were doing it much more frequently? Do you think you'd play around with formulae more if it were simpler (if it could be)? Do you think the game would benefit significantly?

Trivial. I do it frequently. One of the main reasons to use scripting, you can change things quickly and play around with formulae. I practice Rapid Development so it is invaluable.

would you say the functional efforts towards versatility have paid/will pay off for you? Would you do things functionally the same way if modders weren't an issue?

Oh yes, paying off indeed. I'd do it the same if modders weren't an issue, sans documentation, and probably slightly less polished. The payoffs in terms of time saving for me are great. It's win-win.

How have you organized things scriptwise?

Foundation scripts are organized per subsystem. User scripts (the ones that sit in the DB) are called via hooks at logically appropriate points from the subsystems and are indexed simply by name/ID. Eg : When a creature dies it calls an "OnDeath" script which can be any DB script. I have an amusing DoSuicideBomb() script which sends everything around the creature flying into the air.

Another example : When a quest node (the questing system is a Finite State Machine) receives an event (which a user script can throw out) it passes the event to the quest node script, which is also user created. When a spell or ability triggers that uses a ScriptFunction element it also runs a user defined script. During dialogue any element can trigger off a user defined script. You get the idea. Logically appropriate callbacks at hook points.

Presumably you have scripts that run on all objects of type X, as well as unique ones to run on specific objects.

Yep and yep.

What about scripts that don't run for a specific target object?

Don't need to target anything at all.

How much autonomy/scope do scripts have - are there access restrictions, with some kind of structure/hierarchy, or is it a free-for-all with the individual modder setting boundaries?

Depends on what you are accessing. Generally it's pretty much a free for all, especially with pure script elements (which is a good portion of the structure). With other elements you need to understand the underlying foundation structures. No script would allow you to do something the engine didn't allow, obviously. But if you wanted to run a script that deleted every NPC with a name starting with 'A' within 100 ft, then spawn a MonsterX in the exact spot each deleted creature used to stand in and set them all to moving towards the town square, you could do it.

How easy is it for scripts to acquire and use references/handles to generic objects?

Easy. Do a radius/distance or global search for all objects of type X.

e.g. can a script get a handle to all NPCs in 50 feet, then do scripted stuff to them; can a script get handles to all active quests and do something to them [e.g. suspend them while some-weird-stuff happens]..

As above, yes to the first part. As to the quests, yeah, but to suspend them you'd need to write them to process a "suspend" event (see Finite State Machines). Iterating through all quests and sending them an event, sure.

If you have relatively little organization / few restrictions for scripts, does that make organization of your systems more difficult?

It's organized, but not tightly access controlled. Which means, potentially, you could create a script which wreaked havoc with data structures if you felt so inclined. But my thinking is : "Hey, so what, you paid, enjoy yourself".

f you think things are both well organized and highly versatile, how have you gone about this? [specifics welcome, but general principles will do]

Heh, well, I don't know if others would classify it at as the most organized system out there. I like it though. Basically, I achieved this through the callback hooks. When a creature is damaged it calls back to an OnDamaged callback. This, logically, handles the damage event. But like I said, no tight access control, so it could do something completely unrelated to the entity being damaged. Like...loading another stage, altering the players inventory, heck, popping open a web page with the Codex on it.

You can think of the callbacks as programmable bridges between hardcoded functionality. They are logically scoped to an interaction between elements, but not actually coded to be bound purely to the scope of that interaction.

Logically scoped, but I don't enforce the scope if you want to step outside it.

 

[galsiah]

Great stuff all round. Clearly the lack of access controls is nice for modders (and for you if you decide craziness is necessary late in the day), but I had concerns that such a potential free-for-all would turn into a total mess in development. It's good to know that sticking to your self-imposed informal structures works out ok (so far :D).

 

[MetalCraze]

Except the first unreal engine used in Unreal and UT'99. The only fog those support is volumetric lighting, which allows for some impressive eyecandy, but it's a resource hog when used in any large quantites, and, as such, completely unsuitable for the role of distance fog.

Erm, what? Fog isn't the same as volumetric lighting, and any system with volumetric lighting can handle distance fog. If they didn't have it then they simply forgot to expose it to script, distance fog has been in both opengl and directx since before I started looking at graphics at all. I suggest checking the Opengl Red Book or basic directX documentation.

+1
even more - OpenGL even has separate self-explaining function for it
glFog

don't see how it's related to something supported in the engine as fog was always in opengl f.e. and as far as I remember Unreal engine was built around OpenGL originally

 

[Naked Ninja]

@ Draq : Aaaaah, now I understand why you compared volumetric lighting to fog. You're looking at it from the outside, at what it simulates. Yes, volumetric light is supposed to simulate light beams passing through some form of particle, like fog, dust, whatever.

However, the underlying techniques are completely seperate. This often confuses people who aren't aware of how the tech works. For example, confusing at is may seem, lighting and shadowing are two very seperate techniques.

Anyway, volumetric light is achieved by using transparent 3D models which look like the beams coming down. Distance fog is a pair of variables you set, max fog distance and fog colour. It then shades each vertex of an object based on what percentage of the max distance it is away from the viewer X fog colour.

They are two seperate techniques not really related at all. Volumetric light is actually a 3D model and not really a type of "fog". As a reference, distance fog is still a simpler and older technique. In fact that form of volumetric light isn't really what you'd call a gfx technique, its an art asset illusion.

*The reason volumetric fog is a system hog is because transparent objects cause more overdraw, which is costly.

 

[Shannow]

Clearly the codex needs a sub-section for modders.