CoD-MW3-Transmission
Basic Introduction to Game Design

Game System Dynamics

[cite]
Welcome to the fourth week of class in the course: Basic Introduction to Game Design. Thanks for com­ing over from GameCareerGuide if you read my guest post there. Make sure to read the syl­labus and course infor­ma­tion before you con­tin­ue. Today, we are going to dis­cuss sys­tem dynam­ics in games. This text fol­lows close­ly from our text­books (Game Design Workshop, Chapter 5, Challenges for Game Designers, Chapter 2, and Salen and Zimmerman Rules of Play chap­ters 13,14,16,17,18). In pre­vi­ous lec­tures, we have dis­cussed the util­i­ty of rules. As game design­ers, we use rules to deter­mine the actions play­ers can take and the out­come of those actions. In dig­i­tal games, the game log­ic often pro­vides parts of the rules of your game. The audio­vi­su­al man­i­fes­ta­tion of your game (even the sto­ry of your game) is how­ev­er not con­sid­ered a com­po­nent of the for­mal ele­ments of games. When audio­vi­su­al ele­ments influ­ence the for­mal struc­ture of your game, this should be con­sid­ered as a fac­tor of your game rules. Salen and Zimmerman dis­tin­guish between con­sti­t­u­a­tive rules and oper­a­tional rules as well as implic­it rules.

  • Constituative rules are all about a game’s inter­nal events. They are the main log­ic behind your game. In a dig­i­tal game, these are con­tained direct­ly in the code of your game.
  • Operational rules are all the rules need­ed to run the game (not just the con­sti­t­u­a­tive or inter­nal events) includ­ing all exter­nal events relat­ed to your game, such as input and out­put of the game, the way that you express choice in your game and how out­comes are defined for play­ers.
  • Implicit rules are the unstat­ed assump­tions of a game (often sim­i­lar to a player’s hon­our code, but also relat­ing to the nature of the com­put­ing plat­form that your game runs on). Implicit rules often relate to the con­tex­tu­al sit­u­a­tion of a game that we are tak­ing for grant­ed. However, this con­tex­tu­al sit­u­a­tion can be played with, to exper­i­ment with inno­va­tions in game design.

Games as Systems

Minion Camps in League of Legends

The min­ion camps in League of Legends (Riot Games, 2009) are impor­tant ele­ments of the game sys­tem.

As we have dis­cussed in class before, a good way to under­stand games is to break them down into sys­tems. Systems them­selves are defined as a set of ele­ments that inter­act with one anoth­er to form an inte­grat­ed whole. A sys­tem has a bound­ary and sur­round­ing ele­ments. We already see that this def­i­n­i­tion comes close to our under­stand­ing of games as a mag­ic cir­cle with a bound­ary that delin­eates it from the out­side world. To cre­ate bet­ter sys­tems, we need to under­stand basic sys­tem prin­ci­ples, such as inter­ac­tion qual­i­ty, sys­tem growth and the change of the sys­tem over time. When a sys­tem is set in motion, the ele­ments of the sys­tem will inter­act to pro­duce a com­mon goal. The ele­ments of a sys­tem guide its inter­ac­tion qual­i­ty. Similarly, in games, the for­mal (and dra­mat­ic) ele­ments that we have dis­cussed before will cre­ate a com­plex and dynam­ic play­er expe­ri­ence when set in motion. Before look­ing at how sys­tems react when set in motion, it is impor­tant to under­stand their basic ele­ments. Several fac­tors of these ele­ments deter­mine how the sys­tem will behave when set in motion.

However, there is even more to sys­tems as they are dis­tin­guished by their fea­tures that all influ­ence the state of a sys­tem:

  • Objects or ele­ments, which are defined by all of the below items
    • Structure or prop­er­ties
    • Behaviours
    • Relationships
In Nidhogg, the game system has simple objects and a simple goal, but allows for complex behaviours.

In Nidhogg (Messhof, 2014), the game sys­tem has sim­ple objects and a sim­ple goal, but allows for com­plex behav­iours with sim­ple inter­ac­tions.

Objects

Objects are the basic build­ing blocks of a sys­tem. Systems have pieces that relate to one anoth­er and these pieces are the objects or ele­ments of the sys­tem. They can be:

  • Physical. For exam­ple: game pieces, the squares on a grid board, the lines on a sports field, the play­ers them­selves.
  • Abstract. For exam­ple: In-game con­cepts.
  • Both. For exam­ple: Player rep­re­sen­ta­tions that can be both abstract and phys­i­cal.
