Whenever we design anything, we usually start from the goal and work our way backwards. Our goal for these AI players is absolutely not for them to try to win - that would actually be quite easy, as you say. If we wanted the AI to win, it would always play optimally and, if we wanted, could cheat via inhuman reactions, frame-perfect inputs, utilize CPU-only knowledge, never take a shot that could miss, never make an execution mistake, and so on. However, this is not fun or engaging for players by any stretch. Most players would not want to play against such AI. Our goal is to make AI that players want to play against. That means our goal is for our AI to lose convincingly, much like how parents feign weakness or ignorance while playing with their children.

How do we do that? Well, we can consider the kind of mistakes we expect human players to make and expand on those. Players often overestimate their own resources and overextend. Perhaps the AI spends everything it has immediately and keeps nothing in reserve, leaving itself open after exhausting all of its resources. Players can also play too cautiously, keeping too much in reserve and only spending the absolute minimum. We could make an AI greedy to stockpile resources but only use them when they're near full. Players often tunnel vision on one target and forget to tend other tasks they need to do. We can make an AI do that as well.

These design choices would make the AI players feel more like human players to play against by embracing human foibles as their own driving directives. Similarly, such directives also give the AI weaknesses that a player can observe and exploit to win. If you take a step back, you're looking at the basis for all of game design. We want the players to have a specific experience (e.g. a match that feels like playing another human player rather than an AI), so we figure out what it would take for the player to have that experience, and we construct those bits to convince the player it is happening.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

In-game economies are entirely different beasts than real-world economies for one major reason - total currency is not zero-sum. In the real world, it is (mostly) zero-sum - individuals cannot create money out of nothing, so any amount of currency I spend is transferred to someone else and the total amount of currency in the system is preserved. No individual can buy real gold bars infinitely, they'll run out of money to buy the bars eventually and the price of the gold bars will increase as the cheaper sellers are bought out and remaining sellers raise prices. At the ultimate end, there is only so much gold on the planet, which means that even an individual with effectively-infinite money has an upper limit on the total amount of gold she can buy.

In most games, a player character can typically sell as many wombat testicles to the NPC vendor as she might have, creating new currency out of thin air for each testicle sold. There is no limit to the number of wombat testicles she can sell and there is no limit to the amount of currency the NPC can generate for her. Similarly, any currency spent on NPC vendor goods or services (e.g. training costs, equipment repair costs, resurrection costs, consumable costs, etc.) is completely removed from the system. This is called a "faucet to sink" design. The NPCs that generate currency are the "faucet" from which the money comes, and the NPCs that remove currency in exchange for goods and services are the "sink" in which the currency is removed from the system. When the faucet and the sink are generating/removing roughly the equivalent amount of currency from/to the system, the system is in balance. When the faucet outproduces the sink, more players have an ever-increasing amount of currency which is inflation - too much currency chasing too few goods. When the faucet underproduces the sink, we have deflation (which is much rarer) - too little currency chasing too many goods.

In order to reduce in-game inflation, the solution should be fairly obvious - the designers introduce new "sink" options to remove additional currency from the system. This usually takes the form of new consumables, gear options, or benefits from NPC vendors that cost a lot of currency to utilize. Since players will want these new benefits, they'll start spending more currency instead of hoarding and inflation will fall.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Sure. The way to enforce the feeling that a faction is a real thing is that all units from that faction should feel like there's a common theme among them. I suggest that you establish a "faction ability" (or a pool of faction abilities) that all units from the same faction will share in addition to their "class" ability. This way you can create a handful of abilities that can be reused across many enemies and tie everything together at the same time.

Faction abilities should showcase what that faction "feels" like, both from a narrative sense and a gameplay sense. Starcraft, for example, had all Zerg units regenerate, all Protoss have a combination of shields and health, and Terrans have a mix of organic (healable) units and mechanical (repairable) units. Each faction's abilities in Starcraft helps reinforce what they are and how they work. Your faction abilities should be similar. Your Corp foes should have abilities that make evoke the feeling of Corp representatives. Your Cops should feel like cops, and your gangs should feel like gangs.

To do this, think about what makes a Corp and try to capture that in gameplay mechanics. Maybe the Corp units are ignored by Cops unless they directly harm the cops because they have legal immunity. Maybe they have better stats in general, because they have better gear than cops or gangsters. Whatever qualities they have, as Corporate representatives they should have commonalities that players should consider when engaging with them. When players start a fight with Corp enemies, they should have a good idea about what they should expect from Corp enemies.

