Introduction to Computational Media - Progress Report | LCC 2700, Study Guides, Projects, Research of Communication

Download Introduction to Computational Media - Progress Report | LCC 2700 and more Study Guides, Projects, Research Communication in PDF only on Docsity! Progress Report 1 The first time we the group got together we had to decide how we were going to make this game. At this first meeting we chose the ad-hoc method (but as you can see from reading this, we changed our minds later). Then we had to decide what kind of game we were going to make. Our first idea was to recreate the Bomberman game, and our version would be similar to Playing with Fire. We thus discussed several features that our game would possess. It would have two players, and the background would be a static map of impassible and passable tiles forming a maze. The players would be able to pick up bombs lying around in the maze. The point of the game was to detonate the bombs and strategically place them to go off next to the other player to trap and kill them. The bombs would also destroy any of the blocks of the maze they came in contact with. Originally we decided that the bombs would look like little circles that flashed colors when detonated, then make a cross pattern when it blew up. The cross pattern would be what killed any players beside it. At this point we had not designed the actually characters yet, but we knew we were going to make them animated in some way. We came across our first problem while trying to think about how we would make all of this work. We couldn’t figure out how we were going to make the bombs, since the game can only have two sprites and one missile. If we made the bombs a missile it would be too slow and players could only set them off one at a time. We also had to figure out how to change the background every time a bomb blew up a block. One idea we came up with was to make the background itself act as the bombs. For example, whenever a player wanted to detonate a bomb, the square it was on in the background would explode. We then decided to go home and think about these problems until our next meeting. Progress Report 2 In the next meeting we decided to change our idea of the game so we could overcome the previous problems. This time the background would start empty, and the players could drop up to 3 bombs at a time. Instead of picking up bombs, they would just have an infinite supply already on them. When bombs would be dropped, the square they would be dropped on would turn red. When the bomb explodes the square would turn yellow and becomes impassible. We also changed around the object of the game. The players were still supposed to kill each other, but they would have to do this by trapping the other player in the game inside a ring of boxes made from exploded bombs. The detonation of the bombs themselves would not actually kill anyone. We also fiddled around with the idea that the player could die if they walked over the bomb before it detonated, or simply couldn’t walk over the bomb at all. As far as character design, we thought the sprites should look like little construction men. One would be red and one would be blue, and they would both have on yellow construction hats. By now we were pretty confidant that our new idea would work. We also decided to change our method of working and we assigned roles. Lydia(me) would be Producer, Amichai would be Designer, and Elijah would be Programmer. We thought this way would be more efficient. At this meeting we got the PowerPoint for our presentation finished, and made a picture of what we imagined the finished game would look like. We also came up with some things we might like to add to the game if we had enough time in the end. These were the possible things to add that we came up with: Bomb stacking to increase blast radius. When characters are caught in the blast they die. random bombs appearing, Superbombs!, ability to diffuse bombs – 50/50 chance of working, and bombs that explode but don’t destroy background. Progress Report 5 At this point we decided it would be difficult to make sprites for bombs. So basically we decided to throw out the bomb idea altogether. Originally we had pseudo- settled on the idea of making the game called “Demolition.” Well now that we weren’t destroying anything in the game, we needed to change it but keep all of the work we had done so far. So the idea for “Construction” was picked up. The “bomb” squares that the sprites were dropping on the background looked a lot like cardboard boxes in a factory. It also appeared that they were literally building walls of boxes. So we decided that instead of dropping bombs, the players were dropping boxes instead. Basically, the players play as two workers at a box factory who are in a grudge match to the death. Their only weapon is the one tool they have for their construction factory job- the cardboard box. The object of the game is to trap the opponent in a pin of boxes so they can’t move anymore. The idea of sliding boxes and destroying them with missiles was also toyed around with. Just like the idea of the players being able to diffuse the bombs, the players should be able to destroy the boxes. Ideally the players would gain the ability to have 3 missiles that can destroy a box. Progress Report 6 The next objective was to allow the players to slide boxes on top of other boxes. This basically works if the player drops a box on a square where there is already a box. The newly dropped box will move the old box that was dropped before to the next available blank spot in that line of the playing field. Before this was accomplished, a bug in the current code was found. Player 2 was no longer dropping boxes, and player 1 was dropping them instead. What caused this bug was that the function for setting player 2’s bomb was incorrect, causing the program to execute player 1’s box dropping algorithm instead of player2’s. This was then fixed. To get the boxes to slide, the box dropping algorithm was modified to check and see if the next background slot was on or not. If it was, it would add or subtract to increment to the next box and then recursively call itself until it found a blank spot, then it would place a box there. There ended up being a problem with this. After playing for the while, the game would start going crazy, so obviously the game kept adding boxes beyond the playing field forever and ever without stopping. This was resolved by checking to see if the current box was beside the border of the playing field. If it was, the algorithm would immediately terminate and draw a box on top of the border. Progress Report 7 The next goal of the game was to limit the rate at which the players could drop boxes and add in collision detection. Collision detection would make the maze of boxes and actual maze of boxes that the payers could move around in. Before the sprites could just move right through the boxes, and it was impossible to trap the other player. For the limiting of the rate of box dropping, a timer was made that would only allow a bomb to be dropped once every 30 ticks. Making the collision detection work ended up being the hardest programming part of the game. The first version of the game with collision detection would move the player based on which direction the box was that they collided with. This ended up being a problem, however, because the players could slip between boxes when going in a diagonal direction. To try to solve this, the sprites’ movements were limited to the four cardinal directions. The collision detection was redesigned to remember what direction the player was moving prior to collision and then move them in the opposite direction. However, this was easily broken if a player pressed another button while in mid-collision, causing the sprite to slide through the playing field. Finally a working method was produced- to check collision before updating the player’s position, and then just restore the original position. This method caused a problem that eventually turned out good for our game. If a box was placed on top of a sprite, it would be trapped. This meant that if the players dropped the box on their own sprites, they would kill themselves. So in order to avoid this, the sprites were made to drop the boxes far enough away from themselves not to get trapped. So we decided to use the box smashing as the win condition. The goal of the box factory workers was to squish each other to death with their boxes. A good way to do this would be to use the collision detection to its full advantage and trap the other player in a corner of boxes that was previously laid down.