After some brainstorming we have a basic game idea. It'll be a variation of an adventure game called "Gregor Samsa". Initial lines of code were created with a lot of drama in between. Team management is needed.

Coding has commenced. Some drama still going on but the game is evolving and getting structured. Writing diary entries while waiting for some code to be written by co-worker...

Thanks to some new fancy cellphone technology we were able to move outside and work enjoying one of the last summer nights. Some words on our game: It'll be an adventure/story telling game. We still lack large parts of the story, however I'd expect initial gameplay to be finished today and polishing etc. going on in the next days... Let's see. More on the concept will come soon, I'll join the code monks again.

Day 1 recap:

We have an idea and made some progress towards a working game. Basic graphics exist and we'll probably reach a playable state tomorrow. We have our initial screenshot and will work on from here. Initial drama subsided. Some parts of the team work on deployment (already). I hear a lot of swearing about py2exe and py2app.....

This morning we successfully created the first playable version of our little game. Right now there is a small test-story to be played that was mainly written for implementing game mechanics. Major work has to be put into writing/polishing the story and adapting the setting of the game to the story. I'm happy we have at least something working, whether in the end it's fun and nice, I don't know. (I hope so though).
there is a video of the basic gameplay at http://vimeo.com/28979843

Creating a basic story line. Finally we have a viable idea.

Yesterday we started working on the story finally. We had a nice idea and are following the idea now. I hope the complexity doesn't kill us. This is a graphical display of the story so far:

Right now the ability to add pictures to the text is added. A quick change in code and in the story backend did the job. Our framerate plummeted, however pygame.image.load(image).convert() instead of pygame.image.load(image) solved the framerate issue. 

As pyweek approaches the end quickly (less than 2 days to go) it's time to reflect a bit on what we planned an acheived. 

There is some discussion around pyweek on the suitability of python for writing games and a lot of yammering about frame-rate: It depends on two things: your implementation and the game you write. For our simple adventure style game python is perfectly suited. We have nothing running in the background just the occasional check for events. So event driven games are perfectly fine. As soon as you need more complicated stuff, you might get into trouble if you implement your logic too crude. Because of our simple loop we had to limit the framerate to 60fps not to run on 100% CPU all the time. There are computers this happens but even on my fairly weak eeePC the game runs at 60fps without a problem. 

For python: I like python and use it for most of my programming. I am confortable with a lot of things but still I learned a lot during this pyweek, especially because some more experienced and better python programmers reviewed the code and gave hints. My and some other participants motivation primarily was to learn (more) python and I'd say I succeeded. 

The scope of the project seems ok, although the story is very extensive and there is a chance we don't finish it. (the graph shown previously is just a tiny part it grows every day. I should have made a timelapse...) Nevertheless we already have a playable game and will finish. The project was well suited for pyweek (especially for a team entry). If i'd do a solo entry things would be a lot simpler. Graphics even if only stand in graphics or crude things quickly hacked in gimp really make a difference and give a more polished feel to the game. There is still polishing to be done and we still have ideas what to implement. If we don't finish everything the pyggys are an option... 

Overly I'm still stoked about pyweek and programming games in python (have never written a game before, as have some on our team, some others are 4th time participants (with 2DNF and one rather poorly rated entry). I'm looking forward to spend my time playing all the interesting looking games evolving in this pyweek.

Something bugged me today. Although our game runs at a fast 60fps, it still was using about 60% of CPU on my weak eeepc. For a game mainly only active on events this is pretty bad. To solve this issue I decided to get rid of the display.flip() and use pygames.update() instead only updating parts of the screen that are more commonly used. By doing this our CPU usage was reduced to 2/3rds. More optimization to come. 

tl;dr
In case you are not writing a scrolling game: pygame.display.update() might save your framerates.

As threatened previously: we successfully ran our game on mobile platforms. From the first day the N900 of one of the co-developers was used for testing. Today we finished the android specific parts. So go to the marketplace, download the "Pygame subset for android", copy our game to the /sdcard/pygame/ folder and play it! If you can't, here's a screenshot.


Also as you can guess from the title: the first playable demo is online. Play away and give us feedback. 

<3 the invisible hand of adam smith

Work (still) in progress!

... still time for a group photo :)

So the ratings are in? Let's look at it:

Fun: 3.1
Production: 3.7
Innovation: 4.5

Yiiihaaa, this looks pretty good. We didn't score high in Fun, quite ok in Production and we were #1 in Innovation for the competition. As we were aiming at making an experimental game we expected to score high. But with so many great and not less innovative games out there in the entries this is still a pleasant surprise.

First things first: Thanks you everyone for your great comments and ratings! We hoped you enjoyed our game as much as we enjoyed playing yours!

Let's start with a proper Aftermath:

First of all, working with a Team is Fun but Hard. Try to limit your team size to less than 4-5 people. We started out with a lot of people (mainly because so many people wanted to do pyweek at our hackerspace and no other group formed). So at first we had to split up tasks. Luckily we had 2 people with graphics skills and a several programmers. We ended up having 2-3 people write the backend code, 1 person working on the graphics, 2 people working on story (those worked also on the backend for parsing the story format) and several people doing packaging and consulting. We started out with huge discussions about the backend etc. this is where smaller team sizes will be an advantage: everyone brings their own opinion and if you have 7 opinions you discuss a lot. We ended up using pygame after the more pragmatically headed people started to write code instead of sitting around and discussing. The code was easy, compared to the story. So we had a working prototype on the morning of day 3 but no story (and because of this no graphics either). The following days were hardcore story writing days. Some of the people reserved a lot of time to work on our entry (around 5-6h/day) and without this effort the game wouldn't be as extensive as it is. Finally the graphics were done mainly in the final days and hours of pyweek. Integrating them required some changes to the codebase and the story but after all it was simple to do. We finished in time to upload the game, then we went out to get some drinks and dance to loud music and celebrate the fact that we finished (it was 2am here after all).

Our main goals were 1) To learn some python (I did learn a lot and I hope some of the other participants did as well). 2) To finish the game and 3) to get the best score for a pyweek entry ever done in our hackerspace. We succeeded in all three. Considering we did the #1 innovative entry we even exceeded our expectations.

The main comment were people asking for sound/music: Yes this would have been nice, however we had neither time to look around for music that fits the story nor the skills to compose music on our own. However for the future we need this.

Things that could have done differently:
*Smaller Team (in the end 4 people did the majority of the work)
*Different version control (we used svn, git would have helped in many cases, e.q. working offline in the park, nice branching and merging)
*Better time plan (We did a lot of work the first two days then slowed down, because of exhaustion and the loong task to write a story)
*Lower project size (The project ended up very extensive because of the story, we need to find something smaller next time)

After all we learned stuff and pyweek was fun. Expect us back!