ty for your replay:)

Thanks for your question. In the pattern I described, the world server is kind of a coordinator that manages which maps should run on a given area server and keeps track of which maps players are on. In short, the world server would be involved in anything that requires coordination of interactions between maps. The details of this are game-specific, of course, so it’s hard to generalize.

I would recommend against following this pattern in general, as implementing the cross-map interactions is very complex, difficult to get right, and hard to test. The return on investment is not great, in my opinion, and you would be better served to design your game to avoid the need for a “seamless world” as described here. Remember, the goal is to create an engaging and fun experience for players, and there are many ways to do that.

For example, if you really want grand vistas, then look for ways to simulate that on the client. Also, consider limiting the number of players/NPCs that any one client would encounter on a single map at one time to keep the load manageable. Or, consider using the Responsibility-Oriented Game Server pattern. That approach is also complex, but the return on investment is much better in general.

Good job, I like this page

Thanks for your question!

First, there are no stupid questions! 🙂

Because this article describes a pattern, the inter-server communication is really “just” an implementation detail (but of course, the Devil is in the details they say).

On the project I worked on that used this pattern, all inter-server comms was via proprietary messages over TCP, so basically sockets. We had a custom directory server that managed initial connections, but after that connections were peer-to-peer between servers. Yes, it could get pretty hairy.

The main reason for the peer-to-peer connections was to minimize latency. For distributed architectures that require low latency, that’s probably still necessary. However, these days I would hope such an architecture would make use of existing distributed computing tech and/or patterns to mitigate complexity.

Hope this helps, Matt

Thanks for your question. Yes, I know, you wrote me months ago and I’m only just now replying. Sorry about that. I suck, obviously. 🙂

To be honest, I procrastinated on this reply partly because it’s hard to answer. These days there are many resources available for learning general game development concepts. I’ve never seen anything described as a “road map” for game server or back-end game development. A general lack of information is one of the reasons I started this blog (and yes, we already know that I suck for not keeping it updated :P).

Multiplayer game development involves many disciplines and/or skill sets. You can slice and dice them many ways. Here’s one way:

• Graphics (representing the game “world” in 2D or 3D)
• Audio (music, speech, sound effects)
• User Interface (input control, camera control, text display and input, buttons, widgets, and the like)
• Physics (objects colliding and moving in a simulated world)
• AI (NPCs, computer opponents)
• Gameplay (rules, game mechanics, interactive objects, missions, systems, and more)
• Networking (processes communicating with each other, e.g. client-server and server-server)
• Concurrent Programming (performing multiple operations in parallel)
• Databases (storage and retrieval of game state and/or game content)
• Distributed Computing (multiple processes working together)
• Content Tools and Asset Pipeline (transforming art, audio, and game design content into a form used by the game)

I didn’t mention “Client” or “Server” above, because most of these appear in some form in both client and server. There is also a lot of overlap between them. Generally speaking, everything except for graphics, audio, and UI play a part in back-end development. There’s a lot to choose from there.

At a minimum, to do back-end game development on any “real” project, you should probably learn something about:

• Networking
• Concurrent Programming
• Databases
• Distributed Computing

Note that those topics have nothing to do with game development per se, and apply to many computing disciplines. That means you have even more options for learning and getting good with them. The good news is that, with solid skills in these areas, you can be valuable to a game project even with minimal game dev experience. That’s how I got started in game dev after a few years of working in “traditional” development.

In addition, you should get experience with writing game play code for the types of games you like to play or want to work on. As I said earlier, there are already great resources for this stuff all over the web. It’s probably best to try writing some simple games yourself, or join an open source or mod project if you can.
Be warned that writing multiplayer code will make any game project take 10 times longer than a comparable single-player project.

I would start with something simple to get a basic understanding of game play programming first (e.g. finite state machines, game object interactions, event handling, and the like). Then, add in things like AI, physics, and other challenging stuff. Finally, apply those concepts in a new multiplayer game project. NOTE: I also don’t recommend taking a single-player game and making it multiplayer. That way lies dragons.

So, in summary:

Get good at general back-end development that can be used anywhere.
Get good at general game play concepts.
Then combine the two in a mix you feel comfortable with.

I’m sorry I don’t have anything more specific, but I hope this helps a little.

Cheers, and feel free to ask more questions… if you have the patience. 🙂

Thanks for your comments! I’ve still got plans to resume posting to this blog, a few articles started, and many more on a TODO list. I think I’ll get there, but right now I’m mostly heads down coding and debugging. Cheers.

Hello,

WoW used to use sharding techniques. But after the Expansion Wotlk they changed the architecture completely.
In newer versions, when a player enters a zone, he get’s automatically to a zone with players from other servers (so unpopular zones don’t look so empty). Basically the only left restrictions of realms are, that they from a closed economy, it is not possible to trade items of value with other realms, even when you meet them.
Thats really interesting in my opinion, as there was only a concept of completely isolated realms planned, but Blizzard changed in step-by-step (Battlegrounds shared in vanilla, Instances shared @ beginning Wotlk and Zones shared @ end of Wotlk).
I think if they had known that they changed it this way, they wouldn’t have introduced different realms in the first place.

I look forward to see more articles from you, like grid systems or how internal communication between servers could work. A nice article would also be, to describe the techniques used at a particular game. So I hope you start writing again.

Cheers