In the interest of having more game development related material on the site (since it consumes a good portion of my life), I’ve decided to take a look back at one of the site’s best games: Magnetica.

The Story:
Approximately twice a year (though less recently), I host a 72 Hour Game Development Competition. It is, as the name implies, a competition to see who can make the best game in three days. I’ve hosted about seven of them, and usually we get around 20-30 entries per competition, so I’m rather proud of this creation. I haven’t participated in all of them, but whenever I have the time, I try my hand at creating my own game. In the last one, Zach, Ricky, and I all had the perfect schedules, and we were able to participate together - our first game as a group. The game would be Magnetica, with Zach and I on programming and Ricky on music.

Magnetica didn’t start off as Magnetica. It started off as, well, a tech demo. I slapped together a bunch of particles interacting according to gravity with the player, and the resulting behavior created such a nice aesthetic that it really energized us. We played with the tech demo for at least an hour before being productive again. It was good that we stopped then, because we had no game ideas.

We had a late night outing at Eat ‘n Park, bouncing ideas off of each other and sketching things out, trying to think of what would be fun. We went through six or seven ideas, only a handful of them having merit. Eventually we settled on an action game, because that’s what we like to play, and we’re relatively experienced with programming them. Even then, we didn’t have much of a design: we knew that the player would have weapons and shoot things, and he would be energized by particles gravitating around him.

We never did have much of a design beyond that. The game evolved iteratively, with us trying things out to see what worked and what didn’t. Although 72 hours doesn’t seem like a long time, we had plenty of opportunity to prototype and test, and there was a ton of discarding and tweaking. We put together our first playable level, and to be honest, it wasn’t really that fun. And it also ran really slow. And I was a tad worried.

Well, we managed to get it running faster with some pretty clever programming; nothing earth shattering, but enough to impress us. We managed to get it fun by constantly iterating on our idea. We felt the basic mechanics were OK, but the exact implementation left something to be desired. Zach and I did some more things with the particle system, upped the difficulty, created some nifty enemies/obstacles, and focused a bit more on our level design. In the end, we had something significant: a complete game, which we all enjoyed and were proud to call our own. I think it’s better than some games we’ve made with a team twice the size and with 20x more time.

The Good
The Team:
In most of the competitions I had participated in prior, all my teammates were over the internet. And it makes a huge difference. There’s a lot of energy you draw from the people around you, and having someone sitting right beside you is a great motivator to work harder. That’s not to mention the communication benefit: Zach and I immediately knew what we needed to do and who needed to do what. It also helped that we’re all friends, and we could have a whole lot of fun joking around.

Iterative Development:
Games can’t be made with a design-and-implement approach. A better approach is design-implement-tweak-design-implement-tweak-and so on. We were able to eliminate a lot of our bad ideas and refine the good ideas because we didn’t lock ourselves into some arbitrary list of requirements that may not be ideal.

Prototyping:
This goes hand-in-hand with the above. It’s good to have a nice baseline - something impressive to really get your team motivated. For us, our tech demo really put the game at the top of our priorities.

Subversion:
If you don’t use source control, start. At first Zach and I toyed with the idea of passing code back and forth, and we shot that idea down hard. Even with two people in close proximity, source control is essential. It made productivity so much smoother.

The Bad
Poor Coding Structure:
After the competition, Zach and I thought about going back to the game and creating Magnetica 1.5, which would play a lot smoother and have more levels and look more polished. I looked at the code for an hour, shook my head in shame, and decided that was a Bad Idea. Coding under severe time restrictions caused this, but I’m still a little sad our code became so unmanageable.

Timing:
It was not a good weekend for the Wii to be released, and no matter how many e-mails I sent to Miyamoto, he would not consider pushing the release back a week.

Conclusions
Not a whole lot of bad there. We all had a lot of fun developing this game, and it turned out to be one of our best creations. I really hope we can all participate together in the future.

Zach, would you like to do a post-mortem of Penguin Push?