Posts Tagged ‘Grapple’

The case of the missing Majesty

Friday, July 17th, 2009

A few people are asking where is Majesty, howcome everywhere is running out of stock?

Well, Majesty is actually out of stock. We ran out during the May sales, and it is still not reprinted yet.

We have been holding off on the reprint, as we are working heavily on updating it. The first version of Majesty is a little dated now, it uses some old libraries (we were using SDL 1.2.5, which is just a little out of date!), and it uses some systems we have since stopped using (such as the old static/dynamic release system to satisfy the LGPL).

We are also removing the old OpenPlay library used for multiplayer games up to now, and replacing it with Grapple, and integrating it with the PenguinPlay server for lobby and scoring systems (as you can see below).


This does mean network compatibility between versions will be lost, but it means that you now get all the advantages of PenguinPlay, and Grapple, which is a more advanced networking system than OpenPlay. Saved game compatibility will not be lost, luckily!

Unfortunately this all takes time, and we were not expecting to sell out so soon. We sold more Majesty than we were expecting to in the sale, and so we were out in our time estimates by a few months, as to how long the remaining stock would last. The updates were about half way through when the stock finally ran out, and not in any position where we could simply release a new version.

Luckily the changes are almost finished…maj_manual

So, in a few more weeks, you can expect that new Majesty will be coming your way! If you don’t have it already, you probably should get it. If you already have it, well, the new version also has a colour manual instead of the old black and white one, uses the new setup tool, and the disc looks better.

I know some people may ask, why didn’t we make the colour manual and better layouts before? Well back when Majesty was first printed back in 2003, the cost of colour manuals was so high that it was just not possible. Now, colour manuals are much more affordable. As for the rest, well, LGP was just learning its trade back then, and now, we know what we are doing and can do a better job!

So, new player or old, whether you buy the new version, or just patch your existing disc, I hope you enjoy the new version of Majesty. All in all, it is a new lease of life for one of our most popular games!

  • Share/Bookmark

IP MASQ shortcuts causing Grapple to fail

Saturday, July 4th, 2009

This is a technical article that goes to some depth into networking protocols. Reading this article, you will need some overall knowledge of how UDP networking works, and a basic idea about what NAT and IP MASQ is.

We’ve just spent quite a while investigating issues with a small number of games failing to make connections to perfectly good servers. Grapple, the LGP networking layer, is designed to work around the presence of firewalls, NAT, and all that good stuff, so that users can host a game from any machine on their network, whether it be exposed to the outside world or not.

So, when we found out that some people couldn’t connect to games, we were a bit concerned. After all, our code should be just fine for this. It has worked in all of our test scenarios.

Unfortunately we assumed that all networking at the kernel level worked. This was a mistake.

So, take a scenario, lets say host A (lets call it gateway) is the gateway server, running IP MASQ to NAT all servers on its local network. Host B (call it laptop) is a machine on the internal network.

Now, as we run through this article I will run you through some aspects of NAT, STUN, TURN, and other nice things about firewall and NAT handling. I wont be going through the exact protocols, but I’ll give you a bit of an idea how it works.

So, Laptop is the machine I want to use to start up a game server. I start a server and bind a UDP socket to port 2000 on all interfaces. I then use STUN to find out what kind of connection I am on. The method for STUN is shown below.stun

STUN tells me that the server is on a symmetric NAT. This means that the only things that can communicate with the server, are things that the server has talked to itself first.

This is the most restrictive type of NAT, under usual circumstances it will mean that it is effectively impossible to make connections to this laptop game server without making manual traffic routes through your NAT routing table on the gateway machine for each client. Any client connecting to the server will try and connect to the laptop, but any routing will be rejected because the laptop has not first connected to the client.

However, Grapple can handle this, as I will demonstrate.

So, on the gateway machine (it is important for later on to note that the gateway machine is also the client trying to connect to the laptop server to play the game), I start up a client. The client tries to directly connect to the server, sending a number of UDP connection requests. The server does not receive them.

This is not unexpected, as demonstrated earlier, the server is behind a symmetric NAT and the server hasn’t sent any data to the client, and so the servers routing will reject anything being sent to it from the client.

So, at this point it looks fairly hopeless, how can the server magically know the client is connecting to it.

Well, the answer lies in the STUN server. The laptop server has already talked to the STUN server and so the NAT routing tables allow the STUN server to send more data to the laptop.

So, the client gateway knows about the same STUN server, and so sends a request to the STUN server to ask the laptop server to connect to it.

The laptop receives this request, and connects to the address that the STUN server requests. The client should then, we hope, be able to communicate.

Now at this point this can go two ways.

1) Client is not behind a symmetric NAT or firewall

In this case, the client receives the data packet, and communication can start. We’re pretty much done handshaking, the client and server can talk to each other.

2) Client IS behind a symmetric NAT or firewall

The client will never receive the packet from the server. No communication is possible.

Now, in the instance in question, we discover the situation is an impossible one. The client receives the packet from the server, but then is unable to reply.

This is completely impossible, the routing table to the client has seen a packet to from the laptop to the gateway, and so should allow 2 way communication between the two machines (on the same ports). But for some reason – it wasn’t!

This was the sticking point. How could this be possible. We knew that the laptop worked this way because we had communicated with the STUN server successfully, and this relies on the fact that an outbound packet creates a tunnel back to the server. This is vitally important for all networking, or you would just send out data and never get anything back, rendering NAT pretty much useless.

