#feature breakdowns

This is a follow-up post to [this post about Testing Chamber 16 in Portal].

Today, we’ll be examining Testing Chamber 16 from a more designer-centric perspective. We’ve seen and enjoyed the finished product. Now the question to answer is “How does a level designer get from a list of conceptual level goals to that finished product while incorporating and maintaining the game’s overall themes?”

Let’s identify these conceptual level goals for Test Chamber 16 first:

Introduce the sentry turret to the player

Give the player the first major peek behind the curtain with the “survivor room”

These two goals are really all Test Chamber 16 needs to accomplish individually. We also, of course, need to maintain the overall game’s themes. We have established these themes to be:

The world is built on the [scientific method]

What is being shown is not altogether genuine

Imagine that you’re a level designer and tasked with creating TC16 with the goals listed. You have all of the pieces that you can use to build the level - the glass , portal-able materials (light grey tile), non-portal-able materials (metal tile), turret objects, and the various textured decals you can place on walls and floors like the infographics, painted Xs, and so on.  How do we introduce a new element like a sentry turret to a player who has never seen one before? 

There are several different ways to present the turret for the first time, each with its own implications. For example, we could introduce the sentry turret to the player by having it face the player down almost immediately and begin shooting, along with a safe space to avoid taking additional fire. This would clearly instill a sense of danger in the player associated with turrets. We could introduce the turret via a clearly visible laser beam first, allowing the player to approach it from safety and examine it from a distance before being shot at. The presence of danger is still there, but it is not as immediate and it is not as scary. There is nothing wrong with creating encounters like this! These type of encounters are used in TC16 after all - they just aren’t the very first encounter. The first encounter with a new gameplay element will greatly affect how they view the gameplay element in the future due to the qualities of the experience that are emphasized. 

Instead of emphasizing the danger, the level designer chose to place the first turret in the game facing away from the player where the only way to take damage is by ignoring the turret completely and pushing past it. There is no way to bypass this turret without interacting with it in some way. The player may examine the turret and its attributes at their leisure, but it is also an obstacle that clearly blocks their path. If they try to bypass it, it will shoot them. Further, there is no real portaling to be done in this first chamber either. The glass and metal tiles block the use of portals, which severely limit the use. This is as safe an introduction to the turret as possible.

This is how the puzzle elements in Portal are generally presented - especially in the testing chambers portion of the game. Whenever the player is presented with a new puzzle element (like the sentry turret) and the player is encouraged (and initially forced, as above) to experiment and interact with the new puzzle element in varying ways to attempt to solve it. This follows along exactly with the theme of the scientific method. The puzzles generally add one new element to the test each time.

We should also note that each level in Portal testing chambers is a space where several puzzles are presented in a progressive sequence. Each interaction with the turrets teaches the player something new - what a turret looks like, how the turrets detect the player, how to recognize where a turret is, different ways of dealing with turrets, and ways of bypassing turrets. The experience/tension graph for the level looks something like this:

Observe that there are little tension spikes at each puzzle during the level and the stakes at each puzzle increase. 

For sake of length, we really only tackled goal #1 above - “Introduce the sentry turret to the player”. As a bonus exercise, I encourage you to consider goal #2 yourself. If you’re feeling frisky, please reblog and add your own goal #2 breakdown with your observations and analysis! As a hint, consider where the “secret” room is placed, both in the level and in the tension curve. Why put it where it is? What would be the results of placing the “secret” room at different places along the progression through the level?

