Hacker News Reader

Comment by gnarbarian | Hacker News Reader

I think one thing Eve has going for it (and this is only an assumption) is that it wouldn't need to sync each player's position on each frame. It could reduce the load dramatically by only sending the acceleration / orientation data for a ship.

So if a ship has set a course and has stopped accelerating it doesn't need to send anything else unless that course is changed.

View on HN

This is exactly how these types of problems are solved. Local clients run simulations based on known locations/directions, and are synced with the central server at a specified interval.

This allows a client to have a light-weight "cached" view of the reality, and the only trade-off is the occasional discrepancy from the reality. However, if you send updates about changes in speed/directions in real time, you get a pretty reliable representation of the state known by the server.

Sure. It's commonly called dead reckoning as I understand it: http://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_f...

But even if you only send a "real" update once a second, I still don't see how this thing scales (that still leaves 1 PB in the above calculation). And if you send it less than that, I imagine things would start to look rather jittery. The "occasional discrepancy form reality" would be awful.

It depends. If you have 3000 clients and a full sync of all visible ships occurs every second, you get 3000 * 48 = approx 150kb/sec/client. Yes, that means that the server must be able to handle 3000 times that speed, but that still leaves us at about 0.5gbit. Yes, it's a very high load, but then again, these types of situations are extraordinary.

Last but not least, compression is your friend.

Depending on the game (it's been 10 years for me) one 'hack' was to head in one direction, pull the network connection for 3-4 seconds, head in the opposite direction, and plug back in. This allowed you to escape or hide in the terrain fairly reliably.

With higher bandwidths and server capacities I'm guessing these timeouts have been reduced, but never underestimate the player's ability to abuse your trade-offs.

There was an exploit in eve sort of like this. What you did was start warping toward a planet on the far side of the solar system and then kill the application as you got close to it.

The effect was to allow you to sling shot past the destination at warp speed, and if you logged back in at teh right time (seconds later) you could setup a waypoint far outside the outermost celestial body.

(Normally you can only warp to planets and moons, etc... you can't just pick an arbitrary direction and engage warp).

That problem is not because of the trade off. The problem is that the server believe the player's client when it provided an updated location. The 'correct' behavior in this case would be that the server resyncs the client, and the player observe's his ship jump to where the server thinks it should be.

And in Eve, this is even more feasible because, unlike an FPS or even MMO's like WoW, movement is generally slow and controlled. You don't have direct control over your ship; instead, you can only issue commands like 'head for this waypoint', 'orbit this point of interest', etcetera. This would, I think, greatly simplify server communication of movement and such, compared to direct user input where they could change their orientation much more suddenly.

I haven't really played Eve, so I can't say. I'm imagining ships flying around and changing course constantly in a battle, but if someone can give a better description, I'd appreciate it. It'd be further reduced by several players sharing a ship... no idea how common that is.

What I'm describing is definitely leaning more towards players that are constantly moving around though. It helps explain to me why in Asheron's Call, for instance, when you had too many people in the same city a "portal storm" arose and people started getting teleported out of the city randomly.

I also have been toying around with trying to create a MMO fast action space simulation of my own creation. I have a few ideas on how to limit areas of dense players with game mechanics. I haven't even really started on multiplayer beyond the ability to download modify and upload solar systems though.

I think for some really hard engineering problems like this the best course could be to try and find a 'good enough' approach that will allow a significant ammount of players to interact while limiting the upper bound with a game mechanic to make it feel less artificial.

http://code.google.com/p/stableorbit

here are a couple videos from the never ending pyopencl port.

http://www.youtube.com/watch?v=lnOmy1ly6M0 http://www.youtube.com/watch?v=XCvRBHtPbzE

Eve's gameplay could be represented as a text based game, it is not a fast paced space shooting game.

Eve doesn't have WASD controls, there really isn't constant input.

The ship movement command in Eve are limited to:

* Set course / speed (double clicking in space, speed set via clicking a speed dial thing). This is not something that gets constant tweaks, more a 'move in a general direction' command.

* Orbit x @ y distance

* Keep x @ y distance

* Approach x

In addition other actions in eve are relatively long lived, there isn't fps style aiming but 'locking on' and activating modules which have cycles times of 2-60 seconds.

In practice, even in the heat of battle, I doubt the average player gets even close to 1 input action per second over the course of a fight.

If you check the video you'll see it's very slow paced and the ships basically don't seem to move at all (maybe tiny unseen ones do I don't know)

http://www.pcgamer.com/2013/01/28/eve-online-battle-asakai/

Part of the reason it is so slow is that (as mentioned in the article) the server slows time down (as far as 10% of normal) in order to ensure that nothing gets lost.

Combat in Eve is more D&D and less Wing commander. When I played (a few years ago) you would get text based messages pop up saying stuff like "X hits Y for 38 damage"

My guess is they only sync location on transaction (when you fire upon/are fired upon).

And even that can be optimized away - after all, in Eve, you basically issue commands like 'lock onto this ship' and 'activate this cannon', which will then fire every X seconds - all each client has to know is the target, ship information, and a toggle command for a given weapon, the rest can then be determined completely on the client-side when it comes to the visuals. Every X ticks, data (like health) of the target ship can be sent through - although I reckon that too would be optimized away and only sent on-demand, i.e. when the user actually selects the ship under attack.

Reply on news.ycombinator.com