CSE 142 Homework 5

Due Tuesday, August 15th, 10:00 PM
Paper turn in Wednesday, August 16th, 5:00 PM
Turn in Report is due the same time as the Paper turn in (Wednesday)

Homework Requirements:

Program -- U Dub Dug
A Turn In Description -- details here

Overview

U Dub Dug is a one-player game in which you try to shoot monsters and avoid falling rocks, while digging around the screen. You will be given quite a bit of freedom in this assignment, and are encouraged to extend the requirements in creative ways. In this assignment you will be using GP142 again, as well as multidimensional arrays and structs. You will also be allowed to work with a partner from your quiz section.

Read this entire assignment carefully, there are important bits throughout.

Quick Overview

• Read the Specifications
• Read about GP142
• Download the Sample Executable
• Download the starter code:
  • Those using MSVC 6 (in MGH, OUGL, or at home) should get the MSVC 6 self-extracting archive
  • Those using MSVC 5 need the MSVC 5 self-extracting archive
  • All other users need the plain source file hw5.c.
• Write the program
• turn in the assignment
• Write the turn in report

Specifications

You may work with a partner on this assignment, but you are not required to. You and your partner must be in the same quiz section. Read the Submission Details below if you work with a partner.

To play U Dub Dug you use the i,j,k,l keys like the arrow keys. You use the space bar to shoot your beam. The moving green rectangles are monsters, and the brown rectangles are rocks.

The current game is rather simple. However, since we aren't providing you with any starting code, it will take a large effort to get it to this simple state. Start Now. You are encouraged to extend the basic assignment in interesting and creative ways, and some small amount of Extra Credit will be awarded.

Making The Game

You are required to make your game have the following features. It does not have to look identical to our solution, but must be functionally the same.

• Grid of Multicolor Squares (Dirt)
• Must be a 2-dimensional array of structs
• All objects should stay within the bounds of the grid.
• Grid squares should disappear when dug by the player.
• Player character which moves using the keys
• Moving should make the dirt (squares on the grid) disappear.
• Player should be able to shoot a beam which kills monsters
• Player should not be able to walk over rocks.
• Player should die if it touches a monster or is squished by a rock.
• Player should not be able to walk outside of the grid.
• Rocks which will drop if the grid is empty beneath them
  • A rock should kill a monster or the player if it lands on them.
  • A rock should break (i.e. disappear) if it falls and hits something. This means it should disappear if it hits dirt, the edge of the grid, a monster, or the player.
  • The player and monsters should not be able to walk over a rock.
• Monsters which move around
  • These monsters are not very clever. They simply move left and right, or up and down.
  • Monsters should switch direction if their path is blocked (by a rock, or dirt, or the edge of the grid, or another monster).
  • Monsters should die if shot with the beam.
  • Monsters should die if they run into the beam.
  • Monsters should die if squished by a rock.
  • Player should tie if touched by a monster.
• The player shoots a beam
  • The beam should only extend a little ways (it should not go clear across the screen).
  • The beam should be stopped by dirt, the edge of the grid, rocks, or if it reaches its maximum length.
  • It should kill monsters that touch it.
• If all the monsters are killed it should restart, or move to the next level, or do something such that more monsters are created and the game continues.
• If the player is killed the game ends.

Suggestions and Hints

This assignment uses GP142 like the last assignment.

Details:

Grid:

You should probably start by building the grid (the dirt). This is should be represented with a multi-dimensional array of structs. Each square of the grid should keep track of certain information. Perhaps the color it should be displayed as, and the type of thing currently in the square. For example, a red dirt square, or a yellow player square, or a black empty square. Remember that you will have to translate a grid location to a region on the screen. Your colors don't have to match ours, either.

Player:

The second step is to create a player character which moves around the screen. First, you will need a way to indicate that the player is occupying a grid location (perhaps the row and column of the grid where the player is). You might create a struct to store information about the player. After you can draw the player, you need to be able to move the player. This means that you will have to use the GP142 event loop. You might consider copying-and-pasting some of the code from HW4. You will need to handle key presses in order to move the character in the right directions. This is very similar to what was done on the last assignment. Except that each key press moves the position of the player, rather than changing it's speed. You will need to refresh the screen, preferably after each PERIODIC event. Remember, when the player moves, the grid square that he was just in should become empty (the dirt was dug, and disappears). You will also need to check to make sure that the player does not walk off the edge of the screen. This means that you will have to make sure the row and column the player wants to move to are within the bounds of the grid. Perhaps you can store the direction the player is moving along with other player information. You should make sure that if the player is at the edge of the grid, that he can't move towards the edge (only away). There are 4 directions (UP,DOWN,LEFT,RIGHT) that you will need to check. And of course, when in a corner, you have to make sure the player can only move in the two directions away from it.

Rocks:

