A two player horror experience to escape the never ending suburbs!
A two player horror experience to escape the never ending suburbs!
Our game is a two player horror adventure game where you must find your way home after being dropped off in a mysterious neighborhood that seems to never end.
When our group first came together to create our capstone project for Research Methods and Professional Practice (RMPP), we wanted to make a horror video game that had some sort of multiplayer aspect to it. Aidan had the idea to create a game where players are stuck in an infinitely repeating neighborhood, and we came up with a lot of good ideas that we wanted to include, so the group decided to stick with that. We spent the Fall semester ideating on different things we would like to include, along with what aesthetics we found appealing and how we wanted players to experience our video game. With the infinitely repeating neighborhood game idea, we wanted to find a way to create a narrative around how the neighborhood would slowly devolve into chaos and horror, but that contradicted with some of the ideas we had about multiplayer, so we came up with the idea of a two player multiplayer adventure style game, kind of similar to It Takes Two and Split Fiction. This would let us show off what we could do with multiplayer and the unique experience that that can provide, along with letting us formulate certain events and situations that we can put our players into.
Throughout our semester of RMPP, we ran feasibility tests to see whether or not our idea was feasible enough to work on until completion, we interviewed experts to see if our ideas seemed valuable enough to include, and gave presentations demonstrating our timeline for getting our game completed. During this semester, we figured out how to generate new blocks depending on where a player is moving, and started working on how we plan on implementing a multiplayer format. Many of the experts we talked to suggested that we hold many meetings to ensure that we all remain on the same page, and how we can merge our concepts into gameplay that is both interesting and engaging for players. We finished that semester with a clear goal in our heads, and decided that working on it as much as possible as early as possible would be the best idea to make sure we are able to incorporate all the ideas that we find intriguing.
We started by experimenting with Godot’s built-in multiplayer systems, because it felt like the obvious place to begin. We were able to get basic networking concepts working, but we quickly realized that it didn’t really fit the final direction we wanted for the game, especially with how we wanted hosting, joining, and persistence to feel by the end of the project. We pivoted toward using Steam multiplayer instead, because it gave us a cleaner path toward the kind of two-player experience we wanted, and it matched the “real game” feel we were aiming for. At this stage the goal was simple: host and join into the main level reliably. We weren’t trying to build every system at once, we just needed a stable base where two players could connect, see the same world, and not desync immediately. A huge chunk of early work went into making sure items weren’t just local props, but actually worked in multiplayer.
We dived head first into the Spring semester, making sure we were on track and each week actively contributing to our capstone project and having frequent meetings to discuss where we want to go with our game. We started by figuring out how multiplayer would work, and how we could add items that would function for both players and be engaging for both players to use. We implemented an item interaction loop using raycasts to detect what the player is aiming at, and then built the pickup system on top of that. The part that took the most work wasn’t picking something up in singleplayer, it was making sure the server and both peers always agreed on who owns the item, where it is, and whether it is held or dropped. This meant we had to solve problems like preventing two players from grabbing the same object at once, syncing transforms cleanly while held, and ensuring that dropping an item didn’t cause it to desync or teleport differently per client. That was one of the first systems where we really felt how multiplayer makes everything harder, because every small interaction needed an authority decision and consistent replication.
We set up placeholder assets so that we could walk around in game and see what it would feel and look like, and how items would interact with the environment. We were also able to implement Steam multiplayer, using a test server to connect two different computers together using the Steam API, and were successful in syncing up both games so that the world would be the same for both players. With multiplayer successful, we implemented our tether system, which let players not wander too far from each other, and added scary visual effects that the players would see when they got too far apart from each other. In the future, we plan on connecting the tether system into a sanity meter that the players share, so they are more forced to stay together. During this time we also added in simple UI systems along with an inventory system, so we can keep track of items and help players feel less lost upon loading the game, while also letting players find themselves if they stray too far from each other. We also figured out how we want the neighborhood block to look, and how we can design it so that it seems like it seamlessly repeats.
During weeks 4-5, we fully figured out the scale that we wanted the neighborhood to look like, while also adding fog to create an atmosphere that fits the aesthetic that we wanted. We also added small things that added complexity to our character, a stamina bar, footstep noises, and heavy breathing sounds when your stamina bar gets low. To make it easier to get into a game, we added a title screen with a placeholder design, so we could figure out where we wanted our host and join buttons to be placed. We wanted to figure out how NPCs would work in our game, so we added a basic NPC and started implementing its state machine along with a dialogue manager that changes the dialogue depending on which iteration the players are on. Once we had basic movement and multiplayer stability, we started layering in actual gameplay state logic. For NPCs, this meant building the early state machine structure (patrol state, talking/interaction state, and transitions between them). We started treating NPCs less like moving props and more like systems that respond to players.
On the player side, we continued expanding the item system so it didn’t just support generic pickups,it supported specific items with unique behavior, like the flashlight. That was an important shift because it meant we were now syncing not just an object exists but an object has gameplay meaning, and it needed to behave the same for both players. During this time we also started developing the cellar level, which is a chase sequence at the very end of the demo, where both players are stuck together and must make the correct decisions on which doors to run through to escape. We also used our Computer Animation class to create a bunch of models for our game, as we wanted our models to be mostly handmade. During this time, we also developed a system for the neighborhood where we only design one block of houses, and from there we copy that design so that there are 5 identical blocks all next to each other. From there we detect where the players move, and move the unused blocks to new positions around the block that had been moved to, so that the players are always in the center block. This let us not have to create a huge number of blocks that would slow down our computers and would be bad for optimization for our game.
For the sake of our capstone and the Atlas Expo, we had to figure out what we wanted the core game loop to look like for our project, and we decided on creating a demo that would showcase the specific aspects of our game that we found to be the most interesting, and what we wanted to build more upon. The demo features a very quick descent into madness, so we could show what it would look like to go from normal to scary while also fitting it in a small timeframe for Expo. We also wanted to highlight the multiplayer aspects of our game, by creating puzzles and sequences that required players to communicate with each other in order to progress. For the demo, the timeline looks like this:
We found that this game flow shows what we found to be our priorities for what we wanted to accomplish with our game, while also having players experience an engaging environment.
In a previous week, we got feedback from a professional that we should start playtesting our puzzles with people in a low fidelity way, so we came up with basic puzzles that could be done on paper with pencil and started testing out our ideas with our friends. The first puzzle we had playtesters do a music/sound matching puzzle, where one player has headphones on and hears a melody, and must recite that melody to the other player who must guess the melody correctly. We found that most players found this puzzle pretty easy, but some feedback we received was that we should find a way to correlate the sounds with a number or color so that describing the melody would be more intuitive to do. The second puzzle we came up with was a symbol drawing puzzle, where one player gets a symbol and they must describe what it looks like to the other player, and the other player must try to draw the symbol accurately. Feedback we got for this puzzle was that this one was too difficult and took too much time, so we decided on making the symbol more simple, while also adding a grid that players can use to describe the placement of aspects of the symbol. The last puzzle we wanted to add but weren’t able to playtest much was a poem that the players receive, and they must decipher what the poem means and try to find symbols that are hidden around the room that must be revealed with a special flashlight. We playtested this one by hiding certain symbols around the paper that we handed to players, and when we took the papers back, the last question we asked was in relation to what symbols we hid on the paper. Some players remember seeing the symbol, but couldn’t remember what exactly the symbol looked like, which shows that players could remember the place these symbols were hidden, but not how they would fit into the poem. We found that these puzzles would showcase unique interactions with players that can only be done in multiplayer, and would still be fun to show off at Expo.
For the video game, we did a bunch of upgrading to models and bug fixing, and put our new custom model for the houses in game, albeit with no interiors. This includes adding fences, revamping textures, adding trees and mailboxes, changed lighting, and more. These tweaks really helped create the aesthetic we were aiming for in our game, and the game began to look a lot nicer than it was originally. By also upgrading a bunch of parts of our game, we could also start working and changing those parts as time progresses so that it feels like the neighborhood devolves at a better rate. We also started working on narratives for the players along with many recurring NPC’s, and what role those NPC’s would play as we progress the story. In the neighborhood, there are many members of the HOA, which is a group of NPC’s who have a cult-like obsession with the neighborhood and keeping it perfect. We came up with the Campbells, a family with a kid and a dog, who would eventually lose their dog and ask the players to find the dog for them, just for the dog to get hit by a bus. There’s also Abigail, the head of the HOA, whose goal is to sacrifice the players to the demon she calls Suburbia, who lives underneath the surface of the neighborhood, and feeds off those who get lost.
For weeks 8 through 9, we started implementing the puzzles and the bedrooms they would take place in, we designed the rooms to account for the poem that we wrote, and made models for a toy piano and an etch-a-sketch that would be a part of the drawing puzzle and the music puzzle. We got a bunch of free low poly models off the internet for a desk, bed, dresser, etc. so that we could fill out the bedrooms to make them feel more lived in. For the neighborhood, we added a big billboard that will have the title screen graphic on it, because we designed our title screen to look like an advertisement/postcard. We also have plans to change what’s on the billboard in future iterations so that it could give hints and clues for how the players can progress through the game. We also added a functioning flashlight that would reveal hidden symbols when the light goes over the symbol, which we are using for both the 3rd puzzle along with the chase sequence. The flashlight system ended up being more than just a light. We needed it to act like a gameplay tool that interacts with hidden content, which meant building a reveal mechanism for symbols that only become visible under the flashlight. This also tied back into multiplayer: both players needed to see consistent results when the flashlight passed over something important, otherwise one player would progress while the other would be confused.This was one of the first times we felt like we were building real puzzle game logic instead of just movement and environment. We also added more interactivity around the neighborhood, making mailboxes openable and more NPC’s to see and talk to.
We met up with a Game Development Club in Boulder, where we gave a presentation about our game and was able to get a lot of valuable playtesting and feedback from other game developers. A lot of people really enjoyed our game, but the feedback we got said we needed to focus on making things more intentional, and have a more definitive gameplay loop for players to go through. Around this time we also started working on our animations for our cutscenes, where we model, rig, and animate in Blender, and port those video files into Godot to get them working as cutscenes between when we need to load levels. The first cutscene we are implementing is a starting game cutscene where we show the two players getting off the bus, then looking at a picture of their house with its address, informing the player of where they need to go. The 2nd cutscene is a POV shot of the kids walking through the neighborhood as they get kidnapped by two HOA members, and brought into the bedrooms. The 3rd and final cutscene shows the players using the baseball bat to break out of the bedroom window, and fall into the cellar doors as they wake up in an underground basement and must escape.
For weeks 10 through 11, we implemented a Quest Hub system that gives players goals and missions so that we could more easily guide them through our game. When you first load into the game, it gives you the quest to “Find your way home” and as separate side missions show up as you progress, it’ll add those goals into your Quest Hub. After you walk through for the first time the neighborhood repeats, the players will hear a heartbeat noise, which signifies that the player characters realize that they’ve seen these houses before. This heartbeat noise will add the quest to go “Talk to the Campbells” in which after talking to them you’re told that their dog ran away. Finding the dog and returning it to the Campbells is a side quest, which will affect different outcomes of the game depending on what the players do. The last quest for the demo leads the players to talk to Bob, as he tells the players to go investigate one of the houses with strange neighbors. This will make the players go to that house which will trigger the kidnap sequence, so that the game can progress. We also added big exclamation marks that will show up above an NPC’s head when they are needed for a quest, so players don’t get too lost trying to find someone.
We also added our first human models into the game, with functioning animations that correlate to whether the NPC’s are walking through the neighborhood, standing still when players approach them, or talking to the players. For progression in our game, we created a system that uses “iterations”, which was initially going to be a tracker that ticked up each time the players moved to a new block, but we decided that that was too simplistic and boring, so we changed the concept so that when the players meet certain “events” the iteration would tick up. This way we could plan what would happen to players on certain iterations while also changing how interactions with NPC’s work, and would also be a flexible system that could be easily added to and changed in the future. We also added a slowly changing environment that gets darker and more eerie the farther the characters progress into the game, so that players can be more immersed into the atmosphere. To add to the “slowly going mad” vibe of the game, we came up with the idea to have small spooky elements that only show up for one player, and not the other. We figured out how to capture what a player is and isn’t looking at, and will occasionally have something creepy crawl out from a wall to just show for one player. There are also giant tentacles that will appear in the distance as the game progresses, and they become more frequent the farther you go.
During weeks 12 through 13, we started implementing the cohesion between the different sections of our game that we had created. To make sure both players get into the game at the same time, we added a lobby that takes place in the bus that will need both players to join to get into the game. We also figured out what we need the players to do to load in the next levels of our game, along with how the puzzles in the bedroom will lead into each other so that players can successfully figure out the puzzles. The lobby wasn’t just a menu, it became a functional part of multiplayer reliability. We made it so the game doesn’t start until the required player count is reached, which prevents half-loaded sessions and weird desync situations. It also let us keep the tone consistent, since the bus lobby feels like an in-world waiting room instead of a detached UI screen.
Towards the end, we implemented a world conveyor style trick where it feels like the players are moving forward through space, but really the environment is being shifted in a controlled way. This was partly for performance, but also because it helps collisions behave more predictably. Instead of pushing the physics system into extreme situations, we could keep the players in a stable zone and move the world around them. That made traversal feel smoother and reduced the weird collision edge cases that show up when you’re constantly moving through repeating geometry. For the first puzzle, we were able to implement the piano to fully work with sound, so that you can press a button and see how that will sound, so that they can decipher the melody. For the second puzzle, we came up with a new shape that would both provide a challenge while also being easy to describe to another player, and have it successfully implemented so that it checks if the drawn picture is accurate to the original.
We also added the interiors for the houses, with a basic layout that has walls and a kitchen area, but no upstairs. For the purposes of the demo, we are adding interactable front doors to each house, but most if not all will remain locked until the players finish the side quest that is associated with the NPC that lives there. We found that keeping all the houses open has players too overwhelmed with all the places they could go, and not fully interacting with the progression we have implemented for the sake of the demo. Also for the sake of the demo, we storyboarded a trailer that we can show to passerbys.
During the last few weeks, we really started working on creating something presentable for the ATLAS Expo. We needed to finish up our documentation, make a video/trailer, and make a website. This was also the time we did some more playtesting and began fixing a lot of the bugs that were still present all throughout the game. We also fully finished up what our graphic design would look like, implementing a finished title screen with font styling for all the text.
