It's free to join Gamasutra!|Have a question? Want to know who runs this site? Here you go.|Targeting the game development market with your product or service? Get info on advertising here.||For altering your contact information or changing email subscription preferences.
Registered members can log in here.Back to the home page.

Search articles, jobs, buyers guide, and more.

Gamasutra
June 4 2008

A Templated C++ Attribute Library for Object Persistence and Export

arrowrightPage 1
arrowrightPage 2
arrowrightPage 3
arrowrightPage 4
arrowrightPage 5


Printer Friendly Version



Sign up for the Gamasutra Daily Newsletter!

Telltale Games : Technical Artist [11.22.08]
Namco Networks America Inc. : Flash Games Engineer [11.21.08]
War Drum Studios, LLC : Network Game Programmer [11.21.08]
First Act Interactive : Project Lead Software Engineer [11.21.08]
Sony Computer Entertainment America : Senior Manager of Game System Engineering [11.21.08]
Cryptic Studios, Inc. : Lead Game Master Support Representative [11.21.08]
Sparkplay Media : QA Manager [11.21.08]
Cryptic Studios, Inc. : User Interface Designer [11.21.08]
Treyarch / Activision : Technical Director [11.21.08]
Ignition Entertainment : Motion Director [11.21.08]
Ignition Entertainment : Producer [11.21.08]
Sony Pictures Entertainment : Software Engineer / Lua Scripter [11.20.08]
Sony Computer Entertainment America : SR. TECHNICAL PROJECT MANAGER [11.20.08]
Edge of Reality : Project Manager [11.20.08]
Stealth Startup : 3d Graphics Programmer - Virtual Worlds [11.20.08]

View All    Post A Job

Post Resume


Upcoming Events:
DIG London Game Conference
London, Canada
11.27.08

5th Australasian Conference on Interactive Entertainment
Brisbane, Australia
12.03.08

IEEE Symposium on Computational Intelligence and Games
Perth, Australia
12.15.08

2K Bot Prize
Perth, Australia
12.15.08

The 6th Annual Mobile Games Forum 2009
London, United Kingdom
01.21.09

Submit Event

View All


A Templated C++ Attribute Library for Object Persistence and Export

(Page 1/5)
Next arrow


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.

(Page 1/5)
Next arrow


Comments


Andrew Ames 13 Jun 2008 at 10:26 pm PST
The biggest memory savings can be found by separating the attribute container into a class meta data object that is instantiated and filled only once for the class, instead of for each object instance.

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);







join | contact us | advertise | write | my profile
news | features | contract work | jobs | resumes | education | product guide | store