#breaking down problems

A context-sensitive action is an action that can only occur under a specific conditions. In order to allow them to be used, we need to detect that those conditions have been met. If all conditions are satisfied, we can offer the player the option of performing the action.

Imagine we're trying to add a fairly common context-sensitive action - vaulting over a waist-high wall and landing on our feet on the other side - to our game. In order to do this, we need a vaulting-into-landing animation and a way to detect a vaultable waist-high wall. What kind of conditions would need to be met in order to allow the player to vault over the wall? Here are some conditions that I think we would need to meet:

We cannot vault over a wall and land on ground that is a different height than what we started from or the animation won’t work (clip through the floor or land on thin air)

We can only vault over a waist-high wall that is exactly waist-height so that the animation does not clip through or float above the top of the wall

We cannot play the landing animation if there isn't enough ground on the other side of the wall for our feet to land on (no vaulting over a cliff or into another piece of geometry)

We cannot vault over the wall if the wall isn't thick enough for our character model to place hands on it as part of the vault

We may have to adjust the character model's position and orientation in order to ensure the correct approach angle and starting location

We shouldn't move the player too far or it will look really weird, so we need to restrict the player to certain facing angles and distances

This list of requirements sets specific limits of where in our levels we can place these vaultable walls. We can't put them in places where these conditions cannot be met, which means that we need a certain amount of clearance and open space around each vaultable wall. This effectively standardizes contextual actions within the level environment - the level designer can only place vaultable walls in areas that meet these conditions. This kind of constraint exists for all contextual actions - wall running must be at least this length and cover this much area and the player must approach from this angle, climbing a ledge must be at least this tall and have at least this much flat space on top to stand up after ascending, computer keyboards must be this height and this angle in order for the animations to line up, chairs must be a standardized height to match player sitting animations, all stair steps must be the same height in order for the player model's foot not to clip through them, and so on and so forth. If you carefully observe games like Uncharted and Tomb Raider while playing, you'll start seeing the standardization in terms of size, spacing, approach angle, etc. of many of their contextual actions.

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

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Today we'll act as system designers and break down your question into a set of smaller questions that are easier to answer. First, let me establish this as the premise - a MMOG service is like an all-you-can-eat buffet that's open 24 hours a day, 365 days a year (minus server maintenance times). The expectation from players is that they will be able to log on to the game at any time of day, and play without having to wait for too long.

We can break down the sort of gameplay engagement from players into two buckets for this - solo gameplay and gameplay that requires other players. For solo gameplay, we're good - the game service automates all of the NPC spawning and loot table rolling for us, so all of the solo content should be fine on its own. For content dependent on other players, we need to consider the ways in which players can interact with each other within the scope of the MMOG's gameplay systems. These activities can include things like:

Player to Player Trade (direct trade, auction house, etc.)

PVP Group content (e.g. Battlegrounds)

PVE Group content (e.g. Dungeons and Raids)

Zone/Faction PVP participation

PVE World Events

We can break further break these down into two smaller buckets - real time community needs and asynchronous community needs. 

If a player logs in during their preferred play time and can't find other players to run a dungeon with or finds the PVP zone to be empty in real time, they aren't going to have fun. This is the "real time community needs" bucket - a player needs other players right now to play with. To keep these systems from feeling frustrating, we need enough players engaging with these gameplay systems such that the wait time is not too high (i.e. usually < 5 minutes or so). We can usually mitigate the frustration by allowing players to engage with other game content while waiting for their queue to pop, populating empty slots with bots for queues that take too long, and so on. 

Similarly, if a player logs in and the auction house is empty or the faction-wide quest hasn't advanced enough since last week, the player isn't having fun. This is the "asynchronous community needs" bucket - a player needs other players to have engaged with the game within the past N hours/days/etc. and not immediately. For these systems, we have a much longer time frame where we just need to make sure enough players over a period of hours/days/weeks/etc. will engage with the system to keep players from feeling frustrated. This can also be supplemented by generating content for players (e.g. having a bot auto-sell items on the auction house if there aren’t enough of those items to buy).

Usually, this means we want around at minimum of around 10 x (number of players per group) players seeking real time group content at any given time in order to do the matchmaking within a reasonable time frame. This also doesn’t include further subdivisions among the player base (e.g. waiting for a tank to queue, or how level 20 players and level 100 players probably aren’t going to be seeking the same group content). For asynchronous content needs, you need enough players to engage over that time frame (usually a few hundred at minimum) to keep things stocked and working. Exact numbers will, of course, vary with factors like player turnover rate, game length, backfilling players who leave games, mitigation features like bots, etc.

