Boston
University
Fall 2009
Team
Project II
Revisions
091105.1
- Added responses to questions
091103.1
- Added responses to questions
091026.1
- Initial version
Customer
Requirements and Implementation Guidelines
Your
group has been offered an opportunity by a major game distributor to create. .
.
'Boston University
Adventure'
Overview
'Boston
University Adventure' is an exciting multi-player game pitting students against
the Boston University faculty, administration and other hazards in a race for
the coveted title of "Software Engineering Student of the Year".
The
game must run on a local area network with any number of PC's (Mac, Linux or
Windows) connected either wirelessly or by ethernet cable, and will be
implemented with Java.
Rules
The
rules are simple. After a countdown of 10-9-8-7-6-5-4-3-2-1, each player starts
at a random campus location, makes his or her way to student registration to
enroll, then races about campus "attending" classes to earn credits.
Encounters with professors, administrators, the H1N1 virus and other hazards
deplete energy and impede progress. Visits to various campus dining locations
and exercise restore energy. The first student to earn all necessary credits,
and to reach the Agganis Arena for the "Software Engineering Student of
the Year " award wins.
Moving
about campus
Students
move around the Boston University campus along the sidewalks of Commonwealth
Avenue and its side streets, such as Cummington Street. The streets and
sidewalks run only in the four principle directions (i.e. streets and sidewalks
do not run in diagonal directions).
Each
student is represented by a small "South Park"-like graphical
character, and is accompanied by an energy meter that shows the current level,
and a number indicated earned credits. Students navigate by using arrow keys to
change direction and take forward steps.
The
playing area
The
playing area is the Boston University campus, extending from Mass Ave in the
east, to Nickerson Field in the west. The streets have been
"idealized" to run only in the north, south, east and west
directions. The playing area also includes the BU and Harvard bridges, as well
as Memorial Drive to provide students with an opportunity to run "bridge
circuits" to earn health and energy points. Of course the playing area
also shows the location of Student Registration, the Agganis Arena, classrooms,
and various campus eating places.
The
sidewalks consist of paths lined with dots spaced at regular intervals. One
"step" at "normal" speed moves a student by 5 dots.
Randomly
appearing about the playing area are: BU professors and administrators, the
dreaded H1N1 virus, and manholes.
Health,
Energy and Hazards Thereto
Initially,
each student begins with a health value of 100, which allows the student to
move at a "normal" speed. However, racing around campus depletes your
energy and causes you to slow down. Moving 100 dots reduces your health by 5
points. At or below 75 points (but above 25), your speed becomes
"slow" (3 dots per step). At or below 25 points, your speed becomes
"really slow" (1 dot per step).
Encounters
with hazards also deplete energy. If you encounter a professor or adminstrator
(10 of whom randomly pop up on sidewalks), you immediately feel drained, and
lose 5 points. If you come in contact with the H1N1 virus (5 of which is
randomly drifting along sidewalks), you end up in a special state called
"sick", and you must make your way to Student Health Services (at a
speed of "really slow") before you can attend any classes.
Stepping
on manhole covers (10 of which randomly distributed along the sidewalks) may be
either good or bad for you. Manholes may contain energy-depleting Silberite, or
energy-boosting Sclarite. An encounter with Silberite depletes your energy by
15 points and your credits by 2, while an encounter with Sclarite boosts your
energy by 25 points. The material under a manhole changes constantly, and is
determined randomly each time a student steps on the manhole. Chances are 5x
greater that you encounter Silberite than Sclarite.
Of
course good nutrition and exercise increase your energy (assuming you are not
"sick"). Eating at Cranberry Farms, Einstein's Bagels, Jamba Juice,
Loose Leafs or Subway increase your energy level by 20 points. Eating at Panda
Express, Papa John's or Starbucks increases your energy level by only 10
points. Getting something from Dunkin Donuts or Store 24 depletes your energy
by 5 points. A visit to the BU Fitness and Recreation Center increases your
energy level by 15 points. Running a bridge circuit boosts your energy by 25
points (when you are running a bridge circuit, you move at 15 dots per step).
At energy levels at or above 125, you can move at "zippy" speed (8
dots per step). To eat at one of the named locations, or to visit the BU Fitrec
Center, you need to "step" into it, and not just pass it. You must
move at least 200 dots before you can eat or exercise again.
Of
course, the main objective of the game is to accumulate credits. Randomly
distributed around the BU campus are the class locations for CS 101, 103, 105,
107, 108, 211, 212, and, course, 411 and 511. Each course is worth four
credits. In order to receive credit for a course, you must "attend
class" at least twice. You may not attend a class two consecutive times
(i.e. you must attend some other class in between). As you are earning credits,
your graphical character shows how many credits you currently have, and the
last class you attended. When you have earned 36 credits, you should race as
quickly as you can to Agganis Arena to receive your award for "Software
Engineering Student of the Year".
Game "Tuning"
It
is not clear whether the above point and speed systems make the game too easy
or too difficult. Therefore, we may adjust the values specified above if
warranted. It will be beneficial if you design the game to hold a set of
parameters for the point and speed values, rather than allowing these values to
be hard-wired throughout the code.
Communication
A
big part of the engineering behind this game will involve network communication.
All players are moving around in a single game "space", and,
accordingly, this information must be broadcast to all players in some way. In
the case of this game, this communication will occur over the LAN via TCP/IP
sockets.
Students
not familiar with TCP/IP sockets should immediately note this technical area as
a large "unknown" for which project time must be budgeted. We will
most likely do some exercises during the lab portion of class so you can get
some experience with TCP/IP and sockets.
Modules
Each
group will produce two programs: a student app and a game server app. The
student app will display the playing area, and will enable the student to
navigate. The game server app will hold the game data and will perform the game
logic (for instance, when a student app signals a move in a particular
direction, the server app will compute the new location for the student
character).
Additionally,
each student app must be able to play with any of other student and server
apps. Therefore, all groups must agree on a communication protocol for all
types of messages. It is highly advisable to work out an initial protocol as
early in the project as possible.
Multi-threading
Since
each running executable will be listening, broadcasting and updating the
graphics simultaneously, it will have to use threads running in parallel. This
may be another big "unknown" for which project time must be budgeted.
We will most likely do some exercises during the lab portion of class so you
can get some experience with programs that create and run threads.
Graphics
Clearly
a large portion of this project involves rendering the information viewed by
the pilots and spectators. Therefore knowledge of computer graphics is
essential, and may be yet another big "unknown" for which project
time must be budgeted. The lab exercise involving graphics is intended, in
part, to help you resolve this unknown.
Testbeds
Each
of these programs cannot or should not be implemented by writing one big
program. There are lots of pieces to this system, and most of these pieces are
best developed independently. A "divide and conquer" approach is
absolutely necessary for success, and you may be surprised by how well this
works.
Accordingly,
I will expect to see lots of testbed / test harness programs. Besides making
your development difficult, mingling too much development into one program will
cost your group grade points.
Each
testbed must provide the user with the ability to run a test suite and to view
the results. Among the testbeds to be created, there should be at least one
for:
(a)
sending and receiving messages
(b)
game logic
For
some of the testbed programs, there may be great benefit to investing in an
implementation that automatically runs tests and checks results.
Numerous
other portions of the system lend themselves well to development and
verification in testbeds, and I strongly encourage you to take this approach.
Programming
Technique
Development
will be "design-centric", which means that the design documents will
need to be kept current. To kep design documents current, you must change the
design information first. Curiously, using this method, the code is almost
incidental. More on this later.
The
programs will be implemented in Java.
Group
Organization
The
team should be organized into a tech lead, assistant tech lead, and
implementers, with responsibilities as in Project 1, namely:
The
tech lead is responsible for developing and documenting the conceptual data for
the project, and for communicating this information to the implementers. The
conceptual data includes, but is not limited to, the requirements, an overview
of the proposed system, interfaces between portions of the system, and
techniques and approaches for implementing the internals of system components.
The tech lead is also responsible for creating test cases to validate each
requirement item, and for running the test cases to inform implementers of
defects. The tech lead may not do any coding.
The
assistant tech lead is responsible for reviewing with the tech lead the
conceptual data, providing feedback to the tech lead, and for assisting the
tech lead with updating the conceptual data and communicating it to the
implementers. The assistant tech lead is also responsible for writing the user
documentation, for maintaining a schedule based on estimates and projections
from implementers, for maintaining the prioritized list of open issues, and for
writing status reports based on input from team members. The assistant tech
lead may not do any coding.
The
implementers are responsible for producing the code, and for notifying the tech
lead and the assistant tech lead when the conceptual data contains errors, or
requires clarification. When the implementers feel a significant change is
needed in the concepts provided by the tech lead and tech lead assistant, they
must first discuss these issues with the tech lead and the tech lead assistant,
who will make final decisions and document the changes. Implementers may not
make conceptual changes unilaterally. Implementers are also responsible for
providing the tech lead and assistant tech lead with feedback on requirements
and test cases, and with information necessary to develop the status report,
the schedule, the prioritized list of open issues and the user documentation.
Implementers should add test cases as they see appropriate and, of course,
making the tech lead aware of test cases that were added.
During
the entire course of the project, there should be a tight loop of feedback from
implementers to the tech lead and assistant tech lead, including providing the
tech lead and assistant tech lead with frequent (daily) code updates.
It
is highly recommended that you use some chat service for these discussions.
Occasional meetings are not sufficiently frequent to allow the design revision
process to occur quickly.
Initial Project
Tasks
You
probably want to get up to speed with anything you don't understand -- TCP/IP
sockets, graphics, multi-threading, and other issues. Implementers, in
particular, probably will benefit from writing some scratch code to get some
experience with these areas.
In
the meantime, the tech lead and assistant tech lead should write the
requirements, and come up with an overall design, including an initial set of
components and their corresponding test harnesses, and an initial schedule for
the project.
As
a starting point, it will be necessary to write a scenario in which several
students play a game. The details above leave out some key considerations that
will become evident when you try to write a scenario.
For
the functional requirements, it will be helpful to state "abilities"
from the perspectives of both the "student" and the
"server". Therefore your functional requirements should contain
statements of the form "The student shall have the ability to..." as
well as "The server shall have the ability to...".
For
each of the test harnesses, the tech lead and assistant tech lead should
specify an initial set of test cases which will be expanded as needed to
validate the correct functioning of each portion of the system. Implementers
should provide feedback to drafts of the requirements, design, test harnesses
and schedule provided by the tech lead and assistant tech lead.
Deliverables
On
the dates listed below, each group will submit at the start of lecture a
snapshot of the following:
+
Status report
The
status report should be a clearly-structured single page of prose succinctly
indicating what has been completed, what is to be done next, and any issues
facing the project.
+
Requirements document:
The
requirements document should contain a complete description of the intended
system in the form of "Ability to" statements, optionally in an outline
tree format. Each leaf of the tree should reference one or more test cases
containing complete information for reproducing the behavior of that particular
system ability.
The
requirements document should also contain a statement of anticipated risks and
unknowns, and an anticipated range of completion dates based on "best
case" and "worst case". The completion date should be calculated
from the number of and extent of the required features.
+
Current schedule
The
schedule should provide a plan for the entire duration of the project, and
should include significant milestones. Any submitted schedule should be
current, i.e., all target dates and milestones should be updated to take into
account any slippage that has occurred. This document should also contain an
appendix with supporting time estimates.
+
Meeting log
The
meeting log should notes for all meetings, phone calls, chats and any other
scheduled or informal communications among team members. In the case of chats,
a transcript should be included. I strongly recommend chats.
+
Design document:
The design document should contain the following sections: (a) a single page diagram showing the overall structure of the system, showing only relevant details, (b) one or more pages providing details regarding the components on the diagram (e.g. anticipated interfaces, protocols, platforms, development tools, libraries, etc.), and (c) a list of anticipated objects, the data they contain, and any other information essential for a developer to write code for the objects.
For
the user interface aspect of the design, this document should contain
hand-drawn sketches of the expected appearance of the forms presented to the
user.
+
Code
The
Java code written for the project, including test programs used to resolve
unknowns, testbeds, and actual applications.
+
User documentation
User
documentation should be formatted most conveniently for the user.
+
Prioritized list of open issues
This
document details the remaining issues, ordered by importance. The issues should
include known defects, if any.
Snapshots
of these materials will be due at the beginning of lecture on the following
dates:
|
November 9 |
Project
#2 snapshot #1 due by email -- this submission must include: a status report,
a requirements document with test cases, a current projected schedule, a log
of meetings, an initial system design, initial testbed programs |
|
November 23 |
Project
#2 snapshot #2 due by email -- this submission must include: a status report,
a requirements document with test cases, a current projected schedule, a log
of meetings, system design, testbed programs, initial component and system
code, initial user documentation |
|
December 14 |
Project
#2 due by memory stick only -- this submission must include all
specified items |
Important New Requirement : Weekly Personal Status Reports
Each
student must submit a weekly personal status report along with their homework
assignment. The status report should list what the student contributed to their
team project in the past week, along with a list of items the student plans to
contribute in the coming week, plus any relevant issues.
This status report is separate from the group status report to be provided with each snapshot. Additionally, the weekly personal status report must be provided even on weeks when a snapshot is due.
Grading Policy
All
members of a team will not necessarily earn the same grade.
Only
the final submission for each project will be graded. The snapshots will allow
me to provide teams with "mid-stream" feedback and to gauge progress.
However, failure to submit the required components of snapshots will adversely
affect the final grade.
Grades
will be weighted as follows:
|
Status
reports and meeting logs |
5% |
|
Requirements |
10% |
|
Test
cases |
10% |
|
Schedules |
10% |
|
System
design and testing with code |
33% |
|
Final
code refactoring and organization |
5% |
|
Open
issue management |
5% |
|
Documentation |
2% |
|
Snapshot
submissions (timeliness, completeness) |
20% |
Grades
for each of these items will be based on completeness, clarity, thoroughness, proper
grammar and spelling.
Although
it seems the tech lead's items correspond to a larger portion of the grade than
the items for the other team members, it is expected that all team members will
make substantial contributions to schedule development, system design
revisions, open issue management and other activities to equalize the amount of
time each team member spends over the course of the project.
Good luck!
Questions:
Any
questions not answered above will be entered below. Email me with any other questions that
"marketing" can and should answer.
Q:
What about test cases?
A:
Test cases are tricky in this project. On one hand, since you are signing a
contract with a game distributor, you want to have a fairly bullet-proof
acceptance criterion, i.e. some way to demonstrate you have implemented all of
the requirements. On the other hand, creating test cases for each requirement
item will be quite challenging. A good way to go (and perhaps the only
practical way) is to create test cases for the features that can be easily
demonstrated with the UI, and refer to test cases that can be used to
demonstrate features that cannot be tested with simple UI interaction. For
example, to join a game, you can easily go through an exercise on the student
app to show that this feature works. However, you can't easily use simple UI
interactions to show that your energy decreases by 15 points when you encounter
Silberite. Therefore you will need to refer to a test case in the game logic
testbed that deliberately exposes a student to Silberite, and checks the
student's resulting energy level. In either type of feature, it is advisable
that you be able to demonstrate to the game distributor that things work in the
manner specified.
Q:
What map is displayed during a game?
A:
The server app generates the map and defines coordinates. In other words, all
player maps have the same streets and sidewalk dot patterns.
However
the student apps will control how certain things are drawn (e.g. the student
characters, the H1N1 virus, an encounter with a manhole, etc.), so the
displayed map is a hybrid of the structure provided by the server, and the
details provided by the student app.
Added
11/3/2009
Q:
How long do you anticipate a single game to last time-wise?
A:
I really don't know. The student has to attend nine classes twice, as well as
make stops to eat and exercise. Some time may be spent avoiding the H1N1 virus
and running bridge circuits. Let's say each thing takes 15 seconds. That makes
it seem that a game will last about five minutes.
Q:
Are professor/administrator's location randomly determined at the start of the
game when the map is distributed, or do they have a percentage of randomly
appearing throughout the game?
A:
Professors and administrators pop up (they are invisible until encountered),
and then move to a new random location. Does the client need to know where the
invisible professors/administrators are? Or does the client need to know only when
one has been encountered by a player?
Q:
Same question with manholes.
A:
Manholes are visible all the time, and don't move. The only thing that changes
with each encounter is the material under the manhole. It changes randomly,
with a 1:5 bias in favor of Silberite.
Q:
Same question with classes - CS101, etc.
A:
Classes are visible all the time, and don't move. The locations of classes are
determined at the start of a game, randomly or otherwise.
Q:
Are the aforementioned - professors, administrators, manholes - as well as the
H1N1 virus visible on the map as they are approached? (In other words should
players have opportunity to avoid them?)
A:
Professors and administrators are invisible. Manholes and the H1N1 virus are
visible, and can be avoided.
Q:
Is there a maximum achievable health?
A:
No, there is no limit to health/energy. The maximum speed, however, is 8 dots
per step (15 dots per step when running a bridge circuit). A "step"
is one arrow keypress. Your server will receive keypresses, incorporate them
into the game state, and broadcast the resulting game state in "time
slices".
BTW,
a useful experiment would be to see how many time slices your server can handle
per second. The key factor determining the frequency of time slices will be the
length of time it takes to broadcast updates of the game state to all the
players.
Q:
How long does it take to "attend" class?
A:
You just have to step into the class, and then back out.
Q:
How long does it take to eat?
A:
You just have to step into the eating place, and then back out.
Q:
How long does it take to exercise? (Via fitrec and bridge circuits)
A:
Exercising at the fitrec center requires you to just step in, and then back
out. A bridge circuit requires you to actually move your player in a complete
loop that includes the BU bridge, Memorial Drive, the Harvard Bridge, and
Commonweath Avenue. To complete a bridge circuit you need to return to the
place where you started. BTW, there will need to be some way for a player to
declare they are starting a bridge circuit, and to leave some sort of marker at
the starting point.
Q:
How long does an encounter with a professor (or administrator or virus or
manhole cover) take?
A:
No time at all. You just bump into a professor, administrator or virus, or step
on a manhole, and you immediately lose or gain energy points. There should be
some graphical indication reporting what happened. The graphical indication
should remain around long enough for you to realize what happened.
Q:
How long should a step take?
A:
A step is one arrow key press. A step will take as much time as the network
communication takes for the server to recognize that a player pressed a key,
and to send an updated position. BTW, you probably want to consider a process
where the server has a thread listening for key presses from a player, while
another thread is broadcasting the current game state to the player at regular
intervals. During the time between broadcasts, the game logic thread incorporates
the steps that have come in from players.
BTW,
if your speed is, say 8 dots per step, and you are approaching an intersection
that is, say 5 dots away, you will not move 8 dots. You will just move 5 dots
to the intersection so you can choose which way to go from the intersection.
Q:
Will all players need to be visible on each other's maps and if so are there to
be restrictions on two or more players occupying the same space at the same
time? (This could mean the same map square on the street, but also eating at
the same restaurant at the same time or attending class together or exercising
together)
A:
All players will be visible. For simplicity, more than one player may occupy a
location. It will be good if the client provides some way to show that more
than one player is at a location so your player doesn't suddenly
"disappear".
Q:
Do players have "encounters" with each other?
A:
For simplicity, players magically pass through each other.
Q:
Are there any project requirements you are willing to forgo in order for us to
provide a higher quality deliverable?
A:
Probably the first thing to go would be the bridge circuit.
Q:
Be advised that marketing should have consulted with a tech team before
projecting a timeline of having a deliverable 6 weeks after a product
description was given to the tech team. We believe a project of this size takes
months to years to properly develop. The proper design of a map is a month long
task, especially if it is to include decent graphics and a somewhat correct
representation of campus. The sheer size of the map also warrants this, having
to include multiple classroom buildings for at least 9 different course
locations, 10 food locations, several other buildings including FitRec, student
registration services and Agganis, and the "bridge circuits" which
extend off campus. Secondly, the networking for this project is huge, as much
must be communicated in an efficient manner. It is also a big time constraint
to have a protocol committee agreeing on protocols so all games can interact
with each other; a major game distributor would most likely not have several
teams working to produce variations of the same thing and then asking these
teams to work together. Also, despite our group being ready to move forth, it
appears the rest of the class may not quite be ready to establish protocols.
Lastly, testing for a project this size is a multi-week to month long process,
depending on the resultant magnitude of the game. In test, characters will need
to traverse the entire map, have all possible street encounters in varying
order, attempt to eat at all locations, attend all classes, try all forms of
exercise and such. Also at least one secondary map would need to be developed
in order to ensure our game can read a different map file and isn't exclusive
to our map.
With
all of these things in mind I hope you will consider significantly extending
the timeline for this project or reducing the requirements for this game. We
look forward to hearing your responses on the above questions.
A:
Thank you for your well-considered analysis.
Some
simplifications:
(1)
The map will be merely a network of grid points representing streets. It can be
as simple as the following, which took only a few minutes to create:
I'm
not that familiar with the BU campus, so I'm not sure what other streets it
makes sense to include. Classrooms are identified with the course number. The
fineness of the grid will need to be tuned to create a proper rate of player
speed (e.g., one step at 8 dots/step should not take you the full length of
Comm Ave), and to accommodate all of the classrooms, eating places, etc.
BTW,
you probably want to give the clients the ability to zoom in, zoom out and pan
so you can control what you see.
There
is no need to spend a large amount of time creating sophisticated graphics.
(2)
The number of classes and eating places may be reduced, but it doesn't seem
reducing these numbers would simplify the game design.
(3)
We may drop the bridge circuit. However, for now, consider it in. Remember that
the game logic needs to have the ability to remember the location where a
player started a bridge circuit.
You
are correct that the protocol committee must be very responsive. However, the
process of defining the protocol will most likely be an 80/20 thing: I suspect
that the committee will determine 80% of what you need quite quickly.
The
bottom line: the "customer" will judge your work by the quality of
the engineering process you use. It may be that a sound engineering process
will not get the product completed by the designated date. The important thing
will be: what did you accomplish up to that point, and how did you do it?
Q:
The idea of "bridge circuits" - we were a bit confused on how these
would be represented. Is it simply the player going to such a location, and
earning the pre-set amount of health/energy (and having the player
"inactive" for a set amount of time to account for the time it takes
to run such a circuit), or is it an actual mini-game sort of ordeal?
A:
Running a bridge circuit involves moving your player starting somewhere on the
BU campus to the BU bridge, over it to Memorial Drive, along Memorial Drive to
the Harvard Bridge, over the Harvard Bridge to Commonwealth Avenue, and back to
the location on the BU campus where you started. Going the other way around
(Harvard Bridge first) will also be valid. You will actually see the player
avatar running this loop at the speed indicated in the original spec.
There
will probably need to be some way for a student to indicate they are starting a
bridge circuit, and probably some way for the student to decide they have
decided not to complete it (e.g. the student gets to the BU bridge, and decides
to go to a class or something instead).
Completing
a bridge circuit earns the health points indicated in the original spec.
Q:
Is there a difference between health and energy? In some parts of the document,
there seems to be a distinction, but in other parts, they seem to be used as
the same term/concept.
A:
Sorry about using both these terms for the same thing. I mean to call this
quantity energy, the level of which determines how fast you can move.
Q:
For the pop-up of professors, in terms of "randomly appearing", does
that mean that they randomly show up on the map, then disappear off to another
location (like warping), or are they walking around (but have spawn points at
random locations), or are they very random occurrences (in other words, not
drawn at all)
A:
The professors will pop up, and will warp to other locations randomly
afterward. The professors won't be displayed (so students can't avoid them)
except for when a student passes over the location of a professor. A professor
encounter results in some sort of graphical effect that lasts for a brief
period of time to let the student know that they had a professor encounter.
The
H1N1 virus, on the other hand, will visibly drift around the sidewalks, and
students will have the ability to see and avoid it.
Q:
In the discussion of food shops, there was mention of stores that seemed to
only provide negative energy. Is there any reason at all why a player would go
into the shop, if there isn't even an underlying/inherent benefit for the
player to go? (this might be clarified if there was a difference between health
and energy)
A:
This is my sense of humor, and perhaps my message about nutrition. I'd leave
the shops that give you negative energy as potential pitfalls that someone not
paying complete attention might fall into.
Q:
What are the possibilities of using a plug-in graphics engine? Are we
constrained to using only what we write, and not third-party Java libraries?
A:
The graphics will be done using the vanilla graphics code in one of the labs.
Likewise for TCP/IP and threading. You may not use any plug-in engine or third
party libraries.
Q:
On the website, it says the player has to go to class twice in order to pass,
but we thought it would make more sense to require them to go to class once and
then take a final for that class? We could assign the class and final in
different locations, and they could choose to take the final right after the
first class or do other things and then take the final.
A:
I'd like to keep it simple because you have a relatively limited amount of time
to create this game: The player has to attend class twice to get credit for it.
Q:
We also thought that it may be a good idea to divide up the classes into
semesters or years, and have them take the lower-level CS courses before they
can move on to the more advanced classes. Right now there are 9 courses, so 3
courses per level would make sense, or we could add 3 more courses to the list
so that we could have 4 levels = 4 years.
A:
Once again, I'd like to keep it simple: the player has to take all the courses,
with no concept of semesters or years.
Q:
We also felt that due to the complexity of this game, there may be many more
design changes such as the above that we may want to make as we go along, so
would we have to ask you to approve all of them before we go ahead with them?
We felt that changes like the ones above would improve the player's game
experience without changing the type of coding we would have to do.
A:
You should not implement game rules that were not approved by
"marketing" (i.e. me) approves them. Remember that your
"student" app needs to work with some other group's server app, and
vice versa, so your game can't have rules different from those of other groups.
Feel
free to suggest rule changes. Certainly ask for clarifications of the current
rules.
Q:
Also, do we have to hand in our weekly status report this coming Monday?
A:
Yes. Every week.
Added
11/5/2009
Q:
How are players' starting locations determined? (Via server or client, and/or
everybody at same place)
A:
They start at random locations. Seems unfair, but so is life. :-)
Generally
"marketing" doesn't have a clue about how the software is
implemented, but in this case I can provide some guidance. The client reports
only what the server tells it (i.e. the client cannot tell the server where to
place it). Therefore it is the server that must assign each player's initial
location.
Q:
Is there a limit to number of players?
A:
No.
Q:
We weren't sure why you lose energy by eating at Dunkin Donuts (it just seems
that no one would ever eat at Dunkin Donuts).
A:
It is just my commentary about the concept of eating at Dunkin Donuts.
I
don't want to make the project any more complicated, so I *won't* add a rule
that when you leave Dunkin Donuts (i.e. with a sugar high), for five steps, you
have an energy level of 125, and then drop to an energy level of 50.
Q:
We were also wondering what happens when you get to 0 energy.
A:
Nothing. Once you get down to 25 units of energy, you just move slowly. At zero
units, you move just as slowly.
Q:
What should the initial test harnesses should consist of?
A:
Test harnesses are programs that allow you to work on a class or a group of
classes without having to build and run the entire application. In this
particular case, where you have a server and a client that you would have to
set up properly for each test run, test harnesses will save you a lot of time
and effort. In short, test harnesses "decouple" your objects and
components so you can work on each thing more easily and quickly.
For
instance, imagine your game logic is handled by a main game logic class, which
holds the game state, including all the players who have joined. The elements
of the game state are probably represented by classes as well (e.g. an object
for each player, professor/administrator, H1N1 virus, etc.).
You
probably will be able to test your intended game logic design much more quickly
if you create a special program for testing just those objects involved in the
game logic. You'd start out creating a vanilla Java main() program, then add
the objects involved in the game logic.
You
may wonder how this game logic interacts with other parts of the system? In
other words, doesn't this program need to get input from the clients to know
how to move the players around? The answer is: no.
The
way this special program works is that it initializes the game to a particlar
state, and then it sends in some changes. For instance, this special program
can
(1)
create a new instance of the game logic
(2)
add a player at grid point 50, 50 facing east
(3)
update the game state with a step forward by the player
For
instance, you code might look something like:
Game
game = new Game();
Player
player = game.AddPlayer("Aramis");
player.SetPosition
( 50, 50 ); // 50,50 is a location where a player can move eastward by 5 grid
points
player.SetDirection
( EAST );
player.SetEnergy(100);
// so the player moves 5 grid points per step
player.StepForward(1);
Result
result = player.GetLastResult();
//
result can tell you all about what happened when the player took the step.
Location
location = player.GetLocation();
if
( location.x == 55 && location.y == 50 )
{
system.out.print("test case passes");
}
else
{
system.out.print("test case fails");
}
One
option is to hard-code test cases like this. However, you may find it faster
and easier to create new test cases by defining them in a test file using a
format such as:
BeginTestCase
Simple1CanMoveEast
NewGame
AddPlayer
Aramis Position 50,50 Direction EAST Energy 100
StepPlayer
Aramis 1
CheckLocationOf
Aramis ShouldBe 55,50
EndTestCase
Of
course you'll have to add some code to your test harness to parse the commands
in the test file. Also, you will find it helpful to write the success/failure
(possibily with some details) to an output file that contains the results of
all your test cases.
In
any case, the convenient part about this approach is that you will not have to
worry about the communications, graphics or other parts of the system while you
work on your game logic.