Hacker News Reader

Comment by asiekierka | Hacker News Reader

>I hope you make it so that only the surface blocks are sent to the client. The time it takes to "mine" a block is enough for the latency to send the block behind it.

Orebfuscator or Spigot.

>Also, send the input to the server, and not the position/speed vectors. That way you will also get rid of the speed hacks.

What? No. You can't make sure everyone moves the same way, and this would undoubtedly lead to desyncs. If you want to make sure players don't move too fast, use NoCheatPlus or what it was called.

A far bigger issue for servers is mods like Gammabright which make all blocks have a brightness of 15, thus not requiring you to use torches or light sources, as that's very hard to work around.

View on HN

Gameplay penalties can work wonders against Gammabright.

Spending a lot of time in the darkness? enjoy blindness, nausea effect and being on fire next time you venture topside while the sun is out.

http://fabiensanglard.net/quake3/network.php

Quake III was doing server-side calculated game state 16 years ago stupid fast for 32 players moving quickly on dial-up modems; I doubt it'd be much of a problem to do these days with even a lousy architecture for a game with much much slower movement, e.g. Minecraft.

This problem has been solved pretty well many many times before.

The big difference is that the map in Minecraft is constantly changing which can in turn change players position and potential actions - Quake 3 was comparitively much simpler, more or less just a coordinate and velocity vector.

But I agree, there is no reason for Minecraft performance to be so bad when there are only 2 people on a server just mining one brick at a time!

> The big difference is that the map in Minecraft is constantly changing

Not quite. The map in Minecraft changes. But if you optimize the game for the "constantly changing" case, when it usually changes less than 1 block per user per 10 seconds (and even that is high), then you're going to end up with code that doesn't handle normal behavior very well.

The speed of light has not improved since the days of Quake 3. Network gaming code must still be tolerant of latency up to 100 ms or more. At best, network connections today are a lot better than back then but at worst, they are as bad as they used to.

Quake 3 has also got pretty sophisticated client side prediction code to make things seem instantaneous to the players. This is much more complicated to do in Minecraft where the whole terrain may change and lots of race conditions may arise.

Network game code may seem like a solved problem but it's still a complex distributed soft real time software system where solutions are highly application specific. What works for Quake isn't necessarily good for Command and Conquer or Minecraft.

Reply on news.ycombinator.com