Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Postmortem: The Painscreek Killings

    [11.07.19]
    - Fery Tomi

  • The Execution

    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.)

Comments

comments powered by Disqus