Screenshot 01 of Test Level

Deep Breath

A white water rafting challenge.

The code repository can be found here:  Code Repository

Awards


The Rat Avatar Award for Most Palindromic Water Craft
Presented by typhonic

Feel old for knowing these tunes
Presented by wezu

Give this entry an award

Scores

Ratings (show detail)

Overall: 3.5
Fun: 3.4
Production: 3.8
Innovation: 3.5

13% respondents marked the game as not working.
Respondents: 13

Files

File Size Uploader Date
CoDoGuPywk26_Deep_Breath-1.0-FINAL.tar.gzfinal
FINAL game entry, hope you enjoy!
3.9 MB gummbum 2018/10/28 03:22
ss02.jpg
Screenshot 02 of Test Level
60.7 KB gummbum 2018/10/27 02:25
ss01.jpg
Screenshot 01 of Test Level
89.4 KB gummbum 2018/10/27 02:24

Diary Entries

Enable multiplayer

If you want to play our entry against another player then this is possible (this went unmentioned in the readme.txt):

Just un-comment following lines in context_game.py (line 54 and following):

        # # add other players
        # # arrows
        # canoe = Canoe(timing.Timer(scheduler=self.scheduler))
        # canoe.position.y += 150 / PPU
        # self.canoes.append(canoe)  # uncomment for second player

The second player uses the arrow keys instead of a s d f. Same position of key does the same, but you figure that out.

There is no special treatment for multiple player, so the level will just end when the first arrives at the end.

Have fun racing the levels.

Add a comment

Going subpixel with pygame

Hi
first of all, sorry to not have posted any diary entries during the pyweek itself.

This pyweek we had slow moving objects and using pygame that only knows integer coordinates for pixels resulted in a jittery movement. The reason is simple: while the position was calculated in a float that had to be rounded in some way to an integer pixel coordinate. So if the position only changed slowly this results in objects just hopping one pixel from now and then.

Then I remembered a post from long ago:     Going subpixel with pygame
The downside of this is that it requires numpy. But then I remembered that I made a version that uses pygame only (with some clever surface scaling, can be found here: SubPixelSurfacePygame ). This is what we used in our entry so the slow moving objects slide smoothly and do not hop from one pixel to another.

The downside of this sub pixel approach is 9 times more memory usage and slightly blurry images. But it still looks a lot better than without.

2 comments