The availability has improved drastically after more devices were introduced, especially the ability to play on devices not designed for games, such as PCs and mobile phones. This had a huge impact on the gaming demographics. Being able to save games enabled game developers to create stories, and gamers to experience progress on another level. Internet also provided with interactivity that revolutionized gaming.

Chronology

Some major events:

50-59: First game in 52 (tic-tac-toe), and the first interactive game (tennis)

00-09: Pirating, different requirements for different target audiences (e.g. graphics vs game dynamics)

10-11: 3D screens, pervasive games, more smart phone games

Pervasive games

Introduction

Pervasive games are games where virtual and real game elements are used together. There are many different types of pervasive games. Examples of these are smart toys, affective games, tabletop games, location-aware games and augmented reality games.

Smart toys

Most current smart toys are traditional toys equipped with simple sensing technology linked to computer logic. Based on how the toy is used, sounds can be played or graphical information can be displayed. Smart toys are excellent for pervasive games because the toy design suggests interaction method, and parents are not so reluctant to let the kids use smart toys as spending time in front of a monitor.

An example of what a smart toy can be used for is digital storytelling, encouraging children to use the toy in a specific way.

Affective gaming

The goal of affective gaming is to capture how a player is feeling at any given moment and use it to enhance the game experience. This can for instance be done by using sensors to detect how the body is responding, voice analysis, or facial expression analysis.

An example of this is a two-player game where each player tries to move a physical ball which moves based on how relax the players are. Another example is making a player’s character jump when the physical player jumps from being startled.

Location-aware games

Location-aware games work by using technology to track and identify players and objects, and turn the real world into a game board. This can be done with GPS, WiFi, infrared beacons, RFID or other signals. Games like these allow the players to walk around in the real world and use technology for virtual objectives. There are issues with this, like the uncertainty of sensing and wireless communication.

An example of this is a game where players can walk around outside and collect treasure, or accept objectives that shows up only on their smartphones

Augmented reality games

Augmented reality games are done by drawing virtual reality objects into a real-world environment. Users see their view augmented with 3D objects so they appear to exist in real space. This concept fits well with Stapleton's Mixed Fantasy Triad, which says that the ideal entertainment experience provides a combination of physical experience and virtual content, which stimulates the player such that they use their imagination to fill the gaps.

The three general approaches are:

Head-mounted display: Users see virtual objects along with video of the real world taken from a camera mounted on their heads.

Projecting images on real-world surfaces: Difficult to do, and interaction spoils the effect.

Using handheld devices: A lightweight display device with camera can be used as a window into augmented space.

Most of the augmented reality games seen so far have required specialized hardware and controlled environments, which makes the games less convenient. Additionally, finding good interaction methods have been difficult.

MMORPG: Past, Present and Future

Glossary

Griefing: The act of irritating and angering people in video games through the use of destruction, construction, or social engineering

NPC: NonPlayer Character, i.e. a character controlled by the computer

RPG: Role-Playing Game

MMO: Massively Multiplayer Online

Background (part 1)

Precursors to MMORPG

Inspirations for MMORPG

Dungeons & Dragons (D&D)

Table-top game where the good tries to destroy the evil, inspired by The Lord of the Rings and containing similar types of races. Leading a character through an environment, and according to a set of rules and instructions perform tasks that progress their journey.

Multiuser dungeons

MUD1 was a text-based, multiuser dungeon computer game released in 1978. Gameplay was similar to D&D.

Single-player computer RPGs

Introduced real-time mechanics, several possible ways of completing tasks, and graphics so that players did not need to rely (that much) on their fantasy to play.

Multiplayer computer RPGs

Only for a small number of players, and could usually be played both alone or with others over LAN or internet. Some had player impact on the world and randomly generated content.

History of MMORPG

First-generation (1996-99)

Meridian 59, which was released in 1996, is often credited to be the first MMORPG (this is disputed). Had mini-map, chat (with event logging), and player interaction. It was also the first to adopt the monthly fee as opposed to hourly rate. Some more MMORPGs:

Ultima Online: First commercial success. Heavy on PvP

EverQuest: Introduced the idea of raids

Asheron's Call: Custom interface

Second-generation (2000-2004)

Improvements to the graphics and interface (learned from first-generation), as well as Realm vs Realm combat, instances, player economy, crafting, and highly customizable characters. Some MMORPGs from this period:

Dark Age of Camelot: Realm vs Realm

Anarchy Online: Instances

Final Fantasy XI: Cross Platform

