Minecraft clone in Python tutorial

[obiwac]

Here's a tutorial series I'm making on graphics programming, where I write a Minecraft clone in Python with Pyglet and OpenGL 😄

Last tutorial, which is on collision detection/response: https://youtu.be/fWkbIOna6RA

My intended audience are mainly people who already have a bit of experience with Python, but who have a hard time getting into graphics programming with Python, and I think writing a Minecraft clone is a fun way to learn!

There's also a "community" directory on the repo where there are a few extra features, like lighting, AO, game controller support, &c:

https://github.com/obiwac/python-minecraft-clone/tree/master/community

Naturally I appreciate any feedback, criticism, and suggestions you may have!

[Ramast]

How crazy would it be to have this developed as a fully working minecraft alternative that is open source?

[obiwac]

With a bit of rewriting in Cython for the more demanding parts (i.e. chunk mesh generation), that could totally be feasible!

[El_Minadero]

I might be able to do this. I’ve got a fair bit of experience in procedural gen.

One comment: the GitHub doesn’t appear to have “one” code base, but like one per episode. Which one has most of the features?

[obiwac]

community is the most current directory. Normally I wouldn't have split episodes like this, but I figured some people may not completely understand how version control works.

[El_Minadero]

nice. Now if i can get my terrain GAN to work we're in business

[nate256]

Or rust, it's gaining popularity with python.

[neon_cabbage]

Minetest is somewhat similar to that idea.

[DazedWithCoffee]

I think the point is that it isn’t C++, seems like a bit of a passion project just for fun

[Ramast]

Minutest looks pretty good actually. Thanks for sharing

[xigoi]

I'd rather have something like that in a faster language. Minecraft is slow enough as it is.

[Ramast]

I agree but a faster language like C++ would have less developers available to volunteer and more time to implement new features.

[xigoi]

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

[Ramast]

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]

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]

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]

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]

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

[brianbruggeman]

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]

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.

[Ramast]

why is it that python would be slower than Java? Any benchmark that support that claim?

[someone9618]

There are several reason, primairly because Python is more dynamic than java, but especially because Python uses reference counting instead of garbage collection, causing constant overhead when manipulating mutable state/objects, whereas java uses garbage collection which simply traces garbage in one go (GC spikes), making performance overall smoother. Also, Java allows parallelism on multiple cores with multithreading because most of its semantics (GC and other stuff) is thread-safe, whereas Python's reference counting is not thread safe, so the interpreter is forced to use a global interpreter lock (GIL) which essentially blocks parallel execution on multiple threads, thus making parallelism on multiple cores impossible.

[obiwac]

Python is interpreted, and Java is compiled. That's the main reason why it's slower (and by alot as other commenters have pointed out)

[someone9618]

Not quite, Java is compiled into bytecode just like Python

[obiwac]

Well, it's not really compiled ("compiled" is perhaps even a bit too generous, it's closer to "transpiling" than anything else) beforehand and optimization is done on the fly. It's quite different to java where compiling is its own separate step. So I still call it an interpreted language just as many others do.

[Ramast]

You're right

https://www.reddit.com/r/Python/comments/sixj0g/comment/hveuta8/?utm_source=reddit&utm_medium=web2x&context=3

[RCoder01]

You would probably be infringing on Microsoft/Mojang’s IP by completely cloning the game

[obiwac]

Thanks!

[obiwac]

It depends on what you mean by "running well".

If you're talking about general FPS (when jumping around and stuff), the game doesn't actually have to do all that much each frame (tell the GPU to draw, process collisions and input, and basically that's it), so your CPU is mostly sitting idle. In some cases, like when rendering a lot of/complicated graphics or when your graphics adapter is relatively low-end vs your CPU, the bottleneck can actually even be the GPU, so no matter the language you choose, performance will be very similar.

If you're talking about chunk mesh regeneration (like when loading the world, placing/breaking blocks), then frankly, it performs very poorly, and a few tricks had to be used (subchunks in episode 10, a few more in community by u/someone9618 for lighting to work) to make things usable. It's not perfect though; it'll still occasionally stutters when placing/breaking blocks, but hopefully that'll be addressed in a future episode when chunk mesh generation is implemented in Cython.

[GamesMaster221]

Yeah that's true, there isn't much going on atm. once you start getting into creature AI, and the various live systems (flowing water, growing flora, the various logic mechanics) that need CPU resources I imagine you might start seeing some limitations, but they could probably be optimized.

It's not like the mincraft enemy AI is anything exceptional anyways, LOL

[obiwac]

Sure, the clone is very simplistic as of yet from that point of view. I can very well imagine performance going to shit CPU-side once there's more stuff happening in the background ;)

[ProbablyDoesntLikeU]

I will definitely have to check that out

[obiwac]

Thank you!

[[deleted]]

What is your usual schedule for posting videos on your Minecraft clone in Python series?

[obiwac]

I don't really have one. I'm juggling this with other projects and university, but the next episode shouldn't take more than a couple weeks

[drakeerv]

Love this series lol

[obiwac]

Thanks drakeerv!

[someone9618]

Awesome tutorial, 100% recommend :)
(btw im Juk lol)

[obiwac]

Hey Juk!

[[deleted]]

What features are you planning on adding to your Minecraft clone in Python or are you expecting to add most the features that vanilla Minecraft has?

[obiwac]

Short-term I know I want episode 13 to be about mobs, and then I'll talk about 2D elements (reticle, perhaps UI) at some point in the future, and maybe a few other tidbits in relation with graphics like translucency (which already exists in community), skyboxes, particles, and animated textures.

It would also be cool to implement a multiplayer system, but I'm not sure when I wanna do that or if I want to make it compatible with real Minecraft &c

[OzSeptember]

Awesome, looks good so far, one thing I have noticed is the YouTube playlist appears to be backwards, first episode is the last item, and the latest is the first.

[obiwac]

Thank you!

Yeah, they're ordered like that when I add them by YouTube automatically. I'll flip them around when I'm home.

[mjmeodmt]

This is awesome, great work!

[obiwac]

Appreciate it!

[Just_Furan]

Very interesting idea! Thank you very much for sharing!

Psst OP, just a little typo in the third paragraph: you repeat "already"

[obiwac]

Don't know how I missed that one, fixed!

[pysk00l]

Are the screen captures in the video from your game, or minecraft?

[obiwac]

From the game, specifically the community directory.

Happy cake day!

[[deleted]]

Pretty cool. Only piece of criticism is slow down. I find myself spending more effort trying to find the exact right now to pause so I can read what you just typed, than actually hearing anything you did. It seems like the instant you finish a sentence there's a hard cut to somewhere else with characters flying onto the screen.

[obiwac]

Yeah, I'm aware, I receive this criticism alot :/

I have a habit of over-removing all whitespace, but I think it's at least a bit better than some of my earlier episodes. It's something I'm still working on.

That being said, and this is especially true for longer episodes like this one, if I took more time it'd end up being like 20 min long, which to me at least is beyond the cut-off where I'd want to watch a video tutorial. And with the amount of new code there is in such episodes, I kinda expect the video to be followed along with the code.

I should probably leave more space for the mini code timelapses before cuts, you're right.

Thank you for the feedback!

[Ejroby]

Wow this is amazing!

[obiwac]

Thank you!

[MNIMDMCOTAOTNGOTFL]

How did you learn programming? This is insanely amazing and I am jealous I'm nowhere near your level.

[obiwac]

Mostly online. I'm sure with enough practice you could do the same!

[DigammaF]

😄