Gridrunner ---------- by Soren Johnson and Julie Chin ------------------------------------ BEAUTY SHOT DESCRIPTION (beauty.rgb) ------------------------------------ The Blue Player tries to cut off the Red Player, but watch out for that wall! GridRunner is a 3-D update of TRON's classic light cycles game. The game can be played by up to four users over a network. Further, the AI provides a worthy opponent in single-player mode. As the game progresses, the cycles go faster and faster, and the tails get longer and longer. So watch your back! ------------------- RUNNING GRIDRUNNER: ------------------- Make sure a Makefile and gridrunner.c are in your file. The only additional library we used in addition to the gridrunner.c files was -lmui. Type "make" at the prompt. For a one player game, type "./gridrunner". For a multi-player game, the server should type "./gridrunner #[number of human players]", so if there will be three human players, she should type, "./gridrunner #3". After the server has connected, the clients should connect by typing "./gridrunner @[location of server]", so if the server is at raptor5, all clients should type "./gridrunner @raptor5". There are four players active in a new game and there can be up to four human players in a multi-player game. To run the level editor, go to the "leved" directory, and type in "./leved.iris4d". Levels can be saved as "*.grr" files. The level editor can be made by typing "make". ------------ HOW TO PLAY: ------------ Pull-down menu: --------------- For a single-player game, the following are actions enabled by using the pull-down menu: Start New Game Starts a New Game (see Game Play section) Start New Campaign Starts a New Campaign (see Game Play section) End Game Ends game Pause/Unpause Pauses/Unpauses game Toggle Wire Frame Turns on/off wire frames Toggle Texture Turns on/off texture mapping Open Level Opens a dialog box for user to input a the filename of the desired level. Quit Exits Game The server in a multi-player game has a pull-down menu equipped with the following commands. In a multi-player game, the server is the only player who can start, end, or pause a game and has complete control of the shared game state. The game will continue to play unless the server quits the game. As long as she is connected, whether she is alive or dead, the game will continue. The server in a multi-player game has a pull-down menu equipped with the following commands: Start New Game End Game Pause/Unpause Toggle Wire Frame Toggle Texture Quit The client in a multi-player game has a pull-down menu equipped with the following commands: Toggle Wire Frame Toggle Texture Quit Keystrokes: ----------- j/l = turn left/right i/k = speed up/slow down s/f = look left/right c = switch camera p = pause/unpause ---------- GAME PLAY: ---------- Basics: ------- Starting a new game automatically makes the cycle move forward. Cycles cannot move backwards or diagonally. They may only move forward or make right and left turns. Different camera angles and looking angles allow the player to look at her local environment and see the grid from different viewpoints (see How To Play: Keystrokes:) Each cycle leaves a beam of light where it has travelled. The beam length is constrained, such that when the beam reaches a maximum length, the end farthest away from the cycle disappears. A cycle is terminated when it crashes into a wall, a beam, or another cycle. When an opponent dies, there is an explosion. The player will also recieve a notice on her screen telling her which player has died. Running a New Game: ------------------- In single player mode, the game level can be changed by opening a new level. In this mode, the player can choose the particular levels she wants to play as long as they are included in the same file as the executable. In multi-player mode, the server starts a game for herself and the clients simultaneously. Running a New Campaign: ----------------------- A campaign can only be played in single player mode. The player begins at Level One. For every level that the player beats the computer, she may progress to the next level by hitting 'n' on the keyboard. Each level is different, represented by different level layouts and different texture mappings applied to the wheels and the walls. Other parameters which change as a player moves to the next level are the length of the cycle's "tail" or beam and the speed of the cycle. In other words, progressing to the next level increases the tail length and the speed of the cycle. --------------------- OPTIONAL ASSIGNMENTS: --------------------- Multi-Player: ------------- The multi-player code was jump-started using some socket code provided by Szymon. Once the sockets were established between the server and up to 3 clients, a messaging system was used to ensure that the game was synchronized. After each update, the clients send all user input (turn left/right; speed up/slow down) to the server. Once the server received the information, it processed the new positions of all the players and any other relevant events. Then, the server communicated the new display information to the clients. At this point, the server and the clients would update their displays, and the process would begin again. (A specific "FINISH" message was used to ensure that no two steps in the process overlapped.) AI: --- The AI employs probabilistic reasoning to determine whether to turn left, turn right, speed up, or slow down. The weights include the following factors: recent number of left or right turns, distance to the human, speed of the human, obstacles to the front, left, and/or right, current speed, location on the grid (near the center vs. near the edges), and whether in a "tunnel" (close obstacles to the left and right). Further, the weights are used differently when the AI makes a "random" turn instead of a turn to avoid an obstacle. Finally, the (up to) three different AI opponents have different personalities which control how they play. The "factors" involved are preferred speed and frequency of turns. Control Panel: -------------- The control panel consists of a compass, a speed bar, and a map. The compass points in the direction the player's cycle is facing. The speed bar is a graphical representation of the players speed (i.e. twice as fast appears twice as high). The map is a two-dimensional representation of the grid world. It draws the level walls, the cycles, and the beams of the cycles that currently exist. The control panel was implemented after a call to glOrtho. Lighting was turned off so color had an effect. Level Editor: ------------- The level editor is a stand-alone application that loads and saves files. Loading and saving prompts a dialog box to appear that prompts the user for a file name. Each level consists of a 32 by 32 square grid. The cycles cannot be moved. Their respective positions and directions are indicated by colored squares (showing position), with black arrows (showing direction). There are two drawing tools: a stroke mode and a detail mode. "Stroke" mode allows for the user to draw freely by covering more than one square per mouse click. "Detail" mode allows the user to modify the screen one square at a time. Clicking on an empty square adds a wall. Clicking on a walled square makes it empty. The user may not draw over the cycle icons located in each corner of the grid. A "Clear" button is also provided which enables the user to clear the screen. The level editor was coded using xsupport. Frustum Culling --------------- The culling is fairly straightforward. Basically, everything behind the viewpoint (including walls, beams, and the cycles) is not rendered. Collistion Detection -------------------- The collision detection uses a two-dimensional grid to determine if a cycle has collided with a wall or beam. Basically, every square in the playing area is cut up into a 10x10 sub-grid, and each location in the overall grid contains a 1 (for occupied) or a 0 (for empty). The level walls are added to the grid at the beginning, and when beams are created (or removed), they are also added (or erased) from the grid. So, in order to detect collisions, the program simply checks to see if the player's locations on the grid contain any 1's. (note: the player is larger than a 1x1 square, so multiple locations need to be checked...) A Note on Lighting ------------------ Each one of the cycles contains a "headlight" which project a cone of light in the direction the cycle is travelling. The lights have a GL_SPOT_CUTOFF of 30 degrees. (so they project an arc of 60 degrees total) Further, there is a small amount of global ambient lighting and two weak directional lights (one pointing nortwest and the other pointing southeast), which ensure that all parts of the scene will be visible (although still fairly dark). --------------------------------- HOW WE OBTAINED OUR GAME CONTENT: --------------------------------- Our game reads in a bunch of pre-specified textures available for texture mapping through a built-in .ppm reader. The textures themselves were drawn using an earlier cs248 assignment "paint", saved as .ppms and imported into the gridrunner program. Our cycles were designed by the coders as rotating wheels that turn realistically as the players traverse the grid world. When texture mapping is turned on, the cycles are texture mapped. When it is turned off, the cycles are color-coded rotating disks. ---------------- ACKNOWLEDGMENTS: ---------------- Thanks to Mark Kilgard for making his demofont applications and his bitmap_output function. Thanks to Dave Koller for pointing us in the right direction (to Mark Kilgard). Thanks to Chase Garfunkel and Apostolos Lerios for their inspiring ppm.c code example for the insight on how to read a .ppm file. Thanks to Szymon Rusinkiewicz for providing socket starter code.