Posted
by
Soulskill
on Saturday September 15, 2012 @08:36PM
from the massively-multiplayer-regular-game dept.

An anonymous reader writes "Just Cause 2 Multiplayer has been getting a lot of press lately, but this making-of feature points out how the mod raises serious questions about the games industry: if 1,800-player massively multiplayer action games are possible on one server, why did it take a group of modders to prove it? From the article: 'There’s more chaos to come. That 1,800 player limit isn’t maxing out the server or the software by any means. Foote says that the team, who first met online seven years ago playing the similar Multi Theft Auto GTA mod, are "yet to reach any real barrier or limitation preventing us from reaching an even higher player count than the previous public tests." When it’s ready, the team will release the software for everyone to download and run their own servers, wherever they are in the world.'"

My math is old, but with P2P where you update everyone around you of your position with 640k upload, you can do about 50,000 players if your attacks are melee only. The key is not updating people far away as frequently, since they can't get in range and get a hit on you, you only have to calculate a full run between you for the time between sending out data. The biggest trick with P2P as everyone knows is dealing with hackers though... Even games like WOW, I would think you might be able to fly with a hack because their central server probably isn't calculating your collision detection.

Here is a probably patentable or patented method of dealing with that:
Each node shall crypt then sign its data. One key shall be unique keys per connection, it shall be use for encryption. The other key should be unique per application instances, it shall be use to sign the data. A node shall validate the authenticity of that data with a peer after every an empirically determined threshold of data on a singular connection. If there is a mismatch broadcast it to your peers, except the one use to detect the mismatch, inform central.
On reception of the broadcast the peers shall have the following behavior:
If the node having sent unauthentic data is know to the recipient node. It shall validate the authenticity of the data then it shall inform central. It shall also broadcast it to its peers. If the potentially malicious node is unknown, the recipient shall drop the message.
The central should perform a local rollback of the cheater when it reaches an empirically determined threshold with regard to an empirically determined metric.

The crypto stuff is kinda obvious... see for instance gnunet. For the actual p2p, take a look at this http://dl.acm.org/citation.cfm?id=1170257 [acm.org] I know the author, he started doing this more than a decade ago.

Yeah, it's frustrating, you (we) have some good idea, just to find out a lot of people already had it way before. Sometimes centuries ago (for math stuff).On the other hand, we live in a world of awesome possibilities...;)

I am not frustrated at all, sorry if my message ascribe such emotion. To my defense, let me confess that I was trying to karma whore by weakly attacking a favorite of here*1 for no particular reasons whatsoever.
1--the US patent system

If I'm understanding you correctly, I can see two possible problems (at first glance). The first is the overhead introduced by crypto: even at it's fastest, it will always add some latency to the data transmission (simply because the data has to be processed on both ends before it can be received or sent), and it requires additional processor time to manage the encryption. I'm not sure how much, but it could be a fair bit if you are transmitting several dozen times a second (which multiplayer games customarily do). This isn't a problem in BitTorrent where latency and computational overhead are not terribly important. It is a potentially very large problem in a multiplayer action game where the CPU may already be taxed and low latency is absolutely vital.

Secondly, a large number of malicious nodes could probably poison the system, or at least a part of it. This also could also be a problem: cheaters and trolls sometimes run in packs.

Won't work. It's all about trust. Which clients can you trust? Hackers will get multiple clients working together to cheat. Need 3 other clients to verify input? Hackers will get 4. They will also report people who aren't cheating as cheaters, and you will end up banning the good players. You can attempt to create your own fake client honeypots to weed out hackers (until they figure out how to spot them), but that will only help if they can't just go make another account for free. But if its pay to play, th

I was just thinking why don't we just say fuck it and make a wonderfully complicated game where the point was hacking and cheating.

A virtual world where the leader boards are filled with those who have the greatest skill and resources at hacking the code, abusing other players, spreading misinformation, hijacking networks, and generally being as shitty to everyone in the virtual world as possible.

Then I realized we don't have to create this game. That's how the real world works and is why we can't have nice things.

Very True. But that is only if you are insisting on anonymity. If you are willing to lock down a real, permanent identity before allowing someone on your network, then punishing misbehavior becomes trivial. Sometimes is to beneficial to have a network where you know who everyone is.

