Friday, September 19, 2008

My pyweek postmortem. Making a game in a week.

Pyweek, finished recently, and was a real blast... as usual.

Congrats to everyone who took part, pyweek was really fun! I look forward to playing everyones games (I've only got through around ten so far).



'Eye stabs' was our team name.


We didn't post a final entry. Our game isn't really at the stage where we'd like it to be... There's still a number of core features required before it's a 'game'. At the moment, it's kind of a fun intro, and a demo of what the game could be.

For me, recently these competitions have been about experimenting, rather than finishing a game. Getting a buzz off everyone else's energy as they create something in a small amount of time. These competitions are also really good for 'finishing' a game... since they have a finish built in. When the week has ended it's finished.


So we'll make a release some time in the next few weeks. Because we want to show everyone... but not before the basic elements are in place.



""" In the dirty underground music scene often referred to as 'eye stabs', there are lethal gigs in select nightclubs around the world. Musicians play for eyes. A tune is played to the musician, and they must figure out the notes played.

Fuck up the tune, and you are stabbed in the eye! Get the tune right, fortune and respect are yours! Better than the riches and the adoration though -- rich club owners can give you spare eyes... and provide doctors that can give you back eyes you have had stabbed out.

So are you prepared to put your eyes on the line? Can you play well enough to avoid a stab in the eye? Do you trust the sleazy club owners doctors to fix your eye if it does get stabbed? """


_____
q o o p
q o!o p
d o!o b
\!!!/
|===|
|!!!|
|!!!|
|!!!|
|!!!|
|!!!|
_|!!!|__
.+=|!!!|--.`.
.' |!!!| `.\
/ !===! \\
| /|!!!|\ ||
\ \!!!!!/ //
) `===' ((
.' !!!!! `..
/ !!!!! \\
| !!!!! ||
| !!!!! ||
| !!!!! ||
\ ======= //
`. ooooo .;'
`-._______.-'


Think a guitar hero type game, with an insane premise, and instead using a real guitar for playing the notes(instead of a toy guitar). There are also 'sim musician' elements. You need to select which gigs to do, and collect myspace fans. Well that was the idea anyway.




Screen shot of which
notes you need to play
and which notes you played.
It's a musical ear trainer.



things that went well

  • kick arse intro (goes for 60 seconds or so). I would be happy playing it at party.
  • played around with portaudio. Which seems like the best solution for portable audio. I think we might use it in pygame (with likely something like swmixer)
  • learned to use ocempgui (finally).
  • got pitch recognition working for guitar fairly well. Learned about how the algorithm works, and the various limitations.
  • with a little more work, the game could teach people about music. We hoped to make it a useful program, as well as fun. Nicholas has already taken the pitch recognition parts to allow it to talk to other ear training programs.
  • pygame.threads.tmap combined with pygame.fastevents turned out to be a really nice way to do multithreading.
  • authors of libraries we used were very helpful. Especially Nathan(swmixer), and Marcus(ocempgui).
  • cool samples, and music. moxi made some cool music and samples. We only managed to use some of them because of the rush. However we are going to use more later.
  • found 4 new pygame bugs, and about 8 bugs in other python libraries. Even though they wasted time, it was good to find them.




  • Screen shot of intro.


    things that went badly

  • thinking pyweek ended on sunday 5pm, when it ended sunday 10am.
  • dissapearing gfx team member, so I had to work on gfx elements at the last moments, when we realised he wasn't going to contribute.
  • spent most of the time on the intro. Including spending six hours failing to get the video playing with pygame.movie, and instead writing a multithreaded motion jpeg video player.
  • game elements left to the end. We should have polished those parts first. (But had lots of fun with other stuff :)
  • python bloat, and py2exe. Python really has put on the megabytes since python2.3. Took a while getting the size down from an initial 26MB to 6MB. This was important 'cause some of our team were on dialup modems.
  • had technical issues getting the pitch recognition stuff working. That took a while. Was kind of pythons fault really. Including issues with the GIL(pyaudio doesn't release the GIL). Also the non deterministic way in which python does stuff (dicts, garbage collection, finalisers). Calling processes in python is also hard to do multiplatform nicely(even, and especially between different versions of windows).
  • issues with pygame sound loops, and Sound object loading. This wasted a lot of time.
  • You can't win or lose the game. We should have added game elements nearer the start of the week.




  • In the doctors surgery...
    trying to repair your stabbed eyes.

    Tuesday, September 16, 2008

    pygame.test -- moving testing forward.

    We are moving to including the tests with an installed python package... pygame.
    >>> import pygame
    >>> pygame.test.run()

    Why?


    Why include tests in pygame? Rather than only with the build process?

    • More people will run the tests.
    • people can run the tests to see if everything works in their own programs.
    • Can run tests on a persons computer to see if everything in pygame+ your program is working.
    • Which driver/function combination works, or works fastest? Run tests and find out.
    • Testing a py2exe/pyapp generated binary is much easier.
    • Reuse of our testing enhancements for their own tests.
    • Reporting bugs would be easier. Since everyone could run unittests, since they will be installed everywhere pygame is installed.
    • Result submission of unittests easy. This would result in a much larger base of computers running the unittests and submitting problems. This would be opt in of course.
    • Make the testing stuff more a library, than a framework.
    • Allow people submit unittests more easily. Since they won't require a source release of pygame to write unittests. eg people using a windows binary install of pygame, or a ubuntu binary install can run and submit unittests.
    • Make testing easier for people. The easier it is, the more worthwhile testing is.


    A few other things it might do.


    # load your own test into the test runner.
    >>> pygame.test.load("tests/mytest.py")

    # pass commands to the test runner.
    >>> test_results = pygame.test.run(tags="interactive")

    # Submit the test results for review.
    >>> pygame.test.submit_test_results(test_results)

    # submit a test you wrote for review to the pygame developers.
    >>> pygame.test.submit_test("tests/my_new_test.py")


    Nicholas and I have been discussing this for a while, and have now moved discussion to the pygame mailing list. However we would appreciate any thoughts from outside of the pygame community too.