Java中的吃豆人迷宫

Question

So I'm building the pacman game in Java to teach myself game programming.

I have the basic game window with the pacman sprite and the ghost sprites drawn, the pacman moves with the arrow keys, doesn't move beyond the walls of the window, etc. Now I'm trying to build the maze, as in this picture:

Without giving me the direct/complete solution to this, can someone guide me as to how this can be built? I'm talking only about the boundaries and the pipes('T' marks) here which you can't go through and you have to go around. Not the dots which the pacman eats yet.

Here are my questions:

1) What's the most efficient algorithm/method for creating this maze? Will it have to be drawn each time the paint() method is called or is there a way to draw it only at the start of the game and never again?

2) How will this actually be drawn to the screen? I assume the fillRect() will be used?

3) Any hints on collision detection (so the pacman/ghosts can't go through the walls) would be helpful.

4) Any hints on how the vacant space between the pipes will be calculated so the dots can be filled between them will also be very helpful.

Thanks

Answer 1

I wouldn't do it that way.

I'd draw the graphical map and then create a 2D data array which represents the map. The data map would be responsible for determining collisions, eating dots, where candy is and where the ghosts are. Once all the logic for everything is handled just use the 2D array to display everything in their proper pixel coordinates over the graphical map.

For example the user is pressing the left key. First you determine that pacman is at element 3, 3. Element 3, 2 contains information denoting a wall so you can implement the code to make him ignore the command.

EDIT:

Each element would represent about where a dot could be. For example:

No, looking at the board I would say the array would look something like this.

d,d,d,d,d,d,d,d,d,d,d,d,w,w,d,d,d,d,d,d,d,d,d,d,d,d
d,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,d
p,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,p    
d,w,w,w,w,d,w,w,w,w,w,d,w,w,d,w,w,w,w,w,d,w,w,w,w,d    
d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d,d

And so on. You might want to pick a more flexible data structure than just characters however since some areas need to contain a bunch of different information. IE even though the ghost spawning area is blank, pacman isn't allowed in there. The movement of the ghosts and pacman is different for the side escapes, the candy spawn point is a blank spot but if you want to remain flexible you'll want to denote where this is on a per map basis.

Another thing you'll want to remember is that pacman and the ghosts are often inbetween points so containing information that represents a percentage of a space they're taking up between 1,2 and 1,3 is important for collision detection as well as determining when you want to remove dots, powerups and candy from the board.

Answer 2

Here's a hint for you:

alt text http://www.freeimagehosting.net/uploads/66e4131f59.jpg

This hint, properly used, will allow you to handle rendering and collision detection, and will also allow you to represent the maze in a compact fashion.

Answer 3

1. You can paint the map into a BufferedImage and just drawImage that on every paint(). You'll get quite reasonable performance this way.

2. If you are happy with the walls being solid, you can draw each square wall block with fillRect. If you wish to get the same look as in the picture, you need to figure how to draw the lines in the right way and use arcs for corners.

3. The Pacman game map is made of squares and Pacman and the ghosts always move from one square to the neighbouring square in an animated step (ie you press right, the pacman moves one square to the right). That means that collision detection is easy: simply don't allow moves to squares that are not empty.

4. I do not understand what you are trying to ask here.

Answer 4

1) Just to give my advice on redrawing. Something that you can do if you find redrawing the entire image is slow, is determine only the elements that have changed on the screen and redraw those. An approach for this would be the following: Determine the sprites that have moved. Determine (approximate) a rectangle around those sprites. Redraw those rectangles only. This way you are only refreshing parts of the screen and not the whole screen. This should result in an increase in performance over redrawing the entire screen.

The other answers have been reasonable for the other questions you have asked.