Designing Multiplayer Game Engines?

mikera asks: "I'm a pretty experienced programmer but I've just embarked on my first (massively?) multiplayer strategy game. To make things even more interesting, I've decided to write it in C# and pick up a new language at the same time. I've chosen a client-server architecture where the server holds the one 'true' state of the world. The only communication from clients would be commands to units, which is simple enough, but the server will have to propagate game state changes (events) to all clients. I would like to ask Slashdot readers if they have solved a problem like this before or can offer some opinions on the best way to implement a solution."

"Lag is not really critical, but I still want things to be responsive and it must scale up well with the number of clients. The size of the map data, the complexity of the objects and bandwidth constraints rule out sending the complete game state, so only incremental updates will work. The situation is further complicated by the need to limit updates to just the areas of the map that are visible to a given player/team - this is clearly necessary to prevent client-side hacks such as gaining full map knowledge.

I understand the theory well enough, but I'm interested in practical advice on how to implement a solid architecture. What should the object model look like? How do I propagate events that are only partly within a client's field of view? Are there any novel features in C# that might make my life easier? How can I make the networking code as transparent as possible so I don't have to write SendUpdate() after every assignment?"

Your comments, insights, hints and flames are eagerly awaited."

Comments

Not doing two things at once

[peripatetic_bum]

Having been on the dev-team of a popular MMPOG, I have to say that while your ideas are fundamentally correct, but now is not the time to learn c#, just to add another language to your CV. In addition, C# is too OS limited as it stands and you need to be thinking outside the box.

Thanks

Follow the Rules of New Software Projects:

[EraseEraseMe]

First: Ignore the nay-sayers who say "Don't do it in C#"
An argument over the language it's programmed in will only make you lose time on what is truly important, the project itself.

Second: Ignore the nay-sayers who say it's too big of a project.
By the time they give you a full, thought-out reason why you can't do it, you'll be half-done.

Third: Do listen to people who have done it before.
Browse programming newsgroups, MMORPG newsgroups, hopefully one of the coders will connect and you'll be able to pick their brains.

Fourth: Don't get dragged into the open source/closed source fiasco.
You should be programming for just yourself, unless you have a team, then it's a free-for-all

Fifth: Cut yourself off from all human contact and work on it.
Stop showering, stop feeding the cat, forget the wife/kids/work. Finish it as soon as possible because I want to see what you're working on :)

Re:Follow the Rules of New Software Projects:

[rjkimble]

If you program in C# you're limiting yourself to an untested, almost unportable language and to the Microsoft platform. I would think that if you were serious enough to waste all of Slashdot's time with this question, you would be serious enough to choose a real programming language, not some Microsoft marketing scheme.

I don't think this is particularly true. For one thing, Ximian/Mono are developing their own C# compiler. They're also developing their own runtime.

Another point is that Microsoft's operating systems own 90%+ (probably more than 95%) of the home computer game market, so it hardly seems to be a limiting choice, even if the Mono project fails. And no matter how much you dislike Microsoft, I think you have to admit that their notion of a "common language runtime," which makes it rather trivial to integrate components from all the supported programming languages, is a brilliant concept. It may take Microsoft to a whole new level of domination, but that hardly makes the idea some sort of evil.

For the record, before you label me as some sort of Microsoft shill, I'd like to point out that I'm composing this response using Galeon running under Mandrake 8.1, and my company bases all its software development and web hosting on Linux, Apache, Tomcat, and Java. I'm one who believes that the main reason that Microsoft is where they are today is because they actually respond to their customers and most of their competitors behave like morons. Ever try to use Solaris without installing all the GNU versions of the standard utilities? The Sun versions are generally inferior and an outright PITA to use. Microsoft doesn't force that on Sun -- hell, they could just use the GNU versions.

Re:Follow the Rules of New Software Projects:

[Ian Bicking]

I mostly agree, except this one:

Second: Ignore the nay-sayers who say it's too big of a project.
By the time they give you a full, thought-out reason why you can't do it, you'll be half-done.

The nay-sayers are probably right here, and if you research to people who've done it before (rule 3), you'll notice the vast majority of such projects fail.

You must break a project like this into smaller pieces. You must have a forseeable point when you can release something. You can't forsee the end of a project as big as this, so you have to design intermediate points into it where you have something that is at least interesting to other developers, but much preferably is of some interest to gamers (even if only forgiving gamers).

Open Source ideals aside, it's very hard to maintain dedicated to something that only you have ever seen. Also, incremental development is just more likely to be successful.

FreeCiv

[RedWizzard]

Sounds like the architecture you're planning is quite close to FreeCiv's. You might want to take a look at that.

Re:WorldForge

[nehril]

there is an old (1999 ish) article at www.gamasutra.com/features/19990903/lincroft_01.ht m (free reg required) that talks about all the net play problems that the Xwing vs Tie Fighter team faced.

I remember reading it a while ago before you had to register, it had alot of insights as to saving game states, lag, updates, and "late joiners" to a game.

wow, don't even know where to start

[jon_c]

First off let me say that you are way in over your head, don't go into this thinking you will actually make a everquest. Everquest took 4 years to develop with a full staff of experienced programmers and artists, DAoC only took 2 years, but they had a very complete engine to work with. However i do not want to discurege you, attempting this, while foolish is a noble task where you will certainly learn a great deal. that being said:


The only communication from clients would be commands to units, which is simple enough

Generally the way this is handled is setting up a TCP communication for critical information, such as the stats of the player, text communication etc.. then send small UDP (connectionless) messages for non-critical data, such as player and monster movments. Be warry of using TCP for everything, this is something Anarchy Online did, which caused some pretty massive problems on the server side.


The situation is further complicated by the need to limit updates to just the areas of the map that are visible to a given player/team - this is clearly necessary to prevent client-side hacks such as gaining full map knowledge.


There are two approches for this, one is a moving 'buble' of information, where you update the client with all data within a certain radius, another is the zone approach (i.e. everquest) where you send the an entire zone worth of information. Note that you are not sending everything, only monster,player movment and state (are they fighting).

What should the object model look like?

I have no idea, i imagine it would be far too large and complex to even describe in a slashdot post. However i recommend you look at it from a top down view, then try implementing from the bottom up. For example, you know that you have a 'world' and the 'world has players, monsters and items', 'players and monsters' could be concedered 'actors' with certain command antributes. 'actors interact with items' etc.. you should start seeing how to construct a object model. also don't worry about what this looks like at first and you will no doubt be revising it as you go a long, make things the work and compile so you have some possitive feedback for you hard work. When things seem out of hand, step back, make some coffee and draw out what you have and try to thing of a way to break it apart into managable sections.

ok that is all, good luck.

-Jon

Re:WorldForge

[Znork]

Um, if you're working on a commercial project, be careful if you look at worldforge beyond architecture documentation, without at least talking to your legal department (or lawyer) first. WF is GPL and you are no more safe against copyright infringement suits if you copy GPL code than you would be if you got your hands on the code to EverQuest, Anarchy Online, or any other MMORPG.

Looking at code is tricky buisness. You can do it in some ways, and you're probably safe as long as you're not creating a direct competitor with a commercial product, or a work-alike of something. If you do a clean-room implementation of something there cannot be even a chance that you've seen the competitors code. If you're doing your own thing, and just glance at the code to get a basic feel for how they've done things, then write your own, different code, you can probably consider it fair use. Maybe. But it's tricky territory.

This is a lot harder than you think.

[glyph]

If you're really trying to develop a massively multiplayer game, make sure that you're ready for a collossal failure.

I can already see the debate about C# heating up over this -- but that's tangential to the real problem. It's not that C# will doom your project, it's that you wouldn't choose C# if you knew what you were doing (and your project weren't already doomed).

First, my personal suggestion (and I say this as a developer with 2 years commercial MMP development experience at this point): EITHER you want to write an infrastructure, OR you want to write a game. Writing both by yourself will take you the better part of 10 years. Having another programmer around who is doing the other part is handy -- but making sure that they are separate tasks is important. I recommend ditching C# to use Python, and my personal infrastructure project, the Twisted network framework (http://twistedmatrix.com), but if you're not going to use that, then find another high-level language with good asynchronous networking support and the ability to load code at runtime. Other good possibilities are Common Lisp and Scheme.

If you don't have any experience in the area, and this is for an Open Source project, join an existing project and learn some things from there. I can also highly recommend getting involved with a failed project in the game industry to see how difficult the whole thing really is :-)

Be prepared to fail at least once. The number of failure points in an MMP project is astronomical: client code, server code, internet latency, even the community itself is a potential "bug". If your technology is great and your game is fun, but it attracts really mean-spirited people for some reason, you might see your servers empty out over the course of a few months, or never even get to a real "massively" multiplayer state.