DRIVE!! A Three-Dimensional Multiple User Racing Simulation Brent Wiethoff *---------------------------------------------------* Table of Contents: I. The foreword A. Author origin and background B. Program origin C. Theory and mathematic origin 1. Accelerator theory 2. 3D theory 3. Rotation theory D. Program statistics II. The introduction A. Simple explanation B. Technical commentary III. The game A. Simple explanation 1. Rules of the game 2. Controls 3. On-screen identifiers B. Technical commentary 1. Sounds 2. Graphics 3. Movements IV. The options menu A. Simple explanation B. Technical commentary V. The conclusion A. Simple explanation B. Technical commentary *---------------------------------------------------* I-A. The foreword--Author origin and background Brent Wiethoff, at the time of the production of this program, was 17 years old, a senior at Abilene High School in Texas, and a third year computer science student. His first year, in Pascal, he quickly finished his classwork and began to work on his own ideas, most of which were graphically oriented. Brent entered the regional Science Fair with a project entitled "Graphics Entertainment," which was in essence an expanded version of the old game "Pong." His game, "Mortal Pongbat" (the name of which was suggested to him jokingly by an acquaintance), won the Sweepstakes award for the Fair and sent him to the state level in Austin. The next year, Mr. Wiethoff began working in Turbo C++, version, 1.0 (the only version the school offered), and at his own pace, without the help of his teacher, he developed some mathematical ideas which allowed him to make marvelous graphical programs. Producing 3D on a screen came that year, in November of 1996, and in March he again entered the Science Fair with a far more practical idea: the three-dimensional spatial editor. Although it had dozens of bugs and was fairly difficult to operate, the judges claimed it was superior and Brent again won Sweepstakes award and traveled that year to Kentucky for the international level. The next fall, he worked with some more advanced theories of graphical representation, including gravity and plasma. In late December, Brent began this program--another game. Science Fair turned out to be a big loss for him, though; he lost sorely. Nevertheless, this program was produced from it. I-B. The foreword--Program origin A colleague of Brent, Bryan Stone, asked Brent for help in October of 1997 on building a racecar game in Pascal. They worked together for a few weeks and Brent passed on some of his mathematical ideas to Stone, including 3D. Stone, however, went to make the game, and went about it all wrong. In an effort to help, Wiethoff began this program. I-C-1. The foreword--Theory--Accelerator theory The accelerator theory as used in this program, is based on two variables. When user input is taken, the first variable (call it s) is changed by one unit; then the second variable (x) changes by s units. As a result, if x is thought of as position and s speed, the decrementation of s is related to a deceleration of the object. Incrementation, alernately, accelerates the object. I-C-2. The foreword--Theory--3D theory Three-dimensional graphics becomes highly complex as one point has five coordinates instead of just two: three for the virtual space (x, y, z) and two for the screen translation (xscreen, yscreen). The real problem with 3D comes with the actual process of translation; coming up with the screen points is an elusive thing. By way of similar triangles, these coordinates can be calculated with extreme ease, and the process has been packed into an independent procedure which returns the screen values. This in turn makes 3D translation to 2D a one-line problem within the main code. I-C-3. The foreword--Theory--Rotation theory Trigonometry is the most important concept of all Cartesian rotation. The problem becomes more complicated, though, for some [unknown] reason, when trigonometric functions are applied to computer logic: some constant numeric proportions are required which should not be needed. However, the end result is the same; the process is packed into another independent procedure and again simplifies the code of the main procedure. I-D. The foreword--Program statistics Approximate time = 85 days Length = 1417 lines 10 interlocking procedures and functions > 700 variables Approximate executable size = 105 kB *---------------------------------------------------* II-A. The introduction--Simple explanation The beginning sequence displays what most intro- ductory screen might: the title of the program, DRIVE!!, a brief explanation of the game, and a small list of the more attractive (and eloquently stated) features of the game. II-B. The introduction--Technical commentary The background image is a real set of points which have been predefined with the procedure build_car(). This object spins about the Y-axis with the function threeD_rotate() and moves slowly up along the environment. Notice that as the image moves up, it appears to be going above the screen, not merely moving up on the screen. The title is drawn using setlinestyle() with a thicker line, under a preset size and location defined in the call to drive(). The features scroll out, one with every passing of the car in the background. When all have been displayed for at least two passes, all are erased and the scrolling begins again. Alternating colors are very simply done, but for little technical merit. *---------------------------------------------------* III-A-1. The game--Simple explanation--Rules DRIVE!! is just like any other racing simulator in its rules, with perhaps a few exceptions. The object of the game is to race around the track, staying on the track as much as possible, and beat the other player to 5 laps. Going too far off the track will result in bouncing off an invisible wall which is semi-difficult to evade. The cars will run into each other and bounce back; the race gets more difficult if the two cars are side by side. III-A-2. The game--Simple explanation--Controls The controls are fairly simple: the first player (on the top, the red car) uses the arrow keys on the keyboard for their respective movements; The second player (on the bottom, the green car) uses the keys "E", "S", "D", and "F" which correspond to arrow keys used by the first player. Pressing UP_ARROW causes the first player's speed to be incremented by one unit; DOWN_ARROW results in decrementation of the speed of player one. By pressing LEFT_ARROW the first player begins to spin to the left: his rotational speed shifts left one unit. RIGHT_ARROW causes the opposite. The keys "E", "D", "S", and "F" repsectively control player two's movement. The F1 key is used to go into the options menu, the F2 key toggles the music, the "[" key decreases the delay of the program and "]" increases the delay--these two are used to make compensations for the speed of the computer being used. The ESC key will result in immediate exit to the concluding seqence. III-A-3. The game--Simple explanation--On-screen The two divisions of the screen depict the two players (#1 on top, #2 on bottom) and their respective views: the track is gray and the cars are red and green. The "LAP" and "PLACE" signify where each player is in relation to the track and in relation to the other player. III-B-1. The game--Technical commentary--Music Music is a problem: it was coded for a low-profile program with little else going on. As it was appended to the existing program, it slowed down so much that it seems at times only to be random sounds and annoying noises. Also, the sound made by the cars running into each other or the outer wall is independent of the delay: it sounds long for a short delay and vice versa. III-B-2. The game--Technical commentary--Graphics As the car moves, the coordinates of the track seem to jump up into the air. This has been addressed in every feasible way and still continues to take place. The delay accomodation help with the skippiness of the graphics, but at high speeds and high rates of rotation, jumping is inevitable. III-B-3. The game--Technical commentary--Movements The most amazing feat of the program is perhaps its ability to show both players on each view; second is the "solid" nature of the cars. Because of the system used to move the cars along the track, the other player's coordinates are independent of one another. Probably the process as a whole is less efficient than some others, but it is the simplest for all cases. in short, trigonometry and simple algebra allow the player to see their opponent. The actual code which determines if the cars are occupying the same space is about 15 lines long, the most lengthy conditional statement of the entire program. Also, leaving the track too far behind in any direction will result in bouncing off of an invisible wall. The problem is, the velocity doesn't invert: only the degree of rotation. The cause if this is currently unknown. *---------------------------------------------------* IV-A. The options menu--Simple explanation An options menu certainly adds some interest to the game; to be able to change certain aspects of the program is exciting. To access the menu while playing, press F1. When the menu comes up, several numbers will be displayed: The level number, which can be changed by pressing "L", using the arrow keys to change, and the ENTER key to confirm; the player mode, which is fixed at 2 for this program; the delay, which is not dynamic from the menu itself but from game play; the music toggle key, F2; the player controls (see III-A-2); and the car dimensions, which may be altered by pressing "C", navigating through the numbers (that range from 10 to 200) with the arrow keys, and pressing ENTER to confirm the change. Note that either a level change or a car dimension change will result in a restarting of the selected level. IV-B. The options menu--Technical commentary Extremely little is done technically for the menu; The most complicated part is that there are many embedded getch() loops within the main procedure. Also, if the level number is changed, the screen coordinates are not updated immediately--the user will see a series of lines on the screen left over from the previous level which change as the player turns: it fixes itself. The car dimensions are set to a certain default value, and the test for determining if the cars have run into each other works best for these values. The parameters will be changed with dimensions, however, and in theory should work in any arrangement of length, width, and height. *---------------------------------------------------* V-A. The conclusion--Simple explanation The last sequence shows the title of the game as well as the winner of the race (if there is one) and a car in the background, spinning. The colors of the conclusion are the same of the player who won the race. Any key pressed will take the user to another screen where the option is given to play again or quit. V-B. The conclusion--Technical commentary Spinning a car in the background is not complicated due to the procedure threeD_rotate(), but making it stay in the background is an artistic chalenge. Quite simply, it is drawn first and the other objects, text in this case, are drawn over it. *---------------------------------------------------* Written by Brent Wiethoff