Pacman-like game on STM32F429I-DISCO with map editor

Video to attract attention

In a nutshell about yourself

The student is almost 4 courses of the Faculty of PM-PU of St. Petersburg State University, I have been slowly programming in C / C ++ since the 1st year, I started looking at Java about half a year ago (many thanks to the JavaRush project!). Regularly catch on new topics for study: within the framework of the diploma I am engaged in image processing, I also torment Qt, managed to tinker with machine learning, do a project on Ruby on Rails, and now I start to dig into speech recognition.

And once I realized that I want to try to work with the "iron". Long searches on the Internet and thoughts led me to the fact that I decided to deal with ARM processors. Arguments in favor of this were also the fact that in the foreseeable future, when there is free money, I would like to attach a camera and a display to all of this - the power of ARM will allow me to do this.
')

Meet the iron

My choice fell on the STM32 family. Thinking that with a pair of LEDs, I quickly played enough, but with the screen you can already have plenty of fun, I ordered the STM32F429I-DISCO. Being terribly disappointed with all the St. Petersburg stores that sell the iron I need, I still got the cherished fee. About a week to deal with the basics, rejoicing at each blinking LED or earned a function.

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

- from the author “Wow, two lights blink at once!” And “Wow, two lights blink at once with different speeds!”
Then there was a gyroscope, and a display, all sorts of counters / timers / stopwatches, familiarity with FreeRTOS, but that's another story.

Pacman, in person

A little accustomed, there was a desire to do something interesting. Immediately thought about writing a game. At first I thought about the platformer, but decided to make the game a little bit simpler - some sort of Pacman. I chose the path "from simple to complex" - first write the most basic, then gradually add features. The map is already drawn, our Pacman runs around the map, it does not even pass through walls! At this point, I had a minimum in my head, which I would like to realize:

• The main functionality is to run and eat;
• The presence of vrazhin, maliciously interfering with our fattening to eat everything;
• The ability to control movements with both the gyroscope and touchscreen;
• Ability to edit settings (at least select the type of control);
• Ability to edit the map.

Move

The movement on the map is implemented in the simplest, perhaps the most convenient way: everyone moves at the same time and at the same speed. The game field is considered as a grid of 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. It then checks to see if the player can move to the next square in the desired direction. After that, the direction of movement of the enemy is determined and it is checked whether the player and the enemy will collide. The conditions of collision with such a model of movement are very simple - either the player and the enemy are in the same cell, or they are in the neighboring cells and are going to move towards each other.

Evil vrazhina

At first I thought to make the simplest decision-making logic: the player is higher than the enemy - the enemy goes up, the player to the left of the enemy - the enemy goes left, and so on. This idea worked according to its simplicity - the enemy was hopelessly stuck in the corners, allowing you to eat out large sections of the map without any resistance. Attempts to bring the enemy out of this state by random movements were unsuccessful. Fully random movements caused a strong desire to call an ambulance for an enemy suffering from a seizure. One idea worked more or less tolerably - randomly choosing the direction of movement at each fork (between forks in the chosen direction in a straight line, without deviations).

It might have been worthwhile to combine this idea with the very first one, but I decided to no longer try to reinvent the wheel, but to use the good old Lee wave algorithm . After its implementation, everything became just wonderful. Even too great - the complexity of the game has become quite high, because the enemy now chooses the shortest path. Decided to leave everything for now. Only the number of vrazhin did not increase (in the classic Pacman 4).

Settings

With the settings, it's pretty simple. Obviously, the possibility of choosing the type of control. Touchscreen control is implemented using screen zoning:



The upper / lower zone sometimes seemed to me rather small - with an active game, I sometimes wanted these zones to be closer to the center of the screen. Therefore, in the settings made an increase / decrease in these zones. To visualize the changes I decided to make a dash from the edge of the screen. A slight oddity in the behavior of the library functions of working with the display: if the displayed object climbs beyond the right edge of the screen, the remainder appears on the left. And I made a little mistake 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 side of the screen, indicating the position of the dash at the time of opening the settings. Deciding 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 encountered during the writing of the game

The remaining problems, in my opinion, do not require a detailed description, therefore, in brief:

Understanding the touchscreen, I noticed the “bounce” of the touch point - the scatter of the recorded touches is ~ 2-3mm with rare jumps. The bounce itself is practically no problem (except in the editor), but rare jumps are not very encouraging.

Code

And here he is, on a githaba . Slightly put in order, but far from ideal.

Future plans

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