The Challenges of Designing a Multiplayer Metroidvania Roguelike

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, usually augmented with a persistent history showing past progress such as a high-scores chart. Sometimes this constraint is loosened by adding features which persist between deaths.
3. (Optional) Turn-based game play, 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 phenomenon 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 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 amount 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. Death of a single 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 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 which 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 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!