The Tell-Tale Heart is a prototype built in six weeks by a small team of six people. The goal of the project was to explore interactive narrative by adding in branching gameplay through the use of deceit as a mechanic. Players would have to be aware of their answers, their actions, and the clues located around the world. We also wanted a very distinct art style that was greyscale, 2D in a 3D world that felt like a diorama. Having finished the project, we are very happy with what we were able to achieve, even if it wasn’t everything we had hoped for at the start. Here is what we learned through the process.
What Went Right
Overall our project ran very smoothly from beginning to end. This is due to several factors.
The entire team bought into the concept from the very beginning. The initial idea had been sent out to the entire cohort and that triggered the initial spark of interest from the group. It also helped that there was one person responsible for the creative vision and was able to get everyone focused on a single direction.
We spent a lot of time preparing documentation for the design and art style. This allowed everyone on the team to understand what we were trying to achieve and the process required to get to it. This reduced potential conflicts as we did not have to raise a lot of questions.
From the start, we agreed that we would have a full work day every Friday. We would hold a scrum meeting at the start of the day to cover what we each did and we would show off our work on the projector. This allowed us to stay motivated and understand what the next objectives were going to be.
We were very active in keeping our scope in check throughout the duration of the project. Every week we would look at our outstanding tasks and identify and potential issues. We put many ideas into the parking lot early, some of which came back towards the end of the project. We also had a goal of getting to 60% complete on an item and then moving on to the next task. This allowed us to focus on the most important tasks and not worry about all the small details until the polishing stage.
What Went Wrong
We did encounter several issues throughout the process.
At the start of the project, since the majority of the team had never made a game before, we decided that our programmer would be the gatekeeper to the game and be responsible for implementing all the game assets. While this kept the game very stable, we quickly developed a bottleneck and the programmer was spending too much time dealing with assets rather than coding. What we should have done was create some more tools to allow the rest of the team to implement their own assets in a simple manner.
When we first started working, we did not have a repository system and were using Google Docs to share assets. Once we got the repository working, we had some confusion as to where assets were located. To prevent issues with the build, we created separate folders for each person to put their work files in from which the programmer could grab them. This also lead to assets being submitted, but not implemented or updated. What we should have done is create some more procedures for how to inform the team about what has been changed or uploaded.
Art Process Rules
While we had a very good style guide, we didn’t have enough documentation related to asset creation, mainly on the 3d modeling side of things. We didn’t establish rules for pivot point placement, texture sizes, and object hierarchy. This lead to assets being updated and breaking in the game. The house had this happen several times and became a kind of running joke. What we should do is breakdown into detail the entire process for each art asset type.
What We Learned
This was a very interesting project that had plenty of challenges and learning opportunities.
We learned how difficult it can be to get useful feedback if things are not shown in the proper context. For example, showing off our police officer without a background and compared to earlier iterations gave us a fairly negative response. When showing the same images with the proper background resulted in a reversal of the opinions we were receiving.
Patience is a Virtue
We also learned that we could still get an opinion early on, but to only really critique it once it was in the game itself. Our audio designer kept bringing in all these wonderful audio tracks, but we couldn’t tell him if it sounded right until we could hear it with all the other sounds in the game. It can be very difficult to wait, but it is very important skill to have, especially on a project that is longer than six weeks.
We also learned that while our game seemed fairly simple, it was way more complex than we ever thought, both in development and playability. Trying to add deceit as a mechanic and being able to hide evidence of the lie was incredibly confusing to track the flow through the game. We had to simplify the chain of events to the barest amount possible just so we could test out the results. Once we got it to a point where we thought it was easy to understand, we worried it might be too easy, but players showed us how hard it was to keep their own lies straight.
Overall the whole project was well-run and everyone learned a lot. We are happy with the end result and the team looks forward to taking all these lessons into future projects and possibly developing this game even further.