Developing games for the console at the Arduino summer camp
Last year, we held a circle in the summer computer school on Arduino. Teachers participated there as well, resulting in an 8-bit gaming console with a 64x64 screen .
Now we decided to create a circle in which the guys will be able to create their own games for this console. Due to its minimalism, the code should get a bit. In total, the circle was scheduled for about 14 hours during the shift, so the low threshold for entering the programming of such games was an important feature.
4095 LEDs and all-all-all
We had only one piece of iron, so first we had to make an emulator. After all, several teams will work on the games. In addition, initially all the code was in one * .ino file, so it was necessary to break it into pieces so that adding new games was reduced to programming their behavior and rendering. We left the build environment with the Arduino IDE to simplify the configuration of the working machines.
')
To display the image on the screen, the processor constantly scans it and loads it into the pixel color shift registers. Therefore, the correct procedure for updating the screen should give only one line of pixels. But such an interface would be too inconvenient, so we made a set of functions such as game_draw_sprite, game_draw_text, and they are already inside checking which line should be drawn (and whether it should be). Because of this, there is some overhead, as all calls will be made for each line, and not just for the necessary ones.
The emulator provides the same functions, but it renders everything in the framebuffer, besides it works much faster than the console. Therefore, it is not always possible to assess what happens on the gland. But it solves most of the debugging problems, because you can start Visual Studio (or gdb) and see how the program works. All screenshots here are from this emulator.
The developer must implement two functions to make the game: screen drawing and updating the internal state. The update occurs at a predetermined frequency. The drawing function is called for each line of the screen (in fact, for groups of 4 lines at once due to the peculiarities of addressing).
The update function reacts to keys pressed on the joystick and changes the internal data of the game (for example, the coordinates of objects to move them). Since only one game is executed at a time, there is no point in each of them to declare static variables. After all, we have 2 kilobytes of memory. Therefore, working with memory is a little inconvenient for us - all game data is stored in a structure that has to be accessed through a pointer.
To test the functionality of the API, as well as the menu for selecting games, we implemented the game "Snake". We did it slightly in a hurry, so a few bugs remained. The children then happily discovered them.
To begin with, we placed our project from github on the internal server with gitlab. The guys worked with the forks of this repository, and then sent pull requests to collect everything in a heap. In general, everything went well, but we didn’t dive deeply into explaining the principles of git.
Total project participants were not too many. At first, 4 teams showed up, but only 2 came to the end. These were guys from a group just starting to learn algorithms, so it was interesting if they could do something.
The first team decided to make a classic sapper. Mines were placed very tricky - one by one in a column - so they needed only sprites with numbers from 1 to 3. The program consists of 475 lines, but there is garbage and comments left from the template. There was no time left to find fault with the code in pull requests.
The biggest difficulty in the implementation of the sapper is the opening of all free cells adjacent to the free one that the user clicked on. Crawling in width was an explanation for a long time. Yes, and he takes up memory by the queue. Therefore, the guys just scanned the array several times and opened the adjacent and open cells. This is an infrequent operation, so everything worked fine.
Another problem with the display is that if you try to draw the whole field every time, it turns out too slowly and the picture starts to flicker. I had to make a small crutch - a function that allows you to skip whole lines from sprites, if they do not fall on the displayed string. Next, we plan to upgrade the processor to the ATmega2560 in order to have enough memory for the framebuffer. Then all the problems with flicker for such games will disappear.
The game is called Breakout, because the guys first wanted to do exactly that. But then they decided that everything was difficult and they had Pong. The game has several modes - a game of two players, a game with a computer, a demonstration (playing a computer against itself). The truth is that the computer does not know how to play - it always manages to hit the ball. Guys did not have time to come up with a more cunning algorithm. Total file with the game takes 272 lines.
In parallel with the kids, I made Flappy submarine to show them how to work with sprites and controls.
All these games were enough to score 32 kilobytes of program memory. But after the upgrade to ATmega2560, there will be 256 kilobytes of memory, so next year we plan to repeat this circle without discarding the already created games.
→ The source code of the githab project
Now we decided to create a circle in which the guys will be able to create their own games for this console. Due to its minimalism, the code should get a bit. In total, the circle was scheduled for about 14 hours during the shift, so the low threshold for entering the programming of such games was an important feature.
4095 LEDs and all-all-all
API to create games
We had only one piece of iron, so first we had to make an emulator. After all, several teams will work on the games. In addition, initially all the code was in one * .ino file, so it was necessary to break it into pieces so that adding new games was reduced to programming their behavior and rendering. We left the build environment with the Arduino IDE to simplify the configuration of the working machines.
')
To display the image on the screen, the processor constantly scans it and loads it into the pixel color shift registers. Therefore, the correct procedure for updating the screen should give only one line of pixels. But such an interface would be too inconvenient, so we made a set of functions such as game_draw_sprite, game_draw_text, and they are already inside checking which line should be drawn (and whether it should be). Because of this, there is some overhead, as all calls will be made for each line, and not just for the necessary ones.
The emulator provides the same functions, but it renders everything in the framebuffer, besides it works much faster than the console. Therefore, it is not always possible to assess what happens on the gland. But it solves most of the debugging problems, because you can start Visual Studio (or gdb) and see how the program works. All screenshots here are from this emulator.
The developer must implement two functions to make the game: screen drawing and updating the internal state. The update occurs at a predetermined frequency. The drawing function is called for each line of the screen (in fact, for groups of 4 lines at once due to the peculiarities of addressing).
The update function reacts to keys pressed on the joystick and changes the internal data of the game (for example, the coordinates of objects to move them). Since only one game is executed at a time, there is no point in each of them to declare static variables. After all, we have 2 kilobytes of memory. Therefore, working with memory is a little inconvenient for us - all game data is stored in a structure that has to be accessed through a pointer.
To test the functionality of the API, as well as the menu for selecting games, we implemented the game "Snake". We did it slightly in a hurry, so a few bugs remained. The children then happily discovered them.
Collaborative development
To begin with, we placed our project from github on the internal server with gitlab. The guys worked with the forks of this repository, and then sent pull requests to collect everything in a heap. In general, everything went well, but we didn’t dive deeply into explaining the principles of git.
Total project participants were not too many. At first, 4 teams showed up, but only 2 came to the end. These were guys from a group just starting to learn algorithms, so it was interesting if they could do something.
Sapper
The first team decided to make a classic sapper. Mines were placed very tricky - one by one in a column - so they needed only sprites with numbers from 1 to 3. The program consists of 475 lines, but there is garbage and comments left from the template. There was no time left to find fault with the code in pull requests.
The biggest difficulty in the implementation of the sapper is the opening of all free cells adjacent to the free one that the user clicked on. Crawling in width was an explanation for a long time. Yes, and he takes up memory by the queue. Therefore, the guys just scanned the array several times and opened the adjacent and open cells. This is an infrequent operation, so everything worked fine.
Another problem with the display is that if you try to draw the whole field every time, it turns out too slowly and the picture starts to flicker. I had to make a small crutch - a function that allows you to skip whole lines from sprites, if they do not fall on the displayed string. Next, we plan to upgrade the processor to the ATmega2560 in order to have enough memory for the framebuffer. Then all the problems with flicker for such games will disappear.
Breakout
The game is called Breakout, because the guys first wanted to do exactly that. But then they decided that everything was difficult and they had Pong. The game has several modes - a game of two players, a game with a computer, a demonstration (playing a computer against itself). The truth is that the computer does not know how to play - it always manages to hit the ball. Guys did not have time to come up with a more cunning algorithm. Total file with the game takes 272 lines.
Flappy submarine
In parallel with the kids, I made Flappy submarine to show them how to work with sprites and controls.
All these games were enough to score 32 kilobytes of program memory. But after the upgrade to ATmega2560, there will be 256 kilobytes of memory, so next year we plan to repeat this circle without discarding the already created games.
→ The source code of the githab project
Source: https://habr.com/ru/post/336632/
All Articles