6.111 Final Project Proposal.pdf6.111 Final Project Draft Block Diagram.pdfInteractive Adventure Game Greg Luthman Akash Shah Description Our generation was the first to grow up with video games as a large part of our entertainment. Perhaps the most popular of these games was Super Mario Brothers, a side scroll adventure game for the Nintendo Entertainment System. (NES) As children we could become enveloped in the game world and imagine that we were the main character on screen fighting to save the princess from terrible monsters. With our 6.111 final project, we hope to do just that, put the player into the game world. We will create a live action, side scroll adventure game that is similar in concept to Super Mario Brothers, except that instead of playing with a controller and seeing a character move on screen, everything is controlled by the player's actions in front of a camera. We will not only use the video of the player to determine the proper commands to send to the game, but also place that video of the player into the game world. The player will be able to duck objects, jump over objects, move forward or backward in the game world. Other commands are a possibility as we continue designing this project. Akash Shah will develop the input and output modules dealing with video and Greg Luthman will develop the game logic. If there is enough time, we will try to implement sound in the game. Module Breakdown Game Module The game module takes the various control signals from the video portion of the project and uses them to figure out how the player is interacting with the game world. The game module also takes a single bit signal from the video modules that is high if the player occupies the pixel indicated by the current vcount and hcount. Using this, the game module can tell if the player has contacted any of the other elements in the game, and can respond accordingly. There are several submodules that are used to support a main game finite state machine (FSM). These smaller modules includes character sprites, physics engines, timers, and level memories. The game module outputs several signals back to the video modules. It outputs a data bus corresponding to what the game world is to look like without the player video. This is accomplished by changing the color of the pixel to be displayed as the hcount and vcount signals cycle through the entire screen. The game module outputs two scale factor signals, one for the x direction and one for the y direction. This is to tell the video modules how to scale the video of the player to fit appropriately in the game world. The last signals that the game module outputs to the video modules are two signals telling the video modules where to place the video of the player within the game world. This is done by outputting the desired x and y coordinates of the top left corner of the video. These last signals w ill enable the player to see “him self” jum p through the air, or do other specialthings based on the game world. The game world will probably be implemented as a one-way world. This means that once an object is off the left side of the screen, the player cannot go back to that part of the level again, but only up to the edge of the screen. This should make the implementation of the game world less memory intensive, because the module doesn't have to store the state of all objects that have already been interacted with. Game FSM The game FSM will be the brains of the game module. It's main inputs are the commands from the video modules and the player_pixel_on input, also from the video modules. Other inputs will be the character generation pixels from the character sprite modules, timers to keep track of in game events, and an interface with a memory that contains the layout of the level. The levels will probably be created by storing only the coordinates of the desired characters, and then generating those characters on demand. Registers are used to keep track of the position of the player within the game world, as well as the position of other objects in the game world. Each object will be assigned an object number, so storing and detecting collisions and determining whether or not special actions can happen, should be much easier. Game World The game world should be familiar to anybody that has played a side scroll adventure game similar to Super Mario Brothers. There will be enemies that walk slowly across the screen, and to defeat these enemies the player must jump on them. There will also be inanimate objects, both in the background that cannot be interacted with, as well as objects in the foreground that the player must jump on top of and over. When the player jumps, the video representation of the player will move through the “air” in a path determ ined by som e sim ple physics engine. There w ill be objects that w ill affect the player's state, such as coins that can be collected for an extra life, mushrooms (or another object) that will cause the player to “grow ” bigger, and possibly objects such stars or capes that give the player temporary abilities such as invincibility and flight. A player defeats the level by making it to the end of the level's map within a certain amount of time. A player loses if he/she loses all of his/her lives. W hen a player contacts an enem y w ithout jum ping on it, one of tw o things happens. If the player is “big” then the player reverts to a “sm all” state. If the player is “sm all” then the player loses a life and the level restarts. If there is enough time, sound and multiple levels will be implemented, possibly levels with different themes and different physics. (ie. A dungeon level, or an underwater level.) There will be two types of sounds, sound effects and a sound track. The track will be playing in the background and will correspond to the mood of the current level. The sound effects will play at the appropriate actions of the player, such as jumping, squashing an enemy, or busting a block.Video in The video input from the camera will be mostly handled by the hardware that comes bundled with the labkit. The labkit’s ADV7185 should be able to handle the video input that w ould be necessary for this project. Furthermore, the sample code from the website should help in this task as well. Green Screen Detector This module is primarily responsible for handling detection of the green screen background that will be used in this project. This
View Full Document
Unlocking...