Designing a Magic System - Part Thirteen (Digression)

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven and twelve).

So what is the appropriate mechanism for character progression? While I've argued previously that magic systems should use a class based progression system, this doesn't necessarily imply that only a single choice at the start of play should define what abilities the player has, and what order additional abilities are acquired in.

I'm going to develop here a terminology similar to the game design patterns I've already described to explore the progression options open to a game designer. Although I'm defining the patterns by name (highlighted in bold), I'm skipping the detailed methodology here for brevity. I've also not considered the 'Problem' part of the game design patterns in any detail. This is because it's not clear necessarily what the problem each progression type addresses, and, as I've discussed in part twelve, character progress is sometimes a solution in search of a problem.

There are two parts to character progression, that are interrelated but which can be considered separately.

The first is ability choice: that is what restrictions are placed on the choices the player makes to acquiring the possible abilities during the game. At one extreme is linear progression, where the player gains abilities in a fixed order throughout the game. The other extreme is no progression, where the player starts with all abilities that they can possibly have, and does not progress further. Careful consideration highlights a third extreme: where the player can acquire abilities in any order without restriction - I'll refer to this as open progression. Open progression sounds like skills, but is subtly different; with skills, there is still the potential for scalar progression for each skill, and some abilities may be unlocked with sufficiently high skill levels.

Skills are closer to open progression than talent trees (also called technology trees): with skills, the player may invest points in any skill at any time, but with a talent tree, some abilities are only accessible after investment has been made in other abilities. Abilities in talent trees can be restricted in a variety of different ways: such as through having one or more prerequisites that the player must have one, some or all of; having exclusions which prevent other skills from being learned; or requiring a minimum number of points from a pooled list, where existing abilities contribute one or more points towards the total required (this is one possible generalisation of prerequisites). Skills may be arranged in a talent tree like structure: the key differentiator is the frequency of choice, where talents indicate less frequent decisions be made as to which ability to acquire or progress, and skills indicate more frequent decisions (to the point of choosing where each skill point is invested). Talent trees are from a design point strongly related to technology trees, but technology trees require further investment to 'express' the ability - by developing an item, a unit or otherwise investing resource in an in-game element of play. And a variety of matrix development models, seen frequently in Japanese RPGs, represent the character progression in a two or three dimensional board, or a mini-game environment.

Slots are a mechanism for restricting open progression: the player may freely fill slots with abilities without regard for other abilities they have acquired. Sockets are like slots, except that the each item fits in a particular socket type, of which the player has one or more of (think of the restriction of the number of rings, amulets, armour etc. that can be worn). Slots and sockets can be restricted by encumbrance, which places further restrictions on the total number of abilities that can be carried by imposing some kind of numeric limit, and containers, which restrict equipment based on the equipment shape, requiring that the player fit together different shaped items in a number of virtual two-dimensional grids. Containers and sockets are usually represented by a paper doll system, which is a two or three dimensional model representing where slots or sockets can be filled. More complex three dimensional models allow abilities to be selected using a more complex design and modelling software.

Class progression limits the character progression by forcing the player to make a (potentially uninformed) decision at the start of play, which impacts on the overall abilities available. It is also possible to mix and match these progression types. For instance, class progression may then determine that the player gains some abilities through linear progression, and others through one or more talent trees or skills. And the majority of RPGs have a slot/socket/encumberance system for individuals.

The emphasis so far has been on single avatar games, but many games feature multiple avatars per player, each of which has it's individual character progression system. Multiple avatars may be controlled directly, or through a party system, where the player is forced to recruit additional avatars without necessarily having direct control of their starting abilities (or even advancement choices). Finally indirect control is typical for units, which are separate avatars which typically have fixed abilities, but require the character progress, typically through a technology tree type, in order to be able to recruit and control more powerful units.

The second mechanism is ability acquirement: that is how does the player acquire abilities as they progress.

The three axis of acquirement are currency, which supports complete interchangeability of accrued acquisition between abilities, various item systems, where abilities are acquired separately and not interchangeable, and achievement systems, which track acquisition of each ability separately. I'm not going to exhaustively list game design patterns of acquisition here, but note that the concept of drawing cards from a deck into a hand falls within this scope.

There are a number of important design issues around the ability acquirement mechanics. I've already highlighted that problem with acquirement grind, caused by allowing small improvements at low difficulty levels accumulate to large improvements. This is a big problem with currency systems, but can also affect some achievement systems where an achievement is gained through the result of accumulating a large number of individual actions. This can even occur with items, when the ability choice system does not sufficiently restrict the number of a particular item that can be acquired. Even ammunition can be unbalancing in this regard.

Another issue is the fallacy of point equivalence. This is the incorrect assumption that two abilities are equally useful (or the scalar improvement of two abilities are equally useful). In reality, a well-designed game will almost always have one ability to be more useful than another at any point in time (otherwise, why are the abilities any different at all). Allowing the points, or currency, accumulated towards acquiring or improving one ability to be transferred across to another ability will mean that the player will almost always favour one ability and disregard the other.

This suggests that a currency system will encourage grinding and discourage acquiring unusual abilities. A currency system is still important for developing an in-game economy, making them suited more to multiplayer games where a real economy can develop, as opposed to single player games which can only support the simulation of an economy and not the real thing. If you do intend to have currency in a single player game, you are strongly urged to read 'Designing a Single Player Economy', and play Freshly Picked: Tingle's Rosy Rupeeland for further inspiration.

Defining types of character progression in games seems an academic exercise, and one I'll probably pursue further in a different format. For the moment, this is intended as a checklist and inspiration for the various ways you can design character progression in a game.

But it is important to define the language of games further, and game design patterns offer a systematic method of doing so. We are still in the infancy of game design: although the forms are becoming more regular, we still don't have a common vocabulary to define game design the way we talk about the technical language of film. We need the game design equivalent for the terms long shot, pan and zoom. But more than that: game design is at its heart mathematical and logical, and so we can attempt to take this vocabulary and define it more formally using symbolic logic.

With a formal model for game design, we can potentially prove that a game can be completed (unless we fall within the bounds of the Halting Problem), and vary the rules to explore the game space. We could design games algorithmically, or the spaces within games using procedural generation based on the formal rules of the game expressed as an expert system. If this concept intrigues you, I recommend reading Mark J Nelson's work on automated support for game design. I can only sketch the briefest of concepts here, but a fuller treatment would be the subject of more post-graduate work.

Back on track in part fourteen.