Mauveweb (Pyweek)

My Sincerest Apologies Tear-down

Daniel Pope — Sun, 25 Mar 2018 17:06:14 GMT

On Reddit I often see a variation of a conversation like this:

Newbie: I want to write games in Python!

Random person: Python is no good for games. You should use C++ or C#.

The claim that Python is not a good language to write games is not true. It's more accurate to say "Python is not a good language to write games alone."

It is well known that Python trades raw performance for productivity. But if you use it glue together powerful libraries written in faster languages then you can do better - you can have performance and productivity.

My Sincerest Apologies

In October 2017 Larry Hastings and I teamed up to enter the Pyweek Game Jam, and we won! Our game was a fast-paced 2D shooter with real-time lighting effects, called My Sincerest Apologies.

Here's a clip:

How did we write this in a week? With 3000 lines of Python code, but importantly, with four high-performance libraries.

Each one of these libraries is an independent project, written in its own way, but we were able to put them together in a game engine in our spare time in one week.

Pyglet

Pyglet provides bindings for OpenGL, sound, and input devices. As well as these it has higher-level capabilities for rendering 2D sprites and text.

Pyglet is written in pure Python using the ctypes module in the Python standard library.

Pyglet isn't the fastest OpenGL library around. However it gives you the tools to draw hundreds of sprites with very minimal cost, by arranging them into vertex buffers and handing them to OpenGL.

When you're using Pyglet you're mostly delegating all the hard work to your system's OpenGL drivers, and this is easily fast enough for writing many types of games.

All of the basic drawing we do in My Sincerest Apologies is done using Pyglet. We also use Pyglet to control the shaders, framebuffers and render passes needed for our lighting effects.

The base scene as rendered by Pyglet with lighting shaders turned off.

Lepton

Lepton is a venerable Python particle engine that I have recently taken maintainership of.

Lepton is written in C using the Python C API. Most common particle operations, such as forces, rotation, scaling and fading are performed in C under the control of Python. It also draws the particles using OpenGL.

Lepton means that we never need to actually access the particle data in Python. All we need to do is construct and modify Lepton's Emitter objects and let Lepton take care of everything else in fast C code.

Short-lived particle emitters are spawned wherever a railgun ray hits.

Pymunk

Most games need collision detection, and fast native code libraries are a great tool here too.

We used Pymunk, which is a Python library built around the Chipmunk 2D physics engine using CFFI.

Pymunk gives us a lot of the tools we need to create a 2D game. For a start it prevents the player character moving through walls. But it also gives us collision events that we can attach Python code to, such as when a bullet hits an enemy.

It lets us do ray queries to test for objects hit by our railgun rays. We get some great effects for free, such bouncing bullets or what happens when the player character collides with crates:

Your browser does not support WEBM video.

Lightvolume

Lightvolume is the most unknown of the libraries we used - because I wrote it during the competition!

Lightvolume handles the rendering of volumetric (2D) lights. You feed it geometry from Python and it implements the visibility algorithm described in this interactive article by Red Blob Games.

In fact it doesn't even implement this from scratch - it simply wraps the C++ implementation of the algorithm provided by trylock on Github! What a cheat, right? But this was very easy to wrap with just a little C/C++ code and CFFI again.

Lightvolume also takes care of rendering the lit area using OpenGL, meaning that again, we don't need to funnel data managed in a native code library back into Python. All we do with Python is feed in the lights and shadow casting objects, and set up shaders.

A 2D lightvolume being rendered without shaders

Why not try it yourself in Pyweek 25?

That's what we did in Pyweek 24.

But if you read this article and thought "I'd like to have a go", then fear not! Pyweek 25 is happening in April 2018, starting on April 15th, and it's a great opportunity to try out some of these things for yourself.

Join us at pyweek.org!

Pyweek Game Jam is 19th-26th February

Daniel Pope — Thu, 26 Jan 2017 19:49:36 GMT

The 23rd Pyweek games programming competition will run from the 19th to 26th of February 2017, from midnight to midnight (UTC).

The Pyweek rules, in short, are:

Develop a game
In Python (mostly, at least!)
As an individual or with a team
In exactly one week (or less!)
From "scratch" - no personal codebases, only public, documented libraries
On a theme that is selected by vote, announced at the moment the contest starts.

Python has great libraries for programming games, both 2D and 3D, and the flexibility of the language means you can achieve a lot in just 7 days. Pyweek is open to programmers of all ages and experience levels, from anywhere in the world, and it's a great way to challenge yourself and improve your skills.