Settlers of Catan

Settlers of Catan (Klaus Teuber, 1995) board game. Flickr Image CC by Alexandre Duret-Lutz.

In Settlers of Catan, you have many dif­fer­ent game objects. The objects in Settlers of Catan are the play­er and rob­ber pawns, roads and settlements/village pieces, cards for devel­op­ment or resources, spe­cial points (largest army, longest road), ter­rain tiles with resources, ter­rain num­bers and dice. All these objects in the board game make up the game sys­tem. They all have prop­er­ties, behav­iours and rela­tion­ships. If any of the objects were miss­ing, the game would not pro­ceed as designed. For exam­ple, if there were no set­tle­ment pieces or roads, the play­ers could not indi­cate that they have built some­thing. If the resource tiles were miss­ing, play would be mean­ing­less, because it would not be clear how new resources would be gath­ered or which play­er would earn a spe­cif­ic resource. Without a dice, the chance ele­ment of the game would be miss­ing and the game would change com­plete­ly (although the dice ele­ment could be replaced with a skill-based play­er chal­lenge).

Torchlight Game Objects

Torchlight (Runic Games, 2009) game objects in the vil­lage and prop­er­ties relat­ing to the play­er are always vis­i­ble in the dig­i­tal game user inter­face.

Properties

The below exam­ple shows us how some Settlers of Catan objects (e.g., a road, a knight, a set­tle­ment and the city expan­sion) has some costs attached to it. This is a very easy-to-under­stand exam­ple of how game prop­er­ty val­ues work. For exam­ple, a road costs 1 wood and 1 brick. Not only are these the cost val­ues of the road object, but they already estab­lish the rela­tion­ship (anoth­er sys­tem fea­ture) between roads and resources, such as wood and brick.

138/365 ~ Struggles for Catan

Cards dis­play prop­er­ties of game objects in Settlers of Catan. Flickr Image CC by Ray Bouknight.

Object forms are defined by attrib­ut­es that are either phys­i­cal or con­cep­tu­al in nature (see above). Properties are the sets of val­ues that define the nature of game objects. For exam­ple, in role-play­ing games, char­ac­ters (and items) can have val­ues, such as strength, vital­i­ty or expe­ri­ence lev­el. The audio­vi­su­al media rep­re­sen­ta­tion of a game object is also con­sid­ered a prop­er­ty val­ue (e.g., the sprites or the art­work asso­ci­at­ed with the game object). The prop­er­ties of a game ele­ment form a data block that is able to describe the inter­ac­tions that are pos­si­ble with a game object in the game sys­tem. The more com­plex an object is in a game sys­tem, the less pre­dictable the inter­ac­tions with this game object become.

Borderlands Properties

In Borderlands (Gearbox Software, 2009), weapons are game objects that have defin­ing prop­er­ties (e.g., Damage, Accuracy, Fire Rate, Price) as shown above.

In the above exam­ple, we can see how a game object — in this case a weapon in Borderlands —  is defined by its attrib­ut­es or prop­er­ties. Imagine if you had to put this “gun” object into a data­base, you would need to spec­i­fy all these prop­er­ties. For exam­ple: a name, what type of weapon it is, what make, dam­age, accu­ra­cy, fire rate, enhance­ments, clip size, mon­ey val­ue, an image or visu­al mod­el rep­re­sent­ing it. You can see how impor­tant it is to think about all the details of your game objects when you are design­ing a game. You will lat­er spend a lot of time tweak­ing and bal­anc­ing these val­ues. Many game design­ers pre­fer to have these val­ues saved in a spread­sheet (or — some­times — data­base soft­ware) to be able to cal­cu­late the changes of val­ues on in-game inter­ac­tions. Especially, in-game com­bat relies heav­i­ly on how prop­er­ties cre­ate dif­fer­ent rela­tion­ships in your game sys­tems (e.g., prop­er­ties deter­mine how effec­tive units are in com­bat). Damage cal­cu­la­tions often involve rules relat­ing to game object prop­er­ties as well as chance.

Behaviours

We can see behav­iours most com­mon­ly in arti­fi­cial intel­li­gence (AI) scripts exe­cut­ed for non-play­er char­ac­ters (NPCs) in games. However, behav­iours can also be seen on cards in the above exam­ple of Settlers of Catan (e.g., the set­tle­ment card instructs play­ers: “When you build this set­tle­ment, you may flip over the des­tiny card.”). Behaviours refer to the poten­tial actions that game objects could per­form dur­ing a giv­en game state.

