High Level Design:

Rationale and sources of project idea:

Our initial brain-stormed idea was simply a whack-the-mole game with varying characters. But as we started on the project, and along with some constraints in cost, our creativity was further stimulated, and our original one player game slowly transformed into an exciting two player game.

 

 

Logical Structure:

The following is a high level diagram showing how our hardware was connected:

 

Our project was written in C, and the code generates everything that is seen on the TV, processes inputs from the hardware (the gun, 9 button placer, 4 button selector, and foot pedal), and controls the progress of the game. More detail can be found in the Program Design and Hardware Design pages.

The following is a high level state diagram which shows the basic logic of how the software works:

 

 

Background Math:

The background math in our project involved conversion between binary, decimal, and hexadecimal numbers. These conversions were used in determining the location and boundaries of the images placed on the video screen. Floating point was also used.

To simplify calculations, acceleration was kept constant, and velocity was scaled so that dt = 1, and the multiply could be avoided. Now with dt=1, the new position (at t+1) would simply be equal to the position at t=0 + the velocity. For example, x(at t+1)= x (at t=0) + v x *dt, but with dt=1, x=x + v x . These equations provide us with the velocity and position of the figure at different points in time, and would provide us with current information as well as information to calculate the next set of values in time.

After implementing the integration algorithm (previous paragraph) and solving for the x and y coordinates for a particular frame, the code will output the figure shape onto the video screen by calling a function video_putMan, or other video_put commands which created figures on our screen. (video_putMan((char)(x>>8), (char)(y>>8))) The x and y coordinates are shifted right 8 to change the fixed point number back to a regular integer. The video_putMan, and the other similar command functions simply creates pixels at specific points onto the video screen until the desired figure is created.

 

 

Hardware/Software tradeoffs:

Originally we wanted to make an amusement park version of whack the mole, where moles would pop out by using motors or some other method, but with the limited budget, doing this task was quite tough. However, this led to our more original project idea, so we can't complain. Another tradeoff that we had was that our microcontroller limited the size of the guy that we could place on the screen, because if we tried to create/erase too many pixels at once, jittering/distortion would occur. We did not have too many tradeoffs for hardware as a lot of the hardware was built my ourselves, and for missing parts, we simply found alternatives to achieve the same purpose. (e.g. there were no more reset buttons to solder onto our custom pc board, so we just soldered a wire and used it as a short to reset)

 

 

Relationship of design available to IEEE, ISO, ANSI, and other standards:

We implemented an NTSC-rate, non-interlaced video signal, and our game can be played on any standard NTSC television.

 

 

Discuss patents, copyrights:

We'd have to say our game is quite original. The Duck Hunt gun was just used as a piece of hardware, and our game did not include anything that was related to the game Duck Hunt. The pedal was also an original idea, where the gun would reload when the pedal was stepped on, and no arcade games use this concept. Our game may appear similar to the classic game Whack the Mole, but the classic Whack the Mole game is a one player game, and buttons are pressed to actually ‘hit' the mole. But our game is a two player game, and the buttons are used to place a variety of characters onto the screen. To the best of our knowledge, we have not seen a similar game in the arcade, or on any of the gaming consoles.