Hacker News new | past | comments | ask | show | jobs | submit login

Judging Minecraft by its blocky world is very unfair and shortsighted.

Game world is not only de-facto voxels. Its transparent, masked and oblique voxels that interact with each other or other entities, like farm blocks by water blocks, lava blocks with burnable blocks nearby, plants growing up, hostile mobs spawns and lines of sights, mobs pathing as they follow player, fellow mobs or random points of interest for wandering, etc ect.




What makes you think I was judging Minecraft solely based on its low-detail graphics? Yes, its rendering code has historically been comically inefficient to the point that third-party hacks have made huge differences in frame rate and usable draw distance, but that's hardly the only thing Minecraft implements poorly.

The combination of using Java and being coded naively means that there's a huge amount of pointer chasing and unnecessary dynamic memory allocation that can be easily cut out without even needing to dip into the data structures and algorithms literature to try for asymptotic improvements. There's no SIMD and no concern for cache locality. Last time I checked, it didn't even look like terrain generation was done in a separate thread from the interactive game logic, let alone in multiple threads. The game only simulates dynamics within ~128 blocks of a player, but if you've got two players miles apart they're still simulated on the same thread.

I do fully understand that the dynamic modifiability of Minecraft's game world means that it is always going to be hungry for memory bandwidth and will be latency-sensitive. But that doesn't mean it has to be inefficient. The Pocket Edition (not Java) already showed that huge improvements are possible, because they were necessary to get anything resembling Minecraft onto mobile platforms. There's a lot more that can be done when you're back on a platform that has sufficient RAM capacity and a ton more CPU power relative to RAM speed. There's a lot of latency that can be eliminated and a lot more than can be hidden from the user without breaking the game. The development process meant that hardly any of the early fundamental implementation decisions were made with the much later features in mind.


I think notch's success proves that it's better to make something than whine about how it's implemented


Imagine a gentle world in which the person you're responding to is merely commenting on the relative ease with which Minecraft could be optimized, and pointing out some of the reasons for this, without casting aspersions on anybody or complaining about anything. Would such a world necessarily look different from ours? Would it be inconsistent with the comments in this thread?


It's not even commenting that "Minecraft -could- be optimized", it's that "Minecraft -has- been optimized (for the mobile platforms)".


Only if your barometer of success is a monetary one. I happen to like playing Minecraft when I'm not making something and killing it and iterating (yeah bruv), and it makes my future computer from beyond the moon chug at times. (I don't point the blame at Java nearly as much as at the naivete of its development, however, and it has gotten somewhat better over time.)


I used to develop my apps on 5-10 year old computers for precisely this reason. Their limited cache, RAM, etc would show both hotspots and trouble spots fast because the app visibly couldnt perform well (or crashed lol). Ignoring microoptimizations, algorithmic and architectural changes benefiting old PC often made new one scream with performance.


I've worked in computer graphics for a long time and to be honest, I've never seen any performance problems that you're describing. Rendering is smooth even with complex scenes.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: