Developing Your Skills: Playing Games

I recently saw a question on Twitter that spurred a lot of thought for me.

With the risk of adding “one more discourse” to the TL: To make good games, do you need to play a lot of games?

(please keep it civil ❤️)

— Shila Vikström ❤️‍🔥 Make Games With Humanity (@softndeadly) December 28, 2023

I instantly ran through about a million thoughts and counter-thoughts, but to keep it brief, I replied in the negative:

tbh, no. playing games doesn't make you better at making them. being able to understand how other games work and then apply those lessons to your work does. But that's a separate skill than playing games and you can also do that with things that aren't games. https://t.co/yx50AEYZFP

— very cute dog haver (@pedrothedagger) December 28, 2023

Twitter is famously a terrible place to express complex ideas and I got some pushback that I basically all agreed with. But I still think I’m basically correct, and wanted to go into a bit more detail and explain what I meant.

Basically, the core issues I have with the statement “you need to play a lot of games to be a good developer” are:

• Inefficient Use of Time - If your goal is to improve as a developer, “just play games” isn’t a very effective use of time. There are better ways to spend your time in more targeted ways to advance your skills - including more targeted game play.

• Quantity over Quality - It implies a broad, shallow base of experience is better than a narrow, deep base. I vehemently disagree - I think the process of analysis and dissection is the most effective way to extract useful skills from playing other games, and often that requires investing a lot of time and thought into a single game rather than broadly surveying games in general.

• Recency Bias - It isn’t really stated, but a lot of people take this statement to mean “you need to have played the games everyone is talking about”. I think this tends to inject a recency bias into game design and can cause industry-wide stagnation when people are all going to the same well.

What is necessary - and I say this coming from the perspective of a Designer/Programmer but I also believe it is true for Artists and Producers - is the ability to dissect and critically evaluate an experience and for that evaluation to sharpen your own work. I think that much of the time that experience can and should come from playing games, but it is not required to and, in my opinion, should not come exclusively from other games.

Some things I believe are more important and a better use of time than just playing a lot of games:

• Sharpening your critical skills

• Listening to your peers and industry elders share their experiences

• Developing a hobby outside of games that you feel passionate about and invigorates you.

• Using your gaming time wisely

I figured to be more constructive I’d give some tips for these:

Sharpening your Critical Skills

The most important thing you can actively work on as a developer is the ability to do critical analysis, deeply understanding why a game works or doesn’t work, and being able to communicate that to others. That skill is what separates “gaming” from “research for self-improvement”. To develop that skill, I would recommend some of the following exercises:

• Try to write a review for a game you played. Break down what you did and didn’t like. For the things you liked, what choices did the developer make that made them successful? For the things you didn’t like, what do you think the developer was trying to accomplish with them? What would you have done to improve them?

• Find and read some more in-depth criticism - it doesn’t need to be academic but being able to parse criticism that’s a bit deeper than what you’d typically find in <insert gaming site here> is a useful skill that will give you some insight into how to think deeply about games. If you’re comfortable with video format, I’d strongly recommend any of Tim Rogers' youtube work or any of HBomberguy's work - especially surrounding games he likes. Or, if you prefer writing, there’s a ton available but a classic example is Clint Hocking on ludonarrative dissonance in Bioshock which is a great introduction to opening yourself up to thoughts about “what are we really trying to do here, anyways?” when making a game.

• Watch a Lets’ Play or Twitch stream of a game you know fairly well and see how the streamer reacts in situations that you played. Ask yourself some questions: Do they miss things that you noticed? Why? Is that good or bad? Are they having the same kind of experience you had?

Listening to your peers and industry elders share their experiences

Unfortunately GDC is incredibly - stupidly - expensive, but there are some very good GDC talks available on their Youtube. If there is a game you enjoyed, watch the postmortem! Or find if anyone on their team gave a talk! Just watch postmortems in general! Do not just focus on your discipline - learn how to talk to folks in other disciplines about their jobs, too. If you’re a designer, learn what rigging is. Learn a little bit of programming.

Also, there are some great written resources you can access! Nintendo’s long running Ask Iwata/Ask the Developer series is awesome. Listen to some gaming podcasts! No Cartridge and Designer Notes are good! If you found a game really meant a lot to you, try to track down interviews with the developers - this interview with Hidetaka Miyazaki, the director of the Souls games, stuck with me and influenced a lot of my thinking on where I look to find inspiration for game mechanics.

Developing a hobby outside of games that you feel passionate about and invigorates you.

On that note, I think once you have sharpened your critical skills, you owe it to yourself to develop yourself as a person and focus some time on non-gaming hobbies. While sort of counter-intuitive, I think this is critical for at least two reasons:

• As Miyazaki relates in that interview above, inspiration can come from anywhere. And, most importantly, you and your interests can provide a unique perspective to your game development! A lot of your peers will have played Call of Battlefield Modern Black Ops 4 but not a lot of them will have gone fly fishing. If you can look at the experience of fly fishing and understand the joy in it, that is something you bring to the table that most other designers will not. Gardening, Studying History, Film, really anything can fill that role, but any non-game hobby you can become passionate about will develop your unique point of view as a dev.

• Equally important if you hope to have a long career in games, being able to escape the world of video games into a non-gaming hobby can be incredibly restorative and combat burnout. I got to the point, working on console games in the PS360 era, where holding a game controller felt like work. I couldn’t do it. Having music, or weird tech nerd stuff to delve into gave me a way to recharge my batteries and not do longer-lasting damage to my career or mental health.

Using Your Gaming Time Wisely

Ultimately, I think most people get into making games because they on some level enjoy games, so when you do choose to play games it can be really helpful to target your gaming time to develop your skills rather than just shotgunning a lot of games. Some suggestions:

• Keep a specific subject in mind when selecting a game and focus on analyzing it. It can be pretty overwhelming to try to dissect the entire experience of a game as you’re playing it, so it can be helpful - especially if you know something about the game ahead of time - to keep a specific aspect of the game in mind and focus your analysis on that part. Maybe you are interested in a given mechanic, so you select two or three games with that mechanic, and then you compare/contrast how they implement it and where they are successful.

• Try to make yourself uncomfortable. Try to pick well-reviewed games in genres you haven’t typically liked and make a genuine empathic effort to try to figure out why other folks like them.

• Know when to bail. It’s OK to give up on a game if you don’t feel like you are going to learn more by playing it and you aren’t enjoying it.

• Try to go deep on a single game. Pick a single game and try to really fully understand it. Read the Reddit, watch Lets Plays/Twitch streams, get fully immersed in the community, and see where you agree/disagree with the community. Spending a lot of extra time on a single game can often pay off in deep insight into how games work vs. just surveying a large breadth of games.

• Identify your comfort foods. Some games work much better than others as burnout cures - don’t feel a need to push yourself to play the latest thing if you are exhausted. It’s fine to get another Civ 6 game in.

Finally, and this is probably the most important one - you must play your own game. And, if you’re running a studio, schedule working time to play the game you are making. Every person in every department will do their job better with a player’s point of view and understanding of the game they are making. But, employees don’t owe you their time off work, so you need to make time for them to play the game they are making during work hours.

Game Design Topic: Replayability

Given that I haven’t updated my blog in more than a year (oops) likely the first place you find out about this won’t be here if you managed to find your way here from one of my other socials. BUT, I’m giving a talk at GDC next year!

I wanted to focus some of the discussion on topics people found interesting, so I asked folks on twitter for topics they were particularly interested in covering.

Players run WoW dungeons and raids many times. How do you figure out whether a mechanic has legs and will remain fun over time?

How do you allow for players with different skill levels to play in the same group and have fun with each other?

— Lowbo | 就是萝卜 (@itslowbo) December 7, 2023

These questions stood out as maybe not directly related to what I’m covering, but definitely worth discussing. I thought I’d tackle Replayability first.

Replayability

To be completely honest, from the point of view of an encounter designer, or more broadly a combat designer focusing on enemy behaviors, I think it’s very difficult to identify a mechanic as having legs. Replayability is born of the holistic excitement of a play experience, and not any individual mechanic on its own, in my experience. It’s a resonance between all of the various aspects of a game humming together in dynamism.

But, when limited to that encounter designer’s point of view, I do think there are things you can evaluate to try to encourage replayability:

• First - identify the aspects that contribute to your game’s game state that are “chaotic”. For a multiplayer game, that’s fairly obvious (other people) - but as a random example, for a single-player game it might be the physical state of the character. The thing that makes any given jump tricky in an ice-level in a platformer is that the player can’t have quick reactive control over their momentum, so that’s might be a chaotic aspect you could play with.

• Second, identify the type of replayability you are worried about.
  
  Often, roguelikes and high-difficulty encounters in games are focused on replayability of the form “repeated unsuccessful attempts to defeat this encounter should continue to be satisfying”. The idea of “failure is fun”.
  
  On the other hand, low-difficulty repeatable content is often focused on other types of replayability - maybe social replayability that comes from the experience of doing something with different groups of people, or simple variance, where individual attempts of an encounter have radically different ability sets or mechanics.
  
  It’s extremely important to identify which you are going for because they are often diametrically opposed! The random mechanical variance that might work in a piece of casual content is often, in my experience, despised by players challenging extreme difficulty content. They want the ability to break an encounter down mechanic by mechanic and have an enjoyable learning experience. Randomly swapping what they are trying to learn out from under them does not, in my experience, accomplish replayability but instead increases frustration.

• Carefully balance how and when the player will shift from reactive play to learned play. The core difficulty here is not making a mechanic interesting on future playthroughs but instead making solving the mechanic rewarding on future playthroughs. Responding dynamically to a chaotic situation can be extremely taxing mentally for players, so allowing a dynamic situation to quickly “fold down” into a learned process can help balance approachability with replayability.

• Avoid purely binary outcomes. For instance, contrast a situation where a boss goes invincible and forces the player to dodge a complex series of mechanics vs. one where they remain attackable during the sequence. When the boss can’t be attacked, there’s no headroom for a player once they’ve survived the mechanic - either you die or you don’t. When the boss can be attacked and the player is forced to multitask between doing damage to an enemy and avoiding the enemy’s attacks, you essentially have a sliding scale of player performance, all of which would be considered “success” from a purely mechanical point of view, from “I’m 100% focused on avoiding this attack and not trying to do any damage at all” to “I’m able to dodge this mechanic entirely while continuing to do as much damage as normal”. This isn’t just relevant for MMOs - even action platformers like Mega Man, or 3D action games like Dark Souls have boss mechanics where great players can track the boss and deal damage during them and less skilled players have to focus entirely on dodging, increasing the overall length of the fight.
  
  To assist with this, it can often be really helpful to have useful player-visible metrics - either on the game level or within the encounter itself. The obvious ones are things like damage meters or fight timers, but one common more organic example seen in MMOs is being able to push a boss encounter to the next phase before a certain ability goes off. It’s easy to see that as a design flaw, but in reality it can serve as a useful progression marker for a group who has already beat the content and is trying to measure their progress this week against last. Players optimizing their gameplay performance has bred the entire speedrunning scene and leveraging that instinct in your designs can give players a taste of that progression in normal play.

• If you have different classes like in an ARPG or MMO, or different hero characters in a game like LoL or Overwatch, try to make your mechanics clash with the differences in hero stats and abilities in a way that will substantially remix the way an encounter’s mechanics play given a group composition or player choices in character creation. For example, when trying to design engaging “Tank Mechanics” (basically, mechanics that are intended for tanks to do and which force a group to bring a certain number of tanks to a raid encounter), I would often try to find mechanics that would feel very different to the group based on which tank classes they had selected. In WoW this had tons of different angles it could be approached from - different tanks had different damage mitigation strategies, different movement styles, different sets of defensive cooldowns, etc. But, in addition to the differences for the Tank the best Tank mechanics would change how everyone else would react to the tank mechanic based on the class of the Tank as well. Of course, this tends to be more palatable to players on harder difficulties - you often don’t want to target challenge as your avenue of replayability in more approachable content.
  
  Note this is also more useful in a game where you are encouraged to run content with lots of different players. For instance, this kind of variety tended to work better in Mythic+ Dungeons in WoW, which only required 5 players and was basically focused around pick-up groups, vs. Mythic Raids, which required 25 players - the substantial organizational headache tended to force players to form more or less static groups, where they weren’t as likely to see the variance that came from different tanking compositions.

  Finally - and this is most important way but also I can only provide the how here and not the what - but gather the data as a player and from your players.
  
  Keep a list of things that worked in the past and that you can remix or introduce. When you’re designing, implementing, and playtesting a mechanic, are you having fun? If your game hasn’t been released yet, look at other examples from your genre, or that your audience would be familiar with. The more you can empathize with your player’s point of view, the easier it will be for you to identify probable reactions to things you make.

