Jousting program help in C++
domimand
projectj_handouts.pdf
Ver. 3/2013
CSCI 111 – Programming and Algorithms I
Project Materials
Joust
CSCI 111 – Programming and Algorithms I, Joust Materials, Ver. 3/2013 1
M E M O R A N D U M
To: New Developer Team
From: Nancy Mordecai
Date: 10/19/2012
Subject: Project Assignment
I have your first project assignment for you! Again, thanks for starting immediately. As you’ve seen, we have plenty of work to keep you busy.
I have attached to this memo some mail that has gone back and forth between the designers. I would like you to develop the test program they mention in their mail. The test program is for a new game they are designing.
The senior developers will want to borrow heavily from your test code once Martina and Tom complete the design and pass it off. Therefore, be sure to follow the new set coding standards that the senior developers have been working on. And don’t forget the discussion at the developer meeting: encapsulation and abstraction is the cornerstone of good OO design.
Let me know if you have any questions.
Nancy
CSCI 111 – Programming and Algorithms I, Joust Materials, Ver. 3/2013 2
Received: from bogey.saberware.com (bogey.saberware.com [208.43.149.4]) by
is-3.saberware.com (8.7.3/8.7.3) with ESMTP id HAA25926 for
<[email protected]>; Mon, 27 Aug 2012 08:01:01 -0600 (MDT)
Received: from martinav.saberware.com ([208.43.149.44]) by bogey.saberware.com
(Netscape Mail Server v2.0) with ESMTP id AAA5157; Mon, 27 Aug 2012 08:15:35
-0600
Message-ID: <[email protected]>
Date: Tue, 27 Aug 2012 08:15:23 -0800
From: [email protected] (Tom Jenkins)
Organization: SaberWare Software
X-Mailer: Mozilla 4.01 [en] (Win95; U)
MIME-Version: 1.0
Subject: joust game notes
X-Priority: 3 (Normal)
References: <[email protected]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Status: RO
X-Mozilla-Status: 8011
Hi Martina:
Here is a summary of what we talked about in the design meeting. We decided
that a medieval joust would be the theme of the new game. Basically, two
knights joust round after round until one is unhorsed. Each knight carries a
jousting weapon that has a certain chance of unhorsing the opponent.
At some point we wanted to do research to find names of real knights that we
could use.
I thought a bit more about jousting weapons. Rather than assuming each knight
has a lance, let’s have several different weapon choices for the knights. Each
weapon has a different chance to hit. The greater the chance to hit, the more
stamina that is required from the knight to wield the weapon. Each knight can
have a "reserve" of stamina to draw upon. Each round of the joust depletes
from the knight’s stamina. If the knight’s stamina reaches zero before the
joust is over, the knight loses due to collapsing from exhaustion.
"What do you think, sirs?"
Tom
CSCI 111 – Programming and Algorithms I, Joust Materials, Ver. 3/2013 3
Received: from bogey.saberware.com (bogey.saberware.com [208.43.149.4]) by
is-3.saberware.com (8.7.3/8.7.3) with ESMTP id HAA25928 for
<[email protected]>; Tue, 28 Aug 2012 08:36:27 -0600 (MDT)
Received: from martinav.saberware.com ([208.43.149.44]) by bogey.saberware.com
(Netscape Mail Server v2.0) with ESMTP id AAA5157; Tue, 28 Mon 2012 08:26:37
-0600
Message-ID: <[email protected]>
Date: Tue, 28 Aug 2012 08:33:58 -0600
From: [email protected] (Martina Voss)
Organization: SaberWare Software
X-Mailer: Mozilla 4.01 [en] (Win95; U)
MIME-Version: 1.0
Subject: Re: joust game notes
X-Priority: 3 (Normal)
References: <[email protected]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Tom,
To keep things simple, let’s assume that the knights come together
simultaneously. Both get a chance to joust the round before we decide if one
(or both!) is unhorsed. Your idea for the different types of weapons sounds
good.
I thought that before we continue with the design, it would be a good idea to
get the programmers to develop a simple test of our knights and weapons to see
if we can come up with some balanced numbers for the hit chance and stamina
values.
I will talk with Nancy to see if she can loan us some programmers. Some simple
output would be good for verifying the numbers. For instance, at the beginning
of the test run the program would display each knight’s name, stamina, and
weapon statistics. Then, report the result of each round, saying whether a
knight was unhorsed or collapsed off of the horse due to exhaustion.
I imagine after a few tries with different hit-chance/stamina combinations
we’ll start to identify values we’ll want to remember and put into a file.
I’ll have the programmers build some flexibility into the test program so we
can enter the weapon values from the keyboard or read them from a file.
M.
CSCI 111 – Programming and Algorithms I, Joust Materials, Ver. 3/2013 4
Received: from bogey.saberware.com (bogey.saberware.com [208.43.149.4]) by
is-3.saberware.com (8.7.3/8.7.3) with ESMTP id HAA25926 for
<[email protected]>; Wed, 29 Aug 201213:31:14 -0800 (MDT)
Received: from martinav.saberware.com ([208.43.149.44]) by bogey.saberware.com
(Netscape Mail Server v2.0) with ESMTP id AAA5157; Tue, 26 Aug 201213:15:35
-0800
Message-ID: <[email protected]>
Date: Wed, 29 Aug 2012 13:15:23 -0800
From: [email protected] (Tom Jenkins)
Organization: SaberWare Software
X-Mailer: Mozilla 4.01 [en] (Win95; U)
MIME-Version: 1.0
Subject: OK, sounds good
X-Priority: 3 (Normal)
References: <[email protected]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Status: RO
X-Mozilla-Status: 8011
Hey again,
I want to get going ASAP on some experimentation. Let’s hold off on the file
features for now so we can get an initial prototype to play with. The
programmers can work on a revision to support files after we start playing with
the first test program they come up with.
Thinking ahead, since I’ve mentioned the next revision, there are a couple of
things I would like to mention while they’re on my mind. For the next revision
I would like to experiment with some more complex formulas for calculating
exhausion. Not just looking at the stamina, but integrating in other aspects
of the knight as well. Along the same lines it would be nice to come up with a
more complex method of deciding whether the knight is still on a horse.
"I have spoken. I am Tom."
Tom
Coding Standards Version 1.0
1. Constructors should always be written for the creation and initialization of objects. If a constructor which takes arguments isn’t required, a default constructor should be written to initialize all data members.
// File: date.h
class Date{
public:
Date(int m, int d, int y);
private:
int day;
int month;
int year;
};
// File: date.cpp
Date::Date(int mo, int dy, int yr) : day(dy), month(mo), year(yr)
{
}
2. Use common sense commenting. If it isn’t obvious what a segment of code is going to do or what the variable is for, add a comment explaining its purpose. Also, author of the code, as well as the name of the file should be included in comments at the top of each file.
3. Use proper data encapsulation. Member data should always be either protected or private.
1
CSCI 111 – Programming and Algorithms I, Joust Coding Standards, Ver. 3/2013 2
4. Initialization lists should be used in constructors as much as possible. Even built-in types should use the initialization list.
// File: person.h
#include <string>
class Person{
public:
Person(string n, int a);
private:
int age;
string name;
};
// File: person.cpp
#include "person.h"
Person::Person(string nm, int a) : age(a), name(nm)
{
}
5. The class declaration of each class should be placed in a header file with the same name as the class. The definition of the class’s member functions should be placed in a separate source file named the same as the class:
//File: date.h
class Date {
public:
void display();
...
private:
int day;
...
};
//File: date.cpp
void Date::display()
{
cout << month << ’/’ << day << ’/’ << year << endl;
}
CSCI 111 – Programming and Algorithms I, Joust Coding Standards, Ver. 3/2013 3
6. All header files should start and end with preprocessor directives to prevent multiple #include problems. By convention, the symbol names should be the same as the filename, using an underscore instead of a period. Also, the symbol should be all-uppercase:
//File: date.h
#ifndef DATE_H
#define DATE_H
class Date {
...
};
#endif
7. Each project should include a Makefile with proper build rules (rules to build object files from source files, a rule to build an executable from object files).
