Here is another Game Creation Society competition entry I wrote in an evening. The theme was “reflection”, and I took it literally. The game generates a jagged and changing world based on what a webcam sees. This of course, means that it requires a webcam supported by the Pygame Camera module, which should be just about any USB webcam that works in Linux.
In the game, you must steer the heart across the treacherous world without colliding with anything. If you do, you start back at the beginning. If you succeed, the heart gets bigger and you start again. Note that in many cases, the worlds generated will actually be impossible, just like real life.
The game uses the latest Pygame out of SVN, so I compiled it and included it locally for those who don’t have it.
Download:
Reflection Rejection i386
Reflection Rejection amd64
hi,
I tried out your game, and the effect looks really cool 🙂 Reminds me of that cartoon movie… a waking life 🙂
Need to add pygame.camera.init() to it, for it to work with current pygame svn.
Note, that I’ve changed the camera module in svn to require pygame.camera.init() first… since some other camera modules need that, and it’s kind of pygame standard practice.
Also, the game now works with the opencv module… and maybe the vidcapture one. So it should be possible to play it on win/osx with the right dependencies installed. Both of those modules are incomplete… but work enough for the pygame.examples.camera and your game.
On linux, the _camera v4l2 module is the default, so to use the opencv module do:
export PYGAME_CAMERA=opencv
It seems to almost look like your screenshot with this logitech camera on linux using the opencv module. However it doesn’t look right with the v4l2 module. Also, the heart just seems to fly down the screen… not all over the place like in your screenshot.
http://rene.f0o.com/~rene/stuff/reflectionrejection_v42l_logitech.png
http://rene.f0o.com/~rene/stuff/reflectionrejection_opencv_logitech.png
I tried it with your precompiled pygame too… and I get the same result as with my svn compiled one.
Maybe the camera is giving back a surface in different formats for each API. aha! That is it.
opencv is returning:
v4l2 is returning:
What does your camera return? a 24bit surface? Probably something to do with that.
cheers,
hi,
comment stripped out the surface formats… here they are without the angled brackets.
opencv is returning: Surface(640x480x24 SW)
v4l2 is returning: Surface(640x480x32 SW)
ah… I get it now. You need to move the heart with your keyboard! The heart moves when I do that 🙂 Fun game.
I just point the camera at different things and it makes a new level.
Ah, I’m going to have to get updated with the new camera stuff when I have more time. Possibly over spring break in a couple of weeks. School has completely eliminated my free coding time.
It’s possible that the v4l2 results are actually valid. The algorithm for making the level is really very naive. It just makes polygons out of connected components that are away from the average color of the image. I think. I don’t quite remember now. That image could be a valid result if opencv and v4l2 are using different colorspaces. The game uses HSV, and the opencv code is likely RGB. The 24 vs 32 bit is probably just because game is set to use the same bit depth as the display surface for the capture surface on v4l2.
Someday, when I have more time, I’d like to return to this gameplay concept and make it more playable.