Re: possible new feature... scripting?

[Tony Christney <tchristney@xxxxxxxxx>]

On 20-Dec-07, at 6:16 PM, scspieker wrote:
> Some of the fixes I had been working on are UI changes for the  
> client side
> piece.  But there is a few other things that I had been toying with to
> allow integration with a framework frontend (such as struts2) so  
> that a
> fully featured server could be setup and administered by anyone  
> wishing to
> do so.
> There are a couple of areas where the some features can be added to  
> the
> product.  Using SOA webservices to transfer turns while clients are
> running (in the case of a group of users trying to play real-time),  
> a more
> 'glitzy' web interface for players and admins, etc.

I was under the impression that Jon T. was not in favour of a full
blown web interface. Maybe I am misunderstanding his concerns?
I'm all for a nice struts2 based interface. I'm not sure if I would
want to see the web and the standalone client share features or
make them orthogonal. Ideas like that definitely need some fleshing
out before starting implementation.

Also, keep in mind that the market for FTJava is very limited. I
think that one of the huge places for improvement would be getting
the FT rules as implemented by FTJava as a set of user documentation.
This would help open up the game to players who have never played
Full Thrust. Maybe a wiki would help - but who would host it?

On the client GUI side, I think that some flashier sprites would be
a huge improvement. We talked about using a transparent image and
composting a colour with the alpha channel so that any of the sprites
could be in any colour would be a big improvement. Unfortunately, that
kind of stalled - I think because of a lack of proper PNG handling
on Windows. I'm pretty sure this is no longer the case and could be
kick started again.

> I would agree that there is some liability to adding scripting support
> within the game itself, but there is a good potential for adding that
> variability to the games as well.

I think the fun factor outweighs the risk factor, provided we work on
making the script support robust to abuse. Keep in mind that we are
already open to abuse since we can send untested scenarios to the
main server...

> I would be happy to have a look at the import/export code - I work  
> with
> Java and XML all day long, so using DOM to create and read documents
> should be a synch.

I have some ideas in this area. Ideally I would like the exportable
objects in the game to inherit from the DOM Node. Each object's
variables should be attributes, although they need to be subclassed
to take into account FogOfWar. Another potential gotcha is that within
the Server the GameEngine is assembled from several XML files each
turn - the master file from the last turn step and all the order files.
So the GameEngine DOM needs to be spliced together from several sources.
Not a huge difficulty but if you aren't familiar with the Server it
could cause some confusion.

There are also serialization frameworks that use XML as a storage
format. Maybe we might be able to use one of those off the shelf.

So yes, it is possible and desirable to fix this, I wouldn't necessarily
assume it to be a cinch :) It is a pretty major refactoring task that
will probably cause all sorts of regression bugs.

Tony C.

ps. Maybe this would be a segue to move to ftjava-developers.