Recreating the Original Pacman Movement

Outline of the assignment

As part of my university course, one of my modules required me to recreate Pacman (or a game similar) using a university framework for developing games built upon the SDL library. My idea for this was to try and create accurate, usable, and smooth responses to player input to make the game as responsive as possible. The 3 ways I split this problem down was Basic Movement, Collision Detection and adding Turn buffers.

Base Movement

The first problem I had was dealing with player input and applying that to the movement of the character. When researching the original Pacman game for reference material, I found that in the original Pacman, if the player chose a direction, Pacman would continue to move in that direction even if they let go of the key. This means that the player should only need to press a direction once to travel. To do this, I gave Pacman a VelocityX and VelocityY variable. Each frame, the VelocityX and VelocityY would add itself to the current position. By doing this, if I set the check for input to set the VelocityX and VelocityY to the variable I had declared for the movement speed, the player will continuously move depending on which directional input I give the player, with the need to only press it once.

Collision

Next, I had to deal with the player collisions, and how the player would interact with the walls that were put in place.

While creating the map, I decided to build it in a tile-based format. This is solely due to how I was able to import the map via a text file, where each character in the text file equates to a tile in the game.

Now I had Pacman and all the tiles generated to the screen I had to decide and implement my method of collision. I chose bounding boxes due to how they would interact well with each other, as well as the tiles being square in shape. By knowing a tile's position, width, and height, I could find the top, bottom, left and right coordinate boundaries for the object. I could then compare the bounding boxes of Pacman and all the Tiles to see if Pacman is overlapping with any of them.

If Pacman is then found to be overlapping with a tile, by adjusting the Tiles boundaries so that there are small boxes on each side of the tile, it is easy to determine the direction Pacman is approaching from, meaning I could set Pacman’s position to the X or Y coordinate of the wall depending on where Pacman hit the wall. To fix a bug of Pacman stuttering back and forth, I would then set the velocities of Pacman to zero. For Example, if Pacman were to hit the left side of a tile, Pacman's X position would be set to the X position of the left side of the wall plus the width of Pacman, since the X position is judged by the top left of the object.

Turn Buffer

The final, and most likely unknown feature of the original Pacman which I wished to bring forward into my recreation, is the implementation of a turn buffer.

In the original Pacman, if the player held a direction into a wall, Pacman would ignore the updated input and keep moving forward. This would be until that direction no longer is taken up by a wall, allowing the player to move in that direction. This buffer is incredibly important for new players, as it removes the accuracy of needing to be pixel perfect with your input, especially at higher speeds. To implement this, I added validation to my input reading section. I added a check which created a small and thinner bounding box in the direction the player is wanting to go. If this bounding box overlapped with any tiles, the function would return false and the player would not change direction. However, once there was no tile in the way, the function would return true, allowing the player to move in that direction as soon as it is possible.

This made input extremely smooth, and people who didn’t play games often had no issue with picking up my replication.

This picture example shows that the player would not turn to face the tile. This is due to how the checking bounding box is currently overlapping with the tile, showing there is no empty space and returning false.

This second example would show a situation where the player would be able to turn into that direction. This is due to how the bounding box is not overlapping any of the tiles returning true. I decided to make the bounding box slightly thinner than the player to allow a wider range of input to be able to turn into the new direction.

Conclusion

After implementing these three key features for smooth movement, the recreation of movement turned out to be very accurate compared to the base game. The biggest aspect that impacted this was the inclusion of a turn buffer, which allowed people who aren’t used to playing games to be able to control the character and play the game to an efficient degree.