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."
This is true, but from an anlysis our group did,
we did find one interesting factor that could actually make make the windows-based platform not viable anymore.
The fact is that up to now, hardware, the OS software and, for the most part, games have been a pay-once/play forever deal.
With XP, this model is trying to be changed, so not only do you have to keep paying to use XP, but you can think of it as an additional cost to playing your games.
If you dont beleive, think about the Xbox. Now where does MS suggest that you will need to pay to continue to use the Xbox(for now), and that is their games development platform, thus they wisely avoided trying to charge gamers for the OS they are playing on, thus I do think that Linux does have a chance of being a gameing platform, but this is not an advantage that linux only shares, because right now, we dont pay for OS's for any gaming platform ( I mean, PS2, gamexube, etc...) we just pay for the games,
So what I am trying to say is the C# really isnt a good choce because the OS it is to written, now comes with more Costs than any other OS.
Thanks!
Sigs are dangerous coy things
Because the more information there is at the client then the easier it is to cheat.
For example
1) If the maps are client side, I can look at them and see things my opponent and the server don't think i can see.
2) If the rules are client side, I can subvert them. "Hello server, I'm now moving at 100mph and I have 3,000,000 ammo."
---
Oregon
In Java, I have played Dusk (dusk.wesowin.org) which is a basic graphical MUD style environment but seems to be okay and contain a reasonable amount of the basics. And Java is like C# in many areas except supporting reflection and other good ideas, unlike C#. I should mention WorldForge as well.
Yes, it's been done before, by freeciv
I never miss a chance to plug freeciv, because it's my favorite game, and a prime example of what good can come from programming free software.
freeciv takes the same client/server approach you're advocating, and, as near as I can tell, scales somewhat. Now, if you've got a lot of graphics going from client to server, it might not work the same. So I recommend freeciv just as a starting point.
Have fun!
Secession is the right of all sentient beings.
I'll avoid most of my comments about your choice of language because most of it is of a political nature, rather than practical one; however, I really wouldn't suggest trying to make a massively multiplayer game with a language you're unfamiliar with. It's quite an undertaking even with a language you know. I know; i'm working on one.
As for the networking code transparency, this one seems fairly obvious to me.. Just keep a datastructure containing all the changed or "tainted" objects as you go. Make mutator functions of your classes set objects as tainted. Then, just do the networking updates once or twice every time through the main loop (assuming it's in the same thread. Otherwise, you can implement something that might end up being a little more efficient).
As for updating only what the player needs to be updated on, this seems like a question of algorithm efficiency. I don't know the specifics of your game, but with most massively multiplater games, transmitting the entire world state, or even the entire list of changes to every client, every cycle would be insane. So, you have to only update the section of the world that the player can see. How to do this well depends on the internal structure of the world, and what sort of stuff the player can "see". If the game is room-based, then this is easy. If the player can always just see a specific size circle or rectangle around him, this is also easy (each event can check distance to all players in its regeon). If it works like most RTS with arbitrary viewing areas, then you might have to be a little more clever. Whether this is even much of a concern is really a question of the number of people supported, and the expected hardware this'll be running on.
Hope that helps,
ben.c
AOP might be a great way to handle the problem of dealing with the update issue. You can program as though they are on the same box and code your aspects to deal with what to send and when. It's not an easy thing to learn (think when you went from procedural to OOP) but it can pay huge dividends.
I use AspectJ (www.aspectj.org) but that's for Java...I don't know of any AOP toolkits available for C# since it's such a new language.
Good luck.
"All I ask is for a chance to prove that money can't make me happy."
Divide the map up into areas where you want all users to access the same things. Use a broadcast message to send mass updates to this. This cuts down individual client updates. Say there is an earthquake or something in the game. Broadcast this data to all those that affected in one big message. Java has features for this although I'm sure c# does also.
can't sleep slashdot will eat me
Who cares if it's OS Limited? He wants to use C# and target the usual 90% of the market.
Use the BEST tools available for the project you are designing. Anyone who tries to tell you otherwise has no concept of proper development.
If you've never written a client-server game at all, you might check out Netrek for some basic ideas. It isn't massive, but it is client-server, and it's where I learned most of the important things I know about network programming in general (and I do, in fact, get paid to write network code for games now.) Quake or Quake 2 source are probably also good things to look at, though I haven't seen their code personally.
None of those solve the major problems you're really asking about though: how to decide who gets to know about what. Worldforge is the only open source project I can think of to point you to in that area. Perhaps some MUDs might be useful as well, but they tend to be based on rooms, not areas, which doesn't translate well at all to most other games.
Probably the biggest problem is avoiding N^2 operations as much as possible. At some level, there's no way around it: N players in an area generate events that have to be propagated back out to N (or at least N-1) players. This obiously makes scaling to arbitrarily large populations difficult. On the other hand, if you can guarantee a set maximum number of players in an area/server/whatever, you can target that maximum and not worry about it a whole lot.
A slashdot post isn't really the right medium to answer this question. There aren't any quick and easy answers, you need to figure out what makes sense for your game on your own. I've spent a large portion of the last year thinking about these problems myself, and I wish you the best of luck on it. I'm having a blast myself, but it's also the most challenging work I've ever done.
I am interested in hearing your reasons for using C#. That's actually somewhat shocking, but maybe it's just ignorance on my part. I can't imagine why you'd want to bet the farm on such an immature system, regardless of the strengths you've perceived in it. What does it do for you that C++ doesn't, and is it really worth it?
It sounds like you're taking a lot of the stuff off the client's hands to add security. While this is a good idea, I can't stress enough the importance of the client predicting the positions of players and objects. Objects especially are easy to predict (an arrow arcing through the air, something rolling, etc.) Movement prediction can make or break a game; you'd be surprised how little tolerance players have for people/things jumping around with no movement in between.
Heck, players can be pretty predictable objects themselves, if you want to get fancy. Most games have pretty simple algorithms predicting the future state of a player character (if player X is moving in a straight line, he'll probably continue to do so.) But I think you can get fancier than that. What about curves? (circle strafing) Or if the player is repeatedly hitting a button every half-second. (chopping wood?)
It'd take a lot of coding, but the master server could conceivably take note of each player's input characteristics and compile some sort of "personality" profile for each one, which it could transmit to clients every time they start up, to help with their local prediction.
Please note that I have no idea how much CPU time this would take up,
[PowerPoint] is a tool for capitalist presentation
having one "master state" will be hard to scale. Make different states for different "zones" (either physical as on a map, or having to do with aspects of the game), and then you can delegate zones (or subzones) to other machines. Do this also for object-classes (player attribute state may be separate from object state, separate from location states, etc.) so that different subsystems can be independently optimized. A cluster of master META routers can glue these parallel states together to provide a single entry point and consistency. Round robin DNS would be sufficient in most cases (esp if using UDP or persistent (stateful) TCP).
Obviously, until things ramp up, you should be able to do all this with one server, but making these parallel states will make scaling much easier when the need arises.
----- Refactoring is the reason why man does not mistake himself for a god.
In all seriousness, in my opinion (unless you're doing this solely as a personal learning experience), you are starting with two critical strikes:
1. You're trying to do a major project in a language you don't know (and an immature one at that).
2. You're trying to do a major project in a genre with which you have no experience.
Either one could cripple the project. Put them both together and you're doomed before you start. You may eventually make it work - sort of - but it will never work well, and it will be riddled with bugs.
I encourage you to start by developing a small multi-player game in a language in which you are already proficient. This will let you focus on the design and structure without fighting the language. Keep it simple, manage the scale, but incorporate the kinds of capabilities you want in the final version.
When you've got that working, throw it awy and develop it again in C#. Since you're starting with a working design , you're now free to focus on the mechanics of the language. You need time to learn its limitations and idiosyncracies, and to become proficient. (I will let others debate the wisdom of C# - I'm skeptical of all proprietary languages, especially until they're field-proven.)
Once you have succesfully finished a small project in C#, you can begin planning your real game. Based on your experiences, you may decide to scrap C# entirely. If you choose to stick with C#, then throw away ALL of your original code and start over. No matter how good you think your first code was, by the time you finish the big project you will know that it's crap. Might as well get it out of the way up front to reduce re-work and improve the overall quality.
Of course, if this is a project you've been assigned as a commercial effort, you won't be given the luxury of doing it well. You probably already have a deadline pulled out of thin air, and you're probably already behind schedule. Speaking as a pointy-haired boss who actually has significant coding experience (a long time ago, in a galaxy ... etc.), most PHB's have no clue when it comes to software development. They work with the suits to draw up pretty little Gantt charts, and haven't the foggiest notion as to why they are complete fantasies. You can see some of the results in the bargain bin of your local Best Buy, or in the "still delayed" list of your favorite gaming magazine.
In any case, good luck.
Assuming you have a secure communication channel (whether it be trust, PKI, or other encryption), you can try to reduce lag by distributing resource request and allocation.
Rather than the server handling 100 clients, when it needs to push out identical data to all 100, you push out data to 10 of those clients and rely on those 10 clients to push out data to another 9 clients.
You can also push in the other direction. When client 1/100 says 'Hi!', rather than pushing it to the server to push it to 100 clients, the client pushes it to the client he's attached to, who pushes it out to the other 8 people, as well as to the server. The server then pushes the 'Hi' out to the other 9 clients it's connected to, who pushes out to their respective 9 clients.
It's akin to treating the connection to the server as some sort of nested tree; you introduce latency but reduce the amount of server lag.
GPL Deconstructed
...except you can substitute Ruby for C#.
Our Documentation Index page gives a basic list of the areas we have documented. The General Philosophy describes our philosophical outlook, while Core Concepts describe the main ideas which are needed to understand coding FaerieMUD. Our engine is based on the same Design Patterns you're describing. It is open source and is basically finished and tested.
The game engine is known as "The MUES Engine" (pronounced "muse") for Multi-User Environment Server because it allows many users to simultaneously interact with one or more environments each being served by one or more servers. When MUES is being used for serving MMORPGs or MUDs, the environments are usually called "worlds" but MUES does not make any assumptions about their nature. They can be chat rooms or workgroups for collaboration or whatever.
The MUES code is pretty well documented, so you may even be able to use it as pseudocode. (For that matter, it may be possible to use it in Ruby since it doesn't make assumptions about how the objects which are served to it are created.)
Good luck, and let us know if any of your ideas look like they'd help us.
All of which should not be taken as disagreeing about any of the other advice to look at WorldForge or MUDdev lists or whatever.
Eternal vigilance only works if you look in every direction.
While I'm not sure what kind of strategy game you're doing, but if you're planning to make it scale well it's going to be a lot of HARD work. There're a lot of issues to tackle - server load balancing, bandwidth mixing and dead reckoning. If you're considering what features to build, look at the API provided by RTime www.rtimeinc.com. I find their model pretty comprehensive.
Normally I dont responf to AC's but the fallacy in his thinking needs to be pointed out
Windows service packs are released for free
So no need to upgrade just to play
1. Ms has made it quite clear that they wanted people to pay for XP as a subscription model.
2. There is no early reason why they would make the claim that the "value" you get for your subscription money is an up-to-date system which includes bug! The point is that they dont feel that they should continue to their software for free.
3. That means, that You will no longer get service packs for free as these can be viewed as Service Pack upgrade or even a NEW VERSION, the point being that you will need to pay
4. The other point, that MS has back off from, for the time being, is that they want software to be time-limited, which is to say that if you dont pay a subscription fee, then you no longer have the right to use the software, ie, in another words MS has clearly stated they want to change the way people view software from being views as a buy once commidity to something like Cable Tv in which you pay every month, and if you dont pay, you dont Watch, ie you cant play your games on their OS.
Sorry for being so long
Sigs are dangerous coy things
How crap like this get's modded up at all is beyond me.
.NET platform - although new - is extremely robust. Of course, in order to find this out you would have to do research and gather actual scientific data. Remember Boycott Adobe? Well the entire e-commerce portion (for buying T-Shirts, etc.) was run off of a BETA version of .NET. Verizon powers 80%+ of their "Trouble Ticket and Project Management" intranet tools for thousands of users on their Intranet using .NET. They launched on the Beta2 platform in September. Microsoft has converted many of it's internal and external sites over the past year. For example, shopping.msn.com runs on .NET. You may not like MS, but you can't argue the fact that they generate the most traffic on the Internet second to AOL/TW. When MS uses a technology for their systems, it's a powerful case stude in and of itself.
If you program in C# you're limiting yourself to an untested, almost unportable language and to the Microsoft platform.
I thought this was "news for nerds". You know, people who are generally scientific. First, even C++ is not "portable" in the sense that many of the libraries that make any project worth working on are not cross-platform by any means. Second, your belief that Microsoft Is Bad(tm) is Offtopic to this discussion. Third, the
Hey, thanks for the plug. Here's an open letter to developers about my new project, Netsu. It uses Python, the Nebula Device, *and* Twisted...
:-)
Greetings,
I'm a professional game developer who has committed a large portion of his adult life working on virtual worlds of one sort of another. Recently, I worked on Ultima Online 2, which some of you may have been looking forward to playing. I know I was!
I'd like to talk to you a bit about my current project, 'Netsu', which is the culmination of many years of background work. "Netsu", Japanese for "heat" and "fever", is an anime-inspired world which incorporates multiple perspectives of play and a reputation network for players to self-organize. It's going to be fun.
Currently, I'm working on combining a number of existing open source technologies to build the new virtual world system. These include the 'Nebula Device' 3D engine from Radon Labs on the client side, the Twisted framework for server-side and client-server communication, and (as the project moves forward) the OpenCyc knowledge base as server-side archetype repository and artificial intelligence server.
As I develop use cases and other design documentation for Netsu, I intend to keep them as portable as possible between gaming systems, so that they can benefit the most people. I anticipate this work feeding back into Twisted, expanding it to be a more general simulation framework, and into Nebula, adding network support and in-game world editing tools.
So where did this project come from?
The genesis of the project began with my work on virtual reality systems in the early 90's. I developed virtual building walkthroughs for architects, VR games, and created the first hardware accelerated PC-based virtual actor system for Compaq.
This work was all done with C and C++, and it was during this period that I ran up against the need for a dynamic and interactive way to "reach inside" the simulation and manipulate the code and data directly. And that's how I first became acquainted with the language Python.
The next major phase was to build a 3D client engine with Python embedded as a control language. The fruits of that effort are described in the paper I presented at Python 7, "Beyond: A Portable Virtual World Simulation Framework". (This was also the first mention of 'Netsu'.)
In 1998, the path of development took a turn when I was recruited into Origin Systems to work on developing the Python foundation for the Ultima Online 2 project. The focus during the period was on innovation on the server side and on client-server communication. The results of that labor are described in another paper presented at Python 9, "Python for Massively Multiplayer Virtual Worlds".
Both papers are here.
However, to this point, all the software developed for these projects was closed source. The desire for an open source virtual world system was lurking in my head, but it wasn't until the O'Reilly Open Source conference in 2000 that my plan for the open source virtual world crystallized.
At the 2001 O'Reilly conference, while presenting on the UO2 design work, I took the opportunity to discuss my plans for the future open source virtual world system. The response was extremely positive.
So what are next steps to realizing this goal?
Glyph (the originator of the Twisted project and a fellow ex-Origin colleague) and I have been meeting periodically over the last few months to discuss these issues, which intersect nicely with his long term plans for gaming in Twisted. I've also been meeting with the Cycorp folks (who happen to office just down the road from me) to discuss integrating Cyc and driving Python class generation from Cyc.
I recently integrated Python into the Nebula Device, which allowed me to easily integrate the PB remote object communication protocol and made Nebula the first 3D clients for Twisted. Over the next six months, several major components will come online, including character creation, character motion, the GUI system, basic terrain management, character inventory, and combat.
As I wrap up my current consulting project (porting Python to the Playstation 2 and developing a GUI for designers to build Python logic), I'm devoting 100% of my time to Netsu and open source development.
It is my hope that this collaborative approach for virtual world development grows, spreading outward and providing a foundation to help other developers build their own virtual worlds and enable the sharing of code and art resources between worlds..
If you are interesting in finding out more about the project, drop me a line via email and tell me a bit about your interests and background.
Cheers,
Jason Asbahr
jason@asbahr.com
It runs just fine on my Windows.
It always looks and feels awkward, and never 'fits in' the platform it runs on.
Eh? What are you talking about?
* It doesn't seem to really be that 'portable' in the sense that Java programs often seem to work in unexpected ways on different platforms
Having written server software in Java for the past 3 years can't say I've really seen this. I'm still amazed by the fact that I can drop my binaries on the occasional Linux or Solaris box and it just works. It's definately more portable than anything else I've worked with. Most often portability comes down to the experience of the programmer. Java doesn't prevent a newbie from being stupid and screw up portability.
* He can probably compile C# down to any platform he wants to, as Linux seems to have C# compilation support, and other platforms will probably have this soon.
It's not the language thats important, its the libraries. Java has them, C# doesn't have them outside the Win32 platform.
It becomes an issue when the game is run on the SERVER.
Here is a very in-depth look at the networking model for StarSeige: Tribes and Tribes2. It is written by Mark Frohnmayer and Tim Gift, who kinda wrote the thing. It goes into great detail about all the things you're going to have to think about, including construction of the stream layer, the perception of real-time play, preemptive client prediction, etc. A must-read if you're thinking about programming this kind of thing.
You might also want to check out GarageGames for some other game development resources.
-3Suns
~~~~
The Revolution will be Slashdotted
It always looks and feels awkward, and never 'fits in' the platform it runs on.
What you are talking about 'Looks and Feels' is the auto-rearrangement of GUI widgets with some 'Layout' supports. The 'Layout' support is designed from the ground up for cross-platform, such that the GUI widget adjust themselves for different constraints like windows and screen sizes.
Few other language offers such a cross-platform convenient. You can place the widgets pixel-by-pixel in java if you like, but it hurts the portability.
I studied C# a great deal before giving comments on the comparison. My observation is that C# almost has one-to-one mapping of the syntax of Java, some are so un-innovative that adding an 'i' before the keywords. It seems to me another 'embrace and extend' practice.
Of course, I didn't mean C# is a bad language. Doing something based on existing successes would at least yield something good, so I always keep an eye on C#.
A few comments about your post...
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.
If you need a JRE, include one with the game installer.
If you do not know how to change security settings in the browser, then use the regular version. If you have an 'admin', you should probably not be playing a game (at work? at school?).
If you include a version of the Sun JRE that your product works with, then your product will work.
I do not see how java can be 'what they are accustomed to' or not. 99.99% of games have a custom UI anyway. Java apps can be double-clicked on. What is the issue here?
You will be taking a performance hit going to java. Most of a game's speed depends on the video card. It is hard to max out a modern CPU. With a JIT compiler (or a native compiler, if you so desire), you can eliminate most of the speed hit.
C# appears to be an honest open standard created by a company that has historically proven that they have no interest in keeping interoperability any longer than it takes to lock in developers. They will undoubtedly come up with 'extensions' that will make life, if not impossible, then at least difficult for any non-MS users/developers.
I would go with Sun's stupidity over MS's malice any day of the week. At least I know Sun isn't -trying- to screw me over.
--Dan
This is actually very interesting to me...
You could basically write a game that put a display up on multiple X terminals. This would have multiple views into the same world and allow multiple keyboard and mouse inputs to that world. The server system and network would have to be very fast to support this game. It is practically impossible to cheat with this setup too.
The other end of the spectrum would have the game distributed onto each machine, with all updates from every machine being multicast to every other client at the same time. This would allow each client system to distribute part of the load of the game and its display across the network. You would need a very fast network for this.
In between these two extremes is a central server that has clients connect to the server. The best way to distribute the work on this system is to look at what needs to be done. The local system will render the view and play the sounds. It will need to send it's mouse and control movements to the central server. The central server will look at all the inputs and send back update information to all the clients.
It can also be slowly uploading the information it will need for the next level while you are playing the current level. You may also have an encrypted CD at each client that can only read the information when the server gives it a valid key. The key is not cached. You may also want to authenticate that the client is valid by performing a checksum on some portion of the system in memory and returning that to the server.
This way the rules are all on the server, so cheating will be at a minimum. But they will have all the map data, so a hacked client may give them more info than the other players have.
The next step is to also download the rules to the clients at game time and let the clients decide what is happening for themselves, then send an update to the main server which just distributes the info to the other clients on a need to know basis. This would eliminate all mouse and keyboard data uploads.
But having modified clients that allow cheating could be bad. You can minimize this by providing stripped binaries that authenticate to the server, but a determined cracker can get around that.
-- Never make a general statement.