Pagetorn
A data-driven horror game
​
What if in a world of unknowns, trapped in an endless labyrinth of story, your survival depended on your ability to learn?
What if the labyrinth learned, too?
View the Game
What is Pagetorn?
A 3D, first person survival-horror game based on the Library of Babel and dark literature that uses information on players’ habits and behaviors to make each player’s experience more unique.
Made alongside the University of Texas at Dallas' ArtSciLab and the Center for BrainHealth.
ORIGINS
Inspired by an online story of an infinite store, SCP-3008, where survivors had to use their limited environment to survive, the player finds themselves in an endless library based off the story of the Library of Babel. In this endless library, who knows what could lie. Attempting to survive, the player would learn about the library, limited magic that lies in its books, and the dark creatures that inhabit it.
Over the course of the summer of 2022, we worked on preproduction and initial research. We created basic movement, AI systems, and set up the basic structure to build upon later using scriptable objects. After a conversation with ArtSciLab's Roger Malina, we thought about how we could incorporate data systems into the game, and suddenly it became a much bigger venture.
​
​
.jpg)
​
ENEMY AI
AI was built to work in a cycle, and they were built to be territorial and realistic. Creatures walk around in packs with one alpha, and when faced with other packs, alphas will enter combat until one dies. However, if they see the player, they will attack the player instead. All this is true unless the big bad, the Librarian, is in the same room, watching. If so, they all run away.
​
DATA SYSTEMS
As if to simulate the feeling of being watched, we researched practices into incorporating the acquisition and use of player data to create a feedback system that changed the experience depending on player actions. For example, a player could walk 200+ meters, and the game would react to that by thickening the fog; if they were known to walk 200+ meters often, we would tag them with a "behavior boolean", an assumption that they walk a lot. A data reactor then reads this information and, through the use of if-statements, reacts to that data. This way, we could check multiple behaviors to create more specific changes, such as checking if they walk a lot (B_WalksALot) AND if they kill a lot of monsters (B_KillsMonstersOften). The assumption in this case is that the player is not really afraid, and may in fact be aggressive, thus the game should do something to change their behavior and push them out of their comfort zone.
​
EXTERNAL DATA
Working with the Center for BrainHealth, we wanted to extend the data system to read definitive external player data, such as heart rate, level of focus, and pupil dilation. Thankfully, they had access to an HP Omniscept, a VR headset that can read those exact values and comes with a Unity plugin. This system is more experimental, but we should highlight that it is compatible with these values, and with more time, the data system could be fully expanded to react to changes in heart rate, create jumpscares when a player is focused on an object, or read how scared a player might be through both heart rate and pupil dilation and react accordingly. However, this would probably work best for a different kind of game.
​​
​
A reaction to this could be despawning all monsters and relying on sound events and atmosphere to spook them, or it could be making the player feel defenseless by making monsters bigger and stronger. Currently, behavior like this tags the player as hostile (B_isHostile), and causes the librarian to chase the player.
A big challenge with a system like this is the assumptions we have to make about players. Sometimes, they may not be accurate. A player that walks around a lot may not always be aggressive, but rather, scared and running away; curious and exploring; or bored and wanting to find the exit faster. This came up a lot during development of the data system, because our assumptions need to be hard-coded in, but assumptions are not solid, merely guesses that may align from time to time.
​​
​
PIPELINE SIMULATION AND CREDITS
Game development is a slow and unsteady process, and working in a group that you must lead in the right direction can be incredibly difficult. Luckily, the talents and motivations of the team made development better, however it wasn't without its challenges. Scope, the lack of a dedicated artist, and the stress of the school semester caused setbacks. Sometimes it felt like we would take two steps forward and three steps back; as we added more mechanics, more and more issues would arise. Everything is interconnected, so there were moments when spaghetti code revealed a web of issues that had to be reworked, or bugs and glitches changed a week's development plan. This, we now know to be tech debt, where rushed code that worked in the moment revealed itself to be detrimental in the future.
​
With two dedicated programmers, a music and sound designer, a producer, and a director/generalist, we had to split up tasks among the team, essentially creating a small pipeline simulation. Our producer, Jesus Guajardo, kept us on track and would later be our line of communication to the Center for BrainHealth, keeping track of our appointments, group meetings, and deliverable dates. Our director/generalist, Daniel Martinez Murillo, aimed the direction of the game and led its design, as well as assigning programmer tasks and providing feedback on music and sound. He also programmed the game's data systems and did a majority of the 3D art.
​
Brandon Coffey was the lead programmer, creating scriptable object systems, inventory, event systems, and tools that helped development; Gabriel Salamoney was a programmer and animator working on the spells system, combat, feedback systems, and the foundation for the maze generator; and Hannah Bursley was the sound lead, creating virtually all the music and sound you hear in the game.
Original Proposal