Developed by Esaw Adhana, Tesvara Jiang, Dorian Gulley, Jack Ryan, and Kimberly May

Download our game here: https://tesvara.itch.io/someone-call-securi-tree

Artist’s Statement

It’s Big Game Week, and Berkeley is carrying out an organized infiltration of Stanford campus. Their first stop is Flomo Dining Hall. And you are Stanford’s Securi-tree guard, our last line of defense. Your mission is to protect Stanford territory by using all available information to identify the imposters and kick them off of campus. You must carefully examine students’ ID cards, transcripts, GPA, backpacks, and conversations to determine who belongs to Stanford and who doesn’t. Each location will have location-specific time limits, and you must make split-second decisions that will determine the fate of our ownership of campus. 

If you accept too many Berkeley students or turn away too many real Stanford students, we will lose morale on campus and lose the Big Game! From FloMo dining hall to E-Quad all the way to the stadium, the stakes will escalate: more students, smarter imposters, and a tighter time limit. All of your work will culminate into the result of the Big Game. If you are able to protect enough locations on campus, you lead Stanford to victory and become the Cardinal hero!

Can you protect Stanford’s honor and keep our campus our own? Or will the Berkeley Bears succeed in their invasion? The honor of our school is in your hands.

Disclaimer: Someone Call Securi-tree requires knowledge of Stanford’s campus. Players unaffiliated or unfamiliar with the campus will likely be at a disadvantage. We acknowledge that players will be taking on a policing role, which may be uncomfortable to some. We have designed the game to abstract away this sense of authority as much as possible. Our game has no mature themes and can be played by all ages. 

System Model

Initial Decisions About Formal Elements/Values

Our initial design philosophy for Someone Call Securi-tree was centered on adapting the document-inspection mechanics in two of our team’s favorite games: Papers, Please! and That’s not my Neighbor, to gamify a Stanford-Berkeley rival story that would resonate with all of us and our main audience. Here are our initial notes on our narrative: 

Since our game is intentionally designed for any affiliates familiar with Big Game Week and Stanford campus culture, our design hinges on knowledge of real classes, locations, and social cues that our target audience should be able to pick up.

Mechanics

As such, we have built in 4 different mechanics into the game:

1. Identity inspection tools: Clickable elements including ID cards, transcripts, backpacks, and dialogues.

2. Morale bar: A resource representing team spirit tied to player performance.

3. Location progression: A level-based system where each level presents a new Stanford location and increased difficulty.

4. Accessibility options: Easy mode, keyboard shortcuts, visual indicators, and scalable UI.

Dynamics

These dynamics emerge from how players interact with the mechanics over time. For example, with the identity inspection tools players have to quickly evaluate each character that pops up using multi-layered clues from either the script, transcript, or backpack items fostering a fast paced and time-pressured inspection. On top of that time pressure, every mistake the player makes has an immediate effect on campus morale. This error-consequence loop ensures that players take their role of finding Berkeley imposters seriously as it makes each decision tense and impactful. Replayability is also a dynamic as players can aim for redemption in the next round with the shuffled student attributes across runs.

Aesthetics

But beyond just clicking and rejecting, we hope that players feel the strategic satisfaction from uncovering the subtleties and making the right call under pressure. We also hope that when players feel immersed and so much pride to be able to represent Stanford and protect its traditions and the suspense of keeping the morale bar as high as possible as it nears depletion and the final Big Game result hangs in the air.

And to be able to deliver these experiences, we really honed in on our primary mechanic revolves around the multi-layered identity verification, where the player has to click characters on the screen and click through many information sources to look for signs of being a Berkeley imposter. The initial sources of information we decided on were ID cards, transcripts, and SAT scores, but as we further developed the game, we took out SAT scores and added backpack contents and conversation to paint a more full story for each individual. After our June 3th playtest, we also built out more full-fledged logic for each information source to resolve the suggestion that there was too little information being circulated between the characters.

