Somnia Space Defender

The problem

Most blockchain games put the chain in the critical path of play, which means every action waits on a transaction and the game feels broken. The design question is narrower than it looks: which parts of a game genuinely benefit from being on-chain, and which parts only suffer for it?

How it was built

Built as a classic arcade space shooter — ten levels of increasing difficulty with collectible power-ups — where the moment-to-moment gameplay runs entirely client-side on Canvas. Shooting, movement, and collision never touch the network, so the game plays at full frame rate.

The blockchain integration is scoped to the one thing it is actually good at: a global leaderboard where scores are publicly verifiable and not controlled by the developer. That is a real property a centralized leaderboard cannot offer, and it is worth a transaction — unlike firing a weapon.

Rendering runs on Canvas rather than the DOM, which is the right call for a game loop: a per-frame redraw of many sprites is one draw call against a bitmap instead of hundreds of layout operations.

Contracts written in Solidity and developed with Hardhat, with ethers handling the browser-side connection between the game and the chain.

Why this stack

• Canvas — the correct primitive for a real-time game loop; DOM elements are not.
• Solidity plus Hardhat — leaderboard contract development and testing.
• ethers — browser-to-chain connection for score submission.
• Somnia — the chain the leaderboard settles on.

Outcome

• Built solo for a hackathon.
• Playable live, with source on GitHub.

Frequently asked questions

Why put only the leaderboard on-chain?

Because a public, developer-independent score record is something a centralized backend genuinely cannot provide, while on-chain gameplay actions provide nothing except latency. Scoping the chain to where it adds a property you cannot otherwise get is the whole design decision.