从头开始实现一款大型的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:
- 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.
- 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.
- 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:
- 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. - 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). - 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). - 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:
- 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.”
- 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.”
- 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.
- 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!
