Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

What are various ways of handling different version clients in multiplayer games? For example, when there's an update, some games allow you to play with people who have a different version of the client. How is this handled?

share|improve this question
1  
Simply allow only minor versions to differ, and if a change that would break compatibility is introduced, change the major version. –  Lohoris Oct 7 '11 at 12:55
    
It's not handled. Everyone upgrades. What do you hope to achieve by allowing mismatched clients? –  Patrick Hughes Oct 7 '11 at 18:41
    
@PatrickHughes I'm just wondering about how some games handle this because I've observed this in some games. –  skyuzo Oct 8 '11 at 20:58
    
@skyuzo Google does this with their server network, a project called "Protocol Buffers," but it's designed to allow asynchronous updates of their huge network and not to let them all play nicely using older versions. Kylotan's answer is good if you really want to, but his warning about new features in new versions is very important especially to gamers who hate unfairness. In any case it's a huge logistics nightmare once you get past 1 or 2 updates, you end up having to force an update for important new features at some point anyways. –  Patrick Hughes Oct 8 '11 at 21:11
add comment

1 Answer 1

up vote 5 down vote accepted

The first thing is that you need some way of communicating a version number, so the first thing a client should do is probably send its current version so that the server can take action accordingly. You may be able to embed the version number within another message, depending on your protocol.

Most games probably just reject older clients, and force them to upgrade first. Even if the code is unchanged, the presence of older data may mean the game is essentially unplayable. And if the underlying network protocol changes, older clients may not be able to connect at all. It's therefore useful to have a robust version check that doesn't rely directly on this protocol, otherwise people can't even connect to find out that they need to patch up.

The problem is not in allowing different versions of clients to play with each other as such, since usually all communication goes via the server. Only the server needs to worry about versioning, not each client. The developer can have the server note the version of each client and handle them accordingly.

The issue is that a new version usually implies a new or changed feature in some sense, and an old client won't have the information to be able to use that feature. The server can take care to avoid sending messages about this feature to older clients. Or, if you have a protocol that can handle it, you can send the messages anyway and the client can ignore any it doesn't understand.

share|improve this answer
2  
Don't check for client version, check for protocol version. And don't change the handshake part of the protocol ("Hi, I'm the Client, using protocol version X" - "Hi, I'm the Server, come in!"/"Hi, I'm the Server, and I don't speak your protocol version.") ever. –  Martin Sojka Oct 7 '11 at 14:26
    
Protocol version is critically important, but sometimes the client version is important too - if you're lacking the assets or a key feature then you may not be able to play with other people. You have to decide on what different versions will mean for your app. –  Kylotan Oct 8 '11 at 11:39
    
In this case the server sends the data in a way which keeps the game usable at least, and the clients ignore data they can't decipher. It's not like this is limited to games - we have the same problem with HTTP as well (with the two protocol versions being HTTP/1.0 and HTTP/1.1), and any well-designed web site will work in Firefox 1.something as well as in Firefox 8.whatever ... or in Lynx, for that matter. –  Martin Sojka Oct 10 '11 at 7:43
    
It's still not that simple though. It's not like the difference between sending HTTP 1.0 and HTTP 1.1, because that can be handled at the networking level. It's more like relying on a new mimetype, where the recipient needs to be upgraded or reconfigured otherwise it can't use the content at all. Whether this can be ignored or is a critical problem depends on the app. –  Kylotan Oct 10 '11 at 9:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.