Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the EVE Online Servers Deal with a 3,000 Person Battle

penny-arcade.com

Post reply on HN
Print view View original

121–130 of 135 posts

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#121

Post by halfasleep »

jere wrote: post #53

[Edit: this comment turned out not to really be about Eve and more about the difficulty of real time MMOs] This blows my mind. I've been thinking about writing a small multiplayer game for a few weeks. And today I was actually doing back of the napkin calculations. The thing that quickly became clear is bandwidth is O(n^2) where n is the number of players in the same location, since you have to share the location and…

There's some pretty detailed information about the Unreal Engine [1] that might give you some ideas to think about around network protocols for games. At the time they were dealing with 28.8k modems, so there are quite a few tricks in there about saving bandwidth and prioritising some actions over others. [1] http://udn.epicgames.com/Three/NetworkingOverview.html

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#122

Post by vacri »

incision wrote: post #27
outworlder wrote: post #15

Earlier quoted context omitted.

400k+ active players IS a huge number. Specially considering they are in the same logical server. Other MMO's handle this by having copies of the world and splitting the population - which is the same approach used by Ultima Online back in 1997. So actually, EVE is way ahead of the rest, technology-wise.

>So actually, EVE is way ahead of the rest, technology-wise. That doesn't seem like a sensible comparison considering how much the gameplay of EvE differs from the typical MMO. In any case, I'm not making a dig at EvE, rather acknowledging that the game has had a long life and has never been a multi-million subscriber behemoth. Therefore, they might make concessions, or allowed the persistence of previous limitations…

400k subscribing users is a great big pile of cash to work with.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#123

Post by mseebach »

On moving the game to a beefier server: “This is the machine that systems get reinforced on when players request that. Unfortunately, the same thing above applies – anyone in the system when the move happens gets disconnected. Because of this, it’s basically never done,”

It seems like a fairly small addition to the game logic to allow the game to freeze for a few seconds and be forcibly moved to another server. Is this kind of scenario so rare that it's not worth the trouble, or am I missing something else?

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#124

Post by CJefferson »

mseebach wrote: post #123

On moving the game to a beefier server: “This is the machine that systems get reinforced on when players request that. Unfortunately, the same thing above applies – anyone in the system when the move happens gets disconnected. Because of this, it’s basically never done,” It seems like a fairly small addition to the game logic to allow the game to freeze for a few seconds and be forcibly moved to another server. Is th…

The problem (I believe) is that they don't have a way to 'freeze' and transfer a running game. Think of it like any program -- it is easy to "save your work" and load the file on another computer. It's much harder to exactly save the state of all parts of a running program and transfer that to another computer. Each user is represented by a stackless python program, these are hard to shut down and move.

As you say, it could probably be done, but it would be a lot of work, which wouldn't get used very often.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#125

Post by warfangle »

rauljara wrote: post #8

The report of the battle they link to ( http://www.pcgamer.com/2013/01/28/eve-online-battle-asakai/ ) is even more fascinating to me. You spend hours and hours of effort in order to get a ship, and one way of thinking about them is as the time spent to earn them compressed into 3d form. Unlike (most) other MMO's, battles actually destroy things. So in that youtube clip, you're watching years and years of effort getti…

In EVE, you have to think of your ships as ammo.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#126

Post by archon »

CJefferson wrote: post #124
mseebach wrote: post #123

On moving the game to a beefier server: “This is the machine that systems get reinforced on when players request that. Unfortunately, the same thing above applies – anyone in the system when the move happens gets disconnected. Because of this, it’s basically never done,” It seems like a fairly small addition to the game logic to allow the game to freeze for a few seconds and be forcibly moved to another server. Is th…

The problem (I believe) is that they don't have a way to 'freeze' and transfer a running game. Think of it like any program -- it is easy to "save your work" and load the file on another computer. It's much harder to exactly save the state of all parts of a running program and transfer that to another computer. Each user is represented by a stackless python program, these are hard to shut down and move. As you say, i…

The other problem is that they would have to 'pause' the entire game while the physical move was in progress, otherwise players would still be able to move around in the rest of the game world (other than the cluster of stars they took offline to move them). As I understand it, this is already sort of a problem with the Time Dilation mechanic they currently use; time moves at 10% normal within the fight, giving people outside the slowed-down star systems time to deploy forces at 10x speed relative to the fight.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#128

Post by kalleboo »

dclowd9901 wrote: post #69
alexkus wrote: post #38

Earlier quoted context omitted.

Two main solutions (given that the article mentions that they have huge machines already):- A) Allow a single solar system to span multiple machines. Very hard, especially if the server software isn't architected for this. Retrofitting this can be nigh on impossible. B) Have a few huge machines that can be used to host scenarios like this and, more importantly, have a way of migrating users over to the huge machine s…

Option 4C) Create a raspberry pi cluster farm, and host every player with one microserver.

How would the microservers keep up to date with each other fast enough to be useful? "eventual consistency" doesn't work with real time strategy games.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#129

Post by Scramblejams »

Draiken wrote: post #83

The environment EVE creates in almost every aspect of the game is just fascinating. It is the only game I ever played I actually felt an enormous thrill and adrenaline rush when playing pvp. It doesn't matter if you're pvping alone or with a fleet. The fact that you actually lose/gain on a fight differentiates the game from any other MMO. Events that you may have experienced in-game can be recorded forever and actual…

"The fact that you actually lose/gain on a fight differentiates the game from any other MMO."

Could you please expand on this? I'm interested in this point, but I haven't played Eve or other MMOs.

Re: How the EVE Online Servers Deal with a 3,000 Person Battle

#130

Post by dclowd9901 »

kalleboo wrote: post #128
dclowd9901 wrote: post #69

Earlier quoted context omitted.

Option 4C) Create a raspberry pi cluster farm, and host every player with one microserver.

How would the microservers keep up to date with each other fast enough to be useful? "eventual consistency" doesn't work with real time strategy games.

How would they not? Latency between servers would be near zero, and if they all handled point to point transactions while broadcasting their state on each transaction, you're getting all the power you need. We're not talking about complex processing here. It's an RNG coupled with simple health and xyz.
Post reply on HN