Duck Hunt

You know you love this game. Now it’s time to bring it to a 586 near you. The goal of this project is to mimic the game play of Duck Hunt while allowing room for creativity. The original game had either one or two ducks flying at one time. For each level the player has a chance to hit 10 ducks with only 3 shots per duck. To progress to the next level the player must hit X out of 10 ducks. With each new level the speed of the ducks increase as well as how many out of the 10 ducks must be shot.

The game will feature rich graphics in 800x600 mode, both mouse and joystick control and if possible a light gun, if we can find one. On the game screen the landscape fills the entire screen. The number of bullets remain, total hit count out of 10 and the total score located at the bottom of the screen.

This project will need a 3 person team. The areas of expertise are: graphics, joystick/mouse control, and main program operation.

Tank Warz

The point of the game will be to hit the opposing tank with enough damage to take all of its health away. Once a tank’s health is exhausted then the game is over and like tennis, there will be multiple games to a match. However, a game can also be decided by a draw, in which if all weapons are exhausted (there will be a set limit), then the person with the most health wins.

Our version of the game will most likely be in mode 13 graphics (unless we have the time to up it to SVGA). It will incorporate mouse control, a GUI, a physics engine, and a terrain engine. The terrain engine will control the creation of the landscape and the upkeep of it once a fire command is called. Physics will take care of the flight of the weapon and the falling of the tank into a newly created pit/crater. The GUI will do all of the work with the user having command of weapon selection, angle of the turret, and power of the weapon. The game has a simple concept but the concept has infinite extension possibilities. The various weapons that can be added can be as complicated as we want. Besides the standard cannon ball (with large and small variations) there are concussion bombs that once they impact spray shrapnel in random directions among others. In the other versions of the game there has even been animation for falling ground that has had its support knocked from under it.

As for the running of the program, the GUI will first take in a username and color for the player(s) which will then appear on the top of the screen in order to identify the tanks. Once the game starts then the bottom half of the screen becomes the Graphical User Interface. The GUI will have the weapon options, an angle and power indicator and buttons in order to adjust them, which in the case of the power has a slider of sorts and of course the fire button is in the middle.

Once the tank fires then the physics engine takes over and calculates velocity and trajectory in order to create the nice smooth arc that we need. The physics engine will also calculate the impact size and damage and if a tank needs to fall down.

Assembly Paint

Using the framework provided by Jim for mp4 and mp5, our group would create an interface that would allow users to paint various objects, shapes, and lines on the canvas much like Paint for Microsoft Windows.

Different menus would be created depending on what types of things users would want to do. For example, one menu could contain lines of various sizes that the users can draw with. Another menu would be used so the user could choose the certain colors or generic wallpapers they would want to use. A final menu would show various shapes to be inserted into the canvas like squares or circles. In addition there will be a paint bucket option that will allow the user to fill in different shapes on their canvas. Hopefully a color picker option will be implemented allowing the user to pick any color they desire. (Any ideas or suggestions for this part would be helpful)

Most of the program will be driven by the user input from the mouse, all menus and drawing will be driven by the mouse. The user has total control in drawing on the canvas and the menus are provided to enhance the picture creating ability of the user. The main data structures will devised off of the mouse up, mouse down,and mouse drag procedures that were built in the CS306 shell. More information on the inputs and outputs of the methods are available online at our website.

The main focus of this project will be with graphics. Tasks will include breaking up the screen into different areas (paint area vs. menu area) (Graphics), interfacing assembler and the mouse (Mouse Control), providing the connectivity for the menus to the drawing area (Connectivity).

Jackie Chan in ... Rumble in the Jungle

The game will be a tile-based "room-at-a-time" action game, with a 2-d side view in the style of Lode Runner. There will be enemies attacking with hooks and "puzzles" (e.g.: find the key,unlock door). You must battle your way through several "rooms" using your throwing star attack and deadly triple-arm Rhino punch. At the end of the game, you will fight the mysterious leader of the ROBO-pirate army.

This will feature 800x600 graphics, with mainly keyboard control, and some mouse control for the menus. The work can be broken down into game engine, graphics, and input control. Target team size is 3 members.

Piano Music Composer

This music composer can take in a series of notes either keyboard or mouse, then
1) display as a score on the screen
2) save it in the memory
3) play the music
The length of the note depends on the time the key or the mouse is held.
Eg. If the music is set to a beat of 60/min,
1 sec would be 1 beat.

