Doom II - Frame Analysis

Create a simple Design Document for an existing game. I suggest choosing a simple game to keep things easy. Break down a game as I went over in class:

I chose to make this frame breakdown document for Doom II because I felt it would be interesting to try to do this exercise then test my understanding by looking at the game's source code (because it is open source.) https://github.com/id-Software/DOOM/tree/master/linuxdoom-1.10

Sprites are marked by the white boxes, backgrounds by the blue boxes. Sprites were chosen as elements that could move in most cases, this included: The player's gun The Hud Elements, such as doomguy's face, health (individual sprites), armor, keys, weapons, etc. Enemies Doom doors are walls that move, and as such are definitely sprites. Backgrounds were static textures in the environment such as doom walls.

Its worth noting that Doom actually had an SNES release, it would be very interesting to decompile and see how they worked the sprite vs background system on this port to a console that utilized that kind of fixed paradigm.

State, Event and Logic Breakdown for our frame:

States for Doomguy:
  Weapon slot filled type int
     0 true
     1 true
     2 false
     3 false
     4 false
     5 false
     6 false
     7 false
     Chainsaw false
     SSG false
  Health type integer
     100
  Armor type integer
     0
  Weapon Ammunition type integer
     Bull 50
     Shell 0
     Rock 0
     Cell 0
  Position type float  
Position X
     Position Y
     Position Z
  Velocity type float
     Velocity X
     Velocity Y
  Orientation type Unsigned Int
     Orientation x
     Orientation y
  Keys type int
     Red 0
     Blue 0
     Yellow 0
  Level
     int levelState (in source this is broken into next and prev)
  Sprite animation state
     Headbob
     Enemy standing cycle


Events:
     Wake up enemy by sound (gunshot)
     Wake up enemy by line of sight
     Enemy infighting by enemy shooting enemy before you shoot enemy

Update Logic:
  Check position xyz of character, angle, Binary space partition to see what to draw
  Draw enemies, check for enemy line of sight, check for enemy hearing, check for keypresses for gunshot, weapon switch, movement, weapon switch, cheat input.

AI Character Behavior Tree - Zombieman

This state machine lacks one state that should exist which would be for an immediate check for LOS to cause a zombieman to open the door then CHASE or ATTACK rather than simply wander.

Additional reading: http://fabiensanglard.net/doomIphone/doomClassicRenderer.php