Finally, if you are making a game where replayability is a core goal, I would strongly recommend spending a lot of time doing research in “session” games, aka games where you are intended to do many playthroughs specifically for mechanical reasons (i.e. not VNs or choice-based RPGs - totally cool but a different source of replayability imo). Roguelites/Roguelikes, 4x (Civilization etc.) and Tactics games like XCOM are all great examples. PvP games can also be a big help, though it can be a little harder to directly apply the lessons. But standouts from these genres are great examples where you can experience how to achieve replayability quickly and on your own. Deriving lessons from those games, in my experience, directly contributed to my ability to identify and create replayable mechanics in my work.

Sympathy For the Devs: MMO Healer Tuning

I was watching the most recent FFXIV Live Letter, and this question brought up a lot of memories from tuning raid bosses in WoW:
https://youtu.be/WRpdIL7_NII?t=17440

Essentially, the question boils down to balancing healing output to damage done. Of course the answer that Yoshida gave makes sense and is correct, especially from the perspective of communicating with the community. But I thought it might also be a good jumping off point to discuss some of the detailed difficulties in tuning content in MMOs.

Bring the Player, not the Class

This is something Ghostcrawler said a while back with regards to World of Warcraft, and outside of extreme balance outliers in specific situations, it has generally been true that the best players of the worst class perform better than the worst players of the best class. Some examples from FFXIV:

Here you can see several phenomena that are interesting to both raid and class tuning - First, that if you were to stack rank by 50th percentile damage done (the central line in the fat bar), the stack ranking would not be the same as if you stack ranked by upper quintile (the rightmost “whisker”). Or, in other words, the average Reaper does more damage than the average Dragoon, but the best Dragoon does more damage than the best Reaper. This is mostly interesting from a class design perspective, but from the perspective of a content designer and the overall tuning of content with respect to the community, the important thing to note here is that the gap in output due to player skill (the width of each individual box) is much greater than the distance from the weakest class to the strongest class if you fix the player’s position within the respective classes. Again, this has always basically been true in my experience in MMO tuning, outside of extreme system balance problems.
Additionally - and I will have to provide my anecdotal evidence here because gathering data on this is quite complex - but it is my experience that it is very difficult for players and groups to improve their performance at the game. While it is true that very dedicated players will focus on optimizing their class and output, in the majority of cases it is my experience that, when faced with a situation where a player’s only option is to “push their buttons harder”, outside of the most dedicated players, the response of many players is to give up. Especially when you must take into account that some players are dealing with poor internet connections, and/or physical or mental issues that make playing at an optimal level very difficult. Additionally, imagine you were to select a quartile of players, and select the lowest performing class (or the average of all classes at that quartile). That would give you a Damage or Healing number you could then use to set the minimum requirement for your encounter. However, what you are effectively saying is that, outside of improving gear, most of the players below the line you select will never clear the content unless they improve their performance. Because this is so difficult, you are in effect excluding those players from clearing the content.

The Role of Gear

Gear serves a lot of purposes in an MMO, but gear’s most critical purpose from the point of view of a content designer in an MMO is that, as players earn more gear, it increases the percentage of the player base that can clear content. If you take those statistics listed earlier, and somehow were to record all the player inputs and replay the fights they did, but increases their gear level by a given amount, it would effectively serve to shift all of the bars to the right. If you had previously set the minimum requirements at a given quartile of players, it would now allow a lower quartile of players to clear the content.

Or, from a simpler point of view, you can imagine a graph like this:

While the shape of the curve might not be the same for every set of players, every encounter, or every game, the same basic idea applies - if content is of a fixed difficulty with respect to requirements of damage and healing, the percentage of players who can clear the content increases as a function of item level. This is, in fact, generally a very desirable thing from the point of view of an MMO designer! As long as there is an avenue available for players to continue increasing their item level, they will be able to have a future wherein they can clear any encounter in sight. It encourages them to keep playing and keep trying. And, for the highly skilled players, the prestige of being the first, or in the first 100, etc. groups to clear content is a reward in and of itself.

Finally - and this is not necessarily relevant to the specific issue of healers, item level also impacts the tuning level of future content, and XIV has systems that both target specific content to increase the clear percentage without affecting future content (Echo) and to cap the effects of gear progression on a given piece of content (Item Level Sync). This isn’t specifically relevant to this discussion, but it does elucidate the way that the developers see these systems working together to establish the overall percentage of the community that can clear a given encounter at a given point in time.

The Unique Difficulty of Healer Tuning

We’ve talked a lot about the minimum requirements for clearing content, and in general, the difficulties of tuning around the minimum level of player power required to clear a given encounter tend to be the same for all roles. If the minimum bar is too high for a given role, nobody (or too few people) will be able to clear the content. Whether that burden falls on damage dealers, tanks, or healers does affect the overall social dynamic of the group, and since all players contribute to damage, you tend to see the party’s damage output used as the primary “gate” in hard content. The healer and tank roles are already relatively less popular than damage dealer, and the fact that a healing failure, for instance, is not usually able to be “made up” by damage dealers further discourages extremely high healing checks.

And, once players are able to clear, a difference begins to be seen between damage dealers, tanks and healers. As the group’s damage output increases, players are rewarded with a shorter encounter. While the same encounter but shorter is almost always an easier experience, the fact that damage is not generally “rate-limited” by the encounter means that damage dealers are always encouraged to fully participate in dealing damage.

However, because encounters tend to do essentially fixed amounts of damage relative to player performance regardless of gear level, the amount of healing required does not scale with the players as their gear level increases. This means that as healers’ healing output increases past the minimum required for the group to clear the content, the group is not rewarded to the same degree as it is with damage dealers. There are difficult to quantify ways in which you can argue excess healing capacity is rewarded - like less anxiety on the part of the group with regards to damage done, more opportunities for damage dealers to take risks, or more opportunity to mess up mechanics and still clear - but at the end of the day none of these are seen by players as clear wins in the way that shaving a minute off of the clear time of an encounter is.

In fact, if you are a long-time MMO player you are probably familiar with encounters that did rate limit damage done, and how unsatisfying they could be. Very old wave-based encounters, where waves of enemies would spawn on a fixed timer, essentially forced a minimum encounter length as players waited for enemies to spawn. As the player’s damage increased beyond the minimum required to clear a wave before the next wave spawned, players would end up just sitting around, waiting for enemies to spawn. Not a satisfying experience, and why generally these kinds of encounters began to trigger spawning off of various mechanics that are variations on “timers or the previous wave was killed, whichever comes first” or “spawn next waves after previous waves are killed, but set an overall time limit on the encounter”.

As a healer, if you see your desired gameplay as “as many of my button presses should be dedicated to healing as possible”, it is very difficult to continue to enjoy content at the same level as your gear increases. By the very nature of your increasing gear level, and the fixed damage output of an encounter, fewer of your button presses will be required to heal the fixed damage players are taking as you play through an encounter.

The answer that XIV has employed, and that in general has worked well in my experience, is having healers being able to contribute respectable (if less than other roles) damage done to the boss. This does somewhat go against the fantasy of the healer role - gear essentially acts as a factor that requires you to do your primary role less and contribute to damage more. And there are players for whom the fantasy of being a healer is just healing. They may not find that very successful. Additionally, having to have both satisfying healing gameplay and damage gameplay on a class contributes heavily to “button bloat” - to some extent if you are going to have roughly the same number of abilities available for all classes (a good idea, especially from a UI point of view) - you are going to have to simplify the damage dealing aspect of healing classes when compared to the experience of dealing damage on a damage dealer.

There are solutions here, but they have their own issues. If you are familiar with the Mythic+ system in World of Warcraft, that was used to effectively help content keep pace with player item level and continue to reward them as their item level increased. This approach is successful but has its own pitfalls, which are beyond the scope of this article. And, FFXIV has approached it in a slightly different way with its Ultimate encounters, which do not scale with gear. It is much easier to tune a satisfying healing experience for a fixed gear level.

All in all, it is a difficult situation and one that I’d ask players of all MMOs to have patience with!

A Final Note: Feedback

Finally - I would implore players to think about these issues as they are giving feedback to developers. While, on some level, it is a developer’s job to filter through player feedback to see “what the players really want”, this process can only be helped by clear communication. For instance, as much as possible, avoid focusing on what extremely skilled players are able to do is less important than focusing on your experience and whether you found it satisfying. If the best players in the world are able to solo-heal an encounter, does that affect you directly? Or, do you feel that you don’t have an interesting enough damage dealing rotation in the times that you don’t have damage to heal? Focusing on your own experience, and how it doesn’t line up with what you want, is much more helpful than overly focusing on what the best players in the world are capable of.

Encounter Design Topics: RNG in Encounter Design

RNG (random-number generation, a shorthand for randomness) always feels like a topic that inspires holy wars, both among and between developers and players. I feel like discourse on it tends to frequently be non-specific in a way that hurts the exchange of ideas, so I wanted to write up my thoughts on 1) what RNG is 2) how RNG can be useful as a tool and 3) my personal point of view on using RNG, specifically in encounter design.

A few provisos:

• While you can tell from my About Me page that I did a substantial amount of work at both Blizzard and Obsidian, my point of view is not “the Obsidian Way” or “the Blizzard way”. If I use examples from a Blizzard or Obsidian game, they will be examples of content that I worked on and specifically from my point of view. I will not share “blizzard/obsidian rules” for NDA reasons and I also don’t want to misrepresent my opinions as the opinions of those companies. As such, these should purely be taken as one designer’s thoughts.

• Randomness as a tool in game design is a huge topic, easily enough to write a book about. I am not doing that! The scope of this post is purely on player-vs-computer, single-player or multiplayer, “encounter design” aka the design of challenges that a player is expected to overcome. Though, if I’ve done my job, the applications outside of encounter design should make themselves apparent.

What is RNG?

With any technical game design topic, but particularly with RNG, it’s extremely important to define our terms. Arguing over the meaning of words isn’t fun (for me).

From my point of view, RNG in the context of encounter design is any aspect of an encounter which players cannot predict on repeated playthroughs of an encounter, or between different players’ playthroughs. Broadly speaking, I consider all of the following “RNG” to a lesser or greater extent:

• Attack Selection - For example, a boss might use ability A, B and C in any of the following orders, randomly selected at the start of a phase:
  ABC
  ACB
  BAC
  BCA
  CAB
  CBA
  This can be even broader, for instance, a boss might have 3 phases and do those entire phases in a random order.

• Positional Randomness - For instance, a boss might target different parts of the play space with an ability from run to run. Generally speaking, if that positioning is not influenced by external factors under the player’s control (e.g., where the player is standing, or where the player has lured the boss) I would consider these RNG.

• Technical Run-to-Run Variance - Often, for purely technical reasons, a boss may vary their behavior slightly between runs. Maybe the pathing does something weird, maybe a timer syncs up (or doesn’t sync up), maybe the game lags - this is the randomness that a designer does not intend to include.

• Emergent Behavior - For example, the interactions of AI in a Hitman level. This one is tricky, because everything within an emergent system may be effectively rule-based. But, because often the results of an emergent system lie outside the designer’s control, emergent situations often share aspects of RNG so they’re useful to think about in this context.

Additionally, while it’s typical to think of RNG as a dice roll, or rand()%100>X, there is more richness to random systems that is worth considering:

• Deck of Cards/Bag of Tokens - This is a randomness system where it is either guaranteed, or would be guaranteed given enough time, that you would receive each permutation once before any repeat. If you’re drawing cards off of the top of a single deck, once you’ve drawn the 2 of Hearts you know you can’t draw it again unless it gets shuffled back in the deck.

