Even with Perseverance, you will not avoid mistakes news - Perseverance: Part 1

Hi everyone!

Since our last entry written for indieDB concerning Perseverance was focused on things that worked during development of the game, I thought I share with you the other side of the coin as well.
Preparing a Post Mortem is not the coolest thing you can do as a developer but I believe that learning from other people’s mistakes can be valuable.

Team changes

Since my early career as a game developer I always considered this industry to be one of the best for one reason: your education doesn’t matter as much as your skills and dedication do.
When I first started working on 9 Clues: The Secret of Serpent Creek I had a crazy idea that the whole team would grow and mature along the way. So we did. We upgraded from sketches to Blender. We moved from flat hand drawn 2D backgrounds to animated, 3D ‘paintovers’. We learned how to work more efficiently and pay attention to all aspects of a game design: dialogues, pacing, level design, level art. Everything we created along the way got better and better. We grew as a team and as individuals.

This unfortunately didn’t happen while working on Perseverance.

Even though we were using Fungus, which is a tool specifically designed for creating visual novels, we faced challenges with coding and design. This was due to a couple of facts.
First of all, the initial person responsible for the code didn’t clean it up before moving on and giving the project to another developer. A person leaving his or her post in the middle of development (for any reason) can cause error and this is what happened in our case. The hiccup from various, ‘wild’, initial ideas embedded in the project was present till the final hours prior to launch. Plus I felt like the project is loosing its most important member.
Secondly, working with people with small amount of experience is risky. In our case the amount of time needed to actually gain momentum and focus on puting tha game together rather than learining how A and B work together, took a bit too long. A delay in development apartment created delays in other areas. All due to the fact that the adjustment period was not taken into account when intially planinng our schedule.

Lesson learned: adjust your estimates and take time to keep things in order

Not creating projects technical specification

The initial vision for the game changed after six weeks of development. The first Vision Doc described a game that was ‘super-indie’. With time, many ideas came up about the game’s presentation and amount of detail that needed to be included. We agreed on reaching a certain level of quality. But somewhere along the way I forgot to make sure that all the artist work within the same framework. This made backgrounds and characters being imported into the project in many resolutions and sizes. Not to mention files were named in both Polish and English which made navigation around the project a hassle. Having a Technical Document with all the resolutions and sizes described straight from the beginning would save us a lot of time and errors late in the development. Moreover, such document is a good way to introduce new people joining the team to the workflow and rules of the project. Of course, questions may always arise but Tech Doc keeps them to a minimum and when they do arise, most of the time they are very important.

Lesson learned: always create a Technical Document, even for small projects.

Late decisions

I like working on single player linear games because their development is a bit more predictable. If you stick to your initial idea and vision there isn’t much that can pose a threat to your plan later on. Messing with the UI and filling plot holes late in the development created many smaller issues that needed to be dealt with. Since the game is dialogue based, every major change in a dialogue required to alter all that came prior to it and all that comes after. Spelling errors and logic errors begin to occur. Once you make a fix in one place you need to include its affect in another.

This requires to go through the story again and again. After a while, as a writer, you may lose interest in the story as you know it top to bottom. This may also lead to yet more mistakes and errors since you are so familiar with the story that you stop paying attention. And if your text files were sent for proof reading and localization without those late changes, you have a problem.

Lesson learned: wait with proofreading and localization of your text until you are 300% sure there won’t be any further changes.

Pacing

I was responsible for the main story and the way it unfolds in front of a player. I watch a lot of movies and I’m a huge fan of the ones that build up slowly but make you more engaged with every minute. But games are not movies.

I was unaware that some gamers might find Jack and Natalie’s story boring. The beginning of the game does carry an emotional charge but it also can create a sense that, it is all that the game is about. To fix this we had put a foreshadow of Karen (the secret agent) and later on another one of Jane. This helped with the general pace of the game but it did create additional amount of work. With a limited number of resources this often happens at the expense of other aspects of game creation.

Lesson learned: test your story (gameplay) as soon as possible and stay opened to change.

This was not a perfectly ran project. But none of them are. I have huge respect for people involved in big game projects such as The Witcher or Dark Souls because I know how much hard work and attention a project needs to feel polished. Even if you pay 200% of your attention and put in a hundred of hours you’re still going to get bugs. And that’s fine. As game developers we should be focused on getting better and better in resolving issues that arise before us instead of trying to be prepared for each one of them.

Check the game on Steam so you can judge it by yourself.
Feel free to leave a comment. It’s always great to hear an opinion of a fellow game developer.

Cheers!

Daniel, Tap It Games Team

Follow us on Twitter and like us on Facebook.