Freedom Force Fleeing Behaviour

An ene­my flees after being over­pow­ered in Freedom Force (Irrational Games, 2002).

The more actions are pos­si­ble for a game object, the less pre­dictable the behav­iour of the game object. The con­sti­t­u­a­tive rules of our games inform what behav­iours are pos­si­ble in a game, but the oper­a­tional rules can still influ­ence behav­iours, often lead­ing to emer­gent game­play dynam­ics. One thing to keep in mind regard­ing behav­iour com­plex­i­ty is that more game­play com­plex­i­ty does not always equal more fun of play­ing.

Relationships

Having rela­tion­ships among one anoth­er is one of the defin­ing char­ac­ter­is­tics of ele­ments in a sys­tem. If we have a ran­dom set of objects with prop­er­ties and behav­iours that do not relate to one anoth­er, we have a col­lec­tion, but not a sys­tem. In games, rela­tion­ships are easy to express. For exam­ple, by defin­ing the loca­tion of objects on a game board or num­ber­ing the cards in a card game. Relationships can con­sist of fixed, lin­ear rela­tions, loose object rela­tion­ships, or rela­tion­ships, which can change dur­ing game­play. The num­ber hier­ar­chy of a card set deter­mines a log­i­cal rela­tion­ship between the cards in a deck. The def­i­n­i­tion of the rela­tion­ships of sys­tem ele­ments is large­ly respon­si­ble for the dynam­ic expe­ri­ence that occurs when a sys­tem is set in motion. Some objects might only have loose rela­tion­ships with oth­er objects in a sys­tem that are trig­gered when an object is close to them or when a game ele­ment is set to a spe­cif­ic state. One of the most inter­est­ing aspects of rela­tion­ships is that they can change based on play­er choice (as deter­mined by the oper­a­tional rules of the game) or through chance-based events.

Mechanics, Dynamics, Aesthetics

In a GDC 2011 talk, Clint Hocking asked the ques­tion of how games cre­ate mean­ing for play­ers and answered the ques­tion by explain­ing that games cre­ate mean­ing through their dynam­ics. He relates this idea back to a work­shop paper from Hunicke, LeBlanc and Zubek titled MDA: A Formal Approach to Game Design and Game Research (PDF). The paper was one of the first attempts to for­mal­ize game design and has since been adopt­ed by many game design­ers. It defines a game sys­tem as con­sist­ing of:

  • Mechanics. This refers to spe­cif­ic game com­po­nents at the core lev­el (i.e., the lev­el of data rep­re­sen­ta­tion or algo­rithms or rules).
  • Dynamics. This is the putting in motion of the mechan­ics, the run-time behav­iour of the mechan­ics when the play­er inter­acts with the game. It is also val­ue-chang­ing loop of inputs and out­puts of play­er and game sys­tem over time.
  • Aesthetics. This refers to the expe­ri­ence of the play­er, their desired emo­tion­al response when they per­ceive the look and feel of the game sys­tem and inter­act with it.

Clint Hocking re-appro­pri­ates MDA as RBF to make his (and many oth­er game design­ers’) inter­pret­ed mean­ing of this the­o­ret­i­cal struc­ture a bit clear­er:

  • Rules. Mechanics are equiv­a­lent to the rules of a game.
  • Behaviours. Dynamics are run-time behav­iours of the game-play­er sys­tem.
  • Feelings. Aesthetics are the feel­ings that the game evokes in the play­er.

The talk then dis­cuss­es an exam­ple of MDA put into action as dis­cussed by Stephen Lavelle in the game Spelunky.

We can exam­ine MDA put into action by look­ing at the whip weapon in Spelunky. The mechan­ic of the weapon is that it has an ani­ma­tion attached to it that rais­es the whip before its use, it also means that the hit box of the whip goes behind and above the play­er char­ac­ter. This is the whip mechan­ic.

Spelunky Whip Dynamic

In Spelunky (Derek Yu, 2009), the whip has to be raised before it hits, which allows attack­ing ene­mies behind you.

The dynam­ic of the whip is that it is a slow­er weapon that makes it hard­er to attack fly­ing ene­mies. However, if delib­er­ate­ly used, the whip can be dead­ly as it hits ene­mies above you.

Spelunky Whip Dynamics and Bat

Similar to the exam­ple above, the whip can also attack ene­mies above you because of the rais­ing dynam­ic.

