Monthly Archives: September 2016

A Succession Of Progression Mechanisms

When a game is truly engaging for players, they are experiencing what Hungarian psychologist Mihayli Csikszentmihalyi, Distinguished Professor of Psychology and Management at Claremont Graduate University, described as “flow” in his seminal work, Flow: The Psychology of Optimal Experience. Flow is that mental state in which players are fully immersed in a feeling of energized focus, full involvement, and enjoyment of a game. As any player of Civilization can tell you, when players experience flow, time stops, nothing else matters, and when they finally stop, they have no concept of how long they have been playing the game.

Two critical factors identified by Professor Csikszentmihalyi that lead to that desired state of flow are clearly stated game goals and constant, immediate feedback about whether or not the players’ actions are successful as they strive to meet this goal.  “Progression” is the term that game designers use to describe how players’ actions advance them toward successfully achieving a game’s goals, and providing feedback to players about their progression is essential for fully engaging them in the game they are playing.

Arguably the most common form of feedback used to measure and communicate player progression is a score: numerical points awarded to a player for successfully performing actions or completing game objectives.  Often, achieving a high score is the ultimate goal of the game itself.

A graphical representation of a score is a progress bar.  Progress bars are used when a score mechanism has a defined maximum score. Typically, progress bars use a linear function, such that the advancement of a progress bar is directly proportional to the amount of progress that has been completed to that maximum number.

Another common implementation of progression used by game designers is the use of checkpoints, predetermined locations, intervals, or sets of challenges such as missions or quests used as intermediate goals.   The playing boundary of many games are segmented into “boss battles” (especially difficult obstacles) or discrete levels to use as checkpoints for measuring and communicating player progress.  Even the player’s advancement towards a checkpoint, particularly if the path or sequence required to reach it is relatively linear, is a form of progress.

Many games provide multiple forms of feedback to players about their progression.  Role-playing games, for example, will augment a relatively continuous scoring mechanism (usually called “experience points”) with a leveling system, which is a type of checkpoint that recognizes a number of successfully performed actions.  In such games, players may be awarded experience points for successfully killing monsters or finding treasure, and after having had a number of such experiences, they “level up”.  Like other forms of checkpoints, levels are used by game designers to determine when the player is sufficiently skilled to deal with a more difficult set of challenges.

Another form of progression feedback is the use of achievements: badges, titles, or even resources awarded to the player for successfully completing game objectives.  Achievements are useful for recognizing player’s who successfully complete a series of actions that are tangential to the game’s main progression path.

Whatever form of progression you use, it is essential to provide players with a constant sense of progression.  If there is any point in your game where the players don’t know what the game’s goals are, or whether or not they are advancing toward those goals, you run the risk of them deciding to progress on to play another game.

When Assembly Language Turned Into Assembly Lines

When I first started my career in game development, programming was much simpler than it is today, and I was able to develop my games in BASIC (Beginner’s All-Purpose Symbolic Instruction Code), with certain functions such as graphics and AI pathfinding done in assembly language.  Games in general were much simpler than today’s games, and I was able to do the game design, art (such as it was) and sounds all by myself.

However, over time, games became larger and larger in scope, and more people were needed to develop a game.  The lone developer was replaced by a two- or three-person team, which gave way to a half-dozen member team, which in turn evolved into a twenty, then fifty, and eventually a hundred-person team.  Now a major AAA game title might involve over a thousand people, sometimes with several studios and art houses working together.

The production values of games also evolved, and so-called “programmer art” could no longer cut it.  Therefore, development teams needed artists who knew how to draw, animators who knew how to animated, writers who knew how to write, and audio engineers who knew how to compose music and create sound effects.

Even these disciplines gave way to sub-disciplines on large-scale projects.  The design department might be comprised of a lead designer who oversees system designers, content designers, user interface designers, level designers and writers. The programming department might be lead by a technical director who supervises the engine, physics, artificial intelligence, user interface, audio, multiplayer, and tool programmers.  The art director in charge of the art department manages concept artists, texture artists, 3D modelers, riggers, animators, and environmental artists.  The sound department might have different professionals specializing in music, sound effects and voice over.  Each of these developers need to have their tasks scheduled and coordinated so that everyone works together as a team, and so that responsibility would fall to a producer or director, often assisted by a project coordinator and/or production assistant.

Each of the game’s thousands of assets, whether they be character animations, game levels, or cut scenes, might involve many different developers as the asset goes through conceptualization, design, production and implementation into a team.  Creation of these assets involve an assembly-line kind of process, called a pipeline, and an individual developer might spend his or her time on the game just doing one step in this process, over and over again.

Many people who aspire to work on AAA games imagine themselves as having complete creative control over the entire game, but that’s not how major games are made nowadays.  If you want to work in the game industry, you need to be able to take satisfaction in simply contributing to the game, even if your role is confined to creating the textures for all the rocks, tweaking all the attributes of the items for sale, or programming in the buttons for all the menus.  You will likely be part of an assembly line, and your source of pride needs to be in the entire team’s collective work on the game.