• Bad-luck Protection - This is a catch-all term for systems that have random elements but that introduce balancing aspects to deal with the feel-bad nature of outliers. For instance, a system that increases the probability of an event whenever the random chance to trigger that event fails.

Why do anything?

I think before talking about how to use RNG as a tool, you first have to think about the reasoning behind any choice you make when designing an encounter. Whenever I talk about encounter design, my point of reference is going to be what I consider a successful design. To that end, I broadly see a successful encounter as doing the following:

• Contributing to the holistic experience/narrative - To me, all designers are “narrative” designers - in that a narrative to me is a crafted emotional and informational experience and all aspects of a game, including encounters, should fill that role. For instance, your encounter might serve as the apotheosis of a character’s arc, or provide a release of tension, or build the atmosphere of a spooky dungeon. Your design should serve the larger experiential goals of the game at that point.

  • While some games aren’t really based around an authored narrative, all games rely on taking the player on an emotional or intellectual journey. You can still think of this goal as serving the story the player would tell of their encounter. Even if you aren’t really serving a larger authored narrative, you should be asking yourself the following questions:

    • What do I want the player to feel during my encounter?

    • What kinds of stories do I want players to tell about their experience in the encounter?

• Serving as a point in the game’s larger arc of mechanical teaching or testing. In general, encounters in games serve to either teach players about the game’s mechanics, or to test their knowledge/ability to execute them. This can also be part of a larger design, for instance, you might design encounters leading up to a boss to teach the player a mechanic which will then be tested in the boss encounter.

In general, as I discuss ways that RNG can be used, or dangers with it, these are the criteria I’ll be using.

Randomness as a tool

Given these criteria, we have to ask - what experience does randomness serve, or how does it meaningfully affect learning the game’s mechanics? Here are some examples from my experience:

• Randomness encourages active response vs. muscle memory - As players who have done tens or hundreds of pulls on an MMO boss will say, if a boss follows a completely set pattern, players begin to be able to do the encounter without thinking - they begin to follow steps, like a dance. Adding random elements breaks up this pattern and forces active reaction. In that sense, it can help alleviate the boredom involved in repeating a section of an encounter where players are practicing a later stage but are forced to repeat the earlier stage to get there.

• Randomness replaces planning with active reaction - As a corollary to the above, some types of randomness force players to respond to situations on the fly vs. strategizing ahead of time what they will do. For instance, WoW/FFXIV allow players to place markers on the playing field. If a mechanic targets non-randomized locations, or if players have control over those locations, players use these markers to determine where to move in response to mechanics. If positioning is sufficiently random, or there are other elements outside of players control, they will instead have to evaluate on the fly. Or, if a game has cooldown-based strategic resources, players cannot fully plan out every cooldown usage when abilities occur in a random order, especially if random ordering can cause them to recur at different points with respect to a cooldown cycle.

• Randomness can distribute responsibility - In a multiplayer environment, when players have control of who an ability targets, they often tend to make a single player cover the work of doing the mechanic just to reduce the potential for error. Or, even if it uses consistent targeting outside of a player’s control, then certain players are forced to hold the burden of responsibility. If, instead, you want all of the players to have to learn to handle a mechanic, random targeting can accomplish that. Of course, another option would be to separately target each player - but generally speaking that can both be fairly boring and you often don’t have the space and time within an encounter to have that many repetitions of an ability.

  • …or, limit usage of individual powerful counters - In many MMOs, certain classes have powerful abilities that let them avoid certain effects - for isntance, in FFXIV tanks have invlunerabilities, and in WoW characters have abilities like Feign Death, Divine Shield, and Ice Block. When players can control who an ability targets, it often lets them always solve the problem with one of those abilities. This has a couple of knock-on effects - it ends up making the mechanic feel like every other mechanic you just invuln to solve, and it also pushes group composition in a way that can be unhealthy for social cohesion in groups.

• Randomness serves to “blur” breakpoints - I’ll explain this by way of an example - when I was working on World of Warcraft, we would support between 10-30 players in Normal and Heroic raids, with mechanics, damage, and health “smoothly” scaling to account for the difference. However, some mechanics do not scale smoothly.
  
  For instance, imagine an encounter where you require a number of players to complete a task. You might want 2 players to complete the task in a group of 10, and 6 in a group of 30. If you simply round up the fractional part when interpolating between those numbers, then adding, say, an 11th player would suddenly cause the number of tasks to increase by 50% while only increasing group size by 10%, increasing the difficulty for the entire group. Rounding down shifts where this breakpoint happens but doesn’t fundamentally change the problem. A simple solution for most groups would be to not invite additional players, and we saw that social dynamic replicated in earlier encounters.
  
  To help deal with this, one solution I used was to establish an “expected value” of tasks per player. So, for instance, let’s say at 10 players there should be 4 and at 30 players there should be 12. This gives us a “tasks per player” value of .4.
  
  Let’s say a group had 18 players. This put their “tasks per player” at 7.2. I guaranteed 7 tasks and used the fractional portion as a random chance of an additional task (.2 being 20%, in this case). So players had an 80% chance of 7 tasks, and a 20% chance of 8 tasks. I then logged the amount of tasks I’d given in total over the encounter (7 or 8 at this point). At each subsequent recurrence of the ability, I’d then compare the expected tasks at that recurrence to the actual tasks, and get the difference.
  
  For instance, on the second recurrence, their Actual Tasks value would either be 7, or 8, and their Expected Tasks for the next case would be 14.4 (7.2 times 2, since this was the second cast). I’d then subtract the Actual from the Expected, giving me a new “tasks per player” value for this recurrence. In this case:
  
  If the players saw 7 on the first task, their tasks per player would now be 7.4.

  If the players saw 8 on the first task, their tasks per player would now be 6.4.
  
  This means, if the players saw 7 the first time, they would be more likely to see 8 the second. If they saw 8, they would see either 6 or 7 the second. Over the course of an encounter, players would see between 6 and 8, and adding a single player would never suddenly and repeatedly cause more to show up.
  
  In this way, adding additional players to the encounter would subtly shift the average number of players who would have to complete the task over the length of the encounter, but in a way that adding a single player would only make a visible difference if players were carefully tracking the total number of tasks over an entire encounter and dividing them by party size. In this way, the breakpoint was “blurred”, reducing the sense that adding a single player was punishing.

Weaknesses of RNG in Encounters

• Randomness, especially low-frequency randomness, can reduce the player’s agency over their success or failure, particularly in strictly tuned encounters - Often, it is unavoidable that one random outcome is marginally preferable from the point of view of players, and will result in higher or lower damage being done. For instance, often targeting a melee player with an ability that forces them to move away from the group will reduce their damage output more than a ranged player in the same situation.
  Depending on the length of the ability, this can cause a substantial reduction in damage output for the group. If you have enough casts of the ability (and if the game in general or other abilities are tuned such that melee has advantages that balance out the inherent weakness of low range), then the law of large numbers can essentially smooth out the impact of these abilities overall - the variance from the randomness starts to diverge toward the average.
  However, if an ability is very tightly tuned, even that variance can be enough to make the difference between success and failure in an encounter. Or, if it isn’t, in can create the perception that the random effects are what determine success or failure. This creates a situation where, in repeated attempts on a very difficult encounter, players are essentially “fishing” for good RNG rather than feeling like they need to perform better to complete an encounter. This is often a frustrating and undesirable experience.
  In general, the best strategy here is often to try to minimize these random elements as the difficulty of encounters increases - or, to try to ensure that randomness is mitigated through a large number of casts. And, of course, outside of the scope of encounter design, characters classes who are disproportionately affected by things like movement should have other aspects that help to counteract those weaknesses.

• “Bad RNG” situations and forced restarts - Also, outside of the impact on tight tuning, if you have some variations of an ability that are particularly difficult to deal with, and that players can randomly end up receiving, AND the frequency is low enough that players may reasonably get through an entire encounter without seeing the “bad” situation, then players may just choose to intentionally fail the mechanic rather than learning the bad case. This is usually not desirable.
  There are three ways to mitigate this that I’ve tried:

  • First, just eliminating the “bad RNG” case from the possible list of option.

  • Second, increasing the frequency of the ability usage such that it becomes impractical to not learn how to solve the bad RNG case. This is especially effective if the ability happens near the start of an encounter, such that not learning the bad case becomes an impediment to later progression in the fight.

  • Finally, force the bad case at least once. On one mechanic I designed, testers felt that one random case was substantially harder than others and that this might be a problem. I just ALWAYS made the one of the casts the worst case, and then randomized from then on. Players were then forced to learn the worst case in order to progress the fight, but I still had the benefits of randomness in other sections of the encounter.

Final Thoughts/Comments and Questions, please!

RNG is a touchy subject between players and designers, and hopefully this helps explain some of the reasoning behind RNG use in encounter design. However, this is a subject that a whole book could be written about, and I’m sure there are many angles I haven’t covered. Please feel free to ask questions in the comments and if there’s any particularly interesting ones I’ll put the answers in the blog or write a new blog response post for them!

Emo Game Design Pt.1: Bark and Bite

How does dodging a fireball in Mario make you feel?

When we’re designing the challenges that players overcome, game designers often focus on strictly mechanical concerns; balance, timing, difficulty. But, ultimately, I’d argue, demonstrating mastery over a game system, particularly in a non-competitive game, isn’t really a virtue in and of itself. Getting good at Mario or Dark Souls doesn’t make me a better person. And in our role as game designers I feel we have a responsibility to ask what we’ve left the player with when they put down the controller. Distracting players momentarily from the difficulties of their life has some value, but if we don’t leave a lasting emotional or intellectual impact, our game will be subsequently be replaced in their mind by the next fleeting distraction. And, as distractions - like social media - become more able to constantly push out content to distract, types of experiences start to lose their value.

Along those lines, some games are purely mechanical challenges. When I play Picross, or do a crossword, I’m not looking to emotionally engage with the content, really, just going through a rote process that distracts and calms me. But I don’t remember specific Picrosses or crosswords that I played through. They are designed to flow in and out of your mind with ease, which is why you usually buy them in packs of hundreds.

But Mario and Dark Souls aren’t those kinds of momentary distractions because they aren’t about the mechanical challenges, they’re about what the mechanical challenges make you feel. A Mario level or Dark Souls environment is about taking you through an emotional ride and leaving you with the memory of those emotions. I don’t really recall the geometry of Blighttown but I absolutely can recall the emotional dread of moving through it.

But, more importantly, how do we create these emotions? What techniques can we use? I wanted to outline some that I’ve found particularly effective. I’ll start in this article with something I’ll call “Bark” and “Bite”.

Bark v. Bite

When presented with a new challenge, players often are unsure of what exactly they’ll need to do to overcome it. But the initial visual presentation of the challenge is often a clue; I’ll call this it’s “bark”. Does this look scary? Does it seem hard when you first encounter it?

On the other hand, there is the actual, practical mechanical actions required to overcome a challenge. I’ll call this the challenges “bite”. This is contrasted to the bark in that, sometimes, something that seems quite easy can in fact be subtly quite difficult and something that seems difficult can be easy.

I’ll use Mario for two examples.

All Bark, No Bite: Auto Levels

An Auto Level, in Mario Maker parlance, is usually a level that looks impossible, but in fact is won just by holding right for the entire level. The experience is exciting both in kind of the “safe but seems unsafe” way that rollercoasters are, and also just in seeing how the level creator put together this machine to let you get through.

All Bite, No Bark: Kaizo Blocks

Maybe the exact opposite example of an Auto level is a Kaizo Block - an invisible coin block in a Mario level that exists specifically for the purpose of surprising you by killing you when you make a jump a certain way. You don’t even know that a challenge exists there until it kills you the first time. These kinds of sucker punches (the Soulsborne games frequently use these) create a sense of caution, surprise, and (in the right player) humor. They are, basically, pranks.

Balancing Bark and Bite

