Last time, I talked about how we came up with the idea for our game. That took us all of day one (which was six hours in our timezone). However, having the idea is only one part - and just a beginning of a game-making journey. Fasten your seatbelts, because today we will explore day two of GameJam - designing a game. 

One could make an assumption that the game had been designed by the end of day one. After all, the idea was there, the tech demo was there… we just needed graphics, audio, and programming to bring everything together, right? Well, that is partially correct. What we had was a core of a game; a sketch; a blueprint. Only after I started programming and constantly play-testing the game have I realized that it was only a beginning of our journey. 

Some problems I had been aware of before I encountered them, during the planning phase. Others  I noticed after they manifested themselves in gameplay. In both cases I had to examine the issues and decide: "how to fix them", "am I able to fix them" and "is it worth it to fix them". Let’s follow the development of OutBreak chronologically as I explain all the game-designing I have done when making the game.

And at the very beginning there were already a lot of questions that I, as a game designer, had to answer. Just to name a few: - What size should everything be? - How fast should the player move? Or the projectiles? - How many blocks to destroy and repair should there be? - Where on screen should they appear?

These are the essential fundamentals - the basics on which everything else would be built. Players would not think about them if they were executed correctly but would immediately notice if these were off. If I am to be honest with you - in this case I mainly followed my guts. I determined the size and speed of everything through trial and error. I kept changing different values until they felt right to me. Locations of blocks came as a result of size and speed of everything else. I spread them evenly throughout the canvas with enough space for the player character to navigate between them. The palette that bounces projectiles is at the bottom of the screen - just as it was in the 1980's original.

One really weird thing in regards to the size is... the screen itself. The final game it is 1000 pixels wide and 720 pixels tall. I have no idea why. I probably wanted to aim for 1280x720 which is standard HD widescreen resolution, but then somehow mistyped and ended up with 280 pixels less. What's more, the game has 1000 pixels horizontally, but the level itself is a square, 720x720 pixels. The remaining screen estate is dedicated to the HUD. This created a problem. There simply wasn't enough information to display there. 

That's how I came up with this alien character, who watches players's game and reacts accordingly - laughing at them when they lose their combo and getting angry when they skillfully repair blocks. The alien was a very, very late addition to the game. Perhaps talking about it in a post called "day 2" is cheating, because it was introduced day 3, however, judging from the comments of our fellow jammers who played the game, it was the differenciating factor and a huge plus.

Sadly, not every aspect of the game was throughly explored and executed. One such glaring omission are the power ups. How can retro inspired game not include even a single power up? Unfortunately, I could not program them in time. However, I did have them planned. They were meant to be double-edged weapons. They would only appear from broken blocks, just like in the original Breakout - so players would need to make decisions to either get the power up or protect the block. Secondly, they would need to make conscious effort to get them; because if they didn't, the power up would be collected and used by the UFO.

Having a game without power ups did not solve all problems. In fact, it created a bunch of new ones for me to tackle. At that time, the game had extremely weird difficulty curve. It would start relatively easy - because there were a lot of blocks to repair. Then it would get really hard when there were lots of blocks and lots of projectiles. But as the game went on, fewer and fewer blocks remained and it would get very easy again. Players could simply maneuver around a single block and never lose. What's even worse, waiting for a projectile to hit the last block would get really boring really fast. That is why in OutBreak the UFO... is cheating. Or rather, the projectiles are cheating - but only when there are three or less blocks remaining. If this condition is true, every time any meteor bounces from anything, it has 25% chance to bounce not accoring to the laws of physics, but instead to bounce straight towards the closest block. That makes the endgame appropriately difficult and definitely less boring. 

Early builds of the game also struggled with promoting skillful play. Initially, colliding with meteors always stunned the player character for a single second. What's more, the score multiplier was tied to the amount of projectiles on-screen. This made sense to me at first. The more projectiles, the more difficult the game, the bigger the multiplier, right? Alas, this made the early game completely meaningless. It would be more beneficial to protect only a couple of blocks and wait for the multiplier to increase. After some thinking, I decided to implement two features that would heavily promote active and skillful play. Firsly, the stun duration increases with each hit. Secondly, the multiplier is tied to players's combo, which gets bigger each time they repair blocks without taking damage.

The implemented solutions undoubtedly improved the game compared to its previous builds, but when I look at it today, perhaps they made it too difficult. Many players commented that the game gets hard and chaotic very fast - and I think they are right. Maybe there was a simple solution to this problem. I could make the projectiles slower or make them spawn less frequently (currently, a new ball spawns every 15 seconds). Perhaps I could make the multiplier increase every 5 combo instead of every 10 combo. Or, perhaps, none of these would work and the game needed another brainstorming session and more drastic changes. 

But there was no time for that. The second thay came to an end. The final day dawned. I spent majority of the third day playtesting and debugging the game; I don't think there is anything interesting to write about that. However, my friends at Graterdog Studio were still very much busy  making assets which made OutBreak look, sound and feel so charming. That is why the final devlog will be all about them and their GameJam experience.