Artist’s Statement
Our game ‘Not On My Block!’ represents the system of gentrification in a city neighborhood. Specifically focusing on displacement, the gameplay models the process of residents and businesses getting displaced from their neighborhoods due to the development of luxury housing and luxury stores.
Our goal is to immerse players in the inner workings and impact of gentrification through our core mechanics and emergent gameplay. The target audience of our game is all adults. Our game could be appreciated especially by those living in an urban environment. They would be able to understand the significance of the game’s actions when playing as a luxury developer or a resident, especially since gentrification is a system that could impact them or their peers.
One important aspect we wanted to highlight about gentrification was the unfairness of the system in favor of the Developer. We accomplished this through our asymmetric game balance. There is only one Developer in the game and three Residents, but the Developer has unfair advantages to gentrify the neighborhood, such as having more moves and the ability to move diagonally. This models how Developers in real life often have more money and influence backing their moves. Additionally, once a Developer starts gentrifying, it becomes easier for them to do so (adding Luxury Housing hinders the movement of residents and adding Luxury Stores gives the Developer more spawn points), which reflects real positive feedback loops.
However, we did abstract away parts of the system to facilitate gameplay: we have no monetary system, do not get into the specifics of how collective action for Permanent Protection works, don’t provide specific identities (racial, gender, occupation, etc) to Residents, simplify the landscape of neighborhoods to fit onto a gameboard, and represent gradual neighborhood changes with buildings but not finer quality of amenity changes.
The Residents need to cooperate to have a shot at beating the Developer with their more limited resources (i.e. having fewer moves), but they also must balance these collective interests with their own interests (the Resident winner is the one with the most Apartments left on the board). Players enjoyed this tension between strategies and found it realistic.
Overview
Your neighborhood has been home to a vibrant, diverse community for decades. There’s the local bodega with the fat cat, the yearly Fourth of July block party, and the waves and smiles of neighbors as they pass by: this is what makes the neighborhood what it is. However, a new Developer is in town, and they have other plans for this neighborhood—plans that threaten the community that makes this neighborhood so unique.
‘‘Not On My Block!’ is a 2-hour game for 4 adult players that models gentrification in a city neighborhood. In this game, players will take on the roles of Residents and a Developer to determine the fate of this little neighborhood, and whether or not gentrification will change the lives of its people.
The objective of the Developer is to physically push the Resident Apartments off the board, placing Luxury Housing and Luxury Stores as you go. As the Developer, you want to stop the Residents from meddling with your very profitable plans – otherwise your investments go up in flames.
The 3 Residents have competing objectives. As a Resident, you take part in a collective goal to protect as many Resident Apartments as possible—otherwise the Developer will win. However, there can only be one winner: whoever protects the most of their Apartments. You need to strategize how to work together with the other Residents to protect the neighborhood, but also protect your own Apartments.
This game is perfect for players who love strategy board games, especially those who want to experience a real-world system like gentrification.
Concept Map
Not On My Block Game Concept Map (Find link here as well)
Gentrification Concept Map
I’ve attached a concept map for our game and a concept map of gentrification as a system. From the gameplay interactions, you can see how our game illustrates the system of gentrification.
In real life, gentrification happens when developers build amenities such as luxury housing, new stores, and parks, which increase the cost of living. This causes current residents to be pushed out of the neighborhood as they are priced out, which is modeled by our game through apartments literally getting pushed off the board. As the cost of living increases, the neighborhood is seen as more desirable, causing more developers to come in, reinforcing the cycle. In our game, we model this through our developer loop, where it is easier for a developer to win after placing down more and more luxury housing / stores.
On the resident end, in the gentrification concept map, you can see that residents can fight back against development and either stop developers from coming in or prevent the cost of living from going up. In our game, we model this through the permanently protected loop, where if residents collaborate, they can prevent apartments from getting pushed (though we don’t get into specific action details).
Game Bits:
- 15×15 board representing a neighborhood; each square is a ‘block’
- 4 x Identity Cards: 3 Residents + 1 Developer
- 4 x Individual Rule Cards
- 3 x Red Resident Reps
- 3 x Yellow Resident Reps
- 3 x Blue Resident Reps
- 8 x Developer Agents
- 6 x Red Apartment Buildings
- 6 x Yellow Apartment Buildings
- 6 x Blue Apartment Buildings
- 60 x Luxury Housing Developments
- 2 x Luxury Stores
- 3 x D6 Die (Optional)
- 1 X D12 Die (Optional)
Rules
Testing and Version History
All playtests were conducted with Stanford community members in their early-to-mid 20s, fitting our target audience of adult players. Many playtests were conducted with CS 377G students, who are familiar with system game design, and/or a CS 377G TA, who is well-versed in system game design.
Version 1
Our first version had 3 citizens and the developer placing tokens to take control of 12 neighborhoods, with token thresholds depending on if the neighborhood was low-, mid-, or high-rent. The game ended when citizens controlled 5+ neighborhoods or the developer controlled 8+.
We playtested with 3 CS377G students (2 mildly familiar with gentrification, 1 not at all) and a CS377G TA who was very familiar with gentrification. The students were familiar with system game design, and the TA was even more well-versed. Their familiarity with system game design enabled them to give good feedback on game imbalance, and those who knew more about gentrification were also able to point out where we could align the game more with the rules of gentrification.
Citizen cooperation was strong [12:35, 13:45], and players liked the asymmetrical design [20:30, 21:09, and 23:15]. However, the game was very imbalanced in favor of the citizens, and players suggested having mechanics that aligned more strongly with the rules of gentrification such as giving citizens stronger individual incentives and incorporating adjacency. Our TA also mentioned that the game was more of a puzzle than a system.
Version 1 Playtest Final Board
To address these concerns for the next version, each citizen had a specific role, different neighborhoods had different values for each citizen, the developer could invest more to highly gentrify and get additional benefit, and when gentrified hexagons fully surround an unclaimed hexagon, that center hexagon is automatically gentrified.
Version 2
We playtested our second version with 4 CS377G students (3 male, 1 female). Most players knew of gentrification generally, but they could not name specific processes of how neighborhoods become gentrified.
Resident collaboration reflected an emergent gameplay loop where the underpowered Developer could only gentrify one block per every two for the Residents’ turns [11:43, 11:09, 18:37]. This was an unintended reversal of the power structure we wanted to recreate. Players agreed that the fidelity of the game needed to be better, which we kept in mind for our later versions.
Version 2 Playtest Final Board
We playtested again later that day in order to test letting the Developer play first and giving them more tokens per turn to help with game balance. We increased points for protecting neighborhoods with specific resources to incentivize competition among Residents. In order to provide more interaction throughout the game, we introduced the ability for residents to challenge gentrified territory before it became permanently gentrified.
Version 3
We playtested Version 3 with 2 CS377G students and 2 Stanford community members. 3 players were male, 1 was female. All players knew of gentrification processes, such as displacement and exclusion. We played until the end of the game.
From this playtest, we decided to entirely rethink our game. While our game was now successfully a system, players only had fun challenging the Developer over gentrified spaces using rock-paper-scissors [47:27]. The players appreciated our decision to have roles for each resident, but they again wanted better fidelity for game components, and expressed that we should change the hexagon tiles to squares instead [48:20]. We had now overpowered the Developer, considering they could either immediately highly gentrify a space, or gentrify two properties in one turn [22:50].
For Version 4, we made significant mechanic and design changes that better reflect the inner workings of gentrification. First, we replaced hexagon tiles with square blocks to better represent a neighborhood since there was no clear benefit in strategizing with six-sided tile adjacency. Second, simply adding tokens in a neighborhood hexagon to protect or gentrify did not reflect the real-life effects of gentification—in particular, it failed to represent displacing people and businesses into other locations and the positive feedback loop of gentrification. To address this, we changed our key game mechanic from investing tokens on neighborhoods to pushing out apartments by gentrifying the board by building new developments. Residents would now have to strategize together to prevent their apartments from being pushed off the board by the Developer. The goal of the game is for the Developer to push out as many Resident apartments off the board, and for Residents to protect or keep as many of their apartments on the board.
Version 4
We playtested Version 4 with 4 CS377G students. The rules required clarification, so we edited them for the next version. During the playtest, we made a single-element change to alter how many moves players could make each round, going from everyone on a D6/2 (rounded up) to everyone using D6 but the developer adds 2. While this helped, players wanted a fixed number of moves to better build up their strategies, so we implemented that for the next version.
Version 4 Mid-Playtest
As they were familiar with system design, players were able to point out that the game was still imbalanced in favor of the Residents and not very dynamic. As such, we let the Developer use two tokens to gentrify a Store with an area-of-effect advantage (positive feedback loop), push chains of adjacent Apartments, and move diagonally. To empower the Developer more, we also required collaboration between Residents for permanent protection, which increased Resident collaboration (players liked collaborating (e.g., [47:21]). To make gameplay more dynamic, we let Residents strategically place their tiles during setup. Finally, we replaced turn-tracking with a win condition of 50% protected or 50% pushed out.
Version 5
We playtested Version 5 with 4 CS co-term students who didn’t know much about gentrification. Players highlighted that room for strategic thinking and skill gave them a stronger sense of control compared to games that rely heavily on chance [53:58]. One player appreciated how the game afforded clever player strategies over time [54:37], and another noted that the Residents’ ability to cooperate felt true to real life, where communities support one another [44:26]. In short, although none of the players knew much about gentrification, they said they had fun because they felt in control of their strategies and immersed in the theme—especially the Developer who said she felt ‘evil’ gentrifying all the apartments [32:09].
Version 5 Mid-Playtest
However, the game was still imbalanced in favor of the Residents, so we increased the Developer’s moves from 8 to 12 and reduced the win condition for the Developer from pushing out 9 apartments to 7. Additionally, the requirement to go back to Start after each push made the Developer’s progress slower than intended and made having the 8 Developer Agents not as useful [49:27], so we let Developers also respawn at Luxury Stores. To further improve balance, we also added Risk Zones surrounding the Community Center where Developer Agents can catch Resident Reps in this Zone and send them back home.
Residents also relied on a single dominant strategy, always heading straight for Permanent Protection instead of Temporary Protection since the former had the greatest long-term advantage [52:51]. To make strategies more equally viable and rebalance the cost/benefit ratio of Permanent Protection, we made it more difficult to meet the Permanently Protected requirement by only allowing a maximum of 2 Resident Reps on a Community Center and requiring Reps to go back to Start once Permanent Protection is triggered.
Additionally, while Residents enjoyed cooperating with each other, they felt a lack of individual incentive [44:48], so we enabled location swaps between any Resident and the Developer, if both parties agree. This action enables collusion between Residents and the Developer as well as potential sabotage of other Residents.
Version 6
Version 6 Playtest 1, Mid-Playtest
Version 6 was playtested twice.
The first playtest was with 4 CS 377G students. We tested out a few in-game revisions (“A Primer for Playtesting”) that we kept for the next version: Residents can move on Luxury Housing and Stores but it costs them 2 moves (without this, the developer boxed all their Reps in at 22:34); Reps can be on any 2 community squares for permanent protection, and neither has to be the same color as the apartment being protected. This game had strong Resident collaboration (e.g., [44:40]).
Before the second playtest, we rebalanced players by raising Resident moves from 5 to 6 and changing win conditions from 11 protected/7 pushed out to 9 and 9. We also rebalanced strategies by having the player completing the Permanent Protection trifecta now unilaterally deciding which apartment gets protected, sharpening individual competition within cooperation.
Version 6 Playtest 2 Set Up
The second playtest was with 3 CS377G students and 1 TA. We clarified rule changes for balancing players: in the Risk Zone, the Developer must be on the same block as a Resident to send them to Start and then also returns to Start; players keep protected/pushed Apartments in front of them for easy counting; Apartments cannot be pushed into Stores. Both sides discovered viable strategies [20:50, 40:00], showing emergent gameplay and solid asymmetry.
We received strong feedback on player balance, strategy balance, and competition [59:15, 59:45, 1:00:40, 1:07:00; 59:31, 1:06:50] ; one player said “I like that the residents get to work together a lot more while still having secret little agendas”. Observers praised the asymmetrical design [48:00], and players said, “I liked the 3v1 aspect” and “I was surprised how much camaraderie was built through the bullying by the developer.” One player even remarked that they “appreciated the empathy for residents protecting their houses,” a clear signal we achieved an intended outcome. This empathy would have been much harder to achieve had we not been testing with our target audience of adults, and it underscored the value of having players who can not only have fun with the game but also understand its significance.
Additionally, the Developer in Playtest 1 said, “I feel like the ominous black and white developer house, and you guys are the colorful houses” [35:40], indicating the design lined up well with game mechanics. Players also said, “The aesthetic was insanely good” and “I like the colors, and they’re color-blind friendly” [0:52 in Playtest 1].
For our full-length playtest, we added a mechanic to better illustrate the rules of gentrification (“The Mechanic is the Message”): if an apartment gets surrounded with Luxury Housing or Stores, it gets gentrified. We also kept in mind that so far, Permanent Protection was the dominant strategy, and there were no incentives to set houses near Stores.
Version 7
With these small changes, we played Version 7 until the end to see if we could sustain engagement and strategic play throughout the full 2-hour game. 3 playtesters were male, 1 was female; 3 were CS377G students and one was a Stanford community member; all had playtested the game before.
Version 7 Mid-Playtest
Unlike before, residents made ample use of the temporary protection mechanic to make progress towards Permanent Protections [17:20], indicating that there was no longer a dominant strategy. This mechanic also pushed Residents to collaborate, even if they didn’t want to, adding a fun challenge to the tension between competitive and collaborative play. However, players grew distracted towards the end of the game, indicating that 9/18 was too large a number for the win condition, so we adjusted it for the final version to 8.
We also refined rules for clarity, fixed color design, added a first-time example setup, and made quality-of-life improvements. A player suggested separating the legend from the board, but no other player remarked on the legend, we found it was most useful as a reference in play, and we already had a lot of components. We also declined a Resident surround mechanic to preserve asymmetrical balance and reflect real-world power imbalance.
Throughout playtests, we saw players fully embrace their roles, navigating the tensions of competing incentives while experiencing firsthand the dynamics of displacement from gentrification.
Print and Play
To play the game, print the components in the PDF below. You may optionally use 3 D6 and 1 D12 to help count moves each turn. Have fun!
You can also find our full Figma file here.
Images of our game packaging
