Friday 7 November 2008

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.

7 comments:

antony arrigo said...

hello, i have been following your blog for a few months now, but have only now just read all of your posts concerning magic. i would like to suggest a game that fits many of the things you outline in your blog.

maybe you have heard of it. it is a turn based strategy rpg called disgaea. it was originally on the ps2, but has been ported to the psp and ds. it is interesting for many reasons. the first of which is that the maximum level you can reach in the game is lvl 9999. yes, that's right, 9999. i believe that is the highest level cap i have seen for a game, ever.

it is made more interesting in the way that at any time you can choose to 'reincarnate' any character in your party. doing this starts them back at level 1, but also stores the levels you have earned before reincarnating to be used in distributing once you are reborn. you are also able to change that characters class to any of the many classes in the game. and there are 6 tiers to every class, each slightly more powerful than the earlier one, unlocked via reaching a certain level with any other tier.

there is also a simple magic system, that is quite deep once you play more. it features 4 main types, fire, wind, and ice, and star. most enemies you encounter will have 50% resistance to any of the first 3, 50% weakness to one other, and 0% to the last one. then i believe that most enemies have about 90% resistance to star(not too sure on that one). however so do your characters. there are 4 main mages, each specializing in one of the particular elements. then there is a 'prism' mage, specializing in fire, wind and ice. and a galaxy mage, unable to learn any naturally. also when you reincarnate, you have a change of remembering past spells. there are also 5 tiers of spells, each requiring more sp, but significantly more powerful. then there is the area of effect. as you use your spells, you reach higher levels of that spell, allowing you to cause more damage. you also unlock different AoE's for that particular spell. starts of a one square, then a diagonal, 3 in a row, a few others, and then finally a 3x3 square.

there are many other features in this game that are actually talked about in your posts, such as height of the terrain and an interesting feature called 'geopanels'.i can highly recommend at least renting a copy of the Nintendo DS version of the game, if you have one.

Mikolaj said...

You are right on most of what you write about. I"m looking forward for a next installment. Here's a little nitpicking:

> game design is at its heart mathematical and logical,

true

> and so we can attempt to take this vocabulary and define it more formally using symbolic logic.

Generally forget it. You'd have to restrict yourself to a very narrow space of games, but then you are much better off creating a single game with a lot of customizable parameters. Then create another, very different from the first, again with lots of tweakable parameters. Etc. The zoo is too big.

> With a formal model for game design, we can potentially prove that a game can be completed

You are much better off proving it about a single game. Prove that for a range of parameter values the game is winnable, for another particular range it's not and with some luck you may even exclude the middle, where you can't prove either way.

> (unless we fall within the bounds of the Halting Problem)

The undecidability of the halting problem talks only about _automatic_ proofs. What you talk about above is human-made proofs for particular games/game formalizations/parameter ranges. Humans may cope or fail, but it has nothing to do with the halting problem.

And if you contemplate a system, which fed game rules automatically decides if the game is winnable, forget it, again. :)

Andrew Doull said...

> And if you contemplate a system, which fed game rules automatically decides if the game is winnable, forget it, again. :)

That's what Mark J Nelson is doing, AFAICT. Given a formalisation of a game, he's using an AI planner to determine if it is winnable.

Mark said...

Thanks for the mention! That's the goal, yeah. Obviously there are a lot of hard mathematical/logic problems in doing this; we're going for a system that answers enough questions about enough game-design problems to be useful. It's not going to be some sort of formal-verification system where you implement your whole game inside of a system that makes your game provably correct, because past some point the overhead of writing your game in such a way gets higher than the benefit. The hope is that when you're prototyping the design of the game's rules, you aren't yet past that point. :-)

Even then it's easy to write intractable questions: the rules of chess are about a page, and nearly any nontrivial question about chess is impossible to answer with current computational power. But my feeling is that a lot of game-design questions aren't nearly as hard as answering "what's the optimal play for white on move 3 given this board position?" In fact game designers often work out examples manually, in their heads or with paper prototypes and so on---so the goal is to automate a lot of that type of working out implications of rules.

Mikolaj said...

Well, I probably just don't believe in AI. Outside of games, of course. :)

Anyway, good luck. I look forward to reading about your exploits.

Andrew Doull said...

Mark: I was imagining more along the lines of a procedural Zelda-like. e.g. given the following game abilities, what order can we place puzzles in the world to allow the player to overcome the puzzles without requiring an ability which they have not yet been given the opportunity to acquire.

And ideally: given the following abilities, procedurally design a puzzle that requires they be used.

The first question is a 'straight forward' formal verification process - the second question requires more understanding of how people solve problems and may be intractable.

Neither of which has the complexity of chess... I think.

Andrew Doull said...

Antony: I've got a DS, and have been meaning to buy Disgaea for some time... its on the list of things to do. Thanks for the reminder, of course.