It looks like its built on top of irrlicht which probably brings in its own framework view of the world to begin with.
200+ lines functions happen MUCH MORE than you think in AAA code; why split a function if there's going to be a single static caller. John Carmack himself wrote about it a few years ago: http://number-none.com/blow/john_carmack_on_inlined_code.htm...
All the traits you list are superficial compared to getting the thing working and performing well in the first place :)
Heck these are the sort "clean code" practices which make your debug build run at 5 FPS (I've seen worse :). Indirections and conditionals and noise everywhere.
These get stripped in release (hopefully) but the catch is that you end up stepping in optimized code cause 5FPS can't get you where you want to test. Having all that nice cleanliness in a debug build you won't use isn't a great way to end up developing after 5 years of piling stuff up :)
Besides, you can design your systems so that they're both fast and simple; data-driven design is one such approach. Mike Acton talked about it a lot as well: https://www.youtube.com/watch?v=rX0ItVEVjHc
No. Quake and Doom were both extremely performance optimized, and still had clean code.
Avoiding commented-out or otherwise dead code; naming things well; writing concise but thorough comments that explain what's going on: none of those habits hurt performance.
Great code is not just meant to compile, it's meant to be read.
Inlining code manually should almost never be necessary today. Modern compilers inline automatically.
If you do feel the need to uglify code for performance, it should only happen after profiling, not as a habit.
There is no reason, performance or otherwise, to have the main entry point of your program or the render loop for your game be in a 5000 line spaghetti file.
It also doesn't have to be ugly; beauty should be in how it works not how it looks anyways. I would much, much rather focus on simplicity and let beauty emerge naturally. I've seen many projects fail even while following best practices all over the place.
Get its inner workings pretty first, then make the appearances pretty. Its incredibly harder if not outright impossible to do it in the opposite order.
If you think of performance after profiling for the first time, you've probably already wasted 90% of it without even realising it - the CPU is just that fast. Optimising at the macro level should be an habit; its the micro-level you want to optimise after profiling.
Most software today could easily be orders of magnitude faster. Doom and Quake just happen to be built on top of very well engineered foundations, which they then made pretty before releasing it to the world - it most likely wasn't that nice during development.
"(B)ig hairy ball of C++" or not, somehow it's optimized to the point that it feels more modern and advanced than Minecraft, if not as visually polished. My question is, is this purely a C++ vs Java thing? I've played some Java games that look and play awesome on older hardware so I have to wonder what the deal is with Minecraft.
Minecraft was simply never intended to be this big of a game. It was initially designed to be really just a game where you place blocks on other blocks. The Survival-mode, fighting against monsters etc., that was all gradually glued onto an architecture which wasn't intended for it.
One example that I happen to know, is that they never intended to have all these effects like smoke, water drops, the swirls from drinking a potion. All of this was pretty much just a hack for the longest time with no real place for it in the architecture. Eventually they fixed that and added it to the architecture, and could improve effects-performance massively with that, but there's probably still loads of things like that in the game.
Another big part of this is that Minecraft generates and loads its map in 2-dimensional chunks, or pillars if you will. So, when you move through the world, it always has to load in and keep loaded the entire height of the map, no matter if you're scraping along the clouds or if you're deep underground. If you're traveling into new terrain, it has to generate the entire height all at once, as well.
Minetest instead uses 3-dimensional chunks, i.e. cubes, and can just load/generate those freely how it needs them. So, if you're standing on a mountain and look down, it loads all visible chunks, but can just leave out those which are underground. Or if you're underground yourself, it can leave out really pretty much just all chunks altogether, except for the few which are directly around you.
This also has the effect that Minetest-maps can be unlimited in height, whereas Minecraft-maps need to be limited (currently 256 blocks; it started out at 128 blocks), as otherwise Minecraft would really just need infinite RAM and never get done with generating the map.
When Notch passed on maintainership of the code, he apparently didn't pass on his knowledge of how far you can push the JVM, and the new developers proceeded to "modernise" the code, by, for example, introducing a Point class. The amount of garbage Minecraft made went up very quickly as a result and it got slower.
There were a bunch of other glaring problems ... the fact that Optifine is able to improve it so much shows, I think, that the developers didn't fully understand Java performance.
As for your C++ vs Java question... put very simply, C++ will be faster than languages like Java when it comes to graphics and any software that is close to the hardware.
Well, I should have been more accurate: I'm not a programmer by trade, but I do understand the basic concepts of computer programming, and I've dabbled with both high level and low level languages. I've even done some assembly programming in the distant past, about 20 years ago, just to learn it, as well as a stint with SQL/400 on the AS/400 about 14 years ago. But these days the closest I come is bash scripting or dabbling in Python or Lua. I've never messed with C/C++ or Java though, hence my questions directed at those languages.
All that said, I do appreciate your response!
--
People have made some VERY COOL stuff using MineTest.
Check out spheretest: https://www.youtube.com/watch?v=ztAg643gJBA
--
I just tried reading the code to learn how MineTest does voxel meshing, and it didn't go so well.
(Voxel meshing is about turning blocks into triangles efficiently, and it's surprisingly tricky. Mikola Lysenko wrote a great exposition of the problem and several solutions way back in 2012: https://0fps.net/2012/06/30/meshing-in-a-minecraft-game/ )
I was curious which approach MineTest chose, and I still don't know. I think I found the files where the meshing happens, mapblock_mesh.h/cpp. The code quality is... less than perfect.
There are 200+ line C++ functions. There's commented out code and preprocessor "#if 0" ignored code.
There's a struct that looks important, but it's called "MeshMakeData", and I don't know what it represents. The comment above just says "Mesh making stuff":
https://github.com/minetest/minetest/blob/0a16e53b40d347db7d...
The file that seems to run everything, game.cpp, is almost 5000 lines long.
--
For an example of really clean game code, check out Quake or Doom 3. Both have:
* short and sweet main() methods
* comments that guide the reader and explain what does what
* clean decomposition
* short, readable functions, and...
* reasonably small files
So far, MineTest, at least in part, took the "big hairy ball of C++" approach.
Good luck with future development!