The aesthetics of gameplay: a lexical approach

The aesthetics of gameplay: a lexical approach
Zagal and Tomuro
MindTrek'10

See the PDF or the ACM page.

Primary Elements of Gameplay Aesthetics

Aesthetics cluster	Words in cluster	Description
Pacing	fast, stressful, dull, tedious	The perception of how often game events occur.
Scope	endless, vast, immense, minimal	The size of the possibility space afforded by a game.
Complexity	simple, short, complex, uncomplicated	The measure, or sense, of the number of parts in a system and how they are interrelated.
Demands	hardcore, experienced, retro, demanding	The requirements imposed upon the player by the gameplay
Cognitive Accessibility	deep, unusual, twisted, intricate,	The measure, or sense, of the opacity of a system and the challenges it poses in understanding it.
Impact	addictive, boring, overwhelming, visceral	What we feel games “do to us” when we play them, and how they make us feel.

• Analyzed nearly 400k user reviews posted before April 2009 on gamespot.com. 8k games covered by reviews from 112k users.
• 40% of user reviews contain the word gameplay
• Method: Stanford Parser to perform part-of-speech tagging. Matrix of (723 adjectives total that precede and modify the word gameplay) x (5000 most frequent words that occur before or after the adjective, ie context words, ie words that give a context to the adjective). Cells of the matrix contain number of occurrence of an adjective with a context word. Run kmeans on the matrix to obtain k=30 adjective clusters. (Compared to k=10 or 20, k=30 generated better-looking clusters). Two adjectives are similar (and put in the same cluster) if their context word distributions are similar. Then, give a name to each cluster based on the adjectives it contains.
• Only 2 clusters about narrative elements. Therefore, players have no difficulties separating the formal or mechanical aspects (game mechanics) from their narrative interpretations (representation).
• AI does not emerge as a cluster. Possible reasons: no language to describe game AI, or games AI are not sophisticated enough, or a too recently marketed topic to feature in reviews.
• Genre does not emerge as a cluster.
• Limitations: Gamespot population = 95% males, lots of colloquial words disappeared in cleaning phases.

My remarks

• A group like "fast FPS gameplay" may have been considered as "fast gameplay" because FPS is not an English adjective, and the Stanford parser only looks at English adjectives. Since genre adjectives are not English but rather specific of gamer communities (e.g. "FPS", "RTS", "JRPG", etc.), genre did not appear in clusters.
• It'd be interesting to know which game names occurred most often next to gameplay. For instance, "gameplay like Civilization" may be quite rare, but very meaningful when talking about a niche genre.
• If genre is a label of the dataset, then it could be interesting to cluster a matrix like adjectives x genre. Goal = see which adjectives are explaining most a genre.

MVC for games

Second thoughts on MVC (following a first article about the use of MVC by game developers). Let's assume that the user inputs are first caught by a controller, and a view is displayed to the user at the end. What are the communication possibilities in-between?

Vanilla MVC

As seen on Wikipedia, the theoretical 'vanilla' MVC refers to an architecture where the controller updates the model, then notifies the view, which in turn fetches the data to display from the model.

Application for games: the system is event-based: it is only awakened by the actions of the user. If the world has NPCs, they can not act independently of the user. It may be OK for turn-based games like Chess, but not so much for games with living worlds like Morrowind or Harvest Moon.

Web MVC

In web development, the "logic" is often split into multiple controllers. To determine which controller the user's action is targeted to, web frameworks such as ASP.NET or Spring use a front controller pattern. The front controller maps URLs to actions to execute (and which controllers to call). I'm not entirely sure, but compared to the vanilla MVC, it seems that the (front) controller is now giving the model to the view, instead of having the view fetching the model by itself. Therefore, the model to be displayed is carried from M to C, and from C to V, twice more data going around than in vanilla MVC (where it used to be moved only from M to V).

In games, the model can get quite large, and moving it around can get costly. It would not be so costly if only resulting differences to the model (instead of the whole model) were exchanged, but it depends on the modernity of the rendering. Alpha compositing makes it possible to render variations of the game state (ie the model) by layering image elements. Many games/game frameworks such as pygame still use bit blitting, which requires to erase and reprint the whole screen.

Game MVC

This nice article about MVC for games explains:

• The controller handles the input and flow of the game logic. This is akin to the states your game can be in. My primary two controllers are main menu controller and an in-game controller. They are responsible for converting input into something the game world (model) can understand. Eg "Create unit x at base y".
• The model handles all game logic. It has nothing to do with input, rendering or networking. It is a pure view into the game world. Designers need only worry about what’s in the model.
• The view DOES know about the model. The [view] has read-only access to the model. This model can be anything. For my main menu it’s a list of UI controls the controller has built. For the in game view, it’s the game world. Rather than "reusing views in different controllers" what is more important is "having multiple views on a single controller". For example there might be a 2D and a 3D view of the game world.

What is still missing from the picture is the game loop. In games, the model is rendered by the view 60 times per second, and the inputs of the user are processed at the same frequency. As mentioned in the quotes above, some component, be it a controller or something else, still has to determine which view should be active at any given frame, and which controller it is associated with.

Links

• Organizing the game code to fit MVC (Stack Overflow)
• Is MVC used in commercial games? (Stack Overflow)
• MVC in game dev (TIG source)
• Design patterns for games from Zach Simpson's 1998 GDC talk

Fundamentals of Game Design, ch 15: RPG

Inventory can be:

• a grid where player can position items in empty cells, like in Diablo 1 or 2
• one ore more simple list(s) of items, with an eventually limited number of slots, like Pokemon's backpack
• items have weight, and the inventory is limited to a certain weight, like in Baldur's Gate

