On Tue, 2007-01-02 at 17:31 +1300, Lee Begg wrote: > On Saturday 30 December 2006 20:10, Tim Ansell wrote: > > So I guess this divides into the following categories > > > > Locational Properties - > > These are properties which describe where an object is on a starmap > > (and where they are going). > > Yeah. Over time (turns) objects might have different locations and ways of > writing the location. Do we want to handle that? Or keep it consistent?
Sorry, I don't understand what you mean? IE Been "bound" to an object? > > Things like wormholes could have multiple > > positions. > > A wormhole is a connection between two ends. Figuring out where the other end > is is part of the fun. So don't need multiple positions. What do you mean? After you discover the other end you may want to know which one it goes to. > > Descriptional Properties - > > These are properties which are for the players information when > > making decisions. As far as the client is concerned they don't have any > > effect on the game. > > These would include things like "Name", "Description", etc. > > Many of these descriptional properties can be edited (like changing a name) > without affected the game at all. It might be nice to be able to edit them > without sending the whole object. Maybe a "Change property" frame? Would anything else also have this type of property (ie Designs)? <snip> > > Order Queues - > > Currently we only have one order queue. There is no real reason an > > object couldn't have multiple order queue's. > > This could be used for where you want a separate "Build Queue" to an > > "Action Queue". It could also be used on ships where you have an "Battle > > Queue" which specifies what the fleet should do in battle (IE Attack > > hard for X turns, run away). > > Your "battle queue" is not really a queue, but some sort of "standing orders". Another option would be a "Default Order Queue". IE If you wanted new fleets to have a "move to x", "remote mine" default order queue. I think the client should handling "Order Queue"s which only have one type of order specially. Maybe order queues could also have a possible "limit" on the number of orders can be put in them. > > > > Reference Property - Refers to something else (for example a player, a > > design, etc) > > List Property - Lists a bunch of other properties (IE Resources would > > be a list of reference properties?) > > Choice Property - Can make a choice of something. > > Graph Property - Some type of graph, with the location where the > > current value is and where it is heading. This could be used for > > production capability (which is likely to be non-linear). > > > > > > Does this break down look sensible? > > Yes. Those primitive types above should be enough. I think we are better being to descriptive then not enough at this stage. > > I still think we need a bunch of > > common arguments which all objects must have. > > Ok. Any suggestion as to what those could be? > > > We could describe a planet in the following way, > > Temperature - Hab, Range (0K - 10,000K) > > Radiation - Hab, Range (0Rad - 1000Rad) > > Gravity - Hab, Range (0g - 1000g) > > I think you will find that all three of those should be exponential scales, > not linear. > > > Production - Goodness, Graph (X - Value, Y - Production, > > Points[(x,x), (x, x), (x, x)]) > > I notice in the example below that this is written as "(89%, +10%)" which > bears no resemblance to the description above. Just what does this mean? 89% -- current value, +10% where the value is currently heading (IE to 99%). It would be to give an indication of where the values are heading. <snip> > Overall, these look quite good. > > The "property categories", while descriptive, don't actually add anything, I > feel. >From a server side they don't really add anything, on a client side it would change how they are displayed. A gauge type would be displayed as a gauge. An integer would display as a number. Some of the other things are important, IE its better for the client if it knows that the value should be between X and Y. IE See the order arguments stuff. > Time properties (ie, age, etc) don't appear. I might have missed them from > the brain dump. Could be interesting to have the age of a colony or fleet. As in "Turn first seen at", "First created at", etc? Mithro _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
