ECE 390 Final Project:
Doom 390, Group
TEAM MEMBERS:
- Joshua Ratcliff
- Smit Shah
- Baeksun Oh
- Brian Leising
INTRODUCTION:
Taken from ECE 390 Final Projects Description
The main goal
of this project is to create a game similar to that of the well-known DOOM
first person shooter game. It will have
one map, a reasonable representation of Everitt Lab.
We’ll let the user choose a difficulty level, simple artificial intelligence
for monsters, allow user to change weapons, regain health over time, keyboard use
to move, allow user to pause and escape the game. It will include music, and possibly networking
depending on size of the group.
PROJECT OBSTACLES:
With such a daunting task, there are a number of expected problems:
GRAPHICS: The major problem we are concerned about is attempting to mimic the visual effects of the DOOM engine. DOOM had a semi-3-d environment, with perspective, altitude, and a field of view. Even with simple textures and right-angle corners, this will still be a major difficulty. We probably will supplement our code for graphical rendering with code from other sources. Ideally, we’ll have a visual appearance similar to that of Wolfenstein 3D, the predecessor to DOOM.
MAP REPRESENTATION: Another related issue is how to represent the map in memory. We probably will use a board similar to snake and the maze MPs. However, the anticipated problems are actually constructing it in memory (which will require very meticulous coding to initialize) as well as how fine to define the map (as in, how “large” each memory block allocated would represent). DOOM and other related first-person shooters are very smooth when it comes to movement, which means we’ll need to have each memory cell represent a small area. Likewise, larger objects like the player and monsters may need to take up a square or rectangle of memory cells to compensate. However, hopefully, this will make walking and rotating the main player much smoother and nicer.
SOUND AND MUSIC: It might be possible to get authentic DOOM or Wolfenstein music off the internet. This would require a speaker interface. None of the previous MPs ever manipulated the sound hardware of computers.
MONSTER INTELLIGENCE: This might be a problem, depending on how involved we get. On the surface, it shouldn’t be too hard: monsters that melee attack want to close the distance, monsters that shoot will stay at a distance. Checking for collisions would be the harder part of this, as monsters take up more memory cells in the map.
Of course, the difficulty arises from activating the monsters; when does the monster see the player? Furthermore, would it be possible to hear the player shoot his weapon?
Also of
note is keeping track of all the monsters that are active: will they have their
own separate _monsterStatus variables? Or will the map be engineered such that only
a few monsters can ever be active at one time?
PLAYER STATUS: This shouldn’t be too difficult, though the number of conditions to keep track of would make it lengthy, such as, available weapons, current weapon, current health, keycard, etc.
MOVEMENT: This will certainly require a keyboard interrupt, similar to that used in MP3 for the Snake game, though accommodating more possibilities (for shooting and opening doors, changing weapons, etc.). Depending on whether we decide to use a mouse as well, there will need to be a mouse interrupt as well.
This also ties in with MAP REPRESENTATION, above, as well as timer interrupt, to pace the movement of the player and monsters so that players cannot blow about the map at the (virtual) speed of sound.
DIFFICULTY: This may not be as
difficult as it seems, as we can simply modify the function we use to construct
and populate the map to stop populating it if the difficulty is a certain level.
IMPLEMENTATION:
This project will be implemented in protected mode, mainly because of the memory requirements.
MAP: The map will be implemented in memory as a block of cells, much like MP2 and MP3, though an object will likely take up an area of cells, to make movement smoother.
MAJOR SUBROUTINES and VARIABLES:
[_playerStatus] – keeps track of current direction of the player (one of 8 cardinal directions), which weapon is available, the difficulty level, and whether the player has collected a keycard.
[_DMap] – a large block of memory which will contain the map and all objects within it.
_monsterStatus – right now, this is simply a similar, smaller version of _playerStatus that says which way the monster is moving, and whether it is active (i.e., has it seen the player?)
DTimerISR
--INPUTS: none
--OUTPUTS: none
--READS: [_timerTicks]
--MODIFIES: [_timerTicks]
This will be the timer subroutine, which will be used to regulate and control player and monster movement through the map. Two other related subroutines will also be needed to install and remove this interrupt service routine.
DKeyboardISR
--INPUTS: keyboard scan code
--OUTPUTS: acknowledge signal
--READS: none
--MODIFIES: [_playerStatus]
This interrupt, after installed, will process scan codes from the keyboard (asynchronously). It will check whether the player is holding an arrow key down for movement, or pressing space bar to open a door, pressing control to fire, pressing a number key to switch weapons, or pressing escape to exit/bring up a menu (if a menu is implemented). It will alter the status of the [_playerStatus] variable accordingly.
Two other routines will be needed to install and remove this interrupt service routine.
DConstructMap
--INPUTS: none (possibly an external file containing a hard-code version of the map)
--OUTPUTS: none
--READS: none
--MODIFIES: [_DMap]
--CALLS: _MemAlloc
This will be a hard-coded routine for constructing the map in memory, defining the boundaries, walls, and doors of the map. Because of the size of the map, it will ask to dynamically allocate memory for simplicity (using the memory allocation procedure from the 390 libraries).
NOTE – it may be possible to define the map somewhere as an external file, to prevent tedious coding, and simply load it into a selected portion of memory.
DPopulateMap
--INPUTS: none
--OUTPUTS: none
--READS: [_playerStatus] (for the difficulty level)
--MODIFIES: [_DMap]
This routine populates the newly constructed map with monsters, as well as places items, according to the difficulty level selected by the player. This will directly edit the contents of _DMap.
DUpdateMap
--INPUTS: none
--OUTPUTS: none
--READS: [_DMap], [_playerPosX], [_playerPosY]
--MODIFIES: [_playerStatus], [_monsterStatus], [_DMap]
This subroutine will check to see whether there should be any updates made. It will update the location of the player on the map, as well as check to see if the player should switch weapons, whether a new weapons was collected, whether new monsters should be activated, etc.
DMonsterAIMelee
--INPUTS: none
--OUTPUTS: none
--READS: [_monsterStatus]
--MODIFIES: [_monsterStatus]
This routine will be run if there is a monster designated as a melee (close fighting) monster. The routine will alter the _monsterStatus variable to bring the monster as close to the player as possible and then attack.
DMonsterAIRanged
--INPUTS: none
--OUTPUTS: none
--READS: [_monsterStatus]
--MODIFIES: [_monsterStatus]
This routine will control all monsters that are designated as ranged attackers. This routine will try to keep the player at a distance such that it can still attack the player, but the player is not close by. It will adjust _monsterStatus so that the monster is moving to maintain this equilibrium position.
DrawScreen
--INPUTS: none
--OUTPUTS: to the screen
--READS: [_playerStatus], [_playerPosX], [_playerPosY]
--MODIFIES: none
This routine will update the screen to reflect any changes due to movement, rotation, change in health, or a weapon selection. This routine may be heavily supplemented with borrowed code.
ADDITIONAL CODE:
ECE 390 Library subroutines:
_AllocMem