When thinking about tp I've been trying to keep the following things in
mind:
* You should be able to use any client
* Changing client's shouldn't loose you any information
* Client's should be able to predict as much as possible (to reduce
server load)
* No client action may effect another player (Stuff only effects other
players during turn generation.)
* You should be able to create a wide variety of games such as Stars!,
VGA Planets or GC2 without changing the client.
On Thu, 2006-12-14 at 01:08 +1300, Lee Begg wrote:
> Comments below.
>
> On Tuesday 12 December 2006 03:00, Tim Ansell wrote:
> > Hello,
> >
> > With the release of tpclient-pywx 0.2.0 and all the progress over the
> > last couple of months I think it's time to start thinking about the next
> > version of the protocol.
> >
> > So what do people think needs to be added/changed to the next version?
> > Here are some of my thoughts:
> >
> > * Better difference support. Currently there are problems with the fact
> > that you could be running a different server when a person reconnects.
> > What about objects disappearing? That too doesn't work to well.
>
> Currently, it shouldn't be a problem. I future, I plan that when a fleet is
> lost in battle, the object id will remain, but the object would be a debris
> field. That doesn't quite work for everything and objects must eventually
> disappear from the universe.
>
> What is wrong with the object (or generic) id lists with their modtimes? I
> know that tpserver-cpp doesn't support it on somethings, but they are the
> sort of thing that doesn't change anyway.
The id lists with modtimes almost work. The problem is that the list
doesn't include objects which no longer exist.
It is also highly inefficient to download every single ID and it's
modtime, you could have 15,000 objects in a game of which only a few
changes occur (it would take up 1mb of downloads just for the ID
+modtimes).
There is also no way to tell if this server is the same one you
connected to before. For example, if the server gets restarted and was
using the memory database objects will just "disappear" and it confuses
the caching mechanism.
I then each game should get a randomly generate key which I can check.
Maybe add to the Features frame?
> > * 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.
>
> If you join a game late, then you shouldn't see what has happened (except in
> race/government splits, etc). If you miss a turn, then what good is last
> turn's information? Moving object positions? Just look at the objects
> velocity and substract it from the current position.
>
> What is the "use case"? What is the value?
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".
> > * 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.
>
> This is not (necessarily) a protocol issue. Tpserver-cpp supports this in a
> limited sense, with the order queues for objects, only the owner of the
> object can see how many objects in the queue.
>
> The issue ends up being just how many infomation is needed to be stored on
> the
> server side. Does tpserver-cpp have to store a copy of each object for each
> player sees (ie: o * p objects)? With the dynamic object descriptions below
> I might vaguely see some reason to protocol level partial objects, maybe.
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.)
> > * Support for dynamic object descriptions. This is kind of like how we
> > do orders. It would mean we would no longer have to maintain the
> > separate "Objects" document.
> > This would also come hand in hand with displaying stats about planets
> > and economy.
>
> I agree with this, as it also solves other problems for me (namely
> persistence).
I am currently thinking along the same lines as the OrderDesc protocol.
How are you thinking it would be done?
> > * Full protocol XML specification. libtpproto2-py, libtpproto-php and
> > libtpproto-rb all depend on using the XML document specification. It
> > would be good if the documentation was generated directly from this XML
> > specification.
> > It would also mean that the documentation is easier to maintain (IE
> > keeping the tables and such up to date sucks.)
>
> I understand the value as a nice way to document the protocol, and some of
> its
> value for automatically creating implementation in dynamic languages.
Cool, I'm going to try and get the one for the current protocol working.
I definitely need some help with the document generation however.
> > * Individual FrameType versioning. I would like to support versioning
> > the frame types rather then the whole protocol. This would allow
> > libraries which only partially support for the latest protocol and
> > better transition between the protocols.
>
> WTF!?!?!??
>
> It would make things worst than now. Tpserver-cpp still supports TP02. It
> takes considerable work to support multiple versions of the protocol, let
> alone versions for each frame type.
>
> What is the "use case"? What is its value?
The idea is that it would mainly be used for TP02->TP03 and other
protocol transitions. During normal times it would have little to no
effect.
Currently, the problem is that you need to support the whole of TP03
protocol, partial support is hard to do. There is also no support for
TP03.1 or other incremental/bug fix versions.
For this to work the header of the protocol will need to stay the same.
Instead of the first 4 bytes being "TP03" or "TP03" it would be a
version number for that particular frame type.
Say for example we figure out that the Features frame needs another
field. We can just increase the version number and add the new field.
Older clients just ignore the added fields but the new clients know what
to do with it.
The idea is to make it much easier, not harder.
A side point is, you should most probably drop TP02 support. No client
still supports this protocol (that I know of).
> > * Protocol "filter" negotiation. Kind of like what Worldforge's Atlas
> > uses. IE Using bz2, zlib, 7z for compression, Different encryption and
> > tunneling methods. Maybe even UDP or other base level transports.
>
> Note that Atlas is used to decide between data encodings (from when I last
> used it, xml or bach; both text based).
>
> I vaguely agree with this. It could mean that a server only has to open 3
> sockets to fully support clients instead of the current 4 (tp, tps, http,
> https). The most specific filter I would like to see is tls. Many protocols
> (I note smtp and http) use STARTTLS as a command to start tls encryption (and
> jabber has a very round about way of doing the same thing which is similar to
> what we would need.)
The Get Features is also a good start of what we might need. Compression
support would be the most obvious addition.
BTW It would be technically quite trivial for my libraries to also
support different encoding (IE Bach, XML) but I don't think that is
somewhere we want to go.
> > * Support for "technologies" and "research", pretty self explanatory.
>
> Yeah.
Any thoughts how this should work?
I would like to support both "general research" (IE Researching
"electronics") and "specific researching" (IE Researching to get "Super
Powerful Component Marc 2").
What are "technologies" and how do they relate to research?
>
> > Can you people think of anything else that you would like?
> >
> > Tim
>
> In the sf bug tracker I have been adding feature requests (and tagged as
> such)
> for our protocol (note these might not need to be in tp04, maybe tp05). So:
>
> * Diplomacy
What needs to be added for this? Setting of a "no attack" or "can
refuel" type things?
> * Base media url and game statistics
I think most objects need the ability to specify where to get media
from.
What is game statistics for?
> * OOG/OOC chat (Out Of Game/ Out Of Character)
Do we need this, couldn't we just use IRC and email?
> * Player finished doing turn notification (to server)
This is definitely needed. It should be pretty trivial to support.
The server will need to advertise what type of turn progression it
supports. IE Majority Vote, All Finished, Time based.
> * New available design/component notification
How is this not covered by Messages? Are you looking at the time when
two people are connected under the same player?
> * Object Property (bad name, sorry) setting (ie setting object name, other
> things that take effect immediately)
Actually, I've been thinking about this. All these actions will really
be things which don't effect the universe in anyway really.
Can you think of anything apart from the Name?
> * Race/player separation?
I don't think we need to worry about this one for the next version.
> And I'm sure there are many others.
Like?
> In general, I would rather keep going along the lines of TP03 (ie, just
> extend
> it) than a full rewrite. We have a lot invested in what already works and I
> don't really think we want a repeat of the tp01/tp02 transition delay.
>
> Do you/we want to completely re-work the protocol or extend our current
> protocol?
I'm definitely in the extend mode. I don't want to rewrite everything :P
> Later
> Lee
Anything else?
Mithro
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
