- Paul Makl
- Judd Cohen
'run python data_compiler.py'
For our final project, we are going to be working in webGL on a game that would combine both pong and breakout. The game would be setup similar to pong, with two players with paddles on opposing sides of the field. Each player would start with a ball, which could be bounced off the paddles and onto the blocks to break them. The first player to make a ball pass over them wins. Our project would be functionally 2d, but it would 'look' 3d. Light would be cast on the paddles and the ball which would create shadows on the playing field.
Paul Makl Judd Cohen Graphics Final Project Write Up
For our final project, we created Breakout Clash, a game that mixes pong and breakout. Both players have control of a paddle, one on the left side of the screen and the other on the right. At the start of the game, two balls are placed in front of the players’ paddles, and they begin to move. Players then bounce them off their own paddle in an attempt to prevent a ball from ever passing their own padde. A player’s score increases whenever one of the two balls on the arena passes by their opponent’s paddle. The game also features camera controls to change the camera that is viewing the playing field. The game is meant to be played by two players, each using the same computer.
This project is a mashup of some old concepts that we learned throughout CS315 and others that we never got to implement. The newest concepts were those relating to having 3D objects interacting in a real time environment, working in webGL, and user interface design. The older concepts we touch on are related to Phong shading and rendering 3D models from files.
During the game, the balls bounce freely around the field, unless they collide with a paddle, a block, or another ball. Unlike in our ray tracing program, we do not have that much time to calculate collisions between objects, so our collision detection code had to run fast. Our first collision detection algorithm went through every item in the game, and determined if it intersected any other item in the game, and then changed the direction of the appropriate object depending on the type of collision. This was incredibly slow and did redundant work. Since the bricks in the middle of the course never move, and the paddles are locked into only vertical movement, these objects would never collide in the scene. In fact, we only care if one of the two balls has collided with another object in the scene. This means we only had to check collisions between both of the balls and every object in the scene.
While we attempted to stay as true to the laws of physics possible, we had to take some liberties to make the game more enjoyable. When the game starts, both balls are moving horizontally and bounce back and forth between the wall of blocks in front of the player and player’s paddle. Since momentum must be conserved, there is no force that could push the ball up or down. Depending on how close to the edge of the paddle the ball collides with, it will be tilted more in that direction. The player can also add some “spin” to the ball by moving in a certain direction as the ball comes towards their paddle.
Working in a new environment is usually challenging, but implementing projects in webGL was MUCH easier than using GLES and the android virtual machine. The time to go from making a change to seeing your final idea implemented is much faster than working with webGL. You are given free form to organize your classes however you want and render the scenes onto an HTML5 canvas in whatever fashion you desire. We created a GameEngine class to handle rendering objects to the screen, handling camera movement, and working with webGL code. We also created a Breakout class to handle game logic such as collisions and scoring. The user interface is meant to be as simple as possible. A prominent menu is displayed for players as they reach they load the game, giving them time to situate themselves to have two people player on the same computer. Controls are displayed in an easily readable way, that can also be understood quickly, and skipped easily by returning players. Both players are also given an overview of the playing arena before the game starts. This is so both players are not surprised when they start playing the game. While both players play the game, controls for each player are separated on the keyboard so that neither player can accidently hit the other’s hands while both using the keyboard. Camera controls are placed in the center of the keyboard, so that neither player accidently hits them while the game is Menu items are clearly displayed at the bottom of the screen during the game. The camera angle can be adjusted before the game starts, so an optimal viewing angle can be reached. Finally, depending on the user’s screen size, the models on screen will scale according to the users browser window size. All of these changes are to make getting into the game, and playing it as easy as possible. Some of the older ideas we implemented were related to Phong Shading. A simple vertex and fragment shader provide lighting to show off the specular highlights on the paddles. We kept lighting simple for this project, given our new environment and other obstacles that we had to overcome. We also found that implementing other fancy lighting effects slowed down the game on some browsers. A lot of work went into making the backend of the project as robust as possible. A python script allowed us to compile all our model files together and put them into global strings that could be accessed by our javascript files to render the objects to the screen. Breakout Clash is a smattering of what we learned this semester, applied to a more interactive environment. The project focused much more on making optimized code, given that javascript running in a browser is generally slower than an OpenGLES program on the android platform.