Not Quite Immortal

The original concept I brought to the team included ideas about narrative context and some major game mechanics like possession, but the gameplay experience as the whole was an open question. For the first few weeks of development, the team put together three prototypes, each exploring one potential primary aspect of gameplay. Based on the success of those prototypes, we reached the decision to focus on narrative, immersion, exploration, and strategy as design pillars. The combat mechanics we had at the time became secondary, and were later scrapped completely in favor of a stealth-based approach to dealing with enemies.

After Not Quite Immortal cleared the greenlight process, it was time to leave behind the demo levels from our vertical slice prototype and design a full-sized game world. I opted to use a metroidvania-style world layout for a couple reasons– it lends itself well to emphasizing exploration as a key part of the player experience, and the nature of the story required the player to return to the hub town a few times, necessitating some degree of nonlinearity. (This decision also inspired us to adopt other features from the metroidvania genre, most notably the wisp items which grant the player access to new possessions over time.)  The size of the world shifted a lot early on, as the amount of work the team could practically finish came into focus, but in the end we settled on the scope pictured here, a total of 31 rooms across 4 visually distinct zones.

The game’s signature mechanic, the possession ability, allows players to control wild monsters, using their abilities to traverse obstacles and solve puzzles. This created an unusual situation where enemies acted as hazards to be approached with caution, but also as tools necessary to get around the world, and the level design needed to accommodate both. I made sure to give the player space to avoid and sneak around enemies, and occasionally found it necessary to tweak platform layouts when the enemy AI had trouble navigating the level.

As for puzzles, since the team clearly wouldn’t have time to make too many unique objects for the player to interact with, I pushed to prioritize versatility. During the process of conceptualizing the possessable monsters and their abilities, I tried to ensure that all of them would have a couple unique traits to offer to the player, so that they would be useful in a variety of situations. For interactable objects, I relied a lot on things like switches, pressure plates, and moving doors, which could be easily scripted to behave a bit differently every time. Both of these factors ensured that, even with only five possessables and a handful of interactable objects, the puzzle design would not become repetitive too quickly.