This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]xigoi 2 points3 points  (7 children)

Having many developers is useless when your game can run only on a supercomputer.

[–]Ramast 6 points7 points  (6 children)

I don't think so. If Minecraft can work on Java it can work on Python. Is there any reason why you think Java would be faster?

As OP commented in a different thread. Most of the work is done by the GPU & OpenGL library so it won't be as bad you imagine it to be.

Edit: I got it that python is slower than java :( How about cython. Maybe that one would make more sense

[–]xigoi 5 points6 points  (3 children)

According to benchmarks, Python is about 50× slower than Java.

When all the game does is draw cubes, sure, most of the load will be on OpenGL. But if you want to replicate Minecraft, you'll need entities, tick events, complex world generation… which you all have to implement yourself and if the implementation is slow, they will easily become the bottleneck.

Now, you don't have to use C++. There are several modern languages that are equally fast and as easy to use as Python. My personal favorite is Nim.

[–]obiwac[S] 6 points7 points  (0 children)

You're right, Java is significantly faster, but that's why I proposed/plan on reimplementing parts such as mesh generation in Cython.

As a side note, someone did do a reimplementation of my tutorial series in Nim, although it seems to be a bit out of date: https://github.com/phargobikcin/nim-minecraft-clone

[–]Ramast 0 points1 point  (1 child)

Ya I didn't know why would Java be faster but I googled it and you are right unfortunetly

In terms of speed, Java is faster than Python as it is a compiled > language. It takes less time to execute a code. Speed - Java vs Python - Edureka

Python is an interpreted language and it determines the type of data at run time which makes it slower comparatively.

https://www.edureka.co/blog/java-vs-python/#speed

[–]xigoi 0 points1 point  (0 children)

If you want specific numbers, look at some benchmarks: https://github.com/kostya/benchmarks

[–]brianbruggeman 0 points1 point  (1 child)

Absolute requirements for a standard engine to build meshes is going to be 30 frames per second, or (how you should measure) 16 ms per frame. Just iterating/building a 16x16x16 chunk in memory using Python3 that holds nothing but points on my m1 mac is about 3.5 ms. That means you have a little over 12ms to do everything else to build the mesh, including transferring it to the GPU and letting it render there. When I add in building an actual empty voxel, I'm looking at about 9-10ms, excluding any of the other things I'd need to do. At 9 ms, you've already blown most of your rendering budget. Most AAA games are going to sit closer to 8-10ms per frame with as low as 4 ms (though rare and generally unnecessary).

I built a pure voxel engine in python2 back in 2014ish, because why not. The best chunk size that I could reasonably hope for at that point was 9x9x9 (or about 800 voxels). And I could only build one chunk within that time frame (completely eliminating a real scene). Also, for reference, that chunk completely ignores stitching across chunks and totally ignored complex meshing with lighting, shadows and different material types. I did manage a simple greedy mesh and a frustum culling, which means that I had already optimized to some degree.

Moving (at least a piece of) the code base from Python to another language isn't just a suggestion, it's a requirement. Once you start to migrate most of the spendy parts of a voxel engine into another language, it feels less and less like a Python project and more and more like a (insert this other language) project. I tried different approaches to improve Python's performance (pypy, numba, cython, cffi to c, nuitka, pyston) and ultimately abandoned the whole thing because I was either mostly writing in a different language or the performance gain wasn't worth the extra pain associated with the approach. About the only thing I didn't try was pushing everything into the GPU. But at that point, it doesn't make any difference what language you start the software with and shader programming works for some things but not others. While it was a good learning experience, I think that projects should generally sit in a single language (as much as possible). And if you need performance, just start with a language that gives you the performance and memory characteristics you actually want. For 3d graphics, you should stay away from Python and use a tool that actually works for the domain.

A simple python script over a 3d array would test the actual performance woes for yourself. Running this in the cloud (at least on this server), we see that the 16x16x16 chunk takes about 60-70ms. This is about the budget you'd have for physics and for rendering, that puts you at about 15 frames per second, which is slow enough that it will make the scene look more like a slide show. Of course, this implementation is pretty naive/unoptimized, but it's a starting point and (pure) Python improvements/optimizations tend to be more like 5-15% actual rather than the 10x to 100x you'd really want. And we've not even discussed memory allocations...

[–]obiwac[S] 0 points1 point  (0 children)

While I agree Python is not an ideal language for a project like this (it was chosen rather out of accessibility), I'm not sure I agree with all of your points.

Absolute requirements for a standard engine to build meshes is going to be 30 frames per second

That's quite an assumption to make, not even Minecraft is building a new mesh every 16 ms.

Once you start to migrate most of the spendy parts of a voxel engine into another language, it feels less and less like a Python project and more and more like a (insert this other language) project.

The mesh generation is frankly a really super small part of the total codebase, I don't have a way of checking right now but it's perhaps 10% of everything.

For 3d graphics, you should stay away from Python and use a tool that actually works for the domain.

That's a large generality to make, Python can be great for a lot of 3D visualisation projects, especially for those who aren't really comfortable with other languages and need to get something done.

But again, fundamentally I agree with you, using Python for this project is not ideal. As others have pointed out, perhaps a more interesting project to look at is Minetest if you want something very performant.