A lot of work needs to go into differentiating the members of each faction - what is common to those enemies and how fighting them feels different from fighting enemies from other factions. Also, consider how the factions will interact with each other too - the way the factions behave and act will set the stage for how the game world works. The mechanics you create should, when the enemies engage with each other, play out in a way that makes sense within the world. Your game mechanics should help reinforce the narrative and the narrative should help reinforce the mechanics. This establishes a stronger, more cohesive world and experience to the player.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The big problem with manual saves is that players can potentially save in a situation where the game is in an unwinnable state (e.g. save before the player is about to die). For players who like to overwrite their own saves instead of rotating save files, this can result in a really bad feeling and hours of lost progress. One major guiding principle in game design is "make it easy to do things right and hard to do things wrong". It's a lot easier to ensure the saved game is in a good state under controlled situations, such as with established save points and automatic saves. Since then, we've reallowed manual saves with attached conditions so that players have a harder time saving in a broken state, but the reasons for the progression should be fairly clear.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

There's a lot of small details and choices that combine together to make a world feel big. Each small thing isn't enough to do it on its own, but with enough details working together the player will feel that sense of "bigness". Most of these details are rules and expectations that humans have subconsciously internalized, things that we don't necessarily think about but have taken as true.

The most common detail of "bigness" is visible size. Most areas in video games are already built larger than they would be for a real person of that size. Having buildings that are scaled larger than normal in video games contributes to a sense of grandeur. The SWTOR Jedi Temple on Tython, for example, is apparently built for giants. There's no way that normal-sized humanoids could live or operate comfortably in a space that large, but the purpose isn't a real living space, it's to convey a sense of enormity and grandeur to the players who enter that space.

The amount of time it takes to navigate the area also contributes to the sense of how large a place is. If you think about traveling in real life, the metric of travel time is the most commonly used to determine how far away something is. This means that making travel time take longer actually makes something feel bigger, because our brains tell us "the longer it takes to get there means the further away it is", even if it isn't actually that far away. Look at how long it takes the player to approach the Colossus in this animation. It makes the colossus feel so much bigger because it takes so much longer to reach it.

We also often use tricks like forced perspective in certain places in order to make things feel bigger. If we have unreachable areas (e.g. cliffsides, mountain faces, etc.) that are still visible, we can use visual tricks to fool our brains into thinking things are further away or larger than they actually are. Without a reference point that can break the illusion, our minds will fill in the gaps by constructing its own consistent world view - that castle looks this big, so it must be this far away. The illusion above is only broken because we know roughly how tall a human is, so either the humans are giant or the buildings are tiny.

