Concept
For people who know me, I was a gamer my entire life, and I loved the concept of video games as art. I always believed that games themselves can convey meaning like any other artwork, and for some their aesthetic values might even exceed what people traditionally identify as art. Also due to games’ nature of being an interactive medium, it can achieve much more that traditional art forms cannot. For example, the immersion that games bring to people playing them goes far beyond just viewing them, but actually experiencing them yourselves. Therefore, I decided to look for these artistic values in the earliest games, played on the arcades. When I was reading the webpage on The Art of Video Games exhibition in 2012 on the Smithsonian Art Museum website, I came across this game that I had heard of but never played before (because it was too old, obviously), Pac-Man. I knew it was a famous game and almost as old as Tetris, and then soon found out it was one of the first video games that “took this leap beyond the arcade, beyond the screen, into the broader popular culture. That changed the way the world looked at video games and understood that there was something bigger happening here than just a place to waste a quarter.” I took a great interest in this and decided to modify it by combining some other game elements into it and upgrading its interface for my midterm assignment.
I plan to leave the core gameplay of Pac-Man alone and focus on other aspects of the game. In the original version of the game, The map is always the same. I want to combine some roguelike game elements into my project by randomly generating the map every time the player resets the game. therefore the player would always get a new experience when in the game. I also want to make it an endless mode, therefore the player can play to update their personal records. I plan to achieve that by using the tunnels on the left and right sides of the map. Once the player finishes eating all the dots in one map, the tunnels turn into portals that teleport them to other maps with different backgrounds and different theme songs.
Functions and Classes
In this game, I think the main classes are Ghosts, Map, Player, Dots, and Game.
For ghosts, the four types of ghosts (Blinky (red), Pinky (pink), Inky (cyan), and Clyde (orange)) inherit the Ghost class. The Ghost class has certain attributes: intposition for identifying its absolute position, also responsible for calculating destination position; realposition for identifying the true position of the ghost and for determining collisions; targetposition for identifying the target the ghost tries to reach; speed for the speed of the ghosts, and state for determining the current state the ghost is in for it to have different actions. The functions the Ghost class includes are checkCollision, updateTarget, stateChange, directionUpdate, etc. In these functions, updateTarget is different for different types of ghosts.
For the map, it will only have a few attributes. One is a 2D array used to represent the map, and one is its state. it will only have one function, that is mapGen, called every time it is initialized.
For Player, it will have attributes: intposition, realposition, direction, and speed. The only functions it will have are movement and checkDot.
For Dots, the only attribute is its position and type, and the only function is to destroy itself after being touched.
Lastly, for the game class, will have attributes such as points, lives, gamestate(pause, ongoing, in between, etc). It will take care of loading each state of the game and contain data necessary to keep the game going.
This is just a brief outlook of what the system would be like. In practice, some parts may be modified.
Uncertain Part of Project
I find the most uncertain part to be the random map generator. I need to come up with a set of rules so that the map is playable and won’t include too many long corridors the player can be cornered, long dead ends, or areas the player cannot access. However, I have made a preliminary generator that follows one set of rules. This set of rules makes sure that the map is different every time and will not have corridors with width 2 in it. However, this set of rules could result in inaccessible areas. Right now I have an idea about another set of rules to be applied after this so that the inaccessible areas and dead ends can be connected to the other corridors so that the map could be more reasonable. I plan to make any tile that should be accessible with only one or fewer connections with other accessible tiles have at least two connections with other accessible tiles. There will be tiles that cannot find two connection points. Then this tile will be discarded into a wall tile. This process will repeat until no action can be done, and a usable map is then created. I haven’t implemented the second rule set yet, but I have a prototype of the first rule set and it yields satisfying results. It generates grids shown below:
Therefore I am confident that this map generator will be achievable, and I only need to tweak some details.