I assume you validate not only the authenticity but also the feasibility of each command.
A single cheater could run 10 nodes to blend reality in his favor or report as cheater some innocent players.
Then you have to handle data persistence, taking in account that any node can have connection problem at any time.
Client/server(s) model for any robust real time action game has still a bright future in the current decade. (they will put the "cloud" tag on it to be trendy tho)

The problem isn't something crypto can solve. It comes down to an untrusted client. When a client reports 'My player just stabbed this other player' how can the other clients be sure this is what really happened, and the player isn't really using a hacked client to achieve superhuman precision in aiming or hit people from across the level? There are some techniques that can be used to make software much trickier to alter but, as long experience with copy-protection on games has shown, if the software is run

But the problem is gonna be, as we saw in the video, that while it LOOKS cool as hell this thing is gonna end up being a griefer's paradise.

Show of hands, how many here have played JCII? Well I own and love this game and I can tell you picture being Spiderman with access to the most INSANE amount of firepower you can possibly imagine. We are talking Mach 2+ combat aircraft, choppers, tanks, the amount of pure firepower in this game goes beyond crazy and gets into complete batshit.

Uhhh...what does ANY of that have to do with Just Cause II? What you just described already exists, its called Team Fortress 2 and has jack squat to do with the game we are speaking about.

All of that crap might be fine (already done to death, but whatever) on some theoretical future game, but with a mod you have to follow the laws already hard coded into the game engine. And anybody who has played JCII knows that the amount of weaponry in that game is totally batshit. It is the ONLY game that i know of wher

The problem is none of the mods are doing any transaction logging needed for catching cheaters. You can easily handles 200k players in 1 location when there are no checks against movement speeds, positional coherence, etc. This is a non-story at best.

That's easy to do too. The server can just send the data of players to a random group of clients for collision detection and probability calculations (what's the probability of a guy going from height 0 to 10 at that location). If a certain number of clients tells you the results are erroneous, mark them as hackers and kick them or ban them or move them to a cheater's server.

This revives in me an idea a buddy of mine and I had about creating a massively multiplayer online version of joust, after playing it for several hours on xbox live one night in the early 2000's, the game is so simple it should be easy to pile on thousands of players, and would be a fucking blast...unlimited board, unlimited players, would be great. Of course, like any cool idea I wouldn't be surprised if this has already been done by someone.

MMO Pong: Everyone gets a side of an nsided polygon where N is the number of players. There is n-1 balls in play.
MMO ET: Everyone gets thrown into a pit, and you need to jump on top of other people's heads to jump out of the pit. I would think this would have to be a minigame inside an actually fun game, otherwise how would you get people to play it:P

Or make it a 3D game where each player has to protect a face of a polyhedron. When players exit their face of the polyhedron is removed. Maybe even put another polyhedron inside the polyhedron and have players bounce the balls between the polyhedrons.

Game developers set their limits based on what they can reasonably show to be a supported, stable level for the majority of their expected customer base.

Even though the code could potentially handle more, explicitly supporting it requires additional development resources, additional QA resources to validate that it works, etc., for potentially little to no gain.

Anything over 64 players is going to bump it into the real where it's considered "massively multiplayer" by most suits as well.

An hour or so after we started the test, we were hit by a DDoS attack that ended shortly after; roughly 2 hours later we were hit by an even stronger attack, leaving us with no choice but to call off the test.

It is a shame for the beta to end just 3 hours after it started, though we did verify that the server performance fixes most definitely worked.

The point? I assume you're talking about the fact that there were a large number of players in the server concurrently?

That may be the point, but it's only half the headline. The rest of the headline emphasizes that the devs are independent (you know, as opposed to professional), and they did this in their spare time (so they aren't getting paid for it).

Remove those elements from the headline, and I have no problem. But as it is, the headline is emphasizing them as if it's some amazing, unheard of feat that

Planetside had somewhere around 500 on one continent(server) at a time and that was almost 10 years ago and multiple thousands if the articles understanding (or definition) of "a server" being one realm or world is used. The article goes on to talk about how this is the first time there's been a Massively Multiplayer shoot-em' up style game and that it was some genius new idea by these two hobby programmers, I mean EUREKA a shooter MMO. Which is

Planetside lost some of it's original vision after heavily incorporating changes from forum complaints/suggestions. This had the net effect of removing strategic or skill based methods of achieving goals. Interestingly enough, with quick enough hands and some skill a BFR could be brought down from a hot drop mosquito. That of course was nerfed beyond recognition in the name of only equally classed entities should be able to really interact/combat with each other. No sir, your battle monger 5000 can't shoot