The result­ing atmos­phere and expe­ri­ence of delib­er­a­tion is that Spelunky feels a bit smarter than shoot ’em up games. This refers to the feel­ings that the play­er has when play­ing the game. The ques­tion that Hocking asks in his talk is whether the mean­ing (and the feel­ing of of pre­med­i­ta­tive delib­er­a­tion in Spelunky) comes from the rules gov­ern­ing the whip or from how the play­er uses the whip. The trou­ble of under­stand­ing how dynam­ics work comes from try­ing to under­stand what exact­ly play means as a verb. Play can be used out­side of a gam­ing con­text as a verb, too, for exam­ple when play­ing music. Is play just the act of per­form­ing on data (e.g., the notes on a sheet of music or the rules in a game) or does it give deep­er mean­ing exact­ly by how you per­form this as an indi­vid­ual? The feel­ing and appre­ci­a­tion of the data that a play­er per­forms on is what ends up cre­at­ing the expe­ri­ence for them­selves (and poten­tial­ly oth­ers). Hocking thinks that game design­ers can empha­size either author-dri­ven games, where most of the mean­ing comes from the mechan­ics and not much inter­pre­ta­tion is allowed for the play­er (Spec Ops: The Line comes to mind again) or play­er-dri­ven games where design­ers abdi­cate author­ship as much as pos­si­ble to their play­ers. In the video below, you can see an inter­est­ing exam­ple of how an extreme­ly rare reward (remem­ber that val­ue is tied to scarci­ty) in a game like World of Warcraft can influ­ence play­er expe­ri­ence (make sure to lis­ten to the sound in the video).

Complexity of Systems

Complexity is not just a mat­ter of a sys­tem hav­ing lots of parts, which are relat­ed to one anoth­er in non­sim­ple ways.” (Jeremy Campbell)

Game sys­tems are pos­si­bil­i­ty spaces (e.g., the pos­si­bil­i­ty space of Tic Tac Toe can be mod­eled as a tree struc­ture). The options that you chose deter­mine the dynam­ics of the sys­tem when it falls into place. Complexity of a sys­tem becomes an impor­tant fac­tor in the dynam­ics of a sys­tem. Christopher Langton (as men­tioned in Chapter 14 of our Rules of Play text­book) under­stands the com­plex­i­ty of sys­tems at four lev­els:

  • Fixed sys­tems do not change. The rela­tion­ships of the ele­ments in the sys­tem remain the same (like a black TV screen).
  • Periodic sys­tems repeat the same pat­terns over and over again. If you had a mes­sag­ing sys­tem, where a sin­gle mes­sen­ger just runs back and forth between two fac­tions, you have a peri­od­ic sys­tem.
  • Chaotic sys­tems have ele­ments that are con­stant­ly chang­ing, but are ran­dom in their object states and rela­tion­ships.
  • Complex sys­tems, final­ly, are not ran­dom and dynam­ic in their ele­ment rela­tion­ships, but they are more com­plex and less pre­dictable than peri­od­ic sys­tems.

Emergence is above all a prod­uct of cou­pled, con­text-depen­dent inter­ac­tions.” (John Holland)

Complex sys­tems are quite rare and often depend on a lot of con­di­tions work­ing in tan­dem to cre­ate the com­plex­i­ty. Simple rule sets can often lead to com­plex game­play expe­ri­ences. When sys­tems gen­er­ate com­plex and unpre­dictable behav­iour pat­terns based on sim­ple rules, we call this emer­gence.

Game of Life R Pentomino

In Conway’s Game of Life, these are sev­er­al gen­er­a­tions of the R Pentomino con­fig­u­ra­tion.

A good exam­ple of emer­gence is Conway’s game of life, which fol­lows a very sim­ple rule set on a cell grid:

  1. Cell birth. A cell becomes alive in the next gen­er­a­tion (next round or phase or step in the algo­rithm) if three of the neigh­bour­ing cells are alive.
  2. Cell death by lone­li­ness. A cell is dead in the next gen­er­a­tion if it has less than two alive sur­round­ing cells.
  3. Cell death by over­pop­u­la­tion. A cell is dead in the next gen­er­a­tion if it is cur­rent­ly sur­round­ed by more than four alive cells.
Game of Life glider

A glid­er.

The glid­er is a walk­ing vari­ant of the game of life rules.

Emergent sys­tems pro­vide an inter­est­ing com­plex­i­ty for game design­ers as sim­ple rules can often lead to beau­ti­ful and com­plex game­play sce­nar­ios. On the oth­er hand, these sys­tems can be very hard to bal­ance.

