A common task in game development is serializing objects to and from various storage or transmission mediums, and another is exposing those objects to scripting engines, command and debug windows, and other user interfaces. This article addresses these issues through the use of a generic attribute management system.

Every object can be identified by one or more attributes. Once registered with an attribute manager, these attributes can be serialized or exposed, and each can be queried to read or modify its value at any time.

Unlike C#/CLI properties, this implementation does not require that a change be made to the underlying object type. The attribute system can be expanded to support any type of object, including containers of objects, with minimal programming.

Furthermore, it provides a means of querying for all registered attributes and provides a policy based approach to object serialization.

This article discusses best-practices, performance and safety concerns. It presents a complete I/O policy implementation for serializing objects with TinyXML. It also provides examples for creating complex (non-POD) attributes.

During the development of Deer Hunter 2003, I was in the middle of implementing the debugging console window when a report came in from a tester that a newly implemented player setting was not being restored properly from the saved game format. This bug was preventing the testing team from moving forward with their test cases.

This was not a new problem; it had come up several times before. Essentially, any time a new variable was added to the base actor class or one of its derived classes, the programmer had to manually add support in the archiving routines to persist this data.

The problem was further complicated because it was not desirable to serialize all variables during a saved game, and the logic determining which variables should be serialized when was poorly understood.

Questions such as "Should the variable be saved during a saved game?", "Should it be serialized to the network stream?" and "Is the variable state managed by the server, or is it client authoritative?" had to be answered. They were typically understood at the time the variable was added, but when being reviewed by another programmer, the answers to these questions had to be re-discovered.

To add to this already annoying problem was dozens of lines of repetitive code in the serialization methods that serialized each variable independently. The code was not so much messy but highly repetitive and difficult to scan through quickly to determine if a variable was indeed being correctly archived.

This problem had come up often enough that I was finally frustrated with fixing it. I knew that no matter how many times I sent out a policy email about how and when to serialize player data, someone would inevitably forget, and I would be right back to re-visiting the serialize code again and researching the variable to determine when and if it should be serialized and who should be assigned the change order.

Another task I had been working on in the console window was very similar in nature: repetitive lines of code acting on specific, pre-determined variables. I wanted to replace all of the code that looked like this:

if ( input_str_arg1.compare_no_case("velocity") == 0 )
Selected_obj.setVelocity(atof(input_str_arg2);
else …

The new code would be elegant, automated, less error-prone and would not require significant changes to support the new variable. For example:

SetValue(input_str_arg1, input_str_arg2);

It was clear to me that this issue needed to be resolved. What I wanted was a system that solved the following list of requirements:

1. It must have minimal impact on the existing code.
2. It must be simple to expand without changing the code of the management system. In other words, it has to be generic, and it has to support complex types.
3. It must have a small memory footprint. (Thankfully, we were only developing for the PC, so there was some wiggle room.)
4. It must provide a simple, easily discernable means for the programmer who implemented the variable to state how the system and the user should interact with it, if at all. Ideally, this means could be adjusted dynamically.
5. It must provide a way to query an object for all of its attributes that are to be exposed or serialized and, if possible, how and when it should be serialized.
6. It must provide a way to automate the serialization.
7. It must support altering the values of these known variables.
8. And finally, it must not require that the value of the variable be changed through any particular mechanism, or be notified of any such change, while always being aware of the exact value of a known attribute at any time.