What follows is the result of a random idea followed by a thought experiment followed by multiple discussions all which occurred after a decade or more of playing MMORPGs. If you are a game designer or developer and you like what you read here, please feel free to contact me at firstname.lastname@example.org. Happy gaming!
Disclosure: In the interest of full disclosure, I do not now (September 2016), nor have I ever worked for any company that designs and/or makes video games. I have played Firefall and MechWarrior Online, and I have never played Hawken, all of which do share some interesting and similar, but far from radical or new ‘character shell’ mechanics and I am vaguely familiar with Crowfall, but I have not played it as it has not been released at the time that I wrote and published this (September 2016).
Imagine a sci-fi MMORPG where players run the gamut from light infantry mobile battle suits to combat mechs the size of small buildings! Now imagine that video game solving major issues endemic in MMORPGs for both players and content developers alike; issues like abandoned leveling zones, abandoned dungeons, newbie griefing, gear and stat inflation, inventory problems, problems juggling multiple sets of gear, problems juggling multiple character builds, and in-game travel time. Now imagine hordes of rabid, happy gamers cheering you on and shouting your name as they throw money at you by purchasing and playing your awesome genre redefining new sci-fi MMORPG because you made MMORPGs fun again!
Over the many years that I have played video games in general and MMOs in particular multiple recurring pain points have lodged themselves in my brain. While technological advances have certainly pushed the genre of video games far beyond what any of us imagined in the early 1980s, some problems have become endemic in video games, not from technological limitations, but from the way that we, as humans, think about these games. And these problems encompass not just the player experience, but also that of the game designer and developers. What follows is list of some of the more egregious pain points for both sides.
Developer Pain Points
- Abandoned Content
- Leveling Zones
- PVP Battlegrounds
- Gear and/or Stat Inflation
Level Cap Content Abandonment
In possibly all MMOPRGs, players level one or more characters through zones until they hit the current level cap. This typically renders all of the zones used to level characters both absolutely necessary and also virtual ghost towns after the initial leveling rush. I call this phenomenon level cap content abandonment. MMORPGs slowly fill up with these abandoned zones until, near an MMORPG’s end of life, its digital real estate is composed predominantly of under- or unpopulated zones that cannot be removed, yet still require maintenance and support overhead as well as posing the continued threat of development overhead to implement new (expansion) games changes in those old areas or to alleviate technical debt.
Just as leveling zones become both abandoned and absolutely necessary to maintain, so too do dungeons, raids, and other level-pegged player-versus-environment encounters. As players level beyond the maximum level requirement for the dungeon, raid, or encounter in waves tied to content release dates, all of those assets become underutilized or abandoned, but must still be maintained for players leveling through game after or between release dates. Again, these content assets become liabilities that cannot be removed from the game and must be maintained, exerting continued pressure and stress on development teams for maintenance and updates.
Lastly, player versus player battlegrounds are also the victims of level cap content abandonment. During leveling and even after reaching the game’s current level cap, PVP battlegrounds provide an alternative method for players to level and/or earn PVP-specific gear and/or bragging rights within the MMORPG’s player base. However, when there are level restrictions on certain battlegrounds, PVP battlegrounds become abandoned as the player base levels beyond the maximum level requirement for any given battleground. Scaling characters’ levels up or down has been utilized in some MMOs as a possible solution to the level cap content abandonment problem, but the truth of this experience remains that few, if any, scaled up low level characters ever best fully geared level capped characters because the scaled up low level character is missing the full range of class abilities (and time spent playing and learning a given character) and low level gear does not provide combat or ability bonuses that truly even the playing field even when scaled up.
Level Cap Content Abandonment User Story
As an MMORPG designer/developer, I want to create content for my game that will not be forcibly abandoned by my game’s player base due to the mechanics of in-game progression, so that I can create meaningful content that will continue to bring joy to players throughout the life of my game.
Another major issue in long life cycle video games is gear and stat inflation. Traditionally, gear (armor, weapons, etc.) is offered as rewards to player characters who complete content (quests, dungeons, raids, etc.) with better gear being awarded for the completion of more difficult content. This is all well and good within a single iteration of a game, but for games that are expanded upon over the course of time, it becomes a challenge to reward players with gear that offers a meaningful sense of progression from one iteration of the game to the next without artificially inflating the stats on that gear. The classic example of this vanilla World of Warcraft (the first version of the game) versus the World of Warcraft Cataclysm expansion (the third expansion of the game).
In vanilla WoW, a level capped character who had completed all of the end game content, and only a small fraction of the player base actually did this, might have hit points/health somewhere around 7,000. And this would have been for a character that served as a tank. All other classes would have had much fewer hit points. In the Cataclysm expansion, characters who had finished questing and who had not completed endgame content already had hit points over 100,000. This is an almost fifteen fold jump in roughly five years! Player characters at the end of Cataclysm often had more hit points and better stats than endgame boss monsters in vanilla WoW! This kind of rampant gear and stat inflation was the subject of much heated debate by WoW players before and during the Cataclysm expansion.
Finally, it is also worth noting, that this kind of gear and stat inflation only further exacerbates the issues of level cap content abandonment as players find it much easier to progress to the next expansion of a game if it has been released than it is for them to engage in endgame content in the version of the game that they are currently playing since the gear offered as quest rewards in the expansion will outclass any of the endgame geared offered in the previous iteration of the game long before they reach the end of the expansion’s stock quests!
Gear/Stat Inflation User Story
As an MMORPG designer/developer, I want to create progression mechanics and gear for players that does not promote rampant gear/stat inflation, so that I can ensure the continuity of my game’s character progression experience from iteration to iteration of my game.
Player Pain Points
- (Gratuitous) Newbie Griefing by Level Capped Players
- Problems Juggling Multiple Character Builds
- Problems Juggling Multiple Sets of Gear
- Problems Managing Character Inventory
- In-game Travel Time
Newbie Griefing by Level Capped Players
Newbie griefing is not a new phenomenon in online games. And while many players consider it nothing more than a nuisance, in then end, it is still a very frustrating and unpleasant experience. At its essence, newbie griefing is little more than online bullying tacitly sanctioned by traditional game design. And there is little to no value in allowing players with level capped characters to brutally savage unsuspecting players with lower level characters that have assumed that they are in a safe zone because they are in their own racial or class starting zone!
However, designing an MMORPG devoid of open world player-versus-player combat seems harsh and backward. A healthier sentiment would be to allow open world PvP but to somehow even the odds for all concerned without resorting to artificial mechanics like character level scaling. This approach would likely serve to promote meaningful open world PvP combat between groups of players from opposing factions/guilds/clans/etc.
Newbie Griefing User Story
As an MMORPG designer/developer, I want to create a game that promotes meaningful open world player-versus-player combat, so that players can engage other players in meaningful, evenly balanced contests without one player or one side being lopsidedly over or under powered.
Problems Juggling Multiple Sets of Gear
Another common problem in MMORPGs is that of juggling multiple sets of gear for a single character. In some MMORPGs, players feel the need to carry or have access to one set of gear for PvP and still other sets for each character build that they have access to (i.e., healing vs damage). This can leave a player juggling two to three sets of equipment for a single character. This also eats up limited inventory and/or storage space, and can often require an in-game mod to perform all this equipment juggling for them. However the player chooses to solve the problem, provided such solutions exist, juggling multiple sets of gear simply eats up time and detracts from the primary purpose of gaming, which playing and enjoying the game.
Multiple Gear Sets User Story
As a player, I want a quick, easy, and effective way to handle multiple context specific gear sets for my characters in game, so that I do not waste my play time juggling gear sets in-game or searching for solutions outside of the context of the game.
Problems Juggling Multiple Character Builds
In addition to forcing players to juggle multiple sets of gear, some MMORPGs force players to juggle multiple character ability/skill/talent builds, forcing players to take screenshots or notes or use third party character builders to record their prefered builds. The original impetus behind allowing multiple builds per character was to give players more freedom and choice in their play styles depending on their given context, i.e., healing when playing with a group or damaging when playing solo. However, the implementation of this idea in some MMORPGs put the onus of recording this information onto the player outside of the context of the game. Again, poor implementation of allowing multiple builds only serves to take players’ time and attention away from the primary goal of gaming when they are forced to switch build, which is the enjoyment of actually playing the game.
By confining skills, gear, and abilities to a given shell, i.e., a player’s chosen mech or battlesuit, this allows the player to focus on the strengths of that particular shell. When a change is required, the player simply redeploys to the zone in a different shell (which should also be a quick, easy, and frustration free process).
Multiple Character Builds User Story
As a player, I want a quick, easy, and effective way to juggle multiple builds for my characters in game, so that I do not waste my play time juggling multiple builds outside of the context of the game.
Problems Managing Character Inventory
Inventory management has long been a staple of the RPG experience from the earliest days of tabletop RPGs to modern MMORPGs. It has been both one of the joys and, at the same time, one of the banes of RPGs and MMORGs. Effective inventory management for players requires that players have the requisite space in their inventories to manage all of the items in their inventories. One of the complicating factors in this has always been the difference between trash items, which are sold immediately, quest items which are used to fulfill quests, crafting items which are saved for later use, and all of the character’s gear, i.e., existing armor and weapons, plus new quest rewards.
The single most effective way to manage this is to provide players with separate, yet easily accessible crafting, quest, and gear inventories with stackable items that, while playing in a given zone, largely limit themselves to items available in that zone, while allowing players access to their entire inventories when they are not deployed to a zone or are residing in a non-combat and non-level differentiating zone like a faction hub city. The number of slots available in each zone-base inventory tier could be something as simple as picking a number, like 12 or as complex as providing for a storage unit attached to a character’s mech that determines how many initial or additional inventory slots are available in a zone. Total inventory slots available could be the base inventory slots multiplied by the zone number (1-12) for each of the gear, quest, and crafting inventories. Restrictions on the stackability of items should be greatly reduced or eliminated (i.e., allow stacks of 999) so that players are not frustrated by using 6 of their 12 available inventory slots for limited stacks of a given resource required to make meaningful trades, level crafting skills, or craft meaningful gear (i.e., 6 stacks of 20 copper ore to create a worthwhile piece of gear or level their crafting skill).
The final pain point to be addressed here would be the handling of trash items. In many moddable MMOs and MMORPGs players themselves have created mods or plugins that automatically sort and sell trash items when the player’s character interacts with a vendor. This should become a baseline feature of all MMOs/MMORPGs. This eliminates tedious time spent locating and clicking on trash items to sell them and removes this minor irritant from the player’s in-game experience.
Manageable Character Inventory User Story
As a player, I want a quick, easy, and effective way to manage my character’s inventory in game, so that I do not waste my play time deciding what to keep, what to sell and where and how to store it.
In-game Travel Time
In large MMOs with a large number of zones of varying sizes and levels, it can often become a tedious chore to travel from one zone to another requiring anywhere from a minute to ten minutes or more. If players have limited available play time, then any time spent in transit from one area to the next is time spent not playing, which can be a nuisance. However, it is likewise undesirable to allow players to teleport at will to any point in the game world as this defeats the design concept of creating environments and activities that take players on a guided journey through the game. Some middle ground must be found that will allow for both a guided journey through content and minimization of non-productive travel time for players.
Using the concept of deploying into a zone from central faction hub alleviates much of the down time spent in transit from one zone to another via individual waypoints in each zone.
Ingame Travel Time User Story
As a player, I want a quick, easy, and meaningful method of traveling from zone to zone in game, so that I do not waste my play time in transit from one area to another.
Design Solution Concept
In traditional MMORPGs, players create characters with one locked in class that they then use to interact with the environments and other players within the game. This results in all major core stats and skills being attached to the character with minimum and maximum effects (ability to hit and damage, etc.) usually being determined by the character’s level and with bonuses and effects to those stat coming from the gear (the weapons and clothing/armor) that the character wears. This is a design paradigm that owes its origins to tabletop role playing games like Dungeons & Dragons. However, irrespective of how traditional this design paradigm is, it does not need to be an inviolable rule of MMORPG design in the digital age. There are other options.
Imagine an MMORPG where players create characters with a core set of skills but no core attributes and where traditionally derived attributes like health and damage are attached to the armored suit/mech that the character is wearing or piloting. Imagine that each zone of the MMORPG encompasses roughly 10-12 character levels and has an associated weight class of armored suit or mech. It might look something like this:
|Game||Zone||Level Range||Base Skill Range||Mech Class|
|Core||3||24-36||24-36||Light Vehicle Class|
|Core||4||36-48||36-48||Medium Vehicle Class|
|Core||5||48-60||48-60||Heavy Vehicle Class|
|Expansion 1||6||60-72||60-72||Light Giant Robot Class|
|Expansion 2||7||72-84||72-84||Medium Giant Robot Class|
|Expansion 3||8||84-96||84-96||Large Giant Robot Class|
|Expansion 4||9||96-108||96-108||Space Mechs (space fighters)|
|Expansion 5||10||108-120||108-120||Small Starships|
|Expansion 6||11||120-132||120-132||Medium Starships|
|Expansion 7||12||132-144||132-144||Large (Capital) Startships|
Instead of players leveling into and out of zones in a traditional MMORPG, completely discarding old gear, and then moving on leaving zones empty of players, imagine an MMORPG where the character deploys into each zone from a ‘garage’ screen where he or she is presented with a map of accessible zones to select from. Once a zone is selected, the player is then presented with a selection of armored suits or mechs appropriate to only that zone’s level range. The analog for these armored suits/mechs in a traditional MMORPG would be a character class. Any other armoured suits or mechs (i.e., character classes) that the player’s character has access to are not displayed and are not selectable for the selected zone. The player selects one of the available armored suits or mechs and then deploys to any available base in that zone. This design approach ensures that any player deploying to a zone does so only in a level-appropriate armored suit or mech.
Armored suit/mech progression within the zone begins at the zone’s lowest allowable level and progresses to the zone’s maximum allowable level. A character’s skills are likewise pegged to this level range, but may be modified, slightly, by buffs, gear, or other special circumstances, but should never be more than 1.25 times the maximum level limit. However, this ‘rule’ is an assumption that should be validated by testing. By placing limits on how far a player can progress both his character and his character’s armored suits/mechs, each zone is effectively limited to the armored suits/mechs designed for it. When players deploy their higher level characters back to a lower level zone, they are in effect, throttled back down to that zone. This ensures that these higher level characters have little native advantage due to their progression in the game. However, they can eek out some small advantage by completing content and special events within that zone that allow them to collect the best possible gear for their armored suit/mech available from that zone. A comparison of characters in that zone might look like this:
|Skill or Stat||Level 1 (Base/Geared)||Level 12 (Base/Geared)||High Level Player (Base/Geared)|
|Piloting||1 / 1||12 / 13||12 / 16|
|Direct Fire Weapons||1 / 1||12 / 14||12 / 16|
|Indirect Fire Weapons||1 / 1||12 / 12||12 / 16|
|Armor||100 / 100||1200 / 1450||1200 / 1600|
|Speed||10 / 10||10 / 12||10 / 16|
The difference between the character who has reached the upper level of the zone limit and is ready to progress to the next zone is not extraordinarily underpowered compared to the much higher level character who has farmed the zone until he/she has the best gear available for his/her mech.
Each armored suit/mech would have an identical set of slots* into which different components could be placed to control available damage types, armor, speed, etc. Each component would have a quality class** and associated stats for rate of fire, damage type, and damage (for weapons) and armor points and defense types (for armor).
Head/CnC (optional): targeting module
Right Shoulder: weapon, armor
Left Shoulder: weapon, armor
Back: jump jets, armor/shield, special ability module, weapon (optional)
Right Arm: weapon, armor
Left Arm: weapon, armor/shield
Core: armor (optional: storage upgrade)
Power: power generator
Leg Chassis: servos (speed), armor
Feet: jump jets
**Component Quality Classes
|Quality Class||Class Name||Class Bonus||Wpn Attributes*||Armor Attributes*|
*For a zone one item
Thus far, I have only addressed an MMORPG with one faction, presumably some type of humanoid race that utilizes various battlesuits and mechanized armor of differing weight classes. This was for simplicity in the exposition and explanation of the previous pain points and their possible solutions. However, a one-sided conflict in an video game tends to lack a certain depth of variety. This is easily solved by using the same shell mechanic to create additional factions. This mechanic can be replicated across a multitude of humanoid races or pushed even further out to include any type of of a consciousness (the player’s account) inserted into a shell conceit. Here are some examples:
|Humans||Battlesuits, mechs, vehicles||Pilot|
|Space Elves||Battlesuits, mechs, vehicles||Pilot|
|Space Dwarves||Battlesuits, mechs, vehicles||Pilot|
|Space Orcs||Battlesuits, mechs, vehicles||Pilot|
|Artificial Intelligence||Battlesuits, mechs, vehicles||Player account is considered ‘software’ that is loaded into various highly technologically advanced combat shells that do not need to look or feel humanoid|
|Parasite||Organic shells||Player account is considered a kind of ‘parasite’ that is organically loaded into various biological host shells that do not need to look or feel humanoid|
Replicating this shell mechanic across multiple factions allows for the game designers to create a rich and complex environment where conflict is rife across multiple warring factions (2-3 or more).