Google Dino Run on Unihiker k10
This project revolves around a rathe new concept in the evolution in AI technology – vibecoding. Vibecoding is a software development approach, where the user no longer writes the code manually but rather refers to an ai, using natural language to prompt the ai to code. These AI LLMs generate, refine and correct code very efficiently, allowing the user, even with limited programming knowledge to build complex projects.
This project was made entirely in VSCode using the Github Copilot integrated agent as well as the PlatformIO (PIO) IDE extension and a DFRobot Unihiker k10 (ESP32-S3)
The first tool, used in this project is the Github copilot. This agentic coding agent was developed by Github and OpenAI as a pair programmer. Copilot “lives” inside the VSCode IDE on the right hand side of the screen. It can be accesssed via the chatbox in the bottom right of the screen
The second neccesary tool for this project is the PlatformIO (PIO) extension inside VSCode. PIO is a professional, cross-platform ecosystem for embedded software development that acts as a modern alternative to the Arduino IDE. It works primarily as an extension for VS Code, supporting over 1,000+ boards, 40+ platforms, and multiple frameworks like Arduino and ESP-IDF and in the case of this Project, among the many boards, also the ESP32-S3. This tool is neccesary for the connection from the board to the computer. Without it, uploading code isn't possible. To install PIO, follow the steps below:
The thrisd and final tool for this project will be the C/C++ language. This is a programming language that can also easily be installed via the extensions tab.
Once everything is connected the code that will be written, edited and ultimately run will be the main.cpp under the src directory. Now there is only one more thing that needs to be completed before you can start coding which is moving the following two files into the same dcirectory as main.cpp, which is the src directory. These are simply guidelines for copilot to follow in order to use the correct syntax for the specific board. (you can find both in the zip file below)
Archive.zip From here is is simply prompting the AI and watching as it works. It is a very rare occurance that the generated code will work as you want it. It will need finetuning, in which case you can ask follow-up prompts to correct any details that may not be correct.
What I did
The goals of my project was to build a recreation of the Google Rex game that automatically loads when Chrome is not conected to the internet. The game's principle is very simple. There is a T-rex that runs along the desert and avoing cacti and birds by either ducking or jumping over them. I wrote a simply prompt, describing the game as best i could in the greatest detail possible, making sure to include some specifications for the dimensions of the unihiker screen, a day and night cycle and which buttons i wanted to use for whih exact function.
Copilot then generated a code with all of my neccesary requirements. After running the code I noticed some errors. Not with the code, but with the way my idea was executed. The first and most obvious error was the screen refreshment rate. because of the unihiker limited capabilities, the refresh rate of the screen is not very high. This can be bypassed by only refreshing the part of the screen that changes from one frame to the next instead of the entire screen, especially if the majority of the screen remains the same. The second major issue was the logic behind the day and night cycles. Previously I had defined it as a simple inversion of the colours, however that did not match up with the partial frame refresh from the previous idea.
I simply specified these changes that i wanted to make and changed the logic slightly to make the game make sense, lastly i added a restart screen and the project is finished.
Here are some tips and tricks I used in this Project:
- Start with a crystal clear goal: a runner game on the K10 screen with a rectangle dinosaur, scrolling cacti, jump button, increasing score, collision game over, and reset button.
- Talk to the AI like a junior developer: remind it you have a Unihiker K10 board with MicroPython firmware and a specific display library.
- Build in tiny slices: first show a static dino, then make it jump, then add one moving cactus, then collision, then score and game over.
- Embrace the generate-test-complain loop: flash code, paste the exact serial error back to the AI for instant fixes.
- Give constraints up front: state "Use MicroPython, target Unihiker K10, built-in 240x240 screen, button A jump, button B reset, no external libraries."
- Use the file + request pattern: paste your current main.py and ask for a specific addition without changing existing code.
- Ask for a step-by-step plan before any code: request a description of a non-blocking game loop before implementation.
- Request specific output shapes: ask for only a single function like update_game() using global variables, not the whole file.
- Re-prompt with explicit details: if the AI misunderstands, say "No – the dino should jump instantly with a flag, not accelerate upward."
- Run after every change: flash the board and verify each small feature before adding the next.
- Paste the entire error message: copy the full traceback from the serial monitor, never paraphrase.
- Ask the AI to explain the fix: after a bug is corrected, request an explanation like "Why did my while True loop block button detection?"
- Backup working versions: save trex_v1_works.py on your computer before making risky changes.
- Test edge cases: ask what happens if you hold the jump button, or if a cactus spawns exactly on the dino.
- Create a project memory document: keep a text file with screen size 240x240, button pins, dino size 20x20, cactus size 10x30, scroll speed 5 px/frame.
- Reset the conversation if the AI goes off-track: start a fresh chat and paste your project memory and current code.
- Ask for alternative solutions: request simpler ways to store game state, like a single cactus variable instead of a list.
- Throw away bad output: if the AI writes code with threading (unsupported on MicroPython), say "No – keep it single-threaded, simple polling."
- Use a coding agent that supports serial flashing: tools like Cursor or Windsurf can run ampy or mpremote commands automatically.
- Always provide your board’s firmware version: e.g., "Unihiker K10 with stock MicroPython v1.20 from May 2024."
- Pin library versions: ask the AI to generate a requirements.txt with exact versions for any added libraries (like neopixel or ht1621).
- Ask the AI to add comments: request "Comment every line that updates coordinates or checks collision" to learn the logic.
- Request a code walkthrough: ask the AI to explain the main loop’s state machine line by line as if to a beginner.
- Try building the whole game from one prompt after 3-4 iterations: e.g., "Write the complete K10 T-Rex game. Button A jumps, B resets. Score every 10 frames. Collision stops. Display game over. No external libs."
- Never use time.sleep_ms inside the main game loop: use a non-blocking timer based on frame counters or millis.
- Handle button debouncing: ask the AI to add a simple debounce delay or edge detection for button presses.
- Set a fixed frame rate: implement a delay that keeps the loop consistent without blocking input handling.
- Separate drawing from logic: keep collision detection and coordinate updates in one part, screen refresh in another.
- Use simple shapes first: rectangles for dino and cactus are easier to debug before adding sprites.
- After the game works, add a score display and game over text as separate reusable functions.
This is what the full game looks like nad how it functions:
Once the game is loaded up, button a on the unihiker is the main button. It controls the jump and restart. Button b controls the ducking function
If the character touches an object then the screen turns red and the player has the option to restart the game by pressing a again, in which case the game restarts.
The game switches from day to night regularly and the obstacles vary in height and distance to eachother.
