Sponsored By
The Independent Games Festival (IGF) was established in 1998 to encourage innovation in game development and to recognize the best independent game developers. Read more about the 2024 finalists here.

RAM: Random Access Mayhem's body-swapping mechanic was born from playing roguelikes

The directors of RAM: Random Access Mayhem talk about how difficulties doing well while playing challenging roguelike games would spark a compelling idea for a roguelike of their own.

Joel Couture, Contributor

March 12, 2024

11 Min Read
Several robots in a shootout on a platform floating in water
Images via Xylem Studios

The IGF (Independent Games Festival) aims to encourage innovation in game development and to recognize independent game developers advancing the medium. Every year, Game Developer sits down with the finalists for the IGF ahead of GDC to explore the themes, design decisions, and tools behind each entry. Game Developer and GDC are sibling organizations under Informa Tech.

RAM: Random Access Mayhem is a roguelike action game with no specific playable character, instead having you hop into enemy bodies to keep the fight going.

Game Developer sat down with the game’s directors, Andrew Cunningham and Toby Murray, to talk about how a lack of skill at roguelikes would lead them to their own unique take on the genre, how swapping bodies with enemies necessitated more complex thinking when designing foes, and the design ideas that went into balancing a game where you take over enemy bodies when you die.

Who are you, and what was your role in developing RAM: Random Access Mayhem?

Andrew Cunningham: I’m Andrew Cunningham, the project’s co-director and creative lead. I’m in charge of designing and programming the game’s enemies and playable characters (which, in our case, are actually the exact same thing), as well as the story and writing, though not much of that is public at the moment.

Toby Murray: Hi! I’m Toby Murray, the other co-director and producer on the project. I’m a full-time 4th year software engineering student, so I balance my time between my classes and organizing our team's efforts, programming various mechanics, making menus, and generally tackling anything that needs to get done.

What's your background in making games?

Cunningham: I’ve been dabbling with gamedev off-and-on since I was pretty young—various stickman fighting games in MIT Scratch, the usual kind of thing—but I only got serious about it after spending some time in 2016 working with a team on an Undertale fan-game. I was honestly a pretty terrible programmer back then and the project never went anywhere, but the experience helped me internalize that gamedev was something I wanted to pursue above anything else. Since then, it’s just been hopping between solo projects and game jams while slowly working up the competence necessary to execute my own ideas. I’ve never had an industry job.

Murray: I originally started working in the film industry as a production assistant and then as a set electrician, and attended film school for directing and producing. Eventually I decided I wanted to get a full degree and enrolled in software engineering, where I met Andrew at the university GameDev club. I had never worked on a game before, but I found that many of my skills from the film industry were transferable. We worked on a variety of projects and game jams together, honing our skills. Through my university program I have worked co-op jobs at several software companies where I have learned how teams are structured and organized efficiently, which I have been able to apply in my gamedev efforts.

Several robots fighting on a gray catwalk

How did you come up with the concept for RAM: Random Access Mayhem?

Murray: RAM: Random Access Mayhem is born of a skill issue. I was really terrible at bullet hell games like Nuclear Throne and Enter the Gungeon and one day wondered to myself “What if I could swap to become the enemies so that I could avoid the bullets they were shooting at me?” I mentioned the idea to Andrew and we decided to use it as the foundation for our Ludum Dare game jam. The idea was well received and so we decided to continue with the project. This morphed into RAM: Random Access Mayhem.

What development tools were used to build your game?

RAM: Random Access Mayhem is built in Godot 4.0. We chose to use Godot because it is lightweight, easy to modify, and open source. The majority of our art assets are made in Aseprite.

RAM: Random Access Mayhem doesn't have a specific player character, per se, instead having players swap to an enemy unit upon death. What drew you to create this mechanic? What appealed to you about it?

Cunningham: We’re of the opinion that the most engaging roguelike experiences often come from risky play – Grazing past enemies to hit them with the Cube of Meat in The Binding of Isaac, stacking Shaped Glass in Risk of Rain 2 until both you and the enemies die in one hit, etcetera. It’s always fun to play on the edge of death, but it often doesn’t translate into a viable playstyle in typical roguelikes where death is so punishing.

Being unbound from a single player character in RAM: Random Access Mayhem means the game doesn’t end when you die. The lives of your host bodies are just another resource to conserve or expend, and this allows for much riskier play as a baseline—only demanding caution when fatal mistakes begin to pile up in quick succession. We want the player to be able to laugh when they get clobbered by an unnoticed enemy, then jump right back into the fray to take revenge. It allows for enemies to become tools, and for the player to almost map out each encounter as a puzzle of which sequence of enemies and swaps are optimal and/or stylish.

A robot shoots at a massive machine on a gray stone platform

How did this body-hopping mechanic affect the design of the various playable enemies? The design of their combat abilities and weaknesses?

Murray: Simply put, enemies in RAM: Random Access Mayhem are created from player characters, not the other way around. In very early iterations of the game this wasn’t so much the case. We’d come up with basic concepts for enemies then smash a player control scheme onto them and call it a day. This obviously didn’t create the best results. No one wants to control the Goombas in Mario because they’re designed to be limited, predictable, and easy to counter.