Once it began recording, time which mouse/ keyboard is not held down will represent rests notes.

Music guidence mode: Allows user to set the piece to a particular major/ minor and will ignore notes out of it if guidence is set. Eg. If it is set to C major, it will ignore all the inputs with sharps and flats.

Note range: 2-3 octaves begining from the A below middle C.

Work can be divided into input, output, storage and structure

Input: Responsible for mouse control/ & keyboard control to read in notes (including procedures to ignore input when they do not satisfy that set major/minor if music guidence mode is set)
Output: Responsible for displaying the melodies and outputing them into speaker.
Storage: Responsible for creating methods to store the melody input and creating the liburary of major and minors for music guidence mode.
Structure: Responsible for creating main structure of program

This program can be operated in text-mode video or video graphics, depending on the Output person`s preference. If operated in text-mode the score can be displayed in simplified score which consists of numbers, dots and lines.

Robo-Retriever

This project will be concerned with the design and implementation of a puzzle game similar to the robot challenge in the old Castle of Dr. Brain PC game. The game will take place in a top-down, tile-based, 320X200 pixel game field filled with obstacles, hazards, and precious Energist Spheres. The object of the game is to program the robot miner so that it avoids any hazards and successfully collects all of the Energist spheres on the stage. However, the robot has limited memory and only a relativly simple range of commands at its disposal.

The control of the robot will be divided into three "methods", Main, Sub-Routine1, Sub-Routine2. Each method will have space for 8-10 directions followed by a return statment. The Main method can call Sub1 or Sub2, and Sub1 may call Sub2. Other commands include: Move, Turn Right, Turn Left, Pick Up, Drop Off, with the potential for more to be added depending on how adventurous the group members feel. All actions most be programmed in before the robot may run (No moving, turning, and then re-writing the program). Levels will increase in difficulty and require more and more extensive programs to complete.

This game will heavily utilize array structures in its processing. The main portions I forsee in this project are: Mouse Interface, Graphics, Level Design, Animation, Programming Engine design. Ideally we would add in sound and background music as well, and multiple levels would be constructed with a moderate skill ramp. Possible additions that we might wish to include might be moveable hazards (patroling robots), timed hazards (Lazer barrier that switches on and off periodically), and level altering capabilities (Building brides, blowing up walls, etc.). A team of three members should be sufficient for this project.

Swashbucklin` Sampson

Introduction

Implementation

When the player selects to start a new game, he will be taken to the overhead view that shows a picture of the island, with his crashed boat as well as the 2 game levels. The player will be able to walk Sampson around and either enter his ship to see if he has retrieved the sail and the tar, or enter one of the two levels.

When the player enters one of the levels, by pressing enter, the game will switch to a side view. In the side view, the player will be able to walk left and right, up and down in the level, attempting to get to the end without getting killed by an enemy, or falling into a pit or onto spikes, or other deadly shenanigans. Sampson will have a sword that he can use to kill the enemies, and also have the ability to jump. The two levels will be larger than the screen is able to show at any given time, so when Sampson moves across the screen, the screen will scroll.

Various items will be scattered across the levels, and by getting these, Sampson will get points. If he gets enough points, he will gain a new life. Sampson starts out the game with 2 lives. If he loses both of these lives, then the game is over.

The graphics will be done using Jim`s Wicked Graphics Toolkit, referred to from here on as JWGT. All of the images will be done in Photoshop or something, or hopefully stolen, I mean liberated, from the Internet, and maybe, if I`m really lucky, done with some help from my artist girlfriend.

All movement in this game will be done with the keyboard. In fact, you might as well throw your mouse away. This is 1980`s vintage gaming. We don`t need a damn mouse!

Variable and Data Structures

The levels will be represented as arrays. Each byte in the array will represent a half-Sampson sized chunk of the screen. The byte will contain information about that part of the game board, such as if Sampson is there, if there is an item there, an enemy there, if you can walk there, or if you fall through there, and if you die by being there. Each of the levels will have its own array. Some of the array will be static, such as whether you can walk there, or if you die by being there. Other things such as whether Sampson or an enemy is there will change based on the movement of the various things.

The outer world will be represented by a much simpler array. Each byte will simply tell whether there is a level there, whether the ship is there, or whether Sampson is there. Hell, maybe we can use nibbles.

Sampson will be represented by a structure that contains the number of points he has, how many lives he has, and what parts of his boat he has retrieved. That Sampson! What a guy!

Virtual Light Lab