This is a submission for the MLH x DEV Writing Challenge
What I Built
Logical Steam is an endless river game. Your steamboat's engine keeps breaking while a black kraken chases you, and your best runs can be signed onto Solana. It won the Solana track at SBUHacks 2026.
You steer a paddle steamer down a river at night, seen from just behind the boat. Crates and rocks slow you down, waves break the engine, and a whirlpool ends the run. The kraken follows in the rear-view mirror and gains on you whenever you lose speed.
Every 750 to 1,500 m the engine faults and the run pauses for a timed repair. You either wire AND, OR, NOT and XOR signal boxes until the steamboat departs when the order says, or you read a short Python snippet and pick what it prints. Three difficulties change the bends, the obstacles, the kraken's speed and the repair timer. A practice page has all 11 circuits and all 24 coding questions with no clock.
Why we made it
The SBUHacks theme was steel and steam, so we built a game around a steam engine you have to keep fixing. We also wanted a leaderboard nobody could quietly edit, which is where Solana came in.
How we built it
We used plain HTML, CSS and JavaScript, with no framework and no build step. We were new to React, and this way everyone on the team could read every file.
The river is drawn on a canvas one segment at a time, the way old arcade racers fake 3D. The boat, obstacles and kraken are all drawn in code, and at night the bow lamp swings with your steering and lights the water ahead. Every sound is synthesized with the Web Audio API from tones and noise, so the game ships no audio files.
We also wrote tests that run each Python question through a real interpreter to check its answer, and check each circuit against its truth table.
What I learned
I learned how Solana transactions, the Memo program and program-derived addresses fit together, and how to read data back from the chain without a backend. I also learned how canvas game loops handle frame timing, and that contrast checks catch problems you don't see on your own screen.
Demo
Partner Technologies
Solana
A shared leaderboard is the part of a game that normally needs a server. Someone has to host the scores, keep the database running, and be trusted not to edit it. We used Solana so nobody has to. The chain stores the scores, anyone can read them, and nobody, including us, can change one after it's posted.
Recording a run takes one transaction, signed by the player in Phantom. It has two instructions:
- A transfer of 0 lamports to a program-derived address. Nothing moves; the address only tags the transaction so the game can find it later.
- A Memo instruction holding the run as
SJ1|difficulty|metres|name.
To show the leaderboard, the game calls getSignaturesForAddress on the tag address, parses each memo strictly, and sorts by distance. Each entry links to its transaction on Solana Explorer, so anyone can check who posted it and when. There's no server and no database.
It runs on devnet only, so it costs nothing real. The game never sees a private key, because Phantom signs everything. Recording is optional, so you can play without a wallet. When something fails, the game says what happened in plain language: no test SOL, cancelled in Phantom, or devnet not answering.
One bug took us a while. Recording failed in the browser even though our simulations passed. The library's SystemProgram.transfer helper relies on Node's Buffer, which browsers don't have, so we built the transfer instruction by hand. Its data is the instruction index 2 as a little-endian u32, followed by 0 lamports as a u64:
The chain proves who posted a score and when, not that the run was actually played. Anyone with a wallet can post a memo. Verifying runs before they count is the next thing we'd build.
Hackathon Experience
I attended SBUHacks 2026 at Stony Brook University, October 23 to 25, with my partner Ethan.
We went in with one rule: hackathons are supposed to be fun, and we weren't going to give up sleep for this one. It was our first time on the Stony Brook campus, and we had friends there to see, so a lot of the weekend was just exploring. We worked on the project in a few hours in the afternoon and again around midnight.
The idea came from asking ourselves what we would have loved as new computer science students: a game where fixing the engine means actually solving a circuit or reading code.
Every time we walked through the main event area, we saw teams stuck and frustrated, going back and forth with their AI tools without getting closer to what they wanted to build. Keeping our scope small and our goal clear helped us more than anything.
Winning the Solana track after a weekend we mostly spent enjoying ourselves was the best way to end it.
Winning the Solana track was the best way to end it. I was just watching the awards not expecting much but then they called me and I got really hyped! My partner Ethan had to leave early so unfortunately he couldn't witness our win as well.
Top comments (0)