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."
Holy Mac has the transparent networking architecture in a C# framework. It should work well for what you're trying.
worldforge
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
Take a look at The WorldForge Project. You probably won't learn more anywhere else.
~shiny
WILL HACK FOR $$$
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)
Wakeup, most people are using KDE
nt
the mudd developer mailing list is an excellent source of information on exactly this sort of topic... although not specifically regarding the STRATEGY portion of online gaming... most of the issues you have spoken of have already been resolved... take a look at the archives publicly available at https://www.kanga.nu/lists/listinfo/mud-dev
Java's really slow. Point?
Y2K Compliant since the late 1890s
WorldForge is the first thing that should be considered in a discussion on this topic...
I think there is a problem with the first link in your post. I clicked on it, and I was presented with an image of a giant, well-lubricated anus.
This is why there are companies like There.com. Their job is to create multiplayer game engines solving such networking issues. They do not create the graphics or the game logic, just the multiplayer/networking part that you can then use as a drop-in solution to your game or other application.
The WorldForge project is a very interesting site. They have all the sources to their clients/servers available. You should find some useful information there.
Check out WorldForge, an open-source MMORPG project. Nothing like seeing the principles in action!
"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.
Call me weird (or a troll if you must), but I always thought the fun of programming was figuring out the problems yourself.
"hey man got a light?"
If your chosen programming language can send commands over UDP, why not have the game hold the necessary maps and rules client side. When logging in, it can download and changes or mods from the last time. When sending commands and what not to the client, you could send just small packets of information that would then produce the map changes at the client.
This would support active real-time events over large client populations.
You may want to consider Java using RMI, Java is more road tested for distributed applications than C# and the RMI library would help raise the abstraction level for the network programming. Bruce Eckel puts out a good intro book (also on-line) for Java if you don't know Java and O'Reilly puts out a decent RMI book.
Also consider that Java would allow instant support to all Windows, Mac, Linux, and Unix platforms--a real benifit I think.
Good Luck
WorldForge is the first thing that should be considered on this topic...
Sounds like the architecture you're planning is quite close to FreeCiv's. You might want to take a look at that.
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
Hey, let's give karma points to a logged-in poster, not an AC...
Multi player has always been a bugbear, but I'd recommend setting up a merc or diku (if you really want to learn important lessons :) mud and cut your teeth there. Take the advantage of learning to manage other coders who pitch in and checkin/checkout code. FWIW I'd start in c and skip c++ unless I was convinced I needed it.
A feeling of having made the same mistake before: Deja Foobar
Can someone please explain to me what this post was supposed to mean?
Back in '97 I did the exact same thing in Perl. It was actually a multiuser accounting package, but the principals are the same.
By blasting debits, the accountants could increase the net value of the company. If they missed, the debit's could rip through the balance sheet of the company...rendering it's offshore shields useless. If that happened a few two many time, it could spin the whole company into bankrupcy and court-ordered liquidation.
I found that the biggest problem was latency. I worked on some time compensation algo's, but I didn't get a chance before I was right-sized by the company.
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
I only wonder if you know the difference between a monolithic kernel and a microkernel.
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."
What an annoying site. Won't display anything if you're using WebWasher to block banner ads, it just says "WebWasher not allowed".
Just FYI if you're using WebWasher, in the "Proxy Engine" section of the options, turn on "No identification as WebWasher with server", and you'll be let straight in.
What's the sense in blocking WebWasher? If you block people, people aren't going to see your ads anyway, the people blocking them are exactly the people who aren't going to click on them anyway. And especially as WebWasher has an option to hide itself!
C# is slower
Microsoft massacres you to small fragments with its EULA.
Microsoft massacres you to small fragments with its Memory Exception error.
Microsoft massacres you to small fragments with its BSOD.
Your server is DEAD!!
<
A feeling of having made the same mistake before: Deja Foobar
Java is slow as a GUI, but the networking and all the other plumbing you'd need for that game would be fast enough. Java's standard API is incredible, and if I was going to write a big honking game program, I know what I'd write it in.
Do the server in Java, do a client in Java, and let some other sucker do a native client if they want one.
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
I'll be looking forward to the Mac version.
http://en.wikipedia.org/wiki/2004_U.S._Election_c
Of course I do. Richard Stallman uses his tiny, withered MICROKERNEL in that failed TURD project of his. Linus is the one who likes to muck everything up by poking his MONOLITHIC KERNEL in people's faces when they least expect it.
. . . Stop me before I post again!
(Still BANNED.)
If your game will be deterministic, why don't you handle visible sub-world state changing events on clients? Then the server has to supply states of the world only when a new player starts to interact a new sub-world.
Gentlemen, you can't fight in here, this is the War Room!
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
Dear Reader,
You will likely recieve a bewildering variety of responses to your question on this forum, and nearly all of them will be completely worthless.
Thankyou.
goatsex is less offensive
...the server part in C# and not the client UI in C#. .NETs network technolgies. Exactly what you need.
If so, look at the terrarium code (slated for public release in mid Feb. 2002). Terrarium is basically a multiplayer peer to peer game which showcases
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?
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.
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.
Maybe I've had too many pre-game brewskis.
-- @rjamestaylor on Ello
"can't call that justice, if it's just a stupid excuse to fight, single out and attack the ones who've got no defense, you call that a new way of thinking, i call it regression to ignorance"
that's stupid, no it's not! Slower, perhaps, than say, straight C, but who cares?
On a celery 400mhz, limewire, for example, runs fast enough to not feel slow.
If the original poster who posted the question decides not to use java, then at least I would hope he wouldn't use c#. Does c# have features so vastly cool and ahead of other languages, that it would be chosen knowing the limited platforms available?
What's that, most desktops, you say?? Well, when handhelds and other devices become more widespread, wouldn't it be cool to have the game on them as well, with minimal fuss? What about consoles, which seem to be trending towards online-ness, really really this time - only one out of the bunch supports microsoft...this is potentially a bigger market than desktops. Handhelds seem to be comming out left and right, some with their own OS, some with Linux, some with Microsoft...point is on these 'other' types of computers, microsoft does not a monopoly have.
Think about it! Oh yeah, and all the stuff about making deals with the devil, the monopoly stuff, yadah yadah yadah, etc.
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 --]
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
The game engine runs on the server, not the client. The client can use whatever language to interface to the server (even Java). The only time your support issues would be relevant, would be if you were supporting licensees of your server code. You can then charge for this..
fucking CmdrQueer-supporting anti-troll karma whores.
Why do i have to go to the bottom left corner in Windows to get to my "Start" Button, why do i have the go to the bottom left for the KDE equivalent? - same with Gnome? With Windowmaker, you put things where you want them, your "Start" menu is just a right-click away... wherever you are.
So, for my 2 cents... try WindowMaker, you'll like it.
I've seen a java client for a MMORPG. It was cute in a Commodore 64 kind of way.
There were about 800 players on line.....
Stuff like "How can I make the networking code as transparent as possible so I don't have to write SendUpdate() after every assignment?" we can't answer. I mean, it's all events, and there are hundreds of ways to write this. There are countless examples. GUIs are event driven, for example.
A long time ago I wrote a multi-user game. It wasn't anything fancy, but it did the basics of what you are trying to do. It turned out that calling SendUpdate() wasn't the problem -- that's easily done with proper design (inheritance, etc). Heck, you can encapsulate the whole message in a class and let the constructor/destructor take care of it, if you want... The main problem was scheduling time to clients, especially when one client was slower than another. For example, it would be unfair for a fast client to send 10 move messages in the same time that a slow client would send one.
Another distinction you need to figure out is what needs to be real-time and what doesn't. For example, if the program supports inter-user messaging, you can implement "soon-enough" delivery rather than "just-in-time" delivery. It all depends what it is used for. That can be done with a MQ type setup rather than a real-time connection, and it can be sent from client directly to another client.
I wish I could work on such a project again.. open sourced, closed source, I don't care, just not commercial. But the internet is littered with the graves of abandoned open sourced programs, which tells me a little about how much commitment people are willing to put into these things.
Use the Jabber protocol for client <-> server communications, or even server <-> communications. You even get chat for free, then, and you could potentially use a standard Jabber client to inspect the server's state, and send administrative commands. All communications are in XML, so it's easy to see what's going on, and there's fewer endianness problems (even if it's more chatty). You can probably use SOAP or XMLRPC via Jabber.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I replied to a 0 score AC post so for those who don't read replies to posts below their threshold, here's my comment . I posted more important info and quite a few good links there. Enjoy.
~shiny
WILL HACK FOR $$$
I made a 3d game engine and in my cleverness, I figured I'd reduce load on the server by offloading the physics asynchronously onto the clients. I learned the hard way that THIS WONT WORK. The reason is that different floating point processors get slightly different answers in some instances. Indeed, if all processors are the same stepping of the same intel processor, you'll be fine, however for example an Athlon might in some rare circumstance be different by the very last decimal point from an Intel. The butterfly effect will eventually catch up to you and the Athlon machine will for example detect a collision where the intels didn't.
Using emulation or fixed point is either too slow or too inaccurate, so I ended up just doing all the work on the server and doing continual sychronization.
To be more precise, in order to smooth out 'lag' time, the clients would do their own emulation, but would resychronize all decisions on the 'heartbeat'. Using interpolation, this worked out to have great apparent lag response, even lag times of 3 seconds were smoothed out. The only problem then was when a client's lag was unstable, fluctuating a lot. I smoothed this out by emulating a 1 second lag in all circumstance, so everyone has a smoothed out lag response which isn't too bad to play. Only unstable lag of 2 seconds or more caused a problem, where that client would see his character jump around everytime synchronization kicked in.
Basically, I've broken it down into 5 objects: Game, Map, Sector, Player and Item. The ownership relationships are as follows: Game owns one or more Maps, and zero or more Players. Map owns one or more Sectors. Player owns zero or more Items.
There are three subclasses of items so far: Trivial (like swords and onions), Units (like tanks and horses), and Charactors [sic] (like Mario or Frodo). There are also interfaces for the items such as Movable and Jumpable.
Check out Metagame-Sector if this model interests you.
The only remaining issue is what we call "who is right?" If one game claims that a ship blew up because it was hit by shot, and another game claims that the ship dodged at the last minute, who is right? If the game is client-server, the answer is easy: the server is always right. In fact, clients shouldn't even display "big" events like a ship blowing up until it has confirmation from the server that that is what really happened. (Sometimes it's a good idea to use "hint" animations - if the client expects that a ship has been hit and is going to explode, but hasn't received confirmation from the server yet, you might want to show a shower of sparks. Then, if the confirmation is received a moment later, the explosition doesn't seem to be delayed quite so much.)
In peer-to-peer, things get much tougher. In some cases one of the peers simply declares itself a server, in which case you have the situation above. In true peer-to-peer, it's simply up to the game designers. The most obvious choice is to make each machine responisble for its own position as well as the position of the objects its has created. So the player controlling a given ship has the last say on where that ship was at any given moment.
In some cases, you may find that certain game elements (especially if it is an action game) don't work very well when you have to deal with 100ms or more of delay on network traffic. In that case you may want to remove or change those elements. You should pick a number where represents your "maximum" allowable delay, based on whether your target audience is modem users or not.
Wired did a story on Designing Multiplayer Game Engines back in June.
I just heard some sad news on talk radio - Genocidal and cannibalistic former dictator Idi Amin was found dead in his Saudi Arabian home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to tyranny and despotism. Truly a Ugandan icon.
You obviously are paid by Microslop Craporation
for spreading false information about GNU/
Linux.
Please return to your sugar daddy.
Oh shut up and stop bashing Windows. Most people use it because we don't want to have to bother with all the extrenuous complexities of Linux, we just want to use our computers. Furthermore, making games cross-platform is hardly an issue with 90% of PC users running some version of Windows.
I'm not bashing Linux here. I just think it has it's place. Linux is not a desktop OS, and I doubt it ever will be fully accepted as one. On the other hand, you can't beat it when it comes to servers and routers as I can personally attest (I'm building my own Linux box for routing duties.)
Of course, you would need to install a nationwide/worldwide network of these multicasting servers, which would be costly. But really reduce the bandwidth of sending "Verati has been killed by a Golem" to 10384 people simultaneously. However, at that level, you don't want to swamp your clients with those messages, so you would try and make things local - the player can only interact with things within a certain radius of their being (i.e., divide the game area into cells like a mobile GSM network, then only communicate with your cell and adjoining cells)...
I am a writer who constructs abstract representations of unfamiliar realities, worlds that I desire to contain into a multiplayer role playing game. Unfort, I am not a programmer. I am a world creator, from words and mind and want to be part of creating something that is unlike anything previous to it. Something that has an effect on the human mind in almost questionable ways. Also, as a music composer I am wondering how to go about trying to sell my compositional services to a game company?
d. Taylor Singletary,
reality technician techra.el
You might like to investigate Unreal's network architecture for ideas.
If you want a successful project, choose solid, mature implementations of equally mature programming languges.
:)
You could succeed anyway, but then you could be a successful pianist with three missing fingers too. That doesn't mean you want to deliberately chop off three fingers.
I hope this is the long awaited MMORPG version of River City Ransom. If so, may I offer you my services as producer?
(-1, Raw and Uncut is the only way to read)
Do you a favor, use ansi C!
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.
I know that suggesting a different programming language usually gets the same kind of reception that suggesting swapping underwear would, but why not consider writing it in Ada 95?
The learning slope will be very steep at first, but once you get the hang of it it will pay off in spades. Ada is a software engineering language, and it makes you do a good bit more thinking before you start spilling code, but over the long haul you end up spending most of your time in the think-program cycle rather than in the more popular but IMO less satisfying program-debug cycle.
Pros:
- Ada is designed for large software projects.
- Bullet-proof against buffer overflows and such.
- Supported by GVD (the visual version of gdb).
- Very strong portability properties.
- Supports both high-level and low-level programming. (OO, generics, etc. all the way down to in-line machine code. But all are optional; you can write simple code when that's what the problem calls for.)
- Built-in support for multitasking and distributed computing, if you want it. (And distributed might be the way to go for a big-game server.)
- If you need a GUI there are thick bindings for GTK+, portable between UNIX and Windows. These bindings are OO, so you can create custom widgets by inheritance.
- Everything mentioned above is available for free.
Cons:Sheesh, evil *and* a jerk. -- Jade
Product Placement in Video Games? Designing Multiplayer Game Engines?
looks like someone's gonna write up a game proposal...
If you want your server to scale then you should probably consider plain old C. Maybe C++ if you if you are bent that way. I would suggest (flamebait, I know) that no other language will give you the goods that you may find yourself needing. Build it on a BSD/Linux PC but then suddenly find this baby needs to run on an Ultrasparc, and C will be your friend. Build it in C# and try to get a bunch of little machines to do the work of one good one i.e. you could be screwed.
One offtopic word of warning. Do not allow the clients to send data to each other. Ever. Dont take that shortcut. Otherwise the cheaters will ruin whatever you build.
I think you underestimate just how much I just dont care.
you know you bring up some interesting points about developing games for windows.
My question becomes would you continue to pay for upgrades to play your games, when the time comes?
Thank!
Sigs are dangerous coy things
...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.
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
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.
These "meta-designs" are called design patterns, and many useful design patterns are documented in the definitive Design Patterns book. I would encourage you to browse the sample pages at Amazon.com, which will list summaries of the main design patterns. I'm sure you will find a pattern there that is very close to what you want to do. Buy (or check out) the book, study it, and make sure your design closely matches the design pattern. By used a tried-and-tested real-world design pattern, you will avoid many subtle and hard-to-fix design flaws.
How exactly am I going to have to keep paying to use XP? I may have to pay to play certain online games on XP, but the same would be true if I were playing those games on 98, ME or even linux (if the programmers ported that way.
That was slightly amusing.
hmm, you're right, I didnt make it clear.
What is clear that MS does intend to make the os XP a subscription service, and what I was trying to point out is that right now, that is not the model that game players deal with. They dont continue to pay sony to play their old playstation console. Here, in time, you would have to pay to continue to use XP to allow you continue to play your games.
i hope this is clearer
Sigs are dangerous coy things
I don't pay for upgrades ;-)
Besides, Windows service packs are released for free, and you can run most games on Win98, or even Win95, that you can on WinXP. So no need to upgrade just to play. We upgrade for more features, not to run new games.
God damn, it's people like you that make me embarassed to be a Window Maker user.
Design Patterns: Solidify Your C# Application Architecture with Design Patterns
Exploring the Observer Design Pattern
Engine-Collection-Class, a Design Pattern for Building Reusable Enterprise Components
Patterns in the .NET Age
...this?
Eternal vigilance only works if you look in every direction.
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
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,
Bob
"It's funny. On the outside, I was an honest man. Straight as an arrow. I had to come to prison to be a crook."
From the intro page:
.NET Framework.
Terrarium is a multiplayer ecosystem game developed using the
It will probably give you some ideas on how to implement this kind of thing.
Donate background CPU time to fight cancer.
www.nevrax.org
:)
News not updated but the CVS and docs are updated daily.
20 paid professionals work on this thing.
Architecture is CORBA inspired.
and cherry on the pie: RMS is at the board of the company !
"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. "
Obviously you haven't been paying attention over the past several years.
Ultima Online
Everquest
Asheron's Call
Many many numerous others, I know I paid $10/month for a bit to play Allegiance. Going back in history we have examples at Compuserve and so forth.
Ongoing charges has been a factor of life for multiplayer gaming since almost it's beginning some 20 years ago.
Take your FUD elsewhere, troll. If people find enjoyment with the game and the value of paying per month exists they will do so. Otherwise the game will fail.
In the case of the XBox what I see as viable is for them to have a one time charge to access a large farm of hosted servers that grants access to many different multiplayer games. As things stand right now each different game asks for a seperate $10/month fee. Most people I know do not get addicted to just one game, they may play several, or go months at a time without ever touching one particular game.
the way I'd try and do it is to start from the idea of a remote screen and work form there... That is, use the client as a sort of viewer of events happening in the "real world" on the main server.
Show users what you can manage to show and have your client try an interpolate form the data that can be sent. As the user moves around the world, the view might require more timely information about certain areas of the "real world" so it would signal that the events it's interrested int should recieve more updates.
If you use C# - seems like a gutsy move given the language and environments lack of maturity - I'd imagine that these would be critical factors for a networked game.
It could be done using State Threads. It's a library originally created by SGI based on code used in Mozilla. Basically it gives you the illusion of multithreaded programming wrapped around non-blocking I/O calls. For internet servers it's a perfect programming paradigm - as long as they don't have to do any blocking I/O (disk reads are a good example) or library calls that could wait for a long time. The best part about it is since the 'threads' never really run concurrently you don't have to do any locking of variables... everything is in the same memory space and it can all be shared between threads with no synchronization.
I'm not at liberty to say how I know this but this is what I know of Everquest (the most popural MMORPG):
.... reseting crashed NT servers.... yes, that's right. full time server reset people...
They used NT and C (Asm too?) to develop Everquest and they are paying for it dearly.
Everquest has had up to 80,000 simultaneos users which were distributed over 200 NT servers.
These servers are in two locations and they have two FULL TIME employees who walk around all day -- their sole job
In addition, they've had nightmare situations with patching and keeping these systems up to date.
And another thing I know is that their next game (forget the name) they have started nearly from scratch and are developing on a UNIX derivative (may be linux... not sure) mainly because the costs of running the game on NT are too great...
learn from experience...
Rule #1. Do NOT do it in a language you're just 'learning'. The resultant game will be.. crap. I speak not to insult your ability as a programmer, I speak from experience, both my own and that of hundreds of M*'s that have come and gone. Writing a game to 'learn' a new language is *not* a good idea - at least, for the game.
Rule #2. Talk to M* admins - modern games like EQ and UO have their roots in M*'s. And M* admins are easier to get in contact with. Mind you, watch who you're talking with - some young kid (No offense to young kids, of course) who's just embarking on his or her coding career isn't going to be much help. Someone who's code reflects fathomless brutality will be.
Rule #3. Design, design, design. Assuming your game will be continually improving/long lasting/etc, you should realize now that 99% of your time will be spent in the design stage. Do not overlook this! (Nor for any other coding task!) Plan out what everything should do, and how it should be done first, *then* code.
Rule #4. Think if you really want this to be massively multiplayer.. MM games tend to eat tremendous resources, and unless you've got a large chunk of change sitting around, you'll eventually need some sort of commercial support. If that's fine, I suggest taking the route others have suggested - lock yourself in a room and don't come out til it's done. Technology is constantly changing, and if you want people tossing you money, you're going to have to make the game dance through the latest and greatest 3d hoops.
...he might as well learn a language that's actually useful, rather than C# (pronounced ``see-crash''). Ruby is not only extremely useful, but you also don't spend too much time counting spaces to make sure your code blocks are where you think they are... (-:
Oh, and you can run it in a JVM (did I mention portability?) and spit it out as C if you like.
Got time? Spend some of it coding or testing
If Debian users are any indication then there isnt a majority for DE/WM choice. However, Gnome+Enlightenment has the plurality, so "most" people use Gnome+E.
statistical data taken from the Debian Popularity Contest
you can use 2 ways:
- push. the server push/broadcast the state to the client. which depend on the algorithm you use, you can broadcast everything, or just only the changed state
- pull. the client request to the server the world state it needed
my suggestion is just start with UML diagram or any diagram you like. Then identify from there what you want to do, either inherit, mutator, etc
Epic's UnrealScript network docs can give you a few ideas.
1. On UT (their game), if you are playing on a corner or a map and there is a wall(s) such that you are not be able to see or listen to agents beyond, information for them does not get sent over the wire. They call it the "relevant set".
2. They define 3 kinds of clients.
2.1. Simulated clients. The behavior is mathematically/calculable in such a way that every client can determine the behavior of an object without depending on the server to notify them of it. For example, a rocket that flies on a line, or a grenade thrown with a known initial speed/angle/etc.
2.2. Predicted clients. This is for things like the player and missiles whose direction you can control while they travel. They are given high priority because no matter the prediction, they need CORRECTION.
2.3. Dumb clients. A box perhaps? You replicate information on them when they are pickup up (no longer on the map) and when they are dropped. These are of the lowest priority.
One of the things you'll inevitably have to consider is that not all clients will see the same scene to latencies, variations in prediction and so on, so you have to make it believable that they are the same even when they are really not. For example, a missile might look for client A a few pixels to the left than it appears for client B but if it hits a tree, it hits a tree for both of them.
Not it's not... It's slow for GUI but is comparable to C in server applications.
see, you were making some good points until you came to the Troll part, I take you think anyone who doesnt share your point of view is a troll?
how very sad
Sigs are dangerous coy things
I've recently started progamming in Java. The experience has been a very good one so far; the core libraries are complete and mature, and there are many, many third party libraries and utilities available, placing Java among the most well-engineered and supported development platforms I've ever used.
a ry /j-native.html?loc=j
.NET for a few reasons, the most important being maturity of the platform compared to Java; there are also the standard political reasons.
.NET is becoming more alluring in that Mono is building a free CLR, while we're still waiting for a complete and free implementation of the seven-year-old, and in my own opinion, superior Java platform. Kaffe seems to be coming along nicely. Anyone know of any other solutions, besides writing one myself?
As far as Mike's multiplayer game goes, Java's Bean architecture, combined with RMI (or maybe CORBA), sounds perfect for the event propogation needed to sync clients with a server. Although I've never tried using Beans with either, I'm pretty sure RMI would work fine, though I'm not too sure about CORBA.
Java run-time performance is the only question. It would be a cinch to develop the app in a language like Java, but it might not be much fun for the people playing it unless you used JIT compilation or pre-compiled the byte code to native code. Either of these could cause problems using RMI (object serialization breaks with byte-code native code translations), however, and as far as I know, there aren't any free x86 JIT compilers that support AWT and SWING, though I found one commercial Win32 JITter that offers a free personal edition. See this article, recently linked from Slashdot, at IBM Developer Works:
http://www-106.ibm.com/developerworks/java/libr
Maybe you could write critical sections of code in a language that produce native code, then wrap that code in Java using 'native' calls.
...or search google, there are LOTS of commercial solutions.
Your choice to use C# may solve some of the problems described above if you don't care about cross-platform compatability (and even then, Mono aims to solve that problem completely). There's also cross-language integration, which can make management code easier to write (Python, Perl, and VB are certainly easier to use than Managed C++). The platform also provides JIT and native compilation for all supported languages. Personally, I've avoided
Interestingly,
niko
3. You are planning to use an unproven language purely for its hype.
.NET framework combined with an innovative XML protocol for the information superhighway! Wow! That will impress every PHP on Earth.
So to sum up, you have no clue what you are doing (the very fact that you asked it on slashdot, of all things, is an evidence of that); you don't know the language you want to use; and, instead of evaluating your options, you decided to ride the hype, perhaps to make your CV buzzword-compliant. Therefore, this project is doomed before it is even started.
Oh, and just to throw in some more buzzwords, I suggest you make it a Web service using the
___
If you think big enough, you'll never have to do it.
Here are some Slashdot articles that have been posted about cheating in online games. You may want to give them a quick read if you're developing an online game.
Combating cheating in online games (16 November 2000)
Multiplayer Game Cheating (16 July 2000)
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
rather than communicate all world changes to all the clients, only communicate changes to the clients that are within their "scope" of the game. this will keep network usage down, and system load on both the clients and the server down.
Naturally, this model might not work depending on the type of game you are designing, but generally for MMORPG's, you should be good.
www.ebayrp.bizland.com
Without a team, you're setting youself up to be too slow for the corporations...
I wanted to make MMORPGS back in 89-92 when I was like 13... Wasted my early teen years in that shit. I'm a god programmer now, but I hate life.
I hate that corporations can steal market shares so easy. If I had a team, it would have been sweet.
Whats funny is that I'm back at it again... I seriously contemplate suicide on a daily basis, and sometimes throw myself into situations that may kill myself... Try russian roullette but use your car and speeding to see if you attract a police officer.
MMORPGS have already been done though... Why not try true artificial intelligence?
www.contrib.andrew.cmu.edu/~sager
God spoke to me
Did you decide this just to generate a deluge of flames?
Too big to fail? Does that make me to small to succeed?
Don't discount the ease of use of 'Play By Email' systems - you won't have to worry about the finer points of network programming, you won't have to worry about players behind bizarre firewalls.
Of course, this is only ideal for turn-based games. An example of such a game is the the brilliant Laser Squad Nemesis, from the XCOM developers (this was officially released a few days ago.)
It's people like him that make me embarassed to be human.
I beleive someone with a closed mind, would say something you just said. After all, some pretty interesting things have been made with COBOL, and you know everyone hates COBOL :)
now an experianced speller, I am not.. :)
expecially after a few drinks!
1) Slow down a bit, and give this project the respect that it truely deserves.
/. to show you all that you need to do.
2) Don't use C# for everything*
3) Break the project down into parts that are actually accomplishable (i.e. network layer, world engine, actual game). Choose one of these layers and actually get it to work.
4) Read lots of books because it's gonna take a lot more than a couple of comments from
I don't really know of a great networking book, but you would really need to brush up on newtonian physics. There is an aweful lot of physics involved and 3d hardware will for the most part, not calculate this for you.
5) Pay your dues on some open source gaming engines. Get your feet wet before diving head first.
* C# is bad only because your gonna need big time speed for the 3d engine. The server is likely to require a bit of speed in handling client requests efficently too.
For these areas, I would recommend C, or C++ if you know C++ _really_ well. C++ can be just as efficent as C but you have to know _exactly_ how C++ works and you must know the spec inside and out.
C# is really fine for the frills of the engine, but any VM based language would not do well for the heart of the engine.
Key is to use languages where they are appropriate.
int func(int a);
func((b += 3, b));
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.
It becomes an issue when the game is run on the SERVER.
As other posters have mentioned, using C# seems a strange choice. It may be a good choice for the server-side, if you want to restrict yourself to only running the server on Windows boxes. However, for the client, using C# is a good way to dramatically reduce your customer base without gaining anything significant. Fortunately, the client and server don't need to be written in the same language.
There are a few considerations that you should keep in mind. First, I personally am an fan of rolling your own messaging system over open sockets. Use simple encryption to verify that the client is who it is supposed to be--don't pass plain text strings around. Make sure that the server doesn't trust the client to do anything sensible. (Lost packets, hackers, etc...you have no idea what is going to come in.) If you can get by with sending updates no more often than, say, once a second, have the server limit the amount of updates you're sending.
Also, as other posters have mentioned, you want to try to avoid N^2 behavior as much as possible. The server will have to inform everyone of what everyone else is doing--there is no way around that--but whenever there is a case where a change needs to be propagated, think about whether you can't hold off on propagating the change for a little while to see if other data comes in. If you want fast massively multiplayer interaction, this is a must.
Also, don't be afraid to send predictive information to the clients. For instance, most MMORPGs send not just the position of NPCs and PCs but also their velocity so the client can properly update the position without having to interact with the server. Once the velocity vector changes, the server sends an update to the client (sometimes revising history as to where the NPC was). This is a good strategy in general to offload work safely to the client--just make sure that the server checks all requests that the client makes, in case the client is working with inaccurate information and says the user can do something that they really can't do!
I'd have to agree. Also, seeing as C# runs only on a platform that is known to not scale well to large problems, I'd suggest you'd be better off writing it in C++ to run on Solaris (or HP-UX or ...), as you're going to need a _lot_ of grunt once you get past about 6 players.
What a long, strange trip it's been.
If you are intending to do a turn based strategy game, then fire away, Gridley! I can say from experience that a MMTBS is relatively trivial via ASP, and ASP was/is a precursor to ASP.Net. (Remeber that M$ promises .net to be 'language neutral' in the sense that C#-ASP-VB-C++ etc, will be all able to accomplish the same ends.)
I'm already working on my own MMTBS game, and it is comming along very nicely. On the other hand, if you me strategy as in Command and Conquer or Warcraft/Starcraft, you may need to check out what M$ is releasing for modules. They promise (no snickers from the peanut gallery, please) to have modules to allow you do common things w/o reinventing the wheel. Will they ship a fast network communication module? Depends on if they want to try to put wild tangent out of businuess.
Of course, I haven't seen wild tangent actually make their multi player technology work yet...
I hope M$ builds game modules into .net, it would be cool as, not many people know how to build .dlls and COM objects.
HA! I just wasted some of your bandwidth with a frivolous sig!
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
White Orb project in Java.
It's now defunct, but has source code and lots of documentation and design decision records, and may be a good place to start. No licensing problems either! Developed by a small international team.
Steve.
If you are advocating Common Lisp, *please* tell me what compiler you're thinking of.. I've looked over them, and they are all inappropriate for a game. They may have late binding, but not always, and its the 'not always' part that bites you.
I want to build a car using (insert new untested material here) because its new. I know I'll need some windows, and wheels, and some sort of engine. I don't really want any suggestions about what materials would work the best because I want to learn how to use the new (untested material). What I really want to know is has anyone else ever done this before, and what should I look out for? I'm pretty sure I'll need to make sure it gets good gas mileage, but it will have to be really heavy, acceleration isn't important, but I want it to be responsive in the turns...
Why would anyone ask a slashdot group about a C# project?
Casca
Read his profile and his comments.
Insightful? He's just yelling out surjective believes, I don't seen any insight here. The fault in moderation system is that moderators will mod up those who is on the same-side as theirs, not on the content.
You should write your game in C# (or Java or C++) so when it collapses under the weight of it's own sludge, you'll learn what it's like to toss away 6 months worth of work on a bad decision and never make that mistake again. Then you can write it again in ultra clean C and maybe actually ship something that runs halfway decently. With what you are planning, you'll need to get every bit of efficiency out of every critical loop. In a 3D game, especially in massive-multiplayer, you can't afford to trade ease of implementation with not knowing what's going on in your code.
I know very little of the programming of multi player games but if you need guinea pigs to find the bugs let us know.
Well at least you don't disagree with my characterization of your post as FUD.
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
Don't know if this would work for you or not, but you might check out http://www.byond.com which is a multiplayer gaming platform.
I would encourage you also to look into some of the literature regarding cheat proofing methods. Having an authoritative game server (or server farm) is useful, but it doesn't solve every problem. If people are actually going to play the game, then people are going to try to gain an unfair advantage in the process. It's the nature of the beast (er, man).
There are quite a few good papers (Yes, academic! Don't you wish you could do research about games?) out there on the subject. You may particularly want to look into some kind of lockstep protocol, as time cheats (i.e., when a player waits for other nearby players to "make a move" -- whatever that means in your game -- before entering their own in response) can be reduced/stopped with something like this. That's just the tip of the iceberg, though...
Tastes like burning! - Ralph Wiggum
Offtopic!? He's right! This article has all the markings of a troll!
He's an "experienced (Windows) programmer," on Slashdot this usually means that his language is Visual Basic.
Mod me down for being right, I'll get you back in meta-moderation.
http://www.byond.com.
It has some drawbacks, but it is really neat for newbie programmers to play with. Its for Windows, Linux, and FreeBSD, comes with a client (graphical version only available for Windows), a server daemon, and a development interface.
A good example of a game that has been built off of this is Dragon Warrior Online, a fan game off of the popular RPG series.
I won't cover the networking problems, because that's not my forte, but rather the issues of physical proximity of players. You have to assume that a player has a limited range of sight and effect to cull the amount of data sent to a player in real-time. Assuming a perfect 56K connection, you can only send about 600-700 bytes per 100msec frame, so (BOE) you can really only send position updates for about 20-50 other players, depending on compression techniques, etc.
Spatial Data Structures (Hanan Samet) describes a set of aglorithms such as quadtrees (2 - 2.5D), and octrees (3D) which can be used to solve the proximity problem in log time in multidimensions, i.e. you can find the N players within a reasonable distance in a pretty short period of time. In fact, you only have to traverse down once, then traverse back up until you're out of range. Insertions are log N as well, so the server should be limited on network bandwidth, not processing power. You can also give priority (send this packet first) to the player that you're looking directly at (or who's looking at you), with diminishing interest in other players (if his back's to me, and mine to him, I don't care quite as much as if I'm looking directly at him),
The second part is "what happens if I don't get a packet for an assigned player in time", a typical UDP problem. In a flight/driving sim game, you can "guesstimate" with an area of probability where the player's going to be, and if you're shooting at him, give the probability of a hit. Sometimes you'll miss when you should have hit, and vice versa, but you have to do something.
Do the canonical system first, with objects in 3-D space which can manueuver and shoot to tune your algorithms on the server, then you can refine the game. Doing a simple "space shooter" should be relatively easy. You can make robo-clients with scripts to test out your weights and probabilities. Once you have the empty space shooter, you can add a world with static objects, which should be replicated on each client. Dynamic worlds (walls falling down, etc.) are much more complicated, where you have to set the before and after on each client, and kick it off with a trigger. Dynamic interactions get a tad too complicated even in single player games.
If you're doing a game with animated players, it's easiest to have pre-programmed positions (running, shooting, slashing with the sword, kicking), so only a code for the target of the action has to be sent down. You can't ship down full animation information, it's too expensive. Unfortunately, it makes fighting unrealistic, because there's no reaction to the pre-programmed code. Doing interactions between figures is an N^2 problem (I block his kick), which while doable, requires a lot of hand-animation work. Full inverse kinematics is computationally prohibitive (AFAIK), but there are approximations that are quite realistic.
Keep your hopes up. There's a lot of stuff out there that's not very good because it was put together in a hurry.
For the networking stuff, try some tuning of packet sizes and rates for different scenarios (modem, DSL, high ping times) to figure out what's most efficient in terms of accuracy and percentage of arrived packets. You should be able to figure out your optimal packet size and rate for each scenario.
It won't help you solve *all* the problems, but I'm sure you could glom onto a few ideas from having a look at the way a MUD works. Here's one (telnet:// link).. they're based off of MERC, but you'll want to look at the code too so either snag a copy of ROM or QuickMUD (the latter of which is just ROM + Color + OLC + Copyover, basically snazzier to the players/builders :).
"These servers are in two locations and they have two FULL TIME employees who walk around all day -- their sole job .... reseting crashed NT servers.... yes, that's right. full time server reset people... "
This sounds to me more like a management problem.
Instead of having two full-time employees walk around all day rebooting servers, why not just hire one competent sysadmin to read the fucking logs and find out why the servers are crashing? Or maybe hire a few competent programmers (that find the problem and fix it, instead of whining about the OS) if it's the EQ code that's at fault?
Oh wait, my bad, I forgot this is Slashdot, where we bitch about MS, without a link or anything else substantial to back up our slander.
-Tommy
"I got a half gallon of Jack, and 2 dozen Ant Traps. I'm about to get wild." -me
AFAIK broadcasting is part of the IPv4 specs.
It's just that many routers don't implement it.
So yes, you're restricted to LANs for broadcasting
messages.
Oh, very important note if you use TCP in your game. You have to turn off buffering or your lag will be incredibly bad. The manual might say something like never do this because it spams the network and is very inefficient. What this means is that your bandwidth (bytes/sec) goes down with buffering off. But thats ok because you dont care about bytes per second, just time between packets. You have to be sure your server does not send packets as fast as possible, but on a schedule otherwise you will send to many packets and flood the network.
As so many people have made clear C# is completely the wrong tool for the job. How could it possibly be the right tool? After all, it's a new language from Microsoft!
Some other advice on languages: how well this will perform will be completely dependent upon the language you choose. I cannot overemphasize this fact. The language you choose will be the difference between this game of yours being the next Starcraft and this game being the next Civilization: Call To Power.
First off, I would recommend NOT using languages like C, C++, or Objective C. C is especially bad because not only is it not garbage collected, but because it is a structured language it makes working on large projects with it virtually impossible. Every large project which has been written in C instead of C++ has failed completely. C++ is not an object oriented language either. Both C an C++ have a horrible potential for memory leaks because they arent garbage collected. Also, C and C++ have language features which can be abused such as global variables and pointers. The sockets support in these languages is a bit iffy and they don't let you use all the latest language features like POSIX asynchronous I/O. Only a moron would even think of using C or C++ in this day and age, when there are so many better garbage collected languages out there.
I have a number of recommendations to you for language choice. The first is of course Java! Java is an easy language and does an extremely efficient job of garbage collection, more so than what you could ever possibly acheive manually in languages like C or C++. Java is also dynamically recompiled which means it is optomized for your CPU on the fly, making it faster than C or C++. It's also easy to program in, and is a better object oriented language than C++ (Bjarne Stroustrup has admitted that C++ wasn't designed to be an object oriented language, and we all know that if a language isn't truly object oriented it's just no good)
Might I also suggest Pascal as a language of implementation? Pascal has a very nice sockets interface which will let you use the absolute latest kernel features such as POSIX.2 asynchronous I/O which is, believe me, what you want to be using. glibc doesn't document the functions like aio_read() but you can find them on any BSD. Linux does implement asynchronous I/O, right in the kernel which is better than any BSD. And of course I know you want to be using Linux because it's the greatest operating system ever.
Another language to consider is COBOL. COBOL has a great deal of support because it's been around so long. In fact, the COBOL compilers will optomize better than any other compilers on Earth, just because they've been developed so well because COBOL is so old. You should look into COBOL if you feel like writing it in Java isn't your cup of tea.
Smalltalk is the world's greatest object oriented language. There are a great deal of tools for Smalltalk development, plus your program would run faster and be less buggy because it's written in a true object oriented language like Java instead of those fake object oriented languages like C++.
Eiffel is another good object oriented language which you might look into. I haven't used Eiffel much but I hear it's very good.
PHP is a language geared towards portability and rapid development. Use PHP if you want to code the server with ease and run it on a variety of platforms. I think PHP even supports POSIX.2 asynchronous I/O!
LISP and ML are functional languages which are often ignored but very good. Use these if you want to guarantee your server is bug free.
Color Forth is a language which gives you very low level access to the system while still being garbage collected. In fact Java stole its garbage collector from Color Forth. Color Forth also has the world's coolest syntax ever because it's color dependent. Color Forth will give you the best use of Posix Asynchronous I/O out of any of the languages I've mentioned, but watch out for memory leaks! Color Forth does not let you guarantee your program is bug free either.
FORTRAN 95 is another way to go. FORTRAN makes it really easy to parallel process anything which uses the FOREACH command, and there are many great FORTRAN compilers for Linux made by Intel and the Portland Group. And we know if it doesn't run under Linux, your game will be completely worthless.
Visual Basic makes it very easy to program network servers, and will guarantee you easy use of sockets and POSIX.2 Asynchronous I/O. Use Visual Basic if you want a very efficient language that lets you manage memory manually and use a small footprint while being very efficient in your use of CPU algorithms.
For the client I recommend using Direct3D. You are writing a 3D game, right? A 2D game, especially a 2D strategy game, is completely worthless! Every single successful strategy game ever written has used Direct3D. It is for this reason that I recommend you use and learn Direct3D. I recommend you also write the client in Visual Basic as it reduces development time and allows for efficient memory management.
It seems to me that this problem is similar to other "table" propogations as well as firewall forwarding stuff. What I mean is take a look at a spanning tree algorithm where each node is a client on your MMORPG network.
Why not? .NET you can create a distributed application, where the app is hosted on the server. So if you make a change to the client code, the clients automatically get updates.
Being Java based, C# has great networking capabilities, and there's a lot of Java code out there that could be ported to C# easily. It also has the performance advantage over Java, which is important in a network game.
With
C# is an excellent choice for this project.
Check out the Terrarium game at www.gotdotnet.com, they use quite a bit of this technology.
Good luck, and ignore the Linux Jihad!
Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated up.
Something akin to a JMS implementation, or something that can use event routers to increase scalability as you need it like Siena
I wouldn't use C# right now because it is too new.
On one hand I understand the appeal of using the latest and greatest language: I fell into the same trap with Java in 1997, and this was a wrong choice: the library was full of bugs and I spent half of my time working around bugs..
C# is very new, so I wouldn't bet on it.
Oh BTW don't believe the press, at the same time I was badly hurt by the bugs in Java, I kept reading reviews which were swearing that Java was the greatest things since sliced bread (in Byte or Doctor's Dobbs)..
If Microsoft has an open bug report process, first check the "level of bugs" before..
I should have looked at Sun's bug parade before choosing Java, it shows the true state of Java (a looooonnnnnng time to correct the bugs.).
I have started my internet education exactly from diku/merc codebases. It took me almost a year after that to lose some bad coding habits... I must say, that this code is one of the worst pieces of C hack I have seen.
I don't want to be inflammatory here - it works and it can be used. But it is not a place to learn. Try to look at any more contemporary codebases - a lot of stuff was already fixed there.
Another problem with focusing on muds is that they are very simplistic in time handling - they don't care about lag, do not have to really update clients, etc, etc. Everything is simulated on server, clients only get text log of events. This does not scale to anything even semi-real time interactive.
Did the thought ever occur to you that maybe the server code for the game is buggy? In that case, from managements perspective it maybe be more cost effective to have 2 fulltime server resetters then spending programmer hours on finding/fixing/testing/deploying the fix.
And if its not the server code then it may be the drivers (ie. network card) that is causing the crashes and not the OS itself.
I think that most Unix systems are more stable because the vendor (ie. sun, sgi) has direct control over the hardware that it ships with and can fully test the default hardware config with their flavor of unix. If MS was able to test every possible PC configuration then maybe they would be able to guarantee 99.9999% uptime, but NT's uptime reputation is at the mercy of driver developers of other companies.
(I had to remove some information, especially ascii art sheets which the lameness filter catches)
This is a replacement signature.
If you want to learn a new language, why pick a Microsoft-centric language. Most language out-there are cross-platform and will allow your game to run on all these platforms as well.
:)
Chosing C# seems a little bit like tieing oneself to a tree before starting a race. If the rope is big enough you might not notice you won't finish the race until it's too late.
True warriors use the Klingon Google
If you care about scaling... what about a server ring, in a kind like irc. You can add trusted servers (trusted on cheating sense) and balance the load between them on connection or even hotly using some kind of server change message.
You may also use a server tree in order to reduce the latency and keep a centralized data source, while keeping the circle for load balancing and other 'latency/inconsistency don't matter' tasks.
I have already constructed a load balancing system like that in PVM programs. I may help you in constructing such system if you are insterested in, althought my code and coding skills leds to C++ and I am not interested at all in learning C# vokimon.at.jet.dot.es
Vokimon.
just to tell you there is a pretty paper about networked gaming models on
http://www.hut.fi/~jmunkki/netgames/
http://gamasutra.com/ is also a good place to go for documents on general gaming issues
you could accomplish the "selective sending" by making the client send you a "Changed map position" with the coordinates each time he/she goes to another place on the map. When receiving events, you should broadcast them to every player which is in the area the event occured.
hope this helps,
nightdog
C# has no useful for games networking capabilities whatsoever -- it's based on the idea of a remote (procedure,method, ...) call while networked games have to deal with asyncronous streams of requests and messages. One can reduce those streams (plus all related structures that describe which stream describes which instances of objects, and how their state should propagate between clients and servers) to calls but that would be like writing a GUI on a Turing machine.
Contrary to the popular belief, there indeed is no God.
Moderation Totals: Troll=1, Insightful=1, Informative=2, Underrated=1, Total=5.
I think I wont troll again, that will teach me!
~shiny
WILL HACK FOR $$$
Christ, your an ass.
Sigs are dangerous coy things
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
Any game theory application would make the project simply a programming issue.
So ends the conversation.
You obviously have no idea what you are talking about...
What's the largest code base you've worked on? Ever deployed to 200 servers? 80,000 simultaneous users.... I'm guessing no... and since, traffic wise, Everquest is nearly 1/4 of Yahoo's traffic (and the game logic is much more complicated then a web server) its quite a feat...
And there is no such thing as bugless code. What there is though is the complexity of windows and the relative simplicity of a unix build built to match requirements.
blatant MS loving is as pointless and uneducated as blatant MS bashing...
"Hi, I'm an experienced programmer who is going to implement a massively complex project in a brand-new and probaly buggy language. Also, the language in question (C#) will never work on any platform other than Windows and I would like advice from Slashdot readers (??)
.NET archicecture, I'll be able to send all game state changes to thousands of clients at the same time from a single server."
I'm so experienced at programming that I don't need to know what exactly it is I am doing. Since I will be using the
Conformity is the jailer of freedom and enemy of growth. -JFK
I used to work for the CBOE as a Systems Support Analyst. In this job I was supposed to do hands-on troubleshooting of the options quote distribution system that populates the arrays of screens with stock tickers and options prices.
At the core was a huge tablespace (database) of product:Bid:Offer:Last:Timestamp. That was an Amdahl mainframe running TPF (like the Sabre system backend for Travelocity). From there, the prices went through a ring-buffer where they were synchronously distributed (by another corporate entity: OPRA) back to all the derivatives exchanges including the CBOE. This happened over a T-1 in my time. Some Stratus Continuum (Wicked expensive redundant out the wazoo HPPA boxes running VOS) modules massaged the data out to and back in from OPRA. No traders on the CBOE floor have yet seen the effects of their bid/ask changes or last-sales on the overhead ticker displays.
The Stratus modules maintained a first-tier subscription list for 10 georaphic "cells" (really called "posts" at CBOE), and streamed the appropriate updates to a "Post Display Server" (PDS). Each PDS server maintained a second-tier subscription list for 4 (possibly more) "Remote Control Node" (RCN servers) which fed a third-tier of subscriptions to the RCN displays, the end-client, a Tektronix X terminal running proprietary quote-screen software locally.
We could never get clocks on all the servers to synchronise completely, but I estimate it took less than 500ms for a price change to make it to the screens, and peak trading times would see delays of 2-3 seconds.
The multiple tier distribution system is designed to limit the impact of demand/performance spikes to the fewest number of clients possible. For example: your MMPOLG might have a server for each "city" in your game. I've always thought this might be a good application for a Beowulf cluster because of all the paralellism in dealing with all the clients simultaneous actions. Basically, you're a database of game state, and you have to sort and forward events to the fewest clients possible in order to keep things from getting overloaded. Clients recieve state, and they feed input to a state-engine, which generates events, which get sent back to the clients. The server sends the client a pond, the client throws a stone in it, and the server sends ripples back to all the clients at the pond. Your job is to keep that process as lightweight and distributed as possible.
Good luck.
--- Nothing clever here: move along now...
Use IP Multicast. It does not restrict you to LANs and is gettine more widely depoloyed everday. It used the class D address space and uses the routers in the path to maintain group memebership. In this way the server sends the data (UDP) to a single destination address and the distribution tree and packet replication is handled by the routers.
For sending identical datasets to groups of clients, multicast is the way to go.
Cases can be made for a wide number of languages based on a variety of arguments, but I would strongly advise you NOT to use C# for two critical reasons.
1) Microsoft already took one language (Java), made it their own and incompatible, dragged a whole mess of developers into the fray, and then abandoned them. These folks already have to move to C#, the last solution they picked, good or bad, was killed underneath them. Isn't this a nice lawsuit from the Fortune 1K to MSFT?
2) There's lots of languages with real standards and established communities out there that are considerably more seasoned and experienced than something thought up inside MSFT and with no real world use. We are big fans of Smalltalk/Squeak, but there's a lot of good choices out there.
Pick a language, any language. C# is not a language, it's just another poorly engineering trojan horse from msft. Once you ride it, getting off is only slighly more painful than staying on, but pain is the game.
Hope you have a big honkin' server to serve this game to the masses...
Even if there was any useful technology in C# (there is not, all has been done in other places before) to give in to a company with complete disregard for fair business practices is the last thing anybody making business doing software development should lock himslef into.
IANAL but write like a drunk one.
The orignal poster wants to do this in C# not C.
IANAL but write like a drunk one.
Assuming the original poster is not lying (he gave no probe of his allegations) then an OS that crashes because software is running is unacceptable. These are not the 70s were you need to reboot your machine once a week to ensure good operation.
Same with network card.
There are resilient probed stable solutions (the initial poster was right, a UNIX solution would not require those shennanigans of people going stupid rebooting servers).
IANAL but write like a drunk one.
I'm not familiar with the exact details of the problem, though. Work is under way to solve other web page related issues, and this will likely be solved at the same time.
-- zzorn, WorldForge developer.The memento pattern seems to be one of the many you will be using in your design. You will learn alot even if you fail miserably. The book is this one: Here
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
he does not say that the servers crash. He says that they reboot them. This MIGHT be a faster way to handle a "log in, ill the server process, restart it" version. Sort of "just press the small button in front and things handle themselves". Resetting is way faster than even logging in. Again looks like a management decision.
I don't know the specifics of your client or your server. Judging by what you want your server to do though, I would recommend C or C++. The client if it is anything besides basic telnet, could be written in just about any language.
... C#/Java/Python/Perl. Even though I'm a big fan of some of these, I really think you'd be limiting the size of your game by using them.
If I am reading correctly you are making a strategy game and not a mud. Most of the languages I've seen recommended will not give you the speed you want. This really also depends on how many clients you have connected at the same time and how many calculations you have to do. I'm guessing your thinking in the thousands since you stated massive. Under these circumstances you should stick with a compiled language and not a interpreted/bytecode language such as
He's talking about windows not being a good server OS, not the client side. Windows is the right OS if your looking for the one that has the most used on the client side. Windows is NOT a very good server OS. The added fact that you will have subscription fees as an OS tax are not helpful either. Any *nix like OS(Unix, Linux, BSD, even MacOSX) would be a much more viable alternative for a game server. Stability is your prime concern.
When a new user joins a game he does so through the primary game servers, which identify the user and issue a code to the users client program. In addition, the server also issues a *handful* of IP addresses and codes for other players *near* the user (near being in terms of where the player is within the game). This handful of addresses and codes we term the *circle* - and you can think of it as being a circle of friends known to the clients game program.
Once received... the client program then does direct peer-to-peer communication with the *handful* of client IP's that it received from the server.
Now... as new gamers arrive, invariably they are handed some of these same IP's... each time they contact another game client they give their code... and they then remember it.
With each gamer coming online... the *nearest* game clients then *know* about that gamer. However, other clients may not, since they are not *near* the gamer at that point. As they enter the gamers area they, of course, broadcast their codes and positions, not only to their known circle of clients, but also back to the primary game server.
When a gamers client sees a new client code enter their area (as told to them by one of their circle of clients) -- they simply *ask* their circle who that player is. If none of their circle of clients know, they ask the primery server. Anytime they receive the new info, they not only update themselves, but they also tell their circle of clients.
This works similar to DNS... in that... because a particular game client only knows about a few other game clients - the amount of traffic is minimal, but eventually everyone knows about everyone through the *circle*. For anyone that is not known, the master game server knows and is polled. This puts the primary amount of activity in the clients, and peer to peer - as opposed as client to server (the server basically only records the initial entrance of a gamer into the game... and also takes care of responding to any confused clients who can't find out about a gamer from it's local circle).
zzzzzzzzzzzz ... oh sorry. I fell asleep while this pompous ass was going on and on about his "expertise" and "experience". Man, what a putz.
Believe it or not, many MMPGs and MORPHS are based on a tried and true distributed communications architecture called... IRC. Examples: anything by Blizzard (Diablo II etc), Everquest (and Verant's new StarWars Galaxies, etc.)
My humble opinion, but check out what other people have done first...
It is amazing what the slashdot sensors publish as articles these days (and what they don't).
/\/\icro/\/\uncher
Well, I can agree that you can never guarantee security in today's systems.
I also haven't looked at cheating, yet, but I have a couple ideas.
One: PKI. If every packet sent by the server is signed or encrypted, then a client should obviously only trust signed packets. Prevents some man in the middle issues. If both client-server uses PKI, then this applies in both up and down stream situations.
If you use both global and personal keys, then you can encrypt messages in two ways. Personal keys are for specific P2P communications (such as important state changes) while the global keys can be used for multicast information (like monster movements or screen updates). This of course depends on the strength and inassailability of the keys, but that is a technical issue and not a policy issue.
This doesn't address the ability of miniservers to create state. I haven't decided yet if that's going to be allowed, but if it is, one possibility is to have multiple mini servers correlate data, to increase security and robustness. This is still imperfect because a group of friends who play together can still cheat together (bad clients, for example, or proxies, or whatever)
On the other hand, cheating can be curbed, I think, by good game design; where cheating is reduced by making the benefits of not cheating much higher. That's another policy design. IE, a bunch of friends won't cheat each other, if they're really friends...
GPL Deconstructed
I hadn't thought about that problem, but it is a very good point. Its funny how one can think they are pretty informed on a subject, then find out through talking with other people just how much they really arn't aware of (i'm refering to myself of course).
thanks,
-Jon
this is my sig.
Interesting papers...
*grins* Somehow, I hope that the author reads his replies.
At any rate, one of the papers (forgive me, but it's the one with the link on the right side of the page) mentions a method of runtime polymorphism (or something very much like it) that is accomplished by attaching categorized properties to an object.
The paper then implies that the categories themselves are fixed prior to runtime (showing a UML-like class-graph indicating two categories "can use" and "use").
While I believe that flexibility and utility can be served with few categories, and also believe that the categories themselves probably align well with the object model (if one "can use" something then does "use" something, or "can take" something then does "take" something... etc), I find myself wondering if any thought was given to a more general extension system where whole categories themselves could be given to an object during runtime.
I arrived at the desire to do something similar (flexible runtime polymorphism) at a high level of abstraction while considering MMORPG from a graphics-engine perspective, and looking at developing an MMORPG runtime engine based on a directed acyclic graph (just as many graphics API's use the concept of a "scene graph", an MMORPG runtime engine could use a "world graph" in the same way).
Looking at the same example as the paper presents, there is an in-game object, which is furthermore a weapon, which is wielded by one who is pure-of-heart, which has the added effect of undead slaying (my apologies, I know the paper doesn't use those terms, but it's close).
Using a "world graph", it might be worthwhile to view the object as a node, and view the property of "being a weapon" as a sub-node. From there, the "can use" set of properties would be a sub-graph rooted at the "can use" node rooted at the "being a weapon" node rooted at the object's node itself.
At this point, the idea of a "world graph" really isn't any more powerful than the categorized lists, but the framework might be (I believe) more flexible if organized as a graph, and the implicit ability to add seemingly nonsensical properties to an element of the world would _almost_certainly_ appeal to the game-designers ("...wow, I just made a door that can be wielded as a weapon once it's torn from its hinges, bet you never figured we could do that..."). And _hopefully_ the framework could do that without modification to the runtime engine.
*ponders* Yes, sorry. Long post. But in sum, I like the concepts presented in the papers, I'm just wondering if there was any specific reason to truncate it (runtime processing overhead & etc) from a more general approach to runtime polymorphism
I've never had to count spaces with python -- and it's been my primary application language for years.
It's a fine point to try to debate with, until you try to actually use the thing and realize it never comes out at all (as opposed to counting curly braces in other languages, which really has happened to me).
Further, Python too can be run in a JVM or converted to C.
Funny, I was thinking the same thing about you.
  What's the largest code base you've worked on? Ever deployed to 200 servers? 80,000 simultaneous users.... I'm guessing no... and since, traffic wise, Everquest is nearly 1/4 of Yahoo's traffic (and the game logic is much more complicated then a web server) its quite a feat...
Well, I don't see what the size of a code base has to do with piss-poor administration of servers. If the server crashes, figure out why (sometimes referred to as troubleshooting), and take steps to prevent it from happening again. Period.
  And there is no such thing as bugless code.
This is just wrong, and I don't think you that meant to make such an all encompassing statement. Surely, the more complex code gets, the harder it is to be certain that it is bug free, but to say it isn't possible is assinine. Regardless, if there are outright symptoms of bugs (servers constantly crashing) then you need to figure out why... simply using the excuse that all code is buggy, is lame.
  What there is though is the complexity of windows and the relative simplicity of a unix build built to match requirements.
I am not arguing with this, nor did I at anytime. I am a strong supporter of the right tool for the right job. This includes the right programmers and sysadmins for the job, which is my point.
  blatant MS loving is as pointless and uneducated as blatant MS bashing...
Please don't bother to put words in my mouth, I am quite capable of making an ass of myself without help. Not a single part of my post was in the slightest bit 'blatant MS loving', or even subtle MS loving. What I said holds true of any Server OS at all, which is why I never once mentioned MS, except to accuse you of slandering them without any evidence (other than the 'I'm not at liberty to say' bit, which if this is truly the case, you should have STFU to begin with).
-Tommy
"I got a half gallon of Jack, and 2 dozen Ant Traps. I'm about to get wild." -me
If you are developing a final, "retail" version of a product, and are willing to spend a while coding it, then please stick with C++.
If you want to quickly churn out a prototype implementation of your game design, C# is probably a better choice. C# is a much more convenient language to work in, as it lack most of the legacy inconsistencies of C and C++. When you have the basics all ironed out, you can re-implement it in C++, for the final product.
I have done quite a bit of programming in C/C++, C# and Visual Basic. I am currently throwing together a prototype multiplayer game using purely Visual Basic 6.0 (I started it before I got VB.NET). Laugh all you want, but VB has helped me get the implementation down quickly, and fundamental problems are much easier to diagnose and resolve. I promised myself that once I get the basic multiplayer algorithms working properly, I will re-do it all in C++, so it can run faster, better, and on more systems. Of course, this means other problems will crop up, but I think I can handle them.
Ooh, time for an editor crusade! (-:
Knew about Jython (which see-crash can't do for political reasons) but didn't know about C as a compiler target.
I hope that there will never be a JVB compiler, but would find a VB compiler with Python, Ruby or even something ruder like Java or C for a target highly useful as a stopgap from time to time.
Cheers; Leon
Got time? Spend some of it coding or testing
Turn off buffering? Do you mean reduce the TCP window size? That doesn't have much to do with the issues surrounding TCP versus UDP.
:)
The primary issue is that TCP is guaranteed delivery. That means that if your connection goes south for a second, NO OTHER DATA WILL GET THROUGH ON THAT CONNECTION until packet retransmissions get the originally-lost data through. When dealing with any kind of streaming data - streaming audio, streaming movement keystrokes - anything where an interruption in the data flow is worse than a momentary loss of that data - then UDP is what you want to use.
Using TCP to stream multiple-times-per-second movement and position update packets will cause all sorts of hiccups and lengthy recovery delays over the Internet, which is why UDP is the protocol of choice there. On massively multiplayer movement servers, there is an additional issue of the overhead of maintaining hundreds of simultaneous connections to a single server. A protocol design that results in a need to bring up and shut down lots of TCP connections can spell disaster for a massively multiplayer online game server because the overhead requirements don't scale well.
Prototypes on LANs involving a few dozen connections will work great, and lull the dev team into thinking the design's fine. Then you commit to a thousand clients over the Internet and everything goes to hell. Disregard that at your own peril.
"EVE uses a special Stackless version of Python to implement game logic, both on the server and the client."
Matti Á.
If he is going to develop inside the .NET framework and he runs into a problem with C# Libraries, he can always plug C++.NET Networking Libraries in. It is the beautiful thing about the Common Runtime Language.
yeah, not by choice to be using kludge
oh yeah blame "drivers".
so in the early days when slq server sucked and crashed alot (4.5-6.5). was it bad drivers?
what are you? another MCSE who doesnt know how an os works?
Argh! Why couldn't he have called to pytusi or at least py2c? There's already a p2c for Pascal which is in wide use.
Got time? Spend some of it coding or testing
It's *called* Python2C. Just happens that the directory the web page for it is in is called p2c.
you are comical
Designing Multiplayer Game Engines?s on _01.htm
http://www.gamasutra.com/features/20000621/aron
sounds like the sort of thing you might like to read for this.