So, I just did a bit of brainstorming today. Thinking about an easily extensible framework to edit game objects in. My current leaning is to make things fairly open. The RDE will maintain a list of object types and actual objects. To represent an object/propertything from the game all we do is subclass the GameObject class. This ensures that the representation of the object will be able to do a few key things like save to and load from a file as well as generate code for a list of its own objects. Also important is the fact that every GameObject must provide an editor panel that can be fitted into the RDE editor window (meh...wxPython had better support this [edit: yes, it does...somewhere...]...I guess I'll be testing that tonight or tomorrow, then).

There will also be a TPCL Editor of some sort...that will come later. My current thoughts on that involve representing the code in a series of TPCL Nodes that contain code information and references to embedded expressions.


Current unresolved issues are as follows:

1. I would like to, for example, register Components as listeners on their associated Properties so that they can update and check themselves if a property changes (say, a Property changes it's name...we don't want the Ruleset designer to have to reassociate every Component that used that Property with the Property all over again, do we?) The problem is that we need to ensure a specific order of initialization for the components if that's what we're going to do and then we can't have interdependency (A listens to B and B listens to A)...or we need to first load all of our objects and then deal with the connections?
2. With a generic "generateCode()" method in the GameObject class how can we elegantly ensure that every GameObject addon module properly supports what we want to provide output for tpserv-cpp and tpserv-py for example. Maybe a "supported_output_types" field in the GameObject that is checked on runtime?

Hm. More thought in the following days to iron this out better.