Contents  The Game  Threads  Keyboard and Mouse  Double Buffering  Coding the Game  Printable version  Discuss this article  in the forums The Series  The Basics  Making a  Simple Game  The Power of Arrays

Coding the Game

So now that we have a basic idea of how to use threads, double buffering, and the mouse and keyboard we can start working on an air hockey game. I will cover what needs to be coded and how we could go about doing this here and you can look at the sample code which is available on my web site (www.cpsc.ucalgary.ca/~kinga). The code may look kind of confusing, but in the next article I will talk about how to use additional class and methods to make our code look more organized and easier to read.

First off we are going to need to accept input so that the players can move their paddles up and down. The easiest way to accomplish this is going to be to set up a keyDown function with 4 if statements that test the key pressed against the up and down keys for the two players. These if statements will end up changing the value in a variable holding the y position of the appropriate paddle. This y position will be used for the drawing of the paddle and for collision tests to ensure that the paddle doesn’t go off the edge of the board.

If you want to expand the game a bit an extra that you could could add in here would be allowing the paddles to move left and right as well as up and down. This means that you will have to add some extra collision detection code in to check the paddles against the edges of the board and the other paddle. You could also try adding in some mouse support for your game. This could include the ability to use the mouse to move one of the paddles around or you could use the mouse to create some sort of menu system.

The third step that we need to cover is the output on the screen. Now you are probably saying what happened to step number two, but don’t worry it is coming shortly. The output that we need for the screen is very, very simple. All we really need are two filled rectangles for the paddles, an oval for the puck, and some text to display the score. If we wanted to we could make things more complicated by having a nice background for the game to be played on (an image or something dynamic like a starfield), having a puck whose color is constantly changing, or even obstacles on the board (this could get complicated so don’t start off trying to do this).

The second phase which I talked about at the very beginning is the processing stage. So what needs to be processed in our game and what variables will we most likely need? The goal of the game is to have a puck bouncing back and forth on the board and it should bounce off the walls and the paddles. First off we are going to need to have the coordinates of the puck and the two paddles. This means that we will need to have an integer x,y value for each of them. Next we are going to need to have a speed value for the puck. The speed values will be integers which represent the change in the x and y postion of the puck in each time step. With this much information we can move the puck in our run method and test the positions of the puck and paddles to see if there is a collision.

This brings up a good point: how do we detect collisions. There are a lot of complicated formulas for checking collision, but there are some simple methods that will be sufficient for us.

Paddle-Board Collision

For our purposes I’m going to assume that the board is the size of the entire applet area. This means that the extents of the board are from 0 to size().width and 0 to size().height. You will notice that here that I have used size().width and size().height here to represent the maximum height and width of the applet space. If you use these exactly as I have written here in your programs they will provide you with the values that you desire. Testing the paddle for collision with the edge of the board is as simple as having if statements to check whether or not the y value of the paddle is greater than the maximum height or less then zero. If you allow the paddle to move left and right then you can check to see if the x value of the paddle is less then 0 or greater than the maximum width. If we discover that there is a collision or we have gone over the edge of the board then all we have to do is move the paddle back onto the board (eg. 0 or max. height - paddle size).

Paddle-Paddle Collision

We only need to worry about paddle to paddle collision if we allow the user to move his paddle to the left and right. You could even avoid having to worry about this type of collision if you said that a player couldn’t move his paddle past the center of the board. Another option would be to let the paddles simply pass through each other with no collision at all. I would recommend one of the above options since the number of times the two paddles are going to get close enough for a collision is almost zero. If you are still interested in persuing this type of collision then I would recommend that you follow the process that I will discuss in a moment for paddle and puck collisions. This method involves taking the x and y position of the paddle and comparing it against the four edges of the other paddle to see if it is inside the other paddle. If a collision has occurred then we want to move it out of collision.

Paddle-Puck Collision

Checking for collisions between a paddle and the puck isn’t easy, but it is a very important part of the game. You could try to get fancy here, but I recommend that you keep it simple. I believe that the easiest way to check for a collision is to check the x and y coordinates of the puck against the four edges of the paddle. The four edges of the paddle are: paddlex, paddlex + paddle_width, paddley, and paddley + paddle_height. With this knowledge in hand it is a simple matter of creating an if statement for each paddle which will consist of four parts testing the four aforementioned edges against the x and y of the puck to see if the puck is inside the paddle. If it is unclear what is going on I would recommend drawing a little diagram of what the situation looks like and this should make things easier for you. Once we have discovered that a collision has occurred then we need to come up with some means of resolving the collision. The best way to do this is to take the speed of the puck in the x direction and negate it. By negating it we get very believable bouncing of the puck off of the paddle. You could also try to add in the possibility of the puck bouncing off the bottom part of the paddle so the x would stay the same, but the y would change. While this might initially sound like a great thing to do it doesn’t necessarily add a lot to the game so try it out and decide for yourself whether it is worth the extra effort.

One problem that you might come across is a shimmy. This is where the puck collides repeatedly with the paddle and ends up shimmying up or down the paddle before it finally breaks away. This is something that you want to avoid at all cost because it makes your game seem unprofessional and incomplete. A possible solution for this problem is to check the speed of the puck in the x direction. If the puck is coming towards the paddle then it can be checked for a collision. If on the otherhand it is going away from the paddle then we can ignore any collisions that we might think we have.

Puck-Board Collision

Testing for collisions between the puck and the edge of the board is identical to the test that we performed when testing for collisions between the paddles and the board. The only tricky part that we have to watch out for here is that we must check the x and y values of the puck against the extents of the board. Again to resolve this particular type of collision all we have to do is negate the x or y speed of the puck depending on the edge of the board that we hit.

Puck-Goal Collision

This is going to be the same process as what we had to carry out for the paddle to board collision test except in this case we want to check the puck against a limited part of the board. As a starting point lets assume that the goal area consists of the entire left and right hand parts of the board. This means that we can check the x value of the puck against 0 and the maximum width of the board. If we register a collision here then we must increase the score for the appropriate player and put the puck back at the center of the board.

The fourth and final phase is to loop. The loop as we discussed before is accomplished by using threads and the run method. If you are unsure about this you can either refer back to the threads section or check out the sample code for the air hockey game which is available on my web site.

You are now well on the way to creating a great air hockey game. Once you have a basic game up and running you should start playing around and trying to make additions and alterations to your game. Once you have finished your game I would appreciate it if you would send me a copy of your code (kinga@cpsc.ucalgary.ca) and your applet so I can post it on my web page for others to see and learn from. For now my web site is www.cpsc.ucalgary.ca/~kinga, but I’m in need of a new location so when I find one I will inform you of the new address.

Coming Soon!!!

Well we covered a lot of ground in this article. Hopefully you have you learned quite a bit and are starting to get ideas about how you could take what you have learned so far and make a game of your own. In part 3 I am going to cover using the AWT for buttons, checkboxes, etc., some basic points on classes and code organization, and neural networks. Then in part 4 we will go into arrays and how they can be used for games like tetris, nibbles, and anything else that can be put on a grid. If you want to check out some sample java applets you can come to my web page, www.cpsc.ucalgary.ca/~kinga, which will be operational until the end of the summer, but then I will be in search of a new web space because I’m graduating from university. If you have any questions or comments feel free to email me at kinga@cpsc.ucalgary.ca.