If someone were to make something like this a step-by-step tutorial/template appropriate for a classroom setting it would be huge. Imagine a class at High School where you start off learning the basics of Python for the first few weeks and the rest of the semester is spent writing the chunks of code into a template that has lots of notes for guidance.
I'd image something like :
# recall that this is a function that takes in a variable called 'color' as its argument, write the code that will set the current game files configuration file to either 'red', 'blue' or 'green' (p.s. DONT FORGET TO INDENT YOUR CODE!)
Just writing this function and seeing it work once you load up the game is enough to hook almost anyone that has the potential to enjoy programming but just doesn't know it yet.
> If someone were to make something like this a step-by-step tutorial/template appropriate for a classroom setting it would be HUGE.
(emphasis mine :-))
That's the first thing I thought. I teach kids to do creative/interesting things with computers. It's hard to get them writing code (it's not a classroom--they come voluntarily and explore what technology topics they like), one of the older (14) kids started out doing that, however, because he wanted to write Minecraft mods. Those are written in Java, in an Eclipse environment working on a decompiled (and only partially annotated) version of the Minecraft .jar. That was not how I envisioned a gentle introduction to computer-programming :) But he was persistent, and got it to work. This only goes to show what's really important: not if the language is simple, complex, elegant, whether the subject matter is easy to grasp, no. It's just a matter of whether the thing they need to learn is on the path towards a goal they really really want to achieve.
But yes, Minecraft is a huge thing among these kids. Others are cobbling together multi-player servers from scrap computers.
While in a sense, brooksbp (sibling comment) is right, there's a LOT going on in these 580 lines of code (I haven't looked at it yet, but I can imagine), 580 lines is not that much either. And if it's something they can run, edit, run, mess around with, see why it broke, edit, run, etc, that's enough to get started. They don't need to understand the whole thing right away. In fact even something as simple (and hardly programming) as changing the colour or textures is awesome because it teaches them that whatever's going on behind those graphics is yours and yours to control (unlike, say, the TV or their aunt's iPhone).
That 14 year-old kid is currently experimenting with Unity, trying to make an actual game. Unfortunately, I haven't had time to get acquainted with that environment myself, so I can only give him general advice. I'm way more comfortable with Python (especially a mere 580 lines of it :P) so who knows.
 Which still mystifies me, I was writing my first lines of BASIC at the age of 9, without help from my parents or anyone except library books and magazines. That probably makes me an outlier, but enough children pass through here that I'd expect to see at least maybe one or two. I guess it's different because back then that machine (an Amstrad PCW) wouldn't do anything interesting except word-processing unless I coded it myself.
 That was actually a big lesson for me :) I kind of knew it to be the case, but witnessing the process really nailed it down for me.
