：
． ，：
． ，（）：
．“”“”：
．，、，（
）：
．“”“”，
The implementation we provided picks a piece type at random. For some of our
tests of your program, we will build your program with a different
implementation of chooseRandomPieceType, one that supplies a predetermined
sequence of pieces with each successive call. We put the implementation of
chooseRandomPieceType in chetyris.cpp so that we can easily substitute a
different one when we run those tests.
UserInterface.h
This file provides an interface for writing to the screen, reading from the
keyboard, and measuring time. Use these functions for all of your input and
output; don't write to cout or read from cin. We describe these functions below.
UserInterfaceWindows.cpp and UserInterfaceUnix.cpp
These are two implementations of the interface in UserInterface.h. You will use
exactly one of these files on a given platform. Use UserInterfaceWindows.cpp
on a Windows system, and UserInterfaceUnix.cpp on a macOS or Linux
system.
User Interface Routines
Here is the functionality provided by the user interface library we supply.
The Screen class has member functions for writing to the screen. The gotoXY
member function positions the cursor at the x and y coordinates supplied as
parameters; text subsequently written appears starting at that point. The upper left
corner of the screen is (0,0); x increases as you move rightward, and y increases as
you move downward.
The printChar and printString member functions write a single character and a string,
respectively. printStringClearLine writes a string, but also clears the rest of the
characters on the current line after the string (in case any non-blanks were left over
from a previously written longer string). The clear member function clears the screen.
In what was just described, for the Windows implementation, changes to the screen
appear immediately. For the Unix implementation, no changes actually appear on the
screen until you call the refresh member function. (By not refreshing after every
single character change, there's less of a flicker as the cursor moves around.)
When it comes to keyboard input, there are three functions. waitForEnter pauses until
the user presses the Enter key. discardPendingKeys throws away any keypresses that
have not yet been processed by the program. The most important function is
getCharIfAny. This function checks to see if the user has hit a key, and reports
whether or not a key has been pressed; if one has, it also returns the character.
As for timing, the Timer class has a member function that returns the number of
milliseconds that have elapsed since the Timer was created.
Let's see how these might be used. Suppose we wished to process as many keystrokes
as we can in 2 seconds:
// Start a timer
Timer timer;
// Repeat as long as 2000 milliseconds have not yet elapsed
while (timer.elapsed() < 2000)
{
char ch;
if (getCharIfAny(ch))
{
// There was a character typed; it's now in ch
switch (ch)
{
case ' ':
...
break;
case ARROW_LEFT:
...
break;
...
}
}
}
// 2 seconds have elapsed
Project Setup
Here's what you should do to set up this project under Visual Studio.
1. Create a new project called, say, Chetyris.
2. Extract the contents of the chetyris-skeleton.zip file into the folder that already
contains the .vcproj file. If your project is named Chetyris, this will be the
folder Chetyris/Chetyris.
3. In the Solution Explorer window, right-click Header Files, and use Add
Existing Item to add all the .h files.
4. In the Solution Explorer window, right-click Source Files, and use Add
Existing Item to add all the .cpp files except UserInterfaceUnix.cpp.
5. In the course of your development, add new .h and .cpp files to the project.
Here's how to set up this project under Xcode.
1. Create a new project called, say, Chetyris.
2. In the middle panel, select the Build Settings tab, and in the search box on the
line below that tab, type linker flags and hit Return. Click the right-pointing
angle next to Other Linker Flags, then click the Debug that appears, then the +
that appears. In the text box, type -lncurses. (The second character is a lower
case ell, not a one.) Hit Return.
3. Extract the contents of the chetyris-skeleton.zip file into the folder that already
contains the main.cpp file Xcode placed for you.
4. Right-click on the yellow folder icon with the name of your project and select
Add Files to "yourProjectName" to add all the .h and .cpp files to the project
except UserInterfaceWindows.cpp
5. Right-click on main.cpp and select Delete.
6. In the course of your development, add new .h and .cpp files to the project.
7. You can not launch the executable you build through the Go or Run commands,
because Xcode does not provide a true terminal window. Instead, right-click on
the executable under Products, select Show in Finder, and double-click on the
executable in the Finder window.
Here's how to build from the command line under Linux or macOS.
1. Put all the .h and .cpp files in some directory — perhaps ~/Chetyris
2. Open a shell window from the Terminal utility.
3. Change directories into that directory and delete the unneeded Windows
implementation file:
4. cd ~/Chetyris
5. rm UserInterfaceWindows.cpp
6. Execute one of these commands:
7. g32 -o chetyris *.cpp -lncurses on a SEASnet Linux server
8.
9. g++ -std=c++14 -o chetyris *.cpp -lncurses on other Linux machines
or a Mac
(The character after the hyphen is a lower case ell, not a one.) This should
produce an executable file named chetyris. To run it, execute the
command ./chetyris
Don't know how or where to start?
When working on your first large object oriented program, you're likely to feel
overwhelmed and have no idea where to start. It's important to attack your program
piece by piece rather than trying to program everything at once.
We'd recommend that the first thing you do is figure out how to represent the well and
how to display it, since that will let you see what's happening. Then pick one kind of
normal piece, say an I or an O, and get it to drop in the well and stop at the bottom.
Don't worry yet about letting the user shift or rotate it, and don't worry yet about
overlaps with other blocks.
Do not proceed until you have this working. You will clear up some misconceptions
you may have and will figure out some things about how the objects in the program
interact with each other. From this basis, there are many ways you could choose to
proceed next. You'll need to do all of these and more, but at this point you have more
freedom in choosing the order.
Consider overlaps with other blocks.
Respond to player commands.
Vaporize rows that fill up.
Add just a second kind of normal piece; don't jump into adding all the kinds of
pieces at once, or else any mistake in your design will probably be repeated ten
times instead of two. Even with two pieces, you can discover what they have in
common and how they are different to help you design appropriate classes.
Add one of the pieces with a special action.
What to Turn In
For this project, you will turn in a zip file containing exactly these seven files:
Piece.h contains all class definitions and constants relating to pieces
Piece.cpp contains your implementations of the above classes
Well.h contains all class definitions and constants relating to the well
Well.cpp contains your implementations of the above classes
Game.h contains all other class definitions and constants
Game.cpp contains your implementations of the above classes
report.docx,
report.doc,
or report.txt
your report
Notice that you will not turn in chetyris.cpp or the UserInterface files, even though
they are part of your project. Your program must build and function correctly with the
versions we provided.
Your report should contain 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
sing() function in my base Piece class because all Pieces sing, but each kind of
piece sings in its own way."
2. A list of all functionality that you failed to finish as well as known bugs in your
classes, e.g. "My VaporBomb doesn't work correctly, so for now I just treat it
like a normal piece." or "I couldn't get the recursive FoamBomb algorithm to
work, so for now it just checks its four immediate neighbors to see if they can
be foamed."
3. A list of other design decisions and assumptions you made (e.g., It was
ambiguous what to do in situation X, so this is what I decided to do.)
Notice that for this project, your report does not have to include a list of test cases.