Rudy Rucker's
CS 134 Computer Game Design and Implementation

CS 134 Green Sheet, Fall, 2003
Website: www.cs.sjsu.edu/faculty/rucker/cs134.htm

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 Pop framework.

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 games.

The required texts and software for the course are:

1. Rudy Rucker, Software Engineering and Computer Games, (Addison Wesley), 2002.
2. 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 possible. 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:
http://fly.cc.fer.hr/~unreal/theredbook/about.html

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 projects.

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 CS 130.
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 C++. 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.

Calendar

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 to see?

Individual Assignment 2. 20 Pts. Wed, Sept 17.

Hand in the Space Invaders program as discussed in class and in the book.

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 for
certain values. You can at the same time change the backgroudn bitmap with a call to, like,
setBackgroundBitmap(IDB_LEVEL2);

(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 their behavior.

========

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)
{
     cGame::initializeView(pview); //Always call the baseclass method.
     pview->setUseBackgroundBitmap(TRUE); //Default is FALSE
     pview->setGraphicsClass(RUNTIME_CLASS(cGraphicsOpenGL));
     pview->pviewpointcritter()->setListener(new cListenerViewerRide());
}

(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
setSprite(pgame()->randomSprite(cGame::ST_SPHERES));
setSprite(pgame()->randomSprite(cGame::ST_MESHSKIN)); or
setSprite(new cSpriteQuakeBigNose());

==========

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;
setTangent(newdir);

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.

pop31_8.zip.

Make Dambuilder into a 1st Person 3D Racing game as discussed in class.

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*/
return cVector::ZEROVECTOR

Actually the cForceWaypoint::force on p. 163 is too non-physical. Instead use this kind of code, taken from cForceObjectSeek::force

cVector pursueforcevector =
    (pcritter->maxspeed()*pcritter->directionTo(_pnode)) - pcritter->velocity();
pursueforcevector.setMagnitude(_intensity);
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. */
return pursueforcevector;

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 forces.
(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 the gameairhockey.cpp).
(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) Ramps.
(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 test.

Some of the following exercises might possibly appear on the test as well.
3.8
4.1, 4.2, 4.3, 4.4, 4.6
5.1, 5.2, 5.4, 5.6, 5.7
6.2
7.5, 7.6, 7.8, also a cForceAvoidWall to avoid the walls of the _movebox.
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.