We wanted to involve the Big Game into our storyline, so we decided on a morale-based failure system as our resource constraint. Initially, we wanted to open one location at a time, and have each level be its own splice in the game. So for each location level, the player starts with a finite 100% morale that depletes when they make incorrect decisions like accepting a Berkeley person. And then depending on if morale tanked or stayed high, the score was supposed to increment points on the scoreboard for the Big Game, and then culminate into the resulting Big Game score. The problem with this is that we didn’t understand football rules too well, and we didn’t know how to solve the problem of what to do if one side of the scoreboard becomes so high that the game is irrecoverable. To solve this, we pivoted to making a full MVP and making morale universal across all levels, and implementing longer-standing logic so that the morale bar can sustain more failures, enough to give the player a reasonable chance of making it to the stadium and “play” the football game. We ultimately give the player 9 allowable penalty points for wrong decisions before morale hits 0% on the 10th fault. 

In section, one of our team members tried to draw out the initial plan we had with regards to having characters moving around, the content that should be provided when a player clicks on an NPC, and then the ramping up of difficulty. Our initial plan was to allow the NPCs to walk outside of each given background screen, and then randomly appear at another location. We ultimately did not move forward with this, in part due to complications of implementing, but then also realizing that this would likely be a little too unfair (and unfun) for the player. We realized that we wanted the challenge of our game to be watching out for the details while on a time crunch, not necessarily losing because they didn’t notice a character get away. We also realized that we didn’t have consensus exactly on what we wanted, so we spent this section trying to just get a visual. We settled on each character, on click, to have the three things that could be “wrong” with them (or rather, that would delineate that they were from Berkeley) — their dialogue (e.g. saying something Berkeley-like), their inventory (e.g. carrying something Berkeley-like or otherwise suspicious), and/or their transcript (e.g. having a “fake” transcript/one with an invalid class). Back at this point in our iterative process, we were initially planning on having a multi-day leveling process. The narrative of it being Big Game Week was stronger, as it would make sense for the player to be a security guard across that entire week (where traditionally, Berkeley students would try to pull off shenanigans).

Scope

We have created an MVP. While not fully polished, we built the whole game that can be played from start to finish. You can clear every level in one sitting, but the IDs, backpacks, transcripts, and chat lines shuffle during each run, so no two play-throughs feel the same. We worried our scope was too much at first, but our momentum picked up and we were able to complete the game as a team. 

Testing/Iteration History

Over five structured playtests, spanning from May 20 to June 4, we invited eight classmates and two non-classmate players to stress-test our game. Here is a concise chronicle of what happened in each playtest, what broke, what went well, and what we learned. 

May 20, 2025

For our May 20th playtest, we did not have a game ready for players. All we had was a bunch of assets and a big idea. What we had our playtesters do during the section was to hear our idea, take a look at our assets, and then give Papers, Please! a try. We wanted to hear what their thoughts were about the game Papers, Please! because our game was very similar in mechanics and dynamic.

After walking them through our idea, our initial assets, and our paper, please game, we asked them the following questions: 

1. Does the gameplay sound unique/fun? 
2. What would make gameplay unfair? If the game is meant for Stanford students/Stanford specific, should we still have manuals and have all information present, or should the player have to rely on their own knowledge?
3. Do you think there are ethical considerations portraying Berkeley students as “evil”/“violent” 
4. The current plan is to have the game progress on a level by level system where in earlier levels, the player only needs to manage a few locations. As the game progresses, the player needs to manage many locations simultaneously. Does the difficulty progression sound reasonable?

After talking to our playtesters, here is a summary of the advice that they gave us: 

• Core concept feedback
  • Players liked the “gatekeeper” fantasy once we explained it (“keep good folks in, bad folks out”).
  • Players liked the five-day morale bar and thought that losing too much morale should trigger a dramatic ending animation.
    • Takeaway: Make the morale drop dramatic somehow. 
    • Fixed

• Readability & UI of Paper’s Please
  • Text felt tiny; testers leaned toward the screen to read.
    • Takeaway: Larger fonts, bigger buttons, and clearer click targets.
    • Fixed

• Identity-checking cues
  • Popular ideas: 
    • Mismatched face vs. ID photo,
    • Fake ID numbers, 
    • Having Berkeley bears in their backpack, 
    • Getting lost on campus, 
    • Having bad SAT score, 
    • Taking classes that don’t exist here, 
    • Many errors per person because these are so subtle. 
  • Takeaway: Have to make conversations, ID cards, transcripts, and backpack items per character, and we have to be creative on what is wrong with each player.
  • Done
