Welcome to the fifteenth devlog!

Ever since I first had the idea for this project, I knew it was going to be a game for 1-4 players. I also knew that I wanted a dedicated solo mode, unlike some games that seem like they’ve tacked on a solo mode at the last second. (There’s also games made for one player, that tack on a 2-player mode at the last second, which is how you get the games where one player does all the cool stuff and another walks around as a glorified assistant.)

But that’s easier said than done.

How can I make a level that requires people to cooperate … but that’s also playable on your own? How can I make a level that is hard with only two players, but still hard with four players?

I’ve thought about this a lot the past few days, and here’s the options I came up with:

• Solo mode: create two characters, and allow the player to switch between them.
• Playercount-dependent levels: actually create a (slightly) different level for each player count.
  • For example: in level 1, you need at least two players to get a package to the “crate storage”. One to press the button, one to jump on the platform with the package. If I want this level to work in solo mode, I could change the level so that the button is in a different place and you can do everything yourself.
• Start big, slow down: create all levels to fit four players, and simply slow down deliveries (or even remove certain areas/zones) on lower player counts.
• Start small, ramp it up: the opposite of the previous one – create each level for one player, and just add an extra area/mechanic/zone for each extra player.
• The automata system: the “automata” system is becoming more and more mainstream in boardgames. Essentially, you replace a player with something that automatically does stuff.
  • For example: instead of the crane rotating at the press of a button, it rotates automatically. You can make the automatic system as intelligent as you want. Maybe you even give the player a computer-controlled sidekick that helps you with the level.

So, what did you decide?

This is a tough decision, it really is. Each option has advantages and disadvantages. So let’s take a step back.

Why do you want the game to be 1-4 players? In my experience, games in general, especially couch co-op games, are most fun with 3 or 4 players. With 2 players, it’s still fun, but it changes the dynamic a little: you’re closer together, so cooperating becomes easier, but it also becomes easier to just do your own thing during the level.

At the same time, many people will not have three friends just waiting around to play your game at any time. If the game also supports 1 and 2 players, it’s more likely to be considered and bought by someone, and also more likely that it actually gets played often.

And that’s of course what I want: a game that as many people as possible play and enjoy!

(Side note: I can also playtest and iterate the game more easily myself if I have a dedicated solo mode. Otherwise I’d have to wait until other people have the time/energy, or play two controllers simultaneously myself, if I want to test anything.)

Even Overcooked has a single player mode (where you switch between chefs).

The golden rule

What is the simplest way to do it? When in doubt, I always ask myself the question: what is the laziest way to achieve this? The options I think of will never actually be applied, but it always gives me ideas on how to keep the game simple and elegant. How to make sure that different player counts are something that inherently comes out of the core game design.

So, what is the laziest way to make all levels possible with 1-4 players? I think the answer is:

• Create each level for 4 players, remove stuff (if necessary) for 3 and 2 players.
• When playing solo, give the player 2 characters to control (and a button to switch between them), and just load the 2-player level.

I design the levels for 4 players, and simplify/remove systems on lower player counts. I expect this to mostly concern the placement of interactive elements, the distances that need to be traveled, the amount of steps in a certain process, etc.

Doing this means I just create the best level I can imagine, and then remove stuff on lower player counts. That is about the easiest and fastest way I can imagine.

For example: let’s say I have a level with four buttons in different locations. Only if all four buttons are activated simultaneously ( = all players stand on them at the same time), a certain bridge gets closed, which allows you to get to the other side. On lower player counts, I can just remove the extra buttons.

This creates consistency, both for the player and for the developer (which is me, by the way).

Arr, there be problems!

I have to admit something. The first version of this devlog was a 3-page article claiming the exact opposite of what I’ve outlined above. I explained why creating a solo mode where players switched between characters was a bad idea … and now I’m doing exactly that.

Why? What happened? Well, as I was outlining the first five levels of the game, I found lots of opportunities where I could use a “single player switch”, and only a few situations in which a solo player could do a level completely on his own.

No matter how I tried to change the levels, or how I tried to add/remove elements for the single player mode, it never quite worked.

So I did some research, and it turns out that most (board) game designers are facing similar problems, and the players actually want to have a solo mode where you switch between two players. I read many comments like “I hate it when games give a completely different ruleset for single player mode, or where it feels like the single player mode is just a watered-down version of the real game”

Now that I’ve decided to use the “switch between players” system in solo mode, designing the levels became much easier and I was able to use many more interesting mechanics.

I do still have my doubts, though. Here’s some of the remarks I wrote down about why I don’t like this approach:

• I need to reserve a button (on the controller) for the “switch”. A button which will have a different purpose (or no purpose) if you’re not playing solo mode, which creates inconsistency.
• For some in-game mechanics, this switch system does not even make sense. (Some things can’t be solved by switching between players, because those things need to be done simultaneously, not one at a time.)
• The game experience will be slightly different in solo mode. If you’ve played the first five levels solo, and then played the next level in 2-player mode, you’d probably be very confused and disoriented. You can’t switch! The button does something else now! How does this work? How do I solve puzzles now?
• I will need some extra “tutorial” to explain this switch mode. And if things get really bad, there might even be mechanics in the game that you only get to see in solo mode.

But, practice trumps theory, and in practice the switch works much better for my game and level design. So that’s the system I’ve implemented yesterday.

How to make the best of this decision

Of course, transforming this decision from lazy to elegant takes some extra work.

Skill-based: I want to make a good chunk of the game completely skill based. Cooperation is only like 30% of the recipe for success. The other 70% is simply: how fast can you think/move/act, how smart are your choices, timing your jumps correctly, placing stuff at the right locations at the right time, etc.

As I said before, the game is a mix between a platformer action game, and a cooperative puzzle.

By making the game more skill-based, solo mode still works well. The cooperation part might fall away, but there’s the skill-based part that keeps the challenge going.

Take this into account at the first stage of design: when designing a level, I should simply ask myself regularly: will this also work at player count X? If I do this, what must I change/take away to make it work for player count Y?

By asking the question regularly, the design automatically converges to a solution for all player counts.

Add some automata where it fits: the nice thing about computer games is that the computer already is an “automata”. It doesn’t take much extra work to convert a player driven mechanic into a computer driven mechanic.

For example, let’s say there’s a river on the map. During the level, players need to pass each other packages down the river. That’s player driven. But if you’re playing solo mode, it’s easy to switch this around: the computer simply already starts every package at the top of the river. You can keep the same level, even the same mechanic, but now it’s automated.

I don’t want to use this very often, as it feels more like a crutch than good level design. But it’s there when I need it, and it’s the best alternative out of everything I’ve considered.

Conclusion

Pfew, that was a difficult one. I couldn't even find any images to break up the text (and adding random images didn't help). I hope it wasn’t too hard to read, and that it was at least clear and interesting.

It’s really hard to decide these things and to make them work optimally. I’ll be designing the first five or so levels with this philosophy in mind. Then I will evaluate if it’s still the best way going forward.

After all that dry talk about level design, next devlog will be about the campaign and finalizing level 1!

(NOTE: Here’s an interesting link I found on solo modes and playing boardgames solo: https://www.boxofdelights.net/the-selfish-gamer)