Artists’ Statement
NYC Pigeon Simulator grew out of our fascination with the chaos and strange social rules that define city life, but we imagined everything from the perspective of pigeons making their way through New York. Our real goal was never to build a high-stakes strategy game. Instead, we wanted something friends could enjoy together, whether everyone is hanging out in the same room or playing from totally different places. This is the kind of game you pull up when you want a light-hearted competition that can flip into collaboration at any moment, where the only thing that really matters is the shared experience and the laughter it sparks.
Everything in NYC Pigeon Simulator, from the unpredictable minigames to the shifting board tactics, is about sparking moments of ridiculous rivalry, surprise teamwork, and plenty of inside jokes. We want it to be a space where people can go back and forth between trash talk and unexpected alliances, where even the most epic “booms” are just another excuse to laugh together. In the end, this is a leisure-time game meant to make friends feel closer, no matter how far apart they are.
Model
The system at the heart of NYC Pigeon Simulator is built as a loop that connects player action, feedback, and discovery in a way that feels lively and social. When our team set out to design NYC Pigeon Simulator, we wanted to build a system that balances clarity with creativity, giving players a strong sense of direction but also the freedom to find their own way through the game. Everything starts in a shared lobby where friends, whether together in person or miles apart, pick their pigeon identities and get a quick introduction to the world. The in-game tutorials are there to set expectations and walk players through the core objectives and how the board operates. Players eventually learn how to earn tokens in fast-paced minigames and how to use those tokens to place or swap tiles on the main city grid. The goals and the board’s basic logic are explained from the beginning, so everyone feels grounded and ready to participate.
Once the action shifts to the board phase, the game’s true depth starts to reveal itself. Each player takes a turn spending their tokens to place a tile anywhere on the board, or even to overwrite a tile that someone else has already put down. The board itself is a seven-by-seven grid, and the challenge is to create a path from the center to a corner. If you finish a path to a rival’s corner, that player is removed from the game, and the competition narrows. On the surface, the objectives are clear: earn tokens, make connections, and avoid getting cut off. What is not explicitly taught in the tutorials, though, is that you can sabotage others by overwriting their paths or cutting off their strategies. This is an intentional design choice. Instead of spelling out every tactic, we wanted players to explore, experiment, and slowly realize that the board is a living system, where every decision can ripple outward and change the outcome for everyone.
As the game continues, new strategies and dynamics start to emerge. Friends might form temporary alliances to block a common threat, or quietly change their plans to survive one more round. The sense of rivalry and collaboration grows with each session, and every player has the opportunity to shape the board in ways that surprise even themselves. By the standards of the MDA framework, the mechanics provide the structure, the dynamics emerge through play, and the aesthetic comes through in moments of surprise, playful sabotage, and shifting alliances. Over time, players do not just follow the rules; they discover new ways to enjoy and master the game, making every round feel unique. In this way, the model for NYC Pigeon Simulator follows the spirit of Wodtke’s approach to complex systems: making the underlying structure visible and accessible, while leaving space for discovery, creativity, and ongoing evolution in play.
Concept Map
Formal Elements/Values
From the start, we knew that we wanted to have a multiplayer game in which the players are all interacting and at times working together, but mostly competing with each other, in a player versus player versus player versus player dynamic (2-4 players always seemed like a classic amount). While we were unsure of the minigames we wanted to use, the general outcome was to try and connect your fellow player’s detonator to the hub, and not have yours get connected. The procedures would be play minigame → get tiles → place tiles → check if someone is dead → play minigame → get tiles → … and so on until everyone was dead but one player. The only rules we were certain on were that players who perform well in minigames should be rewarded with more tiles, that players can place or turn tiles, that players should die when a pathway of tiles connects their detonator to the central hub, and that dead players (from the board) were done playing. These ultimately stuck with us, and we added some more along the way, such as how with the minigame we chose, players can only move up/down/right/left, they cannot bump into other players, and if they touch the cars, they die. While almost anything in a game can be considered a resource, our primary resources are the tiles that players are awarded as they play the game. There is also the information that they have about who is close to dying, or whose turn it is, but the primary and most important resource is the tiles themselves. The conflict would be the opposing players during the board phases, as everyone would be trying to kill each other. This part stuck around, and we added the conflict of cars trying to hit you in the minigame. The boundaries are essentially the screen that the player plays in. While our game is fun to play with people while you are in the same room as them, since it is fully multiplayer, it doesn’t require that, and as such, the boundaries are just the laptop that you play it on. The outcome is zero-sum as there would be clear losers (those who die), and eventually a clear winner, as there would be one player left.
As far as the values or aesthetics that we were hoping for, initially these were challenge (competing against one another), discovery (solving the circuit board “puzzle” and finding pieces), and most importantly, fellowship (or the lack thereof as players formed bonds and broke them to try and survive longer). Now sitting at the end of P2, these same three values are the primary ones that we have focused on, and are the aesthetics that create the sense of fun in our game.
Scope
For our game, we wanted to make a whole encapsulated experience, so we went for the MVP approach. While we had many iterations in between, including what kinds of minigames we wanted to include, what theme to make it, what art to choose, we always wanted to have an interactive board that acted as a open puzzle for players, and minigame(s) that let the players compete in a more fun and less serious way. So we decided that MVP was the best approach. That way, we could have a complete game that players can play as many times as they want. While we were successful in making a full game, there are more additions that we would make if we had more time. For instance, we always wanted to have 4-6 different minigames. We took inspiration from games like Fun Run and Pico Park, which have different maps and games but keep the same themes and style. In this way, they can create a cohesive piece that challenges players to think in different ways based on different minigames.
Following in these footsteps, with more time, we would expand our MVP to include minigames such as:
- A fly-over, dropping-poop minigame where you try to land your pigeon’s “payload” on cars and people as they move below you.
- A shooter game where players shoot seeds from their mouth (or poop from their butt, although that may be one too many poop themed games) at other players and compete in trying to get the highest K/D.
- A scavenger hunt where players have to search through trash cans and alleys to find food and points.
- A race through Central Park, where you must keep up with each other and try not to get caught by people, park rangers, or various natural hazards (water, trees, lamp posts, etc.)
There are also more quality of life updates that we would include, such as the ability to customize your pigeon instead of just having 4 set ones, or making power-ups that players can use in the games/board. While there are many additional things that we would love to build upon if we had more time, we are incredibly proud of our MVP and think it is a fun, exciting, and engaging, fully-playable game!
Testing/Iteration
| Testing/ Iteration | Takeaways | What Changed? |
| 1 |
|
|
| 2 |
|
|
| 3 |
|
|
| 4 |
|
|
| 5 |
|
|
| 6 |
|
|
| 7 |
|
|
Gameplay Video
In this video, we simulate a full-capacity game with four players to demonstrate what a complete gameplay experience looks like. We used one computer (Computer 1) with three different browsers — Safari, Opera, and Chrome — to represent three players, and a second computer (Computer 2) running Chrome for the fourth player. To avoid overlapping audio, we muted all browsers except Chrome. In a real setting, each player will automatically hear the game sounds.
The game begins at 00:25 with LuckyRobot7443 creating a room. The other players join, and once the fourth player enters, the game starts when LuckyRobot7443 clicks “Start Game”. At 01:03, all players are redirected to the game’s intro screen. A voting-click mechanism ensures players proceed in sync, avoiding desynchronization. All players experience the intro simultaneously, accompanied by a dark, suspenseful soundtrack to convey the looming possibility of elimination. If it’s not a player’s first time, they can choose to skip the intro using the appropriate button.
At 02:02, after the intro, players are guided through the tutorial. The first screen introduces the mini-game mechanics, showing how players earn tokens by crossing a road. The second screen explains the circuit board mechanics — players select tokens and place them to form paths and eliminate opponents. The final screen illustrates how a player is eliminated when a complete circuit connects their corner to the center.
At 2:47, the mini-game begins. In a real multiplayer scenario, all players would race together. However, since one person is simulating four players here, we see LuckyRobot selected and reaching the other side of the road first. This triggers a 30-second countdown (visible in the top-right corner) for the remaining players to finish. The first pigeon to cross receives 3 tiles; those who finish within the timer get 2; those who fail to cross get 1. Note the background sounds of New York City and the distinct effect when a pigeon gets hit by a car — we’ll let you discover that yourself during gameplay.
At 3:37, the players transition to the mini-game results screen, which displays a podium showing each player’s position and tile rewards. A voting button ensures all players proceed to the next phase together. At 04:00, they arrive at the board screen. Player turns are randomly assigned, and each player can place the tiles earned from the mini-game strategically on the board. The gam returns to the minigame and the flow continues. SmartWizard9368 was eliminated. Between 5:20 and 5:30, we see what his screen looks like. SmartWizard6368 becomes a spectator — they can still watch the rest of the game unfold, accompanied by the message “Spectating – you were eliminated.” Once all tile placements are completed, players return to the mini-game, and the loop continues. In the full game, additional mini-games would be implemented, as outlined in the Scope section.
Around 09:00, only two players remain. LuckyGhost7442 is chosen to go first and, thanks to having three tiles, can eliminate LuckyRobot7443 (who turned out not so lucky) and wins the game. We highly encourage you to try the game with at least one other player to fully experience what it’s like to be a pigeon in New York City Pigeon Simulator.
Behind the Scenes
Just like any game, ours involved much work behind the scenes that no one gets to see. From our lecture on game engines, we decided to use Game Maker as we thought it would be the most user-friendly and easiest for our group since we didn’t need insane rendering or graphics like Unreal or Unity offer. We began designing the game board inspired by puzzle-like circuit board mechanics, similar to those featured in Tiny Room Stories: Town Mystery. Figure 2 illustrates this inspiration.
Initially, we successfully implemented the board mechanics, including the algorithm to detect closed loops. Figure 3 shows the board dynamics working for a single player in a GIF. However, the implementation to accommodate more players was far from being accomplished. We saw that there were some multiplayer features built into the engine in the form of “Rollback” functions and tried using these. From week 6-9, we tried desperately to get Game Maker to show the circuit board updating for all players, however, the rollback functions only accounted for movable players (which, while great for the minigames, didn’t help here at all) and projectiles.
One of our first mini-games was built around a shooting mechanic with obstacles that could also collide with and harm the players. We implemented a fully functional version using generic sprites for players, projectiles, and obstacles. Figure 4 shows a minimal version of the mini-game, featuring a movable player (Player 0) and a randomly moving non-playable character used for debugging. We successfully developed a working version in which four players could connect and play against each other. However, when we attempted to integrate the mini-game with the board, we encountered multiple issues. We initially tried treating board pieces as projectiles — freezing them in place to simulate static components — but the board logic failed to retain information about the existing pieces. As more projectiles accumulated, the game became increasingly laggy and unstable.
We tried running separate boards for each player and sending cryptic information for when various pieces were placed. Like for instance, if a person wanted to place a tile at row 2, column 2, we’d send everyone info that a player died twice (decrypted this meant row 2), and the player shot twice (decrypted this meant column 2), and then spawned in an object for each player at that row, but this became an issue of having to kill off players and spawn projectiles and was both far too laggy and would sometimes a lot players extra turns when they weren’t supposed to have them. Getting a working version of the board together with the minigame with Game Maker was a nightmare that the team easily dumped 3 whole weeks into. In parallel, we started to
So finally, we scratched the game engine altogether and used web sockets with an HTML/JS/CSS base to create a web browser game. While this has been a game changer and allowed us to complete our MVP, it did not come without its hardships. Passing so much information through sockets (players moving, players dying, players completing levels, players skipping intros, players placing tiles, players winning) meant we had to make individual sockets for every action and send/receive these in real time as quickly as possible. While there are many ideas that we would have loved to implement with more time, we are incredibly proud of how seamless the multiplayer sockets work in their current form!
Cut Ideas
Throughout this process, we went through many iterations. In the early stages, we first thought about doing a bomb defusal type of game like Don’t Stop Talking or Everyone Explodes, but we wanted to expand the number of players from 2. So we started thinking about having a competition while working together. From that idea, we started getting into a Jigsaw kind of game, where players have bombs strapped to them and must help each other to overcome challenges while also competing against one another in a last-man-standing kind of game. This overarching dynamic ended up staying, but originally, we were thinking of a dark theme where things were serious. At one point, we had the idea to use an ethics mechanic where there is a story generated with the help of LLMs, and each player has their own role that becomes more and more clear throughout the game. Eventually, players would have an idea of which people were “better” or “worse,” and that would give them insight into who they should target to kill. However, this was very dark, and finding a way to provide ethical situations that were grey enough to not immediately make one player hate more than others, but also get players fired up at one another, was a nearly impossible task. So after thinking, we started talking about Happy Tree Friends, Pico Park, and Fun Run, and how these games use funny and cute art and styles to display gruesome concepts. This contrast makes for games and shows that people love because they have the intense sensations of a person dying, but don’t take themselves too seriously. So we started looking at various online sprite packs to get inspiration on what direction to take with our current minigame→board dynamic. We then came across these pigeons that were adorable and had funny animations, and immediately knew we wanted to run with that. Coincidentally, there is the meme that birds are actually government drones, which gave us the perfect reasoning for why the pigeons are at a threat of blowing up (their hardware could malfunction). So we went in that direction and it ended up being our final product!
Extended Narrative
With our game being so fast-paced with quick actions and meaningful decisions, we didn’t want to bog it down with too much exposition or intro. That is why we kept our current intro to only 4 slides that can be clicked through or skipped entirely. However, the game is a part of a much deeper story that, if we had had more time to work on, could have been explained over the course of the entire game.
For starters, as everyone knows, birds aren’t real. Especially the “mindless” and “stupid” pigeons of New York City. While they may seem innocent, they are secretly government spies – drones that fly, walk, and shit over New York City while keeping surveillance over oppressed citizens. But what happens when these government agents go rogue? That’s where NYC Pigeon Simulator picks up. You and your fellow pigeons are all agents who have one final task before you retire: to pick off the other retiring agents. You and the other pigeons are responsible for terrible, awful, downright deceitful actions (actions that we cannot name, even in this write up) that the government cannot have tied back to them, so the only option is to delete the evidence, and as such, the pigeons that carried out the acts. So, despite all being in the same situation, each pigeon believes that if they can detonate their fellow pigeons, they will be the one allowed to retire. Thus, they compete in life-or-death situations like crossing the busy streets of downtown New York City to be rewarded with tile pieces that they can use to cause their fellow pigeons’ detonation. With more time to work on this game, we could even incorporate a potential special ending where the pigeons refuse to kill one another and instead team up to take down the government, although that may be an idea better suited for the eventual sequel.
Accessibility
Throughout our game, we tried to make it as accessible as possible for all parties while maintaining the integrity of the game, narrative, and mechanics. The most prominent features we implemented were the colors chosen for both the minigame and the board.
In the minigame, the cars are very vibrant, with clear distinctions between them and the road. Figure 5 depicts a minigame run where we can observe the road and standard vehicles. The blue car already features a color that stands out, so its design is mostly a solid shape. The brown car is a bit darker, but to ensure it doesn’t blend in with the road, we gave it two distinct windows so that the complexity of the car contrasts with the dull, single-shade grey road. We also ensured that the brown car never spawns in the lane adjacent to the green grass, as players with brown (redish)-green color blindness might otherwise have difficulty distinguishing between the car and the safe grass. Finally, the cop car is likely the closest in color to the road, so we included a red and blue siren to add a pop of color and made it the fastest-moving vehicle. This ensures it is perceived as distinct from the road.
Now, we will be the first to admit that the pigeons themselves, while having different skins, are not particularly easy to tell apart (Figure 6). However, we felt it was better for the game if the pigeons looked similar rather than having drastic, unrealistic colors like red, blue, or purple. To address this, we spaced them out and assigned each one a unique starting position that corresponds with their player card on the left, so players can easily identify which pigeon is theirs. Additionally, to ensure that players understood when they were hit by a car, we added sound effects that trigger on impact, so a player is never left wondering what happened. Our goal was to make the game as clear and honest as possible.
Finally, in the board design (Figure 7), we stuck with similar principles, especially regarding color. Each player is assigned a vibrant color (red, purple, etc.) that stands out clearly from the other tiles. This ensures that the detonators and the hub at the center are easily distinguishable from the tiles placed by players.
Play Our Game
You can create a room and play with friends and family using the link(open in new tab) below:
Raw files of the game can be found in the following github repo: https://github.com/DKristhelTorres/CS247
NYC Pigeon Simulator Playtest
Check out three different groups of playtesters having fun with NYC Pigeon Simulator!