Indie developers in their spare time did something that the big game houses have been claiming was impossible for decades. "We can only support 4/8/16/32" has been the mantra of gaming companies for decades.

Now here a group of unpaid modders proves them spectacularly wrong.

The point of the article is half lost without factoring in that the people who accomplished it are not "professional, top tire game developers at the pinnacle of game research and captains of the gaming industry" but rather is 7 friends who decided to just do it.

Your combativeness towards this headline suggests that you missed the real point of it all.

Except that the big companies were limiting these games to 4/8/16/32 people not out of server demands, but most likely due to network constraints. Most of these FPS require you to have low latency with all of the other players in order to have fun. It sucks shooting at someone's head only to find out that you are shooting at where the person was and not where they really are. The more people you add to the game, the higher the chance that someone will have a poor experience due to latency. This is exace

I think you are looking at it from and upside down viewpoint. It's not just that a large number of players were in the server concurrently, it's also that a group of modders who are not tied to the big game industry, in their spare time demonstrated it was possible.

If this was just about a large number of people in a single server, it probably wouldn't even be news. That happens all the time with other types of servers. Why it is news is because industry dominant forces appear to think it isn't possible or

No it doesn't. There is no claim that PC gamers creating mods is unheard of.

It is emphasizing that some indie devs pulled off the multi player stuff in their spare time rather than a big budget game company. Which is pretty normal for a headline since part of the article is asking why game companies haven't done this already.

Early 1990s MUD games had telnet connections in the three digits. As in, handling raw character input from the players, not nicely aggregated packets from a client GUI. That was on hardware like Sun boxes that pale in processing power and memory size compared to... oh, your Jesus mobe, and such.

ahhhh yes brings back memories of playing my half blind dwarf gromit, he could see a distance of 1, if I wasn't in a group I wasn't able to find the other side of a room. From memory I was connecting from a VAX terminal. At the time MUD's stunned me with how powerful and complex a multi player gaming environment could be and was amazed to see so many people in the same game.

Could anybody give some details on how this was done? How do you hack multiplayer into a closed source game that doesn't have multiplayer support it? Decompile the thing? Find some unused engine hooks that allow multiplayer? Something completely different?

I took a course in game programming the summer of 2011. There was a guest lecturer who discussed something very much like this.

The idea was to have the playable area of the game divided into zones. Each zone would have a flexible border that could be moved around based on the quantity of the players. I think the idea was that each zone would roughly adjust to have an equal amount of players. Each zone, in turn, was responsible for the players within it. The game was specifically designed to handle FPS games

Oddly enough, I work for a company that's been selling an implementation a lot like that for over a decade now.

The problem has not been "how do we get 1800 players into a single play-space" for a long time now, between peer-to-peer, clustered computing, and dynamic spatial division. Zoning was a game play feature, not a technical requirement, by the time World of Warcraft shipped.

The problem now is "How do we make a single play-space fun for 1800 people at once?"

Oddly enough, I work for a company that's been selling an implementation a lot like that for over a decade now.

The problem has not been "how do we get 1800 players into a single play-space" for a long time now, between peer-to-peer, clustered computing, and dynamic spatial division. Zoning was a game play feature, not a technical requirement, by the time World of Warcraft shipped.

The problem now is "How do we make a single play-space fun for 1800 people at once?"

I haven't seen a good answer to that yet, and since I'm still working my way through JC1, I doubt I'll get a chance to see this one either...

(Posting anonymously to keep any commercial concerns abated)

wow, two anon cowards supposedly with solutions for scaling realtime games on consumer connections to thousands of people. YET NO PRODUCT MENTIONED! screw you guys, mention some done things. wow would have been hell of a lot better with your magic tech, instead of the technical scaling limits which ultimately lead to the realms being the size they are(in terms of player amounts, which dictates the designed world size in area so that it wasn't empty or too full).

I'll tell you why networking in video games sucks so much, is so easy to hack and scales so badly: it's simply not designed. The proper approach would be to think what should be the responsibilities of the client and what should be that of the server, then design an adequate protocol and write the server-side algorithms with scalability in mind. For example finding all players within one region is logarithmic in nature, and not sending information to clients that shouldn't have it is common sense, but don't