13

I'm creating a personalized pac-man clone for personal novelty purposes, and I'd like to reproduce the original arcade gameplay as faithfully as possible.

I've read The Pac-Man Dossier, but I don't see anywhere on there exactly how fast pac-man or the ghosts can move.

In several places it is mentioned, "moves at xx% of the base speed", but I don't see anywhere what the base speed is.

Is it based on a number of pixels traveled per frame, or some number of tiles per second?

Improve this question
2
  • The Pac-Man game runs at 60 FPS, so I suppose you could count the frames if need be. Note that Pac-Man, the character, pauses for 1 frame every time he eats a pellet, and for 3 frames when he eats a power pellet.
    – Luck
    Nov 22, 2012 at 6:01
  • 4
    Isn't this more appropriate on game dev?
    – JohnoBoy
    Nov 22, 2012 at 11:41

4 Answers 4

Reset to default
11

Apparently he moves at 11 tiles per second, a tile is made up of an 8 x 8 pixel square. So he travels at 88 pixels per second.

You can find pretty much all of the information you need to find here, but you specifically want slide 48.

Improve this answer
2
  • 1
    Hey thanks, I'll try that and see if it feels right. I'm slightly dubious of that presentation as it seems to contain some incorrect information (claims the blue ghost moves 'at random', which I'm pretty sure is not the true AI). But it might be good enough.
    – Tim
    Nov 22, 2012 at 17:11
  • I noticed there were some inconsistencies too. Unfortunately, it's the best I could find.
    – ediblecode
    Nov 22, 2012 at 17:16
2

After some close examination by hand and by recording, Pac-Man moved a distance of 200 pixels in around 3.10 to 3.15 seconds. This comes out to around 8.00 to 8.05 tiles per second, which is about 64 pixels per second. Since I was on the first level, Pac-Man was at 80% of his full speed. With some math, it turns out Pac-Man moves exactly 80 pixels per second, or 10 tiles per second. Hope this helped.

Improve this answer
0

As someone else said he is likely moving at around 80 pixels per second, so it basically means he is in fact moving faster than a typical 60 fps screen is refreshed (1.33 pixels per frame). While its rather simple to represent pacmans x and y position as fractions and just add the speed (adjusted for screen refresh), it means you have to be careful with your logic for deciding when pacman can turn. Many turns will not be aligned with integer values which is what you operate on the screens pixels. So if your code works with an offset value for pacman (as a max +/- 8 pixel offset from a character position) that offset might jump from e.g. -0.1 to 1.1 meaning that any check for offset 0 as a valid turning point would be missed.

One solution to this could be to work with the fractions by themselves and whenever they pass a full pixel value you then move pacman one pixel and perform the logic for tests/turns. If the fraction add resulted in two pixels move you can do the logic twice too. For example when the fraction x offset of pacman is 0.9, adding the speed of 1.33 means he is at offset 2.23 and in fact has to move two pixels and you should execute the logic tests for each pixel added to his offset, in case he could turn after the first pixel.

One trick often used is to divide the speed by 2 to lower the actual speed below 1 pixel movement per frame and then execute movement logic twice for each screen refresh. This assumes that the frame rate is fixed and known and that the divided speed would become lower than 1.

In reality the movement of pacman is quite a bit more complex as you would have to support "cornering" too, so you have to check if he can turn quite a bit before the actual intersection as well. All this is described in the Pacman Dossier with some detail.

Improve this answer
2
  • The position of Pac Man and the monsters are computed as a combination of a tile and an offset. Pac Man and a monster are deemed to collide when their tile positions coincide, independent of offset. In cases where Pac Man passes through a monster, the player and monster are in adjacent tiles on one frame, and then in the opposite tiles the next frame, without them ever having occupied the same tile.
    – supercat
    Oct 2, 2014 at 16:41
  • Yes but when you have fractions on movement, you have to know exactly when the monster or pacman passed into a new tile and move that fraction over into the direction that it is travelling after its new direction has been decided. Its a common problem people encounter in maze type games where some object is moving faster than 1 pixel per frame update. I was just making some comments on how to do this as the initial poster was doing a pacman clone. Actually I see now that you can do this with only one logic update too by just moving the offset and fraction into the other direction.
    – John Christian Lønningdal
    Oct 3, 2014 at 5:33
-2

1.46... pixels per frame. A frame is 1/60th of a second.

Improve this answer
2
  • 2
    A frame is 1/60th of a second only if your frame rate is 60 frames per second. Makes sense, no?
    – Alex
    Apr 2, 2014 at 13:50
  • I think this is fairly accurate. The better answer would be, at 60 frames per second, he is moving at 1.46 pixels per frame. 1.46 * 60 is 87.6, which is very close to my 88 pixels per second answer
    – ediblecode
    Apr 3, 2014 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .