91–100 of 113 posts
These seemingly "big" games written in a handful of lines of code always make me feel very, very stupid. I know if I made this, I could easily imagine writing 50,000 lines. How do people do this? How do their minds work?
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…
There are many features notch promised when the project first started that where never acted upon, and there's definitely still demand for those.
Earlier quoted context omitted.
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.…
So is this something that can be "fixed" without diving into Pyglet?
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 : def setDefaultBlockColor(color): # reca…
There's an awful LOT happening behind those 580 lines. I'm not sure whether it is a good thing to start at such an unrealistically high level of abstraction for a 3d game.
Jump speed is too fast... if you slow it it works better and is more like minecraft IMHO elif symbol == key.SPACE: if self.dy == 0: self.dy = 0.500 # jump speed
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.
Earlier quoted context omitted.
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.…
So far, all the suggestions seem to be for main.py, not Pyglet. So is this something that can be "fixed" without diving into Pyglet?
If you want the utmost speed, you get it where you can get it the easiest. I bet the other code also can be sped up.
I would expect that the major improvements would be in main.py, though. That Pyglet library would have to be really bad to screw up what main.py does.
More than 100 lines of this are textures! Got this error though. Any ideas? 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
I got it to work on OSX 10.8! slunk's suggestion: `arch -i386 python main.py` got me halfway there You also have to run it with python 2.6 like so: `arch -i386 /usr/bin/python2.6 main.py` If you only have pyglet for 2.7, you will have to install it for 2.6. Installing packages in python for 2.6 will require pip-2.6 which you get like this: `sudo easy_install-2.6 pip` then `pip-2.6 install pyglet` Walla!