When We Thought up the Game, We Had a Very Simple and Broad Idea in Mind. All We Knew Was

Design 1: Ooze

When we thought up the game, we had a very simple and broad idea in mind. All we knew was that we wanted blocks or some kind of obstacle falling down with two players trying to dodge them. The game was not so much a competition as a collaboration between the players, working together to get the best possible score.

We found a very similar game on the alienbill website called “ooze” so we took a look at the code and tried to adapt our idea to that game. The game was not finished by any means, so we just got the basic idea and got more familiar with the code. At this state, it was more like a line of ooze falling down with one sprite shooting the other sprite as the “missile” to shoot the ooze.

From here we took the “missile” out and tried to make the ooze into just a falling brick that the player can dodge. We also took out the border, but kept the invisible border in tact. The scoring part of the game, for some unknown reason, would mess up in the beginning and not correctly show the first digit of the score.

Design 2: One brick ooze – wider

In this design, as said before, was actually one brick falling at a time. But at this point the timing for when the bricks fell was not very random at all. Another problem we thought of was that the bricks were too skinny, so we tried making them a big square rather than a skinny rectangular bar. This would make the game a little harder.

Another way to make the game a little harder was to start the bricks falling at a slow rate, but as the game progresses, the bricks would eventually fall faster and faster. This helped out a little with the randomness of the falling bricks. They would become more random and spaced out, which allows for the player to have some time to move rather than have almost a blanket of bricks falling down.

We haven’t added in the scoring and collision detection yet. These were being worked on separately and will later be collaborated. The score issue has still not been resolved. We also have not yet put in the second player of the game. At this stage, we were still contemplating adding in a missile, such as the one in the original game so that players can shoot the bricks. But we decided against the idea for now since we knew eventually we would have two players, but only one missile which would pose an interesting problem.

Design 3: Collision

In this design, we added in the collision detection. As said before, we made the bricks wider to make it harder and more challenging than before. This was all that was done before moving onto the next design.

We were starting to work on adding in the second player which would allow for the cooperative play that we wanted in the beginning. Again, the problem with the score has still not been resolved. We don’t know why it won’t work right.

Here we were thinking of some titles we could call the game, and decided to go with “Collision” for now. It wasn’t a very creative name but we needed to call the game something.

Design 4: Collision – 2P

After playing around with the code a little bit and trying to change the randomness of the timing for when the bricks would come down, we ran into a bigger problem. The result was that the bricks all came down at once and very fast.

But on the other hand, we got two players working and collision working for both of the players. So now all we needed was a way to track which of the players were still alive, or if both of them are dead. If both were dead, we need to end the game somehow, so we got started on another part of the game – the end screen. We really weren’t sure how to approach this because what else was there to show besides the score? Also adding in the big letters would take up a lot of space, which we didn’t want right now. So in the end, we started to work on a way to clear the screen and just have the score shown at the bottom of the screen.

In this version of the game, we decided to try to add in some form of scoring. We just tried the basic, add a point for every second or so that each player was alive, but it was hard to tell if it was working some of the time. We decided to move on and adapt the scoring later on because our code will probably change. But we tried several different methods of how we could track the sprites and score the game and will test it out on the next version of the game.

Design 5: Efficiency

In this version of the game, we decided to clean up the code a bit and try to get the random bricks falling timing together. In the original version of the game, the coding was using line numbers. We decided it would be best to take out the line numbers entirely because it basically made the program jump around all over the place which made it hard to follow sometimes. Instead, we used blocks of code and would have as few jumps as possible. Here the code looks a lot cleaner

We also fixed the falling bricks problem that we had in the previous design. But we realized that we had made the bricks start off falling pretty quickly, which we will fix in the next design. Here, we also played around with different sprites just to see how it would work out. We aren’t sure if we will keep the different sprites.

Still, we can’t figure out what is wrong with the scoring but we will leave that to the end because it is not a major problem right now. Right now, our focus is on adding in the scoring to the rest of the game. That is basically the only thing we are missing. But we also wanted to add some finishing touches such as a start screen which will display the title of the game. And when you press the “fire” key, it will start the game.

Design 6: Gravity Sucks

This is the final version of the game with everything (excluding the one digit not working on the score) working. To compensate for the digit not working, we decided to increment the score by 10s and 20s rather than 1s and 2s which means the non-working digit will always be 0.

Here we have added in the score and it is working. The way it works is that when both players are still alive, the score will increment by 20 about each second both are alive. And when one dies, the score will increment by only 10 each loop. Before we had a problem with moving the sprite to 0 position because it would continue to calculate the collisions with the bricks even when not in the screen. In the end we decided to track the sprite collisions by moving them to position 180, way off the screen.

We have also implemented the clear screen when both players die. That indicates the end of the game. And that is basically our game. In the end we decided on a different name – “Gravity Sucks” since it is a bit more creative.