Being on the lead design of Death Petal meant I was working with all of the departments of our team. I was there since the ideation, where I came up with the idea of a "shoot everything" game heavily inspired by Killer7, after working with the team and the designers we ended up shaping this project into what I believe is truly special.
Here I would like to talk more so about the specifics of the level design and some major pitfalls I have learned from in this project.
Creating an engaging level for Death Petal, I took a lot of inspiration from other games, notably Portal and Half-life 2. The main portion of the level was designed with the concept of loops in mind. This meant levels had a flow to them where no matter what way the player decided to choose, they would always be, or at least tangentially, close to what is considered the main path. The loops were implemented in such a way that the player never truly had to backtrack (with one exception). The level was split into small parts which were considered Puzzles with the bridges between these rooms was later figured out in engine.
To quickly mock up the visuals beyond scribbles on notepads I ended up repurposing the open-source software Tiled (a tile map editor) to create these level view diagrams. Tiled ended up working quite well for mocking up 3d spaces on diagrams as it's isometric feature allowed for showing height of the spaces. I ended up creating simple tiles that represented the individual game elements and allowed us to show the available game space.
These initial rooms were made to simply introduce the weight system. With destructible crates placed right along the weights as to show the player these objects, while they do not have a visible WP, they are still destructible, and as the weight requires multiple shots to move, the player is very likely to shoot. This whole sequence is set up in a way that teaches the player the purpose of the weights as a puzzle element and show the player optional pickups. By framing the crates as an accident, the player gets to learn something new without the need of a tutorial pop-up and makes it feel like a discovery. These crates were added much later in game, as we found during play testing that player's really struggled with health management, which was much different from when I would play though the game, where I would almost constantly be at maximum health.
The original fix was to add more health to the player as the quickest and obvious solution, or otherwise made the combat encounters more forgiving. However when observing player's actual behavior I noticed players' managed to get through combat on a similar level as me however they would never end up getting healed by the environmental crates. This showed that the while we had the correct issue, we were asking the wrong question. It was this observation and re-framing of the scene that I saw that adding a clearer tutorial for the players to gain health was required instead of other tweaks.
First target puzzle with and without healing crate
Here you can see how the tile-map's looked when utilizing longer and more vertical levels. Notably the level on the left was dubbed the prelude which functioned as a seamless tutorial of our game. Inspired by the tutorial of Portal, here the player is locked out of interacting with the reload system here, so the only mechanic the player must worry about is shooting. Here is introduced the temporary helper mechanic of Reload Circles which automatically load the player’s chamber with the correct bullets for the current scene. The length of the chamber gives the player a long enough time to get to grips with the unconventional movement mechanics and camera systems. In this section the dialogue interactions are mandatory as they teach the player the baseline rules of the world and sets up the story.
Originally the prelude was missing from the game, but during playtesting, players kept complaining about the camera angles and the over-all fixed camera approach of the game. As a team we debated for a long time about pivoting and removing this feature, however we would consistently get feedback that these camera's game the game a very strong aesthetic which worked as the hook for this game. I noticed that the team at large and my self no longer had the issues that we kept stumbling across in playtesting. I decided to try simply expanding the playtest time by padding it out with some empty corridors the player had to walk through as these play tests were too short for a player to get acclimated to the controls. My hypothesis proved immediately true as player's feedback about the difficulty and frustration with the controls quickly dampened.
Biggest lesson that came from this entire project was how outdated our approach to Game Design Documents was. We created a system of utilizing a wiki-style format using Google Docs to write an extensive and deeply in depth wiki of all the mechanics of our game (as can be seen here) While this approach worked perfectly for any smaller scoped games as there simply was not as much pure data that needed to be handled and updated.
At the pre-production stage this document became pivotal in creating the direction and keeping the whole team updated on the current stage of the design. Once we entered proper production, I ended up becoming burdened with a lot of other tasks meaning I feel behind on keeping the document fully up to date. This meant a lot of work was lost as team members would work based off information that I had already changed in a meeting or after playtesting.
To reprimand this I moved a lot if not all of the design documentation to our Jira production, keeping all relevant design decisions inside of individual tasks. This meant that all of the design was quick to reference at a glance as the language changed to bullet points, and most importantly you could see how all elements interacted with each-other as all of the tasks were positions next to each-other.