The following is a series of mini-postmortems for week “zero” of #90DayDev Jam. These prototypes were made between 9/6 and 9/11/2014. They are collectively known as week “zero” because I was trying to figure out how many game prototypes I was going to make in a week. After this first set of prototypes, I decided that I would make five each week with a postmortem about them the following weekend. These games can be played under the “Week ‘Zero'” category on my portfolio page.

The Power of Love

Summary:

I made the Power of Love prototype for two reasons. First, I wanted to learn how to use Construct 2 building a simple platformer. Second, I wanted to challenge certain conventions within Mario games that suggested that outright aggression was the solution to adversity. I would punish the player by sending them back to the beginning if they used aggression to defeat enemies. Instead, they would have to obtain the flower bouquet in the level and “give” flowers to the enemies by touching them in order to win.

What Went Right

• I was able to learn how to make a platform game quickly.
• I was able to insert some basic physics puzzle.
• Players expressed gratification at being able to take down enemies peacefully.
• Players brought their extrinsic knowledge of Mario games to the platformer.
• The game was more challenging than I thought it would be.

What Went Wrong

• One player expressed concern that I was teaching too much at once.
• Players did not realize that you didn’t have to jump on the enemies once obtaining the flower bouquet.
• The game wasn’t a physics game and probably should not have contained a physics puzzle.
• Extrinsic knowledge of Mario games had players expecting Mario physics.
• The level design might be too hard for a level one; probably appropriate for a level two.

Conclusion:

I was happy that players did bring some extrinsic knowledge to the game. I am glad that their first reaction was to “stomp” a Goomba and I enjoyed seeing how that continually frustrated them until they realized it was futile. I am displeased that some still tried to stomp on enemies even after obtaining the flower (I probably should have punished them when they tried and made the level so that they would be forced to directly engage with a Goomba without being able to stomp on it). While I am glad that I was able to get a basic physics puzzle in the game, I should have used the level design to teach the mechanics of the game.

Die by the Sword

Summary:

I made Die by the Sword to familiarize myself with eight-direction movement in Construct 2 and to illustrate a moral teaching attributed to Jesus in Matthew 26:52 (“those who live by the sword will die by the sword”). I wanted to focus on one mechanic, so I decided to make the enemies randomly generate and remain static (touching the enemies did not damage the player’s health). I also felt like an evil-looking enemy would pull on players’ extrinsic knowledge of enemies in other games and force them to shoot. Hitting an enemy with a bullet would remove the enemy from play and increase the players’ score. However, the bullet would continue to wrap around the playing field until it hit the player. The implication was that firing a bullet places your own life in danger and that you would inevitably die when it hits you.

What Went Right

• I was able to make a basic prototype in the time period that I allotted to myself.
• People seemed to identify with the skulls as enemies.
• People enjoyed the “wrap around” effect of the bullets and the danger that placed them in.
• The scoring mechanic was easier to implement than I thought it would be.
• The mechanic tied into the game’s theme.

What Went Wrong

• People were able to exploit the game so that they could continuously kill enemies without dying themselves.
• Construct 2 has a weird way of determining the “front” of a sprite; I had to play with it until it flew in the correct orientation.
• I am not convinced that the game best exemplifies Jesus’ moral teaching (even if people do not use the exploit).
• There could be more action to make the game more exciting (for example, the bullet could ricochet off the ship to make the exploit impossible).
• The game eats up too much memory if the exploit is used and people fire multiple bullets.

Conclusion:

It is good that I was able to use a moral teaching as a starting point to make a new mechanic. People seemed excited and wanted to see more. I suspected that the exploit might be possible when making the prototype, however, I was not too concerned. Nonetheless, it does exemplify why it is important to test to see how people will try to break your game before releasing a final build.

Save the Earth

Summary:

I wanted to experiment with touch input in a game, so I made a simple Missile Command-style clone. The players’ base would be approached by asteroids and they had to remove the asteroids from play by either touching them or clicking them with their mouse. Touching or clicking an asteroid would increase the players’ score.

What Went Right

• Touch mechanics worked a lot more easily than I thought they would.
• Some people thought the “game over” screen was funny.
• I was able to implement some basic difficulty adjustment (the speed of the asteroids and their respawn time increased slightly with time).
• The game was easy to make within the time that I allotted for it.
• The prototype allows for easy expansion.

