Precursors to MMORPG

Inspirations for MMORPG

History of MMORPG

Setting

Most wanted settings:

1. Fantasy/medieval
2. Other setting
3. Futuristic
4. Post apocalyptic
5. Outer space
6. Contemporary

Features

Top 5 best liked features:

1. Class/skill options
2. Graphics and effects
3. Large world to explore
4. PvP
5. Socialization

Bottom 5 least liked features (5 is the least liked):

1. Extensive story telling
2. Low latency
3. Instances
4. Raid content
5. Low system requirements

Issues

Top 5 issues:

1. Exploits and cheats
2. Running out of content
3. Player griefing
4. Real-world services
5. Camping rare items/spawns

Note: Running out of content was reported as the second largest issue, but "lots of content" was only the 6th most wanted feature.

Character development

Most wanted character development systems:

• Combination of class and skill : 41.4
• Skill : 40.6
• Class : 9.8

Improving existing features

• PvP combat: More balanced between classes (usually follows a "rock, paper, scissors" format)
• The (level) grind: Do repetitive actions in order to advance should be improved/hidden by giving it a purpose
• Story line (quests): Better distinguished from grinding; quests should be meaningful and drive the story
• Graphics and effects: Better graphics, but without new hardware. Exactly which improvements? Most could not pinpoint a specific improvement
• Content and updates: Response time on bugs; the need to utilize the variety of a raid party
• Classes and skills: Not balanced for all types of gameplay (e.g. PvP vs PvE); disputes about skill/class progression
• Technical enhancements: Better AI for better immersion
• Item crafting and economy: Needs more meaningful crafting; balance between worth before and after crafting
• Combat and skill: Too repetitive and/or easy combats
• Downtime: Time wasted finding party, travelling, and preparing for combat should be reduced

New features

• Player impact on the world: "How can thousands of subscribers all feel like the hero?"
• Player-created content: More content and quests, made by the users. The problem is to limit the amount
• Technical enhancements: Adding voice chat
• Mini-games: Increase amount of variety and content with mini-games unrelated to the storyline
• Item crafting and economy: Make it more significant by limiting drops; specialized crafting skills, with trading/buying from eachother
• Player-aging and death: Debated, because it would raise the stakes, but at the same time be a huge loss to a committed player when it happens
• Dynamic environments: Flood, fire, weather, day and night; greater immersion if the environment changes
• Dynamic content and quests: Generate content based on player decisions for a personalized experience, and better "replayability"
• Realtime combat and damage: Targeting and then executing attack seems unnatural, they want a more fluid experience
• NPC interaction: They are too static, does not seem real. Should go and live a normal life when you don't need them
• Evolution: Biological and technological evolution according to a timeline

Challenge

Fantasy

Fantasies makes games more interesting to the player, and can make them more compelling or be used as a means of challenge (requiring the player to use his fantasy in order to complete a challenge). Not all fantasies are compelling to all types of people, and need to be carefully considered according to the target audience.

Curiosity

"Curiosity killed the cat, but satisfaction brought it back"

A player's curiosity can be evoked by having just enough informational complexity, that is, some uncertainty in the information provided, while the situation is still comprehensible to the player. In order for the player to feel in control and have fun, the curiosity should be satisfied at some point.

Note that this differs from uncertainty in the challenge: A challenge refers to what the player can do, and complexity to what the player can understand.

Concentration

A requirement for being absorbed in the game is having full concentration on the game and solving the task at hand. In order to do this the tasks should be meaningful, have an appropriate workload, and minimize non-related interactions (e.g. settings or other screen elements).

Example: Detailed world elements, compelling narrative, simple gameplay and interface, and numerous tasks and objects to monitor.

Challenge

A challenge should match the player's skill level and provide different levels of difficulty for players of different skill level, in order to feel neither bored nor anxious. The level of satisfaction of completing a challenge depends on the perceived level of accomplishment, and is a form of intrinsic reward. Pace is said to be an important element, because too many challenges (although at a fitting difficulty level) can be tiring.

