TideKeeper
Four players share one fishery. Every round they vote on how hard to police themselves, then live in the world that vote creates.
Four coastal creatures share one stock of fish. Anyone can steal, sell, cook, or release. At the end of every round the table votes on how often the police show up next round, so the rules the players complain about are the rules they wrote.
The problem
TideKeeper was built for Designing Games for Research (DESIGN 6197/4197) at Cornell Tech in spring 2026, by a team of four. I worked on game design and development.
A research game has a harder job than a fun game. It has to be worth playing on its own terms, and at the same time the things players do while playing have to actually mean something. Otherwise you have entertainment, not an instrument.
What I wanted to watch was strategy against other people. How do players bargain with each other when everyone is drawing from the same pool? What role does someone settle into across repeated rounds, and do they stay in it once the others have read them? And when there is real risk on the table, how do people decide whether to take it?
That is why the game is a commons. Four creatures draw from one shared fishery, every profitable action depletes it, and nobody can succeed by ignoring what the other three are doing.
What I decided
The vote is the mechanic, not the framing. Enforcement is not a rule the game hands down. Each round ends with a group vote that sets how often the police appear in the next round, so players are continuously rewriting the pressure they are about to play under. Every round becomes a decision the table has to live inside, and it gives the research something to measure. Not what people say about enforcement, but what they vote for right after being robbed.
Four players, one table, no install. The game runs in a browser and seats four people on a single keyboard. P1 on WASD, P2 on the arrow keys, P3 on TFGH, P4 on IJKL, with gamepad input merged into the same player slots so a group can mix controllers and keys without configuring anything. That constraint is what makes it a research instrument you can actually run. No accounts, no downloads, no lobby. You open a URL and four people are playing.
Actions had to be legible from across the table. Steal, sell, cook, release. Four verbs, each with its own sound, so an observer or another player can tell what someone just did without reading the screen. Stealing is the one that matters most for the research, and it is the one you can hear.
What shipped
A playable build on itch.io and a repo you can read end to end.
The whole game is one index.html, holding the gameplay loop, UI, rendering, input handling and the round and vote state machine, with a separate stylesheet for the start page and a documented control scheme in GAMEPAD.md. That is not how you would build something meant to grow, but it is right for a game that has to be handed to a playtest group in one link and read by a grader in one file.
The input layer is fussier than it looks. Movement uses a 0.22 stick deadzone with D-pad input merged in and speed limited so the two do not stack. Action buttons are edge triggered on the press transition, so holding a key does not auto repeat. Guard is a hold of at least 0.25 seconds, while a tap under that opens the build menu. One button doing two jobs, separated by time rather than by another key, because there were only so many keys left on a keyboard already seating four people.
The project carries its own audio and art as well: background music, character sprites for all four players and the police, environment and result screens, fish icons, and a sound effect for each of the four actions.