Games are scored by other entrants, on criteria of fun, production and innovation, and you'll have to think about all three to be in with a chance of winning! It's a free competition though, so your prize is recognition :-)

Here's what you need to do if you want to take part:

Sign up/login at http://www.pyweek.org/, and then "Register an entry" at the top-right.
Familiarise yourself with some of the libraries and resources you can use to make games.
Join the IRC Channel, #pyweek on Freenode, for discussion and advice.
Play some of the previous entries at the Pyweek.org site.
Why not post a diary entry (from your entry page), introducing yourself and your team?
Put a "save the date" in your calendar! Theme voting starts 2017-02-12, and the competition the week after, 2017-02-19 00:00 UTC.

Have fun, and good luck!

Pyweek 21 is one week away, 28th February-6th March 2016

Daniel Pope — Sun, 21 Feb 2016 12:25:34 GMT

The next Pyweek competition will run from 00:00 UTC on Sunday 28th February to 00:00 UTC on Sunday 6th March. That's next week!

Pyweek is a week-long games programming competition in which participants are challenged to write a game, from scratch, in a week, in Python.

This week, we vote on themes! The possible themes can be interpreted however you like:

Jump in line - you could do a Dance Dance Revolution-style game with cute animals
Showtime! - perhaps a business sim in which you run a TV network?
The aftermath - clean up the mess from a house party before your parents get home.
The incantation - players enter a TV talent show to prove they are the best spell-caster. Each week one is voted off! Featuring Will.i.am.
In the model - this naturally lends itself to a totally awesome game in which you have to develop a Python script with sklearn to solve exciting big data problems! With cute animals!

But seriously, if these theme ideas get your creative juices flowing, and you have spare time to write a game next week, why not register an entry and give it a go?

Pyweek 20 announced, 9th-15th August 2015

Daniel Pope — Tue, 28 Jul 2015 07:22:52 GMT

The next Pyweek competition has been announced, and will run from 00:00 UTC on Sunday 9th August to 00:00 UTC on Sunday 16th August.

Pyweek is a week-long games programming competition in which participants are challenged to write a game, from scratch, in a week. You can enter as a team or as an individual, and it's a great way to improve your experience with Python and express your creativity at the same time.

If writing a game seems like a daunting challenge, check out Pygame Zero, a zero-boilerplate game framework that can help you get up and running more quickly.

Due to various circumstances this has been delayed somewhat, and is now being announced at somewhat short notice. Be aware that this means that theme voting begins this Sunday, 2nd August.

Pyweek 19 / Animations

Daniel Pope — Wed, 10 Sep 2014 21:00:00 GMT

Pyweek 19 is coming up in October, running from Sunday 5th (00:00 UTC) to Sunday 12th (again, 00:00 UTC). Pyweek is a games programming contest in which you have exactly one week to develop a game in Python, on a theme that is selected by vote and announced at the moment the contest starts.

You don't need to have a great deal of games programming savvy to take part: whatever your level you'll find it fun and informative to program along with other entrants, exchanging your experiences on the challenge blog (link is to the previous challenge).

I'd encourage everyone to take part, either individually or as a team, because there's a lot you can learn, about games programming and software development generally.

In celebration of the upcoming Pyweek, here's a little primer on how to write an animation display system.

Animations

An animation is made up of a set of frames, like these from Last Train to Nowhere:

Frames could be 2D sprites or 3D meshes, but for simplicity, let's assume sprites. I always draw my sprites, but you can find sprite sheets on the web if you're less confident in your art skills.

Playing the animation in a game involves displaying one frame after another, at the right place on the screen, so that the action looks smooth.

First of all, let's look at the typical requirements for such a piece of code:

It needs to be able to draw multiple copies of the same animation, each at different frames and positions.
It needs to be cycle through the frames at a certain rate, which will usually be slower than the rate I'm redrawing the entire game screen.
It needs to draw each frame the right places relative to a fixed "insertion point". That is, if the game treats the animation as being "at" a point (x, y), then the frames should be drawn at an offset (x + ox, y + oy) that will cause them to appear in the right place. The offset vector (ox, oy) may vary between frames if the sprites are different sizes.

Another feature I've found useful in the past is to be able to select from a number of different animations to "play" at the appropriate moment. So rather than needing to create a new animation object to play a different sequence of frames, I just instruct the animation to play a different named sequence:

