This has been five intense weeks, I really feel that I’ve leant more about games than I did the entire first year on my education. Making games this way is a really great way to get lots of experience, fast. I’m not sure I’d do it for ten weeks, I feel pretty spent game design wise. But after I’ve had a few weeks to get my brain back on track again I’d really like to do the same thing again.
One of the greatest challenges with this project were the keywords, more often that not I found myself basing the game on one of the words and sort of cheating in the second (or just ignoring it), this was really against the rules I set in the beginning. But then again, my main goal was to make games that were fun to play, not make games heavily tied to keywords. If I’d do it again I think I’d choose a broader theme like “water” and then do a bunch of variations on that. One good thing with the keyword rules I used is that you can’t really start with the next game until you’re supposed to. This keeps you focused on the game at hand.

Final Advice

I summed up my experiences from this project in a few points. Maybe they can help someone else.

Do the important stuff first and do the fun stuff as a “break” of sorts.
For me this meant to make a toy that tested the gameplay as fast as possible, and then, when that got tedious I did some graphics. It’s pretty easy to tell which games were the most fun to make, they have the worst graphics.

Take the middle route, there’s fast and there’s good. Make it both.
It’s a classic programmers thing to make “good reusable code”, screw that. If it gets the job done it’s the code for you. Of course there’s no point in coding the whole game like crap either, then you’ll be screwed when you need to change stuff. The trick here is obviously to find the middle route, modular but fast to write. It’s also a good idea to look for examples or code snippets that do what you want to do, we’re prototyping here so I say steal and pillage code as much as you like, as long as you give credit where it’s due.

Don’t be afraid to change your game if it isn’t fun.
I spent ages trying to make Popeatron amusing when what I really would have needed to do was to scrap the concept and rethink it entirely. A bit like I did with Isotope. That was also a game that suffered from “unfunniness” but, a rethink of the rules and it turned into something amusing.

Emergence is your friend. When the game makes it’s own content, you won’t have to.
There’s a reason why I’ve used the elastic ropes in half of the games i made. When you make a game in three days you spend the first day coming up with the idea, the second day is making the basic mechanic and the third day is making a game out of it. There’s just no time to make levels.

Final thoughts

I’d recommend this to anyone who claims to be the least bit into designing games, most of my classmates however doesn’t have the programming experience to do it. But I say learn. Spend a few weeks getting to know some way to make games (I’d recommend Flash, over say C++, atleast for prototyping), then go for it on a spree like this.