• Questions from testers (that we were super unsure about as well)
  • How time-sensitive is each decision?
    • We wanted to hold off on this because we don’t have a good idea of how long it will take for us to process all the information from the transcript, the backpack, the IDs, and the conversations. 
  • Will the campus map grow as the game progresses?
    • Presumably yes. We want there to be level progression, so you want more locations as the game progresses. 
  • Can we pressure players so they will make mistakes (completionist vs. time crunch tension)?
    • We thought we were going to do this through opening more locations and making the game faster.

May 23, 2025

By May 23, we had a playable desktop prototype, but it was very minimal. There was almost no assets made other than the original map and a holder asset for each location background. We had classmates run through the one singular level and just click on some characters as we looked over their shoulders. 

Here were some of the observations that they had: 

• Text is still too small. Player is constantly leaning forward. 
• “Is there another place I can go out?”
• On scene change the morale bar is being reset rather. 
  • Takeaway: The morale bar is buggy, and we want to make sure that the morale is continuous throughout the game and not resetting after each location change. 
  • Fixed
• We have not added a significant amount of variance in the sprites yet. 
• UI elements need to be larger in general. Larger bar, interaction panes. 
• Accept versus closing the menu, what is the difference between that? 
  • Takeaway: We need to either make it more clear the difference between accepting a student (closing the whole menu) or just get rid of the option to close the menu so that we can force the game to move forward. (Ultimately, we decided to get rid of the option to close the menu so we can force the player to make a decision on the sprite immediately.) 
  • Fixed
• Currently, if we let them walk off the screen, nothing happens. 
  • Takeaway: We need to work on the dynamics of sprites walking off the screen. If the sprites walk off the screen and then no consequences are being given, that’s a loophole in the game. (Ultimately, we decided that it is not possible for sprites to walk up the screen.)
  • Fixed
• The expectation based on how they move: for them to not have collisions.

May 29, 2025

May 29th was a super quick play test for us. We had just one student, and we had told the TAs that we were going to focus more on playtesting other people’s games as well as fixing our own game rather than doing a playtest because we found that our game not only did not improve from May 23rd that much but it was super buggy. (To make up for this, we did one extra playtest outside of class, see below)

Here were some of the observations that they had: 

• Signals on the main map, exclamation point perhaps to help with debugging and letting us know where the imposters are so we can faster test our game 
• Reading through transcripts is difficult because it is small
• Sometimes frozen when in the inspection screen? 
• We need to have things more accessible:
  • Increase the button size
  • Increase the text size
  • Increase the sprite size
  • Fixed

June 3, 2023 – “Final Playtest” in class. 

By June 3rd, our game was mostly developed. All of the location, background, asset, and information assets were implemented. We already had a bunch of accessibility features implemented as well, for example, volume control, easy mode, and level skipping. Our objective is to uncover bugs in the implementation and also learn from the user which features were nice as well as what new features we need to add to improve the game. We ran two instances of the game at the same time on Tesvara’s and Esaw’s laptops. This setup encouraged the playtesters To share their experiences with each other and build upon them in a way that gave us more feedback as a team. 

Here are our real-time notes that straight up quote the players we worked with as well as our takeaways and implementations: 

Player 1 “It’s like minecraft” Lost first game “Timing out, does that mean that level is over?” –> The transition out of a level is a little jarring and too fast. “The levels are too fast” “It is confusing that they are the same person” Transcript UI is hard to find → Takeaway: New transcript icon  → Fixed “Why does the backpack icon have a background?”  → Takeaway: Make the small fix → Fixed “The levels are really really fast” I would like it if we could slow them down.  → Takeaway: Slow down levels → Fixed: Made level 1 slower and fewer characters, did not really change later levels because most playtesters were ok with the speed

Player 2 “Why would I accept or reject her?” Also lost first game “PoliSci people can’t be in SWID” → LMAO Club connections should maybe be a little more strict. → Takeaway: We should do more research on clubs/ communities on campus or just use the ones that we actually know about  → Resolved: THEY CAN BE IN SWID, even though it is not common! Discrepancies caught but not the obvious ones.  Message chat for sure was the best way  Transcript UI is hard to find “I feel like I wouldn’t know that” → Takeaway: Do better on training portion → Fixed: Made level 1 slower and fewer characters

 

