The genre of Massively Muliplayer Online Games (or MMOGs for short) is a relatively new, but increasingly popular one for game developers. Encouraged by games such as Everquest, Star Wars Galaxies, or Ultima Online, many new developers are inspired to create designs for huge online worlds with never-before-seen levels of interactivity and detail; professional developers may be more drawn by the constant stream of revenue such projects can provide after launch, in contrast to the usual once-in-a-blue-moon payment from the publisher. The market for MMO games is particularly strong in Asia. But while such games are popular, they are also one of the most complex projects you will ever encounter. Leaving aside the game design issues - creating and balancing a virtual society that can accommodate thousands of players - the practical issues of developing and running an MMO game are extremely challenging to navigate. This article seeks to provide an overview of some of the issues you should consider when thinking about an MMO project; to give you some of the questions you should be asking, as well as a few possible answers. Servers, sniffers, systems and suitsThe issues I will cover can be broken down roughly into four categories, though there is some overlap:
One category which you may have expected to show up - client issues - is something that I do not feel I need to cover, as the issues inherent in writing a client for an MMO game are pretty similar to those for any other type of network game. Connection IssuesIn any networked game, you need a system for sending data between nodes in the network. Given that we're talking about MMO games - and all MMO games use a client/server model of communication (as opposed to peer-to-peer, which would suffer major security and management issues) - we can assume that we're talking specifically about the connection between the client and the server. What do we need to be aware of when designing this part of the system? Security. In general, you do not want third parties to be able to screw around with the data that you're sending over the wire. Interception of packets could lead to a victim's game account details - such as the username and password they use to log into the game - being hijacked. A more worrying scenario is the interception of credit card details, in the case of a game which lets players pay their subscription fees from within the game. Encrypting every packet you send is probably impractical, not to mention largely unnecessary - intercepting a packet which gives a player's current position in the game world may help someone cheat, but the effort required to obtain such a small piece of information makes it unlikely that people would bother with it. Still, it is likely that you would want the facility to transmit data securely, even if you do not make use of it all the time. So how will you provide that? Which pieces of information will be encrypted and which won't? Authentication. How can you ensure that the packets you're receiving are really from your client software? How will you prevent someone from hacking together their own client software, which allows them to do things you don't want them to? How can you be sure the source IP address is "safe?" Stability. Players will not be happy if their connection to your server is cutting off every few minutes. Whatever technology you use to connect your servers to the Internet should be very stable; protection against things like Denial of Service attacks is also something you may want to invest in. Running your MMO server on, for example, a home broadband connection which disconnects for five minutes every few hours, is not advised. Bandwidth. The connection will be handling packets from potentially hundreds of thousands of clients; the realtime nature of most games means that each player will be sending and receiving many packets per unit of time, compared to non-realtime services like websites. You need to have a connection which, as a whole, can handle this much data; several gigabytes per hour is not an unreasonable expectation. It's unlikely that you'll be handling everything through a single pipe. Latency. Sadly, it's not yet possible to send information to the average client through quantum entanglement; so, the time it takes for your packets to go from server to client is significant. When sending packets across the Internet, your data will be potentially handled by a pretty large range of devices, each of which running under different loads and imbued with different levels of power. The time taken by a packet to reach its destination will vary, and it may not be small. How will you attempt to minimize latency, at least within the parts of the connection you control? How will you deal with packets that take a long time to reach their destination, and packets that arrive out-of-order? Failure response. What will you do, both at the client and server ends, if the connection drops or packets are lost? This has implications in your game design - particularly dealing with players who conveniently 'drop' from the game just as they're about to be killed violently - but it bears thinking about on the technical end as well. Should the client try and reconnect, or should it wait for the player to instruct it to do so? Should the server give the player a 'grace period' of a few seconds to reconnect, perhaps based on their ping time, or should it treat the disconnection as a proper one immediately? When it comes to the per-packet level, when will you use guaranteed delivery (which causes all lost packets to be automatically resent, but requires extra packets to be sent back to the server for every packet that is received by the client), and when will you use non-guaranteed delivery? Protocol. What conventions will you use in your networking protocol? (By 'protocol' here, I do not mean TCP or UDP - rather, I mean the custom protocol that you build on top). An example would be strings: you could go with C-style null terminated strings, or you could go with Pascal-style strings where the length is prepended to the string. Will you stick to network byte order (big-endian) for your data? |
|