Eve Online: All on one server

Star Wars Galaxies: Crafting

The City of Heroes: Highly custom characters

EverQuest II: Polished from experience

World of Warcraft: Accessible

Survey results (part 2)

122 people participated, where the first part were a quantitative questionnaire, while the second was qualitative.

Setting

Most wanted settings:

Fantasy/medieval

Other setting

Futuristic

Post apocalyptic

Outer space

Contemporary

Features

Top 5 best liked features:

Class/skill options

Graphics and effects

Large world to explore

PvP

Socialization

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

Extensive story telling

Low latency

Instances

Raid content

Low system requirements

Issues

Top 5 issues:

Exploits and cheats

Running out of content

Player griefing

Real-world services

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.

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

Wear Out Effect of a Game-Based Student Response System

Presentation
How is the classroom dynamics, students' engangement, motivation, and perceived learning affected by GSRS short time vs long time? And finally, do they want to continue using it afterwards?

Glossary

SRS: Student Response System

GSRS: Game-based Student Response System

BYOD: Bring Your Own Device

SRS

SRS opened for new ways of teaching in the classrom by offering interactivity and new ways of learning for the students. It also provides benefits to teachers, as it allows them to receive real-time feedback on the learning progress of their students, as well as feedback on the quality of their lectures. The only problem was that some additional device was required in order to participate, which the wave of BYOD solved.

Some other benefits mentioned in the article (some assuming a "promised" quiz at the end of the lecture, so that students have that in mind when working):

Higher attendance

More focus throughout the entire lecture

More work done by the students during class

Most students and lecturers were positive to SRS

Anonymous participation (shy students have benefitted immensely from this, in both learning and showing knowledge)

Peer cooperation (discussing misconceptions)

Make students the teacher by letting them create a quiz

There are also reported challenges:

Time to learn and set up

Create effective questions

Adequate coverage of material

The ability to adapt to instant student feedback

Unreliable technology, such as browser compatibility and wireless

GSRS

Compared to a SRS, a game-based SRS has more emphasis on engaging and motivating students by gamifying the response experience. The idea that fun and engagement provided through games help students learn topics, without realizing it is "work". According to the article, no documented effect on the use of GSRS was found.

Results

The test was performed on Kahoot!, Alf Inge Wang's own creation, by Alf Inge. Some hundred students were given a questionaire with questions concerning their subjective experience of the use of Kahoot!, with the summarized results here:

Classroom dynamics: Small wear out

Engagement: Minimal wear out

Motivation: Minimal wear out

Perceived learning: No wear out

Reusability: 94% wanted to use Kahoot! once a week or more

Specific experiences from the students (negative/neutral/positive):

Easy to use

Mixed response on reducing amount of talking

Fun to compete

Fun to play in the same room

Better concentration

More engaged

Mixed response on emotional engagement

Fun to play

Wished Kahoot! was used more

Neutral to positive response on topic motivation

Learned from playing

What Makes Things Fun to Learn? Heuristics for Designing Instructional Computer Games

The main goal is to provide game developers with some heuristics for making games more fun to play.

Characteristics

The principles presented in the article can generally be categorized as part of either

Challenge

Fantasy

Curiosity

Note that not all principles can be, nor should be, applied to every game. The best games do incorporate elements from all categories though, in a clever way.

Challenge

Goal

In order for a computer game to be challenging, it must provide an attainable goal. Without an objective of the game, people have less motivation to progress. A goal should be/have:

Obvious

Compelling

Appropriate difficulty (according to the players current skill)

Performance feedback

A goal can be made obvious and compelling by the use of visual effect and fantasy. Finding a specific target on a map is not very compelling by itself, but by adding a hero that has to travel there in order to save humanity, the player suddenly have a compelling motivation for completing the goal.

Uncertain outcome

A game is boring if a player is certain to win, or lose. Ways to make a game more uncertain:

Variable difficulty level

Multiple level goals (e.g. easily attainable main goal to drive the story, and a couple of difficult alternative goals to challenge good players)

Hidden info

Randomness

As to variable difficulty level, the difficulty can be automatically decided based on the player's performance, or chosen by the player. An important thing to notice is the player's self-esteem as a factor of the player's perceived success. In order to have success the challenges need to have an appropriate difficulty level, and in order for the player to understand their success, they need feedback and improve their skill. Variations of multiple goal levels include score-keeping and speeded completion. Hidden information can motivate the player to explore and understand his abilities, while randomness can increase the difficulty in achieving a goal.

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.

