# Server-side Architecture for Online Game

basically I have a game client that has communicate with a server for almost every action it takes, the game is in Java (using LWJGL) and right now I will start making the server.

The base of the game is normally one client communicating with the server alone, but I will require later on for several clients to work together for some functionalities.

I've already read how authentication server should be sepparated and I intend on doing it. The problem is I am completely inexperienced in this kind of server-side programming, all I've ever programmed were JSF web applications.

I imagine I'll do socket connections for pretty much every game communication since HTML is very slow, but I still don't really know where to start on my server.

I would appreciate reading material or guidelines on where to start, what architecture should the game server have and maybe some suggestions on frameworks that could help me getting the client-server communication.

I've looked into JNAG but I have no experience with this kind of thing, so I can't really tell if it is a solid and good messaging layer.

Any help is appreciated... Thanks !

EDIT:

Just a little more information about the game. It is intended to be a very complex game with several functionalities, making some functionalities a "program" inside the program. It is not an usual game, like FPS or RPG but I intend on having a lot of users using these many different "programs" inside the game.

If I wasn't clear enough, I'd really appreciate people that have already developed games with java client/server architecture, how they communicated, any frameworks, apis, messaging systems, etc.

It is not a question of lack of knowledge of language, more a question for advice, so I don't end up creating something that works, but in the later stages will have to be rewriten for any kind of limiting reason. PS: sorry if my english is not perfect...

• The Multiverse servers are written in Java as far as remember, but it sounds like you already have a game. Still, there is a nice high level overview you can look at here: update.multiverse.net/wiki/index.php/… – DrDeth Mar 11 '11 at 12:05
• While your game server architecture will be defined by the game in general. It is very much platform and genre dependent. If you're planning for many users, Java is a good opportunity to make use of Amazon's [Elastic Beanstalk][1]. This is a great way to scale your server on demand. Perhaps you should tell us more about the game - JNAG could be more than what you need ie. in a max 4 player turn based game. [1]: aws.amazon.com/elasticbeanstalk – Konrad K. Mar 11 '11 at 17:59

Unfortunately, I'm not aware of any (good) online resources or books on this topic. And I don't know Java. However, seeing that there are no answers yet, I'll share a few tips from personal experience.

First off, you need a fast and reliable RPC, or at least message queue, mechanism. This is what shall be used for both client-server and server-server communication. I don't know if there are any ready-made solutions for Java. With .NET we'd always made our own custom one, as this mechanism is really important. Most commonly a lightweight binary message protocol over TCP is used, but other options may be better depending on the type of game. A turn-based strategy might be better with XML or SOAP, and a fast-paced shooter may warrant UDP.

The absolute minimum for messaging system is the ability to reliably invoke remote actions, while guaranteeing their order. A really helpful addition is support for request-answer pattern, where a remote action may return some kind of result to its initiator. This is not required, but can make your life much easier.

Once you have your messaging, think about partitioning your server. Most probably, a single server machine will not be enough to host the game for all players. You need to carefully consider what tasks can be independent of each other, and thus can be delegated to different servers. Authentication and login is the most obvious candidate for this partitioning. Among others are statistic and rating calculations, database communication (a server to act a specialized DB cache). The problem with MMO games, as opposed to web apps, is that they tend to be highly stateful, with lots of data needed for each player. And most operations require access to all, or almost all, of this data.

Even if you use a single server, you pretty much have to take advantage of multiple processors. Any MMO server is a highly concurrent program (our current server has about 30 concurrent threads). To have any hope of solving synchronization problems, you have to isolate different threads. Like different servers, they'll have their own data, and will communicate using some kind of message-passing interface. Possibly even the same RPC that you network uses, if it's fast enough.

Then you have your database. MMO players usually do a lot of things and generate a lot of chages to the game world, that have to be saved in the database. All the servers I worked with did not save these immediately - instead, changes were accumulated in memory and then saved in bulk every 5 minutes or so. This allows the game to progress more smoothly, at the cost of possible delay when writing takes place. This delay is the main reason to have a separate machine for database communication.

Usually MMO games use relational databases as their data backend, but I believe that NoSQL databases might be better. Usually, you have a bunch of data in your DB for each character, load it all when said character logs in, and very rarely, if ever, do any complex queries. This mode of operation seems to be the forte of NoSQL. That said, I've yet to use a NoSQL DB with an actual MMO server, so I might be wrong here.

Another database-related thing I want to warn you about is this. Many developers, especially early in production cycle, are tempted to store "game-design" data in a DB. I'm talking about things like items' and NPCs' parameters, abilities, and other stuff like that. Don't do that. These things are actually static data that does not change unless there's a server update; and this data is always needed by the server. Normally, you won't be doing any queries against it except a SELECT * ... at server startup. Thus, you don't actually need a database, and having these things in a DB has a lot of drawbacks. For one, you can't put a database under source control.

These are three main components for a MMO server architecture: network communication, logic partitioning and database access. All logic using these three is probably very game-dependent. I might have some more advice if you ask more specific questions and tell us more about the game.

• I would love to get more advices from you but I can't find a way to communicate directly with you (a PM or something like that). Just don't wanna reveal insides of my game publicly. – Draiken Mar 18 '11 at 15:52
• You can reach me via email and/or googletalk at cthulhu dot within at gmail dot com. – Nevermind Mar 18 '11 at 19:40
• Although I strongly suggest you ask as much as possible here, and not in private. That way, it'd benefit more people and you'd get better answers. – Nevermind Mar 18 '11 at 19:46

You probably want to look into sockets-programming. Here's a basic introduction that will help you getting started.

Or just perform a Google search for java sockets and you'll find plenty of material.

• I have used sockets before, have used RMI, EJB and other communication ways, but the problem is not the basics of using it, it is how it SHOULD be used or why this or that way should be used. – Draiken Mar 11 '11 at 16:48
• Oh ok. I misread your question then. Sorry. – bummzack Mar 11 '11 at 17:37