Paintings & Links
CS 134 Green Sheet, Fall, 2003
Prof. Rudy Rucker, MH 213, 924-5147, How to email me.
Office Hours: M 12:30 - 2:00, T 1:30 - 3:00, W 12:00 - 1:30
Section 1 Meets M & W 2:30 - 3:45 PM, SCI 311.
Section 2 Meets M & W 4:00 - 5:15 PM, SCI 311.
Note: we have limited seating in the classroom, and we plan to
work in teams.
You MUST attend the correct time section. You CANNOT register for
one section and be planning to regularly attend the other section.
Midterm: Both Sections, Monday, October 13.
Final Demos and Final Exam:
Section 1: Mon, Dec 15, 12:15 - 2:30 and Section 2: Wed, Dec 17,
2:45 - 5:00.
In this course we are going to work on using and extending an existing
software framework to build a sophisticated two or three dimensional
videogame. We will also discuss topics in software engineering,
object oriented design, and the use of software patterns.
Additional topics include animation techniques, physics simulation,
user controls, graphical methods, and intelligent behaviors. Course
includes a final project.
Our software project will use Windows MFC and the OpenGL
graphics library, and the software "Pop framework" that
accompanies Rucker's textbook, Software
Engineering and Computer Games. The book website also has a
page showing examples of past student game projects built with the
As the Pop framework code is quite object-oriented, you
won't actually need much nitty-gritty Windows knowledge. The main
thing you need to know C++ and the object-oriented paradigm.
The operating system used will be Windows 98/NT/2000/XP. The programming
language will be C++ for Windows, using the Microsoft Foundation
Classes (MFC) and OpenGL
Assignments relating to instructor-specified programs will be given
in the first part of the course by way of getting the students up
to speed with our platform. We will cover some OpenGL topics as
well. In the second part of the course, we will divide the class
into several teams and have the students work on different aspects
of our target game project or projects. The projects will be interactive,
immersive 2D or 3D videogames. It is hoped that students will
develop some new techniques, patterns, and objects for use in their
The specific projects will be discussed and designed by the students
and the professor over several iterations. Team members and project
goals will be assigned by the instructor, taking into account student
preferences and classroom discussion. Each project must (1) be based
on a solid object-oriented design, (2) have a graphical user interface,
and (3) have user documentation. We will do some programming work
in class; to use our lab machines you must either (a) register for
CS 110 (you will need to get an add code) or (b) pay a one-time lab
fee of $45 to the MathCS department.
The required texts and software for the course are:
- Rudy Rucker, Software
Engineering and Computer Games, (Addison Wesley), 2002.
- Microsoft Visual Studio.NET or the older Visual C++,
version 6.0 . You gan get Visual Studio.NET for $100 at the
Spartan bookstore. Get the software installed as soon as
In my opnion, Version 6.0 is just
as good as .NET, so it's fine if you use that.
The OpenGL Programming Guide. (Addison Wesley) is also
recommended if you plan to work in 3D. You can buy this or you can
also read it online at this site:
Grades will be based on writing and programming assignments
(~60 pts), on an in-class written midterm on the lecture material
(~60 pts), the term project (~45 pts), and a short final exam (~15
pts) on your team's specific project which I use to sharpen my judgement
of how much work you did on the team's project. Homework
later than 7 days will not be accepted. WARNING: Skipping a homework
assignment can lower your final grade by as much as a half grade
point. The midterm will be an in-class written test. We will
have in-class practice sessions for the tests to go over the procedures.
For the final exam we will have final classroom demos of the student
The term projects will involve several preliminary assignments
(requirement, specifications, prototype, alpha releases, class-room
demos) as well as the final beta release with documentation. Grading
of the projects will be based on (a) Lack of Bugs, (b) Originality
and Difficulty of the Project, (c) Simplicity and Strength of User
Interface, (d) Quality of Printed and Paintings & Links Documentation,
(e) Classroom Presentations and Demos. About a third of your
project grade will depend upon how much you conribute to the team.
Programs are to be submitted in a two-pocket folder holding (1)
a floppy disk or disks with runnable Windows *.EXE file with buildable
source code and (2) printed documentation. Source code should build
with no warning messages. Specs and documentation should be attractively
formatted and printed out. Assignments are due at the START OF CLASS
on the due dates. Assignments will be graded down 20% for 1-7 days
late. Assignments later than 7 days will not be accepted. WARNING:
Skipping an assignment can lower your grade by a full point.
The prerequisite for this course is (a) CS 151 with B- grade or
higher (b) some knowledge of Windows programming, preferably from
With the prof's approval (ask him about it) some students may possibly
waive requirement (b) if they at least have a strong knowledge of
You should not try to tackle the course if you only know
Java and have no C++ or Windows experience.
Cheating policy: Copying on an exam will result in a score of 0
on that exam for both parties.
Individual Assignment 1. 10 Pts, Wednesday, Sept 3.
Write out your answers to
Exercises 1.1 (A) - (C) as listed in Rucker's book and printed here,
skipping (D) and (E). Also answer 1.2 in Rucker's book as listed
here . Be sure to include a picture! Also
answer question 1.3, stated on this page. Must be typed, spell-checked,
and printed, two to five pages long.
Exercise 1: (2 Pt) Beginning to think about your project.
In the following series of questions, I'd like you to begin trying
to work out what you might do. As you go further in this book you'll
get a better idea of what things might be possible, and you can
then come back and revise your answers to these questions. Write
down your answers to these questions. (A) What are two computer
programs you really like? Say what it is that you like about them.
These can be any kind of program at all. (B) What is a "dream"
program would you like to write if you didn't have to worry about
actually getting the code written? Write out some of the great features
you'd like for this program to have. If you have ideas for several
different dream programs put them all down. (C) What are some areas
of programming you think you'd need to learn about to write some
really great programs? Try to be as specific as you can.
Exercise 2:(6 Pts) Dream and reality. Spend a half hour
running the Pop program. Assume that you're going to build your
project by extending this code. Rethink your answers to Exercise
1. Now write up an idea for a game project you think you might like
to do. Explain what would be the concept of the game, how the user
controls might work, and draw a picture (worth 2 Pts) (picture
can be hand-drawn) of how you think your game screen might look.
Your grade on this part will reflect whether I think the game idea
is feasible, challenging, interesting, and original. Note that you
will be able to change your project idea later on.
Exercise 3: (2 Pts) Extending the Pop Framework. In order
to get the highest credit for your project, you will need to extend
the Pop Framework in some useful way, and then use these new extensions
in your game. What are some classes or features that you might imagine
adding to the framework so as to create the kind of game you'd like
Individual Assignment 2. 20 Pts. Wed, Sept 17.
Hand in the Space Invaders program as discussed in class and in
Score is 20 pts, 5 for Mechanics, 5 for Basics, 10 for Extras.
Extra things to try are listed here.
Go ahead and have some Rival critters.
Get three levels working. The game maintains a _level parameter
which has a default
value of 1 that is reset to 1 when the reset() method is called.
Don't use 0 as as level. Have levels 1, 2, and 3.
(a) Have cGameStub::seedCritters do a switch on the _level value
of 1, 2, or 3.
(b)Have cGameStub::adjustGameParameters() bump the _level and reseed
certain values. You can at the same time change the backgroudn bitmap
with a call to, like,
(c) To really make the levels different, you'd want to have the
Prop and Rival constructors have switch or branch behavior that
depends on pgame()->level(). You can change their apperance and
Have variable effects from hitting the critters with the player,
so you can have healthpacks. You do this by overloading
BOOL cCritterStubPlayer::collide (cCritter *pcritter)
to react to the type of the critter being hit.
Give the game a 3D look by doing the following. I'm not totally
sure this is a good idea, in terms of having the game be visually
nice, but you might do it for one level.
(a) Change cGameStub::initializeView like this.
void cGameStub::initializeView(CPopView *pview)
call the baseclass method.
//Default is FALSE
(b) In the cGameStub constructor, keep the 2D _border.set(20.0,
40.0, 0.0), but
move the background bitmap lower with a line like
cGame::BACKGROUNDOFFSET = 0.5;
(c) Change the constructors of the props, rivals and maybe bullets
to be interesting 3D
sprites, using lines like
To make the props move back and forth like space invaders, try
adding some more
lines to cGameStubProp::update(). Leave the old code in place, with
the wrap tests you put in, but add the following, using a Real _stepdt
time-step parameter intialized to maybe 0.4,
int step = (int)(age()/_stepdt); //Break time into _stepdt chunks
step = step % 4; //Modulo operator % gives us 0, 1, 2, or 3 here.
cVector newdir = -cVector::YAXIS; // point down the screen,
//We simply use this for step case 0 and 2.
if (step == 1)
newdir = cVector::XAXIS;
if (step == 3)
newdir = -cVector::XAXIS;
Note that using the setTangent call in update will erase the effects
of any of the forces you've attached to cCritter. You could use
setVelocity(speed*newdir), instead of setTangent if you like, with
speed maybe being something you set according to whether you're
moving down or across.
-2 late one class, -4 late two classes.
Individual Assignment 3. 25 Pts. Wed, Oct 8.
WHEW. Morning of Oct 2. I fixed the the cCritterWall::collide
code so it takes the colliding critter (like player's) absorberflag
and bounciness into account. I fixed a bug that kept friction from
working on the player. I fixed a bug that kept the walls from being
able to move itno position. Now I have a really nice build for you
to work with, I'd advise migrating your changes into the new gamedambuilder.cpp
and gamedambuilder.h, also be sure and use all the other new files,
as I touched quite a few of them in my repair frenzy.
ONE MORE FIX. Afternoon of Oct 2. I fixed it so the quake
sprites aren't waist deep in the floor. It was a matter of tweaking
the correctionpercent params they use (in game.cpp and in quakesprite.h).
No more changes till after the homework (unless someone finds a
horrible bug). I also fixed a bug where the player bullets were
copying the car's friction.
ONE MORE MORE FIX. I changed critter.*, critterwall.*, and a few
lines in gamedambuilder.cpp so that (a) I can drag walls without
having them sink into the floor and changed spritequake.cpp so (b)
the spritequake guys have a constant animatoin rate, they used to
speed up as the frame rate increased, but now their apparant rate
of armswinging stays the same.
Make Dambuilder into a 1st Person 3D Racing game as discussed in
Note three typos in the description of cForceWaypoint on p. 163.
Line 3 should read <CArray<cVector, cVector>.
The code for cForceWaypoint::force should include "pcritter->"
in front of the calls to distanceTo, position(), and setTangent.
The bottom line of the force code has the */ in the wrong place,
it should read:
will normalize the arg*/
Actually the cForceWaypoint::force on p. 163 is too non-physical.
Instead use this kind of code, taken from cForceObjectSeek::force
cVector pursueforcevector =
pursueforcevector *= pcritter->mass(); /* Optional whether you
include this line
to scale steering with mass. If yes, big
guys have big motors, if no, big guys are
sluggish. See which looks better. */
Score is up to 25 pts:
5 for Mechanics (Release exe in root, printed description of game,
two pocket folder, your name in caption bar.)
12 for basics: (1) Start in 3D ride the player mode with background
bitmap turned off and (1) solid floor lowered with cGame::BACKGROUNDOFFSET
high enough so you're not "wading.". (2) Walled maze,
walls on both sides, maze nice and twisty. (2) Opponents steer along
the track using waypoints. (1) There is a visible finish line. (2)
There is a lap count score. (3) Game is playable. Be wary of putting
a bitmap on the floor (bakground), this tends to slow performance
down on many machines, so better not to do it, I think. Focus on
PLAYABILITY, that comes before looks. Make sure you have OpenGL
acceleration working on your graphics card so you can judge.
13 for extras:
(1) * Walls are nice different heights and colors ( I changed the
cCritterDamWall constructor to randomize height (_prismdz) and color.
(1) * Maybe you figure out how to attach bitmaps to some walls.
But don't overdo and put bitmaps on all the walls as this may kill
the execution speed.
(1) Some hazards in the maze, like spots where there are vortex
(1) Put some marks on the walls or on the "floor" so you
can tell which way is forward around the track. You can draw the
marks in the cGame::drawBackground method (check how I do it in
(2) Use nice sprites for player and opponents look cool. Simply
dropping in a cSpriteQuakeOgro isn't going to impress me, though.
cSpriteComposite of polygons will impress me. If you use an MD2,
find a new one.
(1) Realistic physics including slowdown when you hit a wall, spinout,
slip on curves.
(1) Two player mode.
(1) Speed-up pellets.
(2) Shooting, though if you shoot a rival there should be some "cost".
(a) It drops your speed way down and (b) the rival shatters into
pieces which collide with you, see gamedefender3d.cpp for excample
of fragment critters.
(1) Other cool things I didn't think of.
Late one class: -3 points, late two classes -6 points, late three
classes forget it.
Individual Assignment 4. 10 Pts. Mon, Oct 13.
Right after the mid term, I want to divide the class into three-person
teams. I'll base this partly on your cumulative scores (grouping
people with similar scores together).
So I'd now like you to write a preliminary specification of a
game you would like to design by using the Pop framework as a starting
point. (S1 2 pts) Describe the concept theme and overall idea
of the game, (S2 2 pts) Include one or more sketches of the play
screens, (S3 2 pts) Explain how the controls will work (S4 2 pts)
Descibe the behavior of the critters and the game, how the play
goes, how the levels fit together. (along with a brief User's Guide
which specifies Menu controls, toolbar buttons, cursor tools, and
scoring. Also (S5 2 pts) make a UML of the classes you plan to use.
This is similar to what you did in Assignment 1, but by now, you
should have a better insight into the kinds of thigns that are practical
do to with our framework. This proposal will serve as a starting
point for discussions with your teammates.
In picking the teams, I will try and take into account your preference
regarding the kind of project.
Also if you have a friend in class you are eager to work with,
mention this in the specification proposal as well --- but put this
request on a separate sheet of paper.
Late one class -5, late two classes not accepted.
Midterm. Wed, Oct 15. 60 Pts.
Midterm will be a written test on Chapters 1 - 9. Review in class
on Mon, Oct 13.
Study the lettered A, B, C, etc. Review questions at the
end of each chapter. Any one of these could be a question on the
Some of the following exercises might possibly appear on the test
4.1, 4.2, 4.3, 4.4, 4.6
5.1, 5.2, 5.4, 5.6, 5.7
7.5, 7.6, 7.8, also a cForceAvoidWall to avoid the walls of the
9.3, 9.4, 9.10
Group Assignment 1. Spec, UML, Powerpoint. 10 Pts. Mon, Oct 20.
Write a specificaiton and requirement for the project that your
group has agreed to do.
Include your concept, a drawing of a game screen, a map of the
game world, a description of controls and how the game is played,
extra features to be added. Also provide a UML describing the classes
you will use, and listing their main methods.
Present all this as (a) Powerpoint slides for the class and (b)
a printed document you hand in to the professor.
-5 if any part (spec, UML, or powerpoint) is late.
Group Assignment 2. Alpha. 10 Pts. Wed, November 5.
Alpha release of your program. Should be PLAYABLE. Don't
lose sight of this by focusing too much on graphics. Provide
executable, buildable source code, printed "users's guide",
and timeline plan for the rest of the semester. Demo in class.
Group Assignment 3. Beta. 15 Pts. Mon, November 24.
Beta release of your program. Should function with all intended
features in place. Provide executable, buildable source code,
printed help file and online *.HLP file. Demo in class.
Group Assignment 4. 45 Pts Group plus 15 Pts Individual.
Sect 1: Mon, Dec 15, 12:15 and Sect 2: Wed, Dec 17, 2:45
Final release and demo.
Short test to clarify amount of individual project contribution.