Example: Difficulty of AI, mission variation, mastering different races, balance between races.

Player skills

The player should improve their skills during the game, and the learning should feel like a part of the game (which can make creating tutorials a challenge). Hints and tips during gameplay, or create real-world analogies, can be effective tools to help the player without interrupting the game. Learned skills should be useful for future challenges, and rewarded appropriately compared with the level of progression.

Example: Tool tips, online help, optional tutorial that fits story, RTS conventions, sensory cues, gradual introduction of elements, ability/skill/story rewards.

Control

Players should be able to translate their intentions into in-game behaviour, and facilitate different styles of playing by allowing customization of controls. The control system (whether menues or actions) should be as effortless as possible to use. Actions should have an impact on the world, and let the player solve the problem the way they want (e.g. a multiple choice list of actions will restrict control). There should not be a single optimal strategy when facing a challenge, or the player will feel like being played.

Example: Pathfinding, adjust unit aggression and formations, hotkeys, different play styles for different races.

Clear goals

Goals should be easy to understand and presented at appropriate times (if there is a story, an overall goal should drive the player from start to finish). Each level should have multiple goals that test players in different skills and levels of difficulty.

Example: Introduction to story/world, in-game cutscenes, mission objectives.

Feedback

Feedback should guide the player, both when winning and losing, and provide motivation to continue. In this respect, feedback is essential for maintaining concentration. Both actions and status/score should inform players of their success.

Example: Notification of mission success or failure, mission log, status, score and summary at end of mission, sensory feedback on actions and events.

Immersion

Games should provide deep and effortless involvement, be emotionally engaging, and provide an "escape" from daily life (most games provide an experience that is unavailable to the player in real life). To do this, the interface should be transparent to the player's perception, the story/background relatable, and the game should affect the players senses in an appropriate way.

Example: Concentration, connection to heroes and story, no waiting.

Social interaction

Not directly an element of Flow, and can be both constructive and destructive. The social interaction must either be just what it is, a social device, or improve other flow elements, e.g. motivate cooperation, competition, or immersion.

Example: Multiplayer modes, matchmaking and rankings, text chat, ability to create and share game content.

Tools

The game development community have received little attention regarding development of tools to use. Console producers usually ship some development tools, but since the life span of a console is around 5 years, the tools are only updated for 4 years, tops, and learning to use each tool takes time. 3D-modeling tools are available, but usually directed towards animators and not games. This resuls in game developers creating their own tools, at least when innovating in technology or game design. Lately better asset management tools have been made available, but the article states it is not optimal.

The most common programming language to use is C++, mainly because it is fast, but it is not made to compile game code fast, and no development environments has been created for working with game development.

Workflow

Compiling games takes a long time, as well as debugging, and loading of data (usually not optimized early in development process). When you have to debug for multiple platforms problems are bound to occur often, which requires compiling and loading between each fix for each platform. Some dynamic loading of content and code has been employed successfully. Distributed compilation have also been used, but is no cure-all solution. Refactoring is often performed to improve the compile time, but this sometimes happens at the cost of runtime speed.

Multiplatform development

Prone to errors when developing for several platforms, and lots of restructuring of code is required. With a team of several programmers, code should ideally be merged often, but since the workflow is slow and you don't want to introduce errors which hinders other developers from working, merges are often performed rarely.

3rd-party components

Some components have good reusability, some not. An overview of reusable components, according to success:

• Very successful:
  • Audio low-level
  • Rendering low-level
  • Skeletal animation and morph targets
• Slightly successful:
  • Collision detection and physics (hard to create though)
  • Networking low-level
• Mixed success:
  • Scene management
  • Persistent object storage
  • Scripting languages
• Non-existant:
  • AI functionality

In general, most of 3rd-party components are difficult to use, and requries good insight into the low-level functionality to use properly. Some also requires a specific structure of the data and components, which impose contrainst on the rest of the system. In the end the usefulness of buying versus creating their own components needs to be done for each component.

Full-figure options