anim.play('jump')

The chief benefit of this is that I can preconfigure what happens when animations end. Some animations will loop - such as a running animation. Other animations will segue into another animation - for example, shooting might run for a few frames and then return to standing.

The best approach for a system like this is with the flyweight pattern. Using the flyweight pattern we can split our animation system into two classes:

The Animation class will contain all the details of an animation: the sprite sequences, per-sprites offsets, frame rates, details of what happens when each sequence finishes, and so on. It's basically a collection of data so it doesn't need many methods.
The Animation Instance class will refer to the Animation for all of the data it holds, and include just a few instance variables, things like the current frame and coordinates of the animation on the screen. This will need a lot more code, because your game code will move it around, draw it, and tell it to play different animation sequences.

So the API for our solution might look something like this:

# A sprite and the (x, y) position at which it should be drawn, relative
# to the animation instance
Frame = namedtuple('Frame', 'sprite offset')

# Sentinel value to indicate looping until told to stop, rather than
# switching to a different animation
loop = object()

# A list of of frames plus the name of the next sequence to play when the
# animation ends.
#
# Set next_sequence to ``loop`` to make the animation loop forever.
Sequence = namedtuple('Sequence', 'frames next_sequence')


class Animation:
    def __init__(self, sequences, frame_rate=DEFAULT_FRAME_RATE):
        self.sequences = sequences
        self.frame_rate = frame_rate

    def create_instance(self, pos=(0, 0)):
        return AnimationInstance(self, pos, direction)


class AnimationInstance:
    def __init__(self, animation, pos=(0, 0)):
        self.animation = animation
        self.pos = pos
        self.play('default')  # Start default sequence
        clock.register_interval(self.next_frame, self.animation.frame_rate)

    def play(self, sequence_name):
        """Start playing the given sequence at the beginning."""
        self.currentframe = 0
        self.sequence = self.animation.sequences[sequence_name]

    def next_frame(self):
        """Called by the clock to increment the frame number."""
        self.currentframe += 1
        if self.currentframe >= len(self.sequence.frames):
            next = self.sequence.next_sequence
            if next is loop:
                self.currentframe = 0
            else:
                self.play(next)

    def draw(self):
        """Draw the animation at coordinates given by self.pos.

        The current frame will be drawn at its corresponding offset.

        """
        frame = self.sequence.frames[self.currentframe]
        ox, oy = frame.offset
        x, y = self.pos
        frame.sprite.draw(pos=(x + ox, y + oy))

    def destroy(self):
        clock.unregister_interval(self.next_frame)

This would allow you to define a fully-animated game character with a number of animation sequences and transitions:

player_character = Animation({
    'default': Sequence(..., loop),
    'running': Sequence(..., loop),
    'jumping': Sequence(..., 'default'),
    'dying': Sequence(..., 'dead'),
    'dead': Sequence(..., loop)
})

