The Challenges of Designing a Multiplayer Metroidvania Roguelike

Since the days of Donkey Kong and Jumpman (Mario) in the original arcade game Donkey Kong, there have been platform jumping games (platformers). Platformers have generally always been innovated in ways that haven’t heavily impacted the overall challenge they present to avoid obstacles while reaching the goal at the end of some intricately designed level. The innovations with each generation instead present new difficulties and game design complexities often taken from other genres and themes. This is a trend I’ve always been a huge fan of and with each new generation of console, I tend to gravitate first toward the selection of adventure platformers, particularly Metroidvania games and most of all the trendy yet controversial roguelikes. The reasons roguelikes are controversial isn’t the primary topic but for the sake of explanation several of the design decisions that make something a roguelike, their core mechanics, are the very things that make them inaccessible and unapproachable to so many other people.

What is a Metroidvania?

Metroidvania is a subgenre of platform jumping games where the emphasis is on the exploration of the physical world. Metroidvania is a portmanteau, named for the games Metroid and Castlevania which are two early games featuring the same kind of mechanics mirrored in games of this genre today. They usually feature a kind of character growth where players collect permanent items allowing them to traverse areas of the world that were previously inaccessible, but alternatively, there are puzzles or world objects the player must activate to enable access to those areas. The key design tendency within Metroidvania games is to place entrances to later regions within easily reachable sections of earlier levels. When the player attempts to proceed in the wrong direction, they’re blocked by an obvious sign that they need to come back after doing or acquiring something that will remove the obstacle preventing progress. This is a design technique that has spread beyond this classic genre but is still strongly present within the genre today, and from the player’s perspective it’s commonly referred to as “backtracking.”

I won’t go into any further depth in this article about design within the Metroidvania genre, but there are a few things that are important to emphasize for the sake of the article. Metroidvania games are classically single-player due to most major progress being permanent and the emphasis on exploration. There is a wide availability of multiplayer Metroidvania games now, but a lot of them remove things like backtracking and put a lot less emphasis on exploration and completing puzzles, making the subgenre ascribed to them arguably a weak categorization.

What is a Roguelike?

I see roguelikes as both a genre and separately a subgenre whose mechanical constraints can be applied to a game in almost any genre. A game only has to be so much like the 1980’s game Rogue for us to call it a roguelike. There are advocates for calling real-time games that otherwise follow the roguelike tenants “roguelite” or “roguelike-like” instead. My personal preference is to use phrases like “turn-based roguelike” versus “real-time roguelike,” because I think it’s more about the essence of the challenge and mechanics than it is about constraining the way the game is played.

The core mechanics of roguelike games are the following four constraints, where sometimes the third is loosened or neglected completely. Infrequently though classically the fourth constraint is followed, which I’ll mention here:

1. Procedurally generated (randomized) content such as item and creature stats, most prominently the levels and overall world design.
2. Permanent death resulting in a complete loss of progress is usually augmented with a persistent history showing past progress such as a high-scores chart. Sometimes this constraint is loosened by adding features that persist between deaths.
3. (Optional) Turn-based gameplay, where moves or actions the player takes are either one-for-one with enemies all moving simultaneously, or players and enemies have some sort of stamina or action points allowing multiple moves per turn.
4. (Infrequently used today, but present in most classic roguelikes.) Players and enemies are equivalent, or have the same abilities and stats, leaving items and upgrades as the only way to get a leg-up on your opponents outside of the element of surprise.

This implies several things as a baseline. Strategy and a good understanding of game mechanics aren’t always enough to win, particularly due to the randomized nature of stats for items and creatures. Memorization isn’t the solution to unexpected phenomena such as getting cornered and learning to avoid it on your next play-through. Equipment gained is just as easily lost, and gaining equipment is rarely enough to make meaningful progress. To put it simply, the odds are stacked against you.

Roguelike Design Challenges

The common challenges designers face when creating a roguelike go hand in hand with the type of mechanics the genre entails. Some designers avoid taking control over how the player experiences challenges, relying too much on the random number generator (RNG). When a designer relies on the RNG to provide good results they’re relying on those who enjoy playing games even when they’re losing an unfair fight to be the audience for their game. This puts a strain on achieving a sizeable audience and reduces gameplay accessibility, limiting the number of people who might otherwise enjoy the game.

Not making it obvious which parts of your game are random or hand-crafted, results in an unclear representation of the game when it’s described by people who have played it. Put simply it’s bad game design and bad for advertising if people aren’t sure when it’s their fault that they’re losing.

Designing a Multiplayer Metroidvania Roguelike

I’m in the process of designing a multiplayer, Metroidvania, roguelike game. I’ve never heard of a game like it before. My search results are either single-player Metroidvania roguelikes or multiplayer roguelikes. I’ll explain my design now and explore some of the design challenges that I’ve run into in the process. Later I’ll write articles about a few problems in a little more depth than I will here, particularly since I think their complexity is likely the reason no game like this has surfaced yet.

The game is a 2D, 1–4 player, platforming adventure game where each level is a procedurally generated Metroidvania world. The enemies and puzzles within each level adapt to the number of players who entered. Artifacts are items used to enhance player movement and abilities and are shared by all players, they persist beyond death. There are hundreds of creatures ranging from small (player size), medium, and large, each with unique behavior sets and animations. Some of my friends are remote, and I want to be able to play this game with them, so it will allow both local and remote play with remote screen-splitting or sharing as an option.

I’ll list a few of the obvious design problems I’ve faced so far and briefly explain how I’ve chosen to address them:

• Player death breaks either the roguelike or the Metroidvania experience. To address the issue of the death of players directly would remove too much about what makes these genres so great. By giving the choice back to the players, they get to decide which experience is more important to them. Depending on the settings the host-player created the world with, players will still have all artifacts and levels will still be the same as when they were first generated. The death of just one player results in a loss of their items and they can no longer help solve the level.
• A player dies and it breaks a puzzle requiring multiple players. When a player dies they lose all of their items and can no longer help solve the level. Sometimes this might leave the level in a broken state supposing a puzzle in the level required that player to help solve it. If a living player exits the level to the surface of the world, all dead players will respawn.
• Permanent death ruins the Metroidvania experience. The solution to puzzles being broken by player death is already explained in the above bullet points, but it also damages the Metroidvania experience if it’s difficult to determine whether that player’s death has broken the level. Backtracking will always be possible, and indications of what is required for puzzle solutions will be present where necessary. I.e. buttons might have wires connected to the door they activate, where multiple wires connected to the door would mean multiple actions must be taken.
• Puzzles that open new areas of a map are difficult to generate. Backtracking and procedural generation together present a unique design challenge, particularly because the game won’t use any pre-built room pieces, and I want it to feel like a unique experience for many playthroughs. This means that every level despite feeling non-linear must have at least one linear solution. Every level is predetermined to be solvable at generation time.

Many of the design problems I’ve decided to solve by supplying world settings and giving the power of choice to the players instead. I’ll put default settings into the game as the vision unfolds, but I want players to choose the experience they want. I haven’t gone into some of the more complicated technical problems. In later articles, I’ll describe in detail how I’ve used graph theory and game theory to solve some of them.

If you’d like to follow the development of the game, subscribe via RSS or bookmark the site to check back for updates and technical articles on design challenges as they come up!

Originally published at https://fullylucid.com on April 29, 2020.