Extrinsic fantasy

It augments the game, by helping the player visualize the challenge and receive feedback.

Intrinsic fantasy

The player is required to use his fantasy to complete the game, e.g. shooting darts where distance and angle of the throw needs to be calculated (read: Fantasized) in order to succeed.

Emotion

A difficult element to incorporate in a game, but very powerful: If a player has empathy with the character, the character's goal seems more compelling, and the feedback received resonates stronger with the player; associating a game with a certain emotion has a strong impact on the overall impression of the game. But different players are enticed by different emotions, and as such there is no "one fits all". A common example is horror games: Some people just love it, and some people cannot stand it.

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.

Sensory

Capturing the attention of the player by sensory cues, such as changing visuals or sound, makes a player at some level curious about the change and moves their attention to the source. Some ways of using these effects:

As decoration

Enhance fantasy

As reward

As a representation system: E.g. boring battle stats can be quite enticing with the right sensory tools

Cognitive

When a person is "missing" some information, they feel a need to attain this information to feel completeness and consistency. In order for the informative feedback to be the most engaging, it should be surprising and/or constructive as to motivate further progress.

GameFlow: A Model for Evaluating Player Enjoyment in Games

Inspired by the psychological concept of Flow, this articles formulate an equivalent model for evaluating enjoyment in games, and evaluates its usefulness.

Flow

Invented by Mihaly Csikszentmihalyi ("Me-high Cheek-sent-me-high"), Flow denotes the mental state of operation in which a person is fully immersed and time seems to "fly by". The concepts apply to all types of activities, and is relatable to all humans in all cultures around the world. Although there are no precise definition of the requirements, the general elements can be defined as this:

Task that can be completed

Task has clear goals

Control over actions

Immediate feedback

Ability to concentrate

Immersion

No concerns, stronger sense of self afterwards

Sense of time is altered

GameFlow

The article redefines the previously mentioned elements to specialize it towards games, as described in the following subsections. The examples are taken from the games and may not fit a general context.

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).

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.

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.

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.

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.

Validation of GameFlow

The games were scored on a scale from 0-5 in each element from GameFlow. The games tested are very similar, but differed significantly in their ratings and economical success (Hint: Warcraft 3 was the successful one). These scores where averaged and compared with their ratings from GameRankings, in order to show if GameFlow can approximate how fun a game is:

Game: GameFlow vs GameRankings score

Warcraft 3: 96% vs 94%

Lords of EverQuest: 48% vs 61%

The scores are similar, and thus the GameFlow model seem to be correlated with the fun of a game.

Discussion

One important aspect of GameFlow, and Flow generally, is that the importance of each flow element is different for different types of games/activities. There is no "one fits all" solution, and one needs to find a clever balance between elements where they complement each other in the current context.

Another thing worth mentioning is the qualitative aspect of this review: All elements are subjective, and most requires extended observation of a player to evaluate properly, and are thus difficult to measure objectively. Tools for evaluating games more accurately and efficiently needs to be developed, as well as design models and tools for guiding creation of new games. An important observation was made in this regard: It was easier to identify shortcomings than what a game did well, and several well-done elements of Warcraft 3 was not noticed before its corresponding defects were noticed in Lords of EverQuest.

Game Development: Harder Than You Think

In the early years of game development, the primary concern of the programmers were to optimize the code on a low level in order for the game to run quickly. Now, its a challenge just to produce the desired end result, especially if multiplatform support are of concern. The first section introduce problems related to the size and complexity of game development as a software system, the next more directed at game-related problems.

Project size & complexity

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.

Highly domain-specific requirements

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.

From Visual Simulation to Virtual Reality to Games

Serious games

Serious games denotes the categories of games that are extended by pedagogy or instructional content. In order for a serious game to be successful the pedagogy part should be subordinate to the entertainment, or else the positiv effect of entertainment will be gone. This is what is called collateral learning, where the learning is a "side effect" of other activites that cannot be viewed as traditional teaching.

One of the issues, then, is incorporating pedagogy into games in a way that the player does not realize it. This requires people from all relevant domains, i.e. game designers, educators, and subject experts.

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.

Game production challenges

Some of the problems experienced in game production environments:

Dissolution of team after completing a game

Increasing learning time for tools

Increasing production time

Less reuse of components

Higher demands for portability

Research agenda

These areas are of special interest when researching serious games:

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.

Requirements Engineering and the Creative Process in the Video Game Industry