You'd have to find a suitable clock object to ensure next_frame() is called at the right rate. Pyglet has just such a Clock class; Pygame doesn't, but there might be suitable classes in the Pygame Cookbook. (Take care that the next_frame() method gets unscheduled when the animation is destroyed - note the destroy() method above. You'll need to call destroy(), or use weakrefs, to avoid keeping references to dead objects and "leak" memory.)

There's potentially a lot of metadata there about the various animation sequences, offsets and so on. You might want to load it from a JSON file rather than declaring it in Python - that way opens it up to writing some quick tools to create or preview the animations.

Next, you need to create the flyweight instance and play the right animations as your character responds to game events - perhaps you'd wrap a class around it like this:

class Player:
    def __init__(...):
        self.anim = player_character.create_instance()

    def jump(...):
        self.anim.play('jumping')

    def update(...):
        self.anim.pos = self.pos

    def draw(...):
        self.anim.draw()

I've used this basic pattern in a fair number of games. There are lots of different ways to extend it. Your requirements will depend on the kind of game you're writing. Here are a couple of ideas:

You might want the flyweight instances to be able to flip or rotate the animation. You might store a direction flag or angle variable.
You might want to be able to register arbitrary callback functions, to be called when an animation finishes. This would allow game events to be cued from the animations, which will help to make sure everything syncs up, even as you change the animations.
You could use vector graphics of some sort, and interpolate between keyframes rather than selecting just one frame to show. This would offer smoother animation, but you'd need good tooling to create the animations (tools like Spine).
I've assumed some sort of global clock object. You might want to link animations to a specific clock that you control. This would allow you to pause the animations when the game is paused, by pausing the animation clock. You could go more advanced and manipulate the speed at which the clock runs to do cool time-bending effects.

Have fun coding, and I hope to see your animations in Pyweek!

Pyweek 18 announced

Daniel Pope — Sun, 23 Mar 2014 10:53:32 GMT

Pyweek 18 was announced last week, to run from the 11th May to 18th May 2014, midnight to midnight (UTC).

Pyweek is a bi-annual games programming contest in which teams or individuals compete to develop a game, in Python, from scratch, in exactly one week, on a theme that is selected by vote and announced at the moment the contest starts.

The contest offers the opportunity to program alongside other Python programmers on a level playing field, with teams diarising their progress via the pyweek.org site, as well as chatting on IRC (#pyweek on Freenode).

Games are scored by other entrants, on criteria of fun, production and innovation, and it's a hectic juggling act to achieve all three in the limited time available.

It's open to all, and very beginner friendly. You don't need a team, you don't need finely honed artistic ability, and you don't need to set aside the whole week - winning games have been created in less than a day. I'd encourage you to take part: it's a great opportunity to explore your creative potential and learn something new.

Browse (and play) the previous entries at the Pyweek.org site.

Pyweek 18 kicks off with the theme voting starting at 2014-05-04 00:00 UTC.

Interview: Andy Kelley of Superjoe Software

Daniel Pope — Sun, 15 May 2011 16:03:30 GMT

Andrew Kelley graduated with a degree in Computer Science from Arizona State University last Thursday. He loves programming, game development, and composing electronic music. In two months, he's starting work for Amazon in Seattle. Oh, and his entry, Lemming, was voted the winning solo entry in the latest Pyweek competition.

Congratulations on your PyWeek win - and with your first PyWeek entry too! Did it come as a surprise or were you feeling fairly confident?

Thank you!

I knew I would rank at least up in the top few games, simply because I was in that beautiful stage of freelancing where you have just finished a job, have plenty of money in the bank, and don't have to work for a while. With only 2 classes and no girlfriend I was able to spend upwards of 90 hours on the game. I think that's probably a bit more time than most other contestants had.

Have you written many Python games before?

This was my first Python (and Pyglet) game. I have a few really old Flash games online though. First game ever was in VB6, and the platform I've written the most games for is probably TI-83 (I had a long bus ride home back in high school).

Writing a game in Python was interesting. It's perfect for a rapid development competition like this - Python is fantastic with the arbitrary data structures you often need to solve one-off quick problems in game programming. On the other hand, I did experience some loss in CPU efficiency in my physics loop that writing it in C or C++ probably would have improved.

What would you say are most important lessons you learned through developing Lemming?

Do not write a level editor during PyWeek. I did this the first day, and then scrapped pretty much all my day 1 code on day 2 in favor of Tiled and DR0ID's tiledtmxloader. I'm very happy that I made that decision.

Reserve a non-trivial chunk of time for playtesting on friends and family - people who aren't a part of the development effort. You'll get a sneak peak of what everyone is going to complain about when they judge your game, and hence a chance to prevent that. Or even better, you'll get a preview of how judges will praise your game, and you can use that knowledge to expand upon that aspect.

Start 'em off really easy. The way your gameplay works to you is obvious, since you conceptualized and coded it. Not so for someone who hasn't seen your game yet. You don't want judges to get stuck on level 2 and give up, never to see all the cool stuff in levels 3 and above. There's a time and a place for really hard, difficult gameplay, and that is after the player has proven that they are ready for it. I think Loopback executed this perfectly with their difficulty modes. After playing on easy and getting the hang of it, you can move on to challenging for the really interesting gameplay.

Find good tools and practice before PyWeek. It shouldn't be a pain in the butt to create art, animations, and levels for your game. If it is, keep looking. You need good tools that stay out of your way so you can have more time developing and less time fighting with tools.

Was your original idea anything like the final submission or did it change a lot in the making?

According to my theme brainstorming document, my original idea was for the Fry Cook on Venus possible theme, "You're a french fry leading a stampede of lemming french fries. When you die control transfers to the next one behind you. Your death affects the environment."

When it came time to think of ideas for Nine Times, I thought, "The french fry game but with only 9 of you. And let's use lemmings instead of french fries."

So I pretty much implemented my original idea exactly, but the idea was purposefully vague enough to expand into the different possibilities that came out of it.

What in the world is that main character supposed to be, anyway?

I have no idea. Guesses people have made include "CigarMan", "Dog Poo on Fire ...Man", "The Sausage King from one of the other PyWeek theme proposals" and "The Peperami Guy". I'm no artist. To me he's just a really happy brown rectangle with a death wish.

How did you design the gameplay elements?

The process for inventing gameplay went something like this:

Roughly sketch a level idea on paper, with gameplay concepts that I haven't programmed yet.
Simultaneously create the art and code for the gameplay elements I had sketched out - make them work.
Use Tiled to actually build the level I had sketched, utilizing the new art and code.
Repeat. I only ended up going through 2 iterations.

In the reviews, your level design was praised - and cursed! ;-) - in equal measure. Was the level design something you put a lot of effort into?

Level design is really important to me. I think it can make or break a game. This is why doing most of the level design in crunch time was my biggest mistake. With half of the last day left, I only had 1 really hard grassy-hill themed level, and 1 really hard factory themed level.

I actually split the original level 1 into what is now levels 1, 2, and 3, in order to make them easier. Level 1 is fine, but everybody still gets stuck on levels 2 and 3. What this means is that my concept of difficulty was way off. I should have had more people playtest the game so that they could tell me it was too hard and so that I could make the difficulty ramp up more slowly, while still introducing cool gameplay concepts.

One of the pieces of feedback on the levels that really struck home for me was this: "The later levels of your walkthrough remind me of a Rube Goldberg device with the player getting flung hither and thither with no idea of what to expect next. That's not something it's really feasible to master." This comment is spot-on. I fell into a trap - I wanted to show off how capable and bug-free my physics engine was by making levels as complicated as possible. There is a time and a place for that, but in the case of Lemming the commenter is right, it happened far too much.

I think that as is, the current 9 levels only expose about 10% of the cool gameplay and puzzle levels you could achieve, with already existing code. Since time is a zero-sum game during PyWeek, this means I should have spent less time developing gameplay elements and more time level designing. Fractured Soul pulled off this balance beautifully. They have a pretty simple gameplay - there's not much more to it than jumping and placing 9 statues in each level. Yet they have a ton of wonderfully crafted puzzles that keep the game fresh.

What would you have added or changed if you'd had another week to work on Lemming?

Well, I have had another few weeks to work on Lemming, and I've done absolutely nothing, so I guess that's the honest answer. But hypothetically, the next few things I would add would be more levels, a better victory sound, more level themes and gameplay elements, more ways to die. I'd improve the level design, tweak various physics variables, like turning friction down, and fix some bugs!

Do you have any other projects you're working on?

Yes! Notably, mineflayer, a bot framework for MineCraft. Mineflayer makes it dead simple to create MineCraft bots in JavaScript.

I'm in the middle of refactoring it into a library so that we can kind of merge projects with Charged Miners, an OpenGL MineCraft viewer. Together this will provide an alternate client for people to play MineCraft with.

We hang out in #mcdevs on freenode. It's a pretty fun channel.

What aspects attract you about MineCraft?

I think the idea of starting out weak and vulnerable, but by slowly working your way up, you can become strong and powerful, is a big part of it. It's interesting how none of that is by "leveling up" but actually by moving, placing, and/or physically acquiring certain objects is what makes you strong and powerful. It's nothing inherent.

The Zero Punctuation video pretty much sums it all up.

Nowadays, I think the #mcdevs aspect of it is more fun than the actual game - that is, the community of people who are making MineCraft-related projects. Another example is bravo, an alternate server written in Python. One of our favorite pastimes is to gather in the IRC channel after a big MineCraft update and complain loudly together about how bad a programmer Notch is. ;-)

Interview: Christopher Night of Team Multiverse Factory

Daniel Pope — Fri, 13 May 2011 12:00:57 GMT

Christopher Night, aka Cosmologicon, was the director and producer on the Team Multiverse Factory entry for Pyweek 12, Fractured Soul, which placed second in the team competition. Christopher has also had two previous Pyweek winners in the individual competition, Mortimer the Lepidopterist in Pyweek 11, and Panspermia, in Pyweek 8.

What inspires you/drives you to make games using Python?

This is probably different for me than for most people. I don't like using libraries or frameworks. I've made about 10 solo games in Python now, and I've never used anything beyond Pygame, PyOpenGL, and NumPy. What I like about Python is its highly expressive syntax and powerful standard library. Game development in, say, C++ is mature enough that everyone has a complicated framework they like, so there's little attention paid to development without one. Whereas with Python, I feel like you can jump right in.

Pyweek also has a lot to do with it. I like Pyweek a lot. The scope and community are just about right for me. I originally learned Python in order to compete in Pyweek 6.

What games/genres influence you most, and how?

I don't have any conscious influences that I can think of, as in, I enjoy this game so I want to make more games like it. Games are definitely good for reference, though. When it comes to designing controls and UI, it's great to know a lot of games and understand the design choices and why they work, so that you can make the best choices for your own game. But when it comes to a core mechanic, I like to try to do something different. I actually don't play that many games, but my favorites are single-player action, adventure, and strategy games with a strong story like Zelda.

I was particularly impressed by the idea of freezing yourself into statues in Fractured Soul. How did you come up with the concept?

Nothing special, I think it just came from the idea of playing through the level nine times. You can look at the entirety of the concept as it was when the game started on our wiki under IDEA1.

It wasn't a unique idea, either, someone else posted basically the exact same idea we had.

Yes, actually superjoe's winning individual entry also has the concept of piling up duplicates of your character. Did you spot any really original ideas in other Pyweek entries?

Not as many as in previous Pyweeks. Lots of people did as good a job as possible with the theme ["Nine Times"], but I didn't think this theme really lent itself to much originality. The only examples of really original interpretations (IMHO) I can think of are Tee and adrwen.

How did you tune the difficulty of the game?

Poorly. This is a very important issue for puzzle design, and if things had been slightly different it could have gone badly for us. We were fortunate enough to have enough content that we could make all the stages after the tutorial optional. That way if one of the levels was too hard it wouldn't break the game.

How close to your original concept was the final submission?

The mechanics were very similar. You could see the original concept in the link above. The idea of the "counterweight" platforms came pretty early on day 1. The storyline, sound, and graphical style were pretty much absent from the original concept. They all came late in the week.

Was there anything exciting that you left on the cutting-room floor?

There are usually features I want to add but don't have time for. That wasn't the case this time. There were several features that were somewhere between "jotted in the margin of my notes" and "implemented but disabled" that got cut, namely: double-jumping, wall-jumping, enemies, rolling boulders, water/lava whose level can change, keys, ladders, elevators, teleporters, mobile portals, switches in the ceiling, levels with bizarro mechanics, and using stones to keep objects from moving. (There's no way we would have had time to implement all of them, of course.) The reason these were cut, though, is because the game was already pretty full. I don't know about the rest of the team, but I prefer depth to breadth in gameplay. That is, really exploring a small set of mechanics rather than superficially using a larger set.

One exciting non-mechanic feature we cut was the ability to record yourself playing through a level, save it to a file, and play it back. This was working midway through the week, and we used it for some playtesting, but we had to break it on the last day.

Some of those features sound brilliant - I'd love to see what puzzles you could create with water and lava. Will they ever see the light of day or is the game done and dusted now?

Yeah, we're thinking of continuing work on it, and that would include adding some mechanics. I haven't gotten around to it yet myself, but I'd like to, especially if we can get someone to work on the art.

You've personally had winning entries in Pyweek twice. Can you speculate on the formula for a winning entry?

So, I've entered Pyweek solo five times, and placed 7th, 1st, 9th, 4th, and 1st. That's enough to form some comparisons, and I can look at the other games and try to work out patterns.

My winning entries were based on ideas I came up with early on day 1 and stuck with. Starting halfway through doesn't work, nor does forming your idea before the competition begins.

I think that a winning entry tends to feel complete, even if it's not complete in your mind. One finished level leaves a better impression than three half-finished levels. If people don't know the features were planned, they won't miss them. Winning entries tend to be easy to medium difficulty. For solo entries, winning entries tend to do more with less. Simple, retro graphics and geometric shapes are fine.

But of course, I don't really believe in a winning formula. Mostly it's just making a good game. :)

One last question. What's next for you personally, and for next PyWeek?

As much as I like Python, I'm becoming frustrated that my games are difficult to distribute. Browser-based games get so much more coverage these days than downloadable games. If someone can get pygame running in Google Native Client or something like that, that would be great! In the meantime, I'm trying to learn HTML5 or Flash.

But I'm always planning come back for Pyweek. Multiverse Factory was a very successful experiment in working on a team, from my point of view. But I don't know if I'll be entering solo or on a team next time.