I have a couple of these lying around, and I figured I might aswell write a bit about them. The first one is “rain”. Most my games get a short name like that while I make them, Eater of Worlds was called slingshot, flashbombs was called bounce and dingding was called grid.

This uses the Boids style simulation from Popeatron to make a cloud, it looks really nice, but with one drawback. It’s horribly slow.I could probably speed it up quite a lot using stuff I’ve learned since then, but would still be a waste of processing power to do the cloud like that.

It does controls quite nice, the cloudlike feel is there when you’re moving it about. This is one of those things that worked as a toy, but where I had real trouble finding the gameplay.

I tried playing around with mouse gestures since I didn’t want to get keyboard controls in there, the mouse is so much nicer. So, by “massaging” the cloud you can make it rain, and if you move the mouse a bit faster in one direction you’ll make a lightning bolt.

And that’s about it. I never found a way to make it into a game without making it overly complicated. Instead I moved on to make Eater of Worlds.

The game is after the break.

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.

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.

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.

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.

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.

Description: The idea I had from that was to drive one of those swamp boats around and be generally secret. But that seemed like too much of a racing game and not very interesting. I thought a bit about what you could do with a standard racing game to mix it up a bit. I knew that if I was to make a racing game it’d be top down as anything else would have been a bit too complicated for such a short development cycle. Eventually I came up with the idea that the steering of the boat would be broken, and the player would need to use a rope to latch onto different things to steer. This would make excellent use of my new best friend, the rope.

What went right: I think this is one of my most complete games. It goes beyond being a toy with an added layer of rules on top and actually qualifies as a proper game. Whether this is a good or a bad thing I’m not entirely sure. The game has a kind of flow, which you really need to get into to get good scores and I really like that.

What went wrong: It is a bit hard to play, increasing the size of the anchors wouldn’t hurt at all. I tried to make the game zoom out with the speed of the boat but, as usual, due to somewhat hacky programming it wasn’t possible without a major rewrite.

Conclusion: With this game I found a simple, working gameplay mechanic. It’s as I said one of my most complete games. Though this in it’s current state is a better game than for instance Moonlumber, I think Moonlumber has a deeper mechanic, albeit not as simple. What I’m trying to say with this is that if I’d work a week more on both of these games I really think Moonlumber would end up being the better of the two. But, I might be wrong, this game does have a certain appeal. If you add some obstacles, different things to latch onto and bunch of real levels it might become a real killer. It’d make a nice game for the Nintendo DS for sure.

Description: The first game made as the rules intended. On this game I was inspired rather quickly, and my first plan was to make something about driving a logging-truck on the moon. I found some tutorials on inverse kinematics and toyed around with them, and after looking around a bit I came across the rope physics example. The rope uses a combination of techniques, and handles the segments as a series of particles with constraints. Add some inertia and gravity to that mix and you have a very pleasant behaving rope. This rope was too good of a thing to pass up so I decided that you’d fly around in a saucer picking trees up instead. The first version I did had the saucer flying over a flat landscape, and the challenge was more to keep the saucer from crashing than anything else. That wasn’t really fun enough, so I experimented with wrapping the gameplay around a sphere instead. It did get more interesting, but was in essence the same game with a bit of gloss on the top. But once i made the controls a bit more forgiving and added in the possibility to throw trees I found some solid gameplay.

What went right: I find the game very visually pleasing, add a few more types of trees and a better background and it will look splendid. I really think the gameplay is there, however I think it’d be better suited for mouse control than keyboard. This would remove even more focus from controlling the ship allowing the player focus on the actual game.

What went wrong: It has absolutely horrible code. The ship isn’t really moving around the planet, it’s just rotated in to make it seem that way. This makes the physics behave a bit weird. As an example, it’s impossible to throw a tree into orbit. It will always fall onto the moon, as the gravity really is a linear gravity wrapped around a sphere. If I’d want to make something more of this game I’d have to redo it from scratch. This fact made it very hard to change things as the game went along, adding in mouse control would require a complete rewrite.

Conclusion: I like this game, it has potential. The game would benefit from a more management style approach, watering trees to make them grow, keeping vermin away and remove weeds. This would make the whole throwingmoment a bit more exciting as it’s really a bit of a gamble. You’d be able to get much higher scores, but at the same time you’d might not get anything at all. I’m glad I started working on it as early on as I did because that extra time on the end was sorely needed. Without it the game might not have had the throwing, which would have made it a lot less entertaining.

Description: This was a game I made in less than the chosen time limit, it was basically thrown together in an afternoon just to get back my feel for Flash (It had been more than a year since I did any proper stuff using it).
My original thoughts about the game was to make it a bit more of a freeform music game, where the primary object would be to keep in sync with the beat not having to press a bunch of stuff in proper sequence.

What went right: The basic idea isn’t all that bad, a proper song in the background and some better spawning of the instruments would help it a lot.

What went wrong: It’s a rhythm game that doesn’t keep to the rhythm. You need to do a bit of buffer trickery to get flash to stay on the beat. Fixing this would also add
quite a bit to the gameplay. Most of the other problems are related to this, to get the score to be even slightly accurate I had to make it so forgiving that it almost is hard to understand what it actually rates.

Conclusion: As it is, it’s not a very fun game. It does have a slight potential, but it would need several iterations to be amusing. I’m unsure how well suited it is for being mouse controlled, maybe an analogue gamepad would be better.