Economic System Examples

We cre­ate val­ue in games by mak­ing game objects either scarce or mak­ing them real­ly use­ful for play­ers (prin­ci­ples of scarci­ty and util­i­ty). Some games also allow us to exchange resources among our­selves (between play­ers) and with the game sys­tem. Allowing sim­ple trades in games forms the basic econ­o­my of most games. Often the trades are lim­it­ed and the econ­o­my in a game is con­trolled and does not resem­ble any real-life econ­o­my. To cre­ate a basic econ­o­my, you should allow the exchange through:

  • Items. These are the objects being trad­ed. Often they are game resources and oth­er col­lectible things in games for which you can barter.
  • Resources. These are the enti­ties con­duct­ing the trades. Often they are play­ers or some form of a bank or a game auc­tion house.
  • Methods. These are the oppor­tu­ni­ties for trad­ing. These can be in-game mar­kets, for exam­ple.
Borderlands Values

Values of game objects in Borderlands. Created through util­i­ty and scarci­ty.

To facil­i­tate trad­ing, economies can use cur­ren­cies. The prices of objects depend on the mar­ket con­trols that game design­ers put into place (e.g., things can be free, fixed price or con­trolled by the mar­ket). Similarly, trade oppor­tu­ni­ties in games can be reg­u­lat­ed or allow com­plete free­dom of trade.

Bartering

Bartering sys­tems in games can be sim­ple or com­plex. A sim­ple exam­ple of bar­ter­ing is the game Pit, where the goal is to cor­ner the mar­ket. The num­ber of cards in the game is fixed. This pro­vides a sta­ble amount of prod­uct for the eco­nom­ic sys­tem. The val­ues on the cards also do not change. All trades hap­pen­ing in the game must be for equal num­bers of cards, which essen­tial­ly means that the val­ue objects in the eco­nom­ic sys­tem have a fixed price. These mar­ket reg­u­la­tions in the game mean that eco­nom­ic growth in the game is not pos­si­ble. A more com­plex bar­ter­ing sys­tem exam­ple is Settlers of Catan (again). Here, the val­ues of resources fluc­tu­ate depend­ing on how much of a resource is pro­duced (which is tied to the ran­dom­ness of the dice and the assign­ment of num­bers to resource tiles at the begin­ning of the game). This also changes the total amount of resources (i.e., the prod­uct) avail­able in the econ­o­my. While the 4:1 trad­ing sys­tem (with the game bank) serves as infla­tion con­trol, the high like­li­hood of a sev­en (accord­ing to a nor­mal dis­tri­b­u­tion) being rolled with the dice pun­ish­es play­ers hold­ing too many resource cards on hand. Any play­er with more than sev­en cards will have to return half their hand to the bank.

Markets

Monopoly

Monopoly (Parker Brothers, 1933) show­cas­es an exam­ple of a sim­ple mar­ket using game cur­ren­cy.

Market sys­tems employ cur­ren­cies for their trades. This makes them more com­plex than bar­ter­ing sys­tems. A sim­ple mar­ket exam­ple is the board game Monopoly, where the num­ber of real estate avail­able in the game is finite, but the prices for the real estate fluc­tu­ate sig­nif­i­cant­ly based on play­er goals. Players start with a fixed amount of mon­ey, but have a steady income by pass­ing Go (the start­ing square) every round. There is also no cap on avail­able mon­ey from the bank. The inter­est­ing aspect of the mar­ket is how the val­ue of real estate prop­er­ties are deter­mined. First, a play­er may pur­chase the prop­er­ty at the title deed, but if they decline to pur­chase at that point, the prop­er­ty goes up for an auc­tion among the remain­ing play­ers. The mar­ket val­ue here is deter­mined by play­er goals and by the com­pe­ti­tion aris­ing from already pur­chased prop­er­ties (since there are sig­nif­i­cant ben­e­fits to hav­ing prop­er­ties of the same colour).

More com­plex mar­ket exam­ples can be found in MMORPG auc­tion hous­es and vir­tu­al economies. Players start out with lit­tle resources and will have to put time into gath­er­ing vir­tu­al resources (a process that also relates to gath­er­ing expe­ri­ence and is called grind­ing) with­in those economies. Trading is pos­si­ble between play­ers and with the game sys­tem (in shops). Supply and demand influ­ence the mar­ket val­ues in this econ­o­my. See also the above video about vir­tu­al infla­tion.