There are some game engines available, such as Unreal Engine, which offers a full game development environment. Sometimes they are perfect for a development team, but they are expensive, technically conservative (i.e. cannot innovate gaming industry with them), and has limited applicability in types of games.

Engine code

Creating engine code requires the programmer to be knowledgeable in multiple areas, including mathematics and algorithms. Typical mathematical problems in game development include linear algebra and signal processing, and algorithmic problems 3D problems such as spatial partitioning, intersections, and clipping. There has been done a lot of research in the area, but usually for offline systems that can be adjusted between runs in order to get the wanted behaviour.

Cross-cutting concerns

Many problems have good solutions, in isolation. Making them work together in a harmonious way is harder to do, and in game development there are complex system structures and algorithms that need to be designed to work together.

Depth of simulation

When dealing with realtime graphics, most of the numerical data needs to be integrable over time, which presents many problems in the discrete world of programming (integrate if/then/else-like statements?). Additionally, problems like stiffness (changing parameters results in failure) and tunneling (objects moving through each other when they should collide) occur due to the continuous nature of physics in game worlds.

Profiling

Profiling is a hardware optimization technique that analyze computational requirements and assign computations accordingly to utilize most of the hardware capabilities. The problem in game development is that the bottlenecks are constantly moving from one part of the system/code to another, which means that commercial tools for profiling (using averages for distributing workload) often fails to optimize anything, and vendor-specific profiling tools too general/insufficient for high optimization.

Risk

Game developers are constantly under pressure to deliver something new. This requires using new technology and game design, which introduce uncertainty in both development and end result.

GamePipe Laboratory

A research group dedicated towards developing methodology (principles, processes, and procedures) and tools for creating serious games, in order to shorten development time and improve the quality of such games. The group includes researchers and students from several universities and fields of study.

Infrastructure

MMOGs have pushed the limits of research in areas that are useful in serious games, such as large, networked simulations. But this work has not provided dynamical systems fitting a variety of serious games, which will need to be developed in order to achieve reusability. Current game development engines have limitations, such as size of game areas, and are usually really expensive. The ability of streaming large amounts of data will also need some attention in order to facilitate future requirements.

Cognitive game design

To create a realistic simulation, better human and organizational behaviour needs to be developed, that can run a large number of entities simulaneously. Also, to provide flexibility, a way of creating compelling computer-generated stories should be deviced, which supports player immersion. Usually such tasks have been done by a human monitor, but this is not a viable solution in the long run.

Immersion

Further development in graphics, sound, and haptic feedback is required to create more realistic simulators able of evoking certain emotions in the player. Many environments require the player to cope with, e.g. stress, and has limited usefulness without being able to provoke such emotions. A field of study called affective computing deals with monitoring human responses, like facial expressions and physical responses, which will be crucial in having the game react appropriately. At the time the article was written (2005), it was said that such monitoring systems would be available to a low price within a couple of years, but this seems to still be some years away.

Another element that breaks immersion today is the quality of computer controller entities, i.e. we need better AI.

Emotional factors

The problem with emotional requirements is there are no formal techniques of eliciting specific emotions, and may be hard to specify.

Language

In order for people in different fields and processes of game development to understand each other, they need a common language and understandable documentation. However, creating understandable documentation, at least for the creative process, will impair the end result, and possibly require more iterations of feedback and adjustments.

Elicitation, feedback and emergence

After documentation has been reviewed by the team responsible for the next step in the process, there will often be discovered limitations or misconceptions that needs to be considered in the previous step (e.g. creative team assumes AI will be better than state-of-the-art). As a result there will be a loop of feedback and adjustments, that emerges as new requirements.

Pitfalls

• GDD as requirement specification: Either, the GDD is overly specific or the GDD is solved on a case-to-case basis
• Going into production too soon
• Not documenting changes

Categories

The responses in the evaluation was attributed one or more of the following categories:

• Preproduction
• Internal
• External
• Technological
• Schedule

Results

Internal issues had many more "rights" and "wrongs" than any other category. Many issues were reflected in several categories, which shows a strong cross-domain correlation. All categories were reported to have about equal amount of "rights" and "wrongs", even in the same project, based on different factors. The reason for this is unclear, but might be attributed to a problem with the categorization, or its just an inherent property of the data.