These various tricks (plus others that I haven't talked about) work to stitch a cohesive experience together in the player's mind. Your brain is being shown many things that have all subconsciously meant "big" to it before, so it assumes that its internal rules are still correct and the thing is big.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Most of the time, we start by setting a target time we think the game experience should take for a first-time player to feel what we want them to feel, and then add about 50% to that. A long fight should feel like a protracted fight and the time limit should reflect that. A short fight should feel like a sudden burst with a lot of pressure to finish it quickly. After we set our estimate, we playtest it to see how it feels. If we don't like it or we were off in our estimations, we adjust, playtest, and repeat. We can also ratchet that time limit up or down for various difficulty levels or challenges/achievements.

If we have to do this a lot of times, then yeah - we usually come up with a formula to generate it for us so encounters and similar timed events stay consistent and reasonable, and then tweak the important ones as needed. Consistency is really important for establishing player expectations, so having things become familiar and (to some extent) predictable helps players feel comfortable.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

The way we balance expected player level to power level is... We create a math formula. Levels are mostly arbitrary discrete markers of player power. Conceptually, they exist to provide a reference point for players to understand how strong things are relative to each other. Their very presence establishes that all combat encounters in the game will happen in one of five bands:

We start by establishing what kind of player experience we want these main types of combat encounters to feel like. How long should each of these encounters be? How many mistakes should we allow a player to make (e.g. getting hit) before getting killed in this kind of encounter? How long should enemies be expected to live? How many enemies at a time should the player be expected to deal with? How many enemies should there be before the player actually feels threatened? For the much higher level foe, we need to decide whether we want players to be able to defeat them at all. We need to figure out where the exact line is between a challenging-but-beatable Higher Level Foe and an impossible-to-beat Much Higher Level Foe.

Once we know what we want those experiences to feel like, we work our way backwards to define the variables we can modify for combat - damage, health, attack speed, defense, movement speed, and so on. We use these variables to construct a general combat formula that will satisfy all of our desired encounter band experiences for any set of input levels for player and foe. We use math to model how we want combat to go. The graph of the player's overall power against their level is called a "power curve".

Once we've established our formula, we can fill in the 'expected' stats for a bad guy of a given level. We will do similar passes for equipment, weapons, items, abilities, and so on and so forth. There should be a mathematical formula for the power of each thing so that we can always have a baseline expected experience. We can then fine-tune the individual attributes of any of these things if we want them to be weaker or stronger.

So yeah - system and combat designers are really a bunch of nerds who have to figure out how to turn cool imaginary combat into a bunch of math equations.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Here's the thing - most people who play Monopoly don't understand how to win at Monopoly. Most players play not to lose, which results in the most standard result - a game that goes on way too long and players get bored. It helps to look at Monopoly as a collection of systems focused around looking at the management of resources.

Let's consider the way a player loses at Monopoly - they completely run out of money and resources and go bankrupt. Think about where the money enters the system, and where the money leaves the system. New money enters the system only through a handful of methods - the money you start with, the $200 you get from passing Go, and the occasional chance or community chest card. Money leaves the system when players buy properties and improve properties by building houses or hotels. Occasionally, there will also be money leaving the system through chance and community chest cards, or paying to get out of jail. Money doesn't enter or leave the system when a player pays another player - it only circulates.

Removing money from the system forces players closer to bankruptcy overall. Adding money to the system makes it easier for players to survive overall. What happens if you have a pot of money on Free Parking? Well, it depends on the source of the money. If the pot comes from the bank, it introduces new money into the system and makes the game last longer. If the pot comes from other players, it keeps money within the system for longer. Neither helps end the game quicker, which should be one of the design goals.

I think that the main issue is that Free Parking isn't compelling to land on for gameplay purposes. Landing there feels bad, so making it a money pot makes it feel better. If our goal is to make it more interesting, I would suggest something that would either be more neutral, or even remove money from the system. I think that Monopoly would do better if there were more ways for players to interact with each other. Instead of calling it Free Parking, I might rename it as the Court House, where a player landing there can pay some fee (e.g. $25) to the bank to sue another player and compel the defendant to hand over some amount of money, e.g. $100, or a higher fee ($100) to take another player’s property. This way we remove a little money from the system whenever players land on it, as well as encourage interaction between players. The two important goals are to incentivize players landing on it and remove money from circulation to push all of the players to the endgame.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Breaking Down Testing Chamber 16, part 3: Visual Language

This is the third part in a series breaking down the level design of one of Portal’s more famous levels, Testing Chamber 16. Here are the previous posts in the series: [Part 1] [Part 2]

One major goal of any game is establishing and maintaining a cohesive visual language with the rest of the game so that players can understand the gameplay constraints of the space they inhabit at a glance. Languages are comprised of terms (things) and grammar (the rules that govern the things) and visual languages are no different. Whenever we show a player something gameplay related, there should be a clear understanding of what the thing is and what it does when interacted with. Here are some examples of terms from Super Mario Bros: 

Each of these types of blocks are visual terms, abide by specific rules when you interact with them, and exhibit different behaviors when interacted with. For example, in the case of the second (multi-brick) block, here are the rules associated:

One way Portal does this is through the clearly displayed wall materials. Within the world of Portal, metallic/dark grey tile walls and floor do not allow portals to be placed on them. Light grey concrete allows portals. Like so:

Similarly, Portal’s visual language draws a clear distinction between the objects placed within the space and the rest of the world, which is comprised of the walls, ceilings, and floors:

The rules up to this point have taught the player that the objects can move (or be moved) and can be affected by the player in various ways. The player cannot place portals on objects, only on certain elements in the geometry. The player can pick up (certain) objects and move them about the level. Movable objects share certain qualities - they stay where they are placed and they are often used to solve puzzles. 

As you can see, there are often a lot of rules (the grammar) associated with these visual language terms that must all be taught to the player so that the player can interact with these terms appropriately when they are presented. Let’s get into how Testing Chamber 16 introduces the player to a new visual language term and its associated grammar - the Turret:

Observe how clearly the grammar rules are implied by the first turret’s placement. The targeting laser beam is clearly visible on the dark background, the shadow cast beneath its spindly legs indicate it is probably an object the player can pick up. The player can immediately grasp the major visually important elements of the turret just by where it is placed and what it looks like when observed. A large, bulky turret would give a different visual impression than a small, spindly turret for example:

It would certainly look a lot more imposing, but would also likely cause some cognitive dissonance trying to lift something so enormous up.

Upon picking the turret up, it responds by wiggling and looking around:

Once it is dropped, it fires its guns for long enough to teach the player that these weird little things are potentially dangerous: 

And then it deactivates, going inert and no longer dangerous:

In this very first encounter with the turret, the player has learned these associated rules:

Most people who have any understanding of modern guns will immediately associate the laser beam with the gunfire and assume it is a targeting laser. For those who aren’t sure, the immediate next step is to prove out that case:

This adds most of the in-game rules the player needs to know regarding how turrets behave in game. From here on out, placing a turret brings all associated rules to the player without further need of explanation. If you observe the rest of the level, you can see that most of the gameplay is there to teach the player more nuanced rules regarding the turrets (e.g. the deactivation of the turret is tied to knocking it over).

The most important thing when establishing a visual language is consistency. When we establish visual language terms with the player, it encourages them to hypothesize “reasonable” connections based on the rules involved. When their hypotheses prove correct, it reinforces the visual language’s grammar and makes the world feel more coherent. If their hypotheses prove wrong, players usually both learn something about how the game rules and experience a bit of cognitive dissonance from the incongruity in how they thought the rules worked and the way the rules actually work. 

Building and maintaining this sense of coherence is extremely important for a good player experience! If design breaks the rules they’ve established too often, it breaks player immersion and can cause a lot of frustration. Take a look at this environment from Uncharted 4:

There’s a very clearly established visual language at work here to broadcast the environment’s traversible areas to the player at a glance. If there are environments where the traversible areas are hard to differentiate, the player can get confused and frustrated. The easiest example of this is with jump distances, especially in platformer games. 

One of the biggest visual language terms in games like this is the maximum distance a player can jump. If the gap is significantly longer than the maximum jump distance, the player can understand that this is not a traversible path (yet). If the gap is visibly shorter than the jump distance, the player can make the jump. But if the gap is just a little bit further than the jump distance, it’s unclear and the only way to tell is by the frustrating process of trial and error:

To recap, our takeaways from today’s post on breaking down Testing Chamber 16 are:

When next you play through Portal, observe how the visual language terms like the turrets are both established and then subsequently used. Whenever a new language term is introduced, note what the level design does to teach you how the rules work. Then, in subsequent encounters with those terms, see what they assume you already know and what else they expand on with those terms.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Design Principles: Crafting Interesting Choices, part 1

Recently, a follower on twitter asked me a question that I thought would make for a good post. Specifically, it was about how to go about making interesting cards for a cooperative deck building game. I want to expand on that because I thought that it would make for a good central design concept post - what does it mean for a player to make a choice that is interesting? As a designer, how do I provide interesting choices to the player? Choices become interesting when they generate some tension in the player. This comes from two fundamental elements: 1.) no clear “best” answer and 2.) established stakes that aren’t trivial. 