However, outside of these niche Mario Maker levels, these concepts have a lot of value too, and learning to balance them as a designer will make you much . A common way to make a player feel powerful as they learn is to increase the “Bark” of a mechanic, without necessarily increasing its “Bite”. For example, a common trick I’ve used is to fire a large number of projectiles, having one target a player’s location directly and other scattered randomly at a distance. The player only really has to dodge the one aimed at them, but the other projectiles give the attack a sense of realism and provides the player with a greater sense of power and accomplishment for overcoming the challenge. Increase the missiles - which are from a gameplay point of view essentially just noise - and increase the sense that the player is overcoming overwhelming power to succeed.

On the other hand, increasing “Bite” without increasing “Bark” is a great way to signal to players that they need to be more cautious, or think harder about a challenge. For instance, if you’re making multiple levels of difficulty of a single piece of content, an effective way to highlight the changes is to specifically design to foil a simpler strategy employed on lower difficulties - which allows the player to discover naturally through the course of their attempts on something that their old strategies won’t work. It forces them to take a step back and think through the entire challenge again, to reevaluate old decisions. And, if you made it overly obvious up front that their old strategy wouldn’t work without letting them see it fail for themselves, the emotional moment of reckoning of seeing their plan fail wouldn’t have the punch it would have otherwise.

The critical point here, which is going to be a theme whenever I write about Emotional Game Design, is to put yourself in the shoes of a player who is engaging with the mechanics for the first time, rather than just designing for the specific challenge you want players to overcome. Look at both the actual mechanical difficulty as well as the presentation of that difficulty to make an experience not just challenging, but memorable.

I could go on forever about designing for emotions, but I want to actually post something so I’ll cut this off here. Stay tuned for more!

Welcome! New Site!

Hi! Lots of changes recently that I think warranted me setting up a “real website”, so I went ahead and did that.

Recently I:

• Left my job as an Encounter Designer on World of Warcraft at Blizzard Entertainment! It was an amazing experience and I learned an incredible amount from the other great folks there, and loved my team, but I have new experiences and ideas I needed to explore.

• I also recently appeared on an episode of very cool leftist gaming podcast No Cartridge! Go and listen! And support them on their Patreon!

Anyways, if you’ve come by, thanks for coming by! You can check out the About Me section for my portfolio and a timeline of my career if you’re interested to learn more, and you can always see my latest ramblings on my Twitter. Welcome!

Persona 5, untranslatable jokes, and tokin on 4/20

To preface this: Persona 5 is the best JRPG in years. Please buy the game. Please do not use this or any bitching about the localization you see as a reason not to get it, because it isn’t one. It’s great. Play it. I will probably be making a post soon about some of the brilliant game design things in it!

So I was irritated about one of the questions in Persona 5 and made a random tweet about it after looking it up in english sources and trying to figure out a factual basis for it.  All the english sources on tokin (the name of a promoted pawn in Shogi) did not mention the history of how kin became to, and, more importantly, I could not find a single example of a cursive kin anywhere that looked anything like a to. So what the game was saying seemed pretty darn suspect.

Now to be fair, I don’t consider myself an authority on Japanese language and wouldn’t expect to be cited as such, but shortly thereafter Chris Kohler at Kotaku linked to the tweets and made an article based on them:

http://kotaku.com/this-might-be-persona-5s-biggest-translation-fail-1794223069

Now I want to specify that I was not contacted ahead of time about this. I didn’t plan or want this to become an article at a major game site. I was just kinda bitching. I did not expect this to extend beyond the people who follow me, many of whom give no shits about Persona, localization accuracy, or the minutiae of Kanji. If I had been asked, I would have preferred not to be cited for two reasons:

• It’s really a minor issue and I don’t think it’s representative of my overall feelings on the game.

• The level of research I put into it the tweet was appropriate for a tweet, not for an article in a major game news site.

But, at the same time, I don’t think Chris had any bad intentions with the article - it was just an interesting point of the language and an odd thing to show up in an English localized game. Chris is a good dude.

Anyways, as soon as I saw it had been made into an article, I panicked because if I wanted to be more sure I was accurate, I should have looked at Japanese sources. So I did. And, thankfully, japanese google provided this article which was massively helpful:

http://www.tonan.jp/moji/10tokin/

So, this is a long article. But what it boils down to, is arguing that it is not, in fact, a hiragana と at all - but, it also argues that it is quite uncertain as to what it actually is.

It looks like he ends up feeling like the most likely explanation is that it originated from  今, which is an ateji (phonetic replacement or spelling of a kanji that is read a certain way with no regard to its meaning) for 金.

http://tonan.seesaa.net/article/31091021.html

Anyways, either way, my explanation was wrong, which I then brought up to Chris, who was nice enough to update the article.

Now, while admitting that I was inaccurate in my factual reasoning as to why it was factually wrong, the fact remains that the statement in the english version of the game - that と金 is the cursive form of a specific kanji - is wrong. Now, it appears that there’s argument as to whether the Japanese was even correct - but it’s certainly different, and less wrong than the English. Let me explain why.

Here’s the original Japanese:

In text:

この字はある漢字の崩し字なんだ、 なにか分かる？

So, let’s break this down. First, I’ll translate the easy nouns.  字 (ji) is character (it can mean other stuff but that’s most likely in this context).  漢字 (kanji) is… kanji.  

The other noun is 崩し字 (kuzushiji) , which can sort of theoretically be translated to “cursive” or “simplified” character - but it doesn’t mean cursive in really the same sense that western cursive is used. There’s a ton of possible ways to write a character in  崩し字 - really, anything that is written using a brush and omits or simplifies strokes is technically 崩し字. Which is why, in the articles above, he dislikes the argument that tokin originates from a  崩し字 of  金, because while it could be a theoretically VERY cavalier 崩し字, it really drastically simplifies the kanji (far moreso than the other shoji pieces simplify the same kanji). But I’ll give that that’s a lot of detail the game can’t provide so I’ll let it get away with cursive form :)

Okay, so we have:

この character はある kanji の cursive form なんだ、なにか分かる？

Next, the other easy stuff.  この is this.  なんだ is “what is”.  なにか means something. So we get:

This character  はある kanji の cursive form what is、something 分かる?

Last we’ll do verbs and particles. I won’t explain particles because they’re a whole section of Japanese grammar that’s not really pertinent and is somewhat complex but suffice it to say they are short “grammatical helpers” that mark the grammatical function of words in sentences, sort of like helping verbs and articles in English. Anyways, the verbs here are ある (aru), which means to be/exist (specially referring to inanimate objects), and  分かる (wakaru) which means a lot of different things in english, but usually it means do you understand or know. The only other things are  は, which is a particle marking a new topic of conversation in a sentence, and has no real translatable direct equivalent in english, and の, which indicates that a noun possesses or modifies another noun. So, without any word rearrangement, you end up with:

“This character is cursive form of kanji what is, something understand?”

Which is a little intentionally obtuse but some simple rearrangement gets you something closer to english:

“This character is cursive form of what kanji, something understand?”

This is all you can really infer from transliteration. To turn this into actual English we need to start making value judgments and doing actual translation. So to get English out of this, the first and easiest thing to do is to realize that  なにか分かる is just ellipsing the subject, which is probably the student who the teacher is asking the question to. Also, you need your helping verbs and pronouns, and the nanika wakaru is more of an expression, so it’s probably closer to “do you know?”. All of that is interpretation and at the translator’s discretion, but it’s necessary to end up with something that’s vaguely English.

For the first part of the sentence, you are almost actually at a readable fragment, you just need an article, and here’s where I think the translation goes wrong. It uses “the”, when it clearly should use “a”. 

Why? “the” implies singularity and absoluteness. “the” implies that there is a single, or at the very least primary answer to the question “what is the cursive form of this kanji”, and that that single answer is the one they are looking for. But any Japanese person will tell you that 1) there are many cursive forms of Kanji and 2) that the “primary” cursive form of the 金, if it existed, would not be what is seen on the shogi piece. In fact, the very next slide conflicts with the usage of “the”, because it shows three different purported cursive forms of  金- and again, whether tokin factually is a cursive form of 金 is debatable, but that is at least asserted in the Japanese text, too!

So, I think a closer translation (and closer to the original Japanese structure) would be something like: “This character is a cursive form of a kanji - do you know which?” If you wanted to make it flow better, you could go from there. Something like “Can you tell me which cursive kanji this character originated from?”

Now, you might argue a simple swapping of “a” for “the” isn’t a big deal. And you would be right to some extent. But I certainly would argue that it undermines the coolest part of these little quiz games, which is that they actually teach you things! You could imagine someone playing this game, then later picking up Japanese, seeing a hiragana “to”, and telling their teacher “oh I learned that’s a cursive “kin!”” to be greeted by a frowning head-nod no. One of the coolest parts of the persona games is the opportunity to learn about Japanese, and it’s a bummer that it gives you misinformation by way of a relatively simple error.

But -  I actually think the bigger translation issues, and the reason why I think a bigger change should have been made to this question, is in the answers. So, this is actually even a tricky question in japanese! While searching for japanese sources, I actually found this blog:

http://karigezima.com/archives/25714

which says:

将棋経験者ならすぐに分かる問題です。

