A few comments inline. On Thu, 16 Aug 2007, James Gardner wrote: <snip> > 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. 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.
One key part of Orders is their parameters. RDE could be used to define the order, and the parameters that make up the order. It would then be just a matter of writting the code that makes the order actually do something. > 2) Any new major features (such as resources and trading as seen in > TimTrader) should be implemented > in a server-agnostic format. Trading at a basic level (load/unload resource) is just another order. Diplomacy and the things that come from it is a different issue which we are not sure of yet anyway. > 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 next logical step for the use of TPCL would be to describe the relationships between different researchable technologies in the tech tree (or whatever system is used by the ruleset, could be tech tree/graph, could be research area, etc, etc) I am a little hesitant to greatly increase the use of scheme (or any interpreted language) in tpserver-cpp. I have two general concerns. 1) Scheme doesn't embed well the way I need it to in tpserver-cpp. 2) EOT especially, but the whole server in general, will need to be fast and have fairly good performance. I'm not against using scripting languages, but they need to fit. TPCL works well for designs/components, because it is able to capture the complexity needed, and is only evaluated once (when added or updated). > 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. This should be mostly taken care of by parameters and some good documentation. > 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. I'm hoping that tpserver-cpp will be able to load extra "modules" that will include new object and order types, etc. > 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. > > 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 The RDE should make it a lot easier for people to get into creating a ruleset. Hopefully, it should also be possible to modified an existing ruleset to add something new. Actually, just thought of another possible task for the RDE; managing the media for various objects, etc in the ruleset and their mappings. Some food for thought. Later Lee
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
