This will be a race among all programming languages.
War of the languages!!! The human player will be the Assembly Mobile, and the other AI routines will be named C-Mobile, Fortran Mobile, Basic Mobile, etc. There will be point and time bonuses. Running over (picking up) certain items like a RAM chip, resistors, capacitors, intel symbol, etc. can be used for point bonuses. Time bonuses are possible only through the pick-up of a clock symbol. Obstacles are included in this game also. Such obstacles include undefined variable , mismatch arguments, char-to-int warnings, etc. This will result in points taken away. Objective: be the first to terminate successfully. i.e. Don`t: lose to another (AI) player, or run over an infinite loop symbol or segmentation fault.
The above was the original idea. Our major goals included:
For the whole game, we used eight pcx files that were used throughout the entire program. Such .pcx files included the Introduction, Option, Win, Lose and Credits Screen along with the track components(pictures of the cars among. other things such as the collision icons. The screens used for the screen buffer was 320x200 pixels. There was a total number of seven segments- Sound Segment, Screen Buffer, ZBuffer, Track Segment, Image Segment,Stack Segment, and Scratch Segment. The ImageSeg was used to load each of the seven screens when called within the main game loop. The images.pcx file, stored in ImagSeg while the main game loop is executing, included drawings of all the cars, the obstacles, powerups, track segments, and any other effects used. The IntroScreen was always called at the beginning of the game. It was followed by the OptionScreen with the options to either: Play the Game, View Instructions, or End the Game. From this, it could be determined where to go within the game.
The interrupt routines were similiar to those used in MP3. The user would key in the proper inputs and from that the appropriate flags would be set. The flags represented all the options in the game, the user movement, user direction, and other user inputs that represented other keys being pressed.
When playing the game, it is crucial to continuously check for collisions among other players, objects, and track boundaries. All the offsets to the images of objects in the track were represented in an array called ObjectOffset. This array represented the driveable and nondriveable parts of the track, along with the other obstacles/powerups located on the track. Depending on which collison case, proper adjustments were made to the players' speed, movement, and position.
SoundSeg would contain a .raw file, loaded by a call to PlaySound, and the sound would then be played. However, due to the flakiness that the introduction of the sound code created in the main code, and the fact that IRQ and Channel info was hardcoded, we decided not to implement sound in the final product.
TrackLayout is an include file that is 20 x N bytes long, where N is the length of the track, in 16x16 tiles. The information contained in each byte of the include file represents an object tile (16x16 pixels) ont the actual viewable screen. This allows compression of the play track, so that its representation may fit within one 64k segment. The track then is allowed to be 3270 tiles long (20x3270 = 64k), rather than 12.5 (200/16 = 12.5) this is a great compression rate.
