Slashdot Mirror
Designing Multiplayer Game Engines?
"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."
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
Sigs are dangerous coy things
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
"Anybody who tells me I can't use a program because it's not open source, go suck on rms. I'm not interested." (LT 2004)
Sounds like the architecture you're planning is quite close to FreeCiv's. You might want to take a look at that.
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.
If you want to maximize your users, why not use java instead of c#. The syntax is really similar and the performance difference is negilable. On top of that, your users can run the app is solaris, linux, and windows. Along with that, you can build a client java app, so that users can just use IE, Mozilla or Netscape to play the game. My experience with network clients and users, is that they like to use what they're accustomed to. By embedding something into a browser you're cutting down some tech support and installation problems. The other deal is c# is not too tested and requireds special installations for Win 9x and 2000 because they don't come with it. Everybody doesn't have XP yet. I've implemented some stuff like this in java before and it works very nicely due to java's nice network libraries.
can't sleep slashdot will eat me
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
this is my sig.
Just thinking out loud, but it sounds like the client subscribes to updates from units in a particular "area" (defined however you like) and will automatically be subscribed to the "partial" or "distant" updates for adjacent areas. A client's key allows it to subscribe to exactly one area at a time.
Server side you keep a list of client subscriptions and something like the PropertyChangeListener approach from Java to simplify the updates from your units. I think any solution has these or similar elements, your implementation will depend on what C# can do for you. I don't know anything about that. I used Java links as examples , since I didn't find any C# API links out there.
Please let me know how things go, and I'm interested in feedback on my ideas from more experienced MMPG builders out there.
[-- Trust the Monkey --]
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.
Yeah, I have to agree about not using C#. You're *much* better off learning a new language on a small project for two reasons. First, the language can affect your design decisions -- a neat feature in one language might make it much "neater" to do things an a particular way. Second, it kind of sucks to be the one trying to forge the way for C# on something as performance-intensive as this. If you find out that C# has only one transparent client-server framework out, and it doesn't fit your demands (latency can jump too high or doesn't synchronize elements of your data), you're going to have to start over and write the whole thing over.
C/C++ currently have (besides the performance benefit) a far, far larger library set than C#. Heck, *Java* has a big networking library set.
Let other people live on the bleeding edge and do the bleeding. C# is proven to be solid for little pet projects -- I wouldn't currently try it for big stuff yet.
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.
Glyph Lefkowitz - Project leader, Twisted Matrix Labs
Writer, Programmer - Not a member of the TSU
Please DO NOT LISTEN to this guy.
Try supporting a large java app, with folks who may have to install JRE's, open up security settings in their browser sometimes talking to an admin before being permitted to do so, who will find ENDLESS incompatabilities between various versions, and will discover that that java does NOT look "like what they are accustomed too" and you have yourself a gargantuan support, installation and education headache the like of which you probably have only had nightmares about.
Mix that with the fact that you WILL be taking a performance hit by going to java, and the difference in performance between Java and C# is only likely to INCREASE and the technical arguement becomes even simpler. Remember that Microsoft will be droping Java support as fast as they can, do you think future IE/Windows is going to have a JVM? No chance.
Mix with the face that C# at least so far appears to be an HONEST open standard, unlike Java's endless standardize promises, which have been repeatedly broken so that the only ones who continue to defend their promises of open standards are the insane java zealots, and you have a solid business (open standards are better, safer, and do not put you on the hook to a commercial company) and even moral decision that is clear cut.
Really, writing something as sophisticated as this with a new language which neither you nor it's developers completely understand yet is a really, really bad idea. I wouldn't use C# for any major production project yet. It's not ready for it.
;-)
If you have no prior experience writing this kind of application, I'd recommend using somekind of a framework to provide you the basics. This will save you the roughly 1 billion design mistakes you are likely to make. If you were experienced with this kind of thing, I'd give you different advice. But for your first run it'd be a smart idea to learn a decent design that someone else has already done.
You could look at a few open source projects which are doing this thing. If you don't like any of them, the other thing I'd suggest is using a J2EE solution. What you're describing sounds like a good fit for a JMS-based solution, particularly using message-driven beans. The nice thing with a J2EE solution is you have a proven framework to work within that can provide you with the scalability, availability, and reliability that you need.
I'm not against reinventing the wheel, but it's best if you have some experience before you do that, otherwise you'll end up with a triangular shaped rock.
sigs are a waste of space
It's not even a connection issue, really.
TCP is a problem simply because it resends data that has lost its relevance. Simple example: client position updates.
As a client moves through your world, it needs to communicate its position to the server. If you do this with TCP and run into some lag issues or whatever, it will dutifully try to resend that data. By the time the server actually receives it, the client is (a) far from that position, and (b) already sending new position updates. This results in a variety of problems such as the "snapback" movement issue seen in Ultima Online.
In a game, TCP is good for initiating connections (esp. getting through NAT), login verification, etc. But any data which is updated rapidly, and useless after a short time frame, should be sent via UDP. Client side prediction can smooth out dropped or misordered packets.
- SEAL