I've been teaching my oldest kid (14) programming. By far the toughest problem is finding or developing motivation. Kids have too many interesting things pulling at them these days. Programming can be very dull and confusing until you have a good arsenal of tools and patterns in your head. That also works against developing motivation. It's simply not interesting.
Thankfully we do other things. I was able to use the example of when he learned to fly model airplanes to show why he had to push through the stuff that's just not fun to be able to reach for the good stuff. I reminded him of the work we had to do for him to be able to fly and land solo before he could start on fun aerobatics.
This is why I would suggest simply converting something like this to a tutorial might not guarantee engagement. You need to really think through the "fun and interesting" factor both during and after the course. Not easy.
There was an awful lot happening behind my very first program too. And that was the available level of abstraction. Why start kids coding something so simple when they can mess with something so powerful?
I definitely agree, I graduated with BS in Computer Science but never touched 3D (only 2D game design). Although if I had, I probably would be a lot further than I am now. High expectations, but the results could be amazing.
As something for beginners, this would be great. When you start learning a new skill, it's important to have that feeling of tangible achievement to keep students motivated. Anyone interested enough to pursue a career in game dev will dig into pyglet to understand what's happening, as they start to push the limits of the knowledge gained from this kind of exercise.
And then here's the other nice lesson: students can learn that they don't need to know everything before they start making cool and useful stuff. The confidence that comes from knowing that is just as important (more so?) as being able to implement pyglet from scratch if necessary. The former is a skill used daily, whereas the latter -- well, consider how often in your engineering career you casually rely on the work of others to power your creation. Has anyone ever required you to write a WSGI implementation, or a framework?
Wow, that just brought back a massive flash from the past. I actually remembered how I felt then I wrote those lines (or something very similar) for the first time. It's a powerful feeling. Thanks for that.
As a country the USA needs much more top down (you can do this now! don't you wanna learn how?) rather than bottom up (learn all this math, all these concepts, all this stuff over here, then do it all again for in college, then gradschool and maybe you'll make more money in 20years) education.
I used a variant of this code for a project for my students. Just had to clean it up a bit and organize the code into parts they should be reading (game logic) and parts they should ignore unless they're really curious (mostly the OpenGL stuff).
Please, if you have a link or would agree to send us a copy on request, that would be amazing. I haven't seen the code yet, so I don't know how badly it is needed, but I am definitely going to use this project for teaching programming. And if you already have a cleaned-up version, that would be a great help.
If, for some reason you don't want to link the code here, I put my email in my profile info.
Pyglet is vastly more pythonic than pygame for writing games. I have found it much easier to teach pyglet for newcomers and the code is easier to read too. Since it uses ctypes, it is very easy to port pyglet to a platform that supports OpenGL.
Unfortunately there is very little momentum in the project. Last year an alpha version was released after a gap of two years. I truly hope that pyglet gets the popularity it deserves.
I'm exactly the opposite. Whenever I see a project consisting of 50,000 lines of code, I am amazed that somebody had the stamina to bite down and actually write all that code.
I could never imagine myself writing 50,000 lines, I'm way too lazy for that. Fifty-thousand lines? You could write a universe in that, with a high-level language like Python (or in assembly, a smallish planet).
Semi-kidding aside, it's part laziness and part DRY-principle. I hate writing code twice, even if it's two chunks with similar functionality. If they are so similar (in an abstract way), there's probably a reason for that, and I try to capture that reason into my code by unraveling the similar parts from the specific parts. That usually makes it smaller.
Can you imagine what happens if those 50K lines (comments/white-space aside) all implement nearly unique functionality? Those 64k demos linked upthread are what happens. I'm going to guess those are 100K-250K lines C++ , maybe? But then, a prize-winning 64k probably does a little bit more than a basic partial Minecraft engine :-P
Since you're asking "how do their minds work?", maybe I can get a little bit obsessive over this optimizing (wouldn't call it OCD--that would trivialize the disorder), but I do really get a slight "mind itch" if I notice code with duplicate functionality.
 Sometimes it doesn't. But often there's other advantages, too. If that's not the case either (or I'm on a deadline), I grit my teeth and write the duplicate code, but I try to make it really obvious that it is duplicate. That way at least it'll compress well :P
 Not even the 4K demos use pure assembly any more, compiler tricks and exe packers have become amazing in the past decade since I stopped making them. Not counting the external procedural/generative design tools/Werkzeuge, btw.
