T-Rex-duino - a clone of the dinosaur game from the Chrome browser for Arduino

Having such a device, Firefox users will also be able to play T-Rex when the page fails to load.

To begin with, I was interested in homemade super minimalistic portable game consoles. In particular, the ATtiny85 + OLED display option is very popular:

So a person has already made 13+ games for such a platform.

It's a funny gadget, but after assembling I don’t feel like playing it for a long time. To my taste, the available games are not “speedy” enough to maintain interest for at least a few minutes. Therefore, I decided to make a toy that I myself would like to play for 10-20 minutes and maybe even two or three times. Fortunately, a relatively interesting game has long been appreciated, addictive and simple enough to fit into a microcontroller.

After 4 days off, I got such a clone.

Youtube video

Unfortunately, it was not possible to fit into the ATtiny85 ROM, so I had to use the classic Arduino. Now I even think that this is a better option, because Arduino is more accessible, it is easier to flash and there is much to expand.

The game has additional “fittings”: Ti-Rex can bend down (although this is not necessary, you can just jump!), “Lives” are added to extend the gameplay.

You can play around with the parameters of the game (such as speed, frequency of "enemies" and the like), many settings are placed at the beginning of the sketch.

Assembly

In the minimum version, you will need an Arduino Uno / Nano / Mini, a 128x64 OLED display on the SSD1309 controller and one or two buttons. In the portable version, you will need to add a battery with a charge circuit or batteries.

Scheme.

After the assembly, you need to flash the sketch from the directory t-rex-duino/(link to the repository at the end of the article).

Some implementation details

Here are some details that may come in handy for those who want to make their own mini-game. I tried to write an “engine” in such a way that it was convenient to make games on it, based on rendering sprites and detecting their “collisions” (in general, these are almost the only two functions of the “engine”, the whole game is built on them). Now there are still a lot of free resources, more than 50% in terms of performance and memory.

Because I initially relied on a small microcontroller in which there is only 512 bytes of RAM and 2 times less frequency than that of an arduino stone, a quick render with a “virtual” buffer was written for the game, which renders the screen in vertical or horizontal pieces.

A vertical virtual buffer requires a minimum of 128 bytes of memory, and a horizontal buffer - from 8 bytes. In this case, a full buffer of the entire screen would take 1kb. The direction of the render should be chosen so that it coincides with the main direction of movement on the screen (less distortion). At the beginning of the sketch, there is a switch of the render mode to demonstrate the operation of both options.

Each sprite in the game is described by a point in the screen to which it needs to be rendered and two one-bit bitmaps: “data” and “mask”. These two bitmaps describe a single-bit image with "transparency". Those. each pixel in the sprite can be “white”, “black” or “transparent”. Along with the project code, there is a python utility for game-assets-gen/img-conv.pyconverting png to c-arrays of the corresponding bitmaps. To start the process of regeneration of existing bitmaps, you can rungen_assets.batbeing in game-assets-gen/.

Also, I give an explanatory picture of the coordinate system used.

References

Project repository: github

Available scheme, sources for Arduino, a utility for converting images to the format of bitmaps used in the game.

Display Module: diymore 2.42 inch 128x64 OLED Display Module SSD1309

- That's it, thanks for watching !