将棋してない人からしたら難しい…かな？(´･ω･`;)

Or - “Shogi players will instantly know the answer. But people who don’t play shogi probably screamed about how hard it is, huh?”

So yeah - this is a tricky question in Japanese. But, in typical multiple choice test fashion, it actually has something to help you out:

So here’s the answer options in Japanese. Let’s compare them with the english options:

So, to start things off, the question is asking about the cursive form of kanji - which you need to be able to see the kanji to determine, but the english version doesn’t let you see the freaking kanji! And, a single English word might correspond to multiple kanji. For instance, divination as a kanji could just as easily be 占 as卜. And, while it’s more of a technicality because  金 is certainly the most obvious kanji that means “gold”, gold could also mean  鋆,  釛 ,  鉚,  鎏 ,  鏐 . Those might not be things that a sane person would think of when given the option “gold”, the fact remains that the game is supposed to be translated into English and you shouldn’t need to know Kanji to understand and answer questions correctly in it!

But I think the bigger deal here is that you actually miss out on the “dummy” option. See, because while “Divination” is technically what 卜 means, it is not an option in the Japanese version because of that - it’s there because it’s looks almost exactly like ト, which is the same sound, “to”, in the other major japanese character system, Katakana.

So for a Japanese speaker, you instantly see that dumb middle option and rule it out because it’s clearly a trick answer for dummies. It’s even maybe a little chuckle-worthy. You just miss out on all of that in english.

Because it’s so untranslatable to someone who doesn’t understand Japanese, and because really the relevant point here narratively and symbolically is that the lowest shogi piece can promote into the Gold General, and how that ties into the idea of neauvau riche, I think it would have been nice to just ask something like “This piece indicates when a pawn is promoted to what rank”? It’s a bit further from the Japanese, but again, if you can’t convey the meaning in Japanese without explaining what kanji are, how they are simplified, and make the answers make sense visually to players, maybe just get at the heart of the issue and the bigger narrative point.

Anyways, long story short - I still think this could have been better, but I’m glad it existed in a way because it was very much a learning opportunity for me!

After posting this, someone added a helpful comment:

Hey, Nate. MDB again. Thought I could lend my expertise, since it’s always better to have two experts tackling a problem like this. Here are some notes:

なんだ (nanda) does not mean “what is.” It’s the short/informal form of the phrase なのです (nano desu), which is simply a way to end a clause that ends in a noun while also inserting your personal feelings into the phrase. In effect, it’s a verbal punctuation mark. If that sounds terribly confusing, that’s because it’s Japanese, one of the most complicated languages on Earth.

The word ある (aru) is, as you said, a verb meaning “to be/exist.” And it’s true that placing a verb before a noun makes it a relative clause. So you technically could say that the translation for ある漢字 is “the kanji that exists.” But that extremely inefficient and redundant. You’d get the exact same meaning from taking the “aru” out, so there’s no reason for it to be there.

Which is why! The word “aru” before a noun is used to indicate a particular one of those things. So ある日 means “someday,” ある人 means “somebody,” etc. So the proper translation for ある漢字 would be “some (particular) kanji.”

なにか (nanika) does indeed mean “something” or “anything,” but in the particle か (ka) indicates a request for specific information. When asking a question with a yes or no answer, you use かどうか (kadouka). Examples:

「いくらか分かる？」(Ikura ka wakaru?) “Do you know how much (it is)?”

「どこにあるか全く知らんねんで。」(Doko ni aru ka mattaku wakannen de.) “I ain’t got a clue where it is.”

なに (nani), as I’m sure you know, means “what,” so when the teacher asks, “Nani ka wakaru?” she’s not saying, “Something understand?” it’s more like, “Do you know what (it is)?”

Finally, in your post, you accidentally omitted part of the Japanese version. You wrote:

「 この字はある漢字の崩し字なんだ 、なにか分かる？」

But the text in the game actually says:

「 この字はある漢字の崩し字なんだけど、なにか分かる？」

It’s not super important, but it still holds a minor significance that has to be considered depending on how you want to convey the character. Personally, I like to translate けど (kedo) to “Even though”, but the word “but” works just as well. It’s much more complicated than that, so just role with it, for now. Get it? “Role”? ‘Cause it’s an RPG? Um…anyway.

When you put it all together, there are several ways you could translate the sentence, but it turns out the way it was localized was actually pretty faithful: “This character is the cursive form of a specific kanji. Do you know which one it is?” A little verbose compared to the original, but grammatically, very close!

Hope that helps!

Thanks! That’s helpful :D It’s good to talk about this stuff.

You’re right about  なんだ in this context, for sure. I can be a casual form of なんです, which is what had confused me.

The other points are totally valid, and I totally agree I missed a couple things. I still think the choice of “the” is wrong, though as I said I think it’s a pretty minor issue. I still wish they showed you the kanji options though!

• It’s really a minor issue and I don’t think it’s representative of my overall feelings on the game.

• The level of research I put into it the tweet was appropriate for a tweet, not for an article in a major game news site.

But, at the same time, I don’t think Chris had any bad intentions with the article - it was just an interesting point of the language and an odd thing to show up in an English localized game. Chris is a good dude.

Anyways, as soon as I saw it had been made into an article, I panicked because if I wanted to be more sure I was accurate, I should have looked at Japanese sources. So I did. And, thankfully, japanese google provided this article which was massively helpful:

http://www.tonan.jp/moji/10tokin/

So, this is a long article. But what it boils down to, is arguing that it is not, in fact, a hiragana と at all - but, it also argues that it is quite uncertain as to what it actually is.

It looks like he ends up feeling like the most likely explanation is that it originated from  今, which is an ateji (phonetic replacement or spelling of a kanji that is read a certain way with no regard to its meaning) for 金.

http://tonan.seesaa.net/article/31091021.html

Anyways, either way, my explanation was wrong, which I then brought up to Chris, who was nice enough to update the article.

Now, while admitting that I was inaccurate in my factual reasoning as to why it was factually wrong, the fact remains that the statement in the english version of the game - that と金 is the cursive form of a specific kanji - is wrong. Now, it appears that there’s argument as to whether the Japanese was even correct - but it’s certainly different, and less wrong than the English. Let me explain why.

Here’s the original Japanese:

In text:

この字はある漢字の崩し字なんだ、 なにか分かる？

So, let’s break this down. First, I’ll translate the easy nouns.  字 (ji) is character (it can mean other stuff but that’s most likely in this context).  漢字 (kanji) is… kanji.  

The other noun is 崩し字 (kuzushiji) , which can sort of theoretically be translated to “cursive” or “simplified” character - but it doesn’t mean cursive in really the same sense that western cursive is used. There’s a ton of possible ways to write a character in  崩し字 - really, anything that is written using a brush and omits or simplifies strokes is technically 崩し字. Which is why, in the articles above, he dislikes the argument that tokin originates from a  崩し字 of  金, because while it could be a theoretically VERY cavalier 崩し字, it really drastically simplifies the kanji (far moreso than the other shoji pieces simplify the same kanji). But I’ll give that that’s a lot of detail the game can’t provide so I’ll let it get away with cursive form :)

Okay, so we have:

この character はある kanji の cursive form なんだ、なにか分かる？

Next, the other easy stuff.  この is this.  なんだ is “what is”.  なにか means something. So we get:

This character  はある kanji の cursive form what is、something 分かる?

Last we’ll do verbs and particles. I won’t explain particles because they’re a whole section of Japanese grammar that’s not really pertinent and is somewhat complex but suffice it to say they are short “grammatical helpers” that mark the grammatical function of words in sentences, sort of like helping verbs and articles in English. Anyways, the verbs here are ある (aru), which means to be/exist (specially referring to inanimate objects), and  分かる (wakaru) which means a lot of different things in english, but usually it means do you understand or know. The only other things are  は, which is a particle marking a new topic of conversation in a sentence, and has no real translatable direct equivalent in english, and の, which indicates that a noun possesses or modifies another noun. So, without any word rearrangement, you end up with:

“This character is cursive form of kanji what is, something understand?”

Which is a little intentionally obtuse but some simple rearrangement gets you something closer to english:

“This character is cursive form of what kanji, something understand?”

This is all you can really infer from transliteration. To turn this into actual English we need to start making value judgments and doing actual translation. So to get English out of this, the first and easiest thing to do is to realize that  なにか分かる is just ellipsing the subject, which is probably the student who the teacher is asking the question to. Also, you need your helping verbs and pronouns, and the nanika wakaru is more of an expression, so it’s probably closer to “do you know?”. All of that is interpretation and at the translator’s discretion, but it’s necessary to end up with something that’s vaguely English.

For the first part of the sentence, you are almost actually at a readable fragment, you just need an article, and here’s where I think the translation goes wrong. It uses “the”, when it clearly should use “a”. 

Why? “the” implies singularity and absoluteness. “the” implies that there is a single, or at the very least primary answer to the question “what is the cursive form of this kanji”, and that that single answer is the one they are looking for. But any Japanese person will tell you that 1) there are many cursive forms of Kanji and 2) that the “primary” cursive form of the 金, if it existed, would not be what is seen on the shogi piece. In fact, the very next slide conflicts with the usage of “the”, because it shows three different purported cursive forms of  金- and again, whether tokin factually is a cursive form of 金 is debatable, but that is at least asserted in the Japanese text, too!

So, I think a closer translation (and closer to the original Japanese structure) would be something like: “This character is a cursive form of a kanji - do you know which?” If you wanted to make it flow better, you could go from there. Something like “Can you tell me which cursive kanji this character originated from?”

Now, you might argue a simple swapping of “a” for “the” isn’t a big deal. And you would be right to some extent. But I certainly would argue that it undermines the coolest part of these little quiz games, which is that they actually teach you things! You could imagine someone playing this game, then later picking up Japanese, seeing a hiragana “to”, and telling their teacher “oh I learned that’s a cursive “kin!”” to be greeted by a frowning head-nod no. One of the coolest parts of the persona games is the opportunity to learn about Japanese, and it’s a bummer that it gives you misinformation by way of a relatively simple error.

But -  I actually think the bigger translation issues, and the reason why I think a bigger change should have been made to this question, is in the answers. So, this is actually even a tricky question in japanese! While searching for japanese sources, I actually found this blog:

http://karigezima.com/archives/25714

which says:

将棋経験者ならすぐに分かる問題です。

将棋してない人からしたら難しい…かな？(´･ω･`;)

Or - “Shogi players will instantly know the answer. But people who don’t play shogi probably screamed about how hard it is, huh?”

So yeah - this is a tricky question in Japanese. But, in typical multiple choice test fashion, it actually has something to help you out:

So here’s the answer options in Japanese. Let’s compare them with the english options:

So, to start things off, the question is asking about the cursive form of kanji - which you need to be able to see the kanji to determine, but the english version doesn’t let you see the freaking kanji! And, a single English word might correspond to multiple kanji. For instance, divination as a kanji could just as easily be 占 as  卜. And, while it’s more of a technicality because  金 is certainly the most obvious kanji that means “gold”, gold could also mean  鋆,  釛 ,  鉚,  鎏 ,  鏐 . Those might not be things that a sane person would think of when given the option “gold”, the fact remains that the game is supposed to be translated into English and you shouldn’t need to know Kanji to understand and answer questions correctly in it!

But I think the bigger deal here is that you actually miss out on the “dummy” option. See, because while “Divination” is technically what 卜 means, it is not an option in the Japanese version because of that - it’s there because it’s looks almost exactly like ト, which is the same sound, “to”, in the other major japanese character system, Katakana.

So for a Japanese speaker, you instantly see that dumb middle option and rule it out because it’s clearly a trick answer for dummies. It’s even maybe a little chuckle-worthy. You just miss out on all of that in english.

Because it’s so untranslatable to someone who doesn’t understand Japanese, and because really the relevant point here narratively and symbolically is that the lowest shogi piece can promote into the Gold General, and how that ties into the idea of neauvau riche, I think it would have been nice to just ask something like “This piece indicates when a pawn is promoted to what rank”? It’s a bit further from the Japanese, but again, if you can’t convey the meaning in Japanese without explaining what kanji are, how they are simplified, and make the answers make sense visually to players, maybe just get at the heart of the issue and the bigger narrative point.

Anyways, long story short - I still think this could have been better, but I’m glad it existed in a way because it was very much a learning opportunity for me!

After posting this, someone added a helpful comment:

Hey, Nate. MDB again. Thought I could lend my expertise, since it’s always better to have two experts tackling a problem like this. Here are some notes:

なんだ (nanda) does not mean “what is.” It’s the short/informal form of the phrase なのです (nano desu), which is simply a way to end a clause that ends in a noun while also inserting your personal feelings into the phrase. In effect, it’s a verbal punctuation mark. If that sounds terribly confusing, that’s because it’s Japanese, one of the most complicated languages on Earth.

The word ある (aru) is, as you said, a verb meaning “to be/exist.” And it’s true that placing a verb before a noun makes it a relative clause. So you technically could say that the translation for ある漢字 is “the kanji that exists.” But that extremely inefficient and redundant. You’d get the exact same meaning from taking the “aru” out, so there’s no reason for it to be there.

Which is why! The word “aru” before a noun is used to indicate a particular one of those things. So ある日 means “someday,” ある人 means “somebody,” etc. So the proper translation for ある漢字 would be “some (particular) kanji.”

なにか (nanika) does indeed mean “something” or “anything,” but in the particle か (ka) indicates a request for specific information. When asking a question with a yes or no answer, you use かどうか (kadouka). Examples:

「いくらか分かる？」(Ikura ka wakaru?) “Do you know how much (it is)?”

「どこにあるか全く知らんねんで。」(Doko ni aru ka mattaku wakannen de.) “I ain’t got a clue where it is.”

なに (nani), as I’m sure you know, means “what,” so when the teacher asks, “Nani ka wakaru?” she’s not saying, “Something understand?” it’s more like, “Do you know what (it is)?”

Finally, in your post, you accidentally omitted part of the Japanese version. You wrote:

「 この字はある漢字の崩し字なんだ 、なにか分かる？」

But the text in the game actually says:

「 この字はある漢字の崩し字なんだけど、なにか分かる？」

It’s not super important, but it still holds a minor significance that has to be considered depending on how you want to convey the character. Personally, I like to translate けど (kedo) to “Even though”, but the word “but” works just as well. It’s much more complicated than that, so just role with it, for now. Get it? “Role”? ‘Cause it’s an RPG? Um…anyway.

When you put it all together, there are several ways you could translate the sentence, but it turns out the way it was localized was actually pretty faithful: “This character is the cursive form of a specific kanji. Do you know which one it is?” A little verbose compared to the original, but grammatically, very close!

Hope that helps!

Thanks! That’s helpful :D It’s good to talk about this stuff.

You’re right about  なんだ in this context, for sure. I can be a casual form of なんです, which is what had confused me.

The other points are totally valid, and I totally agree I missed a couple things. I still think the choice of “the” is wrong, though as I said I think it’s a pretty minor issue. I still wish they showed you the kanji options though!

Dark Souls & Easy Modes: A Counter-Argument

I recently read a very good article arguing for the existence of an “easy mode” for Souls games.

