| ||||||||||||||||||||||||||||
|
(Page 1/5) Next 
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.
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 ) 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:
(Page 1/5) Next
|
||||||||||||||||||||||
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.
|
|
Comments
After rereading the article, I see you mentioned this refactor potential:
"One alternative is to have a global instance of AttributeContainer (or at least one that is in a larger scope than the objects it manages). While this saves some memory, it does complicate use, as each bound attribute must be somehow uniquely identified per object."
There are certainly some not-too-difficult solutions that simplify the global shared container pattern for client code.
In a system I worked with, the following client code would serialize an object's properties to a stream:
Object *pObject = ...;
MutableString mutstr;
StringOutputStream sos(mutstr);
XmlSerializer ser(os);
ser.Serialize(pObject);
Login to Comment