Most "Doom clones" just showed static maps and lighting too. They aren't really games at this point, the are just demonstrating the techniques to create some aspect of the game, usually a world view like in this project. Within this project you see voxels with textures, rudimentary world building, and interaction with the world controlled by the direction the camera is looking. I think that is sufficient to call it a "Minecraft clone." This still has a ways to go before it can be called a game, but that wouldn't make it less interesting as a teaching aid.
Well, that's certainly true when we're talking about the underlying 3D graphics libraries, IO, etc. But it seems like there's still a lot more to the rest of it, and that it shouldn't fit in 500 lines of code.
When first learning Python, I was amazed at how my code would shrink.
That is, I would write something in the first, most-obvious way that occurred to me. Then, recognizing patterns, I would refactor it down to something smaller. Usually this repeated a few times, until the 100ish lines of code I wrote turned into 10 or 20.
Python gives a programmer a lot of help in reducing redundant code. It makes C#/Java/etc. feel really tedious with all of the boilerplate code you end up writing.
OSError: dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 6): no suitable image found. Did find:
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture
Unless I'm just terribly mistaken, good luck getting pyglet to run on OS X right now. However, I really hope I am wrong, because that means I was just being a fool last week and will soon be using pyglet.
Software has a habit of becoming exponentially complex as the featureset increases, so I am not that impressed by small code if you cut features aggressively.
To prove a point, I wrote a minecraft clone in about 60 lines of code (10x less than the Python version). It cuts a few more corners (no textures, no gravity), but has the basics of world generation, rendering, and most importantly, adding and removing blocks in front of the crosshairs to build (see the little arch I made in the middle):
It's written in Lobster in about 1.5hrs, which is quite similar in features to Python + pyglet. Yes it uses a few high level calls like simplex() and camera_FPS_view(), but these have been part of the Lobster standard library for a while, so I believe that's fair. All code I created for this demo are in that screenshot.
I mess around with roguelike development and have been migrating from python to scheme for brevity.
I started with python. I've had lots of problems with it, but I'm far stronger in python than anything else, so have been in a sense stuck on it despite separate attempts over the last twelve months to get to momentum in C, C++ and racket.
During the recent 7-day roguelike challenge I found myself still stuck on my old python codebase, now creating DSLs in order to define entities and relationship opportunities between them (e.g. water -> planted_seed = sapling). I found I was able to significantly reduce code size, it's cleaner, and it's far sturdier. That was the point where I realised I needed to drop everything and make the jump to scheme, which I've been doing since.
This derailed my 7-day roguelike effort a couple of weeks ago, but it's progress.
OT, but another benefit I've found is that it's trivial to write zero-dependency, multiplatform code in racket. "raco exe main.rkt".
Whereas getting that done with with python is fiddly. With the previous game I released, I spent more time trying to get exes for the major platforms than I did on everything else combined.
See I look at this and absolutely amazed. I wish I could make something like this but I have no idea of how to event start.
I tried making a Settlers game in Python/PyGame and so far all I have been able to do is generate the board: https://gist.github.com/sareon/5268205 - I've been told I am not properly discretizing the difference between the drawing of the game and the logic of the game which is going to hinder the development of the game.
I have a BSc and an MSc in CS - focusing on NLP and Machine Learning, so I have an idea how to program, just not how to program games like the Minecraft clone or my own Settlers game. I've tried looking for tutorials and resources online and I've followed the InventWithPython which showed me how to make a simple game similar to how I started making my own. Clearly it was inefficient for a larger game.
What are some good resources out there that can help me learn how to make games such as the Minecraft clone or even how to make my own settlers game actually be a useable game?
This. This is why Python, Pyglet, and this particular project rock.
Not the jump thing. But the whole class of things there is something you don't like and can more or less instantly find it, tweak it and see changes. No hours of learning, searching through code, waiting on compilers. Just experiment -> fun -> back to experiment.
I have been teaching my 10 year old Python as an exercise. Recently I've noticed he's getting a little bored and I'm being very careful not to 'sicken' him, as this needs to be fun. I've just shown him the video for this and downloaded the code to show him that its possible in Python. He loves Minecraft (we watched the documentary movie about Mojang) and seeing this has given him a bit more of an interest again
Not only that, it's not even to do with "boredom" in any sense that I understand the word:
"participants limited TV, computer and video games, music, and telephone time to 30 min per day; in the time made free thereby, they were to read, sit quietly, write in their journals, meet with friends, and so on"
Calling that "boredom", says more about whoever wrote the title "Why Kids Need To Be Bored" than it says about kids' performance and boredom.
Then, the result of this study seems to be: out of 3 participants, 1 showed improvement, the other 2 dropped out. No data on 2 out of 3 test subjects, really, statistically proves nothing at all. It could go either way, or completely different. And it's bad science to not clearly point this out in the abstract. There's no shame in a failed experiment, but there is a lot of shame in pretending that it shows a trend that you didn't actually measure.
I'd be very surprised if research points out that more boring study material leads to improved results. Actually, with N=1 I won't be surprised no matter what.
I think everyone forgets that Minecraft's big feature is not its graphics or its gameplay, it's the procedural content generation. Almost anyone could learn to do Minecraft-level graphics in a few weeks, and the level of interactions (combat, crafting, moving things) could be reasonably approximated, too. But its procedural content generation algorithm is quite complex. You're not going to make an algorithm quite as nice as Minecraft's without a lot of research, a lot of hard work, and a lot of tweaking time.
Well, to be honest, this point is also where one could beat Minecraft at its own game. The minecraft devs haven't put emphasis on world exploration in a long time, instead preferring more traditional game features (like "the end").
There are many features notch promised when the project first started that where never acted upon, and there's definitely still demand for those.
Sigh, right in the nostalgia. Liero was better though, it had fluid simulation. You could flood a level with water and drown people, or better - oil and then set it aflame. And it had guided missiles, which you could spam, making one long queue of keyboard-guided death. It was basically Worms Quake.
It's rather simple: you are proccessing huge grids of 3D data, it's always going to be less then-optimal unless you write parts of it in languages that can do this fast.
(This also includes interaction between blocks if you are going to processing a lot of those.)
You also will want to optimize the approach. For example, do you really need to draw each block as a cube? You could draw slabs of identical blocks as a single cuboid. That will complicate the code, but may allow you to run larger worlds faster. Also, you probably want to be smarter in computing which cubes to draw and what parts of them to draw (in a 'no reflections' world, you can see at most three faces of a cube. There is code for drawing fewer faces on lines 177-185, but that is disabled. If you figure out why, you may be able to improve the code). [My guess would be that the display does not look nice enough if you do. Maybe you will get flicker when looking at blocks near edge conditions (no pun intended)?]
Also, keeping angles in degrees means you have to convert to radians on every iteration. It is easy to get rid of that. That will be a tiny, tiny speed up, but if you want to get top speed, you will eventually have to make many of those.
Almost every such improvement in speed will come at the cost of code readability and maintainability.