Hello, Stranger! Welcome to the Abyss Postmortem!

For those who don't know, Abyss is a mystery/drama/puzzle Visual Novel developed during the NaNoRenO 2019 game jam. It details the adventures of a group of individuals lost in a very strange place where civilization seems to have perished and the moon is out crush the Earth. To make matters worse, some strange humanoid creatures lurk the shadows, hunting for the next innocent (or idiotic) victim to cross their paths.

Our original idea could not be fully produced in a month (NaNoRenO lasts one month, taking place from March 1st to April 1st) so we decided to focus on creating the introduction to this tale -- a story segment that would introduce players to the main characters and scenario, and also a sort of tutorial to explain and showcase the mechanics we would like to have in the final game (or, at least, some of them).

On a side note, we drew inspiration from games such as Danganronpa (if you played Abyss and your eyebrow raised when characters were introduced, now you know why) and the Zero Escape series.

OK. Now that the introductions are done, let's get this Postmortem started!

What went right!

    1. Finding the right team!

It might sound cocky what we're about to say, but we loved crafting this game and are proud of the final result! There's still plenty of room to improve, but saying we didn't like what we achieved would be lying. And all of this was only possible because we started recruiting people to our team quite early on (and a pinch of luck).

We would like to highlight the work of our two background artists, Lucas and FishyFeathers, who managed to work in sync. Their styles are drastically different but they worked with those differences to produce something incredible: they negotiated the colour pallet, the perspective and vibe the game should have, which areas they would draw and even offered criticism to one another. There was no drama and both of them delivered their work on time. Based on our experience from other jams, finding people like these is not easy, and we couldn't be more proud of them.

    2. Having a backup plan.

During development we had two unforeseen circumstances that, fortunately, we managed to avoid as best as we could. At the start of development we decided to develop the game in Unity. When looking for team members to partner with, we asked if they had previous experience in Unity and if they would be okay to tackle a project like this on that Engine.
However, 1 week and a half in, one of the programmers had to leave the competition due to work circumstances. We quickly set out to look for another programmer, and luckily, we managed to find one. But disaster struck again. 
Three weeks in, the programmer we had recruited also had to leave the team due to personal circumstances. We knew that only one programmer would not be enough to tackle this whole adventure, especially one week before the delivery date. Fortunately, during recruitment, if we couldn't partner up with two programmers, we knew that we could finish this project by using RenPy, a well known Visual Novel engine. And that's what we did. One week before the delivery date, we, the writing team, with the script almost finished, went on scripting duty and converted the whole script to the game you can play now.
It's also important to mention that, while NaNoRenO ended on April 1st, submissions were open until April 6th. This extra leeway ensured that we could insert the whole script into the game -- otherwise, the demo would conclude after leaving the tutorial room.

    3. Using placeholders to speed up development.

During development, many of the assets you can find in the game were not complete. We used placeholder assets - temporary assets which only intent is to test the game functionalities while the final ones are not finalized - while scripting Abyss. And while this might seem like a waste of time - why bother placing a fake character sprite on screen when the final size, color or position could be so drastically different? - we're confident that our decision was for the best.

When the final assets were completed, all we had to do was insert them in the game. This pretty much meant changing their filename, overwriting the placeholder ones, and run the game to observe if they were working or displaying properly. Many times they were not: animations using backgrounds need some fine tuning and characters sprites needed to be resized and cut. However, since the hard part was already done (coding the assets into the game, and assigning them transitions and/or animations), these quick fixes took between 30 seconds to 1 minute. Summarizing, in 30 minutes, we managed to have the game in a very acceptable state.
If we had waited for the final assets to be completed and only then implemented them, we would probably have been unable to deliver the demo as it is right now.

Another fact supporting this decision was that we did not use placeholder assets for music and SFXs. Implementing them so late in development was a pain in the ass as we had to comb through all the scripts, deciding the best place to insert them - and by then we had a very large script!

What went not so right!

    1. Scope creep

As we mentioned before, we had a backup plan to change to RenPy if something unfortunate were to happen during development with Unity. However, to say that this transition happened without losing something would not be true. In our original idea, the tutorial room would include two puzzles and two mini-games: one where players would play a game similar to "Rock, Paper, Scissors" against Andrea; and another where players would be challenged to traverse a maze from its starting point to the exit.

Unfortunately, only the two puzzles were implemented, and we had to sacrifice the other two mini-games in order to fully implement the script we had written.
Other systems we had to abandon include: interaction with background via point-and-click (a crucial component to the game), and the possibility of choosing the main character gender (and the consequences of doing so).

    2. Incorrect estimation of tasks.

Now that the jam is over, and based on the difficulties we faced, we conclude that we might have wrongly estimated the amount of work some coding tasks would demand from the programmers. Even if all those obstacles didn't show up, would we have been able to deliver a demo with the same systems and quality?
Based on the performance of the programmer who stuck with us through the whole ordeal, who implemented some systems in Unity (that unfortunately never saw the light of the day due to our transition to RenPy), we fear that it might have been impossible...

    3. Communication is key.

This is probably the most stressed sentence everywhere. And to think that when we started this project, we intended to punch it right in the face and never let it be a problem! We drafted several documents containing details about the locations players would visit, puzzles they would have to face, characters' backstory, and even the story script as we wrote it.
And while we're positive we might have avoided some pitfalls, we didn't avoid them all. One of the issues we've faced was portraying the feel of the game to the composer we partnered with. And while the main menu music track he composed is wonderful (you can listen to it, in-game), we feel that it was far from the feelings we're aiming for. Miscommunication I - 0 Abyss.
We also have to apologize to our Sound Designer, as often we were late on giving him proper feedback!

Conclusions

We feel confident to say that this jam was an amazing one and went by like a breeze, even including the not so positive points. It was our first time working in such a large project, for such a long period of time and with so many people (11 team members, including us). Furthermore, we produced something we're really proud of (you're getting tired of hearing us saying this, right?) and love.
We would like to continue developing this game, taking special attention to prioritize communication (although we have no idea how! XD) and adding an extra time buffer to coding tasks (that we know how to do!).

But we're also left with a somewhat big conundrum: do we go back and use Unity as our main engine, knowing that we would need to find someone to implement the system already existing and tested on RenPy in exchange for a bigger freedom in development, or do we stick with RenPy, allowing a large number of team members to work at the same time -- thus boosting productivity -- despite an apparent loss of freedom in the puzzles and mini-games we can craft?

Well, this last question will remain unanswered for now! It's time to rest from NaNoRenO and catch up with RL. And that's a challenge in itself!

Hope to see you again in these lands, Stranger!

-- Abyss Team