PS. If this talk about gameplay time frames reminds you of [primary/secondary/tertiary gameplay loops], you earn a cookie for thinking like a game designer.

[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?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

When we create game systems and content, we’re often translating highly abstract concepts into a set of discrete rules and data values that make the player feel those abstract concepts when encountered in game. Programmers are the people who have the difficult job of translating these abstract concepts into a set of rules that the machine can understand and follow. It is their responsibility to create systems that do the things we designers want quickly and efficiently.

As an example, imagine that we are making a game that has an in-game calendar. Let’s say that one of the major game mechanics is the ability to either go back in time or to replay specific days. How would someone actually create a set of rules basic enough for a machine to follow to enforce the rules for this mechanic? To start with, the programmer needs to establish what a “day” is in terms of game logic. Given the game’s design, the programmer might define a “day” as a container that holds a bunch of occurrences that happened during that specific day - the player completed these missions, which earned these rewards including this much experience and these new items. The player also consumed these items over the course of the day. 

The full game calendar would then be a sequence of days that have occurred with a maximum length for when the game ends. Each previous day in the calendar would then be aggregated to calculate the player’s power and inventory on a specific day. Replaying day six would mean that the player would probably only have access to the items, experience, and party members obtained between days 1-5. Specific days on the calendar must also have certain scripted events, such as holidays on the appropriate day of the month and the final boss appearing on the final day of the game. 

This can, of course, raise a bunch of additional questions. Should the player be able to go back and replay day six while keeping the results of day 7-10? What if there’s an event on day six that unlocks a subsequent event on day nine, which the player did do the first time around, but then replays day six but doesn’t unlock the event that they did on day nine? What kind of ripple effects should be accounted for within the rules of the game? How do we create a set of machine-understandable instructions to adhere to these rules quickly and efficiently? It is questions like these that  are the kind of abstract problems that programmers need to solve. Game programmers write code that provides answers for the machine to the question “... but what if the player does this?”

[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?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Let me unpack this a bit because you’re making an assumption here that should probably be identified before I can answer your question. The assumption here is “the level’s position had to shift because of the scene in question”, and… it really doesn’t. What’s much more likely was that they built some content for E3 hype and liked it enough that they kept it in the final game, even though the progression didn’t quite match up. Let’s dig into it a little bit deeper, I’ll explain.

First off, the various levels in games almost always are built in parallel by separate teams of developers. This means that we can rearrange them however we want - we just change the order of the levels in the build tool and the game will play through them in that order. That can happen late in the development if we feel the need. However, this doesn’t necessarily preserve the flow of the game - a specific level might spawn Marauders as regular enemies, which makes it less likely that we would want to have that level available before the player’s boss fight with the first Marauder. Flow is definitely a consideration that we have to take into account when ordering the levels. But it isn’t carved into stone either, we can set it up such that manipulation of the level order has less impact overall.

Secondly, granting weapons in a game like Doom is done in two parts. There’s the granting of weapons themselves, which is as simple as a single script call (e.g. “grant weapon 5″) that can be done on any level or by placing a weapon pickup in that level. The second part is the narrative and progression element, which is where the designers choose to grant the player the weapon. They find a place in the established progression and narrative where they think it’s a good spot and grant the weapon to the player there. Some games choose to space out the ability granting and others front-load them. Doom Eternal’s team may have started off with more spaced-out progression before E3 and changed their minds later.

Third, the visual aspect of granting the weapon to the player is entirely cosmetic and also modular. All it takes is two specific animations - one for the player and one for the NPC. These animations can actually be played practically anywhere in the game as long as both the player and NPC are standing on flat ground a specific distance from each other. The designers chose the location to play the scene for narrative impact, but it wasn’t mechanically necessary to give the player the gun this way. It was there to build narrative and character and to excite the player. If we wanted to, we could move it to another level, or give the NPC a different gun to grant, or not do it at all. It’s modular - it can slot in just about anywhere it makes sense.

A lot of game development is built in a modular fashion. Most game elements are designed to require as few interdependencies as we can so that developers can work without having to wait on somebody else to finish something first. It’s a good exercise for future developers to try breaking elements of the games they play down as far as they can in order to get a sense of what it takes to build these games and how many people it takes to do so. Smaller elements like grabbing a gun from a terrified NPC can be slotted in where we want them and don’t really have large effects on things like level order. In the trailer’s case, the animation sequence was probably built for E3 hype and the developers left it in the final game because it felt cool.

[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?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

If it’s a physical game with multiple factions, the driving design principle is “each different faction needs to play differently from the others” because there are no fancy graphics or sound to cover up the illusion. If the different factions do not feel sufficiently differentiated from each other, there is no point in their existence - they just add to the list of things a player must remember without any real gain in gameplay. Having different types of play has many benefits - players can find things that suit their particular play styles, players can learn more about the game by playing different factions, it provides a lot more possible depth when players have to think about the different matchups, and it makes creating content a little easier by establishing firm constraints on what a particular faction can and cannot do.

Therein also lies the biggest problem - it’s hard to really differentiate ways to play a game. Even a game as old and storied as Magic runs into this problem - there’s a constant push and pull over what makes an artifact different from an enchantment and many of their set-specific card mechanics are essentially a more limited version of “kicker” with a different name. By having a lot of factions, you have to spread your resources pretty thin across each one in order to build up enough depth to the play style that’s still both easily understandable to new players and unique to the faction. Furthermore, each additional faction increases the number of matchups geometrically. If you have three factions, there are three matchups (AB, AC, BC). For four factions, there are six matchups (AB, AC, AD, BC, BD, CD). Five factions is ten matchups and six factions raises it to fifteen. That’s a lot of balance testing that needs to be done!

One good way of mitigating some of that complexity and overall scope is to have a pool of “common” gameplay elements that all factions can potentially pull from, like artifacts and specialty lands in Magic or the general cards usable in any deck in Hearthstone. If you do this, you need to carefully mind the dividing line - the more general options there are, the more heavy lifting the faction-specific cards need to make the faction feel distinct. If you do this, you must consider the number of elements to create for each faction and the number of common elements.

If you ever want to finish this project, you need to set some hard limits. Think about how many total cards/gameplay elements you have the resources/time to make, and figure out how those will be divided among each faction (and any common elements).Remember, the way the faction feels when played will drive how the players feel about the game. Each faction should have a strong mechanical identity that differentiates it from the others. That could mean a different way to manage resources, a unique way of gaining card or board advantage, or a different way of interacting with other players/factions. If you don’t have enough cards/elements to define the play style of the faction, it won’t feel good to the player. If you don’t have enough cards to establish an early, mid, and late game strategy for each faction, it won’t feel good to the player. Setting scope is super important here. Will 10 cards be enough for a faction? Do you need 20? 50? Figure out what you think the core has to be for that faction and build it out. Then use that as a guideline for creating the other factions.

A faction isn’t really fun if it doesn’t feel sufficiently different from the others. Be wary of the problem of scaling up as you add more factions, rather than adding more options to each faction. Each faction should have roughly the same number of options and resources, so the game’s scope must widen to encompass the total amount of work that must be done for each faction times the number of factions you want to make. Set a hard limit on how many cards/resources/elements each faction gets and then try to make it work within those limits. 

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

I just re-watched [some Youtuber’s] post-mortem of "Evolve", and while he went in depth on why it failed from a business stand point, he didn't really say much about how the gameplay failed. Do you think you can make a list of some of the things that the game did wrong, along with how you might have fixed those problems?

Evolve had developmental issues from a structural perspective. In [the words of Matt Colville], one of the designers on the project, there were several core issues that were never properly addressed during development. These key structural problems made continued development extremely painful, eventually becoming insurmountable.

First, they didn’t allocate their resources very well. They had a team composition that was ideal for developing a game based on exploration, but what they pitched was a game that was based on 4v1 pvp.  They were too focused on building a cool alien world and not on building a solidified vision of gameplay that was fun and sustainable. For the game they pitched, they needed more programmers and designers to create the core gameplay systems and fewer artists building out the world. 

Another element that hurt them very badly was not building a robust system of adding new monsters or hunters to the game, which directly hurt the business model they pitched - regular additions of hunters and monsters. If adding new hunters and monsters to the game is the business plan, it stands to reason they should want to make it easy to create new hunters and monsters. Typically, this would mean a modular design - we can build the abilities and the character art separately and combine them in various ways into one final package, similar to how MOBA or gacha game characters work. Instead, none of their characters used the same mechanics and everything was a one-off. It was incredibly difficult for them to add new heroes and monsters.

They also never solved the problem of designing the game in a way that players would want to play 4v1 cooperatively. When players wanted to play cooperatively, the game was amazing. However, whenever players began playing to win, the game fell apart. The game systems should have been designed in such a way to incentivize cooperative play, rewarding playing the way that was most fun for all players involved. Instead, it was far too easy for players to ruin the gameplay experience for everybody by playing to win.

In addition to this, the gameplay elements often found themselves fighting against the sort of context they brought in. Remember how I mentioned how [sewer levels bring a lot of context] with them because we’re familiar with them? Well, Evolve’s design often actively fought against that included context, which caused lots of cognitive dissonance among players. Colville’s example was a hunter’s debuffing gun. It looked like a sniper rifle, it aimed like a sniper rifle, it animated and felt like a sniper rifle, but it didn’t hurt things like a sniper rifle. Instead, it painted targets on the target for allies to hit and deal more damage. It was a debuffing gun, not a high damage sniper rifle. That just feels bad for a gamer that is expecting a sniper rifle.

Finally, they were only able to update the game once every three months, probably because of client certification issues. That enforced delivery cadence really hurt their ability to react to problems that appeared in the wild. A better way of hosting games and game data on their own servers would have made it significantly easier to roll out server-only updates/hotfixes (e.g. stats for balancing and such) rather than needing a client patch for any change.

Overall, these sort of problems made sustained development for the project incredibly difficult. The game had a lot of potential, but their implementation and allocation of resources was messed up from the beginning. The fact they had to keep building and working around these core problems eventually caused the game to buckle under the combined weight of all of the hacks and workarounds. The overall concept is still sound, but I think their execution in reaching that goal is what failed.

[Join us on Discord]

The FANTa Project is currently on hiatus while I am crunching at work too busy.

[What is the FANTa project?] [Git the FANTa Project]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

It’s FANTa Friday. Today we kick off our design phase, where we’ll go over the level overview for the dungeon. If you remember from the [Concept Phase Review], we are looking to incorporate the following ideas into it:

Verticality

Openness/visibility

Showing places of interest

Encouraging the player to think in terms of up and down

This is a dungeon where power is literally based on height. The higher you go, the more powerful things get. The further down, the lower your status.

Also, this is a winged dungeon. This means that our basic layout will be five total areas:

A staging area (the Mezzanine) to function as a hub to reach the other areas. The key elements here are that multiple floors should be clearly visible from anywhere in this area. Expect spiraling staircases, railings, upper and lower floors, and decorations to indicate where the exits lead. We want to keep the exits to the Mezzanine within the normal field of vision, but not directly at eye level - they must be above or below to really hammer home the verticality.

The area where we obtain our first mechanic, aka the Cellar. This area should convey a feeling of underground, but a little bit different. This is a castle in the sky, which means that there isn’t much underground. Instead, we’re going to have a lot of holes and areas where the player can look down and see the clouds below (and possibly fall to her death). Think lower-class stuff here - servant’s quarters, storage, stonework, etc. This is also an excellent area for platforming.

The area where we obtain our second mechanic, aka the Atrium. Think of it like a botanical garden - it’s curated, but it’s full of greenery. We can expect birds, some wild animals (perhaps escaped from a menagerie) and plants here, but the environment should have a very planned layout.

The area where we obtain our third mechanic, aka the Observatory. Think telescope, lab equipment, and books. Science stuff, paintings, tapestries, bookshelves, and the like.

The area where we fight the boss, aka the Tower. This area will likely be shrouded in mystery, but it will likely have a big hole in the ceiling so the dragon can land and we can fight it.

Right from the start, you should notice that I’m naming each of the separate areas a very distinct name that inspires a specific kind of visual for that area. One of the goals of level design is to make each area visually distinctive in order to instill a sense of place in the player when they see it. One of the most frustrating things a player can go through is getting lost. Similar to how we want characters to have distinct silhouettes, we want level environments to have a distinct visual style. Naming them also helps dispel any confusion in the future when referring to them. I can say “the passage from Atrium to Cellar” and it makes sense to anyone familiar with the layout. If you’re designing a level, you should divide it up into major sections and try naming each one in order to help keep them straight in your mind as well as establishing a common vocabulary with other people and in documents.

You may also have noticed that I’m building the concept of verticality into the design simply by the sort of areas we’re making for each wing. The Cellar implies an underground area. An Atrium is more of a ground floor thing. The Observatory brings expectations of higher elevation, to be closer to the stars. The term Mezzanine refers to a large room with multiple observable levels separated by stairs. This is important - it helps reinforce the theme to the observer as well as the team members. Whatever your level’s theme is, it should be visible throughout your entire level.

I would like to note that this design is looking very ambitious. We may have to cut one (or more) of the areas/mechanics for scope. Five fully designed areas might be too much for one person to handle in a timely fashion. The good news is that any of the three mechanic areas are modular and can be cut. We don’t necessarily need all three. We’ll continue looking at them for now, but it’s just fair warning for those following along - this might be too much to finish. We must keep the mezzanine and the tower, but we could probably cut one (or even two) of the other areas if scope proves to be a problem.

Let’s recap today’s design takeaways: 

Keep your theme central to the different environments you’re planning out. Ask yourself how the theme is being shown in each area. 

Make sure that each planned environment is visually distinct from the rest. Players hate getting lost. 

Name each major section of the environment something short and descriptive to reinforce their distinctiveness. 

Keep an eye on the level scope. Identify early what must be kept and what isn’t necessary but still nice to have.

This week we step into the Design Phase of the FANTa Project!

[What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Sure. When designing a puzzle, a designer must think of the process by which the player interacts with them. Specifically, there are four steps:

The player sees and recognizes the puzzle goal

The player discovers the clues/objects needed to solve the goal

The player associates the relationship of the clues with the puzzle and each other and works out potential solutions

The player solves the puzzle with the proper solution

The designer must make it clear to the player what is happening and what to look for each step of the way. This means that the designer needs to clearly establish context for all four of the elements above. More specifically:

Show the player the goal - a locked door, a treasure chest, an object they want, etc. - but also clearly show that it is not immediately attainable.

Place and advertise the clues to the puzzle goal within the environment. This can be subtle or it can be obvious, depending on whether the puzzle is optional or part of the critical path. 

Provide a way for the player to experiment and learn how the clues interact and behave. This doesn’t have to mean that the player can make attempts until they succeed, but it does mean that they get enough tries with the puzzle to learn the rules.

Create a solution for the puzzle that isn’t too difficult or too easy for the challenge level the designer has chosen.

These are the basic elements that a designer must create in order to make a good puzzle. Missing one of these elements is a recipe for player frustration, and that is something we always want to avoid.

The second layer of designing a puzzle is deciding on the distribution. Puzzles have two primary elements to them - discovering the clues, then using clues to solve some sort of pattern. Some puzzles are 100% clue-finding, such as “find the key to unlock this door”. Some are 100% pattern-solving, such as the Tower of Hanoi. Many are a combination of the two - e.g. the player can play around with this pattern, but is missing a critical piece to finish it.

When designing the pattern, make sure that the pattern is clear and makes sense once all of the pieces are known. If the designer presents a pattern or set of rules to the player for a puzzle, it’s a promise that those rules will be followed. A good puzzle design will let the player make certain assumptions and have a way to test those assumptions. The solution should require some kind of non-obvious, lateral thinking that still satisfies the rules that the designer has set. If the solution breaks the rules or pattern, it will be extremely frustrating to the player.

A good designer will also use multiple solutions to the same puzzle judiciously. Under such circumstances, it’s important to communicate to the player that there are more than one solution and which solution each clue belongs to. Otherwise, the puzzle can cause frustration by making players think that they are missing something when they aren’t, like the nagging feeling one gets when there are leftover parts when building something. One good strategy in puzzle design, in my experience, is to provide a secondary optional bonus puzzle that uses the same rules as the puzzle on the critical path, but provides some additional content or reward to the player for completing it. 

Remember the fundamentals of puzzle design when constructing them. They might seem obvious, but it can be extremely easy to skimp or skip in the creation of one or more of those basic elements. It’s important to get playtesters who aren’t familiar with the puzzle to test it, especially noting any frustration points. Show the player the way first, point out the necessary elements to complete it, and then let the player make those connections and solve it.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr