This is almost a game, though I haven’t tested it. May need to tweak for playbility.
It’s exceedingly hard to maneuver the player. Can you think of a better listener?
Note that Ride the Player view is probably too confusing.
I’d like to see more work on this as a starting point. I’d like to see the asteroids doing flocking motion, for instance.
I think this isn’t playable now, I seem to always lose really fast. Need to tweak the params. Maybe make the world longer. Would be nice not to have the props bunched together so tightly at startup. Would be nice to have some enemies. We need a visual clue to indicate when we successfully “eat” one of the coins on the floor.
Make this a little more of a game. Maybe put in some blocks to hop over. Give the enemies more intersting behavior. Have some power ups.
Is tehre a way to make the world ten times as long without having to load an enormous bitmap? Could we trade in bitmaps as we move along? Also in an “enormously long” world we woudln’t want to have to be computing critters in that whole big world.
Do this either as (a) having (perhaps imperceptible) transitions between levels as you move along, each level with a relatively small size and number of critters. Or (b) give critters a “zone” that they are in and only update and draw the critters that are in the same zone as the player.
I’d like to finish this game as described in the text. The idea is that you want to arrange the dams so that the water flows down at a slow but steady rate. Your score for each object that reaches the bottom relates to how old it is (how long it took). But there has to be a penalty for over-damming. Perahps the objects melt away after a cerain time. Or, perhaps there could be a way to have a dam burst if too many critters are right above it?
This is just a stub. We need to arrange (more) walls to make a closed in track, and to put in which a waypoint force leads the racers. See Assignment 3 in https://www.rudyrucker.com/oldhomepage/cs134.htm. Note that you should now use the cGameRacer as the stub, and not cGameDambuilder. I’d like to finish this one and have it be in the framework.
This needs to be a game, at present it isn’t. Could we make it like DigDug? Could we have the critters leave trails? Also should we be thinking of a cCritterComposite class to hold a bunch of critter together?
cCritterComposite would be good for a boxing game in which a critter is two spheres: a Body and a Fist, visually connected by a spline line.
Ceiling is maybe too garish.
There’s no real game yet. I had in mind something like a side-scroller, where you have to deal with each creature that passes. Difference in 3D is of coruse that thigns can go right past you. Maybe each enemy should have an attractive force that draws him to the player.
Bullets don’t show up well, also they probably shoudn’t bounce off walls.
The Player sprite is too bland and unidirectional. Draw the gun?
More furniture? Powerups? Can I make this a GAME?
Also can I make this much bigger, as dicussed in Ballworld.
Also can I link together rooms at various orientations like in a castle.
· Figure out an automated testing procedure. At the minimum try and imagine a File|Test menu selection which, when invoked, will step the game through a series of menu calls, basically emulating what you do when you make a series of menu selections, pausing for a bit between each call. I'd like to see something like a cTestSequence class that I could initialize with a bunch of menu calls and with a _waitbetweencalls parameter. Even better, I'd like to have cTestSequence.record method that coudl record a series of keystrokes or menu selections. This would probably be a Windows-programmer problem. To use this, you'd create a nice cTestSequence, hard code it into the framework and then call File|Test before posting each new release, and then watch the screens go by and see if you see anything weird. More complex would be to have the probram in some sense "watch the screens" itself, though this probably isn't practical. An intermediate idea would be to the have the program check the updates per second for each game in various modes save these numbers into a speedprofile?.txt file that I (or the program itself) could compare to a prexisting speedprofile?.file that I found on my machine. I'm interestd in this issue because I am setting up a CVS tree so the students can alter the Pop frameowrk, and we would really want to have a standard test to notice in a timely manner if somehting gets broken.
· Integrate sprites for the types torus, cone, teapot, regular polyhedra, and so on, as demoed in GameStub3D. I already have the code for this in the Molecules demo from CS 116A, Fall, 2003.
· Get rid of the sound lag by integrating DirectSound, see the sample code for this on the computergames website.
· Add a cMaterial class cColorStyle, a cLight class, and make a real cLightingModel class.
· Design some good classes for handling multiple levels and multiple rooms assembled into a 3D structure. Note that Design Patterns by Gamma et al. uses this an example they analyze.
· At present, our _border is always a cRealBox with a cSpriteTextureBox. What about other world shapes like spheres or cylinders? We probably need a basic cWorld class with a cWorldBox child that combines our cRealBox and cSpriteTextureBox.
· Put in a switch to have the game show up with no surrounding window at all.
· Make some nice wrappers for writing OpenGL text onto the screen. (We have OpenGl text implemented, but its interface is funky.)
· Allow two or three players to play head-to-head. Consider using a peer-to-peer rather than client-server model. Think about latency and synchronization issues.
· Create and implement a cGraphicsDirectX class.
· Create a cCritterComposite type to hold several critters. Do a test example of a cBoxer which is a critter made up of a (say) large spherical body and a small spherical fist. User controls the fist, and takes hitpoints when enemy hits his body.
· Extend collisions to work with shapes other than current spheres (cCritter default) and boxes (cWall default). Rethink the collision handling code.
· Implement curved mesh surfaces for the ground.
· Implement dynamically generated texture maps for the walls, such as cellular automata.
· Allow loading *.GIF and *.JPG files for the cSpriteIcon, cSpriteTextureBox, and cSpriteQuake.
There are visible seams between tiles of a tiled bitmap.