Our current approach is to design each enemy type to the standards of a playable class in any other roguelike. They all have their own intended playstyle, mechanical synergies, and advanced tech for players to master over time. Once a unit’s mechanics have been fleshed out to that extent, getting them to behave as enemies is mostly a task of whittling down their full moveset to a set of simpler behaviors that can be executed by their AI and that are fair for the player to contend with. Designing enemies to fill varied roles in combat is never something we’ve had to think too hard about; by the time they’re adapted from playable classes, their behaviors are unique by necessity.

Bosses bring unique swapping mechanics to each battle. Can you talk about the design of one of the boss battles you're proud of? How the swapping mechanic is used in some new, compelling way for that fight?

Cunningham: For most enemies in RAM: Random Access Mayhem, swapping into them essentially spells their defeat. They’re instantly neutralized as a threat and you’re free to control them indefinitely. Obviously, to have anything resembling a boss fight, you can’t translate this mechanic over one-to-one, so instead we’re approaching boss possession as a sort of elaborated stagger-and-riposte mechanic à la the posture system from Sekiro. In most games when you get to play as the boss, it's normally the case that they are severely underpowered. A bit like the “We have a boss at home” meme. But in RAM: Random Access Mayhem, you get to control the bosses at peak strength during their fight.

For example, we have a boss in development composed of several floating “heads” anchored to a base. Damaging the heads during specific moments of vulnerability will open them up to be possessed, after which you’ll be free to joyride around the arena and smash into hazards until the boss’s main body can chase you down and evict you.

What thoughts went into balancing out the body-swapping mechanic so that players couldn't endlessly find new bodies and avoid failure? How did you design the energy system that would keep the bullets flying and prevent players from abusing the mechanic?

Murray: Since swapping is a mechanic that lets the player directly undo death, it obviously needs to be limited somehow, but we didn’t want to just limit it with some resource that would be exactly analogous to a health bar. Swapping can be used offensively as much as defensively, so it wouldn’t make sense to “take damage” every time you did it.

The solution we arrived at is a hybrid of regenerating and non-regenerating resource pools that are expended by swapping. We just call the resource “swap juice”. The regenerating pool is consumed first and quickly refills as the player kills enemies, so the player can swap up to twice in a row and still have the opportunity to recoup 100% of the lost juice by standing their ground in one body for a while afterward. Swapping more than that—which you’re often forced to do when your hosts die— requires eating into the larger non-regenerating pool, and is more analogous to “taking damage” in a traditional sense. Once the non-regenerating pool runs out, it’s possible to permanently die.

A final nuance is that, even though swapping can cheat death, the game discriminates between pro-active and re-active cheating. Swapping out of a host that died under your control costs 50% more juice than swapping out while it’s still alive, even if the duration of its lifespan after you leave is a single frame. This makes reflexively hitting the “swap” button in the same way a fighting game player might reflexively hit the “block” button part of the game’s learning curve.

A robot wandering through a red environment

What challenges did you face in designing upgrade systems for all of the playable robots? What challenges came from designing upgrades around disposable host robots?

Cunningham: Roguelikes typically handle powerups in one of two ways. There’s the “Isaac” approach of having a base moveset shared across most playable characters and extremely varied powerups that paint over the blank canvas, or the “Risk of Rain” approach of having characters with diverse abilities in conjunction with generic powerups whose effects can be applied regardless of the underlying moveset.

In RAM: Random Access Mayhem, we use neither approach, and instead curate a separate pool of upgrades for each playable enemy type. This gives the best of both worlds—unique character movesets and zany upgrade effects – at the cost of a smaller set of upgrades available to each enemy. Ideally, we want players to cultivate builds for each type of enemy in parallel as a run progresses, and so disincentivizing players from dumping every possible upgrade into the same enemy type and using them exclusively has been an ongoing design challenge.

Players can afford those upgrades by playing stylishly. How did you design the point system around rewarding players who fight in impressive ways?

Cunningham: It’s no secret that a lot of RAM: Random Access Mayhem’s mechanics take inspiration from games Toby and I like, so the style system might be a bit of an outlier in how little inspiration it takes from other style-centric games. Neither of us are big DMC or Bayonetta fans, and even though RAM: Random Access Mayhem is riddled with Ultrakill DNA, I’ve never been good enough at that game to pay much attention to its style meter.

The goal of RAM: Random Access Mayhem’s style system, or “Fitness” system as it’s called in-universe, is to minimize the distinction between playing “impressively” and “efficiently”. In an ideal RAM: Random Access Mayhem, those words mean the same thing. Being able to swap at a moment’s notice between enemies that each have completely distinct movesets creates endless potential for elaborate trick-shots, but these are usually impractical for clearing encounters compared to standing in place and repeatedly firing a gun. To ensure these fun-but-impractical techniques see the light of day, the Fitness system recognizes when the player does something cool and rewards them with Fitness score that’s needed to purchase upgrades. The goal is to create a balance where boring play is effective in the short-term, but results in a drought of upgrades that makes survival progressively harder as the run continues.

What thoughts went into the visual design of the world and the playable characters? How did you design the visuals so that the characters would stand out immediately as players planned body swaps? So that players could easily navigate the various shots and dangers in the world?

Murray: Neither of us are artists, so when we decided to take the project more seriously we knew we would need to look for talented people to help realize the vision of the game. We were lucky to find our concept artist Gecko and our sprite artist Penusbmic (of Dome Keeper fame). They have done amazing work to make each enemy look and feel unique so you know your options at a glance.

To make sure the player never loses their host we use a few methods to keep things legible, like the camera always centering on the currently-controlled host and adding particle effects around them.

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like