Picture of the prototypes (1. & 2. Bat with sonar, 3. final prototype version, 4. bat in wheelchair, 5. multiplayer, 6. QWOP-bat, 7. Bat & Pig)

During the first phase of this project my main assignment was to prototype different features for our bat game. I don’t think I will have a more enjoyable task throughout the development cycle. Prototyping, or rather experimenting with different features and mechanics is definitely my preferred method to game development and design.

We had a lot of different ideas of how our version of “Heartbeat bat” should be. Some of the ideas where clearly bad and was scrapped instantly other ideas went on to a prototype phase. Here I had to, in Game Maker, quickly make playable prototypes so we could test how a certain feature worked. This blog post will cover the entire prototype phase and I will try to explain how I worked and what that work meant for the design of our game. This is not

At first we tried to make the game play as close as possible to the game described in the concept document. This was mostly based on the sonar mechanic where the bat would use sonar pulses to detect the level obstacles. This was a pretty cool visual effect to see the level appear in front of you, but it also made the game a bit slow. In order to make the game playable and still have a meaningful sonar effect we had to both decrease the complexity of the levels, and the speed of the bat. We wanted to have a bit more speed to our game, so we tried a couple of prototypes with full vision. In these I tried different versions of a more physical control scheme where the bat was controlled almost like a glider. Here the bats angle would affect both the bat’s speed both vertically and horizontally. I really saw potential in this type of movement, it added a big skill element to controlling the avatar. Big dives would give the player a huge boost in speed while ascending quickly would slow down the player to a near stop. But this method of moving the avatar was not received well in the team. They found it way to difficult to control the bat and wanted the player to have much more direct control over the avatar. So the final prototypes was based on a more controllable bat with a more complex level design.

Outside of these above mentioned prototypes we also tried some others that was a little more “outside of the box” for more unique takes on the bat game. Among these were one multiplayer prototype with two bats racing, a QWOP-styled game that let the player individually control each wing of the bat, a physics game with a bat in a wheelchair rolling down a hill and one version that let the player control two characters simultaneous (a bat and a pig). These (except maybe the multiplayer one) did not have substantial impact on the game we are working on now but they made us let go of ideas that weren’t feasible and therefore they worked. Showing that something doesn’t work is almost as important as the opposite.

Extensive experimentation and prototyping might not be the way to go in a well-oiled team with a unified vision and a strong leader. But in an inexperienced team with democratic structures for decisions it pretty important to try out the different ideas of the group. Both to find the good ones but also to leave the bad (or too hard) ones behind. Also, although it is a pretty sloppy way of designing a game, it is pretty fun.