Hi I want to make a native Windows client for TP, as a SoC entry. The main focus of this client would be to provide client-side rulset extensions.
It is quite obvious, that some activities cannot be carried out on the server. Building designs (which can be specified on the client with TPCL, as I've read) is a good example of a client-side, ruleset dependent activity: - it has to be responsive, - there's no reason why it should be done on the server, slowing it and the network down. As I've read about TPCL that it's a Scheme-based language. Funny thing is that on your web site it's described sometimes as easy to learn, and sometimes as hard to learn. From my own experience I know that Scheme is not a user-friendly language. Also it has non-intuitive and unfamiliar syntax and features. It's a bad choice for client-side scripts. My proposal is to identify elements that exist in the interface (StarMap, Orders, Messages, menus, etc.) and provide means to specify "overlays" for those, that would modify them in a context dependent manner. It would be similar to overlays in the NetBeans Platform or Firefox extensions. Those overlays would be specified declaratively for both simplicity and ease of use. An example would be an overlay for the context menu on the StarMap used when a fleet is selected. It would add elements that would generate orders: <overlay target="StarMap/Star/ContextMenu"> <menuitem title="Move" action="addMoveOrder()"/> <menuitem title="Colonize" action="addColonizeOrder()"/> </overlay> <overlay target="StarMap/Fleet/ContextMenu"> <menuitem title="Follow" action="addFollowOrder()"/> <menuitem title="Attack" action="addAttackOrder()"/> </overlay> Similar overlays would be useful in other parts of the UI. The overlay mechanism would be somewhat useful on it's own, but what's really needed to enrich the user experience and allow for interfaces customised for particular rulesets is a standard scripting language. As I understand TPCL was designed to help with that, but it's really a bad choice: - like said before: non-intuitive and unfamiliar, - non-standard across different platforms. What is needed is a scripting language that could be easily incorporated into clients written for all platforms, without the need for implementing it yourself, and one that has a large community (support, examples, tutorials etc.). Since TP is already connected with Python, Python would be a natural choice. My proposal is to implement a client with the overlay mechanism and scripting mechanism. It would include designing interfaces through which the UI and game objects would be manipulated. The client would be written for the .NET platform using the C# language. The Python implementation I would embed would be IronPython (written for .NET, fully compatible with the Python language). The UI would be written using Windows Presentation Foundation. The choice of .NET as a target platform is dictated by the following reasons: - implementing the client is already a large task, so trying to make it also multi-platform would not be a reasonable proposal, - .NET is a modern technology, backed by professional tools that ease the development process, - having a native Windows client for TP would be a plus. The C# language is chosen as: - it is THE language of the .NET platform, - it's easy and powerful, - it is fully interoperable with C++, so reimplementing the protocol libraries would not be necessary. My proposal would significantly enrich the clients. However other clients would have to follow this active-client specification. That's why before I post it on the SoC webapp, I want to ask weather the direction in which this proposal is going is in line with your plans for the future of TP. Zbigniew Skowron _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
