prototyprally

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.

Words: Bird, Pendulum.

Description: When I was looking around for words for this game I instantly knew what to do. Swallows carrying coconuts. I got started on a first prototype, but about midday on the second day it sort of collapsed on itself. There was some sort of bug in the physics that made it behave very weird. I couldn’t sort it out and had to redo the whole thing from the beginning. Which was just as well, the whole thing was a lot better the second time around.

What went right: I really like the theme of the game. The swallows behave nicely and it looks very springy and nice.

What went wrong: Once again I wasn’t entirely sure what the actual gameplay mechanic would be when i started, I think this shows in the final product. As it is now I think the game is too hard, it just gets a bit frustrating not being able to affect the birds directly. I tried allowing the player to attach multiple ropes to one swallow, but then it became too easy instead. The game might benefit from fewer swallows but more control, and then making the levels a bit more like labyrinths.

Conclusion: This game could really have been a second Popeatron, I didn’t really know where I was going with the gameplay until a bit too late. It did however turn out as a pretty neat game in the end.

Words: Mushrooms, Power

Description: It was a bit of a struggle to have to start a new game considering the two minor failures that came before. So this time around I took care to choose a gameplay i was sure would work. The game is inspired from something
called “Conways life”, which is a simple simulation of cells living and dying in a grid system. My game had the same type of system, but I did away with the grid. I pretty soon became a problem when all the cells would stack up in big heaps, so I used some code from Popeatron to make them keep their distance.

What went right: The game is more of an evolution from an existing game rather than a completely new one, still, I feel this is the game that I like best of the ones I made. First I did some neat graphics and planned on doing it in a more 2.5D sort of way, but the game really stood for itself without extra graphics.

What went wrong: The gameplay isn’t all that challenging, there’s lots of room for experimenting, but I would really like to try adding in an opponent just to see what it does to the gameplay.

Conclusion: It pays to really think a concept through before starting on it, just having an idea what the player will actually be doing while playing really helps. A bit of luck won’t hurt either. This is a great example of how emergence can make or break a game, the rules for the game are simple but there are endless possibilities for variation.

Words: Pope, Traffic jam

Description: My plan for this was to make a “god game” where you help the pope in his neat car navigate through a mass of people or cars or something.
I did some reading up on flocking behaviour because I figured that’d be a nice emergent system much like the springs/IK stuff I’ve used in previous games. Pretty soon I found Boids. A very neat way of simulating flock/school behaviour, I also found some pseudocode which greatly helped in implementing the technique in Flash. However there was a problem, it was too slow for what I originally intended to use it for. I barely got 25fps with pink box graphics and 20 Boids scuttling around. I wanted a lot more. I did manage to push the fps a bit by using various optimizing techniques, but it still wasn’t anywhere near fast enough for large crowds.

What went right: The game sure has potential for emergence and the crowd does look real nice. I also like the graphics for the characters, a nice background and it’d look very nice. I did also manage to code a couple of neat functions I was able to reuse in the later games as well.

What went wrong: I focused way too much on the Boids simulation. Nice coding but I never really took time to stop to think about gameplay. Something I could have realized early on was that collision detection, or rather keeping the Boids
from colliding with for instance cars would be a problem. However I didn’t really consider this until it was too late. I spent a full day trying to make a game of it and it just wouldn’t “pop”.

Conclusion: Too much focus on the simulation and far too little on the actual gameplay was this games downfall. I can’t really see this game going anywhere in it’s current state, the simulation is nice, but the actual gameplay quite frankly sucks.

Words: Radiation therapy, Trespass

Description: The words I chose this time were a bit of a weird combination, and I had some trouble coming up with a good idea for them. Eventually I decided to go for a surgery-style game, where you build and control a robotic arm to
“tresspass” into a tumour and radiate it. The plan was to have the player attach a bunch of segments of different kinds to each other and then control these as a kind of probe going into a tunnel.
However, on the the last day for the game I realized it just wasn’t going to be fun, at least not in the time I had left. So a i started a major revamp of the idea, reusing the robot arm, but this time for mimicking radiation patterns.
The idea for the patterns came from a bug in the first version, the arm got stuck in a rotation and made a very interesting pattern. I decided to put a little “pen” on the end of it and it drew really freaky stuff.

What went right: This game has to be the best “save” I did. The first version was a slow, fiddly game that made a rather simple task take forever to complete. Not very fun at all. I still have some faith in the original idea, it would just need better implementation than i managed and a lot of it relies on good level design.
The toy i ended up with does have it’s little perks, it creates all kinds of weird patterns and is quite fun to toy around with. You can make it draw anything from a star to a rocket ship.

What went wrong: I realized that my original idea wasn’t going to be fun a bit too late. Had I realized it earlier it might have ended up becoming a proper game. This way there was just no time for making levels or patterns to match.

Conclusion: I did fail to make a game with this one. However I can’t really feel disappointed over that because the toy that came out has quite a bit of potential. It’s not very complete, but add a day or two of work and it’ll be a
really cool thing.