How do you go about a Property System for an Editor?

Started by
21 comments, last by dave 8 years, 1 month ago

As the title states, what is the concept of creating a Property System that allows a class to be automatically read in by an editor with only a few additions to the class?

I've done something similar to the Cry Engine, which reads in tables from Lua both offline and online. But I would like to extend this ability to the C++ classes as well, as some objects of the game engine needs to exist outside of the code for efficiency's sake.

An example would be the Unreal Engine which uses a set of defines/


UCLASS()
Class SomeClass
{
GENERATED_BODY()

public:

UPROPERTY()
int Something

} 

I tried looking into their code, but a good chunk of the define stuff is an utter mess to read.

Advertisement

The overall concept is to create a way to describe the memory of a class and what each piece of memory represents. IIRC Unreal has some dedicated source that parses C++ to the extent necessary to gather this needed information. This information can be gathered at pre-process time and queried at run-time to allow for user-input to be channeled through the UI into class member modifications.

Alternatively the memory/type information can be gathered at run-time, and this is usually done with the help of templates to generate loads of C++ under the hood. In the end all that's needed is the ability to modify data members of a class, so any system that provides enough information to achieve this will work. Often times this "type information" is used to assign a pair of functions to a data member, one for writing and one for reading. For example, if a specific class member is type "integer" we can lookup integer read and integer write functions. Once the user interacts with the UI the UI can call the appropriate read/write functions to modify the class in-memory.

My initial thought was to use a visitor pattern. But I could never get it to work correctly.

The concept was simply to wrap the code like so.

int Item

PROPERTY(Item)

which would create a getter and setter for it.

The class in question would be derived from a class with a table described on it that the Editor could read from, and use void pointers to access data.

But the problem came to be that I couldn't find a way to have the class actively register it's properties to this table correctly.

This kind of thing would be even easier when C++'s new metatype system gets standardized.



Alternatively the memory/type information can be gathered at run-time, and this is usually done with the help of templates to generate loads of C++ under the hood. In the end all that's needed is the ability to modify data members of a class, so any system that provides enough information to achieve this will work. Often times this "type information" is used to assign a pair of functions to a data member, one for writing and one for reading. For example, if a specific class member is type "integer" we can lookup integer read and integer write functions. Once the user interacts with the UI the UI can call the appropriate read/write functions to modify the class in-memory.

Could you perhaps direct me to something that would help me in this case?

Sure thing, this is the best resource I know about:

Excellent! One up man, if I could throw you a seven, I would.

This is basically the same problem as creating bindings for a scripting language for your C++ code.

In newer languages like C#, reflection is a built-in language feature, so you can just use that a lot of the time... but in C++, it's up to you to invent your own reflection system :|

These systems are almost always based on horrible-to-read template metaprogramming :lol:

As another example, mine is here. It's similar to the unreal macros, but you write a big block of macros after the class definition, instead of inside of it.

At a company that I used to work for, they went down a different route. Instead of using TMP, they annotated their structures with special comments. They then parsed the code files, analysed the structures and these comments, and then generated new code files that contained all the "binding" type logic (including serialization functions, etc)...

My approach would be to drop the c++ classes as source, and have a data description in a file that you can manipulate instead.

I'd write a code generator that takes the data description and generate class code from it.

This is what EMF does in Eclipse, you have an EMF description of your data (with an UML-like class-diagram editor), and you generate (in my case) Java code from it. EMF however is not specifically tied to Java, so there may exist C++ code generators for it too. In addition you get reflection capabilities.

I actually implemented a system heavily inspired by Unreal Engine 4 to implement c++ reflection. some of the info is available on my site http://www.ademolathompson.com/archetypesystem/ and http://www.ademolathompson.com/archetypesystem-20/ . I created a pseudo c++ parser that is run prior to the build pass of the compilation stage. This c++ parser gets all of the meta data, and generates c++ code to be used by the runtime. If you have any questions, I could answer them.

This topic is closed to new replies.

Advertisement