Home   News   Mailing List/irc   Documentation   Download   Screenshots
Printable version, click here
This specification describes the technical side of the protocol used to communicate between the server and client of the Terranova game. This is the protocol for version 0.0.1, see the Battleplan for more information. It is in no sense complete untill the code is fully functional.
The choice of XML is a simple one: it's an open standard that's designed to be robust. This fact lends itself naturally to an open-source project. One of Terranova's objectives is to use XML in various ways to provide media content and make a game out of that. XML is a markup language for describing content of any kind. It has been used in word processing, web pages (XHTML) and other protocols (XML-RPC).
XML and SVG
Since graphics are stored on the server, the obvious choice would be to send embedded SVGs inside an XML protocol. However, in providing services for other types of SVG or XML-TN clients, the SVGs will be stored on a webserver and links to the SVGs will be sent instead. For example, an SVG-enabled webbrowser can still view the SVGs in the picture archive on the webserver.
BNF of XML-TN
Here's a draft version of a server-side XML-TN BNF. The map protocol should be usable, the rest needs more work after the 0.0.1 release is done. Here's the client-side XML-TN BNF. DTDs will follow later.
Order of a client-server stream
1. A client connects successfully to the server:
the server sends an acknowledge with a copy of the command:
or an error:
2. The client asks for the map and a viewport:
Server responds with a map stream (See BNF, XML-TNS clause with XML-MAP in it):
If we look at the XML-TN code we see an acknowledge of the map command followed by a map tag. The total dimensions of the map are 8000 pixels in width and 6000 in height (between dim tags). Next is the Fred entity (ent tag) with an ID of 1. It must be placed on a position (relative to the top-left corner of the map) x,y=2000,500 to begin with. It has 2 behaviours (bhr tags) with values 1 and 2. Suppose, the client has a database of behaviours where behaviour 1 means 'movement which consists of pausing between each frame according to the velocity which will be sent later on'. The 3 svg tags which follow, contain the framesequence which repeats itself. On a sidenote, the server will send updates in translational velocity and rotation which will make the entity move towards the gem. To make Fred pick up the gem, the server will send some XML-TN stream with a behaviour 2 tag in it, which will tell the client that it must use the frames in the sequence, in this case only 1 frame with SVG image 'fred-pickup.svg' .
OK, back to the map code. The next entity is the gem itself. It has an ID which is 1000. Items just lie on the map and the gem lies on it at position x,y=2075,575. It has a behaviour 0 with only one SVG image which is the appearance of the gem on the map. It can apparently be picked up by a player character because the second behaviour contains an image of what it would look like on an inventory screen.
Finally the client ask for an initial viewport:
Server responds with viewport line (See BNF):
3. Future development: Client sends commands to the server and vv.:
Note: this is not part of protocol version 0.0.0
Later on the client or server will send updates of changes of behaviour in entities or changes in velocity or rotation, for example a book gets picked up and it's behviour changes from 2 (lying on the map) to 3 (in inventory). Behaviour can also be used to describe a sprite's random moves to the client in combination with the SVGs already stored there. To prevent that a hacked client can be more advantageous in the game, the order of sending updates is: do stuff in client -> ask server -> server sends response -> update client. Another thing is that acknowledged responses from the server always contain the command which the client sent for. If the server sees the need to update the client without receiving a command it puts a <cmd /> string in it. This can happen for various reasons, for example, a flower sprite needs to change its behaviour (and thus its appearance in the client) because it starts raining.
Open issues and ideas
Author: Johan Ceuppens (jceuppen at sourceforge)
Terranova Project - Last update: Apr 6 2003