Once you've got the player moving about, you should add some rocks to the grid. Again, these should be a different type of grid square than empty, dirt, or player, and should look different. To start with, just make stationary rocks. You might make a rock struct to store information about the rock, and have an array of these structs to keep track of all the rocks. Of course, the grid has to know where these rocks are as well. Now comes the first tricky step. The player should not be able to walk over a rock. This means that if the player tries to move in some direction, and there is a rock there, he should not move. You will need to be able to check for rocks in all 4 directions. Once you have the player moving around, digging dirt, and being stopped by rocks, you're ready to move on. Now for some a little harder. If the dirt is removed from below a rock (and the player moves out from directly under it), the rock should fall until it hits something. This means that you will have to scan the column below the rock, checking to see if it is empty. If so, the rock should drop down. You will need to add a little bit of a delay so that the action is visible (e.g. it should only move down after every 3rd PERIODIC event). The rock should stop falling if it encounters an occupied grid square, or the edge of the grid. The rock should disappear when it stops falling. Now that you have falling rocks, consider making the rocks dangerous. This means that if a rock falls on the player, the player should die and the game should end. The only way this is likely to happen is if the player is under a rock and moves down too slowly, being crushed from above.

Monsters:

Once you've got a fair bit of complexity, it is time to get the game rolling. You need to add monsters. Monsters will probably be a struct of their own, again, stored in an array, like Rocks. First, consider modifying the grid such that it has a few empty channels where Monsters can roam. Now modify the grid such that it displays monsters. You'll need to store their row and column positions again. It gets tricky again when you want to make them move. First, you should decide whether the monster moves left-right or up-down. Let's assume left-right for now. The monster should check whether the grid to the right of it is empty. If it is, it should move into it. It should keep moving right until the square is not empty, or the monster reaches the edge of the grid. At this point it should change directions, and start moving in the opposite direction. The monster should move back and forth. Remember that the grid should be updated with the monster's position. Also, rocks are not empty grid squares, so a monster should turn around if it runs into a grid. Once you have monsters moving back and forth, up and down, (make sure that if you dig to the side of the monster, it moves into the newly opened spaces), you can add the next bit of complexity. As your rock should squish the player if it falls on it, it should squish a monster if it falls on one. Thus you need to go back and modify the Rocks further, such that if they fall onto a monster, the monster dies (i.e. disappears). Once you can squish monsters with rocks, the rocks are complete. Now you should make the monsters kill the player. If I monster tries to move into a square which is filled with the player, the player should die. As you've already written code to handle the player's death, you should only need to modify the monster code such that if an occupied square is a player, the player dies and the game ends.

Beam:

The only thing left is to make the beam that the player shoots. This is fairly complex as it requires checking for a number of conditions. To start with, you will need to make the space bar do something. If the next square over in the direction the player is moving is empty, then when the space bar is pressed, the beam should appear there. This will require updating the grid, and will probably require you storing separate information about where the beam is. The beam should be drawn in the direction the player is facing up to some maxiumum length, say 4 squares. You may want to ignore other keys presses while the beam is being fired (use a true/false variable). Now, when the beam is fired, you should keep extending it one square at a time. You should wait a few periodic events before extending it to the next square. Now, you should have the beam extend until it either reaches its maximum length, or it encounters a non-empty grid square, or the edge of the board. You might keep track of the row, col location of the end of the beam, so that you can keep track of whether or not you're near the edge of the board. The beam should disappear after it is fired. Once you can fire the beam, you got only got one last major step to finish. You've got to make the beam kill the monsters. To do this, you should check to see whether the square that the beam stopped at was occupied by a monster. If so the monster should die, just as if it were squished by a rock. Remember that the beam is fired in all 4 directions, which means you will have to be able to draw it and check for monsters in all directions. Lastly, you need to modify the monsters again. If a monster is walking, and it encounters a grid square which is occupied by the beam, the monster should die. Thus, when you check for empty squares for monsters to move into, you should check for beam squares that kill monsters.

You've now basically finished the game. The last step is to make it so that if all the monsters are killed, then you create new monsters. Consider just initializing the game back to how it was at the start.

There is lots of room for extensions, but getting here will be challenging. Consider making the monsters more intelligent, so that they follow you. Consider adding a score to the game, or multiple lives to the player. Make different difficulty levels. And on...

Get Started Now! Really. We mean it.

Sample Solution

Download and run the sample PC solution hw5.exe.

To play U Dub Dug you use the i,j,k,l keys like the arrow keys. Use the space bar fire the beam.

Getting Started

• self-extracting archive, including starter C file

  • hw5_vc6.exe - for use with MSVC 6.0
  • hw5_vc5.exe - for use with MSVC 5.0
• hw5.c - starter C file as included in above archives
• information about getting the GP142 files for students not using the above archives
• hw5.exe - sample solution

Submitting Your Work

You may work with a partner on this assignment. If you do so, you should try to divide up the work evenly. You do not have to work with a partner but it is recommended.

You only need to sumbit hw5.c electronically, you don't need to submit the gp142 code. You must still hand in a turnin receipt and the turn in report.

Each pair of partners needs only sumbit the code once electronically and turn in one receipt. However, you both need to submit a turn in report (you may discuss what you'll write in it, but you should write it each yourself).

Turn in the assignment Don't forget the the turnin description

You may turn in the program as many times as you wish. Only the last version is graded, and only the receipt from this last version should be handed in.