Proud smile - aka Aftermath

mihi on 2011/10/03 12:31 of the invisible hand of adam smith

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!

(log in to comment)

Comments

Cosmologicon on 2011/10/03 14:21:

Thanks for this postmortem! I've always wanted to write a game with an extensive story, but it's amazing how much time these things can suck up. It's good to know that you had two people working on it for multiple days. It's a good yardstick for me to judge how long it would take me to make one myself.

jerith on 2011/10/04 17:33:

We've found that the advantage of using something like git over svn in a pyweek project is much more about conflict management than branching. Things move so quickly that branching and merging costs more in overhead than it's worth. Being able to work offline is a definite benefit, though.

Working with the same team on multiple pyweeks makes a lot of stuff run smoothly. After the first couple, you know how to divide stuff up well and what major chunks need to be built before you can start testing. Having the basics of a game engine in under a day is really useful, because you can play with ideas by implementing stuff rather than trying to imagine how it would work.

It might actually help to only have one person working on the story rather than two. In our previous pyweek entry (Nine Tales), we had a writer on the team and she did all the story work. The rest of us suggested tweaks and things from time to time, but could otherwise focus on just writing the code and implementing the features the story required. (And sometimes asking for different bits of story, because the features required were too big.)

The pyweek before that was a point-and-click adventure (Suspended Sentence), and we spent most of the first day discussing what the basic story would be. Once we had that decided, we each came up with a puzzle/storyline and implemented the game logic for that. There was still a lot of discussion, but it was more along the lines of "you're using duct tape to do something over there, so leave it in the inventory and I'll use it again to do something in my bit". (The duct tape got used a lot. Turns out it's quite a handy thing to have on a starship full of corpses.)