Tuesday, June 27, 2006

Multiplayer vs Single Player

So, I've made some prototypes, but they sucked. I started asking myself, "what's up with this? Have I lost my touch? Can I only make good designs in the winter? Are my expectations simply too high and others would find these fun?"

Well, I think I figured out the answer.

You see, the vast majority of my game designs are multiplayer, but one I go to build a prototype, I've been building them as single player. This difference is enough to make the prototypes worthless, because the two styles of gameplay are so fundamentally different.

So I looked into it. What's the difference in multiplayer games vs single player games?

The answer is extremely clear to me: complexity.

A single player game has very high complexity, while a multiplayer game uses much lower complexity but with intelligently adapting play (IE, the other players).

Examples: Halo has the more or less the same basic equipment whether in single or multiplayer. But in single player, you play on a huge map with complex combats and carefully designed (or misdesigned, whatever) pacing. In multiplayer, you play on smaller, simpler maps which shape the experience but do not directly guide it.

In a game like Starcraft, you have a fairly simple set of units and capabilities, and it's all in adapting to what the other player might be doing.

"Fairly simple? Are you mad? There's, like, a zillion different units and upgrade paths in recent RTS games!"

Ah, but the content/game complexity of even the most recent, complex RTS games pales in comparison to the content/game complexity of the original Final Fantasy.

Why? Because RTS games are intended for multiplayer, so the game is designed to let the players interact in complex, conscious ways. The RPG is designed for just the opposite: as a solo game, you have only the game to interact with, so the game has to shoulder the burden of that complexity. It has to provide as much complex entertainment as at least one other player would.

MMORPGs are actually one-player games at heart, for a number of reasons. I think that's a mistake, but I've never built one, so I couldn't say for sure.

Annnnyhow.

In my efforts to design ever-simpler-to-implement games, I quickly found myself making multiplayer games, shifting the burden of complex content onto "the other player". Which is fine, if you have another player. But I don't. So the emergent complexity of these designs rarely worked in my favor, because the computer AI I design is simply too stupid.

(I'm not embarrassed by that at all, actually. You try building an AI for a game you've never seen played.)

This approach is untenable. I do not have multiple players for my computer games, and I cannot simulate them.

So, I need to rethink my approach and come up with a design that's intentionally single player without requiring scads of content creation.

Make sense?

3 comments:

Yehuda said...

Makes sense. Good thoughts.

Yehuda

Jason O said...

Unfortunately I think the trend for making what looked like very promising games into multi-player only was done because they were easy to program. No AI to worry about. Sadly, I think many of the games that were early on this trend, back before broadband, didn't think much about net optimization, though that is another topic.

I think multi-player design as a lazy design pattern lead to search a deluge of mediocre games, and worse you saw game development hamstrung in many cases by the need to tack-on multi-player on games where it didn't make sense.

Oddly enough, the best compromise I ever saw was Unreal Tournament that didn't have a strong narrative and allowed you to play against bots which did a reasonable facsimile of human players. However, this also added to the developer's burdens so it ignored the "easy" path but also created a game that was enjoyable to a wide audience.

Though there might have been some trade-off there since they didn't have to mess with scripted events or cutscenes.

Craig Perko said...

Yes, but I'm not just talking scripted events and cut scenes: I'm talking level design, rule complexity, and breadth of content.