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.

First Post

Oy vey! I got accepted to work on the Thousand Parsec project for Google Summer of Code? Who saw that one coming? I didn't. Many good applications got sent in and the IRC channel was abuzz with activity in the weeks after GSoC started to when the results were announced. And when the news got out that TP would only have three (originally two) slots, I knew I was sunk. But here I am. Accepted. Happy. Yay.

Alright. Never had a blog before. Enjoying the rambling stream of consciousness that I'm allowed here. To the nitty gritty. My immediate plan of action is as follows:

1. Establish blog (check)
2. Confer with my mentor and get a feel for what's going on there (nash - later tonight)
3. Handle whatever setup needs to be done to get darcs repository access...public key stuff...uhm...fun version control stuff! I've only ever used Subversion before, so darcs will be fun, I'm sure.
   

And for the more distant future:

1. Start researching what options are available to checking validity of TPCL code. I'll bundle a lisp interpreter with the program and run all code snippits through that, I think, to verify their validity, in addition to straight syntax checking for freely edited code.
2. See what other projects/programs do code generation on the fly (insertion of statements and expressions and the like) and see how they do it. I've got ideas, but, heh, I'm very much the novice and inexperienced. Probably time to buy a book on programming languages and their development.
3. Refrain from developing the Java prototype any further. Yes. I code fast in Java. No, this isn't a Java project. Stop it. wxPython doesn't appear to use MVC so much, so it's best to get used to their way of doing things. Maybe I'll be pleasantly surprised, but I'd rather write the app once and not need to port it later, or try to transform ideas from one platform to another...ugh.
   

That's all for now...more ramblings later.