postponing the upload

Well, I have *something* to upload: A cube wanders serenely through some unsatisfying 3D mazes to a bumping soundtrack. An exercise in zen, maybe, but it's not really a game. Oh well.

My upload is barfing at about 10%. Presumably this is a busy time to be uploading, I'll try again tomorrow. Glorious bedtime!

(log in to comment)


Woo! The "it's not really a game" club membership is growing rapidly - there's three of us now :-)
The screenshot looks fascinating!
To nitpick: it would be good manners to name your directory "cubemaze" or something (not "pyweek11"). It helps when I'm extracting a bunch of games in the same directory. It's also nice that most games name the main Python file, following this also helps judging a bit. (You could check out the skellington for the recommended format.)

I don't mind these nearly as much as this stack trace upon startup though:

Traceback (most recent call last):

  File "", line 8, in <module>
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/", line 19, in main
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/", line 12, in run_game
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/controller/", line 44, in prepare
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/controller/", line 70, in update
    item.update(item, dt, self.time)
  File "/Users/darabos/Downloads/PyWeek-11/pyweek11/source/model/", line 16, in __call__
    if item.position != self.last_position:
  File "source/lib/", line 328, in __ne__
    return not self.__eq__(other)
  File "source/lib/", line 322, in __eq__
    assert hasattr(other, '__len__') and len(other) == 3
workaround: in ($gamedir)\source\model\ replace
self.last_position = None
self.last_position = (-33, -44, -77)
Ohno! Thanks for the feedback cyhawn, and for supplying a timely workaround claxo!

I didn't use the skellington this time around - and you're right, that caused me to unhelpfully stray from some pyweek conventions. I'll add this to my personal 'to remember for next time' notes.

Now that I come to investigate, I see that stacktrace generated on Python26. I was developing on 2.7, I forgot to re-test on 2.6 before I uploaded. Ooops!

I've adopted the fix, I presume it's too late to upload a bugfix version now? Ohdeary.
I applied claxo's fix, and now I get the following (running Ubuntu with python 2.6.2 and pyglet 1.1.2):

Traceback (most recent call last):
  File "", line 8, in <module>
  File "/media/KINGSTON/pyweek11/pyweek11/source/", line 19, in main
  File "/media/KINGSTON/pyweek11/pyweek11/source/", line 12, in run_game
  File "/media/KINGSTON/pyweek11/pyweek11/source/controller/", line 49, in prepare
  File "/media/KINGSTON/pyweek11/pyweek11/source/view/", line 50, in init
  File "/media/KINGSTON/pyweek11/pyweek11/source/view/", line 150, in compile
  File "/media/KINGSTON/pyweek11/pyweek11/source/view/", line 84, in compile
  File "/var/lib/python-support/python2.6/pyglet/gl/", line 105, in errcheck
    raise GLException(msg) invalid enumerant
Thanks for the bug report Cosmologicon, much appreciated.

As you can see from the traceback, it's happening while compiling OpenGL shaders. I'm afraid I don't know enough about opengl drivers to know why this might happen on your hardware but not on mine. I presume your opengl drivers are not very old? If someone else does understand this, I'd appreciate any edification.

I guess you can run without the shaders, by commenting out lines 49-51 of source\view\

        shader = ShaderProgram(vs, fs)

This will make all the game very flat shaded, which will make it a bit ugly and harder to see what's going on. Level 3, in particular, was always a bit tricky to see what was happening - this might tip it over the edge of impossibility.

Oh! You could fix the flat shading, by adding a quick hack at line 90 of source\model\ (at the end of Shape.__init__)

        for face in self.faces:
            light_angle =, -3.0, 2.0).normalized())
            light_angle = (light_angle + 1) / 2
            face.color = face.color.tinted(Color(0,0,0,255), light_angle)

Thanks a lot, it works for me now!
Shaders are a *big* problem in OpenGL - unless you use a library where someone has taken the time to make a nice wrapper for all that stuff...

I have tried them a few times, as has my friend, and stuff that works on his Python/Pyopengl/etc. doesn't work on mine.
But worse, what works on his nVidia doesn't work on my ATI, and vice-versa.
My last entry, (which you should play RB[0]), Wabble used shaders to great effect. I'm not sure I remember it dying for too many people. You just gotta make sure you check for shaders and fail in a workable way.
Ah, the other thing I should probably have pointed out is that there isn't much game there. It's just three mazes, and not particularly good ones, at that. :-( 
Hey, and RB[0], when you say a 'nice wrapper' for shaders, are you thinking of just the code required to call the opengl API to create shader programs, while checking for error codes and raising exceptions in all the right places? Or are you thinking of something more than that? Something that tries to detect ATI vs NVidea? But then what can you do in response to that, to handle the differences? Do you have an example of public shader code that handles this right? The ones I've seen don't seem to do anything different from what my own does, but I don't really know much about what I'm talking about.