Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

An Introduction to the Computational Media - Project 8 | LCC 2700, Study Guides, Projects, Research of Communication

Material Type: Project; Professor: Bogost; Class: Intr-Computational Media; Subject: Lit, Communication & Culture; University: Georgia Institute of Technology-Main Campus; Term: Spring 2006;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/05/2009

koofers-user-90u
koofers-user-90u 🇺🇸

10 documents

1 / 3

Toggle sidebar

Related documents


Partial preview of the text

Download An Introduction to the Computational Media - Project 8 | LCC 2700 and more Study Guides, Projects, Research Communication in PDF only on Docsity! Project 8 Atari 2600 Producer: James Truesdell Developer: Mike Roth Programmer: Matthew Yannetti Game: Sdioretsa Entry 1: 04/18/06 Today we met and discussed what we would like to see as far as a game would go. In the end we decided to go with Sdioretsa which we decided would be one of three versions of a remake of Asteroids. We discussed two modes of play, one being having a game with a plethora of asteroids and have player 1 control ship movement and player 2 control the firing of the guns. The other version was slated to be a setup where player 1 controlled the ship's movement and player 2 controlled the movement of an asteroid. At this point there was no indication as to which direction would be the most possible on the Atari hardware as none of us had previous experience with the system. For this planning session we focused mainly on the idea of controlling the asteroids themselves. A question that was raised was how one might go about drawing multiple asteroids on the screen when on the hardware level you are only given the ability to draw 2 sprites. It was suggested to us by Professor Bogost that we would need to draw directly to the screen rather than rely on the sprites for the asteroids. We discussed the difficulty of this method and then finished our meeting. We had not yet decided whether to go with a human controlled asteroid or a two player ship. Entry 2: 04/24/06 After dwelling on the project for a while we came to the conclusion that based on our talents and schedules we should follow the "roles" method. Mike had expressed interest in being a 'designer' as he was more familiar with flash, Photoshop, and other similar things. Due to my rather large Game Boy Advance project for my CS2260 class I thought it would be better if I was left to do the organizing, emailing, and so fourth on this project. Matthew is currently a CS major and was already somewhat familiar with the BASIC coding language so he seemed the man for the job. At this point Matthew had already begun to program a tech demo so that we could have something to show on the previous day when we were to present our idea to the class. Some difficulty in just how one compiles and writes code for the Atari was expressed. It was still not clear which version of Sdioretsa we should go with as not enough code had yet been written to decide if one was too difficult or not interesting enough. Entry 3: 04/25/06 In an email message I was sent the tech demo version of Sdioretsa that we were going to use in our presentation to the class. Currently it was able to do 8-point turning, move forward based on the direction of the ship and could wrap around on all 4 sides of the screen. Mike had also sent me an email telling us that he had created a flash animation that we would be using for our presentation to help illustrate what our goals were for the project. He also took the time to make us some 70s style box art which was a great surprise. At this point, based on the tech demo, it appears we had decided to go with the original plan for Sdioretsa where the second player controls the enemy asteroids and the first player controls the ship. Before class we briefly reviewed on what we wanted to communicate to the class about our project. We were to touch on briefly what our thought process was for the game and some design difficulties. Entry 4: 04/26/06 It turns out it is quite difficult to make the ship drift in the zero-gravity Asteroids-like manner. To get drifting to work Matthew used a variable split into 8 bits to store memory of the ship's speed. There was a peculiarity in that moving up and right worked as they were supposed to, but left and down didn't. What made this confusing was that, it was the same exact code for up down left and right so if one failed they all should have and if one worked they all should have. Matthew decided to ask the Atari boards to find out if this was a common problem or perhaps some irregularity in the way BASIC compiled down into Atari assembly code. After waiting anxiously for some time Matthew got a response from the people on the Batari forums and found that it was due to a strange, strange to us, syntax that Batari used for splitting bits. Matthew had been storing the bits using a c[2], c[3], etc format but apparently in Batari basic it sees these as arrays. So rather than storing the number that he thought it was storing it was actually storing them in such a way that c[2] = 'e'. Once this was realized he had no trouble at all making the ship have the appropriate zero-gravity drift we were looking for. Entry 5: 04/27/06 After class on Thursday we had a brief meeting to discuss some design issues. Our original plan for Sdioretsa was set so that when the player with the asteroid was hit their asteroid would split into two. One of the asteroids would be controlled normally while the other would be reversed on the x-axis based on the current position of the main asteroid. Then those were also to be split into two upon being shot with further axis inversion. Matthew attempted to implement this but as a group we decided that it was just not going to work. The main reason for this issue was because the Atari game cartridges could only hold 4k of information. If we had implemented our game in its truest vision we would have needed much more space. We had a brief brainstorming session and came up with a few viable solutions to our problem. I suggested that perhaps player 2 only have one asteroid that can take multiple hits. Perhaps then, when it gets hit, it will shrink in size and increase in speed. Mike suggested that we could have an infinite amount of asteroids on-screen that are summoned by having player 2 hold down the fire button on their joystick. Then the second player would control the entire field at once using their joystick. We had envisioned something that had a very rapid spawn rate and would be very chaotic. That is where we left our progress on this day.
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved