Pear2Pair

Inspiration

To develop this project, we were inspired by the famous game Shut The Box, a classic dice game of strategy and probability that consists of flipping down a set of numbered tiles based on the sum of a dice roll.

What it does

Our project replicates the Shut The Box game using a peer-to-peer infrastructure, using Pears and Holepunch tools. The game allows 2 to 6 players to play a sincronous game, being held in a common room and in which you can acces via a topic.

Traditional digital versions of this game usually rely on a central server to sync the "state" of the tiles between players. By moving to a P2P configuration, our version ensures zero latency, as direct communication between players, privacy, because game data stays between the two nodes and resilience. One of the main aspects of our work is that there is no central server to go down; as long as you have a connection to your peer, the box stays open.

How we built it

We built the game using Pear as the peer-to-peer runtime and Hyperswarm for peer discovery. Players join the same room topic, which lets them find each other without a central server and keeps the game fully decentralized.

For persistence, we used Hypercore and Hyperbee. Hypercore stores the append-only history, and Hyperbee gives us a simple key-value layer for match data, events, and player stats. This makes it easy to replay a game state later and keep a local record on each peer.

The UI talks to a game controller, and the controller is the only layer that writes to storage. That means the interface stays simple, while the storage layer handles history and the p2p layer handles discovery and replication.

Challenges we ran into

One of the toughest aspects of this project development was the mentality change we had to implement, as we are quite used to work with a centralized system. For example, not being able to have a game host and then some guests, was something challenging to do.

On the other hand, the programming language we used, JavaScript, has challenged us to learn and master asynchronous execution and event-driven architecture, mainly because we do not usually program with it.

Accomplishments that we're proud of

We are very happy to have implemented a full project that combines diverse tools and techniques, mainly ones that we did not know about. Hyperbee, Hyperswarm and Pear are the ones that we have discovered during this weekend and we are proud to have been able to include them in our game.

What we learned

On the game side, we learned that the safest design is to keep rules and UI separate from persistence. The controller decides when a move is valid, the storage layer records the event, and the UI only reflects the current state, which makes the app easier to test and easier to debug.

We also learned that P2P systems need a bit more care around disconnects and state recovery than a normal client-server app. Because peers can drop and reconnect, the app has to tolerate missing messages by relying on the replicated event history instead of assuming every update arrives live in order