While reading, I noticed that I agreed with the contour of his arguments and understood the motivation. And yet, I disagreed with a fundamental part of his premise - it is both presumptuous and abandons the responsibilities of both the author and the audience.

I’ll go into this in more detail, but the combat mechanics serve to reinforce a central underpinning of Dark Souls, which is an emotional arc that is reinforced through story, mechanics, art and lore.

First - where I agree with his arguments. The arguments against an easy mode that he is refuting are, actually, bad arguments against an easy mode. The first is ludicrous - I do not need to die repeatedly to appreciate an area in Dark Souls. In fact, the effect of the difficulty in Dark Souls is exactly why can appreciate combat areas without dying!

I also think that players should be able to consume games as they like. I don’t believe that there is something morally wrong about changing a piece of art. Where I disagree is about who that rests upon.

To underpin my objection to his argument, I’d like to talk about the role I think difficulty plays in Dark Souls. Many critics assume that the difficulty in Dark Souls primarily exists to force you to reckon with and master its mechanics. I think this is partly true, but mostly false. The reality is, no matter how well you have mastered the mechanics of the game, you can make progress in Dark Souls. The entire RPG conceit of levelling up and coming back to beat a boss later goes against the core concept that mastery must be used to beat bosses. Additionally, the social mechanics, and the summoned AI companions all provide workarounds for mechanical mastery. You could play through a Souls game, blissfully ignoring all mechanics, sheltered by players online. So the argument that demanding mastery of mechanics is the primary reason for Souls’ difficulty seems to be countered by the game itself, which provides many opportunities to circumvent mastery and still make progress.

Additionally, if pure mastery were the goal in a Souls game, I would argue that the games are extremely poorly paced - the RPG progression insures that the first areas in the game are often the most difficult, packed with the most frequent and seemingly unfair deaths. A game that was truly about mastery would layer increasing challenge against an undeveloping character - something like Titan Souls. Or Devil May Cry, though that does offer a soft progression system.

Instead, I see Dark Souls’ difficulty as a narrative paintbrush - it exists to reinforce the hostility of the world and elicit an emotional response on the part of the player. Everything in the game is designed to elicit a sense of anxiety, loneliness, and fear at being a stranger in a strange land. You are unwelcome. You should not be here. As you learn to navigate an area, you become more familiar with it - what once caused anxiety is now commonplace. You have made a foreign place your home.

That emotional arc proceeds on at least three levels - in individual encounters, in whole areas, and in the game as a whole. Your first encounter with a new creature often ends in death. The emotional journey is reinforced by every mechanical and artistic choice made in the game - the unsettling enemy designs that frighten at first, the spare music and echoing sound effects, the sense of extreme loneliness in a game with very few talking characters (and most of whom seem… not entirely there), and even the lack of any in-game map.  And, yes, the progression systems that ultimately make the end of the game easier than the beginning.

So, when people say that the difficulty itself is integral to Dark Souls, I think they are mistaken. The game’s difficulty is a tool to elicit an emotional response on the part of the player, not an end in itself.

Which leads me to why I disagree with what seems like a central supposition of his article - that the game should provide an easy mode.

I don’t, actually, think there’s anything wrong with wanting to play an easy version of Dark Souls. I also don’t think there’s anything wrong with publishing editions of books that remove “difficult” content. However, asking (or demanding) that the creator of the original work provide a compromised version of their vision to suit individual tastes presumes a responsibility on the artist that their art must appeal to the masses. It is demanding that the author not only share their vision, but also write the Cliff’s Notes. Either it fails to understand the artistic value of the mechanical aspects of the games, or it presumes that game creators’ role is to cater to the whims of their audience rather than express what they want to express. I can’t get behind this.

However! I said I agree that players should be able to enjoy games as the wish! And I do believe that.

What I think many of the arguments for an easy mode fail to recognize is the role and responsibility of the audience. There, in fact, does exist an easy mode, along with hundreds of other user customizations - you can go download them on the Dark Souls Nexus: https://www.nexusmods.com/darksouls/mods/top/?. Some of these can be used to lower the difficulty of the game, make monsters stand still, etc. There are maps available online that ease the sense of anxiety exploring new areas. These are all things that the audience has done, creative works of interpretation that a community has done in response to the creator’s original vision.

So - in short - there’s nothing wrong with wanting to play an easy mode in Dark Souls. There is something wrong with asking the creator to compromise their vision in order to deliver it into your hands. The artists responsibility is to communicate their vision, not necessarily to make sure that we all see it.

Numerical Tuning Lessons

At some point, if you’re doing system design, or anything that butts up against system design, you’re going to end up looking at formulas in an excel spreadsheet. I’ve spent plenty of time over the past 10 years looking at these and tweaking games and figured some lessons I’ve learned would help other people.

Lesson 1: Get Exposed

This is a fairly simple one, but important - if you’re working on a big team, and you aren’t an engineer, make sure the engineers expose as many tuning variables and formulas to you as possible. It is your responsibility, and should be your goal, to understand fully how the game’s systems work. Additionally, the ability to A/B test different values is massively helpful when trying to grok how numerical changes effect the feel of gameplay. If those values or formulas are hidden in code that you don’t have access to, you can’t really fully understand how things really work.

This has worked different ways on different games I’ve worked on - on Dungeon Siege III, for instance, I owned the .cpp files that defined the RPG systems and the numerical rules for them. On other games, these have been exposed in data tables or through script. And, in the worst cases, they’ve been hidden in code that I didn’t have access to and had to look over an engineers shoulder as they made changes for me.

The cases where these worked best were where I could fully see and understand all the details of how the system worked and could freely tweak and iterate on my own. You can’t tune a system you can’t edit, and you can’t truly understand a system that you can’t see. Get those values and formulas exposed! 

Lesson 2: Minimize Floating Variables (or: Only Tune What You Want)

Games, especially RPGs, typically have lots of numbers that interact in complex ways. There are the obvious numbers - HP, damage, statistics, and then there are “out-of-game” values, like expected time to kill a monster, power growth per level, monster kills required per level, time per level, etc, that players never directly see but that influence the relationships between those values.

You should understand the mathematical relationships between the in-game values and the tuned values, and ideally set up formulas in something like an excel sheet, so that you can isolate exactly the variable you want to tune and not affect other things - or else you risk ending up with a “man in the shower” problem, where you tune one number, which causes an overshoot in a second system, when forces you to retune that system, which causes an effect on the first number, etc.

The biggest mistake I have found is that people often want to tune the values that players see, but these are often the least important values in the game! Oftentimes, it’s the “feel” values, things like “how many hits does it take to kill a monster at equal level? At one level above?” are the real questions, and people try to tune values like HP to realize those goals. Instead, I would recommend never tuning values like HP directly and instead setting your equations to allow you to directly change the “feel” values - to make those the knobs that you have to turn - and then letting your formulas spit out the in-game values for things like health and damage. Note that these references can get a little bit circular, and so you may need to arbitrarily set some value - for instance, health is often based on a player’s ability to deal damage * expected kill time, but a player’s ability to deal damage at a given level could just as well be definied from a monster’s expected HP. You may end up just deciding “A level 1 player will do 100 damage per second” or “A level 1 standard enemy will have 100 HP” and that will scale all of the numbers in your system. But from that point forward, you should only tune the individual “feel” values you want to hit directly, rather than tuning the player-visible values in a way that will have knock-on effects in other systems.

Lesson 3: Make Big Changes

This is a pretty common lesson shared by lots of system designers, but figured I’d share it here too - especially when you are doing early tuning, double or halve numbers. Don’t nudge values by 5-10%, because it’s too hard to see the changes and it takes you much longer to understand the effect your change is having. Additionally, it can save a ton of time. If you double a number and it doesn’t seem crazy, you just saved yourself a lot of time slowly nudging up to the doubled number. If it does seem crazy, you can try the halfway point between the doubled and the original value.

Lesson 4: Start with Math, End with Feel

Math, spreadsheets, etc. all make a great starting point for tuning, but never trust that math will produce a game that feels good. For one, your math may be wrong. There are probably variables you aren’t accounting for, especially in a game with any action-ey elements. Player skill is a thing. Math is super useful for establishing a baseline, but never, ever trust that your math is correct when playing the game is telling you something different. Additionally, math isn’t going to make your boss feel good, and late in the day, don’t be afraid to change things outside of your formulas to get the feel changes you want - but DO save those changes for late in the process, when you’re sure that your core feel variables (like your time to kill) aren’t likely to change. Otherwise, those big changes can completely overwrite or blow away your fine tuning changes.

Thoughts: Hyper Light Drifter

I just finished Hyper Light Drifter! I want to start actually putting down thoughts when I finish games and they are fresh in my memory, so here goes.

Warning: there will be minor spoilers. But there’s not a ton of story to spoil so I wouldn’t be too worried.

Overall

I really enjoyed the game. If your game’s premise is “Top Down Metroidvania + Intense Action Combat + Beautiful 2D Art” and you deliver at all (and HLD does), I will like your game. HLD delivers. I liked it a lot and would strongly recommend it to anyone who likes tough action games and exploration/Metroidvania games.

Highlights

• Level Design - The level design was just fantastic. Navigating the levels was easy, there were quite a few gorgeous, well placed vistas, the levels were designed to make your navigation abilities (dashing, chain dashing, etc.) super fun. Secrets were abundant and well telegraphed, and about halfway through I began to realize the language that the game uses for secrets (there is a little symbol the game uses in most places! Keep an eye open!).
  
  Additionally, it’s really impressive how the game made such thorough use of relatively few tools in enough varied ways to keep them interesting! There were very few one-off gimmicks in levels and the game never really broke its rules.
  
  The game also made great use of the Metroidvania trick of showing you things that you can’t get to yet, to pique your curiosity and help you understand the flow of the level without making it overly linear. Particularly, the doors that only open when you’ve collected ¾ pieces of the triforce for a given area (it’s a triforce okay) provide a great leading tool for the player without overly constraining them.
  
  Honestly this game is a master class in 2D top down level design.
• Art - I wouldn’t be surprised if this is what drove most people to the game. It’s what drove me to it! But the art is just gorgeous, the palette tasteful (and more important varied - each of the main areas has a very strong aesthetic that is very different from the others), the animation is punchy and expressive. Just a gorgeous game.
  
  I believe super strongly that  “art style > hi-tech graphics” and this is a stellar example of that.
• Music and Sound - The music is sparse and ambient for most of the game, which is why when it DOES kick in, it’s very intense and matches the emotion the game is trying to build quite well. When you hit an impressive vista, or a tough fight, and the music swells, it does exactly what great game music needs to do - works in harmony to make you feel what the game’s trying to express.
  
  The sounds is great on it’s own, as well, but also provides great gameplay feedback, which is something I felt other aspects of the game could have done better - but the sound nailed this.
• Standard Enemy Design - The bestiary in each of the areas felt extremely different, worked really well together, AND had a ton of personality! Their gameplay and art worked together fantastically as well - the swoopy bird guys mechanics instantly sold why I couldn’t slash them when they were flying, and led me to try to shoot them out of the air - when it worked, I was thrilled! The frog ninjas instantly read “frog ninja” which, besides being awesome, led me to think “i bet that frog’s gonna throw a shuriken” before he did, and that felt awesome!
  
  It’s pretty rare that you can spawn a bunch of enemies in a room, let their AI drive them, and get decent gameplay. These enemies are so well designed that it works.
• Atmosphere, Character and Mystery - I’ve felt like designers, especially narrative designers, can overemphasize the importance of the player understanding what is happening in the game world. Instead, I think it’s actually much more important that the player understands the big themes, the “flavor” of the world, and the details are actually often unimportant and boring - in fact, not knowing them, leaving them mysterious, are much more engaging than spelling them out. This is part of the magic of Dark Souls, Ico and Shadow of the Colossus, and Hyper Light Drifter really succeeds.
  
  Additionally, the decision to make the friendly NPCs animal people, and to have them tell little visual stories, was brilliant. It made me care about the world far, far more effectively than dialog would have.

Critiques