System Feedback

Feedback loops are impor­tant parts of the game sys­tem. They can help you to bal­ance your game sys­tem or make it more com­pet­i­tive. For exam­ple, if you have a game sys­tem, where when­ev­er a play­er scores a point, they get a reward like an extra turn, then you are rein­forc­ing the pos­i­tive effects of your reward and cre­ate an advan­tage for that play­er. This pro­motes diver­gence in the game. Good peo­ple will become bet­ter much faster. This is called a pos­i­tive feed­back loop and it can be used to accel­er­ate game­play, because play­ers are able to move faster toward their goal and it makes it hard­er for oth­er play­ers not doing so well to catch up. Depending on whether your game depends on a scor­ing eval­u­a­tion, this loop can lead to the endgame quick­ly. Player-sys­tem rela­tion­ships are rein­forced by a pos­i­tive feed­back loop.

On the oth­er hand, neg­a­tive feed­back loops exist to pro­mote cohe­sion among play­ers. Imagine an exam­ple, where every time you score a point in a game you have to pass your turn to anoth­er play­er. This sys­tem would favour peo­ple not scor­ing as many points as you and sub­tract from your advan­tage gained by scor­ing a point. Negative is not equiv­a­lent with bad here, but it relates to the idea of sub­tract­ing some­thing. Your vari­able gain is turned into a loss. The blue shell (see video below) in Mario Kart games is a very well-known item that facil­i­tates a neg­a­tive feed­back loop. In gen­er­al, in Mario Kart, many high­er pow­er items only become avail­able to you when you are behind in the race and if you use them well, they can help you bal­ance out the game and catch up to the oth­er play­ers. In board games or turn-based dig­i­tal games it can also be used to bal­ance out the first move advan­tage (see oth­er video below). Player-sys­tem rela­tion­ships are bal­anced out by a neg­a­tive feed­back loop.

Homework Assignment

  1. Creating a great pitch: Write a one-page pitch doc­u­ment for your GDW game. What makes your game stand out from the crowd (your unique sell­ing point)? Why is it still rel­e­vant to a big audi­ence? What new things does it offer? Structure like the fol­low­ing:
    • High con­cept para­graph, your hook or mem­o­rable main state­ment (Ideally starts with just one sen­tence, for exam­ple, Brain Training: “Improve the Age of your Brain in just 10 min­utes a day”)
    • Three (3) Key fea­tures bul­let points, pick the strongest points
    • What’s your busi­ness case? Which pub­lish­er would you pitch this to? (The pub­lish­er will ask: Do you have an audi­ence? Will your team deliv­er? Does your pro­pos­al work with the type of game you are pitch­ing? Does it fit in a publisher’s port­fo­lio? Will I make mon­ey? Do I want to give you mon­ey for this?)
    • Summarize all this infor­ma­tion neat­ly (and be pre­pared to pre-empt pos­si­ble lim­i­ta­tions of your game)
  2. Present this doc­u­ment to the rest of the class in the tuto­r­i­al (present it as a one-minute ele­va­tor pitch, you should be able to pitch your game in 30 sec­onds lat­er on). You can use slides for this, but they must be sim­ple and bold. This pitch is as much about sell­ing your­self and your team as it is about the game idea that you have.

Further Reading

Am I miss­ing some­thing? Write a com­ment to this post at the very bot­tom of the page.

  1. Make a bet­ter game — Limit the play­er and The More You Know. Both by Jon Shafer (2012).
  2. Excellent sys­tem review of Shadowrun 5th Edition by Stephen Cheney (2013).
  3. Textbooks as men­tioned at the start of the arti­cle.
  4. Rules vs. Mechanics. Raph Koster’s blog­post (2011).
  5. Mechanics and Dynamics. Ian Schreiber (2009).
  6. Former stu­dent blog from Valerie about games as sys­tems run­ning through an exam­ple of Settlers of Catan.
  7. Watch the GDC talk from James Everett of Ubisoft on Modernizing Splinter Cell’s Gunplay. Lots of infor­ma­tion on bal­anc­ing a game­play sys­tem.
  8. Watch the GDC talk from Clint Hocking on Dynamics: The State of the Art. A fan­tas­tic overview.
  9. The SCVNGR game dynam­ics list.
  10. Ernest Adams on Positive Feedback in the Designer’s Notebook.

Further Viewing

 

 

Standard

One thought on “Game System Dynamics

  1. Pingback: Animal Crossing – Create. build. game.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.