C++代写：ICS214 Iceman Part5

发表于   |   分类于

从头开始实现一款大型的RPG游戏Iceman，第五部分是游戏的其他部分实现，以及tips.

Don’t know how or where to start? Read this!

When working on your first large object oriented program, you’re likely to feel overwhelmed and have no idea where to start; in fact, it’s likely that many students won’t be able to finish their entire program. Therefore, it’s important to attack your program piece by piece rather than trying to program everything at once.

Students who try to program everything at once rather than program incrementally always fail to solve this project, so don’t do it!

Instead, try to get one thing working at a time. Here are some hints:

  1. When you define a new class, try to figure out what public member functions it should have. Then write dummy “stub” code for each of the functions that you’ll fix later. Try to get your project compiling with these dummy functions first, then you can worry about filling in the real code later.

  2. Once you’ve got your program compiling with dummy functions, then start by replacing one dummy function at a time. Update the function, re-compile your program, test your new function, and once you’ve got it working, proceed to the next function.

  3. Make backups of your working code frequently. Any time you get a new feature working, make a backup of all your .cpp and .h files just in case you screw something up later.

If you use this approach, you’ll always have something working that you can test and improve upon. If you write everything at once, you’ll end up with hundreds or thousands of errors and just get frustrated! So don’t do it.

Building the Game

The game assets (i.e., image and level data files) are in a folder named Assets. The way we’ve written the main routine, your program will look for this folder in a standard place (described below for Windows and Mac OS X). A few students may find that their environment is set up in a way that prevents the program from finding the folder. If that happens to you, change the string literal “Assets” in main.cpp to the full path name of wherever you choose to put the folder (e.g., “Z:/Iceman/Assets” or “/Users/fred/Iceman/Assets”).

To build the game, follow these steps:

For Windows

Unzip the Iceman-skeleton-windows.zip archive into a folder on your hard drive. Double-click on Iceman.sln to start Visual Studio.

If you build and run your program from within Visual Studio, the Assets folder should be in the same folder as your .cpp and .h files. On the other hand, if you launch the program by double-clicking on the executable file, the Assets folder should be in the same folder as the executable.

For Mac OS X

Unzip the Iceman-skeleton-mac.zip archive into a folder on your hard drive. Double-click on our provided Iceman.xcodeproj to start Xcode. If you build and run your program from within Xcode, the Assets directory should be in the directory yourProjectDir/DerivedData/yourProjectName/BuildProducts/Debug (e.g., /Users/fred/Iceman/DerivedData/Iceman/Build/Products/Debug). On the other hand, if you launch the program by double-clicking on the executable file, the Assets directory should be in your home directory (e.g., /Users/fred).

What to Turn In

Part #1

Ok, so we know you’re scared to death about this project and don’t know where to start. So, we’re going to incentivize you to work incrementally rather than try to do everything all at once. For the first part of Project 2, your job is to build a really simple version of the Iceman game that implements maybe 15% of the overall project. You must program:

  1. A class that can serve as the base class for all of your game’s objects (e.g., the Iceman, Regular Protesters, Hardcore Protesters, Barrels of oil, Nuggets, Ice, etc.):
    • i. It must have a simple constructor and destructor.
    • ii. It must be derived from our GraphObject class.
    • iii. It (or its base class) must make itself visible via a call to setVisible(true);
    • iv. It must have a virtual method called doSomething() that can be called by the World to get one of the game’s actors to do something.
    • v. You may add other public/private methods and private member variables to this base class, as you see fit.
  2. A Ice class, derived in some way from the base class described in 1 above:
    • i. It must have a simple constructor and destructor that initialize a new Ice object.
    • ii. It must have an Image ID of IMID_ICE.
    • iii. You may add any set of public/private methods and private member variables to your Ice class as you see fit, so long as you use good object oriented programming style (e.g., you must not duplicate functionality across classes).
  3. A limited version of your Iceman class, derived in some way from the base class described in 1 just above (either directly derived from the base class, or derived from some other class that is somehow derived from the base class):
    • i. It must have a simple constructor and destructor that initializes/deinitializes the Iceman - see the Iceman section for more details on where to initially place the Iceman on the screen.
    • ii. It must have an Image ID of IMID_PLAYER.
    • iii. It (or its base class) must make itself visible via a call to setVisible(true);
    • iv. It must have a limited version of a doSomething() method that lets the user pick a direction by hitting a directional key. If the player hits a directional key during the current tick, it updates the Iceman’s location to the target square, removing any Ice objects that overlap with the Iceman’s 4x4 graphic image. To move the Iceman, all this doSomething() method has to do is properly adjust the player’s X,Y coordinates using GraphObject’s moveTo() method and our graphics system will automatically animate its movement it around the oil field!
    • v. You may add any public/private methods and private member variables to your player class as you see fit, so long as you use good object oriented programming style (e.g., you must not duplicate functionality across classes).
  4. Create a limited version of the StudentWorld class.
    • i. Add any private member variables to this class required to keep track of all Ice in the oil field as well as the Iceman object. You may ignore all other items in the oil field such as Boulders, Barrels of oil, Protesters, Nuggets, etc. for part #1.
    • ii. Implement a constructor for this class that initializes all member variables required for proper gameplay.
    • iii. Implement a destructor for this class that frees any remaining dynamically allocated data that has not yet been freed at the time the class is destroyed (e.g., the Iceman and all remaining Ice).
    • iv. Implement the init() method in this class. It must:
      • Create the Iceman object and insert it into the oil field at the right starting location (see the StudentWorld init() section of this document for details on the starting location).
      • Creates all of the oil field’s Ice objects and inserts them into a data structure that tracks active Ice (see the StudentWorld init() section for details on where to place Ice, and what data structure to use track all of the remaining Ice in the game).
    • v. Implement the move() method in your StudentWorld class. During each tick, it must ask your Iceman object to do something. Your move() method need not check to see if the Iceman has died or not; you may assume at this point that the Iceman cannot die. Nor need your move() method deal with any Protesters or other actors (e.g., Nuggets or Boulders) at this point - just the Iceman.
    • vi. Implement a cleanup() method that frees any dynamically allocated data that was allocated during calls to the init() method or the move() method (e.g., it should delete all your allocated Ice and the Iceman). Note: Your StudentWorld class must have both a destructor and the cleanUp() method even though they likely do the same thing.