Documentation transformation

A documentation transformation roughly needs to go through these steps:

• Story: Background for the game
• Gameplay: How the story should be played
• Requirements: What the gameplay requires from a technical perspective
• Specification: Detailed implementation descriptions based on the requirements

Each step produce longer documentation, and workers at each step must take different viewpoints, domain language, NFRs, and inconsistencies from the previous step into account.

Implication

GDDs contains a lot of implied information (probably because of the abstract nature of the specifications?), which needs to be analyzed and understood in order to be specified in a formal manner later in the requirement engineering process. Some levels of implication mentioned in the article:

• First-level implications: Derived directly from the presented material
• Domain knowledge implications: General knowledge about the domain required (e.g. genre elements)
• Implementation knowledge: Knowledge about how the game will be created (e.g. architecture)

An issue raised here is "when should feedback be given?". Late feedback means more work for the programmers, early feedback could have a negative impact on the creative process (conditioning from multiple early restrictions).

A priori knowledge

Everyone cannot know everything about every step of the process, and teaching technical details and such may take longer than an iterative feedback process. Often, the people that should formalize documentation have too little time, and junior staff members which have less knowledge and experience are assigned the task. All of this leads to multiple collaboration problems:

• Lots of abbreviations
• Lack of technical knowledge
• Difficulties in representing visual content in a formal manner

Game logic

Game graphics

Metrics

• Size:
  • Lines of code
  • Number of classes
• Complexity:
  • Attribute complexity: Sum of attribute complexity values in a class (each type assigned a subjective value)
  • WMPC 1: Sum of weighted CC
  • WMPC 2: Number of methods and parameters (higher number = higher complexity)
• Coupling factor: Number of non-inheritance couplings divided by maximum number of couplings
• Lack of cohesion methods: Number of pairs of methods in a class that shares an attribute

where CC (Cyclomatic Complexity) denotes the number of paths through an algorithm.

Results

• Size: Class size went down (good), project size up (bad)
• Complexity: Went down (good) except slight rise in project WMPC2
• Coupling factor: Went down (good)
• Lack of cohesion: Went down (good)

Players

Player enjoyment is the most important criteria when developing games, and require great consideration when choosing design. The criterias considered in this article:

1. Consistency and immersion
2. Intuitiveness and learning
3. Emergent gameplay and player expression

Developers

Different games have different requirements, and the developers need to be aware of the pros and cons when deciding which approach to take. Criterias considered in the article:

1. Effort in designing, implementing, and testing
2. Effort in modifying and extending
3. Level of creative control
4. Uncertainty and quality control
5. Ease of feedback and direction

Evaluation of player criterias

1. Inconsistency between player's expectations and scripted dynamics, which degrades immersion
2. Limited interaction with environment, which breaks intuitivity and player needs to learn its limitations
3. Low degree of freedom

Evaluation of developer criterias

1. Planning requires a lot of time, all elements need to be controlled and tested
2. Scales poorly, hard to extend
3. Full creative control
4. No uncertainty, but needs to be tested for inconsistencies
5. Knows when and how player will interact, so it is easy to give feedback and directions

Techniques

• Finite State Machines
• Scripting languages: Simplify some set of programming tasks

Evaluation of player criterias

1. Intuitive behaviour of world, so greater immersion. Objects consistently behave as expected
2. Intuitive world lets player use external experience, which requires less learning
3. Creative control to solve problems, higher replayability

Evaluation of developer criterias

1. High initial effort in planning, building and fine tuning, but high reusability
2. Easy to scale and extend
3. Lose creative control, hard to control the flow of the game
4. High uncertainty, does not always behave as intended and requires lots of testing
5. The player needs more feedback due to the open environment (but possibly harder to give? Article does not say)

Techniques

• Flocking: E.g. movement of groups of individuals
• Cellular Automata: E.g. influence maps for decision-making or social behaviour
• Neural Networks
• Evolutionary Algorithms