Anyone have a fix for this problem?

Traceback (most recent call last):
  File "run_game.py", line 16, in ?
    main.main()
  File "/Local/Games/Python/PyWeek5/DNAReplicator-1.3-src/lib/main.py", line 148, in main
    basedl[base] = compilemesh(a)
  File "/Local/Games/Python/PyWeek5/DNAReplicator-1.3-src/lib/main.py", line 107, in compilemesh
    for i in xrange(3*npoints):
OverflowError: long int too large to convert to int

There is a bug in our final release that prevents the full level from being displayed on screen. We had some revision control snafu's and we ended up releasing an old version of the code. If you care to see the rest of it please edit lib/levelparse.py:66 self.engine.level.rightmost_pixel = gotx to self.engine.level.rightmost_pixel = goty thanks! jgib

Well, I stayed up way too late the last few nights of the compo, and payed by getting really sick the last day :(
I finally had fydo upload what we had as the final entry and went to bed.

Well....
At about 6(1 hour before the end for me) I woke up and decided to give it another try. There is actually some game-play now, but, regrettably, the file size got up to 25 mega-bytes O_O, so I have decided not to submit it, our entry then is the one fydo uploaded, and it is at version 0.05 for game-play I'd say.

The theme is not at all expressed, but that is due to the fact that game-play itself is expressed very, very little.

Now for trying everyone else's games :D

Aurora Fighter is a 3d shooter where you navigate a ship through a dangerous twisted tunnel avoiding obstacles and trying to shoot down your opposition. I don't want to reveal any details right now to avoid spoiling the surprise, but I'm sure you'll enjoy the atmospheric feel we went for as you get immersed in the action.

It was a lot of effort, but I think we came out with a really cool game and all of the team is certainly very happy with the result. We hope you'll enjoy playing this game as much as we enjoyed making it.

From the programmer side, let me tell you we had almost decided not to go 3D before the final theme came out, except for the twisted theme, where it seemed 3D could help a lot in conveying "twistedness". None of us had significant OpenGL experience, but somehow we managed to develop an engine from scratch full of interesting features that let us create really fun and challenging levels.

We also learned a lot from previous PyWeeks on how to manage the team and set our goals, and that experience is hopefully reflected in this game.

I'll try to post an updated screenshot later, as the one we have on the entry listing was taken the second day of the competition I think. And hopefully my teammates will chip in with their impressions.

Note: We tested the game and it ran fine on Linux and Windows. However, we found a problem that seems to be caused by older PyOpenGL versions not providing the right aliases.

Luckily, it's a very easy fix. Simply change line 165 of lib/tunnel.py from:

glScale(2, -2, 1)

to

glScalef(2, -2, 1)

We accidentally left out the name of "Nubis", one of our main developers in the uploaded version of our code. It was my fault, and I feel deeply embarrassed by it.

This will be fixed on the final release, but if you are so kind, please open lib/main.py and replace line 633 with:

        ["nubis",""],

Thank you.

Everything is over. Still waiting for the torrent, but I guess it's the right time to analyze my doings a little. My approach to coding was quite different from last time, and didn't work quite as well, but at least I learned a few valuable lessons.

Stuff that I did right this time:

• Didn't give up, even when it seemed quite hopeless to finish the game as I had planned. In the end, I have some sort of a game, even if I it doesn't have all the features I would've liked it to have.
• Increased my supply of generic utility functions to ease coding.

Stuff that I didn't do right:

• Bit a little more than I could chew. If I had really been able to use the whole week, the game might've been more complete. But I started a bit late and finished early, and my early plans were way too ambitious for a one week, one man project.
• Didn't test the game nearly enough. Even the final version has some trivial bugs that crash the game or make it behave in a way it shouldn't. And I'm still not sure if the game is balanced or not.
• Didn't plan my architecture well enough. Ok, I was new to network programming anyway, and didn't quite know what it would take. Anyway, I'll have plenty of restructuring work ahead of me.

And finally, the fix to make the game not crash when trying to join a game. On line 77 in main.py, replace

          if (input_addr != None):

with

          if (address != None):

and the game should connect instead of crashing. I also found one other bug - having an unit in the first buy slot in a base can block buying at the second slot, and buying at the second slot might result in errors. Both bugs are fixed in a new version I'm working on now, and I'll publish a new version of the game and also an updated version of Splush after PyWeek voting has finished.

Finally, one site suggestion for richard: Add an author tag to the Diaries RSS entries. Should really help in organizing them.

I've written some documentation for the level editor in 555-BOOM!.

5B-0.5-Doc.tar.gz

If, when you start the game, the level flies away and the ball is in freefall your computer is above average. We didn't regulate simulation speed. So if you still care to play, feel free to change the second argument of the min() function on line 297 in states.py Try lowering it to around 15.

There is a bug on linux. You will get an error similar to: pygame.error: Couldn't open /home/bjorn/Desktop/pyweek/Murmel2/data/art/menusplash.PNG rename /data/art/menusplash.png to /data/art/menusplash.PNG Thanks!