As you implement these classes, repeatedly build your program - you’ll probably start out with lots of errors Relax and try to remove them and get your program to run.

You’ll know you’re done with part 1 when your program builds and does the following: When it runs and the user hits Enter to begin playing, it displays a oil field filled with Ice (except for a single open vertical shaft dug down the middle of the oil field) with the Iceman in its proper starting position in the top-middle of the screen. If your base class(es) and Iceman class work properly, you should be able to move the Iceman around the oil field and dig through the Ice using the directional keys.

Note, the Part #1 specification above doesn’t require you to implement any Regular Protesters, Hardcore Protesters, Boulders, Barrels, etc. (unless you want to). You may do these unmentioned items if you like but they’re not required for Part 1. However, if you add additonal functionality, make sure that your Iceman, Ice, and StudentWorld classes still work properly and that your program still builds and runs, and meets the requirements stated above for Part #1!

If you can get this simple version working, you’ll have done a bunch of the hard design work. You’ll probably still have to change your classes a lot to implement the full project, but you’ll have done most of the hard thinking.

What to Turn In For Part #1

You must turn in your source code for the simple version of your game, which builds without errors under either Visual Studio or Xcode. You do not have to get it to run under more than one compiler. You will turn in a zip file containing nothing more than these four files:

Actor.h           // contains base, Ice, and Iceman class declarations
                  // as well as constants required by these classes
Actor.cpp         // contains the implementations of these classes
StudentWorld.h    // contains your StudentWorld class declaration
StudentWorld.cpp  // contains your StudentWorld class implementation

You will not be turning in any other files - we’ll test your code with our versions of the the other .cpp and .h files. Therefore, your solution must NOT modify any of our files or you will receive zero credit!

Part #2

After you have turned in your work for Part #1 of Project 2, we will discuss one possible design for this assignment. For the rest of this project, you are welcome to continue to improve the design that you came up with for Part #1, or you can use the design we provide.

In Part #2, your goal is to implement a fully working version of the Iceman game, which adheres exactly to the functional specification provided in this document.

What to Turn In For Part #2

You must turn in the following files, and ONLY the following files. If you name your source files with other names, you will be docked points, so be careful!

Actor.h             // contains declarations of your actor classes
                    // as well as constants required by these classes
Actor.cpp           // contains the implementation of these classes
StudentWorld.h      // contains your StudentWorld class declaration
StudentWorld.cpp    // contains your StudentWorld class implementation

You must turn in a report that contains the following:

  1. A high-level description of each of your public member functions in each of your classes, and why you chose to define each member function in its host class; also explain why (or why not) you decided to make each function virtual or pure virtual. For example, “I chose to define a pure virtual version of the blah() function in my base class because all Actors in Iceman must have a blah function, and each type of actor defines their own special version of it.”

  2. A list of all functionality that you failed to finish as well as known bugs in your classes, e.g. “I wasn’t able to implement the Squirt class.” or “My Hardcore Protester doesn’t work correctly yet so I just treat it like a Regular Protester right now.”

  3. A list of other design decisions and assumptions you made, e.g.: i. It was ambiguous what to do in situation X, and this is what I decided to do.

  4. A description of how you tested each of your classes (1-2 paragraphs per class)

FAQ

Q: The specification is ambiguous. What should I do?
A: Play with our sample program and do what it does. Use our program as a reference. If the specification is ambiguous and our program is ambiguous, do whatever seems reasonable and document it in your report. If the specification is ambiguous, but your program behaves like our demonstration program, YOU WILL NOT LOSE POINTS!

Q: What should I do if I can’t finish the project?!
A: Do as much as you can, and whatever you do, make sure your code builds! If we can sort of play your game, but it’s not perfect, that’s better than it not even building!

Q: Can I work with my classmates on this?
A: You can discuss general ideas about the project, but don’t share source code with anyone.

GOOD LUCK!