Game Development Log: Creating a Two-Player Box-Stacking Game - Prof. Ian Bogost, Study Guides, Projects, Research of Communication

Download Game Development Log: Creating a Two-Player Box-Stacking Game - Prof. Ian Bogost and more Study Guides, Projects, Research Communication in PDF only on Docsity! Demolition 1: Date: April 24th Software version: 0.35a Objective: Get 2 player sprites to display and move. Accomplished: Got both player sprites to appear, but only player 0 to move. The player sprites are animated. Problems: For some reason, I kept getting an unresolved symbol list error when I tried to write the code for player 2’s movement. I checked the documentation and was inputting the commands correctly like so if joy1up then w = w – 1 if joy1down then w = w + 1 if joy1left then v = v – 1 if joy1right then v = v + 1 Eventually I gave up and decided to take care of the problem later. The rest of the development went smoothly, I merely adapted code from the Avoid example in order to get movement and animation to work. The sprites I made with the sprite editor that is included with the 2600ide. I wanted to get the sprites to have yellow hard hats, but so far I only know how to make them one color, I’ll work on that later. ------------------------------------------------- Demolition 2: Date: April 24th Software version: 0.99a Objective: Get a bomb to drop, try to get both players moving Accomplished: Got a bomb to drop. Problems: It took a while to get a bomb to drop in the correct spot. I decided that rather than use a sprite or missile for the bomb, I’d just change a background square. I looked in the documentation for the 0.35a release and saw that the background was 32 x 11 squares. I then found out that the screen is 164 x 88 pixels. Dividing 88 by 11, I got 8 pixels per vertical block, dividing 164 by 32, I got 5.125 pixels per block. I set up an algorithm to choose where to place the block depending on the player’s position. The algorithm basically worked like so bomb0 d = x / 5 e = y / 8 pfpixel d e on The bombs were dropping in the correct y location, but only at blockX = 0. I tried importing the mul_div module, but it wasn’t helping. Eventually, I went on the forums and asked around and discovered that 0.35a was really buggy and I should upgrade to 0.99a, which I did. The division worked, but the x position of the background block was still way off. I thought about it for a while and remembered that the Atari 2600 displayed 40 blocks wide, and that the batari Basic kernel chopped off a few blocks. I eventually reasoned that it was lobbing 4 off from each side and added in a buffer of 2 more blocks for the eventual border that would surround the play area for a total of a 10 block loss. This meant that I was effectively working with 30 blocks, and doing more calculations, that the region was 115 pixels wide. So, dividing 115/30, I came up with a number close to 4. Then the algorithm was changed to be bomb0 d = x / 4 d = d - 7 e = y / 8 pfpixel d e on and bombs could be dropped. ------------------------------------------------- Demolition 3: April 24th Software version: 0.99a Objective: Try to drop bombs in better locations, add a border to the play field, try to get both characters moving, try to get both characters dropping bombs. Problems: I was able to solve all of the objectives. Since I had upgraded the software version, both characters could move just fine. I set up a second algorithm so that player 1 could drop a bomb. Since I had the calculations from the previous bomb dropping algorithm, it wasn’t nearly so hard. I just changed the coordinates to reflect player 2 like so bomb1 f = v / 4 f = f - 8 g = w - 1 g = g / 8 pfpixel f g on goto mainloop I made slight changes to both algorithms. Instead of dropping bombs directly on top of the player (a generally bad idea), I offset the x block so that player0 drops bombs to the Construction 7 Date: April 26th Software Version: 0.99a Objective: To make the win condition, when a character has a box placed on top of them they lose. Problems: The win condition took a bit of tinkering to get to work right, but it wasn’t terribly complicated. Whenever there’s a collision, the game checks to see if the player is sharing the same coordinates as an activated part of the playfield. If so, the game is over. The current win screen is very simple and really meant only to test the algorithm; it just changes the color of the playfield to either purple of green. This system is working rather well, I’ve stress tested it and haven’t found any bugs where the player is trapped but the game won’t end. However, this is one of the more important features of the game, so it’ll undergo strenuous testing. Design: It is still possible to trap a player’s movement without winning. This is actually lends a very interesting aspect to game play, for a person can have their foot pinned under a box or some such without being dead. This can be worked into the overall design and strategy of playing the game. ------------------------------------------------- Construction 8 Date: April 27th Software Version: 0.99a Objective: To resolve errors with dropping boxes near the edge of the playing field, add in a permanent intro screen, add in a win screen. Problems: The game was glitching when boxes were dropped near the edge of the screen because it would sometimes cause a negative variable to be stored, which the Atari doesn’t like very much. I put in several fail-safes to make sure that negative numbers would never be generated. I also designed the box dropping such that boxes that would be dropped outside of the playing field would no longer scroll onto the opposite side of the playing field. The intro screen and win screens were rather easy to make, I just used a utility on the bAtari site to generate the code for the words. I also added in a reset button, which can be used to reset the game at any time and to start the game when it is initially loaded. Design: Whenever a player wins, their score counter goes up. There really isn’t an end to the game; it’s just a matter of getting the high score. ------------------------------------------------- Construction 9 Date: April 27th Software Version: 0.99a Objective: Add in sound effects and whatever goodies I can squeeze into the ROM. Problems: I kept running out of space! I think the last build has something like…20 bytes left on the ROM. I added in sound effects for dropping the boxes, each player has a different sound effect, as well as a universal victory music that is played whenever a player wins. I would like to add more, but I’m not sure how much more memory I can squeeze out of the ROM without removing what I currently have, so I’m going to proclaim this game finished.