Functional character attributes = characterization attributes (stats: DEX, STR, INT, ... skills that change unfrequently, a class system pushes players to specialize) + status attributes (XP, different classes can have different amount of XP required per level (e.g. Baldur's Gate), but players should know it when they pick their character).

Instead of having levels giving sudden bonus, we could have no levels and stats would increase directly proportionally to the XP. After all, levels harm immersion. However, levels add achievement goals and let players spend regularly newly-acquired points in skills they choose.

Skills

Spells can cost mana/SP, or they could just disappear from caster's memory until she sleeps (a la Baldur's Gate/DnD). Unpracticed skills could gradually decline in efficiency, while frequently used skills could get "mastery" bonuses (like for WoW's crafting skills). Or the opposite: frequently used skills could eventually wear out of power.

Skills can be learned right away when levelling up, or when a skill point is spent in them, or the skill could be obtained from an NPC ("training" with masters), or from other players/NPC by watching them do the skill (e.g. the creature in Black and White learns spells after they have been performed a few times in front of it).

If a character has 10% chance to unlock a door independently of the previous tries, then the player will try until the lock eventually opens. Then the 10% chance only slows down and annoys the player. Instead, the better at unlocking doors the character is, the faster the door will be opened. If the lock is too complicated for the character's unlocking skills, then the door unlocking progression bar simply does not increase.

Stories and quests

If the overall story is "save the world", then give meaningful reasons why the character would be ready to do side-quests like delivery boy. Good example: helping a hermit to find his lost dog because the collar hides a key to an important door that the player needs to take. Bad example: helping a hermit simply to get XP, or just to help him out by pure generosity (but really, players are not solving NPC problems by pure generosity).

Anyway, stop writing stories about saving the world.

Fundamentals of Game Design, ch 14: Strategy Games

Strategy = planning series of actions against the opponent(s). There's usually a large variety of potential actions. Analysis paralysis happens when players have to wait for the other to be done thinking about his next move. In RTS, decisions have to be taken quickly. The basic mechanics of strategy games involve units and the factories that produce them. There can be diplomacy if the scenario is long enough. The attributes of units can be: (max) health, (max) armor, atk, ammo, aspd, area of effect, range, and others ...

Melee unit's value (eg footman) = max HP * shot power * aspd * accuracy * range * walk speed
Ranged static unit's value (eg tower) = max HP * shot power * aspd * accuracy * range^2/2. Squared because the area defended increases quadratically. Halved because units can generally only cover one side/half, the one side towards the enemy.

Most RTS make little use of line of sight and terrain realism; a unit on top of a hill could see further, a unit behind a hill could be hidden from those behind it, units have atk/def/... bonus when they are in their favorite terrain.

Gold is too important for war for mines to be spread out randomly. Spreading randomly means randomly-chosen players get a random advantage from the start, which is unfair. Mines randomly spread also means that players will hunt for mines instead of fighting strategically against each other. Large mines should be positioned symmetrically if they are decisive. Random mines should be smaller and not be decisive for winning.

Lanchester's laws: 1- In melee combat, army strength is proportional to number of units because each fighter can engage only one enemy at once. 2- In ranged combat, units can concentrate their power on a single enemy. When 1 unit is attacked by 3 archers, its life decreases 3 times faster, and it can only attack one of them, ie 1/3 of the enemies. Therefore, 3 ranged units are 3*3=9 times stronger than a single unit (whether ranged or not).

Imagine the tight and strong negative feedback loop: "wounded units attack weaker". Then players have to play sub-efficiently all the time, and they're going to wage attrition skirmishes, not big epic battles.

Do not block or forbid certain units or skills in a particular level. Instead, make the level so that this unit or skill is very inappropriate. Ex: to prevent the player to use air units, give the opponent lots of anti-air missiles. To prevent the use of iron, set the victory condition to "collect lots of iron".

Upgrades

Upgrades can apply to a single unit (veteran units have +1 dmg), all units of a particular kind (grunts get +2 atk), all units of all kinds (Iron Age = +2 def to everyone), or even the whole mechanics (production speed divided by 2). Upgrades can be unlocked by spending resources, time, achievement, ... The tech tree can be:

• totally open: player spends point in any tree she wants, like in WoW
• constrained: finish one branch to start another
• fixed: once player starts in a tree, only this tree is available for the rest of the game

Production and distribution

Production process should be concrete and visible, while the distribution process should be abstracted. Ex: plant farms for food = concrete food production. No supply lines as long as there are roads = abstract supply distribution. There are different shades and techniques for supply lines: troop caravans between cities in Heroes of Might and Magic IV, trade caravans between cities in Civilization series or Age of Empires, or Armored Personnel Carrier that transports troops and fuel in Advance Wars. Another approach is to have cities within a zone of influence to be supplied: cf the influence zone mechanics of Populous (you can only build in your area of influence), Civilization, and Black and White (you can only exert your god powers within your zone of influence).

AI techniques

• Game tree search, as used in games where there is a finite number of possible moves, such as Chess or Checkers. Problem: the search space increases exponentially, which is a problem for games like Go which have too many possible moves.
• Neural networks: patterns are identified after repeated exposure. Problem: training takes time, the system can hardly be tweaked, and adding new patterns means re-training the whole system.
• FSM: units transition from one state (walking) to another (shooting) because of events (enemy appeared in sight). Problem: the unit can only be in one state at once.
• Hierarchical FSM: FSM of the commander gives orders such as "take this hill" to captains. Captains have an FSM that gives orders to soldiers in the squad, such as "cover fire" or "make diversion". Each soldier has its own FSM as well: "if I see an enemy, run for cover". hFSM can create emergent behavior.