I appreciate your detailed reply!

I'm a Windows C++ developer, and I have rough idea of how long it would take me to do something like that on Windows, so I was curious about how your team was able to get so much work done in such a short period of time.

I'm curious why your team utilized the SPEs for this game. Wouldn't it have been easier to code if you only utilized the PPE? That way, you wouldn't have to worry about communicating with and synchronizing data with the SPEs, you'd only have to deal with basic threading and synchronization. I mean, I can run a game like Half-Life 2 on a meager 2.53 GHz Pentium 4–which must perform all the calculations that the graphics board isn't doing, plus all of the background services that Windows is running, shouldn't the 3.2 GHz PPE be sufficient for this game? Or was it your intention to utilize the SPEs for a specific reason, even if the SPEs weren't necessary for performance reasons?

Six people worked on the game over the course of 24 hours. Jenova, Martin, Nick and I coded; Kellee greased the wheels of industry (made sure food was coming in at regular intervals, made logos, etc.); and Steve, our main sound designer on Flower, did all the sound effects (with a little help from Altered Beast). We all arrived around 10 a.m. on Saturday, and people started going home around midnight, with people leaving every 2 or 3 hours after that. No one slept at the offices during the jam. The final build was made at 9:38 a.m. on Sunday. All-in-all, I'd say we spent about 110 man-hours on the day of the jam.

It's important to note, though, that unlike most game jams, which focus on design, we wanted to use this jam as a test of our raw production skills, so we actually prepared quite extensively before the event. By the time we started jamming on Saturday, we had already figured out some game mechanics, as well as a list of design principles for the kind of game we were making.

Relative to other game jams, we had a fairly large number of coders working together, so we also preplanned the programming pipeline. The inspiration for structuring the programming team actually came from our experience coding the Cell. Each of the 8 processors on the Cell is extremely fast, individually, but communication between processors takes a lot of time and effort. On single processor systems, you generally want to share data as much as possible. If you've calculated something once, why bother doing it again? But on multiprocessor systems like the Cell, it often takes longer to distribute the results of a calculation than it does to run the exact same calculation on each individual processor. You end up repeating some work, but you avoid tons of communication overhead, and since you have a bunch of processors instead of 1, you still get things done much faster than you would in the single processor case.

On our primary games, we try very hard to avoid redundant code, mainly because maintaining code in multiple places is exponentially harder than maintaining it in one. As a result, if someone writes a piece of code that's generally useful, he tells all the other coders about it and we all end up using it. For the game jam, we decided to go with the multiprocessing model, since, in 24-hours, maintenance wasn't much of a concern for us, but communication between coders was (since it's waaaay slower than even communication between processors). As a result, in the 4,500 lines of code we wrote that day, we had 4 different functions for 2D physics, 4 different functions for drawing rectangles and a bunch more duplication beyond that, but we still got a lot more done than we would have had we tried to write our code the clean, non-repeating way.

All that said, I don't think the preplanning took nearly as many man-hours as the game jam, itself, though it didn't happen in parallel, either, so it spanned over the course of a few calendar days.

How many person-hours did you put into it?

Great work and thanks for sharing with us! Can't wait for more!

In the mean time, however, if you're interested in programming the Cell (you've got a retail PS3 running Linux, say), I highly recommend http://www.cellperformance…. I also recommend checking out the R&D pages at http://www.insomniacgames.com. One word of warning, though: Mike Acton is both founder of cellperformance and the Engine Director at Insomniac Games, so if all you do is read these two sites you'll get a very Mike Acton-centric view of programming for the Cell … which isn't terrible, since he's very good at it, but it's always nice to get multiple opinions.

Looks awesome!!!!