Thermomorph Postmortem
Over the past three months, I created and released three horror games - Proctor, Thermomorph, and Arthur’s Nightmare, the latter of which recently went viral. This post is a postmortem for Thermomorph, the second of those games.
Table of Contents
- Inspiration
- Gameplay
- Implementation
- Results
- What I Learned
- Randomness is Hard to Control
- Give the Player Some Busy Work
- Jumpscares are Best When the Player is Focused on Something Else
- Once You Learn the Mechanics, Horror Games Stop Being Scary
- YouTubers Have Their Own Agenda
- Blender Cycles is Slow, Fluid/Fire/Smoke is Excruciatingly Slow
- Put a title on Itch Cover Image
- Conclusion
Inspiration
After releasing Proctor, I went back to the drawing board. I wanted to make a game that was much scarier. I used two tactics to accomplish this.
Imperfect Information
In Proctor, the player can perfectly hear the location of the robo-proctor (assuming that 3D audio works as expected). I believe this makes the game less scary because you always know exactly where the enemy is. For Thermomorph, I wanted to take away as much information as possible in order create uncertainty, while still keeping enough information such that the game is still fair.
Putting Monsters In Your Face
In FNaF, some of the jump scares come not from deaths but from shining the light through the office doors and seeing an animatronic. I felt like the office doors were too small and far away from the view of the player. Instead, I wanted to make sure that the monsters are always in the player’s face. To do this, I put the player in claustrophobic vents with a U shape. This prevents the player from seeing monsters until they’re right up against the camera.
Gameplay
Gameplay in Thermomorph consists of the player sitting in a vent and staring at a motion detector. This detector periodically sweeps across the map showing a dot when the sweep intersects with a monster’s position. The player can look left and right down the vents, as well as shoot a flamethrower with limited fuel. The player must wait until the monsters are right next to them, then fire the flamethrower. The second night adds a heating mechanism that must be periodically reset, and the third night adds in a second monster.
Implementation
Although Thermomorph is a more complicated game than Proctor, I was able to make it in only two weeks. This is because I was able to reuse a significant amount of code, including the node graph, the canvas projection, and general game structure. An early prototype of the game is show below.
Analytics
Thermomorph, like Proctor, uses Sentry for error reporting. Unlike Proctor, I also added game analytics using Keen.io. Any time an event of interest occurs, I send a message to Keen, which stores the messages in an S3 bucket. Later on, I downloaded the messages and did some basic analytics.
Budget
I wanted Thermomorph’s presentation to be better than Proctor, so I spent some money to purchase assets. Overall, I spent $165.48, which is more than I realized at the time.
- $7 on creature scream sound effects
- $95.49 on 3D models
- $62.99 on AWS GPU render time
I was pretty disappointed with having inadvertently spent so much on Thermomorph. For my next game, Arthur’s Nightmare, I tried to spend less.
Results
I found that Thermomorph was about as successful as Proctor - as of now it has 1,287 views and 383 downloads on Itch. I also released on GameJolt, where the game has 188 views and 57 plays.
Analytics
Above is the platform breakdown. As expected, Windows makes up the largest portion of users, however macOS and Linux together make up about a fourth of users. It doesn’t seem as if players on one platform play more games than players on other platforms. The Android games are simply me forgetting to turn analytics off while experimenting with an Android port.
The image above shows how many users progressed to each hour in the game. About 2/3 users did not win hour 1, however this includes the 29.69% of users who did not complete a single game (either by winning or by losing).
Hour | Win Rate | Sample Size |
---|---|---|
1 | 32.57% | 218 |
2 | 17.11% | 152 |
3 | 6.33% | 158 |
Above, we can see the win rate breakdown. These rates are much lower than I intended - I had hoped that the first hour would be really easy, and that the third hour would be hard.
What I Learned
Randomness is Hard to Control
A huge flaw in Thermomorph is that the random behavior of the aliens can result in some runs being incredibly easy while other runs are near impossible. I think the only way to fix this is to hardcode in specific events. For example, shortly after the audio log on the first night, the monster should just make a beeline for you.
Patterns like this feel dirty, but I think such tricks are necessary to make sure that everyone has at least a comparable experience.
Give the Player Some Busy Work
One of the big problems with Thermomorph, especially in the first hour, is that there is too much waiting. In FNaF’s first hour, you have to keep switching between the cameras1, so at least there’s some busy work to do while waiting for the animatronics to attack. The second night alleviates this by adding a heating system that the player can check every few seconds.
Jumpscares are Best When the Player is Focused on Something Else
After playing the game, Herman Chau suggested that that the jumpscares are enhanced by the fact that the player is focused on something else. After watching more people play, this observation appears to hold true. In Thermomorph this object is the tablet - in Proctor this is the test.
Once You Learn the Mechanics, Horror Games Stop Being Scary
While watching people play, I noticed that the first few jump scares were the most potent. After people got into the rhythm of the game and started learning the mechanics, later jump scares elicited less of a reaction. This pattern has held true for all three of my horror games so far.
YouTubers Have Their Own Agenda
After releasing Thermomorph, I found that only two YouTubers made videos of the game (playlist here). I was disappointed as many more videos were made of Proctor. However, it soon became clear why. As I looked at the channels that made videos, I saw that there was a huge variation in the number of views - this occurred regardless of the channel size. This made me realize that YouTube is hit based - it’s all about attracting clicks, and less about building a community (as I had thought previously). These aspects of the YouTube algorithm ultimately influence game selection by YouTubers. Unfortunately, Thermomorph’s theme was simply too boring to be picked up for these kinds of videos.
Blender Cycles is Slow, Fluid/Fire/Smoke is Excruciatingly Slow
I chose to render the visuals for Thermomorph in Blender’s Cycles engine, which I had previously used in Proctor. Because Cycles is a path-tracing renderer, fire actually “casts” light from it’s volume, making the fire effects look really good. By contrast, in the regular Blender renderer, the fire’s light would have to be faked with animated lamps.
However, the fire simulation is excruciatingly slow to render, to the point that it would have been infeasible to render the game in 720p. Even with a 640x360 resolution and an AWS GPU, the animations took hours to render.
Put a title on Itch Cover Image
At first, my Itch cover image was simply a GIF of gameplay. However, clicks seemed suspiciously low. When I got on to fresh, I could very clearly see that, compared to other games on the list, my cover image did not stand out. I deduced that the biggest issue was the lack of a title in the image. I added the title and immediately clicks started to increase.
Conclusion
Ultimately, I was disappointed in Thermomorph - I felt that I had made multiple critical mistakes, both in terms of design and marketing. I also felt that I was retreading too much on territory established by games like Alien: Isolation. For my next game I tried to do something that I felt would be more interesting from both a gameplay and theme perspective.
-
It’s also worth noting that FNaF has a “disapearing spider” effect that Thermomorph doesn’t have. ↩