|A new star map we're investigating using.|
A good friend of mine (and then roommate), Michael Schwern, convinced me to try a PVP (player versus player) server instead of a PVE (player versus environment) server. The primary difference is that in PVP, enemy players can kill you. In PVE, they can't touch you and you just play against the game (yes, I'm oversimplifying). This was a huge eye opener for me because I thought I would prefer exploring the game rather than fighting other people. I was dead wrong. When you're trying to finish a particular quest and there are human bad guys all over the place, it makes the game much more challenging and that really pays off.
Over time, I had played enough games, both single player and multi-player that when I decided to create Veure I was pretty sure that I knew what I was doing. Once again, I was dead wrong.
First off, if you want to design an MMORPG and you have no experience in the field, buy Designing Virtual Worlds by Richard Bartle. Though it's a bit dated, Bartle has such a deep, extensive history in designing games like this that even when you don't agree with him, he will always have thoughtful things to say about any particular bit of game play you're interested in. That being said, don't pick and choose what to read in the book; read it all and take notes — your game will be better for it.
But let's put this aside for a bit while I discuss two rather interesting discoveries I made while creating Veure, both of which lead to the same wonderful result.
The first idea is that of randomness. Because I'm trying to single-handedly create an MMORPG (though my company has recently hired a talented developer to help) I've written a lot of code to auto-generate features in the game. For example, while there are 117 stars in a 40 light-year sphere around the Earth, thus creating constraints in the game design, I auto-generated the space stations and wormhole routes between the stars. That seemed to work fine, but when I finally wrote software to create a 3-D map of the star systems, I discovered that several wormhole routes couldn't be reached. Is that a bug? Well, I started thinking about it and now it's a feature, though for gameplay reasons, I can't discuss why.
Having a certain amount of randomness can lead to unexpected outcomes and rather than redoing things to avoid those outcomes, ask yourself "can these unexpected outcomes stem from logical consequences?" If the answer is "yes", you may have created some surprising gameplay that your players may enjoy.
Of course, sometimes randomness doesn't work. I auto-generated station names and while I'm not totally thrilled with the results, I discovered that the starting station for everyone had been randomly named "The Death of Baghdad." Oops. I'm not trying to make a political statement, so that quickly got changed.
The other, related idea, is challenging assumptions. For example, in database design we have something called a "one-to-many relationship." This is where a thing can have a collection of other things, but those other things only have one of the original thing the relate to. For example, a star can have many space stations, but each space station is in one and only one star system. This is logical and ordinarily I wouldn't have questioned it, but I started wondering what it would mean if somehow a non-moving space station could be related to more than one star system. Could we have an entire space station in a quantum superposition? This could dramatically change the nature of game play! I eventually decided that it wouldn't work, but it did lead me down some other paths that could.
Or for another example, I recently wrote out a quick prototype of a procedural quest generator. I wanted to have it for inspiration in creating missions and it creates quests like this (some are much, much more complicated):
Generating a quest for knowledge: SpyThat can translate to "you need to go somewhere, find an NPC, spy on them, return to the NPC who gave you the quest and report."
[Go someplace, spy on somebody, return and report] ['goto','>spy','goto','>report']
[Just wander around and look] ['>explore']
[Just wander around and look] ['>explore']
Do you see any interesting assumption there? Why is it only NPCs who can give quests? And why would I only be spying on another NPC? What would it mean in a game if a player could give quests? Or I could be given a quest to actively spy on, steal from, or kill another player? That tremendously opens up game play in interesting directions. This won't be in the ALPHA release and may not make it into the BETA (there are lots of dangers here), but this is a fascinating idea that I want to mull over.
Getting back to Bartle, one of the MMORPG problems he talks about is story. Many game designers want to tell a story and many do. There is, however, a fatal flaw in this approach: stories have a beginning, a middle, and an end. Once the story ends, what's the incentive for a player to continue? Unless the game periodically resets (common for strategy games, but a disaster for for RPGs), that's it. Game over. Revenue over. Oops.
As a result, many games employ backstories. I've already developed the backstory for Veure, but there's a lot of fleshed out backstory that's not public for reasons of game play. Recently, my wife (and president of our company), was pushing me to flesh out the backstory more with an idea for developing story. We argued about the relative merits of story and while she reluctantly agreed that an overall story arc is problematic, she was still pretty insistent that there was an important idea here that shouldn't be ignored since so many players ask for this.
So why is story problematic? According to Bartle, there are several reasons, some of which are:
- Either the player is impotent, or they can derail the story arc.
- You can follow the story without playing.
- People don't like coming in on a narrative after it's started.
- Players like to create stuff on their own rather than see what others have created.
- Explorers (one of the main player types Bartle identifies) like to discover new content, but don't want to go back to see what old content has been changed.
- Players are limited by future storyline actions (you can't kill X because she's crucial to the next act).
In thinking about this, I realized that part of the issue is that the story ends. Also, point one above, that characters can't derail the arc, seems like an issue. That's when I realized what I was looking for. I don't want a story, I want a history. In particular, I want what is known as a future history, a technique used by some science fiction authors to build a "metastory" encompassing multiple stories.
Further, after looking at what I've done, I've realized I can do this. There is nothing in my current work which precludes this, but there is a lot which already implies this. Asheron's Call tried a similar idea, but structured differently. They had monthly updates and each story arc lasted a year. That's not what I'm looking for. I already have several planned elements that can't happen until players undertake certain actions, but those could be major changes. New areas will open up and potentially the game itself could change.
Think about history for a bit. What if Columbus never undertook his voyage? What if the "New World" wasn't discovered for another couple centuries? During the intervening years, there would have been no rush to the Americas, the Dutch wouldn't have founded New York (then, New Netherland), New France wouldn't have been created, the Native Americans would have been left in peace for a while and European history would have changed greatly.
Similarly in Veure, perhaps there are paths to opening up new vistas to the game which players may never think about, but some player (or players) will go down in the history of Veure as discovering things which, truth be told, were already there. Or what would happen if Eiríkur Sigurðsson, a freebooter, decides to launch an attack on the Consortium and take over their stations? More importantly, what if Eiríkur, a major NPC, could be permanently killed? What would that change to spawning mechanics and quests if we could permanently kill characters?
Currently, due to how Sick Bays an Cloning Vats work, you generally can't permanently kill someone, but the rationales are all there in the game if you wanted to.
It works like this. If I kill you on a station with a sick bay, whatever remains of your corpse is enough to be resurrected in the sick bay. If the station doesn't have a sick bay, your clone is revived in the last station you gestated a new clone. So what happens if someone from the Consortium attacks and takes control over the a station containing Eiríkur's last clone? They could potentially deactivate this clone, effectively killing him. So you can't just kill him; someone also needs to take out the cloning vat, but ordinarily that's not possible without government intervention, so maybe you first need to petition to Consortium to be allowed to do the unthinkable, disable a clone.
Killing Eiríkur could be the in-game equivalent of taking out Osama bin Laden: a major, permanent, event, but one which nonetheless doesn't stop the world from going on, or new bad guys from arising.
Or maybe your character could capture Eiríkur Sigurðsson and he could be permanently incarcerated? He's a dangerous fellow, so it wouldn't be easy, but these are ideas to have on the back burner, slowly stewing while I finish cooking the rest of this meal. Obviously, this idea doesn't deal with the problem of being able to follow the game without playing, or perhaps being frustrated that areas you already explored are now different, but is that any different from real life?
So if you're going to create a new MMORPG, the first thing you should do is learn why the current ones are created the way that they are. Then, and only then, can you understand the rules you're breaking and why you're breaking them. And while you're at it, challenge every assumption you've ever made about how things are supposed to work.