As these emails are getting very long I'm going to split this into a few
separate lines of thought.
These two issues are ultimately linked. The most important factor we
need to considering these issues is the "Changing client's shouldn't
loose you any information" requirement.
On Fri, 2006-12-15 at 21:31 +1300, Lee Begg wrote:
> On Friday 15 December 2006 18:13, Tim Ansell wrote:
> > > > * History support. Currently you can only get the currently active
> > > > turn. What happens if you join the game late or miss a turn? Maybe we
> > > > should have some way to getting older information.
<snip>
> >
> > Say a Ship goes to Planet A then Planet B and then Planet C and "scans
> > for details" at each planet. The planets are however quite close
> > together, this means that it only takes 1 turn to get around. If you
> > "miss" turn 2 then you miss the details about Planet B.
> >
> > Plus if you no longer have a ship at Planet B it should still list what
> > it was like when you last got there.
> >
> > This is kind of like how in StarCraft where the Fog of War showed what
> > was there when you last was saw it.
> >
> > This is also seen in Stars! Where a planets details may have "128 years
> > ago".
>
> You don't need history support to handle this last case... but on the server
> side it is *nearly* the same implementation.
>
> Ghost objects (such as a stealth ships) which appear once and then disappear
> are reasonable in requiring history, but might be better implemented as a
> kind of "old sensor reading" object. Adding full history just adds to what
> the client could (and i imagine in libtpclient-py, would) download.
There is also another use case, what happens if the client wants to
display a graph of the population on a planet over the years? It would
need data from each year. These graphs could actually be quite important
in many places (IE to see how adding factories improves production).
I can't see a way to do these graphs without having all the previous
turns information available. You can't rely on the libtpclient-py cache
because this would violate the "Changing client's" rule.
Can you think of a better way of doing this?
> > > > * Partial object support. Sometimes you'll only have
> > > > permission/ability to only view parts of an object. For example you
> > > > might only be able to see certain stats of an object (IE tonnage of a
> > > > far away fleet). This would also concern the current problem we have
> > > > about
> > > > designs/components.
<snip>
> > I think there should be a differentiation between the following states
> > of fields:
> > 1. Current Data
> > 2. Unknown Data
> > 3. Old Data (and how old)
> >
> > The client needs to know about these different states to be able to
> > calculate and show correct information to the person.
> >
> > Any suggestions on the best way to do this? I thinking we need an age
> > for each field because you may have the following situation.
> >
> > Scanners can see the size and environment stats.
> > Ships in orbit can see "installations" and population.
> >
> > You have a ship which arrives at a planet.
> > Te ship gets destroyed.
> > Another ship has planet in scanner range.
> >
> > Size/Enviroment stats keep getting updated until the second ship
> > is destroyed while the population/installation stats don't.
> >
> > At the moment it appears to me that every player will have to have their
> > own personal "view" of the universe. How this view is calculated is up
> > to the server. (I can see quite a nice way to do it in tpserver-py.)
>
> Size/Environment isn't something likely to change often. But I get the point.
>
> But I can only see how much bigger this will make object frames, and the
> amount of data to be stored in the database (which isn't that critical I
> suppose). Any idea how we might do that?
I was thinking that maybe we could have an "field age" list of SInts.
This would tell you how old each field is (with -1 being Unknown data)
in number of turns.
For example,
* a UInt32, Design ID
* a UInt64, the last modified time of this design description
* a list of UInt32, categories this design is in
* a Formatted String, name of the design
* a Formatted String, description of the design
* a SInt32, number of times the design is in use
* a SInt32, owner of the design
* a list of,
* a UInt32, component id
* a UInt32, the number of components
* a Formatted String, human readable feedback on the design
* a list of,
* a UInt32, property id
* a Formatted String, property display string
Say we know the following information about an enemies Design and it was
last seen 5 turns ago with a good sensor reading 8 turns ago.
[ 100,
123456783,
[],
"Unknown Ship 1",
"This type ship was first seen at a battle over Planet X. It was last
seen at position (x, y, z)",
0,
0,
[(100 - "Big Hull", 1), (6 - "Weapons of Mass Destruction", 3), (9 -
"Unknown electrical components", 8)],
"",
[(99 - 'mass', "100kt")] ]
[0, 0, -1, -0, 0, -1, 0, [(8, 8), (8, 8), (8, 8)], -1, [(5, 5)]]
It would add 4 bytes (SInt32) for every value on an object.
I think this information is very important in the long run however. It
would also get rid of the need for history data if we didn't need
graphing.
Any thoughts on this proposal?
Mithro
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
