Hey Fro, I did really mean to get back to you in a timely manner, but time just keeps getting away from me. You ideas below are quite interesting and it is cool that you have been thinking/have thought about them.
On Thu, 2007-08-16 at 01:09 -0700, James Gardner wrote: > I pulled these thoughts together on a request from nash. mithro asked me > to post to the > development list as well, so here it is - a few thoughts on things that > could be done that would > make the creation of rulesets more general and perhaps more attractive > to newcomers. > ------------------------------------------------------------------------------------------ > > At the end of last week nash asked me to give some thought as to how > much of a ruleset the RDE > could be used to develop. At the moment there's not that much that it > can be used for, aside from > things like components, properties, designs, resources, or planetary > systems and the like. At the moment, it seems like the RDE could be used to develop anything related to designs. To me this is going to be the heart of customising already existing rulesets. Once we get technology tree (which is something that will possible be possible under tp04), it makes sense to add RDE support to that too. > And entire > ruleset cannot be constructed from within the RDE. That does not mean > that there cannot be, only > that at the present moment it is not possible. I have given some thought > to the issue, however, and > believe that it would be possible to design the majority of a ruleset in > a server-independent form if > a few things were to occur: > > 1) A basic set of Order types would be available for use by a ruleset > from a server. That is, a ruleset > could choose to make use of a stock set of common Orders such as move > orders, fleet construction > orders, colonization orders and the like. It would also be possible for > the ruleset to not use the > available orders, or to simply extend and override the base Order with > its own. I think this is definitely a good idea. The protocol already defines that all orders with an ID under XXX are predefined. This would be a natural extension of that idea. > 2) Any new major features (such as resources and trading as seen in > TimTrader) should be implemented > in a server-agnostic format. Instead of writing the plumbing in Python, > as is the case right now, the TPCL > language should be extended and exploited. In much the same fashion as > Components affect the value > of a Property so too could TPCL (or rather, TPSL [Thousand Parsec > Scripting Language]) code could > be written that allows Producers to generate Resources on a planet and > the Consumers to consume those > same resources. With a bit of forethought, then, it would be a fairly > simple process to put the majority of > the processing and functionality of the feature in a server-neutral > format which could be stored, edited and > tested in the RDE. The problem with TPCL is that writing anything complicated in it **sucks** (hence why we need a RDE :). TPCL is really nothing more then a glorified calculator and I have deliberately tried to *not* make it turning complete so it doesn't get out off hand. The TPCL editor in RDE is a good first step in a direction of making this less painful. However, I don't think that using it for anything else (except server to client "requirement" information) is the right approach. I have thought about maybe defining a set of python interfaces and letting the tpserver-cpp then embed Python. Keeping them compatible would be a huge pain however. > Now, certainly not all Orders can apply to all rulesets. And different > rulesets will have different variations on > the same Order. And it would not be the most efficient thing to do to go > about interpreting TPSL code for all > of the interesting things that happen on the server. However I believe > it should be a goal of the TP project to > make the building of new rulesets accessible and easy. I totally agree. Building custom rulesets is one of the biggest features of Thousand Parsec over other similar games (including other FOSS games). > Games like Neverwinter Nights have such a large and active fan and > hobbiest base because of the fact that it > is quick and easy to create objects or features and share them. More > importantly it is extremely easy to use > the work that other people have already done in your own efforts. The > more Orders that the servers can > provide for use by rulesets by default the quicker rulesets can get up > and running. If the ruleset needs > functionality that isn't already present then it can be put in manually, > hopefully to the benefit of all the other > rulesets as well. Yes, I definitely agree here. > The same applies to features. Making resources, for example, accessible > and easily sharable would make it > more likely for people to make an effort at starting a creation of their > own. True. tpserver-py currently loads resources and components from a CSV file for TIM Trader - this could be made fairly generic to work with any server. If you came up with a good XML way of describing these, I'm sure it would be adopted. > Anyway, those are my two cents (or rather, two ideas). I'm sure there's > plenty that I haven't considered, but > it seems to me that there a bit of an opportunity being missed in some ways. > > -Fro Have you had any more thoughts about this since you sent this email? Tim 'Mithro' Ansell _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
