3D Contraband Wars
Introduction:
Our program is based off of the popular calculator game "Contra Wars." We are making a 3d implementation of the game, in which the player can walk around through 3 (mabye more) different cities, buying and selling contraband. The goal of the game is to make a bunch of money, and not get caught by the cops.
The format of game is based mostly on mp4/mp5, with enhancements in logic, graphics, holding variables for different player statistics, and reading in new parts of the maze for different events that take place within the map.
Events will take place at "dealer points", "addict points", and "airports." At dealer points, you are able to purchase different kinds of contraband. Prices will vary according to city, time, and other random events that may take place. The same is true of addict points, where you can sell your contraband. Addict points will also randomly double as "cop points", where you will be able to either run or surrender, with each decision randomly giving you a different good or bad outcome. There will be one airport per map, which will be both the starting point and the point where you are able to change cities.
There will be global variables that deal with player stats and time. The first variable will be a time limit. After a certain number of minutes, the game will end. We plan on *possibly* implementing a high-score system for the player. Variables will also hold the amount of money the player has, and the number of contraband he is currently carrying. There will be 6 different types of contraband, including doj, coke (a-cola), hcl , vitamin e, pony, and moonshine.
The main program will first read in the all of the maps and store them in seperate arrays, using a readmap procedure. This procedure also reads in dealer points, addict points, and airports. The initial money value is set. The game timer is set and starts counting down at the start of the program. Graphics procedures are called to draw the sky, ground, and walls (and any other visible points). Gameplay is then started, using the logic procedures for random events. When the player hits an event point, a box is drawn with directions telling the player what they can do at that point. Once time runs out, the game ends.
Team Members:
Jamie Doenges - Mode 13h text display, logic operations
Aaron Johnson - Gameplay/logic
Alex Mihov - File I/O, Maps
Matt Welle - Website, PCX Graphics, misc. routines
Problem Description:
There are many different difficult parts of this lab. The first is the implementation of a logic system within the game. When the player gets to an event point, he/she is presented with a number of different options from which to choose. The player can navigate through the different menus, making decisions on how they want their game to go. Another challenging part is holding variables for time, money, and the number of different kinds of contraband the player currently has in their inventory. Yet another challenge is displaying letters and numbers in mode 13h. There are many more aspects to this project, as will be outlined below.
Implementation:
First, we will read in maps as we did in MP3, and store them in an array. However, instead of loading one map, we instead load 3 (for the three different cities it is possible to visit during the game). These cities are stored in temporary arrays, and when the ChangeCity routine is called, the appropriate array is loaded into the main [_MAZE] array.
Initial values are then passed in to the players stock. The player begins with no contraband, and $20000 on hand. When contraband is purchased, the monetary amount goes down, and that type of stock goes up. Likewise, when a sale is made, the stock goes down and the cash goes up.
Airports connect the three cities. When a player activates an action at an airport point, they are able to switch between any of the three cities. Each city offers a different price for different kinds of contra. When a player changes cities, the number of days remaining in the game decreases by 1. When there are no days left, the game is ended.
finproj.asm main game file
I/O Procedures:
- # [pound symbol] maps to WALL
- [space] maps to HALL
- A indicates and airport starting/ending position for each city.
- D indicates a contraband dealer
- C indicates a cop
The procedure will update _POS based on the location of A
This part of the project is much like a souped up mp5. Instead of drawing boxes and trapezoids to represent halls, floors, and ceilings, we instead use PCX graphics. PCX graphics will also be read in for airports, dealers, and addicts. The screen will need to be updated each time the player moves or changes direction.
Inputs:
Draws a box with the given height and width. AX points to the texture file located in the game directory.
Inputs:
Draws the side wall with the supplied texture. AL tells us what side the wall is drawn on.
Inputs:
Simply draws the back wall by loading calling DrawBox.
Inputs:
Sets up the registers for DrawWall, and then calls it. Use the different size arrays to determine where the wall will be drawn. DX holds the current city index, which can be used with a lookup table to decide what city we are in, therefore affecting the pcx graphic that will be used as a texture for the walls.
Inputs:
Draws the floor and ceiling. Also uses View3d[index] to determine whether or not the dealer, addict, or airport needs to be drawn. The pcx graphics for these three elements will be prescaled, and the graphic we load will depend on the depth at which it exists.
Inputs:
Draws the screen by calling DrawBackWall, DrawFloorCeiling, and DrawSides. Depth will be decremented for each trip through the loop, and when index=0 the full screen will be drawn.
Inputs:
This routine updates the screen each time the player turns or moves. This is done by reading the information from the _MAZE array and interfacing it to mode 13h.
ScaleGraphics
Inputs:
This routine scales the texture according to the depth passed in through SI.
This part of the project is basically concerned with data maintenance. There are certain statistics that we have to keep track of, which we will do in variables. We need variables for:
Also if we feel ambitious, we can make a high score chart using what we know about file i/o. We can save the chart directly as ASCII strings for the names (limiting the names to, say, 3 characters) and then one word (or maybe a double word) for the score. Then we can just read from the file whenever we want to display high scores and do read/write to update the scores whenever the game is exited.
Inputs:
Facilitates the output of text messages (such as score) without switching from graphics mode. Reads character image from charArray which contains representations of numbers and capital letters as an 8 pixel by 8 pixel square. The offset into the charArray is calculated from the ASCII value of the character. Successive calls to DrawCharacter should be made with DX increasing by 8 each time, since the characters are 8 pixels wide.
Inputs:
Analagous to dspmsg, but for graphics mode. Calls DrawCharacter with the contents of the provided string until reaching the null character. Now we can easily use binasc with the DrawCharacter routine to display scores and whatnot. Care must be taken to properly justify message and insure that it does not overflow the screen when using this routine.
Inputs:
Draws all of this information on the top of the screen (since there is nothing important to look at there anyway). Uses an opaque background color so that we can update the message without redrawing the other stuff on the screen. This routine should be called from DrawGRScreen after everything else is drawn, and also anytime any of the stats are modified.
Inputs:
Returns:
Accesses the price and quantity arrays for the given drug to determine whether the deal is allowed. If the deal is successful, the quantity array and cash on hand values are modified and DrawStats is called. Otherwise, a nonzero value is returned in AX to indicate the reason (so that it can later be used to display an appropriate message).
Logic
What's needed?
Are addicts cops?
High score... $$ after 30 days, or when exit.. write to file
Variables:
Methods
- update: update time, call relative events, and day update.
INPUTS: NONE
OUTPUTS: if event occurs, calls "updateDisplay", changes _day if needed
DESCRIPTION: overrides the timer interrupt and establishes a counter to keep track of the time gone by. Every 10 seconds, there is a 1/100 chance of one of ten events happening. Also, each day will be 4(?) minutes long, and the display is updated accordingly when the days change. Calls "change prices" regulary as well. ALSO quits game if 31 days is reached
- quit game
INPUTS: NONE
OUTPUTS: _cash
DESCRIPTION: converts all of drugs into money at a certain rate, and then varifies if the score was good enough for a high score. Write to file, if it was.
- relative event: certain chance of event. if chosen, calls out methods to carry out event and display to user
INPUTS: NONE
OUTPUTS: if event occurs, calls "updateDispay." Depending on what event, will change the prices of drugs dramatically
DESCRIPTION: called every 10 seconds. Uses random numbers to determine if an even has occured, and which one has in fact, occured. After changing the price, displays a text message to the user
- change prices (changes prices in all towns, and the random# dealer array)
INPUTS: NONE
OUPUTS: drugzTownA_, drugzTownB, drugzTownC, dealerNum. Calls "update screen" method to let user know about price changes
DESCRIPTION: Randomly changes the price of drugs in the different towns, as well as the dealer numbers. this might eventually incorporate trends into its logic, but for now is just random.
- copDecision: takes in what the users decision to a cop was, and responds accordingly
INPUTS: AL is 0 if run, 1 if surrender, and 2 if offer drugs
OUTPUTS; _currentDrugz, _cash
DESCRIPTION: Called after addict is shown to be a cop, and user selects an option of what to do. This ranomly decides what to do with the reaction. Changes drug amount and $$ accordingly.
- randomnumber: returns a random number
INPUTS: AL is bottom value, AH is top value
OUTPUT: AL is the random value.
DESCRIPTION: Simply returns a random variable.