The problem Bubblewars.io solves

It solves the problem of blockspace being incredibly boring and saturated with DeFi applications. Bubblewars.io serves as an additional way for ETH holders to spend and earn ETH in an active manner.

Join the game by spawning a Portal. Portals serve as your entry and exit point into the application. You can think of your portal as a separate EOA (or account abstracted) address. Any funds you send to your Portal get automatically transmitted to the app-rollup that is running Bubblewars and can be withdrawn back to the Layer 1 at any point in time after the proving cycle is finalized (Additionally, any ETH that falls into your Portal from other players also belongs to you) Once your Portal is spawned and a sufficient amount of ETH has been deposited into it, you can begin emitting Bubbles from it. Bubbles serve as your main means of exerting dominance within the game. Your main goal as a player is to absorb ETH mass from enemy Bubbles and deposit it back to your Portal for a profit. Any Bubble that has less ETH mass than yours can be consumed. Conversely, any Bubble with more mass than yours can consume you. Bubbles (and all other objects ) move around the world in a fully physics based manner. To propel a Bubble you must emit ETH in the opposing direction (per conservation of momentum). Additionally, the momentum of absorbed mass is also passed along as well. So absorbed Bubbles can speed you up or slow you down.

Now that the core mechanics have been established, the main concern with this model is that the user with most ETH wins. "Just deposit more ETH to your portal, emit the biggest bubble and win". As a result of this I have implemented (not live now) an additional mechanic called Resource Nodes. Resource Nodes are objects randomly placed throughout the canvas that emit Resources. These Resources can be absorbed by Bubbles (and Portals) and used as power ups to even the playing field against larger Bubbles. (Still currently designing the Resource types).

Challenges we ran into

This is a fully on-chain game. (Seriously)

We are running a physics engine (Planck.js) within our own rollup (CartesiVM, Node.js/Typescript smart contract).

All inputs are transactions sent to the Layer 1 without sequencing (currently a local anvil blockchain serves as our L1 for quick iteration and CI/CD. But could of easily been deployed to Sepolia, Holesky Redstone or some other testnet) (Also we get to faucet unlimited anvil ETH to burner wallets). Upon each user input/transaction (using burner wallets at the moment) the rollapp runs the simulation of the game physics from the timestamp of the last submitted transaction up to the timestamp of the most recently submitted transaction. So the gameplay physics is simulated in real time, but in an input driven manner (because of the nature of blockchain). So to get a real time feel, we implemented a state server (or indexer). This is a websocket server that listens to the L1 for transactions to the rollup contract, simulates transactions as soon as they are added to a block and then syncs clients with the appropriate game state that exists within the rollapp. Users can choose to use our state server (for better UX) or simulate game state within their own client ( or if even just wait for the rollup to publish state changes back to the L2, but that'll take slightly longer). The state server allows for a seamless web2-equivalent user experience. (very vital)

So the hurdle was implementing a fully on-chain REAL-TIME game where the smallest smallest possible timestep within the game loop is about 0.03 seconds and syncing all of the clients in a seamless manner. (Your inputs are of course bottlenecked by the layer 1's block speed, but dedicated sequencing can change that). (And thanks Cartesi Machine for the computing power)

Next steps:

1. Iterate on the game loop.
2. Then testnet.
3. Then mainnet.
4. THEN TOKEN!!!!