An Interesting Choice shouldn’t have just one answer

A choice is a situation where a player must decide between two or more mutually exclusive options. A choice is not interesting where the better option is obvious. If you are choosing between spending one mana and dealing two damage or dealing three damage to any target in a vacuum, the choice is obvious. Even if it involves some amount of calculation, if those calculations are the same, the choice isn’t interesting. It’s a math problem and it gets solved. A solved choice is not interesting by definition, because there’s a right answer and a wrong answer. The choice is no longer interesting once you know what the answer is. Memorization isn’t interesting.

An interesting choice is one where things aren’t always known. Conditions that are not always fulfilled (e.g. flame punch deals high damage than laser fist normally, but laser fist deals extra damage to burning enemies) lead to interesting choices. Controlled randomization of outcome (e.g. this move has a higher chance to critically hit than that one) can be interesting. Choosing a character can be interesting if the characters are reasonably balanced. 

An Interesting Choice needs stakes

If a choice doesn’t cost the chooser anything, it isn’t interesting because the stakes are too low. When you have tens of thousands of gold coins, deciding whether to buy a potion for single-digit gold cost isn’t really interesting. If the player isn’t aware of the stakes of the decision, the choice won’t be interesting. When you want the choice to be interesting, the player must be aware of what the stakes are for the choice - choosing this option means this big event happens, which means that other big event won’t happen. If the results from the choice are significant to the game, the story, or the character, we must convey this to the players in order for them to understand full weight of the choice that is being made. 

This isn’t limited to a game’s story though - think about the factors involved in making the decision to use your character’s Ultimate in Overwatch or League of Legends. The stakes are important - using it right can often swing the game in a drastic way. Using it wrong and you’ve wasted a long cooldown for little appreciable gain. Deciding when to use your ult in a close game is much more interesting than deciding when to use it in a curbstomp game because the stakes are higher.

Not all Choices must be Interesting

It’s important to recognize that not all choices must be interesting. Making a choice requires the decisionmaker to expend mental energy. Think back to when you spent a lot of time thinking about hard problems all day and just felt utterly exhausted afterward. Expending too much mental energy leads to mental fatigue. Too many Interesting Choices can cause that to happen to our players if we’re not careful. Interesting Choices are good at raising the tension level of the current gameplay experience and not good when players are already riding high on the [tension curve] and the choices push them over the edge into feeling stressed out. When you’re designing the gameplay experience, consider where these choices are offered and what the expected tension level should be.

These two elements are the core of what makes choices interesting. I’ll soon post part 2, where we can examine some details in the implementation - different ways we can adjust the answers and stakes of some example choices to make them more or less interesting. In the meantime, try looking at the various choices you are offered in games. You should start seeing how they break down - what the stakes are, what the answers they offer are, etc. Consider which choices you found interesting. Can you see the options and the stakes? What about for those that weren’t interesting?

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?