That's awesome! It looks really fun. Reminds me of Liero a bit, but with more intuitive controls. I'd love to play it!

PSN download please?

Looks awesome!!!!

haha awesome!!!!!

hehe that's nice
Is there any chance to get source code and maybe a sort of tutorial to show us how to program on PS3 and the so called "synergistic" cpu ?

Perhaps we will release some code one day … but probably not too soon. It takes a certain amount of time and effort to get the code in a state where we can release it without breaking any license agreements and so it's at all meaningful for people who can't compile it on full blown PS3 devkits.

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.

This Jam product is neat! Leave the concept and gameplay as it is, just enhance the graphics and audio and you'll have a bestseller!
I do partly agree with locking the games after the 24th hour, but that should only be the concept.

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

Thanks for your detailed reply, John. And all the best for this saturday new GameJam

Did you guys sleep at all during the 24 hours or was it 24 hours of straight development?

How many person-hours did you put into it?

[I'm going to answer your question in far more detail than you were probably looking for, so feel free to stop reading after the first paragraph. ]

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.

John,

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?

Hah, I think I confused the matter with my long-winded explanation. During the game jam we only coded on the PPU, because, as you surmised, it takes a bit less time than writing for the SPUs. In my previous post I was just attempting to force an analogy between how we normally code for the SPUs on our main projects and how we structured the programming team during the game jam. The code we wrote the day of the jam was all very much vanilla single-threaded C++.