Everybody that actually worked with N3 has probably stumbled over NIDL files. They are basically XML files that are compiled to c++ code via the idl compiler and then included in the project. They are used for example for defining the messages between entities/properties and for defining new scripting commands.

One of our age old problem when creating a level editor tool was the use of properties and attributes in the project. If the editor wants to be able to display information about properties and allow editing of attributes, it has to be linked to the actual project in some way since all that information is defined only in the code. At first we had the idea to turn everything into a shared library and use a simple launcher that will load the games shared library and then run it. That would allow the level editor to actually just load in the specific game’s library and add the actual properties to the project. While that would definitely be awesome we decided against that for the time being since we don’t have enough time.

Our much simpler solution is to have the level editor only use very simple entities with graphics and physics (for picking) and just use generic editor widgets for all attributes used by the entity. The drawback with this option is that it’s not possible to see the effect of most attributes live, but at least it is possible to edit, save and batch them to the level database.
However, this does not solve the problem of the editor not knowing about what attributes exist and are used by which entity class. Now this is where the NIDL files come into play again. I extended the idl compiler to support new entries for attributes and properties and even the information about what attributes are used by which property. Those NIDL files can then be used by the level editor to display and edit unknown attributes and properties, additionally the idl compiler will generate code that automatically defines and declares all attributes and even registers them in the properties automatically so that they don’t need to be defined in the code as well, thus avoiding the risk for them being out of sync.