Orah Retrospective

Metroidvania Month 23 is the second game jam I've participated in, with the first being Ludum Dare. It has been an enjoyable experience and I'll definitely be considering participating again! For my own sake, I decided to write up a retrospective going over the initial goals I wanted to achieve with this project, as well as the overall design process and a "what went well/what went wrong" exercise. These are my own thoughts, so Seth may have differing opinions about how successful the jam was in general, or about specific topics!

Project Goals

Starting this project, I set out three goals, all of which I completed to some degree:

• Commit!
• Learn Godot
• Create an interesting prototype

Committing - I have many ideas and often have passing desire to work on side projects, but I've never been good at internal motivation. I'll often start something, work on it heavily for a week or two, and then drop it for good. Many times it's just because I had new ideas, or another hobby caught my eye. The jam gave me a hard deadline to focus on so I could keep scope constrained and have a known end point where I could return focus on other hobbies. This jam in particular was a great choice because it had plenty of time to make something cool while also maintaining a healthy balance between actual work, jam work, and rest. Most days I only spent an hour or two, and it was nice not feeling like I had to spend every waking moment focused on the jam. Having a partner also helped greatly by giving me the fear of disappointing a friend if I were to drop out. Between these two pressures, I set myself up for success and was able to stick to the jam and work on it nearly every day!

Learning Godot - I work in Unreal every day and while I generally like it more than other engines I've used, it is not great for 2D titles. I've never enjoyed Unity that much so giving Godot a chance was ideal. The jam gave an excuse to try something new technically, and the length of it meant I could spend the first week fumbling through basic knowledge about the engine. I also spent the week before the jam following tutorials, without that I would've been even slower at the start. But, now that the jam is complete, I feel like I know enough to hit the ground running on the next project I start in Godot. I'm by no means an expert, but I have enough familiarity with GDScript and the node structure to know what I want to focus on next time. I think a more accurate version of the goal would be "Become familiar with Godot to have a general impression of the engine so that I feel confident on embarking on larger projects in it." Phrased like that, I definitely have achieved what I wanted.

Create an interesting prototype - We wanted to make a game that would serve as a prototype to explore ideas. I did not set out to make the foundations of a game that I would continue working on with the goal of shipping. Instead, thinking of everything as throwaway code and design gave me the freedom to not worry about architecture or performance. I knew that once the jam ended, even if I carry ideas forward, it would be in a new codebase. That helped keep myself from spinning on small things aiming for perfection, and I was ok with letting go some bugs for the sake of making the game more complete overall. The scripts I wrote might be a mess and the game might not have menus or branding, but I was able to explore the core design ideas of the game to a point where I know what I would want to do for a version 2 of the game. I think the polarity swapping mechanic and bullet hell design is underexplored in platformers and even with our super simple bullet patterns we were limited to, I feel there is potential to explore this a lot more. In that sense, creating an 'interesting prototype' was a success in my book.

---

Design Process

There were three main phases of developing Orah from my perspective:

• Brainstorm
• Implement mechanics
• Design levels

I don't think Seth followed this as neatly, as he was focused on polish and code. This section only really applies to me, having started with code and switched almost exclusively to level design partway through the project.

Brainstorming - 

The first couple days, Seth and I voice called with a shared text document and just discussed and wrote down ideas. Before the jam we had a vague idea of wanting to make a pacifist metroidvania, so we focused on exclusively defensive mechanics. This immediately helped narrow down the potential featureset heavily and gave us a point to focus on. I think starting with this high level pillar worked quite well in inspiring more specific mechanics early on.

We also brainstormed themes and environments. We settled on sci-fi quickly as we both are much bigger sci-fi fans than anything else, but we went over several motivations for the character. The one we picked ended up not being conveyed in-game, even though it vaguely guided the overall world design and unlock progression. This was mainly due to art restraints. The bullet hell approach meant that enemies could create more complex interactions without needing to program AI or have animation, which led into us thinking of Ikaruga and Outland, both of which I am a fan of. The polarity swap is such a simple mechanic that can have incredible depth if mixed well with just one or two other mechanics.