• The Bosses - The difficulty level of the boss fights felt pretty all over the place. The bird boss was a super easy one-shot, and the west boss was pretty darn difficult. That’s normally fine, but it didn’t mesh well with the overall area difficulty to produce a “standard path” - I found the west area’s standard enemies to be easier than the bird area’s, for instance.
  
  Also, I felt the bosses tended to highlight some of the control and feedback issues I’ll raise below.
• Controls - For the most part, the game controlled beautifully, felt fluid, smooth and precise. But a few issues really marred that:
• Dashing - The game has either a hidden cooldown, input lag, or just a bug with dashing. It felt like there was a cooldown potentially after 3 dashes in a row (talking about standard dashes here - not chain dashes) but it was very unclear what in particular triggered the cooldown, how long you needed to wait in between dashes to clear the cooldown, or really just why sometimes you’d press the dash button and nothing would happen.
• Hit Reacts - Hit reacts on players are fine. Long hit reacts are cool. But, it felt like you regained movement control of your character after a hit react before you regained the ability to dash - I’d need to really dig in to figure out what felt wrong here - but in general, I find that it’s clearer when there’s a very firm hierarchy of actions - e.g. you can always do action A if you can do action B. If I can dash while moving, and cancel attacks with dashes, I’m going to assume that any time I can move I should be able to dash. It didn’t feel that way - but I could have been wrong.
• Non-audio Feedback - While there were strong indicators when e.g. you got hit (including massive hit stop), some indicators felt missing - for example, after firing the shotgun, you have to cock it to fire again (your character automatically cocks it after a time, but other actions, like dashing, can delay your ability to cock it). How do you know if it’s cocked? Well, there’s a sound. That’s it, as far as I can tell. No animation, no UI indicator, nothing. For something as critical as when your buttons will work vs. do nothing, that’s not good.
• Perspective & Depth Perception - Overall the game did a great job with this, but because it uses an orthogonal projection (there’s no foreshortening) and because some enemies and objects are quite tall, trying to tell what I could and couldn’t walk “behind” was often kinda frustrating. There’s not a great solve for this IMO, but it’s one of the drawbacks of their otherwise super super cool art style.
• Visual Noise & Getting Lost - It was way too easy to lose yourself onscreen in chaotic firefights. Additionally, the visual they used for Dashes didn’t do enough to help situate the player onscreen AFTER the dash - I really needed to know where I ended up, and the visual did a better job of showing where I WAS then where I ended up. This problem was especially pronounced in the bird area, where some of the bird-man attacks used the same color palate as the drifter’s dash visuals.
• Minigames - The Soccer and Dash minigames were awful. Don’t ask or encourage players to engage in a repetitive stress inducing “repeat this thing 800 times” activity. Especially don’t reward it. Please. These things would have worked as cute little side activities (the 100 dash challenge was OK, the soccer game should have just been an easy little goof).
• RPG Progression - Overall I thought this worked well, but I did feel that the “big upgrades” (the sword and dash upgrades) shouldn’t have been priced the same as the “little upgrades” (the gun and health pack upgrades). The sword upgrades and dash upgrades were way more “fun” - it felt like the gun, bomb and health pack upgrades were the wrong choice - even if maybe they were pretty good gameplay-wise.
• Balance - The shotgun, IMO, was stupid overpowered on bosses and the “dodging through projectile” upgrade on the dash shouldn’t have refilled your ammo - the game should have done more to force you to use the sword on bosses more often.

Game Dev Lessons: Neverwinter Nights 2

I thought it would be a fun exercise to reflect back on some of the games I’ve worked on and think about some things that the experience taught me, or that in retrospect had interesting things to learn. To keep it focused, I’m going to stick to 5 things, but I may do more in the future!

Context: I was the first QA tester at Obsidian on Neverwinter Nights 2, eventually became lead tester when the QA team expanded, and by the end of the project moved into production as an assistant producer. So these aren’t really design lessons so much, though they are development lessons!

---

• Teach Producers to do stuff - Producers are support folks, true. But producers should learn some aspects of your tools and development process for two important reasons:
• Understanding how people do their jobs makes you a better producer and helps you make better decisions.
• Producers being able to pick up the slack in implementation can be a huge help in the 11th hour. On NWN2, the executive producer and I took over most of the implementation of the front-end GUI in XML, and our ability to do that meant that other, much more challenging aspects of the UI, were able to be implemented. Without us handling that, the people who were more capable to do the heavy lifting couldn’t have dedicated their time to more important things.
• Being a Lead is hard - Managing people is really, really hard. This is where I personally came face to face with the Peter principle - the idea that people get promoted until they hit a job they are incapable of doing. In the game industry, you can learn that when you promote your best programmer to Lead Programmer, you lose your best programmer and get a mediocre lead in his place.
  
  In my case, I went from a skilled, experienced tester to the manager of a team of almost 20 people, many of whom had no QA experience, and I had basically no training or management experience. That was hard and I did not do a very good job. I feel bad for the testers that worked under me.
  
  I don’t know that there was a better option in my case, but it definitely made me respect the idea that there should be a path for promotion for folks who excel at their job but don’t make good managers, or who don’t have the managerial training or experience to manage a large team.
• Copy the right things - After I became a producer, I was assigned to work on the UI. Because we didn’t have a real UI designer, and we were getting very negative feedback on the UI, I was assigned to work with engineering to see what we could do to improve things in the time we had.
  
  The first thing I did? Open WoW and figure out why dragging buttons to different hotbar slots felt fine in WoW and was awful in our game. It felt extremely finicky, and you’d drag an icon went you meant to use it all the time.
  
  Turns out, there’s a dead zone in WoW - about 50% of the size of the icon - outside of which you have to drag your cursor with the button held down in order to “pick up” the icon. Windows has this, too, but it’s much smaller (and clicking and dragging feel worse in Windows than in WoW for this reason IMO). This dead zone makes the difference between a click and drag and a click to use the ability much more pronounced, and stealing it fixed the problem.
  
  When you have a problem that is tricky to solve, you should figure out the “state of the art” solution before you try to roll your own. Copying is okay, as long as you copy the right things.
• Feedback is King - There were major feedback problems with NWN2 before ship (and after ship, but before ship is was far worse). Because NWN2 simulates D&D, and characters are running turn timers every X seconds, players would often select an action (like casting a spell) and the characters wouldn’t actually do anything until their next round came up. The game felt broken as a result because you would click to cast a spell, and not tell whether the game ate your input or whether you were just waiting for the next turn.
  
  The solution ended up being to add a UI element that shows the next queued action - your queued action icon would change when you gave a new command, which was all the information that you needed to know that the game did hear you and was just waiting for your next turn.
  
  The gameplay feedback that we got after implementing this was massively more positive - and it was the first of many times I learned that UI, sound, and animation feedback in response to actions is as if not more important than issues like game balance, cool loot, and great story.
• Nobody Reads Design Docs - This was the first time I learned another lesson that would be repeated over and over again - if a design doc is more than a page or two, nobody will read it. It can be useful for yourself to catalog what you were thinking, and you can send it to a publisher to sate their hunger for milestone deliverables.
  
  But almost nobody actually reads docs, whether to comb through them to distill a list of actual actionable, or to get all the implementation details you’ve put in there - you still have to go explain and discuss everything you want with them anyways.
  
  Maybe your experiences are different, but this was the first time of many that I learned that generating a doc to “throw over the wall” at implementers - or to get meaningful feedback on the possibility of implementing the documented content - doesn’t work.

Engineer Anxiety vs. Designer Freedom

Update: There were some formatting issues that caused this to copy over wrong from my old blog and it was missing some words. Fixed now!

Every team has its own interdepartmental relationships - some more dramatic than others - but something that has been an issue on every project I’ve worked on has been the way that Designer desire for implementation freedom, expressive tools, and power has conflicted with Engineer anxiety over what the hell Design is doing.

First, I want to say that I am ultimately sympathetic with the Engineers in these situations.

Engineers (when working most effectively) build systems, not content. And those systems have to be built to support the content before the content is built - meaning that there’s an inherent degree to which Engineers on games are never really sure what exact spec they’re building to.

• Design, on the other hand, has the freedom to mold and adapt their Designs after they’ve got the systems. Engineers can do that, too, but it risks messing up all the other stuff Design’s already built on their system, so it’s always an extremely risky, dangerous proposition.

Engineers get stuck holding the bag when Design’s shit breaks.

Engineers understand the guts underneath the abstractions they are presenting to Design, and know just how deep we can dig ourselves when those abstractions leak (super good article on leaky abstractions over at Joel on Software).

BUT I also know that there’s been pretty much a direct correlation between the quality of the games I’ve worked on and the extent to which the technology allowed the designers to directly implement their vision through powerful tools vs. being constrained by limited systems.

If I knew the absolute solution to this I’d be the most successful game director ever, not a designer. But I do know some things that have helped:

• Tons and tons of direct communication back and forth between Design and Engineering. The more a good Engineering team knows, the LESS they worry. One of the awesome design principles at Blizzard is to avoid the grand reveal - basically don’t work in secret and then show everyone else your work, after you’ve finished, with a big “tada!”. This is important among other designers, but it’s ALSO hugely important between the departments, and especially with engineering. They can think about how to make what you want to do work much better if they know what you want to do earlier.
• Engineers need to take the time to explain the “why” to designers, not just the “what”. One of the worst things you can tell a designer is “Don’t do that. That’s expensive.” The end result of that admonishment is usually the designer tries it out, sees that the framerate is fine, and assumes that you’re just being a worrywart engineer again.
  
  Instead, if you say (for example), “Overlapping collision is expensive because when the game has to do a line of sight check, the overlapping geometry makes the collision checks much more complex”, you give Design something to work with. A fundamental requirement of design is to work with what you’re given to come up with solutions - and given that information, the designer may say, “Oh! Well, it actually isn’t important that the collision matches so closely to the object. If we really simplify the collision geometry, can that help mitigate the problem?” Again, just as an example.
  
  Design doesn’t want to make shit run bad! It’s just that we rarely understand the complexities of why the stuff we makes runs like crap unless you tell us. And once we know the why, we can make good decisions in the future.
• Engineers should make systems, not content. Engineering time is crazy valuable. Designer time is less valuable. Good engineering work is elegant, robust and built to handle many cases and situations. Design work is by nature mostly one-off. Subtle bugs often never show up in design content (unless you’re making an MMO where that content is going to live for 9 years, but the general point remains).
  
  The end result being that Engineers should generally specialize as force multipliers by making systems that are bulletproofed, extensible, and used many times by many designers. Leave the specifics of what a given AI does, how the UI controls are laid out, etc. to designers. Engineers shouldn’t have to spend time touching that shit.
• Believe in Tech Designers - Engineers should find allies on the design team, who are either technically minded or have some sort of CS/Programming/Engineering background, and work with them to communicate things to design. Some of the best, most efficient teams I’ve worked on have leveraged highly technical designers to work in-between code and content to make frameworks for other designers.
  
  I’ll use an example from a game that I worked on for a while that was cancelled. It was going to have a really neat strategic layer that was mostly paper-designed out, and because of the team culture on that project was going to be 100% implemented in code. One of the most skilled gameplay programmers on the team worked for at least a month, maybe more on the system, only to be taken off of it to work on more critical features.
  
  Ultimately, the strategic feature never got implemented and the game was cancelled before any more work was done on it. Had that time been spent instead on implementing script features,  extensible, data-driven systems, etc. such that technical designers could have used those basic features to implement the specifics of the strategic game, the engineer work would likely have been reusable to make other aspects of the game better.
• Designers: Love the Design, not the Implementation. Sometimes, a designer’s implementation is good enough for 80%, but it needs some code refactoring and replacing design implementation with code to really shine. As long as the design is established and proven in prototype, feel free to get advice from code on how they can make what you’re doing more efficient and bulletproof.
• Designers: Learn from Engineers. Learn to read C/C++ at a super basic level, and sit with Engineers when they are debugging things. Learn the specifics of how the code actually works in sections that are critical to what you work on. This can be hugely helpful and really demystifies the kinds of bugs where everything looks like you set it up right in the editor but it just doesn’t work in-game.

Anyways, again, not perfect solutions but some things that have worked for me. Also, as a general rule, I’ve found that the best Engineers I’ve worked with want to nurture and enable designer creativity, and the best designers want to make things that are technically sound and are curious and interested in how the game actually works. So the departments are at their best when they are working together, not acting as stern parent and rebellious child.