What Went Wrong

• The game should become most difficult at about two minutes before trying to push players out.
• Obtaining points was not engaging enough; the game needed other “more fun” ways to obtain points.
• More feedback on a player’s progress was needed (such as displaying the final score when the player loses).
• The time allotted to develop the game was only appropriate for general knowledge, not more in-depth knowledge.
• I did not know how to implement visual effects (rolling asteroids, “juiciness” such as asteroids exploding and score multipliers displaying, etc.).

Conclusion:

This game was meant to teach me how to make a game which implemented on touch mechanics. If I build on it at a later date, I might work on implementing the things that were “wrong” with the game. It might also serve as a springboard into a more complex project. I am not sure there is much of a “game” here for it to be fun at this point.

The Power of Love 2

Summary:

I showed a friend my Power of Love prototype and he complained that the level design was too difficult for a first level (he felt it would make a good “level two”, however). I then hacked away at The Power of Love and made a simple level design that would force the player to learn the mechanics while being appropriate for a first level. I made it so that the player was forced to jump over the Goomba, go through the platform with the “jump through” property, and wrap around to collect the bouquet. The player was then forced to confront a Goomba. Doing this would teach them that it is okay to touch Goombas when you had the bouquet.

What Went Right

• I was able to quickly adapt the level design of the original Power of Love prototype.
• Players were constrained in their decisions and learned the design lessons that I taught them.
• There was no room for the aggression that was in the original prototype; even after collecting the bouquet, players were not as able to easily stomp on all of the Goombas.
• Players were forced to think about their decisions before acting.
• Someone remarked that The Power of Love might make a great mobile game.

What Went Wrong

• I felt like there was less exploration and players didn’t get to discover the solution for themselves.
• The level design can probably still be simpler.
• Perhaps it might be a better idea to create even simpler levels where players learn one concept at a time (one level could be collecting the flower, the other could be giving it to enemies, and so on).
• There should probably be more situations where players feel compelled or even come close to stomping on or attacking enemies.
• The punishment might be too strict if players stomp on enemies.

Conclusion: I still need to figure out how to balance instructing players how to play the game through the level design and letting players discover things for themselves. I could also do the opposite whereby I teach them the games’ rules in baby steps and then challenge them to continue to play within the rules. For example, I can lessen the penalty of attacking enemies and make it so that the player gets less of a reward for doing so (they might not get the best ending, they might get a lesser grade, etc.). Enemies might exhibit behavior such as throwing projectiles or being erratic in a way that might force the player to stomp them to deal with the problem in the short term but which will hurt the player in the long term.

Bullet Time

Summary:

I made Bullet Time to familiarize with how to adjust a sprite’s angle in Construct 2. Originally, I had generic enemies with evil looking faces, but I decided to stick with turrets for both the player and the enemies because I felt it was easier to track the turret’s line of fire by relying on the players’ extrinsic knowledge of turrets in other games. Enemy turrets fire bullets slowly and the player must destroy the turret quickly before being hit by too many enemy bullets.

What Went Right

• It was easier to track where the bullets were aimed by using the sprite as a reference.
• It was not that difficult to get the sprites to orient themselves toward a reference point.
• The game is easy enough to adapt for a future prototype.
• There is a bit of strategy in firing shots.
• The bullets and enemies contrast well against the background.

What Went Wrong

• The game ended up being an entirely different game than I envisioned.
• The game probably could have been more fast paced.
• There is no feedback on important things such as player and enemy health.
• I could have relied on other symbols to communicate gameplay.
• I was not able to implement a recharge timer for both the player and enemies.

Conclusion:

I think that the symbols in this game could be mapped differently. For example, instead of bullets, I could use enemies escaping from a base trying to attack the player. The player must then kill the enemies and attack the base. The reason I came to this conclusion was because people expect bullets to move faster. If I remapped it to a “slower moving” object, then people might not have carried these expectations. There were also technical issues which I could not address in the time allotted. I will gain that knowledge in time. Perhaps I should focus on a specific “game genre” and use prototypes to learn how to master different aspects of that genre.