The issue turned out to be the IP MASQ NAT on the gateway.

The laptop sent a packet to the external IP address of the client. This means that it should have gone out to the NAT layer, and been NAT’d to the external IP and port of the server socket communicating to the client. The client would have received a request that external IP was trying to talk, and would respond to that address. The response would have gone through the same IP MASQ layer, and the server would get back a response from the location it expected.


IP MASQ has decided in its infinite wisdom to take a short cut. It spots a packet will be routed to the gateway, and decides that, hey, they are on the same internal network. They can talk directly! And so, the packet presented to the client is not showing as coming from the outside internet, it is shown as coming from (the internal IP address of the laptop). And so, when it gets this reply, it sends a response back. As the response never passes through the IP MASQ because it is going over the internal network, then the response to the server comes from and as the server sent its data to the servers own firewall (independent of the NAT) says ‘hey, I don’t know you’ and rejects the packet.

All because IP MASQ takes a short cut.

In the end, the problem is solved that if the client doesn’t receive further communication from the server, then it falls back to its final communication option, TURN. We have already demonstrated that the STUN server can talk to both sides, as both sides initiated communication with the server. This means that the STUN server can act as a relay between the client and the server, sending any and all data via this third party. However to be honest, we don’t like doing that as obviously it will increase latency of games, and also it means that any and all game traffic that has to resort to TURN has to be passed via our servers. A few games running at once, no problem, but more and more games means more and more bandwidth used, and we’d like to avoid that!

So in the end, the problem is solved, but really, if not for IP MASQ making a shortcut for efficiency, there would never have been a problem in the first place.

[Edit: I am adding the layout of the network below, to explain a little better]


  • Share/Bookmark

Sacred Gold is now, well, gold!

Friday, March 6th, 2009

sacredIt took a little longer than we had expected, but we can finally announce that Sacred Gold has been sent to the production company, and we expect it to be ready to ship in 2-3 weeks.

We expected to have had it ready weeks ago, but some last minute issues caused some unexpected delays. The network layer, Grapple, had an error in how it communicated through certain types of firewalls and NAT routers, which meant that only around 30% of players would be able to access the multiplayer features of the game on the PenguinPlay servers.

But that is all past us now, and the game is in production! The game also has a nice new large map insert being produced with the game, just as a small bonus extra! We are also working on the finalising of the demo, which we hope to have available before stock of the game arrives, so you can try it out before buying.

  • Share/Bookmark

Enabling online gaming

Wednesday, February 18th, 2009

We recently released PenguinPlay, a multi player matchmaking service for Linux. Part of our motivation to do this was the fact that it could, at times, be very hard to actually find someone to play online Linux games with, our community not being as large as the gaming communities on other platforms, as well as the fact that none of the other matchmaking services had proper Linux support. One of the main reasons for this, of course, is the fact that most games aren’t compatible across platforms, usually because they use a proprietary network layer that only works on one platform. PenguinPlay on the other hand is built around the LGP networking library, Grapple, which both makes support for PenguinPlay quite easy to implement, as well as giving support for platform-independent multiplayer. The service itself had been in the making for quite some time before its recent release.

Although it still is relatively new, there’s already quite a few nifty features available, such as in-game lobby, live information about ongoing games on the web site, as well as highscores for all games. Sadly though it can still at times be somewhat hard to find someone to play with, which is why we added a new feature to PenguinPlay this week, namely e-mail notifications. This lets you subscribe to notifications for games, then PenguinPlay sends you an e-mail when a multiplayer game that you can join is started. In order to enable this feature you need only log in to your PenguinPlay account, edit your account settings and then select that you wish to edit notification settings. From there you can subscribe and unsubscribe to new game notifications for the various games available on PenguinPlay.

To compliment the notification service and the on-site forums we have also started an IRC channel where PenguinPlay games can chat and schedule games in. Join #PenguinPlay on the IRC network.

One of the primary things that separates PenguinPlay from the many others similar services out there (apart from the obvious support for Linux) is that it is available, very cheaply, for developers of Free/Open source games. The Grapple library is already open, so they need only pay a (nominal) fee for hosting services, and then we take care of the rest (no proprietary code needed). The library itself is multi-platform and runs on Linux, BSD, MacOS X and Windows. Our goal is that a multi-platform online gaming community is built up around it, in particular, one where Linux gamers are real full-time members of the community and treated at least as well as gamers from other platforms.

As of this writing, the games that are available are only Linux versions, and only commercial games. There is no technical reason why the developers of the games for other platforms shouldn’t be able to patch their games to work with PenguinPlay. The games that are available are currently available for online play are Ballistics and Knights & Merchants both of which needs to be patched to the latest version, as well as high score support for Jets’n'Guns, which was the first LGP game to ship with PenguinPlay support out-of-the-box, and Candy Cruncher (which also requires a patch). The upcoming LGP game Sacred: Gold will also ship with PenguinPlay support out-of-the-box, enabling Linux gamers to adventure together, and our beta team has already done so. I for one can’t wait to quest along with fellow Linux gamers.

We are hoping that the service improves the multiplayer experience for Linux gamers, making it easier for the gamers to find people to play with, and games developers to have full multi-platform multiplayer support in their games. Keep checking this blog and the PenguinPlay website for news about more upcoming PenguinPlay features and games.

If you have any input, suggestions or questions for me, feel free to ask them here in the comments, on IRC, or via e-mail (to eskild at the domain linuxgamepublishing dot com).

  • Share/Bookmark