   How to code Pacman Map?
  Hey all,I'm writing a pacman clone in C#/XNA.I'm at the point where I have my pacman and my 4 ghosts on a 800x600 screen.  I can control my pacman (he can go wherever he wants on the 800x600 pixel screen) and the ghosts have some simple AI to either chase him or wander.The next step for me is to somehow design the map.  Just like in the original pacman, the ghosts and pacman are supposed to follow some predetermined "invisible" lines.  I'm not sure how to accomplish this...I want to avoid creating corriders that are exactly the same height/width as my pacman/ghost sprites (that seems like an un-clever way to do it).  I'd prefer to somehow come up with a way that the ghosts and pacman won't take a turn that they aren't allowed to take without having to test for collision between the sprite and the wall.Does anyone know the right way to implement this?   
  Are you asking about how to create the map or how to handle pathfinding?A common approach for the map would be to create it using a tile-based approach whereby the map is a 2D grid of tiles. Each tile can be associated with an image for drawing and a boolean attribute stating whether the tile represents a wall or a corridor (and hence whether the player or enemies can move over the tile).For pathfinding you could take a look at the A* algorithm.;Quote:Original post by alphsterI want to avoid creating corriders that are exactly the same height/width as my pacman/ghost sprites (that seems like an un-clever way to do it).  I'd prefer to somehow come up with a way that the ghosts and pacman won't take a turn that they aren't allowed to take without having to test for collision between the sprite and the wall.That's probably not the route you want to take.Is it your intention that players be able to 'wiggle' up and down within a corridor?Remember that there is a difference between what is shown on screen for the game, and the model you use in the game.For Pac-Man clones, you probably want a tile based system, as InsaneBoarder234 pointed out.You can then track it likeOn tile (x,y) entering tile (s,t) at (timestamp)That lets you do quite a few things:* You can easily edit your maps as a text file, or similar easy-to-edit format.* You can decouple rendering from the simulation.*** You can change the timestep for your simulation independently from the rendering.  If it is moving too fast, simply adjust the simulation update frequency.  If it is using too much processor time, adjust the rendering frequency.*** You can render 'as fast as possible', for example, render a frame at 37% between the two timestamps.  That lets your icons move smoothly.  While not very important on Pac-Man where rendering speed is probably not an issue, this will be an important ability as your projects grow in complexity.* You will have easier pathfinding, since your world will be extremely small.* You can more easily debug, generating logs of when each avatar moved between each tile* You can more easily enable network play, assuming you have interest in that kind of thing* You can more easily grow your systemIt is relatively easy to move a tile-based system to a more free-range world. All you need to do is allow decimal points in the player's location.For now, though, you have a few icons that travel from tile to tile, interpolating their position as they go.   ;All about Pacman. (See chapter 4!);Quote:Original post by InsaneBoarder234For pathfinding you could take a look at the A* algorithm.Won't work. Perhaps for 1 of the ghosts, but not the rest.As for the map format, it's really up to you..a 2D array, using numbers to represent edges and open space would be the simplest way, but any number of ways to represent it.   ;Quote:Original post by marius1930Quote:Original post by InsaneBoarder234For pathfinding you could take a look at the A* algorithm.Won't work. Perhaps for 1 of the ghosts, but not the rest.Care to explain why you think it won't work? I know the ghosts have different behaviour but according to the previously linked "Pac-Man Dossier" all four of the ghosts require pathfinding ability. Another article hosted here at gamedev.net says that three of the ghosts require pathfinding and one has random movement - and depending how you implement random movement you may still require pathfinding (e.g. select a random location then use pathfinding to determine the route).   ;  The reason you don't need A* is because the ghosts use different algoritms:From this post:Quote:* Red ghost (Oikake): Input is Pac-Man's location. He doesn't consider which direction Pac-Man is going. He attempts to reduce the distance between himself and Pac-Man. He will turn in the direction that will immediately reduce whichever is GREATER of the horizontal distance or vertical distance between himself and Pac-Man. This usually has him tenaciously following Pac-Man, but will occasionally lead to a "stupid" choice (see illustration below).* Pink ghost (Machibuse): Input is four tiles in front of Pac-Man. Therefore direction Pac-Man is facing as well as actual location of Pac-Man determine Pinky's "target." Pinky attempts to home in on this target using the same logic as the Red ghost uses to home in on Pac-Man. This does indeed effectively "set up an ambush" if Pinky manages to get in front of you. At close range, the direction you face can mean life or death. If you're facing away from Pinky, he will chase you (his "target" is now in front of both you and him). If you face him or turn off to a side, he may turn away from you if that provides a shorter route to the target than running through you. Note that if the space four tiles in front of you is on the other side of a wall, he will go over there in preference to the side you are on.* Blue ghost (Kimagure): Inputs, as mentioned, are the square two tiles in front of Pac-Man, and the location of the Red ghost. (Edited out incorrect information here and replaced with correct information that follows-->) To envision Inky's target, draw a line from the Red ghost to the spot 2 tiles in front of Pac-Man. Now extend that line twice as far in the same direction and draw an "x" where it winds up. Inky wants to reach that "x." The fact that Inky's AI has two inputs instead of one makes his behavior more complex. On a fast-moving playing field with Pac-Man and the red ghost constantly changing position, that "x" can be jumping all over the place and sometimes Inky's behavior seems completely random - but it's not. No wonder his alternate name on the Puck-Man rom is "Stylist"! His regular name, Kimagure ("Whimsy") is also appropriate. It makes sense that the closer the red ghost is to Pac-Man (technically, the closer he is to the spot two spaces in front of Pac-Man), the more predictable Inky's behavior appears. Thanks to JamieVegas and Dav for getting this right the first time. Sorry I temporarily had completely wrong information on here!* Orange ghost (Otoboke): Has two modes, "near" (within 8 tiles of Pac-Man) and "far" (farther away than 8 tiles). In "far" mode, he heads toward Pac-Man using Blinky's logic. This gets him in the same general area of the maze, but then in "near" mode, he has a bizarre change of heart and decides to head for his corner of the maze (lower left island). Unless you happen to be in the lower left region, his about-face will soon take him into "far" mode again, and he will circle back toward your area. If you are in the lower left, he will circle his favorite island indefinitely. He will usually only "chase" you if you happen to be in the path between him and the lower left of the screen. Orange's "far" mode rarely leaves him doubled up on top of Red due to the fact that their home quadrants are on opposite sides of the map and "scatter" mode repeatedly separates them. Plus, red is usually close enough to you that orange will go into "near" mode if he gets close to red.;  As already mentioned, a tile-based method for map representation is the way to go.  I have done a PacMan clone myself, and I created a tileset that represented all the possible wall segments.  Each of these is couple to a specific representation in a text file.  I parse the text file and draw the appropriate tile in the right place.As for collisions, my PacMan can be anywhere, as long as there is no collision.   When PacMan wants to move, I translate his projected X,Y coordinates into the appropriate tile location and check the map to see if there is a wall there.  The maze map is stored in a vector of vectors (2D array).If you want to see how I did it, go here:  http://sourceforge.net/projects/aipac/  You're welcome to use my tileset, too, if you like.  I can't guarantee that the code is perfect, but it might get you started.-Kirk