The following blog post, unless otherwise noted, was written by a member of Gamasutras community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
It’s been over two years since The Painscreek Killings (TPK) launched on September 27, 2017. Prior to that, it took a little over five years to develop. Looking back, TPK struggled in development and failed in marketing, but sold about 40,000 units as of today and somehow was able to keep us afloat as a startup company. Was it all worth it? We would say yes. But that’s not what this article is only about.
What we hope through this postmortem is that we could share our experience from start to finish with those who are in the same boat as us - indie developers creating mystery investigation games using the walking simulator formula - to take what worked for us and hopefully avoid the pitfalls that we faced.
First, about detective games…
Detective games don't sell. At least that's what we come to realize after releasing TPK and looking at most indie games in the detective genre. Either nobody wants to play them or we failed to create good ones. Unfortunately (or fortunately), we didn't know that. Thus, TPK was born.
As a quick introduction, TPK is a 3D first-person view, mystery investigation where the player plays a journalist investigator in an abandoned town trying to find a story before it gets auctioned off and bulldozed. What starts out as a leisurely search turns into a full-blown cold case investigation.
A person was killed. Another person is the killer. Your job is to find out who the killer is. Anyone who have seen the anime ‘Detective Conan’ will know right away what it’s about: there is only one truth and it’s about finding it out. We played quite a number of detective investigation games and while they work, none made us feel like a true detective. Either the game handholds us too much, or the game is too linear, or they are impossible to solve without guides. We decided to make an investigation game that we want to play, one that makes us feel like a detective. Since it’s our first time into game development and we did not have a programmer, we decided to keep it simple: it will be a walking simulator, there will be no in-game character models to make, the programming should be kept to a minimum and done through visual scripting, etc. To counter all that limitations, the game had to be immersive. To achieve that, we did the following.
("The truth shall set you free.")
When watching any detective film, all the audience want is to know who the killer is. If we could keep players guessing who the killer is until the end of the game, it could just work. That was one of the core design we embraced right from the start.
Players should be able to decide how they would start their investigation. We did not want a linear game where players are told to progress from point A to point B. To achieve that, we went for an open-world, free roaming experience. Since the goals are player-created and not dictated by the game, it would enhance the overall detective experience.
We also wanted to encourage players to really look around and search for important clues and items rather than having the items highlighted or outlined. In order not to make it too difficult for players, everything was placed in a believable manner, every puzzle was provided with at least one or more clues, and some puzzles can be solved without finding the hint but through logical thinking. An example in TPK was the slim jim. If you grew up in the 90s, you would probably know that it's a tool used by thieves to unlock car doors. Players might also come across an item that do not make sense at the time they found it, but would make perfect sense later on. One such example was the shovel, which was found in Oliver's Photography store but used in the cemetery.
When it comes to the puzzles, they have to be logical and make sense, just like in the real world. We didn't want to pull a lever in room A that unlocked a hidden doorway in room B without being informed. If players have to access twelve locations sprawled across a town, then the clues and hints need to be logical for them to proceed. The game can be hard or challenging, but it should not be illogical.
We also wanted the game to make players find the right clues to proceed. Rather than knocking on every door found in the game, players need to find clues that would lead their investigation in the right direction. Many recent games have players clear one stage before continuing on to the next, knowing that they could not proceed further if they did not clear that particular stage. TPK, on the other hand, introduced the whole town right from the start. Because of that, it’s futile to knock on every door and see which doors can be opened. Instead, what was the first thing that caught their attention while investigating the Sheriff’s outpost? Was it the mansion where Vivian’s body was found? How about the Church where Scott, the suspect, used to work? It’s these kind of clues, whether direct or indirect, that should give the players a nod towards the direction in which to proceed with their investigations.
(Can you unlock the locked stairway that leads to the secret basement?)
The game had to be in 3d to achieve the level of immersion, which was difficult to achieve in 2d. We also decided to abandon any quest markers, game hints, overhead compass, etc. In short, we decided to make an experience that resembles real life. Anything that does not appear in real life should not be in the game.
One other important factor was getting the atmosphere right. Why do most horror or scary games happen at night? Could a game take place in broad daylight and still make you feel afraid or uneasy? We looked at games, films and TV shows while researching on this topic. There's a movie called The Ring. The American version had a lot of night/dark scenes while the Japanese version had more daytime scenes. The American version had jump scares while the Japanese version didn't employ that technique. When Sadako came out of the television, the American version was scary for that moment, but that moment only. The Japanese version, on the other hand, had me scared for days. So how did the Japanese film have such a stronger impact than the American version? We realize you don't really need jump scares to make a film or game scary. Jump scares are like fluffs with no substance - the impact is there when it happened, but diminishes quickly when it's over. Movies like Sixth Sense and Zodiac created tension and fear in a way that made their audiences remember them long after the movie is over. We wanted to achieve that effect so we focused on building up the tension through music, atmosphere, and most importantly, story hooks. It’s for this reason we decided that TPK will happen during the day.
(The view from the bench behind the mansion shows how TPK tried to incorporate the bleak mysterious atmosphere even though it's in broad daylight.)
Before developing the game, we tested the Unreal Development Kit (UDK) and the Unity 4 game engine. Although UDK seemed more powerful at that time, we decided to go with Unity for the following reason: we wanted to know everything under the hood. UDK seemed to have everything right from the get go while Unity forces us to create everything from scratch. Although development will seem longer with Unity, it will make us understand the engine better. In addition, UDK had a 25% royalty fee while Unity was free. So we went with Unity.
(Early Unity 4 game engine test.)
We set out to make a detective game right from the start. Instead of coming up with a story first, we structured a mold for it. What would it take to make a detective game that we would want to play? We decided on the following design focuses: (1) it has to hook the players, (2) it has to mimic a real detective experience, and (3) it has to make the players feel smart.
To hook the players, we focused on both story and characters arcs. We layered our story like an onion for players to peel, revealing bits and pieces of information crucial to unraveling the whole storyline. We also structured the story into 3 acts, with 2 plot-points and a mid-point inserted in between the acts to hook the players and remind them of the goal. As for characters, we decided early on that all the important NPCs will have their own character arcs so how they were portrayed at the start and who they really were by the end will be quite different.
To mimic a real detective experience, we thought of how would a police solve a case. What we realized was that progression is determined by clues and leads, being perceptive is necessary and that it wouldn’t be easy at all. Our house/workplace was burglarized twice, with the second one involving numerous police officers and a forensic guy who combed through the place picking up bloodstained samples left by the intruders. Three years later, the case is yet to be solved. Thus, we decided on the following: no handholding, logical puzzles that are solved through hints and clues, and a free-roaming open world game.
To make the players feel smart, we decided on the following: provide multiple but subtle hints for every main ‘puzzle’, a breadcrumb system as opposed to trying to make a Sherlock Holmes out of the player, and let players connect the dots themselves to create their personal ‘Ah-ha!’ moments.
Along the way, we also solidified our design philosophy: (1) focus on our strengths, (2) go from general to details, and (3) story is the priority and if we have to compromise, compromise the graphics. That became the foundation for the next five-and-a-half years of developing our game.
We knew the importance of 3-act story structure and how crucial it was to making a film work, but will it work for a game? Googling this topic yields many thumbed down responses and articles. Yet we still went with it because of the influence from films. We needed to have plot-points throughout in order to hook the players and some form of structure for the story to build up from start to finish. Using the 3-act structure also allowed us to re-affirm that the story‘s design was leading somewhere and not just going anywhere. We were able to envision how players might experience the game the way it’s intended to be. It’s not perfect because it limited the free-roaming aspect to a certain degree, but was a necessary compromise for a game like ours.
Once the story’s structure had been laid out, we moved to design sheets. We decided that the era would be around the late 1990s. There were several reasons for that. First, we were familiar with the 80s and 90s, so it was a no-brainer to go with that era. Second, we could research everything on Google without coming up with new designs. Third, we could implement stories and journals based on our childhood years, which helped to cement the story’s believability and add a certain level of realism to the NPCs’ storylines.
(Early village design that would eventually be scrapped for a better layout.)
(Research done to break up different parts of a building in order to make them modular.)
After the story was done and while the design sheets were still being worked on, the 3D asset creation phase started. That time, a volunteer who came to learn about game development helped us with asset creation. His arrival helped to free my partner to learn programming, something we didn’t know would be crucial in helping TPK come to fruition. We knew all games need programmers to make, but we thought that with the help of Unity’s asset store, we would not require a programmer to pull the game off, especially when it’s a walking simulator game. We were wrong. Having a programmer was indispensable.
The task of a programmer seemed simple at first due to the nature of our game. As time went on, however, the task list grew and the difficulty challenge rose. Over time, our programmer's skill improved and she was able to pull off most of them. Later, she even replaced plugins bought from the Unity asset store with her own custom made scripts. This was one big step for us because towards the end of development, we implemented some crucial game mechanics, one of them being the in-game journal.
(Testing uScript at an early stage of development.)
(Notes provided by the programmer on how to use her custom made script.)
A year later, three high school graduates joined our team. Two of them helped with environment/prop asset creation while the third became our level designer. Similar to the first volunteer, the three of them were learning the ropes on game development while helping out at the same time. We also had someone helping out with the design sheets. Now our development team consisted of seven people: one game designer/writer, one programmer, one on design sheets, one level designer and three asset artists. From there on, we implemented some form of project management. Using Trello, we were able to structure our production pipeline more efficiently and help reduce chaos. Later on, we included Moxtra, Asana, Evernote and Microsoft OneNote. They proved indispensable to our workflow and pipeline, and were free to use.
After creating approximately one thousand props and twelve game locations, it was time to test the game. The lighting wasn’t setup yet, and there weren't any audio. Hundreds of warnings and errors that filled the console window when running the game, and we spent more time experiencing bugs than actually play-testing the game. We did a total of three alpha tests and by the end of it, we could see how the game was shaping into. Almost 60% of the initial build were altered or revised, 20% were scrapped, and only 20% of the original design remained. Nevertheless, we have a functional, playable game on our hands.
It would take us another year to build upon what we have from alpha - scripting, asset fixing, game re-designing, setting up in-game lights, implementing sound effects, bug hunting and fixing, etc. It was during this time period that we were introduced to the concept of game optimization. Despite understanding its importance, we were unfortunately unable to achieve it and had to abandon the idea of game optimization, which turned out to be a problem post launch.
Four years after first initiating the project, we entered beta phase. This time, the game was in a pretty good shape for play-testing. There were many factors to consider how the game was faring, but our top few priorities were as follows. First, was the game fun? If it’s not, we returned to the design board to fix it immediately. Second, was the atmosphere fitting? To achieve this, we focused on lighting and background music. At this time, the music used were still commercial soundtrack used as placeholders. But it helped provide the feel of the whole game. Third, were the puzzles logical, with the hints/clues well planted, and was the game well paced? This was where we spent most of our time tweaking. Fourth, were there any assets that were too high in polygon and affecting the frame rate? I believe we spent as many months fixing and re-doing our hi-res assets as we did beta testing. Lastly, were there any game breaking bugs? With each iteration, the game came closer to completion. We did a total of nine beta tests.
It wasn’t until four months before release that we realize Act 2B (the second half of the game) was not working. How did we miss that all along? The design worked on paper, and it worked in the beta tests (the alpha phase was too rough and too early for us to spot this problem). Yet Act 2B felt like a complete roller-coaster ride. All players had to do was to pick up all the keys, connect the dots, and all the red herrings will fade away with the real killer revealed by itself. We didn’t feel like we were playing detective at all. By then, the release date has been announced and we had to decide fast: to leave it the way it was or redo Act 2B altogether. We went for the latter. So we went back to the design board and spent a few weeks changing the design to the following: each NPC now would possibly have a motive to kill Vivian, and the player is free to suspect any of them. Only by going down that NPC’s path can the player know whether it’s a red herring or not. It took many sleepless nights to accomplish but we believe that was the right decision to make.
We worked on pre-production and production at the same time, and found ourselves changing the design a number of times, resulting in lots of wasted production hours and hundreds of unused props. If we could turn back time, we could have focused more time on pre-production, then we’d be able to gauge production time much better. The only areas that we didn’t waste time on were lighting, music composing, and the ending cinematic. For those, we planned well before attempting production. The only area that we couldn’t make it work was game optimization and unfortunately, that came back to bite us later on.
(Going back to the design board to fix Act 2B.)
Game launch & post launch
TPK was released on September 27, 2017. We failed to market the game and there were no press mention. A small number of YouTubers streamed the game during the week’s launch and after that, everything died down. We sold about 800 units in the first two months of launch, which included a Steam Autumn sale. After that, the game sold a weekly average of 50 units. We were artists focusing on making the game as good as it possibly can and didn’t understand the importance of marketing or how to go about it. We assumed that if the game is good, streamers will pick it up, the press will cover it, and gamers will come to buy it. It wasn't like that at all. To make things worse, right after the game launched, we received complaints from gamers about falling-through-the-world, game crashing and not loading, bad frame rate that caused motion sickness, etc. We weren’t sure what to do about it. Prior to releasing, we tested TPK on seven machines, from decent spec PCs to end-of-the line gaming machines. Other than long loading times on a decent spec PC, we didn’t experience any crashing, and took that as an indication that the game was ready to go. But when a number of people experience technical issues with the game, it was a sign for us to look into optimization. Thus, the journey into understanding optimization began.
It took us nine months to finally complete optimization. Although it was a long time, the results were worth it. The optimization completed right before 2018 Steam Summer sale. The game ran smoothly, the frame rates were running twice better and loading time reduced by up to ten times faster, especially when the game ran on an SSD. Gamer complaints also reduced quite drastically. Although a small number of players still encountered bugs, they were mostly non game-breaking. At last, we could declare that TPK was done. We thought there’s nothing else we can do for TPK.
("TPK Fully Optimized" announcement made on Steam.)
Little did we know that three months later, we started tackling localization for the sake of our fans. TPK has a total of over 30,000 words. Finding people to translate it properly was a challenge, mainly due to the small budget we had. Fortunately, the process turned out pretty well.
One thing that we prioritized since launch was customer service. We knew we had to provide service and feedback to anyone who bought or played our game. We addressed all negative complaints as apologetically as we could, and tried to be positive in the face of troll comments. We tried to understand their situation and put the problems they encountered on our fix list. When players commented on the game’s grammatical error, we asked someone to proof-check our content, which resulted in an almost complete rewrite of the game content. When some attendees at PAX South play-tested our and expressed that the game wasn’t interesting enough for them to continue playing, we added more interesting content to the beginning of the game. Lastly, we created a demo which included the complete 1st act of the entire game (which is about 2 hours long), so players can try out TPK before deciding whether or not to purchase the game.
(The demo was launch on Feb13, 2018 for a limited time.)
What went right
1. We made a game that makes us feel like a detective
TPK was a detective mystery investigation game born out of passion. It was made because we couldn’t find any other game that makes us feel like a real detective (there probably are a few that we didn’t know about). We kept that vision all the way till the end and never once had to compromise. That turned out well and we’re glad that many TPK fans felt the same way.
2. The game had as many iterations as it needed
Despite working many late nights, we didn’t rush the project out the door just because the deadline was up. We focused on whether the game would play as good as we had envisioned it from the start. From the first alpha test to the final release build, we had a total of fourteen iterations. The game evolved quite significantly during a few iterations, making it much better than when it was first conceived.
3. Refusing to accept compromises
When Act 2B didn’t pan out the way we wanted, we went back to the drawing board and fixed it right away. Technically, the game was working. But it was soulless and a departure from the detective experience. Not doing anything to improve it would have been disastrous, and a betrayal to those who bought our game. Even though we couldn’t guarantee a hundred percent that the newer version would hold up, we knew it has to be better and didn’t hesitate to change it. Fortunately for us, the changes were worth it.
4. Not giving up on the product even if it wasn’t commercially successful
When TPK didn’t sell well at launch, we were disappointed, to say the least. It was what the industry considered ‘dead product’. However, TPK garnered 86% positive reviews (from launch till today). At some point, however, we decided not to give up on it. After all, TPK was the only product we have. So we started looking for publishers who would promote our game. Sadly, no publisher would invest in a game that’s already out. We also found out that releasing a game in Q3 and Q4 of the year was a big mistake. Although one publisher eventually took us up for a year, their strategy was to simply have huge sale discounts as many times as possible, and asked us if we even considered lowering our price tag. We agreed with the former but declined the latter. The sale discounts helped in some ways but it wasn’t going to last forever. So we took the initiative to localize our game.
Our first localization was Japanese, which we did in-house. Because the translator was also one of the co-writer of TPK, she translated the game beautifully. Not long after the Japanese language was released, a Russian translation team, The Bullfinch Team, approached us and offered to translate it for free. Not only were they fast and their attitude professional, the translation was well done. The Japanese and Russian languages accounted for most of our sales outside English speaking countries for quite awhile. We then went on with seven more localizations. Today, TPK has 9 languages - English, Japanese, Russian, French, Simplified-Chinese, Traditional-Chinese, German, Portuguese-Brazil, and Hungarian - with Korean language coming out soon. About 35% of our monthly sales now come from localization.
(The number of languages currently available for TPK.)
5. Focusing on customer service
Another thing that we did was to focus on customer service. Whether the game was buggy at launch or ran smoothly now, we paid as much attention as we can to the gaming community's concerns and needs. It was a lot of work and sometimes stressful. However, we believe that good customer service is necessary in this day and age, and responding to them shows that we care both for them and for our product. Not only does this build trust between the developers and their fans, it also raises the value of the company and show the gaming community who we really are. In short, we want to invest in long-term gains rather than short-term profits.
What went wrong
1. Going into production when pre-production clearly isn’t done
This was probably one of the biggest issue plaguing our development. Although the list below does not include everything, they are the biggest contributing factors.
We were still developing the story details and working on the design sheets when production started. Not wanting to keep the volunteers waiting, we sent out approved designs to them and have them worked on it. This resulted in more than 400 props that never made it into the final release.
The story went into numerous revisions, which not only increased the list of unused props but also churned out more props to be made. To make it worse, we didn’t have a standardized guideline on asset creation. Since the volunteers were new to game development, they didn’t know how many polygons is the right number to go with. While they had some foundation in CG and 3d modeling, everyone had their own take of the best approach for creating the assets, including the naming. By the time we imported everything into Unity for testing, the hierarchy was in a mess, the game was running between 5-10 frames per second on a gaming PC, and it took a long time to clean up the project file.
We switched game engines halfway through production. Going from Unity 4 to Unity 5 based on the promise of a better lighting and rendering resulted in lots of overtime hours and workarounds to fix the problems. We should have done more tests as part of pre-production’s R&D before deciding whether or not it’s beneficial to switch game engines.
It all stems from our inexperience as a game developer.
2. The game was not optimized before launch
Although this was not the key reason that TPK’s poor launch sales, it was crucial from the gamer’s perspective. We did not know that games HAVE to be optimized until the game’s post launch. Although we’ve read on the concept of game optimization such as poly crunching, object merging, texture atlas and LOD creation, etc., we didn’t set time to really test it out. TPK relied on realism and immersion which mimics a real-life detective investigative experience. So when players fall through the world, or when bugs prevented objects from appearing in game, or when the game runs at 15 frames per second, this breaks immersion and frustrates players. Although we spent the next 9 months after launch to optimize the game, it was a bit late.
(Screenshot taken by a player who fell through the game world.)
3. There was no marketing plan
TPK did not have a marketing strategy, nor did we understand how important that was. Here’s what we did wrong:
We did not hype up the game before launch, nor did we have a social media presence about our product. So when the game launched, it was a game that no one knew.
We reached out to potential press and game influencers two weeks before the game’s launch, hoping that they would take a look at our game. This was a big mistake because we didn’t consider the number of games they have had to review prior to ours, and we didn’t do follow ups with the them because we thought it would be rude. We should have reached out to them months beforehand.
We launched TPK in Q3 of 2017 simply to push it out into the market as soon as we're done developing. Later, we realized from other publishers that Q3 and Q4 are the worst times to launch a game.
We invested about $10,000 to prepare for PAX South, but only sold 50 units in return.
In the end...
The 5+ years before the game’s launch was us dipping our toes into the world of game development, and the 2 years after the game's launch was us learning the importance of marketing and customer service. If there’s one thing that we got out of this, other than not to repeat the same mistakes as those listed in the ‘what went wrong’ section, is that we were able to leave TPK with no regrets. The reason? We did our very best, and we made a game that makes you feel like a real-life detective.
We are now ready to move on to our next game projects.
If you would like to check out our game, please visit the Steam page. And you can follow us on Twitter as well. Thank you for reading.