Combining create and technological processes are hard to do, where many problems can be traced back to the transition from pre-production to production, i.e. requirements engineering. The article presents some of the problems, highlighting the need for an improved requirements engineering process.

Glossary

NFR: Non-Functional Requirement

GDD: Game Design Document (conceptual description of the game)

Background

Requirements engineering is the process happening between preproduction and production, where the technical team needs to create a specification using the GDD. Some of the issues that arise are described below.

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.

Transition from preproduction to production

The current processes of requirements engineering have several faults that should be improved in order to shorten development time and avoid errors and misconceptions.

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

Postmortem evaluation

In the evaluation, members of development teams and middle management were asked top 5 things of what went right and what went wrong. They were also asked to stay away from "common" problems, and tell them what they perceived as unique or different for their project.

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.

Examples from real games

External problems would often lead to internal problems, which again would make the schedule uncertain.

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:

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

Challenges

Some challenges that are presented as unique to the game development industry:

Stakeholders with different backgrounds

Resisting feature additions

Influence of prior work (e.g. sequels of game series)

Media and technological integration and interaction

Importance of NFRs

Gameplay requirements

Evaluation of Object-Oriented Design Patterns in Game Development

Compared with earlier, games today are subject to higher change rates and greater complexity. Because of the increasing demand from customers we can expect this trend to continue, and so there is a great need to find design patterns in games to mitigate these developments.

Glossary

LOD: Level Of Detail

WMPC: Weighted Methods Per Class

Design patterns

Design patterns should be used in order to improve

Flexibility

Reusability

Maintainability

Comprehensibility

of code, which is especially important when future development and/or updates are required. One of the obvious answers to these problems are using modules of independent code that can be reused, and exchanged if necessary. By keeping all relevant logic in separate modules, the maintainability and comprehensibility will increase, and switching between modules for different behaviour increases flexibility.

Modules, or design patters, can be used in both logic and graphics of the game.

Game logic

Strategy pattern

The strategy pattern denotes a family of algorithms which are interchangable. Example: Different difficulties of a chess computer.

Observer pattern

An observer pattern is a one-to-many relation, used when an object needs to notify many other objects of changes. Example: Football team have had a practice, and so all players' skill should increase.

Game graphics

State pattern

This pattern allows an object to alter its behaviour when its internal state changes. Example: LOD according to distance from the object

Bridge pattern

Decouples abstraction and implementation, i.e. lets an object have multiple different, interchangable properties. Example: Ball having the possibility to have either smooth or rough texture.

Evaluation

Tests were conducted on two different open-source games, Cannon Smash and Ice Hockey Manager, because of availability, multiple releases, and presence of design patterns in one version and not in another.

Metrics

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)

Future research

More object-oriented design patterns should be examined to decide usefulness in keeping projects simple. Also, investigations to decide if classes participating in patterns are more prone to change should be done. The article authors are planning to implement a game engine or game according to the findings of the article.

Scripting Versus Emergence: Issues for Game Developers and Players in Game Environment Design

The article presents the issues associated with the two different design approaches, and discusses the methods used for facilitating each design.

Criteria

Players

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

Consistency and immersion

Intuitiveness and learning

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:

Effort in designing, implementing, and testing

Effort in modifying and extending

Level of creative control

Uncertainty and quality control

Ease of feedback and direction

Scripting

A scripted game is limited to the behaviour and progression the developer has predefined. While it is possible to create meaningful and engaging stories, some degree of immersion might be loss when the player discovers limiting dynamics.

Evaluation of player criterias

Inconsistency between player's expectations and scripted dynamics, which degrades immersion

Limited interaction with environment, which breaks intuitivity and player needs to learn its limitations

Low degree of freedom

Evaluation of developer criterias

Planning requires a lot of time, all elements need to be controlled and tested

Scales poorly, hard to extend

Full creative control

No uncertainty, but needs to be tested for inconsistencies

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

Emergence

An emergent game has general rules and mechanisms that dynamically controls game elements.

Evaluation of player criterias

Intuitive world lets player use external experience, which requires less learning

Creative control to solve problems, higher replayability

Evaluation of developer criterias

High initial effort in planning, building and fine tuning, but high reusability

Easy to scale and extend

Lose creative control, hard to control the flow of the game

High uncertainty, does not always behave as intended and requires lots of testing

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

Scripting vs Emergence

Emergence focuses on what the player wants to do, whereas scripting focuses on what the designer wants the player to do. There are drawbacks with each extreme of designs, which suggest that using a combination is a good approach, and will be used significantly in the (near) future.