| |
|
|
Indie Links
|
 |
|
|
| |
|
|
Jabber in Games Part 1 - Meet Jabber
|
|
|
Location: Blogs Theoretically Speaking |
 |
| Posted by: Andrew Douglas |
1/19/2007 |
Okay, who knows what Jabber is? If you do and you're not already using it in your games, then why not? Even though Jabber is a very stable, extremely simple and really quite useful platform for developing online systems (games, Instant Messaging and a variety of other online applications), very few games really take advantage of it, and in most cases are worse off because of it. So this series of articles will go over why to use Jabber, how to build on top of Jabber and hopefully will include some useful code to get you going in no time flat.
This first article is simply the "what and why" about Jabber. If you don't have any idea what Jabber is or how it can help you make better games, then this is the place to start. If you're already familiar with its concepts, I'd love to hear from you - like how are using it today - if you aren't, I really want to know why. I'd also appreciate feedback on things like how you plan to use it in the future and what kind of information would be helpful to you in these articles. Help me help you.
What is Jabber:
Jabber is really known as an Instant Messenger alternative to the "Big Boys" like Yahoo, AIM, ICQ and MSN. It's based on an open (as in, non-proprietary and free to use), extensible XML based protocol called XMPP. There's a huge ecosystem of applications, tools, services and companies that are built around Jabber/XMPP and it's "openness" means that there's an extremely low barrier to entry, which is perfect for indie game developers. But if Jabber is just an Instant Messenger, what does it have to offer to game developers?
This is where it gets fun. See, as you think about the things you need for your next, ultra-cool online multiplayer game, what features do you think of:
1. brain-dead simple but secure authentication
2. messaging
a. between players
b. between teams
c. between your application and the players
d. lobby chat
3. game hosting - either peer to peer or with dedicated "game servers" and the NAT issues involved with connecting players
4. matchmaking
5. content-filtering of all those naughty words
6. saving server-side data to prevent cheating and to allow users the ability to switch between computers without losing their data
7. friend management
8. presence information so you can tell who's online
9. leaderboards
10. online tournaments
11. bots/AI
12. voice and/or video chat
13. versioning - or rather, ensuring that your users are running the latest version.
14. and of course - when the game becomes a huge success, load balancing, distributed servers, hosting, etc.
I'm not going to say that Jabber has all of these problems solved out of the box for you, but let's look at how most indies go about solving these and then how Jabber can help them solve their problems in a more rational and efficient manner.
So most indies I know of don't really make online games. Sure, they may have a leaderboard written in PHP, they may have built an update service so that patches are distributed automagically. They may even have rudimentary online play. The few successful indie games that are online play capable are fairly few and far between though, which tells me that maybe there's some work to be done to improve the situation a bit. I'd say that for the most part, the way indie's solve these problems is that they just don't. It's too complicated, too expensive and too time-consuming to build out this infrastructure when all you really want to do is make games, right? But let's look at an example online indie game and see how they solve these problems.
Dawnspire was the Game Tunnel Multiplayer Game of the year for 2006. That should be an ideal candidate to see how successful indie games handle multiplayer. And the answer is? Dedicated Servers. What's a dedicated server? It's a machine that's not running the game "client" or GUI, it's just running the "simulation" for one or more matches and making sure all the game rules are followed by everyone. This is a great solution because it's drop-dead simple to get a client to get connected to a match. The tricky part is getting the dedicated server accessible to the client, and that's because most machines "on the internet" are behind a router/firewall that is providing Network Address Translation (NAT). This means that in order for the internet to be able to access the server, holes have to be punched into the firewall and requests for specific ports must be forwarded through the NAT. This isn't an automatic operation by any means and is completely unacceptable for a 'casual' game. But once the dedicate servers are configured, then the clients all can connect to a game without any problem.
If dedicated servers didn't exist, and a peer to peer network architecture is used, then NAT traversal becomes a huge issue. There are games that have overcome this (without requiring network administration changes in order for them to work), but it's generally considered a load of trouble and, if it is supported by a game but NAT traversal must be configured manually, it is usually not advertised very well because of it's complexity to configure. The problem is that, for a small indie game developer, where do the "dedicated server" machines come from? Well, usually the developers have to host a few dedicated servers themselves, but generally speaking, people who want to play matches against their friends will get their geekiest friends to setup a dedicated server that they can all play together. This is just the way life goes really. But until you build up a large number of players, it's hard to get people to bother setting up dedicated servers for your game, so just be ready to host the dedicated server(s) yourself.
The other big issue is that all a dedicated server gets you is "online play". It doesn't get you matchmaking, friends lists, presence, guild management or a whole slew of other features. You're usually left to coding up these services yourself and they usually run on a whole other server.
Right... This is why the huge majority of indie games don't support online play let alone all those "community" features. There are services like GameSpy out there, but these aren't geared towards indie's either. The state of online indie gaming is... poor. So let's look at how Jabber can solve these problems better:
1. There are freely available, infinitely scalable Jabber servers that run on a variety of platforms, coded in a variety of languages with a large assortment of features that you can have up and running in less than an hour. They are extensible and distributed, which means writing "game server" extensions is not only extremely simple, but it means you focus on your game. Most Jabber servers support the following features out of the box:
- Roster Management - ie. Friends lists
- Presence - who's online and what are they doing.
- User to User and Multi-User chat. It's an instant messenger service after all, right?
- Version checking. This isn't necessarily going to do everything you need, but it's free and "in the box"
- Custom User data - save user settings to the server.
- Search - find other users or matches. You can add quite a bit of complexity to this without writing any server code at all.
- Content filtering - each message can be scanned for naughty words.
SSL and a whole assortment of security features.
- Anybody who's spent any time on IRC knows that writing "bots" is easy. It's just another "user" that happens to be a computer.
Now all you've got to do is write the UI and the game server logic. And that's the way it should be.
2. One protocol to rule them all. Unless you have some heavy duty network experience, UDP, TCP, NAT, ICE and a whole slew of other acronyms scare and confuse you. That's okay... Jabber sits on top of those low level networking layers and allows your application to speak XML between clients and servers. In fact, most libraries make it so easy you don't really need to know XML in order to send and receive simple messages. Whether your building out the UI or coding up your game logic, there are just a few building blocks (that we'll cover in another article) to learn and everything is simply built on those few blocks.
3. Peer to Peer without NAT issues. There are two options here. If you don't want to write up and host your game server, you can actually have each client have the ability to run the "game server" like code. If you're making a turn based or "almost real time" game, it might work out okay. But for those of you thinking "but this doesn't apply to me because I'm making an FPS" (or other twitch based multiplayer game), fear not. Jingle is a new addition to Jabber that's only just now starting to become popular. It's how Google Talk does peer to peer voice messaging, and in fact Google has released their toolkit for how they did it - called LibJingle - as an open source project (BSD style license so you can use it commercially). Their toolkit allows UDP or TCP like peer to peer connections that will "automagically" punch holes through NAT's and firewalls and it only uses Jabber to establish the connection. The great thing is that you can get the best of both worlds by having a Jingle connection for things like your twitch based games, for your peer to peer voice chatting or even for video chatting, and you still have the Jabber connection to the server for messaging and friends lists. You can have your cake and eat it too!
4. The only thing left really on your todo list is leader boards and tournaments. That's really where the extensibility of the Jabber protocol comes in. Your game server, leader boards and tournaments are extensions that you write for your server that clients can make requests to. Your extension simply sends the appropriate messages back to the client that requested them. These functions are easy to create. So easy in fact, that some of the future articles in the series will (hopefully) include full source for leader board and tournament management. There will also be some helpful building blocks for writing your game server logic that should come along with it.
So if you are really excited about getting started with Jabber, you can check out a few online resources below. I really want to foster a community for Jabber based game developers. One idea is to start a wiki. If you have any suggestions or ideas, they are more than welcome. Watch this space for more info, code and resources.
-Andrew Douglas
http://theoreticalgames.com
|
|
| Permalink |
Trackback |
Comments (3)
Add Comment
|
using it for casual game development right now. |
By Nate on
4/23/2007 |
| Yeah, I'm using Jabber extensively for a casual game my company is developing. It's nice to have so much functionality out of the box. We've got bots and rooms and services and everything, for the low low price of writing some client code. Unfortunately I wasn't able to find an XMPP client that fit our licensing and performance needs, so I had to hand-roll my own, but even so I really appreciate the server and protocol. |
|
|
Re: Jabber in Games Part 1 - Meet Jabber |
By GBGames on
8/13/2007 |
I used Jabber to communicate with friends, but almost none of my friends used it, so I stopped logging on myself.
I know of one developer who used IRC for multiplayer support. I found it novel but didn't think it would work for a "serious" game...then again, they are getting pretty serious with venture capital and the like...
Using Jabber for indie game development sounds great, and with Jingle, it seems that the performance isn't going to be a problem. Are there any negatives to using it? |
|
|
Re: Jabber in Games Part 1 - Meet Jabber |
By scot with one t on
8/23/2007 |
| this is your blog?? |
|
|
|
|