Kamaze wrote:
The client sends the deflated XML with all necessary data (extensible) to the master server.
(I tested compressing this small XML's. It only saves ~1 or 2 bytes due it own tininess.
yeah. saving a few bytes isn't worth the processor usage (however small) that'd involved.
and in case it's not blatantly obvious, whitespace is good for showing the spec, but you'd want to generate xml messages without any formatting whatsover, as that'd save those 17 bytes in the below message compared to when it has the extra line breaks and tabs.
Code: Select all
<?xml version="1.0" encoding="UTF-8" ?>
<ClientMessage>
<OpenGame
port="9999"
map="Sk-Rush"
maxplayer="4"
techlevel="1"
version="2.1"
name="My Game Name"
/>
</ClientMessage>
it might be worth allowing for an optional
ip attribute -- there might be reasons that a user would want to use an intermediate "master" server, or other instances where the ip address of the actual game would be different than the ip address of that the "OpenGame" message came from, like if i had one connection for high-priority traffic (such as the actual game) while i had another for low priority stuff (such as http and master server requests) on the same machine, and if the ip address is not specified, it'd be assumed that the game would be hosted on the same ip as the one used to send the "OpenGame" request.
additionally, a map "hash" might be useful in addition to the map name, so that it'd allow the client to determine if they have the right version of a map -- would be wise to accompany this with client-side map hashing so that multiple versions of a map may be stored and used.
port int_16
map char[64]
maxplayer int_8
techlevel int_8
version char[16]
name char[128] (limit it in game or via the server -just cut it if too long) to 60 or 80 chars)
gameid char[16] (12 chars length)
state char[16]
the reason multiplayer game servers often have really long names is generally because there is no adequate system for filtering and tagging different types of servers -- even quake3-based games, which generally have very above-par server filtering options don't give the server admins enough flexibility, since there's almost never any way to specify house server rules before you enter a game. for that, we might add an optional child element to OpenGame, named something like "ServerRulesText" that holds plaintext, which allows the server admins to specify house rules that aren't enforcable by the engine, but can still be viewed before joining a game. Also, showing every single settable game option to be viewable from the player's client will greatly lessen the need for any server admins to have overly verbose game names like "~~MEH~~ clan *house of pain* - Sk-Rush HUMANS-VS-BOTS NO RUSHING jimmy is admin, CHEATERS GET ONE WARNING" -- in that example, if you also add clan information to be available as a seperate attribute or element, then you can allow the client to display or hide such information, and perhaps allowing clients to add a color based on filters would allow them to display all small map servers in red, or all techlevel=2 servers in blue, or both of those in red at the same time (user customizable). ideally, we'd want to get the actual server name down to just "*house of pain*", where everything else is a collapsable column or is displayed in the extended server info when it is selected but before it is joined.
FIPA gives specifications and examples for a bit efficient message protocol that you should give strong consideration to...