This is an outline of the WorldFoundry Attribute editing system, and why we think it is a good idea.

Motivation - what is meant by "attribute editing"?

• architecture of game engine: the concept of "gameobjects"
• engine manipulates gameobjects in general-purpose ways (collision, physics, rendering properties EGColor,Reflectance,Intensity, universal rules not specific to any game)
• game logic manipulates gameobjects in game-specific ways (point values, triggers/traps/switches, AI-controlled movement)
• attributes are parameters that specify some property about the gameobject which influences the way either the engine or game logic handles the gameobject
• typed vs. non-typed systems. type safety. abstract types. Are typed gameobjects necessary for a game? (E.g. Blender has an attribute system for gameobjects, but it is non-typed, though it has a limited single-attribute type-like broadcast mechanism where a message can be broadcast to all objects possessing a certain attribute, which is a limited form of type discrimination.) Probably depends on complexity, same argument with typed vs. non-typed languages; typed are good for large systems; non-typed for quick prototypes.
• attribute editing with a typed gameobject system (briefly describe attribedit here - select type name, edit attributes). is inheritance allowed? multiple inheritance?
• evolution of attributes over time - why might a new type be needed? why might a new attribute be needed? how should these cases be handled?
• default values and override values. "must"-fields (fields which must be filled out). fields for which no sensible default exists?
• changes that are difficult to track (changing name of an object, deleting attributes in a type for which override values have been specified in instances of that type)

What properties must a general-purpose attribute-editing system have?

• easily extendable: ability to add new attributes to a object type, as well as completely new object types as the need arrises.
• easy to use. This includes being able to easily duplicate an existing behavior, as well as have reasonable defaults.
• fast. The designer MUST be able to make a change in the level editor and see it in the game within seconds.
• robust. The engineer must be able to change the way things work without breaking all of the level work which has already been done

How would one extend the system with new attributes and types?

The system was designed to make this easy: To add a new attribute: lets say you are adding the ability for your player to punch things, so you want the designers to be able to set how much damage a punch does. You would go to the player.oas file and add a line like the following:

TYPEENTRYINT32(Punch strength,punchStrength,0,40,10,"",SHOW_AS_SLIDER,"How much damage a punch does")

See OAD for documentation on the various type entries and what their fields are.

This tells the attribute system the new attribute is a 32 bit integer named Punch strength, with a minimum value of 0, a maximum of 40, defaults to 10, is displayed as a slider, and even has some pop up help. All the engineer has to do now is execute the makefile, rebuilding the OADs and the engine. Inside the engine the engineer will be able to read this new attribute from the player data structure: player->punchStrength, and in the level editor the attribute will appear on all objects of type "Player".

How could you interface this with an arbitrary 3D engine?

attribedit is a stand alone gtk-- program, it can be run on attribute data stored in a disk file.

To use attribedit in any 3D program it needs to have:

1. ability to store arbitrary text data in an object
2. ability to write a plugin which does the following:
   1. read data chuck back from selected object (if any)
   2. write it out to a temporary disk file
   3. call external program (attribedit)
   4. read disk file back in
   5. write it back into the selected object

similarly, another plugin would be used to export the level data:

1. iterate all objects, reading their attribute data, as well as position, orientation, size, and path
2. Write it out into an IFF file (.lev).

Then levelcon/Iff2lvl reads that iff file as well as all of the oad files, for each object loads the defaults, then applies the overrides from the lev file and creates the WF specific level file output.

That is all that is needed to use any 3D program with WF. See wfi3dplugins/LevelExportPlugin/wflevelexport.cpp

To use the attribute system with another 3D engine would require a different iff2lvl. unfortunately iff2lvl is a piece of crap, it has been adapted (read hacked) and ported many times since it was started in late 1994. Portions of what it does would be needed by any engine using our system (mostly reading the oad files and the .lev file and producing a binary structure filled out with the attributes for each object).

Just for fun, a short list of what has been done to iff2lvl:

• started as a dos application using dos4/gw under watcom, and tools.h++ (pre standard C++ library)
• made to use ever changing WorldFoundry libraries
• ported to windows msvc
• switched from tools.h++ to standard C++ library and early version of STL
• ported to be a 3D studio max plugin
• ported back to windows program
• input oad format changed from binary data to iff files
• ported to linux

Needless to say, some cruft has accumulated.

It probably wouldn't take me very long to write that portion from scratch using the classes in attribedit, but I don't know when I would have the time.

Another issue is that attribedit requires WF to build. It only uses the lower libraries, but currently wfsource is monolithic.

What specific things need to be done to get this working with Blender?

• Add GameData block to Blender objects
• Write python script to call attribedit on selected object
• Figure out how to access from object to its parent path in Blender Python, for exporting path info
• Write python script to duplicate functionality of wflevelexport.cpp, iterating all objects and their attributes and producing the ASCII IFF-format .LEV file which will get converted by iff2lvl. This allows Blender as a level editor.
• Tighter integration is probably very difficult

why is this whole thing a good idea?

Because the easier it is for designers to edit levels, the better the levels will be. The easier it is for engineers to adapt the system to changing needs, the better the game will be.