The End of It All
The End of It All
The End of It All
overview
overview
overview
Investigate. Exploit. Convert. The ENd of it All is an isometric adventure game in which players must expand the ranks of an eldritch cult.
Investigate. Exploit. Convert. The ENd of it All is an isometric adventure game in which players must expand the ranks of an eldritch cult.
Investigate. Exploit. Convert. The ENd of it All is an isometric adventure game in which players must expand the ranks of an eldritch cult.
Role
Narrative Designer, System Designer
Narrative Designer, System Designer
Narrative/System Designer
Engine
Unreal Engine 4.2
Unreal Engine 4.2
Duration
6 months
6 months
Team Size
22 People
22 People
Platforms
The End of It All is my Thesis Project for my Bachelors at the University of Utah. I worked with 5 engineers, 8 artists, 3 producers, and 5 designers. I joined the team after prototype stage was over as I had worked on another game that had gotten through the selection process.
The End of It All is an isometric narrative-strategy game where players grow an eldritch cult by manipulating townsfolk through relationships, madness, and calculated sacrifice. As Narrative and System Designer, I created the Insanity System, turning emotional instability into a risky but potent gameplay resource. I designed how characters spiral toward (or resist) conversion, mapped out complex relationship webs, and built narrative systems that evolved as the world unraveled. From structuring conversion logic around environmental interactions and item delivery to writing branching dialogue packed with subtext, I helped make each player choice matter—and each loss sting.
The End of It All is my Thesis Project for my Bachelors at the University of Utah. I worked with 5 engineers, 8 artists, 3 producers, and 5 designers. I joined the team after prototype stage was over as I had worked on another game that had gotten through the selection process.
The End of It All is an isometric narrative-strategy game where players grow an eldritch cult by manipulating townsfolk through relationships, madness, and calculated sacrifice. As Narrative and System Designer, I created the Insanity System, turning emotional instability into a risky but potent gameplay resource. I designed how characters spiral toward (or resist) conversion, mapped out complex relationship webs, and built narrative systems that evolved as the world unraveled. From structuring conversion logic around environmental interactions and item delivery to writing branching dialogue packed with subtext, I helped make each player choice matter—and each loss sting.
The End of It All is my Thesis Project for my Bachelors at the University of Utah. I worked with 5 engineers, 8 artists, 3 producers, and 5 designers. I joined the team after prototype stage was over as I had worked on another game that had gotten through the selection process.
The End of It All is an isometric narrative-strategy game where players grow an eldritch cult by manipulating townsfolk through relationships, madness, and calculated sacrifice. As Narrative and System Designer, I created the Insanity System, turning emotional instability into a risky but potent gameplay resource. I designed how characters spiral toward (or resist) conversion, mapped out complex relationship webs, and built narrative systems that evolved as the world unraveled. From structuring conversion logic around environmental interactions and item delivery to writing branching dialogue packed with subtext, I helped make each player choice matter—and each loss sting.
Screenshots
Screenshots
Prototyping
Prototyping
I joined the project after the initial prototype was completed, and was immediately impressed by its open-ended design. Even with just three characters in a single store, the branching conversations and relationship mechanics showed immense promise. I knew there was something special worth expanding.
I joined the project after the initial prototype was completed, and was immediately impressed by its open-ended design. Even with just three characters in a single store, the branching conversations and relationship mechanics showed immense promise. I knew there was something special worth expanding.
I came onto this project after it was done with its prototyping stage. It had a very strong base which you can see here in this trailer.
What I really liked about the prototype is how open ended it was and the number of conversations you could have even when it was limited to just 3 people in the store.
I was deeply impressed by the relationship system integrated into the game, seeing immense potential for its future development.
Major Contributions
Major Contributions
Major Contributions
Insanity System- System Design
Insanity System- System Design
Insanity System- System Design
Result🎉
A system that added stakes to the converting process in the game to avoid being just a spam fest for the players. It raised emotional stakes by forcing them to decide what characters to sacrifice to access more content and players were given an out of getting rid of characters they didn't like. Insanity turned into a resource that players needed to manage and take care of and going too crazy with too many characters meant the game would end.
Result🎉
A system that added stakes to the converting process in the game to avoid being just a spam fest for the players. It raised emotional stakes by forcing them to decide what characters to sacrifice to access more content and players were given an out of getting rid of characters they didn't like. Insanity turned into a resource that players needed to manage and take care of and going too crazy with too many characters meant the game would end.
Result🎉
A system that added stakes to the converting process in the game to avoid being just a spam fest for the players. It raised emotional stakes by forcing them to decide what characters to sacrifice to access more content and players were given an out of getting rid of characters they didn't like. Insanity turned into a resource that players needed to manage and take care of and going too crazy with too many characters meant the game would end.
Problem 🔍
During playtests and internal discussions, it was obvious that the game didn't have any sense of challenge or progression. A Major flow with the core loop was that nothing was preventing players from going around just spamming all the buttons and not enjoy the deep relationship system we wanted to create.
Problem 🔍
During playtests and internal discussions, it was obvious that the game didn't have any sense of challenge or progression. A Major flow with the core loop was that nothing was preventing players from going around just spamming all the buttons and not enjoy the deep relationship system we wanted to create.
Problem 🔍
During playtests and internal discussions, it was obvious that the game didn't have any sense of challenge or progression. A Major flow with the core loop was that nothing was preventing players from going around just spamming all the buttons and not enjoy the deep relationship system we wanted to create.
Solution 💡
I designed and implemented the Insanity System—a risk/reward mechanic where every character has an insanity threshold and belief level that must be met before they can be converted.
Gaining Insanity makes characters more effective at converting others.
Players must strategically manage which characters to use, when to rest them, and when to sacrifice them.
This transformed Insanity into a resource that’s both powerful and dangerous.
insanity LETS CHARACTERS DO MORE OUTLANDISH THINGS. it MAKES THEM BETTER AT CONVERTING PEOPLE, BUT IF THEY GO TOO INSANE…..
Solution 💡
I designed and implemented the Insanity System—a risk/reward mechanic where every character has an insanity threshold and belief level that must be met before they can be converted.
Going insane makes characters more effective at converting others.
Players must strategically manage which characters to use, when to rest them, and when to sacrifice them.
This transformed Insanity into a resource that’s both powerful and dangerous.
insanity LETS CHARACTERS DO MORE OUTLANDISH THINGS. it MAKES THEM BETTER AT CONVERTING PEOPLE, BUT IF THEY GO TOO INSANE…..
Solution 💡
I designed and implemented the Insanity System—a risk/reward mechanic where every character has an insanity threshold and belief level that must be met before they can be converted.
Gaining Insanity makes characters more effective at converting others.
Players must strategically manage which characters to use, when to rest them, and when to sacrifice them.
This transformed Insanity into a resource that’s both powerful and dangerous.
insanity LETS CHARACTERS DO MORE OUTLANDISH THINGS. it MAKES THEM BETTER AT CONVERTING PEOPLE, BUT IF THEY GO TOO INSANE…..
tHEY dIE!
Design Process
Design Process
Understand role of the system
The system had to support the relationship system while still adding challenge to the overall game as well. The Insanity System had to:
Prevent players from spamming dialogue options
Encourage deeper interaction with character relationships
Support the game’s Lovecraftian tone
Answering these helped shape the system's core mechanics.
Understand role of the system
The system had to support the relationship system while still adding challenge to the overall game as well. The Insanity System had to:
Prevent players from spamming dialogue options
Encourage deeper interaction with character relationships
Support the game’s Lovecraftian tone
Answering these helped shape the system's core mechanics.
Start Small then COmplicate
At first, insanity was a simple threshold. But I iterated to add some variability and to give emphasis to the relationship systems:
Conversion methods now vary in insanity gain
Affinities between characters reduce insanity loss and increase success
Overusing one converter adds risk, encouraging rotation and planning
Start Small then COmplicate
At first, insanity was a simple threshold. But I iterated to add some variability and to give emphasis to the relationship systems:
Conversion methods now vary in insanity gain
Affinities between characters reduce insanity loss and increase success
Overusing one converter adds risk, encouraging rotation and planning
Understand role of the system
The system had to support the relationship system while still adding challenge to the overall game as well. This meant boiling down the overall system to get to such a point that it could answer three questions as follows:
How to stop players from just spamming dialogue choices?
Does the system make players engage more with the relationships between characters?
Does it fit the theming of the game?
The easiest question to answer was the last one due to Insanity being such a core part of Lovecraftian Games. Now came the question of how to incorporate it into the game itself.
This is a quick little machination to show how the insanity system works in the conversion of Zach from Josie POV. You have to get her to a certain insanity before you can use some of the other converting techniques, but you run the risk of making her too insane stopping the simulation instantly!
This is a quick little machination to show how the insanity system works in the conversion of Zach from Josie POV. You have to get her to a certain insanity before you can use some of the other converting techniques, but you run the risk of making her too insane stopping the simulation instantly!
Hover Over the Image!
Change the WOrld
As players performed more deranged actions, the world began to reflect their madness. We updated environmental cues to show the town's descent giving players that their actions had consequences.
Change the World
Changing the World was one that arose from the improvements the Insanity System brought. If you're doing insane things, then the world should reflect that and show up in the world. It's also nice for players to see the town descend into chaos and madness
Narrative Design
Narrative Design
Narrative Design
Create Characters
If we wanted the relationship system to WORK, we needed to have dynamic characters that players would care for.
I was tasked with creating a web of interactions between all the characters we had designed, so I made some requirements that all characters needed to have in order to be viable for the game.
Characters should Have:
Physical Traits
Personality
Friends
Enemies
Characters similar in media
This made it easier for the team to write consistent, compelling characters.
Create Characters
If we wanted the relationship system to WORK, we needed to have dynamic characters that players would care for.
I was tasked with creating a web of interactions between all the characters we had designed, so I made some requirements that all characters needed to have in order to be viable for the game.
Characters should Have:
Physical Traits
Personality
Friends
Enemies
Characters similar in media
This made it easier for the team to write consistent, compelling characters.
Make Relationships
Relationships were the lifeblood for the game, so we needed to plan out how relationships start off and where they end up.
I decided to use 3 emotions of Dislike, Neutral, and Like as they were the easiest division of emotions to understand how you stand with another character.
Characters having personalities made this easier as nicer characters would be easier to go through relationships and would be liked by more people.
To avoid characters feeling like stereotypes, I designed unexpected relationships between them—connections that seemed unlikely on the surface but revealed depth and logic as players explored each character. This approach added nuance to the cast and made the relationship system feel more dynamic, surprising, and rewarding to engage with.
Make Relationships
Relationships were the lifeblood for the game, so we needed to plan out how relationships start off and where they end up.
I decided to use 3 emotions of Dislike, Neutral, and Like as they were the easiest division of emotions to understand how you stand with another character.
Characters having personalities made this easier as nicer characters would be easier to go through relationships and would be liked by more people.
To avoid characters feeling like stereotypes, I designed unexpected relationships between them—connections that seemed unlikely on the surface but revealed depth and logic as players explored each character. This approach added nuance to the cast and made the relationship system feel more dynamic, surprising, and rewarding to engage with.
Make Relationships
Relationships were the lifeblood for the game, so we needed to plan out how relationships start off and where they end up.
I decided to use 3 emotions of Dislike, Neutral, and Like as they were the easiest division of emotions to understand how you stand with another character.
Characters having personalities made this easier as nicer characters would be easier to go through relationships and would be liked by more people.
To avoid characters feeling like stereotypes, I designed unexpected relationships between them—connections that seemed unlikely on the surface but revealed depth and logic as players explored each character. This approach added nuance to the cast and made the relationship system feel more dynamic, surprising, and rewarding to engage with.
Make A Critical Path
To establish a strong foundation for our minimum viable product, I designed the critical path around the fewest necessary conversions. However, relying solely on dialogue for conversion quickly became repetitive. To address this, I expanded our mechanics by integrating Item Delivery and Environmental Interactions.
I then created a comprehensive design guide that mapped out all conversion routes based on three core pillars:
Relationships
Environmental Interactions
Item Delivery
Each character was given unique conversion conditions tailored to their location, personality, and relationships. These systems also integrated with our insanity mechanic, assigning clear resource costs and showing how relationships could evolve dynamically over time.
Make A Critical Path
To establish a strong foundation for our minimum viable product, I designed the critical path around the fewest necessary conversions. However, relying solely on dialogue for conversion quickly became repetitive. To address this, I expanded our mechanics by integrating Item Delivery and Environmental Interactions.
I then created a comprehensive design guide that mapped out all conversion routes based on three core pillars:
Relationships
Environmental Interactions
Item Delivery
Each character was given unique conversion conditions tailored to their location, personality, and relationships. These systems also integrated with our insanity mechanic, assigning clear resource costs and showing how relationships could evolve dynamically over time.
Write Dialogue
I wrote branching dialogue for several characters—primarily Amelia and parts of Dean.
This is where all the previous work came in handy, I was able to write short dialogue that packed a lot of personality and their relationship with the character they are talking to. I could refer to goals and ways that person to be converted to drop clues in some dialogues to guide players to certain interactions.
To streamline writing and implementation, we transitioned to Workflowy, which allowed easy branching and helped engineers to parse the conversation trees more efficiently.
Write Dialogue
I wrote branching dialogue for several characters—primarily Amelia and parts of Dean.
This is where all the previous work came in handy, I was able to write short dialogue that packed a lot of personality and their relationship with the character they are talking to. I could refer to goals and ways that person to be converted to drop clues in some dialogues to guide players to certain interactions.
To streamline writing and implementation, we transitioned to Workflowy, which allowed easy branching and helped engineers to parse the conversation trees more efficiently.
Write Dialogue
I wrote branching dialogue for several characters—primarily Amelia and parts of Dean.
This is where all the previous work came in handy, I was able to write short dialogue that packed a lot of personality and their relationship with the character they are talking to. I could refer to goals and ways that person to be converted to drop clues in some dialogues to guide players to certain interactions.
To streamline writing and implementation, we transitioned to Workflowy, which allowed easy branching and helped engineers to parse the conversation trees more efficiently.
Post Mortem
Post Mortem
✅Achievments
First title launched on Steam
Independently designed a core system with strategic depth
Created and wrote for characters that resonated with players
✅Achievments
First title launched on Steam
Independently designed a core system with strategic depth
Created and wrote for characters that resonated with players
✅Achievments
First title launched on Steam
Independently designed a core system with strategic depth
Created and wrote for characters that resonated with players
⚠️Challenges
Production bottlenecks: Producers prioritized polishing a single level before building others, resulting in downtime and fewer levels in the final release.
Solution: Ideally what we should have done is spread out the team more. I should've pushed back on the producers a little bit and tell them that we could work on other levels. We could start modeling of the characters, white boxing, and creating basic interactions for the players based on the systems already in place. I will mention however is that I did try to Whitebox some of the other levels but was told that we already had designers working on it.
Shifting win/loss conditions: Frequent changes to the core gameplay loop made system design unstable and delayed polish.
Solution: We should've picked one and stuck with it. I think had we been able to reach the number of levels we wanted it could be worth looking into more and made for a unique experience, but for the cuts and down scoping we had to do it was the right decision even if it made the game not as enjoyable as it could've been.
Limited dialogue pipeline: Only engineers could implement dialogue, creating long turnaround times and reducing iteration speed for narrative content.
Solution: The narrative side should've stepped up more and demanded to know how to use the dialogue implementation even if it was as confusing as the engineers were making it out to be. This would have freed them to work on other systems and polish the code of the game.
⚠️Challenges
Production bottlenecks: Producers prioritized polishing a single level before building others, resulting in downtime and fewer levels in the final release.
Solution: Ideally what we should have done is spread out the team more. I should've pushed back on the producers a little bit and tell them that we could work on other levels. We could start modeling of the characters, white boxing, and creating basic interactions for the players based on the systems already in place. I will mention however is that I did try to Whitebox some of the other levels but was told that we already had designers working on it.
Shifting win/loss conditions: Frequent changes to the core gameplay loop made system design unstable and delayed polish.
Solution: We should've picked one and stuck with it. I think had we been able to reach the number of levels we wanted it could be worth looking into more and made for a unique experience, but for the cuts and down scoping we had to do it was the right decision even if it made the game not as enjoyable as it could've been.
Limited dialogue pipeline: Only engineers could implement dialogue, creating long turnaround times and reducing iteration speed for narrative content.
Solution: The narrative side should've stepped up more and demanded to know how to use the dialogue implementation even if it was as confusing as the engineers were making it out to be. This would have freed them to work on other systems and polish the code of the game.
⚠️Challenges
Production bottlenecks: Producers prioritized polishing a single level before building others, resulting in downtime and fewer levels in the final release.
Solution: Ideally what we should have done is spread out the team more. I should've pushed back on the producers a little bit and tell them that we could work on other levels. We could start modeling of the characters, white boxing, and creating basic interactions for the players based on the systems already in place. I will mention however is that I did try to Whitebox some of the other levels but was told that we already had designers working on it.
Shifting win/loss conditions: Frequent changes to the core gameplay loop made system design unstable and delayed polish.
Solution: We should've picked one and stuck with it. I think had we been able to reach the number of levels we wanted it could be worth looking into more and made for a unique experience, but for the cuts and down scoping we had to do it was the right decision even if it made the game not as enjoyable as it could've been.
Limited dialogue pipeline: Only engineers could implement dialogue, creating long turnaround times and reducing iteration speed for narrative content.
Solution: The narrative side should've stepped up more and demanded to know how to use the dialogue implementation even if it was as confusing as the engineers were making it out to be. This would have freed them to work on other systems and polish the code of the game.
📘Takeaways
Time management and clear milestones are critical to ensuring the full scope of a game is achievable and polished.
Pivots are healthy—stepping back to reassess can lead to a stronger, more focused product.
Interactive feedback matters—players respond positively when their choices visibly affect the game world.
📘Takeaways
Time management and clear milestones are critical to ensuring the full scope of a game is achievable and polished.
Pivots are healthy—stepping back to reassess can lead to a stronger, more focused product.
Interactive feedback matters—players respond positively when their choices visibly affect the game world.
📘Takeaways
Time management and clear milestones are critical to ensuring the full scope of a game is achievable and polished.
Pivots are healthy—stepping back to reassess can lead to a stronger, more focused product.
Interactive feedback matters—players respond positively when their choices visibly affect the game world.
Platforms
Steam
Role
Narrative/System Designer
Duration
6 Months
Team Size
22 People
similar work
