sponsors gamedev.net search:

Technology issues In this section I'll discuss some of the MMOG-specific technology issues, covering both client and server applications (the "server application" being the collection of programs you run on the server-side operating platform). Caching. Caching is the practice of storing resources that you're more likely to need in a place that's faster to get to than the regular data storage. In MMO gaming, the client programs will pretty much always be caching data - that's because the "regular data storage" is all the way over the network at the server, so accessing it is likely to be very slow. So, we're talking about data that the client will need for the very next frame - models, textures, sounds, and other assets for the player's current status and location would be an example. A key concept with caching is "temporal coherence" - the idea that something is the same from one frame to the next. If something is temporally coherent, there's no point re-loading the data from the server, so you cache it. Beyond that, though, what do you want to cache? How much of that content needs to be picked up dynamically - from the servers - and how much can be included in the client software (i.e. on the CD)? The rule of thumb is: cache anything you might need in a hurry, especially if you can't predict when you'll need it. Graphics for an in-game menu would be an example - you have no way of knowing when the player will bring up the in-game menu, and you definitely don't have time to sit around downloading the graphic from the server. Given that they're unlikely to change, they'd be prime candidates for including in the client software. At the server end, you'll probably find advantages to caching things as well. You might want to cache things like level geometry around spawn points, so that it can be sent more quickly to players joining the game, rather than having to pull it out of hard storage; or maybe you'll cache information about a specific item that people keep asking for. The best way to find out what to cache is to monitor the requests and see which ones come up the most frequently; a truly rock-solid caching system will do exactly that, and has the advantage that it can adjust over time (i.e. if people hardly ever use a given spawn point, it can detect that and stop caching it). You'll also want individual servers to cache information within the operating platform. Say you're processing collision detection for a bunch of entities; you'll get a good performance boost from fetching them all into the cache and testing them there, rather than fetching them one-by-one, testing, and then dropping them so that you have to get them from the database again next time. Also, at both ends of the wire, How large will caches be? Client-side, you'll probably be limited by both the amount of system memory and the amount of hard-disk space you can reasonably use; server-side, though, you've got more control. You should definitely take cache sizes into account when designing your operating platform. Dynamic Updates. The ability to dynamically update the game - adding new content, removing existing content, or changing content - is crucial. New content keeps the game from getting boring and thus keeps the players playing; there may also be bugs or gameplay balance issues which haven't emerged until several thousand players are present in the game (the latter is especially common). What's your procedure for updating the server application? How about the clients? Will you just stop all the servers completely, make the changes, and relaunch it? Perhaps you'll take down servers one by one - after moving their load off to other machines - update them, and then bring them back into an operational state? That means that until you've done all the machines, some parts of your network will be running the 'old' version and some the 'new' - how will you deal with that? Or perhaps you'll avoid bringing the machines down at all, providing a mechanism for the server application to 'assimilate' changes while it's still running? The effects of content updates can be extremely extensive. Say you want to create a brand new building in a specific place - will you just sit there and wait until the space you want becomes clear of players? If you're placing the building in a town, that could be quite a wait. So perhaps you'd go for some system which lets you 'mark' the space as about-to-be-built-upon, turning it into a no-entry zone for players until you're done building? The addition of a brand new chunk of geometry to the world would force players in the vicinity to download it from the server into their caches - how would you give the clients 'advance warning' so that they could pick up the mesh before it's needed, to prevent an awkward pause when you place it? Then, say you want to remove that building a few months later. What do you do with players (or NPCs, for that matter) who are currently inside it? Just drop them on the floor outside with no warning? Would you tell clients that the assets for the building no longer need to be cached, and if so, how? The most difficult type of update is usually a code update - where you're changing the actual software running either client-side or server-side. You may well want players to refrain from playing until they've installed the client-side update (for example, if it closes an exploit that some players were using to cheat with) - how will you enforce that? Will it be done from within the game, or will players have to exit and visit your game's website to get the update? Security. It's probably been said that computer security is all about being openly paranoid about your users; if it hasn't, then I'm saying it, because it's true. Any user is a potential cheater, cracker, or malicious script kiddie aiming to take down your servers or generally ruin the game for other people. As such, you should never trust anything information coming from the user - even if you have authentication measures in place to try and ensure that data from the user really is from your client app. Say that your client app is repeatedly sending the position of the player to the server, and the server is simply copying this position into the database as holy writ. An enterprising cracker could modify the client application to send a position value of his choice; and, presto, he's granted himself the ability to 'teleport.' Even if your authentication system prevents modifications to the client software, there are still ways of modifying packets on the fly. If someone finds a way around your authentication, then it's as good as non-existent. So look at things from that point of view, of the position of having no client authentication. The most secure situation would be to send data to the server purely as a stream of input commands, and have the server do the actual processing of those commands to move the player around and so forth. Even then a cheater could still take advantage of you; he could record a stream of keypresses and send them all to the server in quick succession, allowing him to "press keys" faster than a real human actually could. So you'd still need some kind of 'sanity checker' to watch the user input streams, just to check that what it's seeing is reasonable input for a human player. Of course, this whole approach isn't used because of the processing power it requires; you'd effectively be moving the load from all of your clients (who may number in the hundreds of thousands) onto the server, which is a pretty significant load. The MMO client-server setup represents a pretty significant distributed computing platform, but you have to be careful about what the clients are actually doing. As such, it never hurts to keep things fairly tightly locked down on the client side; server-side security systems are all very well, but it's nicer if you don't have to use them. Pirating an MMOG client is usually pointless (you still need to pay a subscription fee) so copy-protection schemes are generally unnecessary; instead, the client should be watching out for modified data files (perhaps through a checksumming mechanism), unsavoury-looking programs in memory (particularly so-called 'trainers' that attempt to alter the client's memory while it's running), and debuggers. All three could be signs of someone trying to cheat the game. Synchronization. Here it is again, though in more of a gaming context - you need to keep all your clients, and all your servers, synchronized (or as close to it as possible). That doesn't just mean that they need to all display the same game clock time; they all need to be working with the same set of data. A player shooting at an enemy will be less than impressed if that enemy actually moved away several minutes ago and they're shooting a ghost (but couldn't tell because the server isn't keeping them up to date). This issue is particularly prominent in MMO games where different servers are handling different regions of the world. When the player travels from one region to the other, and hits a 'server boundary' (i.e. reaches the edge of the area controlled by the current server), he must transfer to a different server. If the two servers are out of sync, it could cause major problems; for example, standing in one server the player sees a tank rolling in his direction but still far-off; when he switches servers, he discovers that the tank is actually right on top of him. Even to an observer it can look very strange - an entity can be seen to 'skip' boundaries as an out-of-sync position is suddenly updated to a correct one. Business issues

Contents   Introduction   Operating Platform Issues   Technology issues   Business issues   Printable version   Discuss this article