What is Gameplay?

My personal theory of fun centers around gameplay. I don’t think that gameplay is the only reason why we play games, and I certainly don’t think it’s the only reason why we enjoy interactive or digital media. However, it is

the clear point of distinction between games and other forms of media (books, movies, interactive movies), and it’s an aspect of games that is the primary responsibility of game designers. And because that’s my job, I selfishly consider it a  fundamental aspect of fun.

So, what is gameplay?

First, I think it’s important to define clearly what a game is, and to differentiate it from other game-like things. To me, the critical aspects of a game are:

• There are two types of rules: first, a series of actions are defined as valid for players. These can be presented as the valid inputs allowed to players in a video game, or as a list of things you can’t do in a sport, or a list of how each piece moves in a board game.
  
  Second, you have rules that determine how the game state is updated based on the cumulative actions of players. These rules can be relatively simple (Chess) or very complex (American Football).

Given that definition of a game, I would then define gameplay as the feedback loop between the actions of one or more players and the rules, with each player (or the only player, in the case of a single-player game) attempting to make choices that optimize their outcome in whatever success metric the game uses. That feedback loop relies on players understanding the actions available and forecasting the effects of actions to determine which will be most or least successful.

I think this definition is helpful because it starts to take apart things that have traditionally been a part of games (e.g. Puzzles) and sets them apart from core gameplay. Most puzzles in games don’t really rely on gameplay - when you’re trying to find the right item to open a door in an adventure game, there isn’t really a ruleset to rely on or a gamestate to update. If there is, it’s so simplistic (Actions: each item in your inventory! Rules: binary success or failure based on which item you picked!) that the “gameplay” becomes trivial. Or, the results of the actions are unclear, and the goal is to figure out which action is correct, not to optimize the results across many different valid options.

Raid Boss Dissection: FFXIV, Thordan Extreme

Because I am obviously much closer to the development process on WoW, I don’t really get the opportunity to dissect our fights as a player in the same way that I do for FFXIV. So I thought it’d be a fun exercise, and might be interesting for people to read, to have an MMO Raid Boss designer’s PoV into the design of another game’s raid boss.

Note this is pretty casual and I didn’t spend a ton of time going into depth and preparing information for this, so if you do find this interesting let me know and I may spend more time on things like this in the future. Also please comment if you have any questions/arguments/corrections/etc!

Fight Info

First, here’s a link to a video of the encounter:

https://www.youtube.com/watch?v=HuDTxp2iedg

Here’s a link to a video guide, which explains many of the mechanics in detail (with lots of bad puns):

https://www.youtube.com/watch?v=-pZ5MfWpOTw

Next, some things, if you haven’t played FFXIV but have played WoW, that you should know:

• All “real” raids in FFXIV are 8 players, and groups are typically 2 Tanks, 2 Healers, 4 DPS. There is also a type of content where three raids join together in an instance, but this is generally for more casual content, sort of parallel to WoW’s LFR, but with only one difficulty.
• Personal defensive cooldowns, and especially external healer cooldowns, are pretty minimal in FFXIV. Overall, players are substantially weaker in FFXIV than they are in WoW - or, maybe more accurately, players have much less opportunity to use abilities to counteract mechanics.
• FFXIV has no dungeon journal, very few boss emotes, no support for UI addons, and even damage meters require a 3rd party program that is technically against the ToS.
• Players can be freely resurrected in the fight when they die, but suffer a stacking -max health and damage done debuff for one minute after being resurrected. Additionally, the resurrection spells have exceedingly long cast times (8s, interrupted by moving) and while you can use Swiftcast to raise someone instantly(which makes it instant), Swiftcast is on a 60s cooldown.

As a quick breakdown, here’s the general fight structure. Note the timing is based on the first video linked, DPS can change it somewhat:

• 0:00 - 1:40 : Introduction to Fight Mechanics
• 1:50 - 2:05: Dance 1 - Chains, Area Denial, Soak Towers,
• 2:05 - 2:28: Sir Zephirin: DPS Check/Mercy Rule 1
• 2:28 - 2:38: Dodging “divebombs”, moving in to position to fight the brothers
• 2:38 - 4:08: The brothers + dragoon fall off damage
• 4:08 - 4:28: Dance 2 - Ice Bombs, Charges, Growing Area Denial + Knockback
• 4:28 - 5:14: Dance 3 (World in Flames + Player targeted missiles) + Burndown
• 5:14 - 5:51: ULTIMATE ATTACCCCKKKKK!!!! (plus little breather)
• 5:51 - 6:52: Dance 4 - Healer Stun + Line Meteor + Tank Buster + Look Away + Raid Damage
• 6:52 - 7:41: Dance 5 - Soak Towers + Look Away + World In Flames, Growing Area Denial, Knockback + Meteor
• 7:41 - 8:30: Dance 6 - Lightning + Divebomb + Charge + Dragoon Fall Off + Meteor
• 8:30 - 9:27: Dance 7 - Chains + Large Player Targeted Area Denial + Player Targeted Missiles + Ice Bombs + Pie Wedges
• Rest of Fight: Burndown w/ Ramping AoE Damage

Wow! That looks like a whole lot of junk! At first, when I was looking at guides to this fight, it looked a lot more like “mechanics vomit” than “one of the most elegantly designed and well tuned boss fights I’ve seen”. But, first appearances are deceiving - it really is an incredible boss fight.

How the hell does it work?

Consistent Visual Language

First, and this is crucial - every mechanic on the fight has a distinct visual tell - no mechanics lack visual tells, and no mechanics’ visual tells are similar.

For instance, this ring is the generic “you’re being targeted with something that’s going to go off soon” visual:

This visual is only used for two mechanics on the fight, and these are very simple avoidance mechanics - this attack, and the pie wedge slash that he uses in the beginning of the fight and in Dance 7.

The other attacks in the fight are quite distinct visually. For example, this means you are being targeted by a meteor:

This means you are being targeted by a dragoon for Falloff damage:

And so on. It would be easy for a game to try to enforce a single “you are being targeted by an effect” mechanic, and in so doing create something that is very confusing and hard to parse. Even though the huge variety of targeting visuals in the fight may seem at first overwhelming, as you progress and learn the mechanics, you appreciate being able to instantly associate a visual with a very specific game mechanic. Which leads to…

Memory, Re-use, and Clarity of Purpose

Probably the single greatest aspect of the fight: while there are a large number of phases, there are not as many mechanics as it looks at first, especially considering you’ve seen many of these in the game before.

Looking through the fight I counted 7 new mechanics, 2 of which are very simple avoidance mechanics, 6 mechanics that you’ve encountered before with different visuals, and 8 mechanics you’ve seen 100% identically before.

Now, some players will make the argument that this is lazy re-use, but on the contrary - the mechanics exist to elicit specific reactions from the players, and the quicker you can get players to understand what the intended response is, the more easily you can ask them to do complex things in reaction to combinations of mechanics.

Additionally, because they are willing to accept a large number of mechanics, each mechanic can be quite simple - a single problem with a single solution. This increases clarity of purpose, and the likelihood that players will understand what is being asked of them, as well as the likelihood that the designed solution is the solution that players will use.

A common pitfall in attempting to use too few mechanics, given a certain level of complexity you are trying to achieve, is that each mechanic has to shoulder a much larger portion of the complexity burden of the fight. This often ends up with an individual mechanic that has several elements - multiple effects, bizarre fail conditions, etc. or, fails to achieve its intended gameplay because of some gap in the design of the ability.

As a designer, each mechanic in a fight is both a tool to create interesting gameplay, and a type of problem you are asking your player to solve. While it is fun to think up crazy new mechanics, re-use has major advantages in that you can much more quickly get to the gameplay you want without having to re-teach players the mechanic.

Organic Complexity & Player vs. Designer Fun

It’s fun to design new mechanics. But something that’s more fun to design isn’t necessarily more fun to play. Sometimes, clever combinations of existing mechanics can be just as interesting as a new mechanic.

For example, a trick that floored me when I saw it in the fight was very simple: target a meteor at a player, and then knock all the player back in a common direction from a single point shortly before the meteor detonates. Additionally, hitting the wall will kill you. Each of those mechanics is incredibly simple - seen in numerous boss fights in MMOs. But the combination requires a very different reaction - typically, your instinct as a player after having been knocked back is to run as quickly as possible back towards the boss. But if you do that, then the meteor doesn’t hit enough people. Your instinct when soaking a meteor is to move as little as possible to try to soak the meteor - but if you do that, you get knocked in a different direction from the clump, making soaking very difficult. You intuit that you need to prestack near the center to get knocked in the same direction, and then stand still to make sure you soak the meteor properly.

This mechanic doesn’t necessarily make a designer feel super smart when designing it. You don’t get to give your timing of 2 mechanics a special name and unique visual. But overcoming that combination of mechanics makes the

player

feel smart. Obviously you’ve designed your solution, but because the complexity originates from organic combinations of simple mechanics, the player feels like they’ve come up with the solution rather than just finding the bespoke solution that the oh-so-clever designer intended in the first place.

Lawd Have Mercy

A design value we talk about a lot on the WoW encounter design team is minimizing the time between when the player made the mistake that will kill them, and when they see that failure. We often talk about the problem with the player making a mistake at two minutes into a fight that causes them to wipe to the berserk timer, eight minutes later. This is, generally speaking, very frustrating and not fun.

The concept is similar to mercy rules in sports - points where, when one team or player gets ahead by enough, they win instantly without having to play out the rest of the match.

This problem is magnified in FFXIV because, since players can resurrect with a damage down debuff, often times you can limp through a fight, constantly losing people, only to wipe at the very end to the berserk timer.

Thordan uses two “mercy rule” strategies to end fights early when players aren’t performing well enough:

• Heavy unavoidable party-wide damage shortly after bursts of avoidable damage, intended to finish off the party when they fail a large number of mechanics.
• Short but fairly forgiving DPS checks through the fight that you are unlikely to pass with dead players.

Often these two are combined - for instance, the two Brothers phase of the Thordan fight deals heavy damage to individual players via the Dragoon Dives - but these also deal falloff damage. The Brothers themselves also have a large unavoidable AoE. Done correctly, healers have just enough time to heal the Dived players with a single target heal, and top off the party with an AoE, before the group damage hits. If the players targeted by Dragoon Dives do not move away from the group, then while the damage they take doesn’t change, the fact that the rest of the party also took heavy damage means that the AoE heals are not enough to save the party from the unavoidable damage. And, the brothers’ unavoidable AoE ramps in damage with each cast - ensuring that, at some point, you will wipe if you fail the mechanics badly enough. This is preferable to letting the player limp through the phase with constant damage, but wiping minutes later to a berserk timer.

Peaks and Valleys

From 5:17 to 5:50 - a full 33 seconds - there is essentially nothing happening in the encounter.

This is something that is VERY different between WoW and FFXIV, and that I know is very controversial when I talk to people about their boss fights. But personally, I really appreciate that their game will follow bursts of very strict mechanics checks (in this case, the past two minutes of dodging mechanics + dps check) with a rest period - a chance for healers to top everyone off, to raise players who have died, to take a breath. It makes the level of tension of the mechanical bursts acceptable and avoids overly stressing players out. It feels like a reward in itself - you did good, take a little break. It doesn’t need to mean you do nothing, either - for instance, they often include burndowns at the end of their fights that are mechanically very simple, but are essentially healing and DPS checks. If you made it through everything else, and you can do a decent amount of DPS, you win. These can be more or less tightly tuned - Thordan’s is very loose - but that break, to just sit back and do your rotation - feels hard earned after 8 minutes of dancing around mechanics combinations.

Additionally, they often use those moments to sell how badass the boss is with a crazy animation, which helps. It makes you feel incredibly strong that you can take out this creature that can blow up the whole world around you.

Anyways…

Hopefully this gives some insight into the thought process of designing a raid boss. I’m sure it could be more interesting or better written, but I figured just writing something beats giving up on it halfway. Please leave feedback if you liked/didn’t like/would want more!