On gameplay and the possibilities of the post WOW MMO

Earlier today on Tobolds Blog, Tobold continued his series 'Why do we play?' series by talking about Gameplay. He defines gameplay as the repeating elements of the game. Examples would be combat, or crafting. I find this to be a very elegantly definition for what gameplay is and it gives some focus to how one should go about designing gameplay.

First, gameplay needs to be repeatable. No matter how much fun something may be, if a player can only do it once, then there is not much point to including it within an MMO.

Second, it needs to be fun. You would think that this should go without saying, but it needs to be said for one specific reason... not everyone defines 'Fun' in the same way. Some people are enthralled with competition against other live individuals, and no matter how good your AI is they will never have fun because there is no real person on the other end for them to best. Other people find collecting fun, it could be experience, gold, virtual window treatments, etc... but they desire an ever increasing pile of 'something' in order to have fun. still others might be a variation on the collector who only derives fun from completing collections, and thus will be frustrated if there is no end to the possible virtual window treatments.

Third, and this is personal qualification because I am a lone developer with limited time and resources, gameplay, in whatever form it takes, should be generated and not authored. to put it simply, I am but one man, and I cannot custom craft each and every experience that each and every player might want to experience. This, as a rule, is the same for every game developer, because no matter how big your team and how deep your budget, there is no way you can produce content faster than the playerbase can consume it. You can't ever come close. I my case this true-ism is just greatly magnified.

I therefore set down the requirement that any gameplay designed for Skies of Psyberia be generated either algorithmically, or by the actions of the amalgamated playerbase. Here are some examples that I have off the top of my head:

Delivery quests: These are not scripted, one use quests that we normally experience in today's games, but quests generated out of need. I plan on going with a pseudo-closed economy, in that if a Shop in the city of Cog sells swords... the need to come from somewhere. If a store's inventory is finite then the price of the items should naturally be tied to supply and demand. If you live on a floating island, and a war is starting, weapons will be a hot item, as the stock of weapons in stores dwindles, the price goes up. At the same time merchants will need to restock, so local weaponsmiths will be swamped with production re'Quests' (see how I worked that in there), and suddenly there is a need to move objects from one place to another... thus delivery quests are born. There are all kinds of variations that can be put on a system such as this, because it is a system rather than a hand written quest. Let us say that the player is carrying a crate of daggers from the smith to the market stall and is set upon by a few opportunist rogues (either generated AI or real players, doesn't really matter, the players could even be following a generated quest that popped into the system when the crate was picked up at the smiths). If the player evades or bests the rogues and makes it to the delivery, then all is well and the player is rewarded with both money and the trust of the merchant. Possibly even a discount. If the crate never makes it to the destination, then the quest has failed, and the player is no only out whatever potential rewards would have come from the delivery, but might find it harder to be trusted with such valuable cargo in the future. This can be scaled up and down to be a simple note passed between lovers, to an entire ships hold full of cargo, but the idea is the same. Build a 'system' that 'generates' a quest rather than authoring the quest directly.

Kill X foozles: Kill quests are a core of MMORPGs and they probably always will be, but rather than author them, generate them. Want a 'Kill 10 Rats' quest, ok, design a spawn system that creates rats at a reasonable exponential rate, the more rats there are, the the faster they multiply, we will cheat the system by making them spawn at a minimum rate even if there are none left (you never can find them all you see, tip of the iceberg and all that). Now, and here is the twist, give the rats a way to affect one or more other systems... say they can steal grain from the mill, or they can ruin crops growing in the field, or they can cause disease by proximity, etc... There are plenty of reasonable bad effects that rats can cause. Now the systems react. The mill owner, detects stores dropping without sales... basic inventory management. It also detects rats, basic perception. One table look-up later and the mill owner is running down the street to the Job posting board with a reward poster for each batch of 10 dead rats... or at least their tails. This quest will be available to anyone that sees it until such a time as the miller no longer feels threatened by the rat population. At the same time, a local farmer is having trouble with his cabbages... you get the idea. When merchants and inventory are not magically stocked, but are the just a part of a system, then it becomes logical to interconnect systems that are normally independent silos in current games. This also means that players can really effect the world... visibly. If nobody takes the rat killing quests because that is beneath them, then things happen, big things... The cabbage crop is lost, the mill goes out of business, the baker either imports flour and raises prices to cover the deliver quest cost, or goes out of business. An ir/responsible playerbase can cause an entire ecosystem to fall apart, or cause it to flourish... A developer can cause a stable system to start moving again by introducing plot... such as a war between NPC factions, and thus generate tons of quests and 'gameplay' with just a few paragraphs of text and some database tweaks.

There are some limits that would have to be put in place. Players by their nature are not invested into the survival of the world... If a core pivotal city in the game world crashes down around them and everyone else dies, it might just be a giggle for them. After all, it is just a game, there are no real repercussions. SO the systems as designed would need to be monitored and tweaked. If players destabilize too many systems, then artificial enticements or stimulus would need to be added into the system. The Miller might be given a cash infusion from the city council (in exchange for a discount price for future product), A farmer from a neighboring island, hearing about the cabbage crisis might start shipping in his own cabbage at inflated prices... he might even have to switch crops to do so. The idea is that a few administrators can chase large systems and keep them healthy faster than the same number of content authors can create new and unique content. This won't be a perfect solution, but rather than say it can't be done I would diversify and insert created content chains into the world to fill the gaps while letting generated content become the bulk of the player diet. The more content that can be triggered or generated either directly or indirectly by the players actions... the better.

Now, I just need to get off my butt and start coding interdependent systems... umm, this is going to be easy... right... ... ... anybody wanna help? ... Please?