On Thursday 04 January 2007 02:51, Tim Ansell wrote: > 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?
Yeah. The three I can think of are: - 3d free space - 2d planet surface - (0,1 or 2d) "inside" (such as in carrier, spacesation, drydock, etc) > > > 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. The two objects that appear in the universe are the two ends. They can be linked together either through an invisible (and has no position) wormhole object, or each end could specify which is the other end (if known) > > > 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)? I wouldn't like it on designs. Although maybe the comment field (per-user! nnnoooo!!!!) could be I guess. The other thing is what other players know designs and player created objects as. > <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. That is a tricky one. I guess it would be possible to add that to the player's data (although I have no idea how tpserver-cpp could handle that). The most useful use of that is for new planets. > I think the client should handling "Order Queue"s which only have one > type of order specially. What do you mean by "type of order"? Each object specifies what orders can be placed on it. Therefore only the type(s) of orders are allowed. > Maybe order queues could also have a possible "limit" on the number of > orders can be put in them. Not hard to do either. Although most of the time, the limit will be one of these things: - the human player's patience entering the orders - the resources at the object (fuel, supplies (endurance), or other normal resources) - boredom > > > 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. Ok. I just don't want too much complexity or redundancy. "Keep It Simple". > > > 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. Ahh, I somewhat see what your saying. Could you map the two examples to each other please? What does "(89%, +10%)" look like in "Graph (X - Value, Y - Production, Points[(x,x), (x, x), (x, x)])" form? > <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. True. Fair enough. > 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. That wasn't the bit I was worried about. It was the "Descriptional Properties", "Habitation Properties", "Resource Properties", "Goodness Properties", etc. > 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? Yeah, but more specifically "info is X turns old" (but presented in absolute turn, so curr_turn - turn = X). > Mithro Later Lee
pgpCtxY9bh3hQ.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
