As announced earlier, I’ve been working on a demo release of Kings of Space. Today, the time for the release has finally come.

Before this release, I’ve had about ten Weltensaga players test version I10 of the game. These tests reveiled a few shortcomings that I had to fix before this release. Creating a new character at a server was, for example, too confusing for most testers because three different “create” buttons had to be clicked. So that’s fixed now, the server list has been improved a little and I’ve added a few more planet names. Additionally, a Direct X version of the game is provided with the Windows download to accommodate those who don’t have a working OpenGL version installed.

For more information on this game take a look at the KoS project page where you can find screenshots, a video and a little information.

Bottom line: Here is Kings of Space version I11 for free download:

• Linux version I11, TAR-GZ file, 23 MB
• Windows version I11, ZIP file, 24 MB

But beware: This is a very early version of the game and by no means finished. I call it a pre-alpha or tech demo release. Do not expect the game to work reliably or to be able to keep your character/ship/goods/money/etc. between versions! This game probably will not even be finished in the future.

That being said I’m looking forward to any kind of feedback. Just post a comment to this entry or send me an e-mail.

Update (July 8th, 15:05) I’ve just uploaded a new version of both the Windows and Linux files. This version is still compatible with the old one, but fixes a bug in the server which caused it to crash.

I’ve finally managed to record a video of KoS in action. It can be viewed at YouTube or directly here:

More information is available at the game’s project page.

The video was recorded using glc (which really is a great tool!) and converted using mencoder.
If everything goes well I’ll release a playable version of the game in a few days.

As described yesterday, I’ve used RakNet’s Lightweight Database to keep a server list on a master server. Overall it isn’t that difficult, but there were a few things I had problems with. I think that it’s mainly due to the poor documentation of the Lightweight Database plugin. The documentation can be found here (manual), here (Doxygen for the server) and here (Doxygen for the client).

Column Numbers

My first problem was finding the proper cells in the table on the client. I connected to the server and got an object of type DataStructures::Table (documentation here) through deserializing the incoming stream. But when I then tried to use the member function GetCellValueByIndex of the Table class I got mostly garbage or data that didn’t make any sense. I then got the idea to simply dump the whole table to the console and was able to see that the table had more columns than I had specified when creating the table.

The LightweightDatabaseServer::AddTable member function silently adds columns to the table which it needs to work. I understand that those columns are necessary, but the function’s documentation should mention this because when you otherwise get strange results when using GetCellValueByIndex with an index you think is right though it’s not right.

Additionally, the number of columns added depends on the parameters given to AddTable. So you should make your choice about the parameters you want to hand AddTable and then check what columns the table really contains.

Pings

RakNet offers the possibility to ping a remote host, but RakNet doesn’t do normal pings, just its own pings which need a RakNet peer on the other side. I stumbled across this when I tried to use the removeRowOnPingFailure option of LightweightDatabaseServer::AddTable. After adding my server to the table I closed the connection to the server and destroyed the instance of RakPeerInterface.

If removeRowOnPingFailure was set at the master server the newly added server would only show up for a few seconds or minutes and vanish again. As it turns out RakNet pings the other side by trying to connect to the port the lightweight database request came from. Because I had already destroyed the peer which had used that port, the ping failed and my server was removed from the list.

I fixed this problem by making the local peer, that connected to the master server, use the port number that would later be used to accept connections from player clients. This actually worked and I’ve learned that, although RakNet doesn’t need to have the connection kept open, it needs to find a RakNet peer on the exact same port that was used to connect to the server when adding something to the table.

When I was last working on Kings of Space (“KoS”) I implemented a master server, i. e. a server list that is centrally held, using RakNet’s Lightweight Database which – after some problems – worked reasonably well. There is only the problem that I don’t really have the resources for always running a custom server.

I then decided to convert the code to using HTTP with a few PHP scripts on the server side. That way it’s possible to use Apache on the server side which is running anyway. Although RakNet is solely UDP based, it fortunately has a TCP plugin (“TCP Interface”) which can be used to make HTTP requests. I proceeded with implementing this “master server” and everything went fine, a local Apache correctly added servers, removed servers and sent clients a list of servers.

But when I uploaded the PHP scripts to a remote server (actually the server you’re using right now), it simply stopped working. On the client side it looked like the connection attempt had been successful, but when sending a message to the server the client would hang forever and the server wouldn’t even get an HTTP request. Running netstat on the server showed that the TCP connection was in the state SYN_RECV which obviously means that the connection hadn’t yet been fully established. Waiting for something to happen didn’t help because nothing would happen.

Finally, I got the idea that the problem might not be my code or the server’s firewall, but my router here at home. It’s a Speedtouch 585, one of these integrated DSL modem + router + switch things. So I looked through the configuration and found something called Web Browsing Interception, I switched it off and suddenly everything worked the way it should.

This Web Browsing Interception is normally only visible when the router doesn’t have an active internet connection and you try to access a webpage anyway. It then delivers a page to the browser describing the problem instead of letting the browser find out about the problem itself. I guess I can live without this “feature”.

I’m currently working on getting KoS so far that I can make a public tech demo available on this website.