On Friday 15 December 2006 18:13, Tim Ansell wrote: > 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)
Without a cache, there isn't much to predict, and I have been trying to keep redundancy down. I agree with the above statements. > * No client action may effect another player (Stuff only effects other > players during turn generation.) Agreed. > * You should be able to create a wide variety of games such as Stars!, > VGA Planets or GC2 without changing the client. Or at least be similar. Things might happen in slightly different ways. > 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. ...Which should give you a clue that they no longer exist since they are not in the list. > 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). In tpserver-cpp you will only get the object ids that you can see, which should reduce it a little bit. But I can't think of a way to make it more efficient. > 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? Part of what I called "Game statistics" below would include when the game was started, which could be used for that key. > > > * 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". 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. > > > * 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.) 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? > > > * 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? Same sort of thing as OrderDesc. Lucky you brought this up as I might have started something for the backend of tpserver-cpp that wouldn't be compatible. > > > * 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. No prob. I know some xslt. > > > * 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). Maybe we need to divorce the framing (the header) and data encoding from the frame type and contents. I guess I vaguely agree with this, but I would like to see an example. > > > * 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. The problem with STARTTLS is that it *has* to be synchronised. If either stream (in either direction) is as little as one byte out, it doesn't work. Get Features could be used to announce that these filters are available, but some new frame would be needed to make the transition. > 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. No way! Different encodings is just asking for trouble. > > > * 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"). There are many ways to implement research. See Civilisation vs Stars!/Space Empires series. > What are "technologies" and how do they relate to research? Technologies are outcomes of research, such as new processes, order, components, designs, research areas, facilities, etc. > > > 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? Well, a way of setting diplomatic state (parent, alliance, peace, netural, war, etc), codifying the sort of things you suggest above, etc. The basics could be in tp04 with a better/more complex/complete system later. > > * Base media url and game statistics > > I think most objects need the ability to specify where to get media > from. The question is how to set that. Better would be a mapping between object types and properties to media, which could just be relative to the base media url. The base media url could be used by your current media system to specify where to start. > What is game statistics for? Things like * number of players * length (type) of turn * number of objects * game start time * server uptime * etc > > * OOG/OOC chat (Out Of Game/ Out Of Character) > > Do we need this, couldn't we just use IRC and email? You suggested it. Hence me adding it to the sf tracker. Some sort of public messaging system is needed (storing old messages for retrieval as well.) > > * 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. Yeah. > > * 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? This would be for asynchronous notification. When a working design is completed in one category makes a new component available in another category (as tpserver-cpp would implement it). Not related to when two people are connected as the same player (which tpserver-cpp doesn't support). > > * 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. No, just the object in question. And they are not really significant changes really. > Can you think of anything apart from the Name? Perhaps planet production priority? Or population split between industries? > > * Race/player separation? > > I don't think we need to worry about this one for the next version. Ok. > > And I'm sure there are many others. > > Like? Can't think of any offhand. Must be most of them. > > 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 Except for extensive changes to the object frame and a few others. Good to know this is just extention, not replacement. > > Later > > Lee > > Anything else? Not right now. > Mithro Later Lee
pgpcAeJyoxD07.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
