Designing a C++ Property System

As I’ve been working on Devastro 2 I thought it would be great to be able to see and adjust properties of the in-game entities in the level editor.

Properties can be generic ones such as position, angle or color but there can also be ones specific only to certain types of objects – for example a “crate” object can have a (bool) property that defines if a pickup item should appear when the crate is broken. An enemy ship can have a property that defines how much damage it can take.

But how does the game know what types of objects have what properties? I guess we’ll need some kind of system for that.

A property system is a way to inspect and modify the properties of objects at runtime.

Implementing this is quite easy to do in languages such as Java or C# because reflection (aka introspection) is part of their runtimes. Also, custom annotations can be used to further describe how we want the properties to be published. But being the stubborn person I am, I’m writing this game in C++, so… how hard could it be? Maximum effort

Use cases:

  • Serialization – read/write properties to a file when saving and loading levels
  • Editing – interactively adjust properties using sliders, checkboxes etc in a GUI.
  • Debugging – inspect objects at runtime

We need to:

  • Get a list of properties for each class in the game
  • For each property, get its type, name and additional info for editing & serialization purposes
  • For a given object instance, get/set the value of each property

I defined several constraints for the system:

  • No custom preprocessing steps (looking at you, Qt)
  • No macros
  • Don’t use C++ RTTI
  • Non-invasive – objects don’t need to register or add getters/setters; this is hard to avoid completely but currently there’s only 1 line of boilerplate declaration to be added to each class
  • No runtime overhead for objects with properties (allow direct access to values when type is known)
  • Simple setup (all properties for all objects defined in single location, DRY for subclasses)

And some compromises:

  • OK to do string lookups but only when editing/loading, not in main game loop
  • Limited set of property types (int/float/bool/string/enum)
  • Limited amount of validation (can set a property to any value, object must deal with it; a value range can be defined as a hint for editor UI but is not enforced internally)

As of now the property system is up and running. Phew! I went through several iterations before settling on a design and it took a lot of effort to flesh it out for all the use cases and integrate it into the game.

Bottom line: Interesting challenge; looking forward to using Jai.