Results for
One-Button Game Mini Hack Entry: Pump-Send
Hi everyone! Pump-Send is a side-view mountain bike game on an endless desert pump track. You never pedal: all your speed comes from pumping the rollers, and one button does everything. On the ground, a tap pumps or pops; in the air, it throws you into a backflip.
How scoring works
- You get **1 point for every meter** you ride. The run ends if you run out of momentum or crash.
- Every **clean backflip is worth 50 points**, so one flip equals 50 meters of riding.
- Your score and flip count are shown in the top-left corner.
Definitions
- Pump: A tap while rolling downhill. You push the bike into the slope and gain speed.
- Scrub: A tap at the wrong time (going uphill, or a second tap right after a pump). It costs you a little speed.
- Lip: The rising face just before the top of a hill. It glows yellow.
- Pop: A tap on a glowing lip. It's the only way to get airborne.
- Flip: A tap in the air spins the rider backward. Each full rotation you land counts as one flip. Tap only; don't hold the button.
- Stall: Going too slow for too long. This ends the run.
Physics you'll want to know
- Steeper downhill = bigger pump. A pump on a steep drop gives you a big shove, about a third of your starting speed. On a nearly flat stretch, it does almost nothing. Aim for one good pump on each downhill.
- Scrubs add up. A badly timed tap only takes back about a third of a good pump, but a few in a row can leave you crawling.
- Watch the hills scroll. If the scenery slows down and you're barely making it over the crests, pump now or you'll stall.
- Speed is hang time. The faster you hit a glowing lip, the higher and longer you fly, and the more time you have to finish a flip.
- Spin fades in the air. Each tap adds spin, and the spin slowly dies down. More taps spin you faster, but you have to be wheels-down at the right angle when you touch the ground.
- Land matching the slope. Don't start another flip if you won't finish it in time to land at the right angle.
Quick tips
- Build speed with a few pumps before you try your first flip.
- On a big jump, one tap in the air is usually a full flip. Count, then stop tapping.
- When in doubt, skip the flip: distance points still add up.
- The game gets harder as you go, with tighter pump timing and landing requirements.
Behind the scenes
I built Pump-Send with a team of Claude Code agents: one designed the game, one wrote the tests (113 of them!), one built it, one reviewed the code, and one judged prototypes to help me choose among my four original ideas. The judging turned out to be less useful than I expected, since it was pretty obvious after playing which idea would pan out best. The most interesting lesson for me was about using bots to tune the physics.
Lesson one: the bot was too good
The first bot was simply too good at the game. It predicted where each jump would land and planned its flips accordingly, scoring hundreds of points. Then I took the wheel (err, handlebars) and crashed in seconds.
So I had the agents build a bot that plays like a person. It makes the same decisions, but each tap arrives 100 ± 60 ms late, it waits to see what one tap did before deciding again, and it taps at most 10 times per second. That bot survived a median of 8 seconds and crashed in 17 of 30 rides.
Here's what it uncovered and what I changed:
- A slightly late tap on a lip turned into a backflip spin on a tiny hop. Now you only leave the ground when you tap.
- Riders landed on the next uphill 55–68% of the time. Now a lip glows only if a pop at your current speed will land on a downhill.
- A flat dead zone at every crest turned late taps into scrubs. It's gone.
- Everything runs in gentle slow motion (0.8×), so every timing window lasts 25% longer.
- In most flips, the rider's head went through the ground. Now the rider spins around the hips.
After those fixes, the human-like bot survived a median of **53 seconds** with **0 of 30** crashes. "The human-like bot survives at least 30 seconds" is now a permanent test for every new build.
Lesson two: bad players on purpose
Bots that play badly are just as useful. Every build is tested against `idle` (never taps), `spam` (taps every frame), and `masher` (8 taps per second). Each one has to die within 15 seconds or score under a fifth of what the scripted bot scores, so you can't win by ignoring or mashing the button. A `random` tapper rounds out the lineup.
Results for the current build, 20 rides of up to 60 seconds each (a different set of rides from the 30 above, so the human-like numbers differ a little):
+------------+----------------------------+-----------------+--------------+--------------+
| Bot | How it plays | Median survival | Median score | Median flips |
+------------+----------------------------+-----------------+--------------+--------------+
| idle | Never taps | 12.8 s | 40 | 0 |
| spam | Taps every frame | 2.2 s | 1 | 0 |
| masher | 8 taps per second | 2.3 s | 9 | 0 |
| random | Random taps | 6.2 s | 30 | 0 |
| human-like | Smart taps, 100 ms late | 46.3 s | 801 | 8.5 |
| scripted | Smart taps, perfect timing | 51.2 s | 1,391 | 14.5 |
+------------+----------------------------+-----------------+--------------+--------------+
Your turn
What's your high score? Did you beat the human-like bot? I'd love to hear if anyone lands three flips in one jump.
My entry for the one-button game mini hack Lunar Lander - Tap to Burn, is a one-button powered descent. You start 500 m above the surface, falling at 10 m/s, with 200 kg of propellant. One tap turns on the engine, and the next tap stops it.
How scoring works
- Crash: landing at 3 m/s or faster scores 0.
- Abort: rising above 750 m scores 0.
- Safe landing: below 3 m/s scores 10 points per kilogram of fuel remaining.
- Perfect touchdown: below 1 m/s doubles the reward to 20 points per kilogram of fuel remaining.
Physics in the game
- Fuel mass decreases as propellant is burned.
- Gravity continuously accelerates the lander downward.
- The engine does not reach full thrust instantly, so timing matters.
- The display turning red indicates when a full thrust landing burn becomes possible.
Display readouts
- ALT [m]: Height above the surface.
- V/S [m/s]: Vertical speed.
- FUEL [kg]: Remaining propellant.
- dV [m/s]: remaining velocity change the fuel can provide, from the rocket equation Δv=Isp·g₀·ln(m/m_dry).
- T/W: Thrust to weight ratio.
My best so far is 1300. Has anyone managed a sub 1m/s landing?
The day and night colours depend on how far the fox has run. Instead of recolouring everything on every frame, I turn the cycle into a small number of steps and only recolour when the step changes:
nn=.5-.5*cos(2*pi*s.dist/3200);
q=round(nn*40);
if ~isequal(s.ax.UserData,q)
s.ax.UserData=q;
% recolour the background, ground, text and obstacles here
end
The current step is stored in the axes UserData, so the check is cheap. Text works the same way. I only set a text string when the new string is different from the old one:
if ~strcmp(s.sct.String,t), s.sct.String=t; end
Setting properties that have not changed still costs time in every frame, so skipping them helps a lot in a game that redraws many times per second.
Check against your code: the first block is simplified from your renderFrame. Your real code also adds +100*(s.st==2) to q so the colours change on the game-over screen, and I left that out to keep the tip simple. The strcmp line is from your score text. Both matc
The day and night colours depend on how far the fox has run. Instead of recolouring everything on every frame, I turn the cycle into a small number of steps and only recolour when the step changes:
nn=.5-.5*cos(2*pi*s.dist/3200);
q=round(nn*40);
if ~isequal(s.ax.UserData,q)
s.ax.UserData=q;
% recolour the background, ground, text and obstacles here
end
The current step is stored in the axes UserData, so the check is cheap. Text works the same way. I only set a text string when the new string is different from the old one:
if ~strcmp(s.sct.String,t), s.sct.String=t; end
Setting properties that have not changed still costs time in every frame, so skipping them helps a lot in a game that redraws many times per second.
All the graphics objects (patches, lines and text) are created one time, when the game starts. After that, the render function only changes their data with set:
set(s.hd,'XData',s.DS{k}+DX,'YData',s.DT{k}+G+s.dy)
Creating new objects on every frame is a common reason MATLAB games feel slow. Updating objects that already exist is much cheaper. To hide an object, I set its data to NaN instead of deleting it:
set(s.ho(m),'XData',NaN,'YData',NaN)
Disclosure: the game code was written with Claude (an AI assistant). I tested the game in MATLAB and checked the details myself.
For the One-button Game Mini Hack, the code limit is 10,000 characters. I made a game called Ember Fox, where a fox runs and a stone guardian chases it, and you have one button. These are the techniques in the code that I found most useful.
Tip 1: Draw pixel-art sprites from text
Each sprite is stored as a grid of characters, where # is a filled pixel and . is empty:
A=['######';'#.##.#';'######';'.####.'];
[X,Y]=spr(A,0.6);
A helper function, spr, turns the grid into rectangles. For each row it uses diff to find where every run of # starts and ends, and each run becomes one rectangle instead of one rectangle per pixel. This keeps the sprite data small and the number of graphics objects low. All the sprites are built once, when the game starts.
If you are as excited as me to play these games but somehow something is stopping you from doing just that, you are at the right place. Follow the steps below and you will be playing in no time (maybe some time depending on your browser, network speed, etc.):
- Click on the game you like the look of (let's say, something that is transformative).
- This will open up its details page with the game code, preview video and the "Play Game" button. Click the video or the button.
- This will open up "MATLAB Drive" in a new browser window with a preview screenshot of a half-played game and a "Run this App" button. Click this button and nothing will seem to happen at first. And nothing will happen at any other subsequent tries. But don't worry, that's why you're here.
- Click on the "entry-×××××" blue hyperlink just above the preview area (underlined in red above). This will take you to a list of two files but hide the crucial blue button. Click on the "Entry×××××.mlapp" file to resurface the blue button.
- With expectant hands, click the "Run this App" button. This time it will reload the "MATLAB Drive" and put it in the mode to run your chosen game.
- Finally, you are where you expected to be in the point 3! Enjoy your game.🥳
Hi everyone,
I made Ember Fox: Outrun the Stone Guardian for the One-button Game Mini Hack. A fox runs forward, and a stone guardian rolls behind it and chases it. You must hop over obstacles to stay ahead.
Play it here: https://www.mathworks.com/matlabcentral/communitycontests/contests/10/entries/16448
(Click Play Game, then Run this App.)
The whole game fits in less than 10,000 characters. Below are the main tricks I used. I hope they help you with your own games.
How the game works
- One button does everything: tap to hop, tap again in the air to dive.
- If you hit an obstacle, the stone guardian gets closer. If it catches you, the game ends.
- Diving onto a flying enemy gives bonus points.
- Power-ups give a shield, slow motion, or push the guardian back.
- Passing obstacles builds a combo multiplier.
- The game gets faster the longer you play, and the sky changes from day to night.
Trick 1: Draw pixel-art sprites from text
I draw each sprite as a grid of characters. A # means a filled pixel:
A=['######';'#.##.#';'######';'.####.'];
[X,Y]=spr(A,0.6);
My helper function spr turns each row into rectangles. It uses diff to find where every run of # starts and ends. One run becomes one rectangle, not one rectangle per pixel. This keeps the number of graphics objects low and the code short.
Trick 2: Create graphics once, then only update them
In init I create every patch, line and text object one time. In renderFrame I only change them with set:
set(s.hd,'XData',s.DS{k}+DX,'YData',s.DT{k}+G+s.dy)
Creating new objects every frame makes a game slow. Updating existing ones is much faster. To hide an object, I set its data to NaN instead of deleting it.
Trick 3: Update only what changed
The day and night colours depend on how far you have run. I turn the cycle into a small number of steps and change the colours only when the step changes:
nn=.5-.5*cos(2*pi*s.dist/3200);
q=round(nn*40);
if ~isequal(s.ax.UserData,q)
s.ax.UserData=q; % change all colours here
end
I do the same for text. I only set the text when the new text is different:
if ~strcmp(h.String,t), h.String=t; end
Trick 4: One button, different actions
The game state decides what the button does:
- On the start or game-over screen, it starts the game.
- On the ground, it makes the fox hop.
- In the air, it makes the fox dive down faster.
This gives the player more choices without adding more buttons.
Trick 5: Smooth difficulty and simple collisions
The speed grows quickly at first, then slows down, so the game stays fair:
s.spd=55+90*(1-exp(-s.sc/900));
Collisions are simple rectangle checks. After a hit, the fox is safe for a short time, so one mistake does not cause many hits in a row.
Trick 6: Fit the character limit
- Use short variable names.
- Use loops and shared code instead of repeating lines.
- Run minihackContest.validate often to check the character count.
Known problem: the game runs smoothly in desktop MATLAB, but it can lag in MATLAB Online. For the best experience, run it on your computer with minihackContest.play.
Thank you for reading! If you have questions or ideas to make it better, please write a comment. I would love to see how you solve these problems in your own games.
I started my game for this contest, Stack OverDad, one month before the contest began. Dad tells programming jokes at the dinner table, and you have to laugh at the right moment. I was very happy with it. It had a dog, a little brother with a spoon, a window with a sun that goes down, fifty jokes, and many small animations.
Then the contest started, and I read the rules again. One line said: each entry is limited to 10,000 characters of MATLAB code.
My code had more than 70,000 characters.
So, as you can guess, the next hourse were cut, test, cut, test, cut... In this post, I will tell you what I learned on the way (from my AI friend!). Some of it surprised me.
Step 1: Cut What the Player Does Not Feel
For every part of the game, I asked: "Does the player really feel this?"
The dog: cute, but no. The brother: funny, but no. The sunset: nobody looks at the window when Dad tells a joke. Forty jokes: a game only uses ten anyway.
This was the biggest step, and the hardest, because I liked all of these things. But the game did not get worse. It got clearer. After this, my file had about 9,800 characters. I was done!
Step 2: The Surprise
The contest project has a command to check the game before you submit it:
minihackContest.validate
I ran it, and it said:
Validation failed: game.m exceeds the character limit (16145 / 10000, comments excluded).
16,145? My file had 9,800 characters. I counted again. It still had 9,800.
So I opened the validator to see how it counts. This is the line:
charCount = strlength(char(tree2str(mtree(gameFile, '-file'))));
mtree reads the code into a tree, and this removes the comments. Then tree2str writes the code again, in a clean, standard layout. The validator counts that text, not my file.
And the clean layout is not short at all. For example, this one line of mine:
if p,pr(s.T);end
comes back from tree2str like this:
if p
pr( s.T );
end
Every statement gets its own line. Every line gets indentation. Every f(a,b) becomes f( a, b ), and every [1 2 3] becomes [ 1, 2, 3 ]. My short style was not short anymore.
The good news: now I knew the real rule, so I could play by it.
Step 3: What Is Cheap and What Is Expensive
- Expensive: many statements, deep nesting, and long lists of numbers.
- Cheap: text inside a string. tree2str does not change a string at all.
So the plan was: fewer statements, less nesting, and move numbers into strings.
Example 1: Many Values in One Statement
s.st = 3;
s.t0 = t;
s.la = -1;
becomes one statement with deal:
[s.st, s.t0, s.la] = deal(3, t, -1);
Example 2: A Small if Without if
if n == 1
s.fl = "TEN?!";
end
With logical indexing, it is one line. If the condition is false, nothing changes:
s.fl(n == 1) = "TEN?!";
Example 3: Many Strings in One String
A list like ["PERFECT!", "GOOD!", "TOO LATE..."] pays for every ", ". One string with a separator is cheaper:
B = split("PERFECT!|GOOD!|TOO LATE...", "|");
All fifteen jokes are now one string too.
Example 4: Numbers Inside a String
This was the biggest trick. My scene (the table, the chairs, Dad, the family) is made of rectangles, ellipses, and polygons. That is hundreds of numbers.
So I stored each number as one character in a string. A character is really a number (its code), so I can turn it back:
v = double(char(z))/20 - 1025; % every character of z becomes one number again
I chose codes from a big block of normal, printable characters. They look like Chinese characters, but they are not words. I only use their codes. One small loop reads the string and draws all the shapes with patch. Now the whole scene costs about one character per number.
One warning from my own mistake: use double(char(z)), not double(z). If z is a string, double(z) gives NaN. My first test showed an empty table because of this.
I kept the readable list of shapes in a separate file, and it writes the packed strings for me.
I Had Help
I worked with an AI assistant the whole way. It read the validator with me, tested many small ideas fast, measured which part of the code cost the most, and rewrote code again and again without getting tired.
But the AI did not decide what the game is. It could tell me that the dog costs 1,700 characters. It could not tell me if the dog is worth it. Every "keep" or "cut" was my choice. I think this is the best way to work with AI: let it do the heavy lifting, and keep the decisions for yourself.
The Result
The validator now says 9,936 characters. The game still has Dad, THE LOOK, Mom's warnings, the family walking out, the ranks, and fifteen jokes.
My advice: run minihackContest.validate early. Do not count the characters yourself, because the validator does not count your file. It counts the clean version of your file.
I hope you have found this helpful. Thank you for reading.
We are excited to invite you to join our 2024 community contest – MATLAB Shorts Mini Hack! Last year, we challenged you to create a 48-frame animation. In 2024, we are increasing the frame count to 96 and supporting audio. Your mission? Create a short movie!
Whether you are a seasoned MATLAB user or just a beginner, you can participate in the contest and have opportunities to win amazing prizes. Be sure to check out our Blog post for more details on the Community Contests.
Timeframe
This contest runs for 5 weeks, from Oct. 7th to Nov. 10th.
How to Participate
- Create a new short movie or remix an existing one with up to 2,000 characters of code.
- Vote or comment on the short movies you love!
Prizes
You will have opportunities to win compelling prizes, including Amazon gift cards, MathWorks T-shirts, and virtual badges. We will give out both weekly prizes and grand prizes.
Stay Informed
Make sure to follow the contest to get important announcements and your prize updates.
Loving all the animations I'm seeing so far and feeling so inspired and impressed by what y'all are sharing. Thanks for loading me up with new topics to learn about!
Hopefully you are aware that MATLAB is built into ThingSpeak. Right now, MathWorks is hosting two contentsthat can help you learn MATLAB and then improve your IoT project.
I just set a calendar reminder to do a Cody problem each day. I can't win a prize but I can still get a virtual badge if I get a streak going.