Player 3 Me: Do you know what’s going on?  Player 3: “I have no idea.” Player 4: “I have no idea what I am doing” “We got frozen in Engineering Quad”  “I guess one other thing is that when the level ends, it’s very abrupt. It is very disorienting.”  “Tutorial is not very informative in terms of what is going on story-wise – rn it says ‘Something mysterious is going on, figure it out’” + “Tutorial taking game time is no no” Me: How did we incorporate the manifesto?  Player: I feel like I paid the least attention to the ID card.  Player 3: Not the best tutorial design. Can you embed it in how we play? Can you prompt us to click it in the game instead of saying it? Player 4: Really, all the tutorial we need is: “There are Berkeley students on campus! Find out who they are!” → Decision: To start off the game, we can have a few clickable slides that tell the player what is going on, and they are only focused on the slides and not thinking about the characters.  → Fixed

Player 4 “You know the game Paper’s Please, it’s very much like that” People are not understanding the game. We need to make the name + manifesto more visible → Decision: To start off the game, we can have a few clickable slides that tell the player what is going on, and they are only focused on the slides and not thinking about the characters.  → Fixed “I think you need more names. It has the same names in every place: Tenzin Sherpa, Ryan Field…”  → Fixed “I don’t like how I need to scroll through the chat every time, maybe you can increase the window size.” → Fixed “Save feature, like an XML or JSON to save progress” “Sound effect for losing health”  “I think mismatching the character is a fun one.” “Procedural difficulty. Maybe you can add more diversity in difficult” “On later levels, only one discrepancy.” → These “hard” characters are already implemented

June 4, 2025 – Playtesting new features/onboarding

After the June 3rd playtest, we implemented lots of micro-changes. To make sure everything is working, we chose to do another playtest outside of the class. Our objective was to see if the new onboarding process was sufficient enough to get players through the game with no instruction. We told the playtester absolutely nothing apart from the fact that they would be playing a game made in a game design class and to react to any parts of the game they found interesting vocally.

The playtester read through the newly added “story” screens that open when the game was opened. They laughed at the imagery of Cal students dyeing the fountain blue, and seemed to understand what the story and plot of the game was. Upon entering the first level, they immediately accepted the first student they saw because they presented with a Stanford ID. Even though the student was a Cal student in disguise, the playtester’s outburst of “What!?”, became a learning experience as the new prompt popped up explaining that they had to be more careful and search through the student’s belongings, transcript, and speak to them in order to find out if they were truly a stanford student or not.

By the time the playtester was in the second level, they were playing the game with a high level of proficiency. They checked all of the students’ attributes or potential giveaways, and made many sequential correct guesses, making it very far in the game before eventually losing due to the sheer number of people that had to be checked. (This is good, because we had intended for players to not be able to beat the game in one shot.) From this playtest, we have confidence in handing you our game as it is now. 

Optional Additional Assets and Materials

Evolution of our Design

Ideation

This sketch came from one of our members, where we pulled mechanics from games like Five Nights at Freddy’s where we don’t actually move around and travel to locations, but rather perceive the world through security cameras. We collectively liked the idea, and we liked how it made more “sense” (in that we are ‘travelling’ to locations via the cameras rather than just teleporting there magically), but we abandoned it mainly because we thought if we wanted the player to be able to interact with NPCs at a scene, we couldn’t explain how that would fit the narrative if we are not actually going to the locations. The inspection panel (which shows the users ID, transcript, etc.) would not make any sense, thus this idea was ultimately ditched. Again, the current way we have set the game up doesn’t really explain how the player gets around, but we think it was a worthwhile sacrifice that doesn’t take away too much from the immersion (and didn’t get any concerns during playtesting).

Map 1

This was the first iteration of our map that we used for a while. We liked that it was simple and we liked that it was colorful, but we thought it could very much be improved upon. Namely, it was a little unclear to players what was a location and what was the background. Even if we had the tooltip/hover mechanic that we ultimately implemented, we thought the ambiguousness was detrimental. Additionally, we got this map from https://brendenkoo.com/stanford-map/, which was meant for NSO, and we didn’t like that we didn’t personalize/contribute to its creation, so we ultimately swapped to making one of our own (with some LLM help).

Map 2

