Fro's tpserver-cpp

My testing server can be accessed at jgard.dyndns.org, just point your TP client that way. There are no guarantees that it will be up and running, but when it is it will always allow new players to join.

-Fro

To the left we see the precompiled version of tpclient-pywx connected to the modified tpserver-cpp that I have running. The server is running using code that was generated by the RDE. The FroHull component was generated completely from within the RDE with no C++ code written by my own self to get it working aside from a simple call to an initComponents function. A slight modification to the DesignStore in tpserver-cpp allows Components to be referenced by name and makes code generation for these basic elements quite easy.

In the process of getting the generated code to work within the current Minisec ruleset I discovered that to adequately assist the development of rulesets the RDE will need to edit and track a number of other "objects" from within the game, the bare minimum being the design Category attribute.

Another thing that came up was the fact that there is no checking of the TPCL code being done, so when I first generated the code I had a tpcl cost function with a # where a number should have been, which resulted in a (to me) cryptic error during loading the game. I eventually want to validate components and properties, at least on a basic level, in the RDE before code can be generated.

I will probably have to work out a specific coding style to be followed for those wishing to use the RDE to generate their code, but I expected that from the beginning. Right now I'm just happy that the code that I generate works and can be used to generate properties and components by adding only four lines of code. The structure of the generated code will likely change with time, perhaps to make a single function call that will initialize all RDE generated objects so that it becomes trivial to use.

-Fro

GSoC Status Report 618-6/24

Two more features need to be implemented to make the RDE usable as an environment to store and edit game Properties and Components (editing TPCL Cost functions and renaming objects). That should be completed early this week and then a few more tweaks to the GUI (loading from XRC) will be the last that I want to do before I dive into code generation for tpserver-cpp.

Things that I accomplished this past week are:

1. Added a menubar and statusbar
2. Ability to add and delete objects
3. Ability to create projects
4. Ability to open projects
5. Added Scheme syntax highlighting for TPCL code
6. Fixed the sentinel properties (which I'll probably get rid of anyway since explicit is better than implicit)
7. Messed around with XRC to get some good layouts for editing objects
8. Ability to associate Properties with Components

Things that I want to accomplish this coming week are:

1. Conversion to XRC for most of the GUI (need to talk to mithro about that, feh, timezones)
   
2. Ability to rename objects
3. Ability to edit TPCL Cost functions
4. Maybe context menus for some useful functionality
5. Basic framework for code generation

As a peek at what I want to do with the GUI to make it more intuitive, below is the component editing panel as it currently sits in wxGlade. The big change is that associated Properties are listed in a listbox and their TPCL Cost functions are displayed and editable to the right - less clicking and easier to inspect this way.


-Fro

The RDE is coming along well. Syntax highlighting came easily thanks to the StyledTextCtrl which is powered by the Scintila plugin. Code folding and highlighting are all included. It'll mostly be just a matter of getting a proper keyword list for the subset of Scheme that TPCL uses. The code for implementing the syntax highlighting and code folding was all readily available in the wxPython demo application and was easily adapted to the needs of the RDE.

The RDE now has the ability to create and open projects, but not yet the ability to delete projects. Almost all of the features are in place for a ruleset designing to input the components and properties of a ruleset into the app. Once the internals of the app are worked out I can get to work getting code generation to work, starting with the C++ server (since mithro has so kindly offered to do code generation for the python server, woot)

I also poked around with XRC...and I have to say, mithro was right that it's pretty awesome. In about five minutes I was able to duplicate the current layout of the ComponentPanel with far less frustration than coding by hand.











-Fro

Been a while since the last update, eh? Well, along with this post comes a screenshot of the current state of the RDE. No menu bar or status bar yet, but there is some nice highlighting going one which shows a Component selected for editing and each of the Properties that it affects highlighted in red.

As for the current state of the project, read below:


What has been achieved so far:

1. Storage for multiple gametypes which is completely decoupled from the program itself
2. Dynamic loading of game object information to ensure that the only bloat is Python's inherent size
3. Game object data model and interface for listeners for changes to that data (which may not seem like a lot but was quite interesting to get working as I learned a good bit about properties in Python and initializing methods on the fly)

What is yet to be achieved:

1. Implement the interface that allows the program access to and the ability to modify game objects (adding new ones, modifying existing ones, etc, and ensuring that changes are propagated to all important places). Examples of features that will use this are highlighting made to objects that have been changed since the last update and highlighting properties affected by a given component.
2. Use a more robust and reliable method for reading in and writing out XML
3. Ensure that all global variables are properly set and include a setup script to ensure that directories are properly recognized by the RDE (as it is now it's dependent on the working directory which must by .../tpruledev/src/ which is just sloppy)
4. Code generation
5. Possible use of XRC and AUI for GUI as per Mithro's recommendations (poking around the development branch on tpclient-pywx for that)

Anyway, more later.

-Fro