Pacman-like game on STM32F429I-DISCO with map editor

Attention Video

In a nutshell about yourself

Almost 4-year student of the Faculty of Applied Mathematics and Mathematics of St. Petersburg State University, since the first year I have been slowly programming in C / C ++, about six months ago I began to glance towards Java (many thanks to the JavaRush project!). Regularly catch on new topics for study: in the framework of the diploma I am engaged in image processing, I also torment Qt, managed to tinker with machine learning, make a project on Ruby on Rails, and now I'm starting to delve into speech recognition.

And then one day I realized that I wanted to try to work with "iron". Long searches on the Internet and meditations led me to the fact that I decided to deal with ARM processors. The argument in favor of this was also that in the foreseeable future, when there will be free money, I would like to attach a camera and a display to all this - the ARM power will allow me to do this.

Acquaintance with Iron

My choice fell on the STM32 family. Thinking that with a couple of LEDs I’ll quickly get enough of it, but I can already have a lot of fun with the screen, I ordered myself STM32F429I-DISCO. Being terribly disappointed with all the St. Petersburg stores that sell the hardware I need, I still received the coveted fee. For about a week, I figured out the basics, enjoying every blinking LED or function that worked.

Oh look, I press the button and the light stops flashing!

- from the author “Wow, two bulbs are blinking at once!” and “Wow, two bulbs at a different speed flash at once!”
Then there was a gyroscope and a display, all kinds of counters / timers / stopwatch, acquaintance with FreeRTOS, but that's another story.

Pacman, in person

Having mastered a little, there was a desire to do something interesting. Immediately thought about writing the game. At first I thought about the platformer, but decided to make the game a little simpler - a kind of Pacman. I chose the path “from simple to complex” for myself - first write the most basic, then gradually add features. Now the map is drawn, our Pacman runs around the map, even through the walls does not pass! At this point, I had a minimum in my head that I would like to realize:

• The main functionality is to run and eat;
• The presence of virulence, maliciously preventing us from eating fat to eat everything;
• The ability to control movements using both a gyroscope and a touchscreen;
• Ability to edit settings (at least select a control type);
• Ability to edit the map.

Moving

The movement on the map is implemented in the simplest, perhaps, way: everyone moves at the same time and at the same speed. The playing field is considered as a grid measuring 19x21 cells. At each iteration, the function responsible for the movement has information about the current location of the objects and the desired direction of movement of the player. Then it is checked whether the player can move to the next cell in the desired direction. After that, the direction of movement of the enemy is determined and checked whether the player and the enemy collide. The collision conditions with this model of movement are very simple - either the player and the enemy are in the same cell, or they are in neighboring cells and are going to move towards each other.

Evil Enemy

At first I thought of making the simplest decision-making logic: the player is above the enemy — the enemy goes up, the player is to the left of the enemy — the enemy goes left, etc. This idea worked according to its simplicity - the enemy was hopelessly stuck in the corners, allowing you to eat large sections of the map without any resistance. Attempts to get the enemy out of this state with random movements were unsuccessful. Completely random movements caused a strong desire to call an ambulance for an enemy suffering from a seizure. One idea worked more or less tolerably - a random choice of the direction of movement at each fork (between the forks - in the selected direction in a straight line, without deviations).

Perhaps it was worth combining this idea with the very first one, but I decided not to try to invent a bicycle anymore, but to use the good old Lee wave algorithm . After its implementation, everything became just wonderful. Even too wonderful - the complexity of the game has become quite high, because the enemy has now chosen the shortest path. I decided to leave it as it is for now. Only the number of vrazhin did not increase (them in the classic Pacman 4).

Settings

With the settings, everything is pretty simple. Obviously, the opportunity to choose the type of control is implemented. Touchscreen control is implemented using screen zoning:



The upper / lower zone sometimes seemed quite small to me - with an active game, I sometimes wanted these zones to be closer to the center of the screen. Therefore, in the settings I made an increase / decrease in these zones. To visualize the changes, I decided to draw dashes with the edge of the screen. A slight oddity in the behavior of library functions for working with the display: if the displayed object creeps out to the right border of the screen, the remainder appears on the left. And I was a little mistaken in the length of the very first drawing of the dash, which gave an interesting side effect - the dash eventually moved as it should, but 2 pixels remained on the screen, on the left and right sides of the screen, indicating the position of the dash at the time the settings were opened. Having decided that the effect is interesting, but not obvious to the user, he did everything as expected. It is not good for something to look like a bug.

Problems Writing a Game

The other problems, in my opinion, do not require a detailed description, so in a nutshell:

While sorting out the touchscreen, I noticed a “rattling” of the touch point — the scatter of recorded touches is ~ 2-3mm with rare jumps. Chatter itself practically does not cause problems (except in the editor), but rare jumps are not very encouraging.

The code

And here he is on the github . A little tidy, but far from ideal.

Future plans

It would be nice to redo the movement system, since in its current form it does not allow changing the speed of enemies and the player relative to each other. After that, slightly slow down the enemies and realize them closer to the original Pacman.