This was the second iteration of our map, which looks pretty similar to the current style, except we have several additional locations. Ultimately, we decided against it because we thought it was just too much. At this point, we were still planning on having the NPCs move around between locations, and we realized it would be too confusing to have 20 locations to worry about. Even after we swapped to the level-based system, we still liked our decision since 20 levels seemed like a lot (even if we made every location 30 seconds, that was still 10 minutes of gameplay, which seemed a little too much/repetitive).

Map 3 (Final)

So for our final map, we cut down on locations and also expanded the aspect ratio to be wider so that we can fit the whole screen and so that all of our backgrounds would have the same aspect ratio for cleanliness!

Here is a screenshot of our full Figma design file, we used Figma to design, organize, and give feedback on most of the artwork that we used in the game: 

Sprites

These are four sprites (with their walking animation gifs) of Berkeley students, which we crafted when we were in the early stages of our design process. We were using them for testing purposes, before we properly fleshed out how the player was meant to tell if someone was from Berkeley, but then eventually fizzled them out (since, of course, the whole game relies on the game not being too obvious).

ID Cards

Here are two examples of ID cards. Guess the imposters. (It turns out, both of these ID cards are imposters. Look at the fake ID numbers to tell!). We created these ID cards in Procreate!

Backpack Items

Here are backpack items. The above backpack items are normal, but the ones below this line are red flags.

Transcripts

This was our first draft of our transcripts, and they didn’t change much from then until our final design, but we ultimately decided to remove the name, ID, GPA, and major. We did this mainly because we rethought how we wanted to design our characters. Initially, we were planning on fully hardcoded personalities, e.g. two examples that we created below, but we ultimately decided on a mixture of that, so we can have a more dynamic game. 

Character Mockups

The key idea here being that we would have many, many specific characters, and then manually decide if they were Stanford or Berkeley based on their details. We were very much a fan of this idea as we liked that it allowed us to imbue characters with specific, realistic characteristics, but we ultimately leaned away from it for one key reason: scalability (or rather, lack thereof). Making these characters, and giving them specific transcripts, dialogue, etc. was extremely time-consuming. Sure, we could ask ChatGPT (or any LLM for that matter) to generate characters with specific SAT scores, dorms, majors, etc., but the bottleneck was the transcripts. Since those had to be hand-drawn, we would be stuck manually writing out all the classes and all the names, which we ultimately thought wouldn’t be the best use of our time.

We thus pivoted slightly from this, where all the details are essentially in two groups for each category (e.g. the dialogue, inventory items, and transcripts), based on whether that item was Stanford-coded or Berkeley-coded. As a more concrete example, we have a batch of real Stanford transcripts and a batch of fake“Stanford” transcripts, thus if an NPC spawns and is decided to be Berkeley, we will have a chance to give them one of the bad transcripts. Depending on how obvious the level wants to be, we might give them Berkeley-coded dialogue, inventory, and transcript, but ultimately at least one thing would be incorrect (there always needs to be something wrong that the player can recognize).

Programming in Accessibility

We think we did a pretty good job when it came to accessibility. Here are all of the options we have implemented in the Pause Menu: 

1. Volume can be adjusted for players who might be sensitive
2. All dialogue was visual/written down, especially useful for those who are hard of hearing
3. Player able to enable “easy mode” which significantly reduces stress of keeping track of characters while keeping gameplay similar.
   1. Initially, easy mode relied on red and blue exclamation points to show to the players who were from Stanford and who were from Berkeley, but we ultimately swapped this out to the red “S” and blue “B” for the sake of being inclusive to those who are colorblind.
4. Keyboard shortcuts, like “Press any key to continue” and arrow keys for volume and ESC to Pause.
5. Map has visual cues to tell people where to go and what is clickable.
   Next location flashes momentarily as well as is hoverable with a yellow border with tooltip.
   
   Completed locations remain visible but not clickable with a clear tooltip.
   
   Subsequent levels are hidden from the user by being grayed out, also unclickable with “Level Locked” on hover.
6. Players are given real-time feedback on the first level if they make a mistake (e.g. 1. Rejecting a Stanford NPC or 2. failing to reject a Berkeley NPC).
   
7. Player able to enable “speedy mode” to skip most of the gameplay and just see the ending, just in case the player is on a time crunch or doesn’t want to play through the full game (also helpful for testing purposes)

Here is the full picture of our accessibility features on our pause menu:

Playtests