[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’s talk for a moment about what makes a move offensive or defensive in a fighting game. In a 1v1 fighting game, offense is generally about trying to either start a damage dealing combo or maneuvering your opponent into a bad situation (e.g. knocked down, in the corner, dizzy, guard broken, etc.). Defensive play is about avoiding these situations - keep the opponent out of their optimal range, punishing mistakes, and generally playing not to lose - a big distinction from trying to win the game. Once we figure out what each style of play wants to do, we can then tune their tools to do the things they want up or down in terms of effectiveness. The effectiveness of their available options determines how good a character is.

Any given move in a 1v1 fighting game has many tunable factors in determining its risk/reward ratio.  These factors include recovery time, range, startup speed, the complexity of activating the move (e.g. a difficult motion input vs pushing a single button), the move’s cooldown, time duration an opponent is unable to act when hit by the move, time duration an opponent is unable to act when defending the move, and the effective range the move can hit. It is within these factors that we the ability to make a particular move better or worse.

What makes a move good is its risk/reward ratio. An offensive move will usually reward the player with something - damage (a combo) or a positional advantage (knockdown, push opponent into the corner, etc.). The risk is typically the move’s recovery - if the player commits to a move, she becomes vulnerable during the move’s recovery and cannot act/defend herself until the recovery period is finished. Moves that have long recovery are more risky than those with short recovery. Moves that recover before the opponent can retaliate are “safe” - a player can use the move without fear of being punished for it. If a safe move also provides a combo opportunity or positional advantage, the move is very good - the risk (low) to reward (high) ratio is in its favor.

Similarly, defensive moves also have a risk/reward ratio. The goals for a defensive move are often positional advantage over damage opportunities. A defensive player generally wants to keep her opponent at a positional disadvantage (in a position where the offensive player’s moves won’t work as well - too close, too far, loses to available defensive options). We can strengthen a defensive move by making it recover faster, stun an opponent for longer, come out quicker, push an opponent away, or knock an opponent down, or even just change the move’s effective range. Conversely, we can weaken them by increasing the risk - longer recovery, more difficult execution, slower startup, etc.

If you want to incentivize offense over defense for a particular character, give them moves/options that are generally safe and/or rewarding while attacking proactively. If the offensive player can attack from relative safety, the defensive player won’t have as many options to counterattack or retaliate against the aggressor. Players will then naturally gravitate toward using these safer moves when on the offense as they find them, because they are great value in terms of low risk and good reward. 

[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

Commentary lines are mostly designed to be modular so that we can construct them on the fly as needed. The lines are broken down into individual chunks of recorded audio and assign them to specific categories so that we can assemble finished lines from the chunks. So, for example, let’s say that we start with this intro line from FIFA 2020:

“Welcome to you all here from the Etihad Stadium in Manchester. Martin Tyler here along with Alan Smith. Premier league football is coming right up. Manchester City against Liverpool.”

How can we begin to break this down into categories? We start by going sentence by sentence. There are four sentences here:

Greeting + Location introduction: “Welcome to you all here from Etihad Stadium in Manchester”

Commentator Introduction: “Martin Tyler here along with Alan Smith”

League introduction: “Premier league football is coming right up.”

Team introduction: “Manchester City against Liverpool.”

Within the sentences, we also identify the parts that need to be recognized. Let’s take the Greeting line and break it down. First, the greeting line could be:

“Welcome to you all here from…”

“It truly is a special place, a stadium that every football fan should visit should he or she get the chance, …”

“Hello wherever you happen to be. Welcome to…”

Followed by the stadium name and then the location:

… the Etihad Stadium in Manchester.

… the Estadio Santiago Bernabeu here in Madrid.

… Catalonia. Welcome to Barcelona.

If you combine each of the three greetings with each of the stadium locations, you can have many more valid commentary lines. We can formulate commentary lines like this for in-game events such as short passes, long passes, penalty kicks, blocked shots, short range goal, long range goal, yellow cards, red cards, etc. as well. They just have to follow a formula - a description of the event, the player(s) involved with the event, and maybe a color commentary reaction to the event. The recorded voiceover lines are organized like a bank of different ways to do each of these parts like the event description, the player names, and the color commentary reactions, as well as different inflections and deliveries for each line in order to convey something different (e.g. excitedly announcing a player name vs normally announcing a player name), and then strung together on the fly to form a complete commentary line. The game then does this for every event that triggers a commentary line, resulting in one of many possible commentary combinations. It also works for different spoken languages as well, as long as the specific category tags for each voice line is keyed in to the database properly. Dynamic voiced line systems like this are also often used in RPGs, with variables like character names, locations, etc. being the categories by which the lines are assembled on the fly.

[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

While this is theoretically possible, there’s some pretty big problems with this method in practice. Before a game launches, most of the gameplay is still in flux - this environment might change, those spell damage values might change, these choices might get swapped around in the talent tree, etc. - because we’re still building the game. If you’re using machine learning to figure out how to play a game and then you change the game, much of the previous data is no longer good because the parameters of the game have changed. Considering that it takes millions of iterations and improvements to get something even approaching reasonable, this isn’t feasible from a scheduling perspective. In order to have the AI learn the game properly, we’d have to completely finish the game except for the AI, then have the AI play millions of games to teach itself how to play, all the while hoping that there are no bugs in the AI system. That’s not really feasible. We don’t have that kind of time, especially because we always have to make changes to the game.

Machine Learning is best utilized in situations that meet two conditions:

The parameters of the problem don’t change

The machine has access to many millions of data points

A game that hasn’t launched yet doesn’t meet either of these two. A game that has already launched might meet #2, but not necessarily #1 due to content updates and patches.

That said, publishers are looking to harness machine learning to do some pretty amazing things, it’s just that they aren’t using it for player-facing gameplay. Instead, they’re using machine learning for two other major features - retaining players and policing players. It’s easy to see why - both of these are tasks that are too big for humans, their parameters don’t change, and they have the requisite millions of data points to analyze. 

Every game wants to keep players playing as long as possible, but quitting players quit for a million different reasons. We can use machine learning to analyze the millions of data points for player behavior to see who’s likely to quit and what we can do or offer them to keep them around. Obviously, we can’t keep everybody from quitting, but we always want to maximize our player retention. Machine learning is very handy to tailor our retention programs to keep players playing because the AI can figure out the various factors of a player we could potentially keep. Big publishers like EA and Activision are already exploring machine learning retention strategies.

Similarly, every game with a player base has a community full of people and some of those people are going to be jerks. Policing toxic behavior is a huge problem that scales up as the number of players grows vastly greater than the number of human GMs capable of handling tickets and punishing toxic behavior. Instead, we can have a machine learning AI scrub through millions of games, chat logs, messages, behavior, player reports, etc. and figure out markers for toxic behavior, then immediately action a player it decides is toxic. The system would obviously need an appeals process in place in case of false positives, but the more data obtained by the AI, the fewer false positives there would be. Riot utilizes machine learning as a means of policing the League of Legends community.

This week we continue the Design Phase of the FANTa Project!

[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

For those who haven’t followed Bloodstained, it’s a new Metroidvania style game from longtime Castlevania producer, writer, and programmer, Koji Igarashi. It was successfully crowdfunded back in 2015. Here’s some gameplay video of Bloodstained in action, recorded at E3 2017:

So… what’s wrong with it? Why does it look bad? There’s two main problems I see with it and both are animation-related.

Problem #1: Everything takes a long time

I downloaded the above video and scrubbed through it frame by frame. The video was captured at 30 frames per second. Almost all of Miriam’s motions are stretched out over many frames of animation, making them feel like the overall game is slow. Her normal fast attacks have 4-5 frames of startup (anticipation, before actually striking) around 25 frames to complete. Heavy attacks with the Claymore sword have 14-15 frames of startup (not striking until half a second after the animation begins), and took 32 frames to complete (more than one second). Picking up a shard (which happened quite often in the demo) took five seconds. It takes two seconds to get a special item in Symphony of the Night.

This is the top of Miriam’s jump arc. Notice how she’s not changing height here at all, and yet there’s still a solid five frames of just floating along horizontally? These extra frames of animation make the player feel like Miriam moves more like a balloon than a slayer of evil.Her jumps feel super floaty because of all this extra time in the air. In comparison, Alucard from Symphony of the Night only spends two frames at the crest of his jump before descending. 

Here’s a sword attack from Bloodstained:

And a similar sword attack from Symphony of the Night.

They are both running at the same frame rate.

Bloodstained has all sorts of movement and combat animations that feel unnecessarily long, and the overall effect is that the game looks and feels floaty and sluggish. It’s a real problem for a game of this type, because the vast majority of the game is spent moving, jumping, and attacking. These motions must feel responsive and tight, and that means short, snappy animations that read well. Bloodstained is supposed to be a spiritual successor to Castlevania, but Castlevania had super responsive and tight controls, and that meant super responsive and tight animations that were played as a result of those controls.

Problem #2: Miriam’s body language is lacking

In most of the actions Miriam is performing, she doesn’t really convey much about who she is or how she’s different. In fact, most of her movements look very much like they were directly inspired by Alucard. The problem is that Miriam should be her own separate person. If you’ve ever played Overwatch, you can tell a lot about each character simply by the way they move. The body language gives you insight about the character. Tracer shows how expressive she is by sticking her arms and legs out all the time. Mei keeps her hands and knees together because she’s shy. Soldier 76 keeps his arms in tight to his chest because he’s old and grumpy, and so on.

What we expect from a slayer of evil would be a wider stance - feet firmly planted and spread apart for stability, facing her potential foes, arms loose and ready in case of trouble. It’s a comfortable stance that’s ready to rumble. Maria Renard (pictured) has a stance like that. Alucard has a stance like that. Miriam does not.

Miriam’s body language is kind of a mess. Her idle stance is this odd side-facing stance with knees together and one arm raised. She’s not facing her threats unless she attacks. Her knees and ankles are kept together, which makes her seem nervous. She has one hand lifted to her cheek as if she is about to sneeze. This pose is not comfortable at all. This visual does not depict a monster hunting slayer of evil. Overall, she looks more like she’s posing for a fashion photographer than ready to fight. If she’s supposed to look this way, then the normal combat animations certainly don’t show it. When she swings a sword, whip, or spear, she looks like she knows what she’s doing. But then she returns to this odd, unnatural looking idle pose and everything feels off. It’s this weird lack of consistency in her movements that throws things off kilter.

Overall, they could improve how the game feels simply by increasing the speed. As an experiment, go back to the youtube video shown above, click the gear icon and change the speed setting to 1.25x or even 1.5x. Now watch some of the gameplay. See how much better it feels? Then throw on some music for atmosphere, and it will feel a lot better. Depending on how final these assets are, there’s still time for them to improve on this. I’m sure the animators at the very least are aware of these problems. I just suspect that there’s somebody in a position of authority that likes it this way.

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

This week, I’ll be taking a look at Redout, a futuristic space racing game by 34BigThings, published on Steam. I don’t know much about this game aside from what I saw in the trailer; I’d never heard of it until @XP_Omake tweeted it to me. Here’s the trailer:

The first thing about this game is that it’s a racing game. As such, the fact that the trailer is only 84 seconds long (with 7 seconds of logos in the beginning and 12 at the end) means that they aimed to convey the gist of the game in roughly 65 seconds of footage. This tells me that they probably focused primarily on the racing gameplay and don’t have a ton of depth in any additional modes, like battle, story, or career. I didn’t see any footage of really resource-intensive features either (like building/customizing your own car) which means they probably didn’t implement it. I am fairly certain that the team must have seriously discussed the possibility, but probably decided it was too much work. If such a feature existed, it would have been showcased in the trailer. It would have required far too many resources otherwise.

The game looks like it’s been optimized for maximum frame rate. You can tell that the environments are low polygon because they all look reminiscent of being molded out of clay - no fancy normal maps or specular maps, not many details to them if you look closely. That’s perfectly fine though - players will barely notice any details because they will be driving through them so quickly. They de-emphasize the low polycount with the bright colors, vfx, level design, and art style. The player’s eyes are almost always drawn to look at the upcoming environment’s shape more than any details. I suspect that the game would feels very arcade-like - none of the tracks’ locations are at all believable as a real (albeit stylized) location. Instead, Redout feels much more like the façade of a theme park ride.

The choice of the futuristic look of the game also feeds into this. Because they are using bright colors and visual effects everywhere, the eye is drawn away from the blockier-looking models. They also aren’t using realistic looking vehicles on purpose. Most racing game fans would recognize a Ferrari or Lamborghini if they saw one. Furthermore, they’d feel strange watching a low polygon car almost immediately because of their familiarity with the vehicle and its design. It just wouldn’t look right. However, players don’t have any such familiarity with future cars, which means that the art team can get away with less detail and lower polygons. All they need is for the cars in the game to be visually distinct (optimally each with a strong and unique silhouette for maximum recognizability).

Usually, it’s because the player is the active participant while most monsters or AI exist only to act as obstacles to overcome. Usually, the player is the one who bypasses these obstacles in search of the objective. Locking a door is inherently contrary to this because it is, by nature, a defensive action. The player is the one doing the seeking, and not trying to protect the objective. Breaking down the act of locking a door, it comes down to two things - the gameplay choice, and showing the player the results of that choice. Let’s examine what this means.

In order for locking a door to become a worthwhile gameplay choice, it requires that the player have something to protect. Typically, this would be the player him or herself, but it is also possible to protect something else. Furthermore, it means the game has to make the player remain in one place long enough for the door locking to be noticeable. The gameplay objective should be about preventing the adversary from advancing - think something like tower defense, or Five Nights at Freddy’s. It’s also possible to make it a solution to a puzzle game or survival horror game - the player needs to be shown that the enemy is not practically defeatable, so simply hindering or barring the enemy’s progress for minimal resources becomes an attractive option. If the goal is to make door locking a gameplay system, rather than a simple one-off puzzle scenario, then you’ll need to figure out what or why the player would want to choose it over not locking the door. Does it take more time? Does it consume some other resource? Is locking a door more secure than simply closing it? Does it help against certain monsters and not others? 

The other issue is that the player needs a chance to see the results of her decision. If a designer gives the player a choice but never shows the consequences of that choice, it might as well not have occurred for the player. A good designer can do this in a variety of ways, and not all of them are visual. You could have the enemy bang on the door and cause loud sounds, or you could show the enemy trying to break through it. You could show fingers trying to reach underneath the door, or you could display blood leaking underneath it. Regardless, a good designer will not only acknowledge the fact the player has locked the door, but also intuitively convey to the player whether that choice was effective or not. Without some kind of reaction or acknowledgement, it isn’t real to the player.

I could probably write an entire book about the sorts of issues when implementing and designing a party-based game like Dragon Age and not even cover them all. It’s sort of a perfect storm of player expectations versus difficult implementations, because it shows just how hard it is to make AI actually behave in a believable fashion. Since nobody really has time for that (least of all me), I’ll try to just talk a little about some of the issues that stem from just the pathfinding.

Let’s just examine some of the issues that stem from pathfinding. When you have a single follower that needs to do pathfinding, you have a number of general issues - setting aside the rather complicated process of actually selecting where to go, you need to figure out how to get there. In a perfect situation, that requires solving navigational challenges like circumventing world geometry and obstacles. Will it traverse things that the player can traverse like jumpable gaps? If not, the player will potentially be able to cause the AI to misbehave by jumping back and forth over an obstacle, and watching the AI run back and forth around it to catch up. This could end up very bad if the AI is a boss type and the player is kiting it.

Coming up with a “perfect” algorithm to select the best path isn’t always what you want either. What if an enemy drops something like a burning patch of oil on the ground? The terrain is clearly traversible, but an intelligent person would want to avoid it. But then you don’t always want to avoid them either - a real person wouldn’t necessarily just completely bounce off of any environmental hazards, and it would become incredibly frustrating if the enemy AI also behaved the same way and avoided any and all environmental space control abilities that the player places. It severely weakens the effectiveness of those abilities when the AI is almost never affected by them. But players are also often frustrated when their AI allies stand in such hazards and continue to take damage.

Sometimes the player would want to take the fire damage if it was advantageous to do so as well - suppose you needed to get into range to heal an ally, or use that last special attack to finish off a powerful foe, then vacating the danger. In such a case, you want these environmental hazards to work sometimes, but how often is enough? How would characters decide whether it was “worth it” to stand in the fire? What if the player disagrees with the AI assessment? How would the player direct how willing the AI is to brave the environmental hazards? Would it be acceptable to stand in fire, but not an ice mine or a poison cloud? And then what happens if the hazard only exists sometimes? Imagine a statue that spits out a cloud of fire that turns itself on and off every few seconds, providing enough time to get through. Would it affect the navigation graph each time it turned on and off? How often would you recalculate the path to take?

Keep in mind, we’re only talking about just one follower here. When you add a second, things get even more complicated. Let’s suppose your pathfinding algorithm decides that there’s one optimal path to get from point A to point B. If you have two followers that both want to get to point B, the algorithm will most likely say to take the same path. So instead of two “intelligent” people moving in an organic way, you’ll end up with a train of AI in a bizarre conga line to get to the target location. Additional followers just add to the length of the conga line until you get a weird looking caterpillar of characters all moving in a line. Solving this particular issue isn’t always cut and dry either, especially when you have to take the previous issues into account as well. 

Adding additional followers also adds to the content complexity at a geometric rate. If you have one follower from a group of N, you have N total options. But if you have two followers, you have N * (N-1) possible combinations. Three pushes this to N * (N-1) * (N-2), four pushes this to N * (N-1) * (N-2) * (N-3) and so forth. What happens if you need somebody to make a comment about something? Since the player can have up to some constant number of party members, you cannot guarantee that any given party member will be there, aside from (possibly) the protagonist. That means every single character has to have a response or comment for specific triggers, in case they are the only one present. You need to have them interact with each other, or it takes away from their believability as characters - the party banter in Dragon Age is a wonderful example of this. But it’s also extremely complex, because there’s an awful lot of it.

This isn’t even taking into account resource limitations, like needing to load each companion’s entire asset suite and how much of the budget is left for enemies and ambient NPCs, which will affect level design. We’ve also completely ignored the actual decisions the AI needs to make in order to decide where to go, and not just how to get there. Each character should also exhibit and build his or her own personality through in-game actions and behavior, not just what he or she has to say. As you can see, there’s quite a rabbit hole when it comes to creating a coherent system of companions for a game like Dragon Age. A real companion system has to be one of those core, fundamental game features that the entire game is planned and built around like stealth. You can’t realistically make a good companion/party system without committing a huge amount of resources to it. 

~~~~~~~~~~~