Since the last Pyweek I've become seriously disciplined at test-driven development in my day job. If it doesn't has tests, how can I know it works? Now I'm wondering whether it would be valuable for Pyweek.

Six months ago I would have thought it was a crazy idea to write tests for a Pyweek game. Pyweek is all about coding as fast as possible, right? And tests are just a waste of time I could be spending adding more features! But seriously, the amount of time I spend in a Pyweek manually testing my own game is massive, and it's always possible to leave some crasher in, something that worked once but got broken in the headlong rush to move features. I've read articles suggesting TDD is just always faster.

And anyway, how can you test that such and such a particle effect looks just so? Well, you're much more likely to break the code so that the particle effect just crashes with some exception, or is never started, or emits them off screen or something. How it looks is hard to test, but it's not the most important thing to test. I love having to not have to deal with that kind of crap any more.

So what do we think? Has anyone done a substantial amount of TDD in a Pyweek? Is it an approach that can work?

I had to go to a wedding in the afternoon of day 1, so I only managed to get as far as mockups. But I thought I'd share them with you anyway, to whet your appetite.

Day 2 has seen rapid progress what with it being a bank holiday in the UK. I've bunged together some fairly crude physics courtesy of Pymunk and bolted that into Pyglet to render the art that I largely drew yesterday.

I've not used Pymunk before - I've always used pyBox2D in my experiments. On the plus side Pymunk seems to be more Pythonic, with excellent support for various collision callbacks. On the downside I've not found moment of inertia and centre of gravity calculations built in. Or perhaps I'm missing a trick.

So right now we can tweak Susie's engines:



And rather clumsily fly her:

Day 3 has felt very short, compared to yesterday.

I've added an infinite plane of random clouds (and stars, if you can get high enough) generated with a spatial seeded RNG, a la Elite:



I've also added crude, unfinished buying and selling to the editor:



There's still so much to do - hours of tweaking flight physics, I'm sure. I always underestimate how much work is involved in getting playable games out of physics engines.

Not much visible progress today, but I've continued to add necessary features and the gameplay has therefore improved quite a bit.

You can now design quite weird and wonderful squid conveyance rigs, and the improved aerofoil physics makes tweaking the orientations of the parts relatively fun. However the gameplay really needs pitch control components to help players keep their squid straight and level in flight.



There was nearly a showstopper today with Pymunk. I wanted Pymunk to give me the coordinates of the insertion point for a component, as Box2D does. This is the point I draw the sprite and allows me to connect it in the right place in the hierarchy. But Pymunk only works on centres of gravity - you can't choose an arbitrary insertion point for a body. Therefore I'm constantly having to recompute the insertion point from the centre of gravity point and the body's rotation. It's an annoying omission that makes Pymunk just plain harder to use than Box2D. A few changes in my code could help relieve the omission but I don't think it's worth wasting the time on that during Pyweek.

Day 5 saw me get massively bogged down in particles for the rockets (and hopefully, other effects too). lepton's BillboardRenderer just wasn't drawing colours right, so after about 3 hours of fiddling with it I reimplemented it crudely with pyglet sprites.



You might also notice a slicker HUD with a list of the components you can use. And fuel gets consumed by things that require fuel. The editor is also looking finished:



All in all, I'm relatively pleased with where I am - that's the game mechanics largely complete.

This evening I sat down to try to draw enough art for me to finish the game completely tomorrow I was keen to get in a cutscene to set up the awesome plot. Turns out cut scenes are quite easy to write - I just knocked up a Python API for writing a cutscene "script".



The other thing I tackled was animations for the propellers and rotors, but this didn't take long either, because I didn't draw multiple animation frames, I just swap in a "full-speed" image in place of the "stopped" image:



It turns out that this instant feedback actually makes the game seem much more responsive. Win!

As soon as I release the game I discover a showstopper that plain wasn't there in development.

Crashing into the water now crashes the game and very rapidly swallows all the memory for the machine. I've had to pull my entry until I can get it fixed.

Running with ulimit -v:

Loading chipmunk for Linux (64bit) [/home/mauve/.virtualenvs/flying/local/lib/python2.7/site-packages/pymunk/libchipmunk64.so]
Initializing cpSpace - Chipmunk v6.0.2 (Debug Enabled)
Compile with -DNDEBUG defined to disable debug mode and runtime assertion checks
Traceback (most recent call last):
  File "/home/mauve/.virtualenvs/flying/bin/korovic", line 9, in <module>
    load_entry_point('korovic==1.0', 'console_scripts', 'korovic')()
  File "/home/mauve/dev/flying/korovic/__main__.py", line 9, in main
    g.start(level=options.level)
  File "/home/mauve/dev/flying/korovic/game.py", line 42, in start
    pyglet.app.run()
  File "/usr/lib/pymodules/python2.7/pyglet/app/__init__.py", line 264, in run
    EventLoop().run()
  File "/usr/lib/pymodules/python2.7/pyglet/app/xlib.py", line 93, in run
    sleep_time = self.idle()
  File "/usr/lib/pymodules/python2.7/pyglet/app/__init__.py", line 187, in idle
    dt = clock.tick(True)
  File "/usr/lib/pymodules/python2.7/pyglet/clock.py", line 700, in tick
    return _default.tick(poll)
  File "/usr/lib/pymodules/python2.7/pyglet/clock.py", line 303, in tick
    item.func(ts - item.last_ts, *item.args, **item.kwargs)
  File "/home/mauve/dev/flying/korovic/game.py", line 76, in update
    self.scene.update(dt)
  File "/home/mauve/dev/flying/korovic/scene.py", line 74, in update
    self.world.update(dt)
  File "/home/mauve/dev/flying/korovic/world.py", line 206, in update
    self.check_crash()
  File "/home/mauve/dev/flying/korovic/world.py", line 231, in check_crash
    self.particle_splash(p, v(vx, vy))
  File "/home/mauve/dev/flying/korovic/world.py", line 82, in particle_splash
    e.emit(30, self.splash_group)
MemoryError

e is a lepton.emitter.StaticEmitter. So I'm fairly sure it's happening in lepton.

Strangely I've seen the splash effect work. It just worked as it was supposed to when I programmed it and didn't fail until after the deadline!

I'm going to try and find a workaround for you. If you've already downloaded it, don't play without a -v ulimit!

It's done! Some features didn't quite make it in, such as balloons, though I did get as far as making the physical rope to connect them. Susie briefly had tentacles (squid have two long tentacles and eight short ones) - but it affected the flight dynamics too much.



Among various other features, I added a title screen:



I wish I had another week to work on it! So many possibilities - but the code is in dire need of a refactor now. Such is the way of Pyweek.

Congratulations to everyone on all their brilliant games. I look forward to playing them!

If you went over to PyPI or Bitbucket right now, you could download a new release of Doctor Korovic's Flying Atomic Squid with a bunch of new components, including lighter-than-air flight. Just sayin'.

Thanks to everyone who played and rated my game.