Make a game in 7 weeks based on 2 out of 6 keywords.
Weekly Reviews every friday.
Must use the Unity Engine.
The most important thing to keep in mind when developing with limited budget is playing to your teams strengths. Our niche strengths were two of our 3d artist with an interest for monster design and a sound designer who could deliver high quality audio. This seeded the idea of creating a horror game.
The horror idea was internally pitched between designers before it was brought up with the rest of the team.
The inspirations from P.T. were there from the beginning.
The core concept of a looping level felt like an interesting design challenge. Looping levels opens up for a lot of reusability which is vital when developing on a budget.
"We should make sure we play to the strengths of our team. I know our 3D-guys are good at making monsters..."
"...What about a horror game?..."
"...Oh yeah! Have you played P.T?"
~Conversation Between Myself and John Walden
The entire first week was dedicated to different types of research.
Mechanical, Technical, and Psychological.
What mechanics do other horror games do well to immerse and anchor the player in the experience?
What tools do we need to develop the game, how do we use them, and what are their limitations?
How do we induce fear. What psychological triggers do we have at our disposal?
Plan of game sequence
We left pre production with a thorough plan of the game sequence, denoting most of our design ideas. Some ideas were cut or modified to create tension and meet our experience goals.
The decapitated man was cut during production. When we got the placeholder model done we noticed the version without him had a better pacing. The death sequence overshadowed the intended climax of the game.
Keeping 12 developers happy for 7 weeks in a row is a challenging task. Team morale is one of the greatest obstacles when it comes to productivity. Some of the solutions we implemented should definitely be considered in any producers toolbag
Cookies and love bombing. post friday reviews we had mandatory fika and encouragement in form of love bombing. These really helped us break down and solve obstacles together.
So many problems can be resolved by asking the right person questions. When working in a short term project with strangers, alleviating the pressure of talking to eachother is crucial. The psychology behind love bombing and sharing sweets can work wonders and make people open up.
By week 5 we had produced several events we thought were scary individualy. However the distribution of the events made the tension of the game peak before we wanted it to, making following loops feel less scary, detracting from the overall experience.
A demon screams at you from a balcony, not only was it intense it was also the first straight up hostile creature the player experiences in the game.
The other being a the radio announcer talking over the PA system in the bar confusing the player.
We arranged playtests with different arrangements of events. After just a few tests it was made clear what events were breaking the pace of the game, and they were cut.
The big weight in a project like this is the feeling of lost work. While there was no doubt the conflicting events had to be cut, spending several days implementing a feature that has to be cut can make you feel unproductive. This is where cookies and reflection play an important role. It allows you to open up a discussion where no one feels hurt when you have to kill their darlings. In reality, it is inevitable.
The Black Rose radio announcer was instead reused in the game trailer giving it a unique touch.
When you eventualy have to kill someones darling make sure it's communicated why and how it benefits the game. Again I want to stress the importance of morale, there were some sad faces when we decided to cut content. What I would like to stress, is that developing and cutting content is important work when shaping a game.
Workflow: Agile - Scrum
The project went beyond expectations, there were of course a few setbacks but due to an effiecient and diverse team, and a proactive workflow most things were resolved in a very short timespan.
Working with experimental engine features is dangerous, there are a lot of things that can break any second. Sometimes they did, which in turn caused some necessary redesign and broken spirits, all of which were eventualy resolved.
You can read about them below in the next section Challenges and solutions.
4 days before the final deadline, the school's distributed perforce licences ran out. Timing could not have been worse as many things had yet recieved their final textures as well as some remaining bugs still breaking the game experience, with no way of synchronizing our assets I thought we would miss our deadline.
Thankfully I did have a personal SVN server set up for Game Jam projects. The entire ordeal cost us 1 day of work resulting in a lot of crunch hours to deliver the final build.
As our go to IT person I took the responsibility to get a new source control system up and running.
I migrated the entire project to a home server (raspberry pi running SVN) and rapidly brief the entire team in how to use tortoiseSVN which thankfully is one of the easier source control systems to manage at small scale. Conflict prevention is a bit trickier to manage in tortoisSVN but the state of the project did not require any big new implementations minimizing those kinds of issues.
The time loss resulted in a lot of overtime the last 2 days.
Some things are out of your hands, and sometimes it's all about solving issues fast and efficiently. Always have a backup. Especially to any indie developer. Make sure to have a plan B for any scenario. Unity collab and Git are two other contenders for source control but when it comes to scaleability and working with formats other than text files it's hard to compete with perforce or SVN.
The first prototype I made when testing scary elements was created in Unreal Engine. Unreal as is a way faster when prototyping 3D games in general due to their robust and designer friendly blueprints.
The prototype was made to experiment with lighting and walking mechanics like dynamic light events, flashlights and head bobbing, in less than an hour. Creating the same prototype in unity would have taken at least an entire workday if not several without any paid assets.