mini_consol
- 9 Devlogs
- 28 Total hours
mini consol on Arduino Nano with display and 5 buttons to play games on it
mini consol on Arduino Nano with display and 5 buttons to play games on it
###What’s New
###How It Works
It was a fairly straightforward feature to implement, but it instantly made the project feel much more like a complete game!
Flicker-Free Rendering
To prevent screen flickering caused by redrawing the entire screen, I optimized the loop by clearing only the bird’s exact position before rendering its new frame.
Physics Implementation
Movement relies on both velocity and acceleration:
- Acceleration continuously increases the downward velocity (gravity).
- Jump mechanic resets the downward velocity to initial on every input.
Obstacle Setup
I need to create an array of one dynamic wall.
Recycling Logic
- As soon as a wall reaches the left edge of the screen, it will wrap around to the right.
- The height/position will randomize each time it reappears to form a continuous level.
I added sound effects for every button press on my mini-console! Sounds like a super quick and easy task, right? Well, it should have been. But a few architectural bumps in the road ended up eating way more time than expected.
My buzzer was originally soldered to a pin used by
SPI. As soon as the display initialized, things went sideways.
My game logic was running inside an infinite loop within a standalone function, while the sound playback logic lived in the main loop calling that function.
Solution: soldered the buzzer to another pin and quick architecture refactor solved both problems pretty easily — I spent about an hour on each issue.
I tried to tame it in software using PWM (Pulse Width Modulation) to decrease the volume. But PWM control is tricky on its own, and since the buzzer relies on a fixed frequency to generate tone, layering custom PWM over it completely broke the audio pitch.
What’s New
Pause Menu Implemented: Players can now pause the game at any time with two options:
-> Continue: Return to the game with all current progress intact.
-> Exit to Menu: Quit to the main menu (resets all game progress).
Technical Challenges
The main challenge was handling this within my current architecture, which relies on a main loop with a nested switch statement for state management. I needed a reliable way for these states to communicate and handle game object lifecycles properly:
-> Persisting Objects: Retaining game objects in memory when resuming from pause.
-> Cleaning Up: Safely destroying objects and resetting state when returning to the main menu (either voluntarily or on Game Over).
Next Goals
-> Add sound effects using the built-in piezo buzzer.
-> Implement a new mini-game: Flappy Bird.
DevLog №3 :
What I worked on: Started implementing the Pause state during gameplay. To make this work properly, the game needs to preserve the current state of both the Snake and Food objects when transitioning into pause and back. Slightly refactored the main loop architecture and updated the SnakeGameHandle function.
The Struggle: decided to write a helper function to update values inside my StateMachine (handling states like Game, Menu, Pause, Snake, FlappyBird).Blaming it on late-night fatigue, I wrote the function in the most overcomplicated way possible… and called it even worse.
The result? Every time I exited the Snake game, I was greeted by a blank black screen because the Menu state was never getting assigned correctly.
I spent over an hour staring at the code, completely stumped as to why it was breaking.
I think it happened because of self-assignment
The Fix: Decided to get some sleep. Woke up the next morning with a fresh head and fixed the black screen issue in 20 minutes.
Next Goal: Finish up the Pause feature completely
devlog #2:
added StateHandle file to handle all the actions(menu, games) in my main loop in main.cpp. Now my main loop is shorter and more understandable
Devlog #1:
I uploaded all the files I had written before I found out about Hack Club. After that, I spent most of my time figuring out how to detect collisions between the snake and the food. Since I originally built everything pixel-by-pixel instead of using a grid system, comparing screen positions directly required too many pixel checks. To optimize this and avoid checking every single pixel pair, I had to tweak the logic. Even though it was tricky to adjust without a strict grid, the collision detection is working now and the game is totally playable