Our lack of artist heavily influenced our brainstorming as well. Anything that would require complex animations were a no-go immediately, which is where the orb character came from. I can animate a ball rolling, but not a full humanoid set of motions. We could have spent the time to make or find a workable set of animations but ultimately that isn't what we wanted to focus on in the jam.

We had a fairly long list of potential mechanics, but it got narrowed down once we decided on polarity as a starting point. Because switching between them can already have a high mental load, we stuck with movement mechanics to compliment it. Dashing and the magnet grapple seemed like low-cost movement abilities that would lead to intuitive interactions with polarity. I think it ended up working pretty well ultimately.

Implementing Mechanics - 

All of the brainstorming happened in the first couple days, so we had a plan to work off of independently. We decided that I would write the player movement script while Seth would work on the world and enemies. It was slow-going for the first few days as we tried to figure out how to do things in Godot, but I had the basis of the player movement in within a couple days. I took a state machine approach to movement loosely inspired by Unreal's character movement. Knowing that we were making a metroidvania, I wanted to leave the majority of the jam to level design. I timeboxed settling on movement metrics and mechanics to a week, and by the middle of week 2 we had all of the pieces in place. The grapple is especially jank, but it was good enough to explore the idea. 

Once I started working on levels, I only touched code to fix bugs. I left the mechanics as they were from that point on, despite some frustrations and 'quick fixes' that I could've made. Resisting that temptation gave me more time to make levels and more confidence that levels wouldn't have to be later tweaked due to mechanics changing. At the end of development, Seth spent some time trying to fix bugs with the grapple and accidentally changed how it worked in the process, leading me to upload an unfinishable version of the game due to some grapple jumps being impossible. It was a reminder that trying to make last minute tweaks can be like playing with fire, and that every tweak means the whole game needs to be tested again!

Designing Levels - 

Note that I am not a level designer by trade, so a lot of this may be obvious to some. This was my first project in maybe 15 years where I did design work!

While Seth worked on enemy features and the technical side of how the world map worked, I spent a week creating throwaway test levels. With the turrets and Godot's tilemap, I would pick one feature and try to come up with a level that explored that one feature. The first was for jumping and dashing, which helped me understand the exact movement metrics we were working with. That point was the last time I tweaked variables that affected jump height and distance. I could have spent a bit more time tuning things as I'm not totally satisfied with how momentum feels moving around, but it's a game jam so I prioritized speed over perfection. Settling let me focus entirely on exploring level design ideas. 

I made a map based on grappling alone, seeing how it felt to do complex series of grapples, and how our specific implementation could lend itself to metroidvania-style implicit locks based on the grapple letting you squeeze through single tile gaps. I reused some of the motifs I came up with in this test map all over the final game. I also made a hallway with no platforming elements to explore combinations of bullet patterns and get an idea of what kinds of patterns were easy or difficult to pass. Once I felt like I had a good understanding of all the mechanics in isolation, I created two maps that focused on exploring the combinations of them. Grapple + dash, grapple + enemies, dash + enemies. These maps were not used in the final game, but I polished them to a representative quality that I would aim for with all levels going forward, but in difficulty and in visual design.

The next step was to create the overall world map. I used Miro to create a grid of standard sized rooms, and drew arrows between them. I started with 5x4 rooms that were each 60x32 tiles. I picked an arbitrary starting point and started placing the general locations of unlocks. I then created arrows between them to show which rooms were accessible. By picking some connections to be mechanic-gates, i started designing the overall progression of the game. Once unlock locations were decided on, I then filled each box with a general idea of what skills that room would challenge. Rooms could either be a single-mechanic introductory room, such as the first room the player sees turrets or the room just after unlocking grapple that shows the player a couple variations on how grapples will be presented later in the game. Later rooms usually were focused on a pair of mechanics, such as a room focused on the combination of grapple and dash. This gave me a conceptual starting point for every room I designed, and it was super helpful in preventing the blank page problem of not knowing where to start on any given room.

This approach also let me design the metroidvania-esque backtracking and mechanic foreshadowing. I made sure that going between unlocks always looped around previously explored places for at least one room, so that let the player see examples of grapples and the polarity system before getting the unlocks. The placement of these foreshadowing moments didn't change from the original design.

