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.