Goals and Features

Project Goals:

Ruleset Development Environment:
The first objective of the RDE is to provide a ruleset designer with an environment which will organize and keep track of all game objects while he is developing a ruleset. The ability to visualize the interactions between Properties and Components and Designs, for example, becomes quite necessary when the number of each object increases dramatically. No ruleset yet implemented using TP has required an incomprehensible amount of properties or components, but Reach for the Stars, for example, will require a large number of each and being able to step back from the code will prove beneficial here.

In short, the RDE will be for the purpose of organization above all else. It will relieve the designer from the burden of maintaining the entire ruleset in his head.

TPCL Editor:
Writing TPCL code is both tedious and error-prone. If a standard set of expressions and function skeletons can be provided to a ruleset designer, and the ability to next expressions with the ease of pre-defined expression types and a point and click interface then it will be much easier to create complex behavior.

In short, the TPCL Editor will aim to make it easy to create working TPCL functions.

Currently Planned Features:

Ruleset Development Environment:
(1) Ability to store, sort and organize game objects and save a ruleset in development to disk in some orderly, non-server specific fashion.
(2) Ability to easily add new game objects to the editor (so that as new things are added, such as Races, the editor can be extended to track and edit those things as well)
(3) Ability to visually illustrate the connections between game objects (hiding all of the Properties except those associated with the selected Component, or things like that)
(4) Ability to output usable, functional code that can be included in a Thousand Parsec server

TPCL Editor:
(1) "Point-and-Click" editing of TPCL functions utilizing a catalog of known and accepted TPCL expressions.
(2) Ability for ruleset designer to add his/her own TPCL expressions and have them saved for later use.
(3) Ability to save entire TPCL functions for later reuse (as a template, for example, allowing the designer to easily give a game object a certain class of behavior). This makes it easy to make Components that have a requirements function that always returns true, or has a check on a single Property, or checks two properties, or anything else, thus saving time and improving consistency.

Current Plans To Achieve Goals/Features:

Ruleset Development Environment:
I feel fairly confident about how I will accomplish these goals. Most of it is straightforward, the most difficult thing will be developing an interface for game object modules to implement that is consistent, simple, powerful and efficient. To truly see what is necessary I will need to get a framework up and running and begin developing a ruleset, I believe.
(1) Every game object specification will also outline how to persist a collection of such objects in a given directory. (For example: ./Rulesets/RulesetName/objects/, the subsequent directory hiearchy will be determined by the object class itself) and how to load them. The saving of objects will likely be done in XML.
(2) Game objects will be included in the editor by writing a Python module that satisfies a specified interface. These modules will be loaded at runtime so that an ruleset designers can write modules for the own specific game objects and include them easily in the editor.
(3) The editor window will use a tree to display the different game object types and instances of those game objects that have been created in the editor. The implmentations of the game objects will allow for the user to filter what is displayed in the tree (boolean function applied to game objects, for example).
(4) Each game object module will have a function that writes out a collection of objects of that type as code in a specific language and designed for a specific server - this requires more research of the current server implementations before anything is set in stone.

TPCL Editor:
Much less thought has been given here so far. I have a vague concept of how I would like to accomplish the task, but am sure that things will change radically as my understanding of the problem changes.
(1) This will be accomplished by only allowing predefined TPCL expressions to be inserted into function blocks. There can be an option to write code directly by hand, but this would necessarily sacrifice the point-and-click editing of TPCL code. This method will ensure well-formed and functioning TPCL code. Expressions will be stored as XML.
(2) There will be an interface for adding new TPCL expressions in much the same way that one edits TPCL functions. Since TPCL expressions will be stored as XML it will be a simple matter to store these new, user-designed, expressions in the same way.
(3) This will be accomplished in much the same way as (2) above.

wxPython is interesting. I'm inclined both to like it and dislike it. The dislike probably comes from my familiarity with Swing and Sun's strict adherence to an MVC architecture. Having no separation between the tree control and its data is...interesting, for example. As is the fact that windows reference their parents as opposed to their children, at least from what I've seen so far...which is quite different from Swing. However...I'll say this - getting an item in the tree to spawn its own panel and insert it into a pre-existing pane was easy. A bit easier, I would say, than doing the same thing in Swing.

I also have to admit to feeling a bit lost without static typing. And without having to declare fields/attributes. But that's just unfamiliarity, though. I'll be browsing code over the next few weeks to acclimate myself to the style found in Python so I'm not trying to shoehorn Java idioms in.

Things are looking up, though. I've chosen to forego a GUI builder here, so that the code is easier to maintain (hah! I hope) and extend later. I'd rather get my hands dirty than let something like Boa Constructor do all the work for me. I should be able to duplicate the functionality of the Java prototype by the end of the week if not sooner.

All in all good stuff. Heh. I should probably check in with nash and make sure that I should be as concerned with the display and organization of properties and components and other game objects, or if I should be focusing more energy on the TPCL Editor (hooo, boy is that going to be fun)

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.