This whole map planning process only took a couple hours, and the only tweaks I made to it after that first session were because I needed to cut some rooms for time's sake. I originally planned for 22 rooms, and I think we ended up with about 16 standard room sizes in the end. There are fewer actual rooms because they could take up multiple standard sizes, such as the central column that extends from floors 1 through 4. Much like the game mechanics, locking this overall map design early gave me just enough of a framework to build out everything else quickly. I couldn't sit and tweak endlessly, I just had to roll with it and move on. I spent two weeks on level design at this point, which went up until the morning we submitted. 

---

What went well?

• Pace of development was not disruptive to life but we still accomplished what we set out to do
• Level design went pretty quick and I'm happy with where it ended up
• Me switching to focusing on design and relying on Seth to do everything else worked out well I think. My design focus gave good feedback on what kinds of tweaks I needed to enemies and movement, and Seth was able to quickly implement my requests. 
• I felt the difficulty scaling went pretty well. I developed levels in the order of game progression, so I think it was pretty easy to introduce harder jumps at times where it was appropriate. I don't think this approach would work for a larger scale game, but for our purposes, it was great. 
• By designing levels in the order of progression, I was able to very easily cut some levels as I started running out of time. There was no need to shuffle anything that was already made, so any restructuring that had to be done happened on the Miro board alone.
• Early decisions on design limitations helped keep scope manageable. Decided on pacifism as a pillar gave us a strong direction to move in and cut out a lot of potentially difficult mechanics right away, such as making a good feeling melee attack or anything. Having no death gave our game a bit more of a unique feel for the genre while also reducing the work we had to do. I wish we could've gotten one or two more of the mechanic ideas into the game, but I felt that we had a solid grasp of what was achievable early on and didn't push that too far.
• This jam didn't interrupt life, which was a big thing for me. I didn't want to burn out, and keeping stress low made the process more fun.

What went wrong?

• Being unfamiliar with Godot led to some poor technical choices and slowed down initial mechanic development
• A significant game-breaking bug was left in the game, and our attempts to fix it came too late. Seth did a great job mitigating it as much as he could, but I should have taken more care in the initial implementation to make the grapple more robust. Developing code quickly doesn't have to result in sloppy code, just simple!
• Polarity went in relatively late, and I didn't explore changing the unlock progression at all. Part of me wishes I would've taken the time to explore how unlocking the first polarity upgrade before dash would've played out.
• We had no optional upgrades as none of our mechanics lent themselves to incremental upgrades. Missing that optional incentive for more backtracking feels like a failing when making a capital-M Metroidvania.
• Deciding that we wouldn't have death or health led to some design challenges that I don't think we resolved. Particularly, being bounced around uncontrollably when failing a jump in the middle of a web of bullets does not feel great. This also put limitations on level design, where each jump needed a way to safely fall without losing too much progress or getting stuck. There are some levels where it feels too punishing to miss the last jump, and being stun locked by bullets can actually feel worse than dying and resetting at the start of the room at times. I did pretty well mitigating these problems in most levels, but they're still there and would require more iteration to fix.

Future work

• I really like the idea of a pacifist metroidvania. Its sort of the opposite approach that seems obvious, where genre innovation might often come from more complex combat mechanics. Instead we focused on the platforming aspect of the 'action-platformer' genre. On one hand it makes our game feel more akin to a precision platformer than castlevania, but that's not a bad thing in my mind!
• I want to explore the polarity mechanic in more contexts! there are a number of games that have put their spin on it, but I think there's a lot of untapped potential there.
• Specifically for this probject, my first goal would be to make turrets have a much more customizable bullet pattern designer. I'd like to be able to create curved paths, have one turret shoot both polarities in various patterns, and be able to more finely control timing. I think there's a lot of mileage we could get out of the game leaning into the bullet hell aspects more heavily. 
• After that, I would focus on adding one or two more upgrades, preferably one that could lend itself to optional upgrades. 
• I'd like to get new art assets and make the player's animations and VFX more juicy as well, but that would require finding an artist :)