And every few months, a handful of people who’ve actually done the work on this have to explain why treating social media as an absolute source of truth is a mistake.

Here is a short and incomplete list of the reasons why doing what you think social media says is not the free win you think it is.

Sampling Bias

You’re listening in the least honest location

What people say is affected by who is listening.

People who do and say things on social media are doing so for social interaction, and these interactions are the driving reward behind it. We know that people will repeat opinions they don’t even hold so long as they believe that other people believe they are correct. We also know that people shy away from opinions that receive social punishment. The 2026 environment of gaming discourse on Reddit/social sense is dominated by Being Right About Games where the goal is not to discuss but to Know Things. This creates a problem, because feedback should be a personal experience, but instead, you’re rewarded for being Right and punished for being Wrong. There is no such thing as a wrong personal experience, so as long as it’s actually yours.

That’s where it gets tricky, because in that social space, content creator opinions get repeated by their fans as correct as part of a desire to affirm themselves as Knowing Things, and to affirm their creators as knowledgeable, despite the creator’s opinions rarely actually relating to the player at all, either through Elo or consumption habits. Of course a Challenger-ranked player is affected differently by a small change than a Bronze player. Of course someone who plays games on stream 8 hours a day runs out of content faster than someone who plays an hour a night.

Groupthink runs rampant in these kinds of communities once they convince themselves something is true. Remember the origin of “We did it, reddit”? A bunch of redditors convinced themselves they’d found the Boston Marathon bomber, and went after some random guy, who it turns out, killed himself.

Social media perspective differs per subject

So now everyone thinks they’re right because everyone agrees on a particular topic.

…until you bring algorithms into play, which divide opinions into clusters. You end up with multiple clusters of players on a social media site, all of whom believe their opinion is the one that’s universally held, because the software is specifically designed to feed you more of the opinions you want to see.

The things you believe are “universal” may very well just be the algorithm working as intended and showing you things you like. Your Twitter feed is not even representative of Twitter as a whole, let alone the player base.

The people you’re listening to aren’t even your players

Once something is being discussed in public, people get social rewards for discussing it and saying the right opinions. A staggering number of people will chime in about games they have never even played and repeat an opinion they believe to be Right, because again, Being Right About Games is what matters.

Let me be extremely clear about this. People who have never played your game will give you feedback about it.

This extends into Steam review bombing, where once a Correct Opinion has been formed, people who haven’t played the game will rush to Steam to punish it, again, despite not having actually played it. The feedback they provide is not about the game, it’s about an opinion they believe to be correct based on the crowd.

Even the ones that are your players are a minority of your real players

Every live service game learns this over time. League of Legends, Overwatch, Apex Legends, Dauntless… we all chased Reddit’s approval at the direction of product managers, then watched our player counts crumble. The stark reality is that only a tiny fraction of ANY player base is on social media, and the ones that provide feedback aren’t a representative sample of the overall player base. Even if you get past this selection bias, people complain after only slightly bad experiences, but an experience generally has to be great in order for someone to leave positive feedback, so you aren’t even getting a representative sample of the opinions of the group you are seeing. Treating what you hear there as a global consensus is a recipe to crater your game, and every game that tries this learns the hard way.

Self-reporting Bias

When you share an opinion or give feedback, you are telling a story about yourself. People want to share a story that they like, and that makes them feel skilled, or knowledgeable. They do not write the honest objective truth about themselves into these things. They write the version that they wish they were. We know this because we’ve surveyed a lot of players over the years and then compared their answers with their actual behavior data, and the two rarely have anything in common.

Whenever you give someone the opportunity to tell you a story, they’re telling you a story that reflects on them the way they want to be seen, and you need to take this into account when deciding what to take away from it.

Frequently wrong about themselves

Sure, there are complex psychological issues at play, but surely people can at least be trusted to tell you about themselves, right? Unfortunately not.

A particular AAA developer I know of once sent surveys to 1000 players asking them which game they had played the most, then compared it with the data of what they had actually played. Not a single one answered correctly.

Zero out of one thousand players could remember their own habits enough to tell which game they’d played the most. Player answers were so consistently wildly wrong that the team involved thought that their data must have been corrupted. Upon validating that it was in fact accurate, they went back to the players and told them what their actual most played games were, and every single one said something along the lines of “OH! Right. Well, that makes sense”.

When people tell you things they’re really telling you the stories they tell themselves about themselves, and those stories may not have anything at all to do with reality.

Experiential projection

If they can’t speak accurately about what they have experienced, how are they supposed to guess how they’ll feel about things they haven’t?

Turns out, people are terrible at telling how they’ll feel about something they haven’t experienced. This seems like a pretty obvious thing to say, but it goes wrong easily, because researchers often tend to treat a question about “how a player feels about something they’ve experienced” the same as “how they think they might feel about something new”.

This is a trap, because people who are offered a new option often fixate on what they would be losing if the old option went away, and because they haven’t experienced the benefits of the new one yet, they can’t actually place those two as equal. Those kinds of questions are great research for discovering what players are afraid of, not what they actually want. The classic case of this is The Guy Who Tried To Ruin Halo 2.

In the lead up to Halo 2, players were asked what they think about queueing up instead of using fixed servers. Results were overwhelmingly negative, because they focused on losing the servers they were used to, but couldn’t preempt the benefit they’d receive from being able to queue, so they answered based on what they thought they’d lose, and said they didn’t want it. When Trueskill queue launched with the game, it was a huge success and it was so influential that it changed the landscape of online gaming forever.

It’s staggeringly easy to completely misinterpret what players are telling you if you’re not paying close to attention to the conditions under which you’ve asked.

Subject matter expertise

There was a time where in order to be a PC gamer, you needed to have a good grasp on technology. That time has passed. Most players have no expertise in computers or games. Unfortunately, they tend to believe that they do, and they have no idea that it isn’t true. With their whole chests, they will declare you stupid for not implementing their “easy solution” to a problem they believe exists in a game, and then when you look further you discover something that obviously, fundamentally cannot work. There isn’t a way around this.

I once saw a player in the top 0.5% of League ranks say that the fix for tanks doing too much damage was to put -10% damage output on Tank Mythic items.

Mythic items were a type of item in League of Legends. You could only have one “Mythic” item, and it would give extra stats or behaviors to every additional completed item. Tank mythics would give additional health or resistances, mage mythics would give extra ability power, etc. They have since been deprecated.

This could never have worked for many reasons, listed in the thread, but the short version is “any change of this nature would create more problems without actually solving the problem it was trying to”. Trying to make tanks less of a threat to glass cannon characters is a complicated problem, exacerbated by the fact that “doing damage to glass cannons” is actually the primary gameplay purpose of many LoL tanks, so you are also trying not to make an entire class useless. It is not actually a simple problem, but if you never throw your rock in the water, you never have to think about the splash.

People also make grand assertions about how rank, MMR and matchmaking should work, but those are mathematical systems, and when people approach them without considering the mathematics involved, they make suggestions that do not and cannot work. Most of the ones I’ve seen make things objectively, provably worse, which again, you can prove with math, if you do the math and don’t just wing it. But as long as people believe they understand the problem and the tools, they’re going to tell you about it.

Problem identification

Players are excellent at telling when there’s a problem. They’re useless at knowing how to fix it. Never mistake one for the other.

Secondarily, if your solution to basically anything seems simple, you can be assured that every other person on the team has also thought of this, because it is very simple. If you ever find yourself saying “I don’t understand why they don’t just [thing]” then your answer is right there: you don’t understand the problem.

Instead of looking at something and deciding that people must be stupid to have done this, consider the thing you are seeing may not have been the desired result, and ask yourself what context might possibly exist that makes what you’re seeing the least bad option.

It doesn’t occur to most players that result they see might not have been a compromise, but it’s actually incredibly common for things in games to work out differently than how they were planned. On every single game that has ever been made, either tech debt, design debt, timing, capitalism, or all of the above has forced developers to make something than they intended.

You will find yourself right more often than wrong if you assume that everyone involved in a situation is smart and good at their job, and had no better alternative.

Combinations of the above

When you start to combine the problems above, you can see pretty clearly that when you’re taking feedback from social media, you need to temper what you read, because:

• you’re sampling the wrong people

• and they’re making bad suggestions

• they’re making those suggestions based on things that aren’t even real

• and that they likely don’t understand what they’re asking for

You should definitely listen to players but you need to do so with intention, in deliberate ways, and then use their actual in-game behaviors and purchasing behaviors to supplement the things they told you. Every player will make suggestions they believe will benefit them, but it’s not their job to find solutions, it’s yours. Your job is to listen to their problems, then identify solutions that benefit the whole system, not just the ones quote tweeting Drew Levin.

Remember: “what people say” is data, not fact. It is a story they are telling you. That story has value, but only if you don’t blindly interpret it as canonical truth. It should be considered along side all other data.

The Skill-based matchmaking example

SBMM has been a community sticking point in the COD community for a long time, for a lot of reasons ranging from “content creators want highlight reels” to “people making up conspiracy theories” and finally settling in “no matter what we do to matchmaking, nothing will make it be 2007 again, the community has been playing for 20+ years now”.

The goal of SBMM is to make fair matches that either team has a reasonable chance of winning. The community claimed to not want this, so as an experiment, Activision slightly reduced the weight of ‘skill’ as a matchmaking input.

Almost immediately, unfair unbalanced one-sided matches went up, people started quitting mid-match way more often, and then ultimately started quitting the game forever significantly more. The data was astoundingly clear that all but the top 10% of players hemorrhaged and quit excessively under these conditions.

The issue is, when you tell people this, they all want to think they’re in the top 10%, so it wouldn’t affect them. While this isn’t even true on it’s face for most players, the second order effect is that when players not in the top 10% quit, players who were previously in the top 10% fall out of the top 10%, and then also start quitting. It is a slowly recursive quitting cycle that causes people from 90% of your player base to quit more, until eventually you have no more players.

This is exactly what happened when XDefiant launched on the promise of NO skill-based matchmaking. Initially, people praised the variability in the match quality (this is a legitimate reason to detune SBMM, as noted by Samy Duc and Christophe Pierce in their GDC presentation on Apex Legends matchmaking), and it received generally good reviews and player feedback. However, as time passed and the player stories gave way to reality, people started to quit in exactly the manner described by the Activision research, and they slowly bled off players until eventually the game was shut down.

Media amplifies all of the above

Publishing media and content creators heavily monitor social media as a sentiment source because it’s public and easy to get clickable content from. This causes them to report on the things that people are saying on social, which then reinforces to their viewers and readers that these ideas are the objective truth, which makes more content creators and media post about the ideas, and before you know it, something that was just a guess is treated as a colloquially known truth. It doesn’t matter what the reality is, so long as people can point to something to justify their opinion and be Right About Games.

And remember, we’re dealing with something subjective. Both traditional media and content creators are incentivized to take the most inflammatory, controversial path they can, becausae that gets clicks. It’s in their best interests to get people angrily sharing their articles and videos. No-one goes viral for a nuanced and balanced take that explains everything without a bad guy. They’re never going to try to look for a truth to understand because they’re incentivized not to.

It’s difficult to make people understand something when their livelihood depends on them not understanding it. If the devs are stupid then players have someone to get mad at, and they get to feel like they’d be really good at being a developer themselves. The content paints a picture that lets everyone tell a story about themselves that feels good, and clicks will flow.

These opinions will pass back and forth from audience to creator, and once the snake starts eating its own tail, the thing someone made up will be repeated forever to the point where players are incredulous if you question it.

Surely the truth comes out eventually?

Generally speaking, no. Player opinions on design, marketing, operations, etc won’t ever actually be tested, and because all of these opinions exist in a frictionless vacuum, they get to remain pristine and untouched. It’s easy for someone to say ‘-10% on Tank Mythics’ because they will never have to make a balance change or deal with the effects of their ideas, and so they’ll get to believe them indefinitely.

In the XDefiant/COD SBMM case we can even have mathematical proof that matching on skill provides a better experience, and that proof can be echoed by every matchmaking study ever done across every studio that ever made a PvP game, but some players will keep believing otherwise because they’ll either outright reject the data because it contradicts something they feel special for knowing, or they’ll argue for it anyway because that’s what high Elo players do, and they want to feel like they’re high Elo.

So how can we try to be more right?

The data you have about player behavior is probably correct, but remember: the story you tell about that data is the part you’re creating. Statistics are just numbers. The words are yours, and how you interpret the numbers is everything.

The real question you need to ask yourself is this:

Are you prepared to bet 8 figures, the jobs of all your friends, and four years of your life on being right?

The terrifying reality is that most game ideas seem good until they’re actually tested, and the appeal of spectating is that nothing you do will ever be scrutinized by players, so you never have to find out that you don’t know what you’re doing. Being more right involves exposing yourself to that failure, because game design is not knowing, it’s problem solving. It’s very easy to look at anything that didn’t work in hindsight and say “well they should have known” but every car that’s ever crashed was driving just fine until it wasn’t, and when you’re travelling at 60mph you can’t always bleed off that speed and stop safely.

That sucks, but it’s the reality of the industry, and all any of us can do is do our best work, theorycraft, problem solve, playtest, iterate, and hope that an insane hate mob determined to destroy what we’ve created doesn’t descend on us because of which trailer spot we occupied. We all try to make something we love that we think players will want, and we hope it works out.

So how do we actually know what players want?

The reality is that you do actually have to listen to all of the data you have available, and that data includes social media, but the important missing step is that all of that data must be viewed IN CONTEXT.

With the correct context, every bit of data can tell a true story about your game, but without it, you can take the entire wrong meaning away from it. Numbers don’t lie, but the stories people tell about numbers do, so be mindful and deliberate about the stories you tell and try to think through the human context behind everything you’re measuring.

And finally, if there’s ever a conflict between what people say and what they do, believe their actions. People say things that aren’t true all the time, but the way they use buttons that say Play Now and Uninstall tell their ultimate truth.

Until next time.

// for those we have lost
// for those we can yet save

The instant that idea forms, the bounds of what it might become feel endless. As you design, ideate, and choose, the space begins to contract and take shape into something not quite so formless, and a meaningful possibility space is drawn. The number of possibilities shrinks from something unknowable to something that fits in a particular area, in a particular shape.

But as you start to fill in the details and explore the space, the number of possibilities begins to grow again. You learn about your space you’re mapping, and with that knowledge, you start widening the scope of what might be. The potential grows, and it keeps growing... until one day, it stops.

Through either choices you’ve agreed to, budget, market forces, or all of the above, choosing what your game is forces you to also choose what it isn’t. The possibility space begins to contract. Edge by edge, the space where your game might be is refined and defined like marble becoming a statue. The cuts become more inevitable, each decision excluding possibilities it’s incompatible with. As we settle on what we must have, we inherently define what we cannot have and must not have, and we bury those possibilities. When we spend our time, the amount of time we have left dictates what we cannot spend the rest on. Eventually, the possibility space that began infinite has a definite singular form.

When you start a game, it can become anything.

When you finish, it is precisely one thing.

To finish is to mourn the death of infinite possibilities, and celebrate the birth of one new thing.

That is our Ambrosia Project, and today we celebrate the birth of Ambrosia Sky.

Available now on Steam and Epic Games Store.

// for those we have lost
// for those we can yet save

I won’t regale you with tales I couldn’t prove in a courtroom, but I will say that I quit very soon after getting my permanent residence in Canada. I’m sure you can imagine how being an immigrant on a work permit might be a source of vulnerability in an employment conflict.

I mention this because today I’m here to talk to you about recovery, and in order to do that I need to tell the story of how I broke, the hole I found myself buried in, and how I dug myself out.

Last time, on LBT

The original article went through all the different ways in which stress, trauma, conflict, thrash, crunch, nervous system activation, lack of psychological safety, and other byproducts of bad leadership take their toll on the body, the mind, and the emotions. A lot of people reached out to me to thank me or vent the flood of feelings they’d been hit with from finally having words to describe what they were experiencing. This felt like success to me since the point of the article was to help people understand what was happening to them, but it received criticism from some — including Dr. Alok Kanojia aka “Dr. K” of HealthyGamer.GG — that it really didn’t really offer any solutions.

In truth, I didn’t cover the solution space because I don’t believe there is an effective universal approach to fixing the kind of damage you get when a game studio fucks you up. I still felt broken, so how could I help anyone fix themselves when I couldn’t fix myself? We know there are things that help in general, and you’ve all heard those a thousand times. Eat healthy, rest, exercise, blah blah blah. Those things are never going to hurt, but they can’t actually do anything on their own. Rest isn’t relaxing when you’re in a C-PTSD hole and can’t stop bouncing your legs on the balls of your feet. Exercise can technically help the body but even getting to exercise in the first place may be impossible, and it might not even help if you just spend the whole time thinking about work.

At the end of the article, I offered hope and posited that if there was a key to healing, it depended on redefining your relationship with the things that hurt you. And god damn, do I hate being right.

Who hurt you?

Effort. What hurt me was the concept of willpower itself, and the application of it as a means of solving my problems.

The launch of Dauntless in 2019 tore me to pieces over a month of 15-20 hour days, 7 days a week. We crunched through over 1700 deployments in that time. They wrote whitepapers about what we achieved, and they were right to, because what we did and what it cost us was beyond human capacity. It has taken me the last six years to recover what I lost in that room.

If we didn’t succeed, none of us would have jobs because the studio would close. But that was a manageable amount of pressure compared to the real Sword of Damocles that hung over my head.

If I didn’t succeed to the arbitrary satisfaction of my employer, I would be fired and forced to leave the country.

The pressure was unfathomable, my health was already failing, and my life as I knew it hung on my ability and capacity to perform.

But I’d already uprooted my life the year before to escape the Trump administration’s destruction of the visa program, and staring down the barrel of being forced to move back to Australia, I decided that I would do whatever I had to do to succeed to the arbitrary satisfaction of my employer. It pushed me so far beyond the physical limits of my body that by the end of the second week I was throwing up several times a day, shitting my guts out, unable to sleep without whiskey, and unable to wake without a carton of Red Bull. I survived off fast food, granola, and soda, because it was what I could consume quickly and get back to work. I took Advil for the muscle spasms, Tylenol for the headaches, and Valium for the brain zaps. I stole swag from marketing because I didn’t have clean clothes. A friend flew in from the US to take care of me, who said I was, and I quote “not a person”.

Seems bad

I pushed myself beyond the limits of human endurance, physically and mentally. Every time my mind or body attempted to enforce a limit, I found a way to overcome that limit thanks to my seemingly-endless resolve and deep pit of rage built up over decades of a life I never should have been subjected to. Withholding details to maintain my G-rating, it is possible to force a person’s sympathetic nervous system into Fight or Flight and dump all the adrenaline it has into your body. I did this on purpose, multiple times a day, every day, for a month. That had a cost which I inevitably paid, and a limit which I inevitably hit. When the juice ran out, I hit a wall like a Toyota Tercel leaving the highway hits a pine tree.

When it was over, I couldn’t get out of bed. I tried. It didn’t work. I physically could not force the muscles to carry me. Later, doctors would theorize a number of reasons why this happened, all of them terrifying. I asked to take short term disability leave but was told to take PTO instead. I wasn’t functional enough to argue.

When I eventually returned to work, the person I had been before was gone. I felt nothing, I enjoyed nothing, and I did little outside of work except drink and talk to people I wished lived closer. Unable to quit because of my work permit, I stayed at PHX and tried to make the best of a bad situation for a further two years while I waited for my Permanent Residence (canadian green card). When it finally arrived, the situation at PHX was already deteriorating rapidly. After another few months of suffering, an Incident occurred. I walked out and emailed to say I would not be coming back.

Soon after, I took a job on Call of Duty with the intention of transitioning back into big tech and leaving game development forever. But then the strangest thing happened.

Things got better

It turns out, when a studio releases one game a year for basically fifteen years straight, they get pretty good at doing it sustainably. Working on COD was easily the best gamedev job I’d ever had. The values of the studio were codified in their practices, which reinforced all the things I’d theorized might be possible with competent leadership. It was organized, competent, management was aware of their responsibilities and worked with their team to create effective work environments.

Experiencing this and breathing a sigh of relief, I wrote the article you know and love after about six months there, having studied how Demonware worked with Treyarch, Infinity Ward, Sledgehammer, Raven, and High Moon in detail with people from every level of the orgs. I spent time with every level of leadership unpacking the structure, operation, and ideals behind all of it, and I’m being deadly serious when I say every single day was good. I did not have a single bad day at work in two years, including the launches. We released Vanguard, Modern Warfare 2, and Warzone 2.0, all the while doing maintenance work on Cold War, Black Ops 4, MW2019 and COD Mobile. The work was complex, and difficult but achievable, and there was always support from the team. It was truly one of the best things that’s ever happened to me.

After a couple of years I left to help Jules, Kait, and Joel build Soft Rains, a new indie studio making Ambrosia Sky. We got to create the studio we’d always talked about and I think we’ve been very successful. Every day I wake up happy to work with my friends on a game I believe in and you should wishlist it.

It’s a high pressure environment that I genuinely care about, but unfortunately, that revealed damage that had so far remained hidden.

Oops! All trauma

Working in a large AAA team, there’s a high degree of specialization and a high degree of redundancy. Working on a small indie team, there’s a high degree of generalization and almost no redundancy. Task domain changes constantly, and your colleagues are depending on you doing your work so they can do theirs. And because you have fewer colleagues and fewer teams, you spend less time on coordination and communication and more hours every day on the tools. Since no-one can possibly know every part of the engine, you constantly know less than you need to, and almost every task requires research into how to actually do it.

That is a lot of words to say that it was challenging, and it required me to, you know, try. Normal, right?

I didn’t know how to anymore. When I’d hit a wall and not know what to do, my brain began to lock up. I couldn’t focus, couldn’t think, couldn’t work. I’d stare at the IDE for hours, unable to even begin attacking the problems I was working on. It’s Unreal Engine, so the answer to every problem was in the source code somewhere, but past a certain point I couldn’t force myself to keep looking for them. No matter what, I couldn’t force myself to apply willpower, because last time I did that it broke me as a person and nearly killed me. It became a severely limiting factor in what I could do, because the only other time in my career I needed to spend this much of my time programming was the original Dauntless launch. I couldn’t write the amount of code that I needed to, and the answer I turned to last time scared me.

I feared that pushing the button in my head marked “generate willpower” might trigger the fight or flight that broke me, but more than that, I feared a much worse scenario: if in a moment of desperation, I reached for that old, dangerous button as a last resort, and it didn’t work. Knowing that I’d been pushed so far as to reach for my secret weapon, only to find that I didn’t have one? I knew that’d break me, so I stayed well away from anything that even felt like effort.

Just when I thought things couldn’t get worse, they did.

Death of a friend

A friend from my home town died. His name was Paul Wankadia, and when I was a kid he was the first person I knew who also Liked Computer. You might have known him as Junyer from his contributions to RE2. He had a heart attack at work and later died recovering at home. Our lives didn’t look so different, and his killed him. Not too long after, a doctor would tell me that mine was going to kill me for the same reasons, and I needed to fix my shit. But with what? I was still cooked, I had no juice to spend on such a thing.

This put me in a bind. Before, I couldn’t apply effort because last time I did it nearly killed me. Now I was being told if I didn’t apply effort to change my life, it would definitely kill me.

It simplified the choice quite a bit. If death is likely either way, pick the one that’s least likely. So I changed my life, and committed to earning my health back, and that started with exercise. Aware of my propensity to go too hard too quickly and hurt myself, I started with light cardio and light dumbbells at home. When that stopped making me feel ruined for multiple days afterwards, I started going to the gym in my building, with a little more intense cardio. When that started being manageable, I very lightly started lifting, as I had at so many other points in my life. Weeks passed and the weights went up and down, but about a month in, as I began to approach failure, the strangest thing happened.

Lifting the bar

I felt my body weaken, my muscles ask for rest. At any point during the previous the past six years, I’d have listened. But an old, long dormant part of me began to whisper in guttural tones begging me to fight. A muscle memory I thought lost crept into the fibers and demanded I push, and together they spat fire into my lungs. Suddenly, there was one more rep left in me. Then another. Then another. Then ten more. And two more sets. It wasn’t until the end of the night as I sat alone on the floor of the gym, quietly sobbing, that I realized I had found a part of me that I’d thought had died in the fire of 2019. Applying effort to the weights was safe, and good for me, and something that would inherently reward me. Without realizing it, I’d been retraining my brain to remember that effort could lead places that weren’t just pain, disappointment, and burnout. After that day, I began to crave challenge again. I lifted heavier and heavier, and started to play games. I started to write for fun again, I went to the League of Legends Mid-Season Invitational, and started to join people for ARAMs. The days no longer ended with me collapsing in front of TV, ordering a burrito, drinking until it was time to sleep, and passing out, instead punctuated with social activities, exercise, and reading.

It’s been nearly a year since I started trying to fix my life, and I’m still going to the gym four or five days a week, for about an hour and a half per day. I’m regularly lifting three plates (315lb / 145kg) on my heaviest lifts in most of those sessions. I’m eating for the sole purpose of fueling my body for the next lift, and it is working. I am, quite frankly, strong as hell and ripped.

But more than anything, I’m able to work to my fullest capacity again. Before weightlifting, I’d already done the work to change my relationship with employment and game development and I’d learned to trust that my team had my back. Despite that, the damage that prevented me from applying willpower had lurked in the background for years, sucking up my ability to do … well, just about anything. It took me until now to realize it, but that damage had widespread impacts over my life. It’s the reason I’ve barely even been able to play games or during most of this time period, because games are the application of effort towards a challenge and the idea of recreationally applying effort caused the exact same lock up that attempting to push through a problem at work did. I could barely read books because it required me to sit alone with my thoughts, and quite frankly that sounded like hell. It doesn’t, anymore. I’m reading Gideon the 9th right now, and it’s lovely.

A better life

I play games and read most days now. I wake up at 9, start work at 10, work until 6, then gym until 7:30, cook dinner, and spend the rest of the night playing. I eat 140 - 195g of protein a day, and buy a quite frankly unholy amount of chicken breast and eggs every week. I don’t really drink or smoke anymore. Not really intentionally, I just don’t want to. I have other priorities and things in my life that reward me more than they did, so I do not need them.

Even with a dream job, you can still be bleeding from old wounds.

I tell you this story — my story — to illustrate how insidious damage from the worst of our experiences can lurk beneath the surface, and to show how recovery is possible. It also serves to show how the recovery requirements are different for each of us. My damage was specific to the nature of the incidents that broke me, and so the work required to heal me meant addressing that. I was lucky (?) that external circumstances put me in a place where I accidentally discovered what I was stuck on. I hope that you are luckier than me in this regard.

Our brains are neural networks, and neural networks cannot simply be told how to operate. Saying a space is safe doesn’t make it safe, nor does it make you feel safe. We must be shown that things are safe and have it demonstrated repeatedly until the pathways that process that information strengthen and we can trust that what we have seen and are seeing will continue to be seen.

We are players in the game of our own lives and we must train ourselves with input until our natural reactions are the ones we want. We must build the game such that our experiences retrain us simply by living in the core gameplay loops we have set out.

Moving on

On May 29th 2025, Dauntless died an unremarkable death and sank offline into an unmarked grave. A handful of people from the Phoenix Labs Survivor’s Support Group got together in a nearby park to mourn its passing. I was not one of them. It was a bad thing that happened to us, and its memory remains a warning for all that come after.

The last step in healing is saying goodbye to your pain, and moving past it. The people who did these things to us will never see consequences. You will have to make peace with that however you can, because the last step is leaving them behind altogether, and never thinking about them again. They cannot hurt you anymore; once we purge the damage they inflicted, their influence is gone forever.

You can heal from these terrible things. You can build a better life for yourself. You just have to figure out how, and no-one knows you better than you.

Good luck, old friend. I believe in you.

// for those we have lost
// for those we can yet save

There are a lot of reasons you may need to import text-based tables into UE5. You might be building your own editor modules. You might be using data assets instead of data tables. You might be building a VO pipeline and need to import and export states from the recording sheet. Fortunately, there’s a format for that!

If you search for this in the official documentation, you’ll likely find this article in the official Unreal Learning Community: CSV to Data Table manipulation

It details a method for reading from CSV files in C++. The only problem is: it doesn’t really “work”, so to speak. It might, but it probably won’t.

It contains the following line of code:

aString.ParseIntoArray(stringArray, TEXT(","), false);

It will probably not work for you because it is a simple string split. If you have any commas in your text fields, they will be taken to be new fields. This is the correct and expected behavior for that function, but it was “fixed” to help with CSV files in UE4.5, and at an unknown time has been adjusted back to a basic string split. So the function itself is fine, but it’s not the right one to use because it can fail depending on your data.

Secondarily, when I tried the method it uses to load the CSV file, it failed every time:

FFileHelper::LoadANSITextFileToStrings(*CsvFile, NULL, Lines);

If you want it to actually work:

1. Use FFileHelper::LoadFileToString to load the file into a string.

2. Use the CsvParser module to parse the string you just loaded.

This is confirmed working on 5.3+, although be aware “Load File To String” will fail if the file is open in another program; it does attempt an exclusive read so please close/save your CSV before importing via this method.

#include "Serialization/Csv/CsvParser.h"

FString CsvFile = *(FilePath + "\\filename.csv"); // filepath 
FString CsvString; // string to load csv into

if (FPaths::FileExists(CsvFile))
{
	FFileHelper::LoadFileToString(CsvString, *CsvFile);
	FCsvParser CsvParser = FCsvParser(CsvString);
	TMap<FString, TArray<FString>> CsvData;
	
	for (auto& Row : CsvParser.GetRows())
	{
	UE_LOG(LogCategory, Display, TEXT("1: %s\n2: %s\n3: %s\n4: %s\n5: %s\n"), Row[0], Row[1], Row[2], Row[3], Row[4]);
	}
}

And while you’re here, a quick sample for writing CSV files.

FString CSVOutputFileContents = TEXT("Line_ID,Character,Dialogue Text,Status\n"); // CSV header row
TCHAR Format[35] = TEXT("\"%s\",\"%s\",\"%s\",\"%s\",\"%s\"\n"); // format for printf

for (auto& Row : SomeIterableThing)
{
CSVOutputFileContents += FString::Printf(Format, *Line_ID, *CharacterName, *DialogueText, *Status); // iterate over your things and write one row each here
}
FFileHelper::SaveStringToFile(CSVOutputFileContents, *(FilePath + "\\recording-export.csv")); // finally, save the file

This took up way too much of my Tuesday. I write it down so as to potentially save yours.

Until next time.

// for those we have lost
// for those we can yet save

Following the Epic Building From Source guide won’t get you a compiling install. There’s one additional prerequisite step that’s not well-documented: Visual Studio setup. So, here are the steps I use to set it up.

The Steps

1. The latest VS C++ toolchain doesn’t work with UE5.3 and below, but if you’re not actually using Visual Studio, you can install just the build tools for VS, fixed to a particular release. The version you want is 17.6 and it can be downloaded from the release page.

   

   If you do need to use VS then you’ll need Professional to pick your version, but if you’re still on 5.3 at this stage you’re likely a professional so you probably already have it.

2. When you run the installer, you’ll see a window like this.

   

3. From the two-column list of options on the left, make sure the following items are ticked:

   1. .NET desktop development

   2. Desktop development with C++

   3. Universal Windows Platform development

   4. Game development with C++, plus the following optional items under this heading:

      • C++ profiling tools

      • C++ AddressSanitizer

4. After you’ve selected the correct options, the window should look more like this. Please ignore the day/night mode swap.

   

5. Now, go to the Individual Components tab and ensure the following items are ticked:

   1. .NET Framework 4.8 SDK

   2. .NET Framework 4.7.2 targeting pack

   3. .NET Framework 4.6.1 targeting pack

   4. MSVC v143 - VS 2022 C++ x64/x86 build tools (v14.36-17.6)

   5. C++ v14.36 (17.6) ATL for v143 build tools (x86 & x64)

   6. C++ v14.36 (17.6) MFC for v143 build tools (x86 & x64)

   7. C++/CLI support for v143 build tools (14.36-17.6)

   8. Windows 11 SDK (10.0.22000.0)

6. Run Setup.bat in the source folder as administrator.

7. You’re done! Now you can follow the guide.

Why is it like this?

The official documentation doesn’t know anything about your setup and doesn’t want to, they have to account for everything and that’s all well and good but it’s still a problem you’d have to solve for yourself. Now you don’t have to.

// for those we have lost
// for those we can yet save

Earlier this week, Network Engineering Influencer “TracketPacer” (presumably a Spoonerism of the Cisco network simulation tool “Packet Tracer”) posted a video of a network hub looped back on itself. Confusingly, this did not create a broadcast storm, as she’d hoped.

For those of you not familiar with the dark arts of Network Engineering that underpin our entire online infrastructure, looping Ethernet switches or hubs usually creates a self-sustaining broadcast storm that very quickly consumes all available bandwidth. There are protocols designed to prevent this, but they’re usually only available on higher end “managed” switches. Her basic, unmanaged Netgear hubs didn’t have anything like that. They were arguably some of the dumbest network devices in existence.

And yet, when she fired up Wireshark (a network capture program) to look at the network traffic and sent some pings out, she could only see ARP requests going out for the ping attempt, and nothing else. No storm, no flood, no nothing. So what gives?

It’s tempting to just dive in and start screwing around, but we’re professionals here, and we’re trying to be better professionals, so here’s a technique I like to call “Possibility Space Division”.

Possibility Spaces

A possibility space is a potential scenario that applies rules, limitations, or otherwise partitions off potential root causes of an issue into forking decision trees (n-way, or binary trees for the programmers) for evaluation and elimination.

What this means in practice is generally asking questions in the shape of “Either X is true or it is false”. Dividing our problems like this serves two purposes:

1. To eliminate entire segments of potential causes at once

2. To help us track what potential problems we have eliminated

Both of these serve a single goal: to help us drill down and identify the root cause as quickly as possible.

So, let’s evaluate what we think we know about this problem. We have three pieces of information.

1. There is a looped layer 2 network

2. Looped layer 2 networks, absent of an antiloop protocol, create broadcast storms

3. Wireshark didn’t show a broadcast storm

You’ll notice that I didn’t say “there wasn’t a broadcast storm”. This is because of a second layer of troubleshooting that you need to be aware of as an engineer - that everything we do, trust, and rely on, is based on assumptions and proxies. We have to verify those assumptions. Our user story was “Broadcast storm should happen but doesn’t”. But do we actually know that it didn’t happen? Not yet. All we really know is that Wireshark didn’t show one.

So we have two possibility spaces:

1. Either there wasn’t a broadcast storm, or;

2. There was a broadcast storm and Wireshark wasn’t displaying it

We now have the root node of a binary tree of troubleshooting, and we get to choose which assumption we want to validate first, to determine which one we need to investigate. But which one should we investigate first?

That choice is simple: use Occam’s razor, and investigate the possibility with the fewest assumptions. Anything involving a PC is orders of magnitude more complicated than a network device, let alone one of the dumbest network devices on the planet. And yeah, there’s some low hanging fruit on Wireshark, but there are a million thing that could go wrong there. Driver error, usbpcap failure, OS failures, misconfigurations, promiscuous mode not enabled, all sorts of stuff. But the network is simple and these hubs are simple so we should look at the hubs because either we will find our answer quickly or we will eliminate them quickly.

We Looked At The Hubs

As it turns out, an enterprising user in the replies looked up the manual for the hub in question and found what the colors of the lights mean for it. There was a yellow light on the port, which if you consult the user manual for the device, indicate the port has been partitioned (separated for excessive collisions etc), and thus was not forwarding. So a storm had started, immediately created collisions, and been shut down by partitioning. Did you know that was a thing? Who among us has used a hub recently? Did anyone recognize the yellow light or remember that port partitioning existed, or that collisions would need to be handled? I didn’t, but if you check the manual, it’s right there.

In the brief few seconds we saw the network devices, we could see two things.

1. The ports themselves weren’t blinking with a lot of traffic

2. The ports had a secondary yellow light

Now, you could write the not-blinking off as ‘the storm hasn’t started yet’, which might be reasonable in the video because they usually take a little bit to get going, but ultimately “port is partitioned” explained everything, and we never had to dig into the complex option of “what if Wireshark is lying to me?”

When dealing with possibility space division, simplicity is your friend, and speed of fork elimination is your other friend. This goes double during an outage.

Why Does This Matter?

Quite frankly, it matters because some of you are very, very bad at troubleshooting.

One time in recent history, a Computer Science Fundamentals course instructor I came across was having trouble with his web server. He was Not A Web Guy and got stuck quickly. He should have realized very quickly where his problem was, because all the information he needed was available, and he was continuing to attempt to re-check things that he had already validated. He was not respecting the fork, he wasn’t tracking what he’d validated, and so he wasted an entire day chasing the problem.

If you know anything about the internet, you know that a working website depends on a handful of things.

1. A domain name pointing to an IP address

2. IP traffic being able to be routed to that IP address

3. Clients being able to look up that domain name and resolve the IP address

4. Clients being able to craft a HTTP request, and send it to that IP address

5. Those requests may need to be routed to the IP (load balancer, application layer firewall, etc)

6. A process on a server somewhere listening on a port must receive that request.

7. That request needs to be processed by the service process and then Stuff Happens to look up what the contents of the web page must be and return it

Our instructor could ping the server by its DNS name, via a command like ping mycompscicourse.com and get responses back. This proves without a doubt two things:

1. DNS is working. It was successfully resolving the IP address of the domain name.

2. Layer 3 (IP address) is working. Ping was successfully arriving on that IP and it was replying.

At this stage, he should have been looking further down the stack of things that need to happen. The correct next step is to try to connect to the server by DNS name on the appropriate port and see if it worked.

If it did, then we can move further down and investigate the server process.

If it didn’t, then we need to validate that HTTP requests can reach the server.

However, he didn’t attempt to validate those. He wasn’t scientific about it, and didn’t bother to think through that he had actually validated DNS and IP already. This man wasted hours messing around with DNS configurations and all sorts of other things, but his initial testing had already validated DNS. He was re-investigating things that should have been cleared.

If it’s this easy for an instructor to fuck up, you better believe we’re all capable of it if we’re not tracking the depth and forking of our troubleshooting, or the assumptions that we’re making.

Your Tools Can Lie

The other reason that this is important is that there is a moment some time right before you become a senior where you realize that all your evidence for anything is based on assumptions and we all stand on the shoulders of giants.

When I was a Network Engineer, I got called out at 3am for a network that was down. I logged into the router and there was no evidence it was actually down except for the fact that it was definitely down. Every single tool reported that it should have been working. The one thing that stood out was that the CPU was kind of high, but the CPU on that router was kind of shitty so that wasn’t abnormal.

So, I began eliminating things and validating my assumptions. The routing table correctly showed that the internet was reachable out the Internet port and my customer was available out of the customer port. But no matter what I did, I couldn’t get ping responses through it. I wanted to reboot it, but it was carrying critical traffic for another customer and the provider said no. Fortunately, I carried a tool for these situations - a tiny but full-featured ethernet router, a Mikrotik RB750GL.

I configured it as a packet sniffer to aggregate the inbound and outbound traffic into a single port and send them to my laptop where the awaiting Wireshark would be able to show me what was really happening. I set up another laptop nearby and started generating traffic so I could 100% confirm that traffic I was sending was traversing the router and coming out the other side.

Friends. It was not coming out the other side. It went out a different interface entirely. I sat baffled by a router that clearly said route X was going out interface A, but I could see it coming out interface B. So, first a few facts:

1. The customer’s network could definitely not reach the Internet or vice versa

2. The router’s software reported correct routes for both customer and Internet

3. Packets traversing the router did not follow those routes

So, back to the possibility spaces. Either:

1. The router is telling the truth

2. Or it isn’t, and it needs to be rebooted or replaced

Possibility space 2 is bad, interruptive, and at worst case, expensive, so let’s start with possibility space 1. “We know the routing table is wrong” is low hanging fruit, but we need to be precise with language here.

What we actually know, is that the output of “show ip route” doesn’t match the observed flow of packets. How could that happen? Where does “show ip route” gets information from, and how do packets actually traverse the router?

There lay the answer. This was a hardware accelerated router. Although it relied on its CPU to learn about routes and configuration, the actual packet forwarding happened in hardware. The process went something like this:

1. A route is learned or configured in software

2. The routing table (RIB) is populated with that entry and a destination

3. The in-hardware forwarding table (FIB) that actually passes the packets around receives messages about RIB updates that tell it how to configure the actual forwarding

So I queried the FIB, and sure enough, there were the entries that were punting all our client’s packets out the wrong interface. But then something jumped out at me - a single line in the output that said something like:

Queued updates: 51,239

I hit the command again and the number decreased slightly. Why would there be 50k+ queued updates? I went back to the logs again and found the source of all our woes - the internet link had been flapping furiously over the night. Up, down, up, down. Someone had likely disturbed a cable, so it would start and stop working over and over again. Problem was though, this was a BGP connection - it worked by sending the router instructions for how to reach every single network on the internet. At the time, the full global routing table was around 500,000 prefixes (destinations). Because of the magnitude of this kind of change, usually connections like this have some configuration on them to stop flapping from affecting them. This one didn’t. So when the internet connection started going up and down over and over, our poor little router was receiving an entire internet’s worth of destinations, then being told “oops no destinations, delete everything I just sent you”, then milliseconds later, an entire Internet’s worth of update again. This happened ~100,000 times, leaving our poor, tiny, underpowered router CPU with a queue of fifty billion route updates to process.

A few more refreshes and we could see the queue decreasing enough that napkin math said it would fix itself in 4 hours. I hacked up a workaround using the Mikrotik router, then came back in the afternoon to pick it up when the queue had emptied, and all was fine.

When I observed the RIB, I wasn’t looking at where the packets were going. I was looking at where the software intended them to go. It wasn’t until I looked at the FIB that I could see where the packets were actually going. Now most of the time, the RIB and FIB are in sync and that’s not an issue, so looking at the RIB as a proxy for the FIB is usually fine. Today it wasn’t. Every tool is querying something to get its information, and that query works in a particular way. Many of those ways can be broken, and choosing to ignore the ways in which they can break are the assumptions that we make our decisions on.

What Did We Learn?

Lesson 1: By separating the possible failure conditions into binary tree spaces we can prune branches of troubleshooting and save a lot of time.

Lesson 2: Understand the difference between information and a proxy for information.

My first thought was that the command “show ip route” lied to me. But it didn’t, not really. Through force of habit (and the fact that it’s usually true) I expected the output of the RIB to match how packets were forwarded, but that was an assumption on my part. It’s one that’s usually correct, but that day it wasn’t, and if I hadn’t been able to identify and interrogate that assumption, I would have never solved the issue.

I believed “show ip route” was showing me the way that packets would flow through the router, but it was a proxy for that - it sat upstream of the thing that actually did the forwarding.

Best of luck in your troubleshooting.

// for those we have lost
// for those we can yet save

Most of you have probably tried to follow an Unreal tutorial before and never really quite understood what was happening.

The issue with Unreal tutorials is that in order to learn to be functional quickly for the reward, they give you a hammer. After that, every problem looks like a nail. In reality, there’s an entire toolbox that’s equally accessible, but unless they know what else is in there, people keep reaching for the hammer.

This is not a tutorial. It is a guided reference. It’s not intended to be memorized, it’s intended to be read at a high level, and referred back to as you need it.

What follows is a structured walk-through of what the tutorials don’t tell you about the things they get you to do, so that when you do follow a tutorial or try to build something, you understand the correct techniques to use, and where to use them.

In this part, we discuss the building blocks and how to use them.

In the next article, we’ll talk about how they all fit together in a game and go over common techniques and strategies for how to perform common tasks.

If I get enough questions about the first two parts, I’ll do a FAQ.

This method of learning UE5 works. I’ve brought developers up to speed and functional on various titles using this technique. We’re only dealing with Blueprint here. A lot of C++ exists underneath the Blueprint, but it’s beyond the scope of this primer.

I’m going to be using screenshots and examples from an old prototype of mine called THREADS, which looks suspiciously like single-player cyberpunk League of Legends.

The Basics

Actors and Components

The basic building blocks in Unreal are Actors, and Components.

Actors are the main building blocks of your game, and like most things in UE5 they are objects, in the Object Oriented Programming sense. They exist in the game world somewhere - they have a Transform (location + rotation) in 3D space. Your player character, your NPCs, trees, even the ground itself, are all types of Actors.

This is an Actor (BP_Enemy).

Components are things that attach to Actors to provide specific functionality. When you add a component to an Actor in the Editor, it becomes attached, and follows the Actor around. These are some of the components attached to BP_Enemy.

Where to start building

If you’ve ever programmed anything, you know that you don’t want to write the same code twice. You want to write it once, then call that code when you need it, like with functions. The first thing you need to decide is where you want that code to live. Let’s start with something simple you’ve seen before. THREADS has combat, so I need to a place to store HP information, and to display a health bar. This needs to happen for the player, for enemies, and for destructible objects. I don’t want to write this code on the player, and every enemy. Instead, I make a Component for Health.

The Health_Component

Anything in THREADS that takes damage has a Health Component. It serves four purposes:

• Stores the max HP and current HP

• Displays a health bar, colored for team

• Receives notification of taking damage (or healing) from the Actor it’s attached to

• Notifies the Actor when it is out of health, so it knows to die

By putting this functionality in a Component, I can add the concept of Health and all the associated functions to support it to any Actor in the game. I just need to put code on the Actor to tell the Health Component when damage was taken, and code to program what happens when it dies. Even if different Actors have different ways of receiving damage and do different things when they die, the health itself remains managed in the component.

But I also don’t want to have to write code over and over on every Actor to take damage, send it to the Health Component, and receive Death notifications. So what should I do? This is where Inheritance comes in.

Inheritance

Let’s say I want to create Enemies in the game. If I used an entirely separate Actor every time, I’d have to program the same interactions over and over. To avoid that, Unreal makes use of a common programming technique called Inheritance.

Inheritance lets you add a new type of Actor as a child of a different type, called the Parent. Child classes have all the variables and code of their parent, but let you either extend the class by adding new variables and code, or override it by changing the implementation of the same code.

So, rather than building entirely new class for every enemy, I create a basic, generic enemy class called BP_Enemy and put a Health_Component on it. Unreal has a native concept of Damage, so the base class has an event “AnyDamage” that fires when it takes damage. So, when any damage occurs, we notify the Health Component, and play Damage Animation.

Then, when I want to create a specific type of enemy - let’s say an Orc. BP_Enemy is a child class of Actor, so I’ll make a new child class of BP_Enemy called BP_Enemy_Orc. The resulting class has all the functions and variables for an Actor, plus the ones I added in BP_Enemy, plus any new ones I add for directly to the Orc. I can change also specific properties/variables that were set on BP_Enemy, like a new Max HP value on the component, replace the Actor’s Mesh with a new Orc model, and replace the Damage animation with one designed for Orcs. I repeat this process for every new kind of Enemy, just changing the parameters I need to be different, but with all the base variables and functions intact.

Now we have a base class of Enemy that we can build different types of Enemy from, and a Health Component we can put on anything that needs HP.

Key takeaway:

• To put different behaviors/data in objects that are similar, use child classes. E.g. I want to make ten different kinds of Enemy.

• To put the same behavior in objects that are different, use components.
  E.g. I want to add Health to Enemies, Players, and Obstacles.

Final note on adding how Actors and Components work: Every variable or function can be public or private, which determines whether it can be accessed from inside your Blueprint, or whether other Blueprints can access it. If you add a variable to your Actor or Component but can’t access it elsewhere in the code, check its visibility.

How Stuff Works

We started with Actors and Components because they’re the basic building blocks. Next, you need to actually write code in them.

Places You Can Write Code

There are four main ways that code executes in Unreal: Functions, Events, Timers, and Tick. We’ll approach them in that order.

Functions

Functions are a way to group a chunk of reusable code together that can be called on demand rather than rewriting it every place you need it. Functions can have inputs (arguments) and outputs (return values), but they don’t have to have either.

Here’s a function in THREADS with one argument, and no return value. It gets called when an Actor enters firing range, and the argument is a reference to that Actor called “Target Entering”. It checks if it’s targetable, then checks if it’s currently targeted, and if yes to both, alerts the Player Controller that it’s fine to start attacking.

Key takeaway:

Use Functions when you need to execute the same code a number of times inside the same Blueprint.

In Blueprint, functions are guaranteed to return on the same frame. This means you can’t use Delay nodes in them, because it would delay the entire current frame. So what do you do when you need to run code, but don’t need to wait for it to finish?

Events

Events (also called Delegates) are asynchronous - fire and forget functions that won’t blow things up if the listening object goes away.

When you want to trigger actions on one or more objects in response to something happening, you probably want Events. All Unreal Actors have a tonne of Events built in from AActor. One that you’ll see frequently is “Begin Play”. It’s fired when an actor finishes spawning in the level. Here’s one for an enemy Actor. When it triggers, it sets the enemy’s team to Hostile, creates a health bar, and adds it to the enemy Actor.

Here’s another common pair: “On [Actor/Component] Begin Overlap”, which basically means “something else touched me”, and then On End Overlap for the opposite (that thing is no longer touching me). They’re generally used to trigger interactions between different Actors. Events can have arguments passed to them like functions - in this case, BeginPlay has no arguments, but when Overlap fires, it’ll pass in information about the overlap itself.

These are Overlap Events from a Collision Sphere called “Interact Radius” on the Player Character. Collision volumes exist to identify when things collide, and"Begin Overlap” fires when something overlaps with it. When that happens, it calls the function “On Enter Interact Range” which enables interaction with another object in the game.

Key Takeaway:

Use Events when you need to trigger code, but don’t need to wait for it to finish.

You can also trigger Events asynchronously on a delay using..

Timers

Timers do stuff after a delay. They return an object called a Timer Handle that holds information about the timer, like how much time is left. You can also do things like terminate early and do the stuff, or just kill it and do nothing.

Here’s an example of using Timers to make a weapon reload. The “Start Reload” event:

1. Sets “Attack Available” variable to false, locking you out of shooting.

2. Starts a timer with length Reload Time. The event pin for the timer connects to the “Finish Reload” event.

3. When the timer expires, the “Finish Reload” event fires.

4. Sets current ammunition amount to the max size of the magazine

5. Then finally, re-enables Attack Available.

Tick

Events: “A thing happened, let’s do stuff”. But what about things you want to be constantly updated? You use Tick.

Every Actor and Component has a Tick() function that, if enabled, runs every frame (sort of). Use it for anything you need to be calculated or updated every frame.

The Unreal Top Down Example project’s Tick() function to get the mouse cursor’s position, raycast down into the world, and render a decal on the ground underneath it.

In THREADS, there’s a particular component that I want to always be facing the camera. The tick code runs every frame to rotate it with Set World Rotation().

You can also set the tick time to be slower, on an interval. If it’s not important that it happens immediately but is important that it happens constantly, you can set an Actor’s tick to happen at longer delays. If I have a system that’s constantly changing the time of day and adjusting the sun position and lighting, it might need to only run every five seconds, so I’d set the tick time to 5.

Tick is great, because it means things can be always updating themselves. However, Tick can also be bad, because again, the code will run every frame. Executing unnecessary or expensive code on Tick every frame is the fastest way to slow your game down. There’s a function “Get All Actors” which just … lists every actor in the game. There’s actually a warning on it that says “DO NOT CALL THIS ON TICK”. Yes, it’s in capital letters.

Key Takeaway:

• Use the On Tick function for things that must update constantly.

• All Actors and Components can Tick.

• You can tick at a larger interval instead of every frame.

• Also you can disable or enable Tick for any Actor or Component as needed.

• A Component cannot tick if the Actor it is attached to has Tick disabled.

More info in the docs on Actor Ticking.

So now we’ve got four methods of executing code. Where do we put that code?

Tools

Pawns and Controllers

A Pawn is an Actor that’s controlled by a Controller to make it do things. The Controller allows your game to issue commands to Actors, like “Move in this direction” or “Stop” or “Walk to this location”.

A Controller can take commands directly from code, but there are also two special kinds of controllers: Player Controllers and AI Controllers. They’re both children of the Controller class, and extend it in different ways.

A Player Controller receives inputs from the player (key presses, mouse, etc) and translates them into specific directions it can pass to the Pawn. It’s preconfigured with the inputs you configured for your project like mouse, gamepad buttons, or key presses.

An AI Controller has a bunch of tools on it for making AI for NPCs, like Behavior Trees, that let you program rules for how the Pawn should behave.

Pawns don’t do a whole lot on their own. The code on the base Pawn class is mostly about taking commands. If you want an actual NPC in your game, there’s a child class called Character that has all the stuff you probably want.

• A Mesh, so it has a 3D model to display and animate.

• A Movement Component that controls walking, running, falling, etc.

• A Capsule Component for collision.

• A bunch of networking / multiplayer code.

That’s everything you need for an NPC, but a player-controlled character is going to need more. There’s a Player Character class that adds things like:

• Input from a Player Controller

• A Camera Manager for controlling the viewport

• A UI / HUD Overlay

• Force Feedback effects

Key takeaway:

• A Pawn is an Actor controlled by a Controller

• AI Controllers control Characters

• Player Controllers control Player Characters

• Create child classes of Character for NPCs

• Create child classes of Player Character for players

• Create a child class of Player Controller to customize input handling

When a Controller takes control of a Pawn, this is called “possessing” it, which is definitely not creepy at all.

For more info, check out docs for Player Controller and Pawn.

If you want more info on how input is handled in UE5, try Enhanced Input.

Collision & Traces

Collision is a means of checking if an Actor touched another Actor. There are two types of collisions available: Hits (blocking) and Overlaps (non-blocking).

An Actor has a collision Object Type - other types of Actors then configure how they should respond to collisions for that object type, and whether they should ignore them, fire an Overlap event, or block (collide) and generate a Hit event.

Use Collision to configure what kinds of Actors should pass through each other unnoticed, what should overlap, and what should stop. You might use Collision object types to let friendly fire pass through teammates, but hit enemies.

You can also do Traces, to check what something might run into. You can trace in a line, or in a shape, like a box. Traces occur on Collision Channels and instruct Actors on how they should respond to a particular type of trace.

Use Traces to measure what you might hit in a particular direction. You might use Traces to tell if there are interactable objects in your field of vision.

Collision is what triggers Events like the one I’m going to reference next, for one Actor overlapping another.

But when you test Collision, the function returns an Actor reference. You don’t know what the collided object is yet, so how do you find out, and do stuff relevant to it?

Casting

The answer is Casting. This one’s a bit complicated, and deals with Inheritance again.

In THREADS, items that can be picked up inherit from a base Pickup class, which inherits from Actor. An Ammo pack’s inheritance goes:

Actor → BP_Pickup_Base → BP_Pickup_Ammo

In the below code, I have an event that fires when any Actor enters an automatic pickup radius around the player. We want to pick up anything we have inventory space for, and show a warning instead if it’s full.

But you need to declare types of variables on functions and events, and the overlap function needs to return any Actor, so its output type is set to Actor.

We can pick up anything that inherits from BP_Pickup_Base, and the Actor we overlapped might be, but there are two problems:

1. We don’t know if it IS a child of BP_Pickup_Base.

2. Even if it is, we can only access the properties of the Actor class, because that’s the Type we were given for this object reference. We can’t access the variable for how many inventory slots it takes up because we’re looking at it through a base Type lens.

Casting lets us solve both these problems at once by trying to treat the object as a different type.

An object reference’s class (type) is what lets Unreal know what variables and functions exist on an object, and where to find them. Our child class BP_Pickup_Base has an Inventory Slot Cost variable, but since the reference is currently of type Actor, we can’t see it. So we attempt to Cast our Actor to BP_Pickup_Base.

If it works, then it is a BP_Pickup_Base or a child of it, and then we can access the variables stored on BP_Pickup_Base, including the one we need: “Inventory Slot Cost”.

Since we now know that it is a pickup, we can retrieve the inventory slot cost and we can tell if we have enough inventory space for it and figure out whether to pick it up or just show a warning that inventory is full.

The object always was a BP_Pickup_Ammo - it was just originally referred to as an Actor, and then cast to BP_Pickup_Base. You could cast it to BP_Pickup_Ammo, or back to Actor, and it would work. The object itself remains unchanged, but the variables you could access would be different, because the type instructs how to access them.

Internally, the Event is triggered by the BP_Pickup_Ammo object, but casts it to Actor before it fires since you need to declare the argument type when you create an event. If it didn’t, you’d need a separate event for every different child class of Actor you might overlap.

It’s kind of like a template for a business listing on Google. If a business is a restaurant, and Google has menu data for it, it will display that on the profile. But if the template for the profile is set to a generic business listing, even if Google has the menu data, there’s nowhere in the UI for it to display.

You will primarily use casting in two situations, both because generic functions/events tend to return base class type references.

1. An overlap or collision event returns an Actor reference, which we may want to do something with, so we cast it to a type to do something.

2. A generic function like Get Player Controller returns the base Unreal player controller class, but if we’ve extended it to our own Player Controller class and are using it, we need to cast the returned player controller to our class to get access to the extra stuff on it. In the function we saw earlier, I get the player controller and Cast it to our actual player controller class TopDownController.

You can cast an object to any type in its inheritance chain. Don’t worry, this is as Programmer as it gets, and there’s more info in the Cast documentation.

But what if you want to call the same function on two objects that don’t have a shared parent? There’s a tool for that called..

Interfaces

We talked about when you want similar objects to have different behaviors, and when you want different objects to have the same behaviors, but what if you want different things to react differently to the same interaction?

That’s what Interfaces are for. An interface is a virtual set of functions that you can apply to any object that give other objects a defined way to interact with them.

In THREADS, “Interact” does different things depending on what the object is. If it’s a person, it’ll start a conversation. If it’s an item, it will pick it up. To achieve this, we create an “Interact” interface, and define functions on it for Interaction Start and Interaction End, then add that interface to my Pickup base class and my NPC base class.

On the Pickup base class, I implement the Start Interaction function from the Interact interface, and write code to call the inventory pickup logic, and updates any quests that are listening that have a ‘pick up this thing’ task.

On the NPC base class, I implement the Interaction Start function from the Interact interface, and write code to trigger the UI for dialogue. I also implement the Interaction End event because I need to undo stuff if the player terminates the conversation early, like reset the camera position (Set View Target).

Finally, when an object enters the interaction radius of the Player Character, instead of checking its type, I can simply check if it implements the Interact interface, and if it does, (after some other checks) call the Interaction Start function.

With that final method of calling code out of the way, we can get back to types of Actors.

Volumes

Volumes are three-dimensional Actors (usually boxes) used to alter the behavior of areas within levels.

Unreal includes a bunch of different types that do different things:

• Triggering Events when you walk into them.

• Blocking Actors from walking into them.

• Changing the way a level calculates its lighting or visibility.

Use Volumes any time you care whether or not any Actor is inside of any particular space in your game.

For more information on the kinds of Volumes available out of the box, check out the official documentation.

Brushes

The geometry of a Volume comes from its parent class Brush. Brushes are an easy way to quickly make test level geometry. They can be Additive or Subtractive, meaning they either get used to place geometry, or act as a cutout for it. I’m going to show you where to find them because it’s hard to find.

This is an example of two box brushes. One is set to “Additive” to make the box itself and set to Hollow so it’s just the walls. The other “Subtractive” to cut a hole out of it, which is highlighted.

These aren’t to be used in your final game. You’ll need to convert them to…

Meshes

If your Actor needs a 3D model, add a Mesh Component.

Meshes are 3D models. There are two kinds of Mesh: Static Mesh and Skeletal Mesh. Static Meshes don’t move or animate, but Skeletal Meshes have a “skeleton” (rig) that controls how they move and animate. If an Actor has a 3D model in the game, it probably has a Static Mesh or Skeletal Mesh.

Animation

The animation rig in a Skeletal Mesh lets parts of it move. A particular unique animation for a rig is called a Montage. The overall animation of a Skeletal Mesh is controlled by an Animation Blueprint, which is a tool for telling what animations should play under what conditions, control the transitions between them, and how they can be blended together. In technical terms, you can think of it like a State Machine. It represents the state of your character (walking, running, standing, falling), defines animations for each state, and configures how to transition between other states.

Animation Blueprints allow you to blend animations together - for example, you might have one animation for Walk and one for Run. As you speed up, they will slowly mix together to create a smooth transition. This is called a Blend Space.

You can also layer animations together - like playing a cheering animation with the upper body while still running. Look up Additive vs Full Body for more info.

Widgets / UI

UI in Unreal is basically made up of Widgets, which are objects that render a 2D image of some sort. They’re commonly used for menus, buttons, and overlays.

Widget editing has two pages, which you swap between in the top right: Designer, and Graph. The Designer page is where you create the layout, the Graph page is where you add your code, like a regular Blueprint.

You can add them to the viewport to become part of the UI.

To use a Widget, first Create it, then either add it to the viewport (screen), or assign it to a Widget Component on an Actor.

If you want to make a popup menu or clickable UI, you’ll need to give focus to the keyboard, and set input mode to UI only.

When destroying your menu, don’t forget to bring back input mode and unpause:

You can also add Widgets to Actors using a Widget Component. This is good for character nameplates or health bars. Widgets attached to Actors can exist in “Screen Space” (2D, drawn over the top) or “World Space” (3D, part of the game world).

If you want to do Screen Space widgets, you may need to do line traces to the camera occasionally, to check if they should be seen, otherwise far away characters will draw over the top of the rest of your game.

The alternative that I use in THREADS is that they’re in World Space, so they can be occluded by the environment. I use the Tick function to manually face them towards the camera by getting the camera rotation, then flipping it 180 degrees.

For more info, check out the Building UI page.

Sound

Unreal actually has a pretty complicated sound system out of the box, and the documentation is incomplete. Don’t feel bad if you’re struggling. There’s a short guide to importing .wav files into your game here.

Once you have a sound in, you’re probably going to want to use it for one of four things:

• 2D sounds like menu clicks

• 3D sounds that occur in the game world

• Dialogue (can have subtitles attached)

• Ambient sounds, that play when you’re in a space

It’s difficult to find documentation on Unreal sound, so here’s a list of all the Blueprint nodes you can use related to sounds.

You can play sounds either using Gameplay Statics that are unrelated to any Actors, or you can add an Audio Component to an Actor and have sound “emit” from it.

The best way to learn sound is to just try it, and it’s the one of two things in this primer that I’m going to tell you to just get in editor and mess with the functions listed above, and see what happens.

Key Takeaway:

• Sound is hard but there’s probably an engine function for your use case

VFX

The other thing you should just get in and play with is VFX, which is done through Niagara. The Niagara documentation is similarly incomprehensible if you don’t already understand it, so we’re going to simplify it down to “how to use what it ships with”.

Niagara displays VFX in the game world, like smoke, particles, or fluids - things that would be too complex and expensive to simulate in regular actors.

Niagara works in two parts: Systems, and Emitters.

A System is a controlling actor - it doesn’t actually do anything on its own. It exists to control Emitters, which are the things that actually make the particles you’re simulating. A system can have multiple emitters - the Fire systems below might have one Emitter for the fire effects, and another Emitter for the smoke.

Most premade assets will be a System with Emitters preconfigured on it, and the controls available on the System generally set things like how long the particles hang around for and how far they travel. If you want use one of these Fire systems, and you want more fire and less smoke, you’d likely configure that on the System itself rather than going in and editing the Emitter directly.

To get started, first you have to enable the Niagara plugin, then add a System to your level or actor. There are premade systems you can use like the Fire ones above, or you can download more. The details of Niagara are too complex to cover here, but you can learn more by editing existing Systems to see how they work.

Key Takeaway:

• Niagara Systems are controllers for Emitters.

• Emitters are the things that actually make the particles / fluids / etc.

• Particles don’t entirely exist in the game world because this is GPU magic.

Data

The last piece of the puzzle is data itself - how variables are stored. Data in Unreal functions similarly to most other programming languages, and there is no way around how Programmer-ey this is.

You may find yourself glazing over during this last section, as it’s almost purely technical. Don’t worry, we’re nearly done. This is mostly a reference so you can look up the details if you need them.

Variable types

Variables are ways to store data, like references to actors, or integers (whole numbers), but they can be organized in different kinds of containers.

1. Properties, which are just actual stored variables on an object.

2. References, which link to a stored variable somewhere else. Functions in Unreal pass objects with by value (copies the whole object) or reference (link to the original). Most variables in Unreal are passed by reference. Changing a copy doesn’t affect the original. Changing a referenced object does.

3. Arrays, which are a list of a particular type of variable you can iterate over or access certain slots in. The items in the list have an explicit order.

4. Maps, which uses a key of one variable type to store or retrieve another. They are unordered and fast. If you have a very large array you need to find one particular value in, you might want a Map so you can look it up directly.

5. Class references, which treats the class type AS a variable. Useful for storing what type of object to spawn.

We mostly care about Arrays, because they’re the most common in the engine.

Many built-in functions that need to return multiple results like “Get All Overlapping Actors” will return an Array. Your inventory might just be an Array of items. They are ordered, and can also be sorted. Searching an Array requires inspecting every value manually, so it can be slow for large numbers of entries if you don’t know which entry you need.

Individual items in an Array are accessed by “index”, which is basically just a count of ‘how many items along are they’. The first item is 0, second is 1, etc. Adding or deleting items from an Array will cause other array items to change their index. If you loop over an Array containing fruit, and in each loop, delete the current item, this will happen.

Maps work on keys, so they don’t have this problem. When you add an item to a Map, you provide a specific Key to retrieve it, and set the Value for that key to your data. Here’s the same operations from before, but performed on a Map.

This may sound like an argument to use Maps all the time instead of Arrays, but Arrays are ordered - you can shuffle the elements around, and the order can mean something, like which slot in an Inventory something is in. Maps are unordered, but they’re good for looking up one specific thing.

You might use a Map to keep track of every line of dialogue in the game, by having the Key be its line ID, and the Value be the text itself. You couldn’t do this with an Array, because if you were storing which line was associated with which index, every time you delete a line, you’d renumber the rest of them. Neither is better or worse than the other, they’re just used for different things.

Here’s an article on how to use Arrays in more detail.

Structs and Enums

Structs are a way of grouping a number of variables that are commonly used together into a single object, so they can be passed together. They’re like classes, but with less functionality.

A common example of a struct: When you Trace for collision, you don’t just want info about what you hit, but also other info like the location of the collision, and whether it was a block or an overlap. It would be bothersome to have separate variables for every possible bit of information you might need separately, so all Traces returns a single HitResult struct containing all the variables you need. Then, it’s easy to pass that data around as a single unit relating to that “hit”.

To access the individual variables inside a Struct, you “Break” it to expand them out and get one pin each. To create a Struct, you “Make” it, which takes all the variables individually and outputs them as a single struct variable.

Enums are a particular variable with a number of preset options. They’re good for making dropdowns, or handling the same object differently depending on which of the preset values it has. Use them for Types of other things.

Here’s an example: I have a Data Table (like a spreadsheet), and when I request a row from it, I get a Struct containing a variable for each column.

In this screenshot, each row in the DT_Pickupable table contains a single Pickupable Struct with all the information about a pickup. I retrieve a single Pickupable Struct from a table, and “break” it to access the variables - specifically the Pickup_Type Enum.

I use a Switch node to reroute the code depending on what the value of the Pickup Type Enum is, to execute different code for each pickup type.

That’s The End Of Part 1

These are all the basic moving parts of Unreal Engine 5 that you’ll need to make a prototype of something. If you’ve followed any tutorial, you’ve probably been asked to use some or most of these, but not understood what they did or why. I hope this clears it up. There’s a lot more - this is just the basics.

Stay tuned for Part 2, where we’ll take all the elements we just learned about, learn how they fit together in the game, and teach you how to apply these tools to solve common problems.

// for those we have lost
// for those we can yet save

There’s a reason that accurately simulating something like aerodynamics requires supercomputers — reality is complicated. There are so many variables and processes that need to run, and they need to run at such small intervals they can’t run in real time.

Games also need to run simulations, but unlike the simulations that keep our planes in the air, they must run in real time. In order for that to be achievable, we need to optimize reality and make systems that instead simulate a simplified approximation of it.

In order to hold 60fps, each frame must complete in 16.6ms. That’s not a lot of time. We can simulate semi-realistic physics with large objects in that timeframe, and hand a lot of it off to the GPU, but simulating the actual physical reality of sound in a game is impossible to do on desktop hardware in a matter of milliseconds. So instead of simulating it physically, we approximate it.

The Absolute Basics

This primer will use terminology and functions from Unreal Engine 5 and the Wwise sound engine from AudioKinetic.

So how do we simulate sounds?

We start with two basic Actor Components from Wwise:

1. Emitters, which tell the game world a sound is being played (AkComponent)

2. Listeners, which receive the sounds being played (AkAudioListener)

In a very basic setup, you’d have a Listener component on the player character (or camera), and Emitter components on anything that creates a sound. The Emitter components get fed sound files, and the Listener component gets hooked up to the output audio device, so when an Emitter signals that it is playing a sound, the Listener receives that signal and plays the sound on your computer.

But if we stop here, all sounds in the game will be heard at the same maximum volume — as if you’d just hit play on the sound file.

Attenuation

In order to simulate the fact that sounds that happen further away appear quieter to the listener, the game engine feeds Location information for both the Emitter and the Listener into the sound engine. Knowing these two locations lets it figure out how far away they are from one another.

Sounds are physical waves in the air, and those waves decay as they travel. Since we’re not actually simulating the waves in the air, we need a method to approximate how much they tail off between the two locations. The amount that a sound decays between two points is called attenuation, which is basically ‘how much does the volume decrease’. To calculate the decrease, each sound has an attenuation curve, which is a 2D graph mapping Distance to Attenuation. Wwise gets the distance between the Listener and the Emitter, then looks up the attenuation curve — for distance x, it uses the value y to determine how much quieter to make the sound.

The important thing to grasp is that a Listener isn’t receiving an audio stream of the actual sound from an Emitter the way a microphone does. It’s simply being told that the Emitter sound should play to this Listener at a certain volume level, which is dependent on distance.

(All numbers in the diagrams that follow are made up for illustration purposes.)

But there’s one more value to calculate to finish the basics.

Balance

If we only use location information, we will hear the sound in both ears the same volume. But a sound playing to our right should be heard more loudly in the right ear than the left, and so we also need Rotation information to calculate how much sound should be played in each ear. By taking the rotation of the camera in 3D space, and calculating the “look at rotation” — how much we’d need to turn to be facing the sound directly — the sound engine can calculate how much to balance the sound between the Left and Right audio channels. This won’t necessarily drop a channel to zero either, as sounds usually make it to both ears — they’re just louder in the ear they’re closest to.

Remember, this is all just calculation. The sum total of playing sounds is only mixed down to an actual output waveform when it’s finally played by a Listener.

So that’s the basics of simple 3D sound setup - the locations become attenuation, and the rotation becomes balance. Put them together, and your player can hear sounds relative to their position from you. It’s a great start! But it’s still only the beginning. If you want to make your sound immersive, you need to start simulating how sound travels through the environment.

The Environment

If you just recoiled in horror thinking about how to simulate sound in a complex physical environment without actually simulating the sound waves… good. It is very, very complicated. We need to:

1. Mimic the behaviors of the real world while:

   1. Making sure the right sounds can be heard, and;

   2. Processing sounds based on the game world to ensure realism.

2. Optimize away anything we can cull, simplify, or eliminate, because step 1 can be CPU and RAM intensive.

Wwise provides a number of tools for this, and groups some of them together using Volumes in a building block called a Spatial Audio Volume (AkSpatialAudioVolume).

Spatial Audio Volumes and Acoustic Portals

A Spatial Audio Volume is a Volume that has a number of specialized components on it that let Wwise do stuff and make calculations. Spatial Audio Volumes are used to divide the world up into smaller chunks, to both define behaviors of sound within them and how it travels between them. Without them, the engine would have to evaluate every sound in the game world individually to see if you can hear it.

A Spatial Audio Volume provides three functions, which can all be provided separately if their components are attached to any Volume:

1. A Surface Reflector Set component, to reflect and transmit sound at the edges.

2. A Room component, to contain and group sounds together.

3. A Late Reverb component, to calculate and route reverb to other buses.

Surface Reflector Sets

Wwise keeps its own internal 3D geometry of the shape of your levels to track how sound should travel through and bounce off objects and the environment.

A Surface Reflector pushes an Actor’s geometry into Wwise so it can make calculations about what should happen when sound hits it.

Surface Reflector Sets in a Spatial Audio Volume automatically construct reflectors around the boundaries of the Volume so you can configure the behavior of the room as a unit. This allows you to adjust things like:

1. How much sound “leaks” through the edges of the room (Transmission Loss)

2. How sound bounces off the walls and is absorbed, reflected, etc. (Acoustic Materials)

Example: A room in your game that’s an airlock might have its Transmission Loss set to 1 (no transmission through walls) and have Materials that mostly absorb sound. A tiled bathroom might have moderate transmission loss because of its wall thickness, but its Materials (primarily tile) would reflect back most frequencies.

At its core, a Surface Reflector Set is pure 3D geometry and nothing more. It defines audio boundaries in the game world and what happens when sounds interact with them. We don’t (usually) want to hear sounds from the entire game world. But in order to cull those world sounds so they’re not “playing” unnecessarily and consuming CPU, we need to figure out what we should hear in a given space. We also don’t want to be processing every sound in the game world separately, so we need an organizational concept that lets us group them together for more efficient culling or activation.

This is why we have Rooms and Portals.

Rooms And Portals

Internally, Wwise keeps an adjacency map of which Spatial Audio Volumes are connected to each other using Rooms and Portals. You can think of rooms and portals as links in a chain - a “propagation path” which will be walked and added up to calculate the total path between Emitter and Listener, so the Listener knows what the volume, balance, reverb, and other effects should be when the sound finally plays to the mix.

Rooms contain sounds, and they transmit sounds within them to other rooms via Portals.

Rooms

A Spatial Audio Volume “becomes” a room because it is a Volume that has a Room Component. A Portal is an entirely separate Actor (AkAcousticPortal) with an AkPortalComponent. You can create your own Room or Portal actors by adding an AkRoom or AkPortalComponent to any Volume.

Wwise uses the Room Component (AkRoom) to provide a few core behaviors:

1. Transmitting the sounds that occur inside it to other Rooms via Portals (or in the absence of a Surface Reflector Set, through its boundaries).

2. Defining oriented reverb within a space. (more on that later)

Portals

A Portal acts as a bridge between two rooms, and alters the values to be applied to a sound for the next room. In this example, the Portal lets the sound in Room 1 (left, r1) be heard in Room 2 (right, r2). The sound will appear in Room 2 (r2) from the location of the Portal.

The process of a sound traveling between Rooms goes something like this:

1. An Emitter plays a sound within Room 1 (r1).

2. The distance (and other acoustic properties) between the Emitter and the Portal (p1) is calculated.

3. If the sound would be “audible” to the Portal (p1) based on how far it’s allowed to travel, the Portal “hears” the sound.

4. The Portal (p1) adjusts the sound’s location to be coming its own location as it enters Room 2 (p2) with its new values, and optionally, lowers its attenuation if it is partially closed.

5. The Listener on the player receives the sound, calculates the total attenuation and balance from the chain, and the player hears the sound as coming from the Portal (p1) in the second Room (r2).

Optimization

Now let’s take a look at what happens when a Portal is closed.

In the image above, the engine knows there are three sounds in the first Room (r1). It also knows sound does not leak through the walls. It knows that the Portal (p1) between Room 1 (r1) and the Room the player is in (r2) is closed, so it determines not to play those sounds. The engine is able to temporarily ignore anything in Room 1 (r1) by evaluating just the state of Room 1 (r1) (no wall transmission) and the Portal (p1) (closed).

By evaluating these choke points in our tree of connected Rooms and Portals (propagation path), we can cull entire areas of the map from audio that we know aren’t relevant — and stop any processing on them — with math alone.

Ambient Sounds

We talked about sound emitting from locations and about sound distance from Portals, but what if we don’t want sounds to play from a specific location? What if we want the quiet hum of an air conditioner to play gently anywhere in a Room? This is called “Ambient Sound” and it’s treated a special way inside Rooms.

Usually, an Emitter (AkComponent) has a specific position in 3D space that a sound plays from, and its volume and balance are calculated for the Listener relative to that location.

Ambient sounds played on a Room play at a consistent volume and balance no matter where you are in the Room. Attenuation profiles on a sound playing inside a room will not apply until that sound exits the room via a Portal. After it exits via a portal, it behaves as in the earlier example - a Portal (p1) that “hears” an ambient sound in one room (r1) will then rebroadcast that sound with itself as the origin point. So, if you’re standing in the adjacent room (r2), you will hear the ambient sound as coming from the Portal (p1), as the volume and balance to the Listener on the player/camera calculate it from the location of the Portal.

Wwise note: In Wwise, you don’t actually trigger sounds directly — you post an Event which references the sound and tells it how to play. Events can be used to start or stop specific sounds, play loops, or trigger other arbitrary actions.

If you want a sound to play ambiently in a room, there’s a field in the AkRoom for an AkEvent which triggers playing a sound. Optionally, there’s a checkbox for “auto-post” which means it will post the event when the game starts (on BeginPlay).

Ambient Spaces Outdoors

If you want a particular space to have an ambient sound in and around it, there’s an option in the AkRoom to make it a “Reverb Volume”, which changes the rules a little. The sound will play ambiently inside the space, but emit outwards in all directions from the room without connecting Portals to do so. This is useful for outdoor spaces where you want an area to have some particular sounds (like birds coming from non-specific trees in one area in the park), and also want that to tail off smoothly as you walk away.

Other Rules About Rooms

• Rooms have a priority value to allow you to nest Rooms inside of other Rooms (highest wins). For example: You might have one Room volume for the entire inside of a warehouse, with another Portal and Room inside it in the corner representing the inside of an office.

• If a sound is played and it’s not inside a Room, it will fall back to the default “Outdoors” Room.

Late Reverb

The final feature of a Spatial Audio Volume is Late Reverb, which is mostly beyond the scope of this article. It lets you calculate reverbs and echoes that occur within the Volume, and send the resulting sounds to a separate bus output so you can control how and when it’s heard. This is useful during the later stages of tuning how your level sounds.

The Core Lesson

The thing to really get across here is that we are defining — in software — a logical chain of objects and their properties between an Emitter and the Player. Traversing this list allows the sound engine to:

1. Determine if a sound can be heard, and do nothing if it can’t.

2. Build a list of property changes and effects to be applied to the sound when it is finally played.

The sound is never actually played unless Wwise logically determines that it can be heard by a Listener that can play it to an output. All we are ever doing is feeding the sound engine the information it needs to make those calculations and apply the appropriate changes/effects during final playback.

Unreal Audio Tips

Here’s some other stuff you might find useful as you start to get into it:

• If you want to play a sound from a particular Actor, post the Play Event to the Actor.

  • If the Actor has a child AkComponent, it will play back from the first one found.

  • If there is no existing AkComponent, one will be created on the Actor’s root component.

• If you want to play a sound from a particular Actor Component, post the Play Event to the Component. An AkComponent will be created if one does not exist as a child of that Component.

• If you have a reference to a specific AkComponent that you want to play sound from, you can post the event directly to that AkComponent.

• Destroying an actor that has a sound playing from a child AkComponent will stop any sound currently playing from it, because the Game Object Id playing back the sound no longer exists.

• You don’t actually need one AkComponent for every possible place you might need to play sound from. There is nothing stopping you from simply moving one AkComponent around programmatically instead of having one at every location.

  • For example: If you have a large segment of electrical wire that you want to emit an electrical “buzz”, instead of placing Emitters all the way along the cable, you might have three Emitters that move along it with the player so that the whole thing appears to be buzzing.

• You can also just play a sound at any random location using the Post Event At Location. This plays from a temporary Wwise Game Object which is immediately destroyed, and no AkComponent is created because there is no parent actor. This is a cheap way of playing a lot of short-lived sounds with little overhead.

Unfortunately, It Gets Way More Complicated

You now have the basics on how to play sound and how to structure your levels to get approximately the result you want. The issue, however, is that in the real world, sound is far more complicated. Ever thought about how sound reflects more off tiles than it does wooden walls? Or how the bass from a car stereo travels further than treble? What about how a car backfiring in the city can echo back several times as it hits different buildings?

There are so many things you can simulate in order to make things sound “real”.

The simplest is diffraction — how sound moves around the edges of objects in the audio geometry. It too can be calculated with math.

What about moving through large environments like a city, where different buildings and obstacles are meaningful distances from your sound source, like a gunshot? Sound takes time to travel, so the reflections of that sound are going to arrive back at different times and with different properties.

If you have a system that simulates and adds rain noise when you’re outside, it won’t be enough simply to add an ambient “rain” sound to the outside volume. If your game has objects that you can shelter under (e.g. bridges, bus stops), you may also need to be checking line of sight to the sky every frame, then use Real Time Parameter Controls to adjust the properties of the rain sound to dampen them.

Do you have plants that would absorb sound in your level, like the indoor park in Prey (2018)? Can you fit them all in the geometry that you send to the sound engine with the amount of RAM you have available? Will you need to use simplified geometry for sound purposes? How will that be stored?

If you’re doing something sufficiently complex, you’re going to run into the limits of your hardware way faster than you expect. If you just place an AkComponent on everything that could ever make sound, you’re going to run out of memory and CPU fast. You may need to start writing your own code to optimize, cull, emulate, and manage what you can afford to keep in memory and executing in CPU.

If you want to dive deeper into just how wild game audio can get, I recommend checking out the GDC talk by David Osternacher and Alex Riviere, Everything is Connected: Ambient Sound in 'Avatar: Frontiers of Pandora'. They have thousands of emitters making sound throughout a forest, and the level of detail is quite frankly stunning.

And if you haven’t gone completely insane by the end of all this (or you don’t have access to the GDC Vault), check out Robert Bantin’s talk Finding Space for Sound: Acoustics in 'Avatar: Frontiers of Pandora', which digs into techniques for creating realistic, immersive in-game sound through reverb, diffraction, and a tonne of other things you can simulate.

The rabbit hole of game audio is as deep as you decide is important for your game.

Summary

We’ve covered a lot here, but it should be enough for you to at least get started using Wwise with Unreal.

To recap, here’s a quick hit list of the most important stuff:

• Sounds play by having an Event posted to a game object.

• Sound play notifications come from Emitters and are received by Listeners that play the actual sound.

• Wwise calculates how sound travels between the Emitter and the Listener using math, instead of simulating the reality of sound.

• The path can be affected by geometry that the sound engine has been informed about by AkGeometry, Surface Reflectors, Spot Reflectors, or Surface Reflector Sets.

• Rooms organize and group sounds together to make it more efficient to determine what the player can hear and unload / not process anything that they can’t.

• Rooms can contain Emitters and also be Emitters for ambient sound.

• Portals create a propagation path so they can bridge sound between rooms.

• Posting an Event to an AkRoomComponent will make it play ambiently inside the room.

Until next time.

// for those we have lost
// for those we can yet save

I could make programs and web sites, but the user logs I was seeing for my creations were baffling. I did not understand why people clicked the things they did, typed the things they did. I tried things, watched what happened, guessed why, but consistently made fundamental attribution errors. I would add features but was often wrong about what the results would be and could not understand why. By the time I was 20, it became obvious to me that I needed to understand how people worked before I could ever hope to understand why they were doing the things that they were doing.

The more I studied psychology and learned about the brain, the more I came to understand that despite the differences in individual people, there are commonalities in how people work. By seeking to understand how people experience the things we make, we give ourselves formal tools to both predict how people will react, and to fix it when our design intent doesn’t match the effect.

Today we’re going to go through the State Machine Model — one such tool for understanding how people experience things and react — and learn how to use it in practice to solve game design problems both pre-emptively and reactively. With any luck, you’ll be ready when you hear someone in Insights mutter the most cursed sentence in game development:

“Why are players DOING that?”

Let’s start with a real world example we can learn from.

Elden Ring

Elden Ring was the first FromSoft game for many players. There is a tutorial that you get to by jumping in a hole early in the game. However, in the initial network test, they found that many players were missing the tutorial and immediately struggling to play because they never learned how to do basic combat. They knew FromSoft games were “difficult”, so they just assumed their struggles with combat were intended, and they were absolutely not. It was intended that new players would jump in the hole, but the hole was very deep and with no sense of how much fall damage they take, many people just didn’t think that was even an option.

This is a video of the first closed network test. From 4:59, you can see the player reads a message “The Cave Of Knowledge lies below”, has no idea what it means, can’t see the hole, and walks straight past the tutorial.

This is the version that was released on launch day with 1.0, and you can see how much this area has changed, and how much more it’s been flagged.

The basic work that was done here:

1. Added an NPC ghost that said “Brave tarnished. Take the plunge. Of learning, and remembrance. Recall the arts of war. And your warrior's blood.”

2. Additional lighting to let you see the lip of the hole.

3. (not visible in this pic) More rocks were added below the drop to imply that the jump could be made without dying.

This helped the problem, but didn’t fix it, and players took to social media to complain about not being taught the basic mechanics. When they found out they’d missed a tutorial, many were annoyed.

Some people read that text and didn’t think ‘tutorial in hole’. Other new people read it and they’d heard that FromSoft NPCs lied to you, and assumed it was a trick. Between vagueness and knowledge obtained outside of the game, they did not understand the choice being offered, and subsequently missed it.

Whenever there is a gap between the intent of a design and the effect of a design, we need to deconstruct the problem in a way that gives us tools to map both of those things so we can find what the gap was. The State Machine Model gives us tools to identify these gaps by modeling players as a kind of state machine.

What Is A State Machine?

A state machine is a representation of a process that is “stateful”. A stateful system has memory - past actions of the system can affect future actions of the system. Games can be considered to be state machines, as can the individual actors within them with their various AIs or health pools or etc. This is in contrast to a “stateless” system like a static web site where every click on a link returns a fixed web page, and it does not matter which order I click on them - the same input will always return the same output.

State machines are a common computer science problem, and so to model player behavior as a state machine, we need to track their personal states, the inputs they receive (images and sounds), the knowledge they hold, and understand the processes that happen in order for them to perform output (pressing buttons). Most importantly, the thing people are currently experiencing can affect this process, and also affect future responses to things that they experience.

The entire process a person goes through when receiving the output of a game looks something like this. This is a simplified version:

The first step in understanding this model is one of the first things we learn as children: discovering that people are different from each other.

Theory Of Mind

Before we can get to the model itself, we need to start with Theory of Mind. Theory of mind is, at its core, the fundamental understanding that different people hold different knowledge. Children generally begin developing an understanding of Theory of Mind around age five, and there is a very simple test you can perform that will determine whether a child has gained this understanding.

Acquire two children, somehow. Set them five feet apart, then show the first child this box, and ask them what they think is in it.

They will answer “Smarties, of course”, and probably feel quite proud of themselves.

Then, open the box to reveal a surprise - it is not in fact Smarties. It is full of pencils. Then ask that child what they think the second child, who has not seen inside the box, thinks is inside it.

If they answer “Smarties”, they have passed the test, having gained the understanding that another human who has observed different things can hold different knowledge based on those observations. If they answer “pencils”, they have failed, because they have not yet come to separate their consciousness from that of others.

This test triggers a knowledge change in a child that grants them understanding they previously did not have, and asks them to remember their previous state, then project that onto a second person.

But people are more complex than their knowledge, so Theory of Mind alone is insufficient for explaining player behavior.

While we like to think of ourselves as in control of our own minds, the classical conditioning of Pavlov’s Dog applies to people as well as it does animals - if you ring a bell every time before you feed a dog, its mouth will begin watering upon hearing the bell, because the brain has learned to associate the sound of the bell with receiving food.

In a past relationship, I lived in a small apartment with my now-ex, and our computer desks were behind the couch. She’d tap the back of my chair twice to let me know she needed to get past, and I’d pull my chair in. Years later, someone at work tapped the back of my chair twice to get my attention while I was coding, and I instinctively pulled my chair in without even thinking, because I’d unconsciously trained that reaction. I didn’t even realize I’d done it until they mentioned it later.

The most important thing here is that we don’t automatically know why we react the way we do. In the moment our brains and bodies simply react due to our past experiences. We can learn about ourselves, our patterns, our habits, and then apply that information to understand why we felt something, or did something, but it is a reverse-engineering process. And since we don’t inherently know why our brains respond the way they do, it means that we need to learn about ourselves through observing our own output, and the output of others, in order to understand why we react the way we do. And while everyone is different, there are commonalities to human experiences that we can use to help us make better designs.

Much like our Elden Ring new players in the network test, we need to watch how players act, react, and observe their output in order to understand why they reacted the way they did.

But in order to understand why people react, first we need to understand how they react.

Part 1: Stimulus and Perception

The Theory of Mind test has prerequisites - for example, knowing what smarties are (or at least being able to read), being able to see, and not having done the test before.

When we think about perception, we tend to think of merely seeing something and skipping straight to understanding, but there are two parts to it, which are demonstrated through two problems.

Imagine that we show two adult humans a painting. One art.

Problem 1: Bodies are different. You can show two different people the exact same picture, but differences in their physiology can mean that the image they receive is not actually the same.

Problem 2: Even if their eyes are identical, and the image their brain receives is the same, people’s brains filter the stimulus they receive differently. We will all notice different things about the painting based on our experiences.

Finally, we react to the thing we’ve seen. We might have learned something, or felt something, and our state changes based on the result of that.

In its simplest terms, the brain interprets input while also being changed by it. Two people with different experiences of the world have had their brains trained differently and thus will extract different versions of what is important in the raw input they have just seen, and react differently, and learn different things from their reaction.

An artist may see a painting and may instinctively notice the framing, the construction of the characters, and the use of light to guide the eye. A narrative designer who saw the exact same thing may not notice those implementation details but have a greater understanding of the vibe and what it does to a person.

Part 2: Response and emotional state

What if the child is familiar with the test? They may experience a sense of excitement at a problem they are aware of, and feel a burst of satisfaction, dispensing dopamine and other happy chemicals. A child unfamiliar with the test may experience similar excitement thinking they’re getting Smarties, followed by disappointment when they learn that there are no Smarties waiting for them.

The child, having perceived the input, has an unconscious and immediate reaction that is different depending on their past experiences. We can see again that how we’ve been trained can dictate the emotional response, which in turn affects our state, and how all of our internal mental processes behave.

This can be tested on almost any gamer of a certain age by playing them the scream of the Poison Head Crabs in Ravenholm from Half-Life 2, on any engineer who’s been on-call by playing the Pagerduty alert sound, or on any developer by playing them the tak-tak sound of an incoming Slack message. Before they’ve had a chance to think about what they’ve heard, they’re already experiencing stress, or fear, which by experiencing it again strengthens the brain’s pathway that triggered that response, and makes it easier to experience again.

Thing is, this response can affect a person’s physical state as well, and our physical state affects how our brains work. In the famous Capilano Bridge Experiment, researchers found that men who encountered an attractive woman in a situation where their heartrates were elevated were more likely to call her afterwards. The response to the situation affected their physicality affected their emotional state, which affected their behavior.

We can see on the diagram of the state machine that our Response flavors the current action, and future actions.

Part 3: Accessing and adding to knowledge

You need to know something in order to consciously analyze it. The act of perceiving something may add new knowledge to a person’s total knowledge pool, which then can be used for Analysis.

However, the Capilano Bridge Experiment shows, the Response step can give rise to emotional stimulation which affects the state of the brain, and again, colors what Knowledge can and will be accessed, and can change a person’s behavior. Stress often causes reduced access to memory, and thus the accessible knowledge may be reduced. In some people it can cause more acute memories. We always arrive at Knowledge, but how we arrive there is colored by our Response and what we already Know.

If I watch a movie I’ve already seen, I may find myself noticing things I didn’t notice the first time, because my Knowledge component isn’t as fixated on absorbing the core of the what’s being presented, and may let me focus on different details.

Part 4: Analysis

Now, having received input, translated that into brain input, felt a certain way about it, and had it collide with things we know, finally we arrive at Analysis. This too is not always a conscious process - we are not rational actors nor are we perfect information analyzing machines.

We’ve been trained by the things we’ve experienced in the past and our state has been flavored by the thing we’re currently experiencing with the context of those past experiences. When making games, we have players who usually have experience with other games that they will bring to ours. We have to be aware of conventions, because if you suddenly make a traffic light “red” mean “go” instead of stop, you’re asking people to unlearn a lifetime of “red light means stop”.

Part 5+: Action

Finally, our stimulus gets converted to action. If you’re playing Half-life 2 and you see a red dot on the ground near you, you know there’s a rocket launcher being trained on you, and might immediately begin moving the mouse to preemptively return fire or run for cover.

All of this happens automatically, and near-instantly. Depending on our level of immersion in the game (or whatever we’re experiencing), we’re taking action in sub-second intervals. In League of Legends you may be clicking six times per second, but the instant you hear the telltale sound effect of Morgana firing a Dark Binding (crowd control skillshot) at you, your next click is likely perpendicular, moving horizontally away to avoid it. You may even instinctively flash if your experience tells you that the binding is unavoidable, and that being hit by it will result in your death, so you need to use a high-cooldown blink to escape.

Here’s a hypothetical example in which we understand that some CC is coming at us, and we need to dodge it immediately.

1. Intent

   1. What happens: My brain has output a course of action that I will now attempt to take. This is based on all of the previous steps and modifiers.

   2. Outcome: “I need to flash to dodge this!”

2. Unconscious Actions

   1. What happens: My body reacts to the input without me consciously planning to do so.

   2. Outcome: Tensing my shoulders in response to the danger, perhaps gasping from surprise.

3. Instruction To Act

   1. What happens: Conscious actions to convert Intent into Physicality

   2. Outcome: Attempting to move the mouse perpendicular to the incoming CC, and attempting to move my finger from hovering E to pressing F. This may happen very quickly because I’ve flashed a binding a hundred times, or it may happen very slowly because I need to think about it because I’m new and this isn’t muscle memory yet

4. Action Taken

   1. What happens: The combination of 2 and 3; what the body actually did. Because I’ve now moved my muscles, this can also affect the body’s physical ability to respond by tiring or training them, so I may respond differently in future intentionally or strain my wrist and slow future movement. Or my hands might just not do what I told them because I’ve been tensing for 20 minutes because it’s a stressful game ie. affected by past Responses.

   2. Outcome: My right hand moved up and to the left. My left hand pointer moved from E to F and pressed the key to Flash out of the way.

Our final physical reaction is a byproduct of all of the states and processes up to and during the current thing that’s happening.

The Final States

If you’re still reading, good for you. This is an insane amount of detail into something most people do not simply ever think about, and if you’re still here you’re either really into understanding people, or really committed to making better video games. Good for you, probably.

Now that we’ve learned about what processes people go through:

1. Perception

2. Response

3. Analysis

4. Action

And, that there are three states that are affect those processes.

1. Physical

2. Emotional

3. Knowledge

Game Design For The Human State Machine

By focusing on which of these we plan to affect and when, we can design games that impact people. As a case study, I like to use a very simple game of mine: An Easy Fix.

An Easy Fix is a simple twine game about a very bad day that I had trying to fix a time-critical bug, and engineers all over the world have cursed at me for raising their blood pressure.

It has one input: choosing what to do or say in any given passage.

It has two outputs:

1. What happened based on my last choice

2. What time is it currently (ie. how much time is left before everything is ruined)

When a choice makes something happen, new knowledge is added to the player’s Knowledge pool. When a choice causes time to pass, the clock ticks up, closer to the deadline. This creates an Emotional reaction of time pressure, which affects Physicality via stress.

On my first pass making the game, it was frustrating (intentional) but kind of boring (unintentional). It didn’t reproduce the actual tension of that day. I realized that this wasn’t the fault of the writing, it was simply the missing the component that actually made the day tense: a countdown to failure against a task of unknowable complexity.

When I added the timer, everything changed, and suddenly it was doing exactly what I’d intended. I had only been adding to the Knowledge Pool, but I needed to be incrementally adjusting the knowledge pool to affect the Emotional state. When retroing this, I realized I could have added the slack message sound to stress people out further, which was my intended experience. It was a valuable lesson.

Training, Onboarding, and the First Time User Experience

The first time that you play Dance Dance Revolution, you are probably standing in the center of the mat, like the tutorial showed you.

When you see an arrow coming up the screen, you might notice that, realize you have to stomp on an arrow, look down to see where the pad is in relation to your foot, then move your foot to it, then move it back to the middle.

The tenth time, you might have realized it’s not tenable to make three movements per arrow, and instead start with your feet on the pads. You might be used to alternating which foot moves so it’s more like dancing, left right left right, rather than simply moving the same foot over as new players do.

The hundredth time you’ve played it, you might recognize entire patterns of moves which you know to be Ladders or Crossovers. You might be able to glance at this screenshot and know that Player 2 (right) is hitting the down arrow with their left foot, because their right needs to hit the next Up arrow in order to set up the walk for the rest of the pattern on-screen, otherwise they’d need to either hit two successive notes with their left foot and break their rhythm, or spin around backwards to continue alternating, which looks very cool but is harder.

Even the default ordering of songs in DDR is intentional - each subsequent song at each difficulty adds new Knowledge about these patterns and what they mean for us. There’s also an obvious Physical component - a new player who hasn’t had these muscles trained isn’t going to be able to jump into higher difficulty songs because they might just not be fit enough to keep up with the stomping requirements. On an individual song design, you need to think about which sections are uptime (high intensity), which are downtime (space to recover), how we’ll manage our player fitness, and when and where to test it.

An easy-to-read but high-step-count set of Ladders might push our player Physicality while groups of skipping with high variance in rhythm might test their Perception in mapping those to actions.

Helldivers 2

You might then load up Helldivers 2 and despite a lifetime of Dance Dance Revolution, struggle with reading lists of arrows that are horizontal instead of vertical. You might also make that conversion quickly, and find yourself calling down Stratagems faster than anyone else on your second session.

You can see pretty quickly that when we’re dealing with games, we’re almost always dealing with precedent, because most people who buy a game are not buying their first game, so they come with the knowledge they learned playing other games. You have to design both for players with different sets of pre-existing knowledge.

An Imaginary ARPG I Just Made Up: SwordJammers

Say you’re working on the initial design for an upcoming ARPG called “SwordJammers”. You want to use combos in a particularly new and innovative way, and you’re trying to figure out if it’s worth it. A player new to the genre may pick every version of how combos work at roughly the same speed because they have to learn something new anyway, but an existing player may have transferrable knowledge that speeds up the process.

That same existing player may experience friction between their existing knowledge if they’re used to them working differently, as now they have to adjust the muscle memory they’ve already built up in other games. This friction may be increased if SwordJammers is the third in a series, and you’ve spent two whole games training fans to play a certain way then pulled the rug out from under them. Figuring out what knowledge exists in the player and what their expectations are is part of the challenge of teaching people your game.

This becomes increasingly more complex when you realize that sometimes, training people to know how to do what they need to before they need to do it may not actually be the goal.

Say you have particularly complex combos that need to be performed quickly in certain situations. If those skills and responses haven’t been trained and ingrained in the player, they may not be able to perform those complex moves, and you might find out that in the moments they really NEED powerful combos, that most players are simply not using them because they don’t have the muscle memory built up. You may only discover this through telemetry when you realize they’re not leveling up those abilities because they just don’t use them.

So what do you do? You may decide that in the area before these become mandatory, you will put in a handful of enemies that encourage and repeat the action of inputting complex combos in low-pressure situations such that the brain and hands are ready to go when the moment calls for it. However, you might also decided the opposite - that it’s the concept of combos that need to be taught, and that the challenge is supposed to be looking up, planning out, and mastering the right ones.

Will I add Knowledge? Will I try to increase recognition during Perception? Will I train their Physicality to have muscle memory? Do I need to give them a rest so they’re relaxed Physically and not tested Analytically right before the big fight? Will I try to increase Analysis? Which of these systems are being tested, how much, and why?

There is no Right Answer that universally applies, because every answer produces a different experience. Deciding what experiences to create and figuring out how to create them IS the job.

Tracking The Human State Machine

Wherever you go, the sky is the sky, and people are people. All people are different, which means that creating a universal experience is impossible. This is part of the reason that I say writing well is more difficult than programming well, because programming has a predictable deterministic compiler, but writing must be passed through the ad-hoc conceptual maps of reality created for themselves by an infinite number of different people with different versions of the core parts of life training their brains while equally infinite numbers of good and bad things randomly occur.

If you are making a game for everyone, you are making a game for no-one. Your game has target demographics and it has people it’s designed to appeal to. While serving each of these cohorts you will make assumptions about their Knowledge Pool, their Emotional state, and their Physicality. If you are releasing a new MOBA, you can assume that some portion of players will be bringing their Knowledge and Physicality over from League of Legends and DOTA2, but you’ll also have new players unfamiliar with the genre. But for all of them, you can determine that by 40 minutes into the game when people are getting one-shot by assassins, they will be emotionally tense. You must onboard people from whatever states you decide are worth your effort to invest in.

Tracking this in an absolute, objective manner is impossible. You’ll never have the exact same response from any two people, but by speaking in generalities about the kinds of people, the demographics, the cohorts, you can begin to figure out how to create what you want to create. Games are a special case for this, because unlike a film or a song where you can at least be assured that everyone is experiencing roughly the same stimulus, player actions change what they see and hear. For most, it’s impossible to guarantee that any two players will even experience the same stimulus.

Everything we get our players to experience affects their knowledge pool, their emotional state, and often their physical state. We are training their brains to respond in the ways we want, to deliver the experience we want to create. The challenge, then, is to design our games and systems such that we induce the results we want in the people that we want them from.

And that, dear reader, is on you to solve.

// for those we have lost
// for those we can yet save

One year, there was a Nintendo party where I got a heap of old consoles and emulators and set them up all over the house, something like 10 screens in total, everyone came in costume of their favorite Nintendo characters. Another year, I ran a mini-festival, invited four bands, and after they played their sets, they started taking requests. “Who knows [such and such a song]” and people from various bands would jump on whatever instrument and try to play it from memory.

If these seem like they have divergent audiences, it’s because they did. I had my friends who played video games and tabletop, my music friends who played in bands, and my work friends who were all network engineers, and I noticed that even in these party situations, the groups rarely interacted with each other.

That’s what sparked the idea for a social game party that would encourage them to mix.

A Social Rock-Paper-Scissors Battle Royale

I made hundreds of badges, each with a picture of either Rock, Paper, or Scissors, and put them in buckets behind a desk by the door. As people arrived, they were issued three badges, either Rock, Paper, or Scissors.

The rules were simple:

• You may challenge someone with a badge that your badge “beats” to a game of Rock Paper Scissors.

  • You “bet” your badge against your opponent’s badge.

  • Best of three wins the opponent’s badge.

  • A challenge could not be refused.

• The beaten party could request a rematch, but had to bet double the previous bet ie. playing for two badges.

  • A rematch request could be refused.

  • Any type of badge could be bet on a rematch.

  • This could continue to happen as long as people wanted, each time doubling the number of badges on the line.

• The winner would be the person with the most badges at the end of the night.

The Twist

This is where it got sneaky.

When you started, you got three badges of the same type. By selectively weighting which types of badges were distributed to people from which social circle, I was able to make it so that while it was possible to play a little within your own group, you needed to go outside it to get a lot of matches. This worked exactly how I’d imagined - groups played within themselves at first, but quickly found themselves exhausting their pool, and looked for more opponents. The groups began to mix, and the previously disparate social groups drank, competed, and bet more and more against each other.

If you lost all your badges and wanted to keep playing, you could request more from the secret stash behind the counter.

The Outcome

By the end of the night, all of the reserve badges were gone, and almost all the badges were concentrated on two people, creating a massive grand final surrounded by drunken cheering, and both went all-in on one final best-of-three.

I don’t remember who won. It wasn’t important. What was important was that the design of the game was explicitly crafted around affecting player behavior to influence movement around the house and which other players they interacted with. When it was over, we did what we did at the end of every party and fell back to the one activity that sated every ground: playing Rock Band on a full suite of instruments.

It was a success by every metric. By the end of the night, the badges were ALL gone, everyone had played the maximum amount possible and aside from the badges people stole for posterity, the game ended with no-one else able to challenge the winner.

That night formed many new friendships (and a few hookups 😘) and represented a major social shift in the social makeup of the groups. The music crew and the gaming crew partially merged and began to hang out outside of my gatherings. The tech crew didn’t integrate as well, but did have some fringe overlap with the gaming crew, and that also formed some new friendships. The more introverted folks took more time to join the fray than others, but after a few drinks and a few matches, still mingled outside of their circles, which didn’t usually happen.

Subscribe now

The Retro

This was a rousing success, but that doesn’t mean there weren’t lessons to be learned. I retro’d this, because of course I did, to see what I could have done better, and figured out a few missed opportunities.

• Learned: People had a bias towards which badge they wanted to start with.

  • This makes sense as most people default to a particular move in RPS.

    • Do differently (Art): I could have influenced this by doing better badge design to appeal to each intended group e.g. album-art themed for scissors for music, D&D themed for rock, tech-themed for paper.

• Went poorly: There were not enough snacks.

  • Do differently (MTX): I could have encouraged people to bring snacks by offering snack tokens to exchange for additional badges, which people wanted.

    • This would require getting something previously unavailable so perhaps needed to add a time gate like ‘no replacement badges in the first hour except for via snack token’.

    • That would need to feel optional so as not to appear greedy or demanding.

• Learned (via Feedback): The idea of not being able to refuse a challenge made some of the more introverted people uncomfortable, but ultimately they came to enjoy it.

  • This was primarily a perception issue but could have been a trust & safety issue if I had less trustworthy friends.

  • Fortunately everyone was reasonably socially competent so they tended not to bother people who didn’t want to be bothered.

  • Do differently (Social): I needed a mechanism via which people could set themselves to be ‘off the table’ for challenges.

    • Perhaps ‘visible badges’ and you could hide them with a coat?

      • Brisbane winter is cold enough that indoor coat usage is viable.

    • Alternately, a flippable state badge for red/green. This would have required more effort and for me to start this process more than two days before the event.

How This Applies To Game Development

Wherever you go, the sky is the sky and people are people.

Changing the method of the game adjusts your tooling. When designing physical games, you no longer have a computer to track state and enforce rules. Instead, state is tracked physically and rules are enforced cognitively. Both of these things create player burden.

A game for drunk people in a social setting needed to have rules that were trivial to enforce, and state that was trivial to track. The known mechanics of Rock-Paper-Scissors required no learning, so there were only two new systems for players to learn:

1. Matchmaking

2. Progression

When designing player-facing game systems, you have to think through how players are going to:

• Interpret what they’ve been presented with

• Think using that interpretation

• Feel about that interpretation

• Act based on those thoughts and feelings

I call this “human state machine modeling”, and it relies on the fundamentals of how people experience things to create experiences. It’s the fundamental way that I approach design, and it applies to everything from game design to copywriting to internal process design.

Stay tuned for a deep dive into that in a future post here on Load-bearing Tomato.

The future delivered: “How People Experience Things.”

// for those we have lost
// for those we can yet save

It is fitting then that I chose today to talk about staffing, and specifically, a phrase I heard for the first time at on Dauntless.

“We only hire seniors.”

On the surface, this sounds like it could be a sensible policy in a AA studio. With a limited maximum headcount, surely you want the most capable individual contributors?

I counter this logic with one single question.

“When was the last time you saw a major failure in game development caused by a lack of skill in a individual contributor?”

Was it… never? I can’t think of a single instance. When I look back over my long and storied career spanning both tech and games, I can point to failures caused by poor organizational management, disorganized operations, failures of individual managers, communication issues, production issues, lack of leadership, lack of defined processes, but not a single time where I’ve lamented having a junior.

In order to talk about what happens when you only hire seniors, we need to first talk about how game studios (and software development companies in general) are structured, and why.

The Normal Structure

All companies run on hierarchy. If a company claims to have a ‘flat structure’, they’re lying. They have a hierarchy, it’s just undocumented. Here is a non-exhaustive hierarchy of my hypothetical game company “40 More Servers Studios”.

Obviously there’s more disciplines, roles, and departments than this, but you get the idea.

A vertical line indicates seniority - a relationship whereby the people below a role’s seniority are bound to the decisions made by the level above it.

Decisions fall into one of three categories:

1. Identifying a required outcome

2. Deciding what to do to achieve that outcome

3. Deciding how to do it

The Game Director might decide “we need two playable characters: one who is out of place, and one who is local to the world”.

The Narrative Director might decide “We are going to make a Black samurai, and a Japanese ninja.”

The manager of the character narrative team might then assign the Senior Narrative Designer to naming these characters and designing their backstories.

The Narrative Designers might then be assigned writing the individual barks, dialogue, and lines for the characters to bring them to life, in line with the design decisions made above them.

If we use the RACI model (Responsible, Accountable, Consulted, Informed) we can see that at each level, the lower level is Responsible for doing the work, and the higher level is Accountable for the work getting done. The narrative director is Accountable for the creation of characters that serves the game’s needs, and the narrative designers below them are Responsible for bringing them to life.

Every time you traverse down a level on the chart, the scope of the decisions you need to make narrows. They become more focused. You are bound by the decisions that occur above you, but you have the agency to make decisions within your area of responsibility and perform that work.

But We Only Hire Seniors?

People like the idea of “only hiring seniors” because seniors are experienced enough to make decisions, and execute on those decisions. As a senior, you often receive vague requirements and requests, and must not only translate the need you’ve been given into an action for your discipline, but also figure out how that action will be taken. There are many decisions to be made, so hiring a lot of people who can make decisions makes sense, right?

No. Let’s look at an alternative chart, where you only hired seniors.

Anyone who’s worked somewhere “We only hire seniors” already knows where this is going. There are three massive problems here.

1. There are fewer decisions arriving downwards.

2. The number of people that you need consensus from for a decision on your level has gone up by a lot.

3. The people making those decisions are also the ones responsible for doing the work.

Decisions that people should have been empowered to make now affect all of seniors, so they’re no longer empowered to make decisions. In the RACI model, you now have a large group of peers who need to be Consulted about your decisions. Every decision is everyone’s problem.

Seniors are great because they have a lot of experience, and no two people’s experience is the same. But without agency, this strength becomes a weakness because no two people’s experience is the same, so the ‘best’ thing to do and the ‘best’ way to do it can appear to be very different to different seniors. They also care more, because they are going to have to be the ones to do it. While everyone is generally very good at their craft at this level, if they don’t have management experience they are not going to know how to handle this disagreement, and will resort to the one tool they have in their toolbelt: meetings.

And all of a sudden, the calendar time to implement anything has gone up. Despite the Manager being Accountable for a task, and any particular worker Responsible, all of your peers need to be Consulted. For tasks above a particular size that may require multiple workers, the worker that is Responsible now requires people they have no seniority over to also participate in that work. Your velocity grinds to a crawl, as even things that should be simple require a lot of effective communication on, with no clear structure to define how that should happen, or who can tell anyone else what to do or how to do it.

Look at what has happened to your decision inheritance. You’ve taken a perfectly functional headcount and given it anxiety.

Subscribe now

Does It Actually Work This Way In Real Life?

Yes. It’s common for studios to build a game, release it, and then take most of the workers off the original game, leaving only a maintenance crew to keep the game going, keep it patched, make DLC, etc.

One thing that I’ve observed with terrifying consistency is that in senior-only environments, every time a team shuffles workers off for new title teams, the work output of the team increases. I don’t even mean “per person”, I mean total completed work.

This sounds insane until you remember that seniors are smart people who work best when empowered to make decisions in areas they are responsible for. Large teams of seniors around them create roadblocks that everyone within them must clear in order to perform work they should have just been able to do.

Some examples:

• A team of services engineers reduced from 7 to 2 more than doubled their work output, as measured by delivery time of requests for new services, and changes to existing services

• An engine programmer who had always run into roadblocks around addressing the root cause of high server costs and poor performance no longer having anyone to tell him to address “low hanging fruit” first was able to prioritize the medium-sized task of reworking the server core and reduced costs by millions of dollars per year.

• A designer who was able to design and implement entirely new gameplay features on their own faster than with a team, for simply not having to have so many meetings about it.

• A delivery specialist (packaging, compilation, distribution) who lost two senior peers and gained two interns able to bring forward the “drop dead date” of last call for content by multiple days by simply having people they could tell what to do, who then did it.

One side effect of this problem is decision paralysis. When Seniors who are used to making decisions just go ahead and do that, it creates problems when their peers disagree with the methodology. So you yank the emergency brake to set up meetings about work that’s already in flight, and have to discuss whether you’re going to undo it or keep going. It doesn’t take long for this to train everyone on the team that they’re unable to make decisions without everyone’s input, which again, creates delays and disempowers the people who should be making decisions.

It also creates an institutional knowledge problem, because instead of formal responsibilities for particular systems or areas of the game, people can fall into undocumented roles where they’re “the audio person” or “the one that knows about player blobs”. Organizationally, it looks like there’s redundancy, but corporate can’t see this when they’re getting ready to do layoffs, and the next thing you know, the only person who knew how your ambient sound emitters operate just got booted from the company slack.

Juniors In Action

Fresh graduates coming out of universities and colleges these days are shockingly good. They know significantly more than I did when I graduated, and they’re better with their tools. What they lack is experience in the workplace — how to operate in teams, how to communicate, how to use collaboration tools, good practices for being functional in a company full of moving parts.

You just need to tell them what to do, with occasional guidance on how to do it. This necessitates good documentation practices, since you can no longer count on ten years of experience to ‘figure it out’; you have to plan. Seniors in these situations have more than once said to me that they refused to write documentation or comment code, because “we only hire seniors” so it’s fine because people would figure it out. I do not need to explain why this is bad.

Games take more work to make than they ever have. Engines are more complex. Server infrastructure has to handle larger player counts. Players expect longer play time and higher graphical fidelity. The amount of raw work that needs to be performed has gone up by so much that Doom (2016) had over 100x more workers than the original Doom (1993).

By giving seniors who are empowered to make decisions juniors to instruct and direct, you allow them to take horizontally-scalable action on those decisions. Those juniors will probably not work as quickly or effectively as an appropriately skilled senior, but they will receive far more specific instructions and be able to act on them quickly and in parallel with other juniors on their team.

By removing decisions as a choke point in a broad senior level you increase velocity using juniors to act on those decisions.

They’re also just cheaper per person in pure labor cost! By a lot!

Also, We Want The Future To Be Bright

The final, obvious problem with only hiring seniors is that you’re breaking your progression pipeline.

Seniors are generally pretty capable, and there are very few paths for advancement in these broad teams. Most organizations don’t have advanced individual contributor tracks, and sending people who are subject matter experts straight into management is part of the reason we ended up in this mess in the first place. Knowing ‘how to Make A Good Art’ is very different skillset from ‘how to get a team of ten to Make Many Good Arts’.

This shortsightedness blinds people towards how unsustainable this is for the industry at large. If you are not bringing juniors into the industry and giving them experience, they do not ever get to be seniors. You and I will get older, we will burn out, we will retire, we will move into other industries when we get sick of layoffs, and there will simply not be enough experienced people to replace us. The attitude of only hiring seniors shoots itself in the foot with unsustainability because it prevents the kind of people you want to hire from existing.

“We only hire seniors” is a red flag of pointless meetings, thrash, and low-velocity low-satisfaction work environments, and should be treated as such.

Stay tuned for next time, where we’ll be learning about how to use the Wwise audio engine with Unreal Engine 5 by addressing the basic concepts and objects involved, and how to avoid the undocumented pitfalls that await you within.

// for those we have lost
// for those we can yet save

The term had existed for some time when it was popularized by Seth Godin with his 2005 blog post “Don’t Shave That Yak”, in which he described a series of increasingly bizarre tasks that diverge further and further from the task you’re actually trying to complete.

“I want to wax the car today.”

“Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”

“But Home Depot is on the other side of the Tappan Zee bridge and getting there without my EZPass is miserable because of the tolls.”

“But, wait! I could borrow my neighbor’s EZPass…”

“Bob won’t lend me his EZPass until I return the mooshi pillow my son borrowed, though.”

“And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it.”

And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.

I prefer a shorter definition.

“When the prerequisites for a task recursively generate more prerequisites.”

Yak-shaving occurs for one singular reason.

Lack of pre/intra-task scoping evaluation

Yak-shaving can occur when the depth of the recursion required for the original task is unknown. In practice, the first sign of yak-shaving is often having to go back after sprint planning to report “actually this task is much more complex than I first thought, and now I have to do [OTHER TASK] in order to start”. If this happens more than once in the chain of tasks spawned by the original task, you are probably yak-shaving.

The root cause of yak-shaving is a lack of understanding of the chain of dependencies involved, and those dependencies not being raised during grooming or planning when your task was prioritized and scheduled.

What should happen:

1. A need for a particular task is raised.

2. A subject-matter expert flags that the task has prerequisite that prevent the work from being completed.

3. An optimized chain of work is created, with each task listed as a blocker or sub-task of it’s parent.

What actually happens?

A Real World Example

This is a paraphrasing of a real yak-shaving incident that I was the sole participant in.

• I wanted to distribute an app in the Mac app store.

• So I needed to sign my code. (known)

• So I applied for a code signing certificate from Comodo. (known)

• Comodo needed to validate my business entity, which they wouldn’t do because that entity was not locally registered. Everything past this point was unknown work outside of scope.

• So I needed to gather materials for personal validation instead.

• I had changed my name when I got married, and the name on my locally-verifiable identity had not been updated yet, so I needed to go to the DMV to get a new driver’s license.

• The DMV would not accept my name change certificate because it was issued out-of-state, and because as an immigrant, my “foundational document” was my green card.

• My green card had also not been updated with my new name, and in order to do that, I needed an FBI background check.

• In order to get an FBI background check, I needed to get my biometrics (fingerprints) verified to make sure I wasn’t a criminal, so I had to go to a third-party fingerprinting business.

• To park outside the fingerprinting business, I needed to use a particular app, but that app was rejecting my credit card information, so I had to call my bank, and it turned out my card had been flagged for fraud and blocked.

And that’s how I ended up trawling my transaction history to validate my purchases, so I could unblock my credit card, so I could pay for parking, so I could get my fingerprints taken, so I could get a background check, so I could get a new green card, so I could get a new driver’s license, so I could validate my identity, so I could get a code signing certificate, so I could publish a completed app to the app store.

The Real Truth About Yak-shaving

Yak-shaving, at it’s core, is the recursive resolution of technical debt. That debt can occur in many forms. It can be as simple as that the process you’re attempting to undertake has simply not been done before, and you are unaware the dependencies of what you’re attempting to do.

Since we can’t simply wish our way into complete knowledge of the world and our code-bases, instead we must have strategies to manage yak-shaving. In practice, this means identifying when you are experiencing task prerequisite recursion as early as possible.

In my example, if I’d understood the depth of the recursion, I would have just registered a local business entity the second that Comodo told me I needed one. It would have been faster and easier. Instead, I went down a rabbit hole that recursively opened up further rabbit holes, and the rest of those tasks could have been completed at my leisure without blocking app publication.

Yak-avoidant scoping opens up new possibilities for how to achieve your goals. You might be able to assign multiple engineers to work on parts of the chain concurrently, allowing you to still deliver on time. You might discover that it isn’t worth the amount of time you’d have to spend fixing the system, and instead make the call to rewrite it or replace it.

Subscribe now

What About When The Chain Is Unavoidable?

When I was working on Dauntless, I needed to add a new type of Hunt to a player menu. Three weeks later, I was tearing the codebase apart, pulling out 30+ references to a kind of daily/weekly challenge system that had not been used in years, of a chain of dependencies in the software that necessitated decommissioning the system in order to update three more levels of system that all needed changes to allow for an alternate data source. It took six times longer than we’d budgeted, and it was pure technical debt. This was unavoidable, but it shouldn’t have been unknown. The work was “punted over the fence” to me by the design team, who simply wanted to be able to selectively show or hide new types of Hunts.

What I should have done was push back on the original task, and instead set up an investigation task to correctly scope the work. If I’d taken the time to evaluate it properly, since I was unfamiliar with the systems involved I would have contacted the original UI engineer who built the menu system, and they could have correctly scoped that work.

What I actually did was just start work on it, and sequentially run head first into the limitations of each of the four layers of systems that constructed the menus.

The fix is the same: Correctly scope the work so know what you’re signing up for, so you can correctly set your stakeholder expectations.

Don’t Shave That Yak

We’ve discussed technical debt before in the context of rapid prototyping. Technical debt should be resolved at the point at which the outcome that resolving it justifies the work involved in resolving it.

These four statements will help you identify if you are yak-shaving:

• The work must depend on tasks that were not known during scoping.

• Attempting those tasks must generate additional tasks.

• The work may not be delivered in the expected timeframe.

• The work may not be the the optimal path to resolution of the initial task.

Using this criteria during retros will assist you in identifying yak-shaving incidents, and once you’ve done that, you can start adjusting your workflow to prevent them.

How Do We Avoid This, Organizationally?

A short, but non-exhaustive list:

• Design your codebase in a way that takes knowability into account.

  • Remember, if you have a live game and a junior cannot fix a bug in your code at 3am without you, you are signing yourself up to be called at 3am.

• Publish high level dependency charts of how your game fits together.

  • Don’t forget to include historical context of how and why particular systems and arrangements came to be. This can be valuable and is often missed.

• Think through the entire process of a task and what it touches before you start to generate a list of dependencies.

  • What systems in the codebase does the thing I’m touching rely on?

  • Are there things outside the game code this depends on? Kubernetes, services, and deployment environments often get forgotten here.

• Be aware when you are making assumptions about how a system works.

• Have your processes allow for flagging of those assumptions for validation.

• Keeping an eye out for tasks that are recursing, and flagging it early.

—

Stay tuned for next time, when we’ll discuss my favorite red flag:

“We only hire seniors”.

// for those we have lost
// for those we can yet save

There is a 4717 line file called card.lua that contains all of the gameplay logic. A lot of people who have not done a lot of game development are laughing at this.

Rapid Prototyping

The thing is, games do not pop into existence fully formed. There’s a pitch, sure, but that’s just an idea; a space where a game might come to be. In order to discover what your game might be, you need to experiment, and in order to do that, you need to write code that will allow you test ideas quickly and easily. The process of doing this is called “Rapid Prototyping”, and it’s a vital part of the process of exploring your game idea and finding the details of the reality.

A lot of things that sound good actually just aren’t that fun in practice. Other times, things you never imagined in the pitch come to you while you’re experimenting and you pivot. Being able to pivot your design quickly is key to being able to make those discoveries. The real skill of gameplay programming during R&D is being able to find a balance between “what lets us test ideas quickly” and “what limits our ability to move forward”.

If you actually look at what this code is doing, it’s not something a simple “switch” case could necessarily do, and Lua doesn’t even have a switch case. This block of code is looking for a single sub-block to return, but the value match sometimes comes with one or more validation checks that prevent it from entering the sub-block if the preconditions aren’t met, and the work performed in each sub-block is not necessarily static either. It’s setting a couple of different variables and performing per-card functionality ONLY once the card precondition has been satisfied. A look-up table (LUT) alone won’t satisfy this as it must have configurable precondition checks and post-check actions. You are routing. You need a system.

Systems design can be tricky. Every person’s strengths and weaknesses as a developer and as a programmer will give them different approaches. Systemizing too early has several drawbacks:

1. You need to commit to a significant amount of development before you can start designing

2. Increasing design reliance on engineering resources to perform basic experiments if the system is not appropriately extensible

3. Failure to correctly predict where design will need to go can limit the execution options your designers have and shoehorn them into behaviors supported by the system, affecting design outputs

You need to make sure that you provide tools that allow designers as much freedom as they can have without breaking fundamental engineering pillars, and they need to be able to experiment quickly. When you systemize, you add constraints, and these constraints can mean that your designers either can’t do what they want without help, or worse; that they start working around your systems in ways that will cause later breakage as your assumptions are invalidated.

While I’d feel confident building a card system that could extend to the necessary potential outcomes while leaving room for experimentation, I come from a data-driven background so that’s the methodology that makes sense to me, and I have a lot of experience coming at problems from that angle. I’ve worked on a lot of F2P live service games so I’m always going to be thinking about maintenance and effectiveness, and it’s trivial for me to write those kind of systems.

But even then, I don’t always write them as a first option. Outside of my day job, I help out on indie games. The other day I was making footstep audio, and the first-pass version was to simply place sound emitters approximately where the player character’s feet are, and trigger some manual logic in the animation blueprint to fire events when the animations stepped. It passed through a series of if/then branches to figure out which footstep sound to play, and voila.

The sound designers are unblocked now, and can work on creating and tuning the footstep sounds as they see fit. It will not work for non-bipedal creatures, or anything that doesn’t share the humanoid animation blueprint. It will also need refactoring if footstep location needs to accurately reflect bone placement. But presently, the game does not need those things, and if either of them become a priority, that is the trigger for refactoring. If neither of those things occur, that simple branching logic will probably ship, because it is good enough.

Subscribe now

Good Enough

People talk about “good code” but what does that mean?

In junior infrastructure interviews, I like to ask the following question.

“You have a task to write a program to retrieve, process, and analyze game data logs (telemetry) and upload the output to a server. There are two approaches you can take to this task.

The first (hacky) will take an hour to write and four hours to run.

The alternative (structured) will take four days to write and ten minutes to run.

Which approach should you take?”

The answer, is that there is not enough information to answer the question, and in fact to ask two other questions:

1. How often does it need to run?

2. What does execution time scale off, and what is the rate of change of that thing?

3. What are the repercussions of it not executing in time / can two of them run concurrently?

If this task only needs to run daily, and it scales off records which are doubling every 12 months, then the hour-long hack version can happily be in place for 3+ years before needing to be replaced. If the output doesn’t need to be available the same day, it may never need to be replaced.

Conversely, if two instances cannot run simultaneously then it MUST be replaced after three years. If you can’t even approximately guess how the scaling factor will change, and it could potentially 6x overnight, then you MUST write the long version.

Also .. do you have four days of development time available to prioritize it? If nothing else is on the table or urgent, maybe you just do the good version straight away and never worry about it again.

It’s the dreaded senior answer: “it depends”. Code needs only be good enough for its requirements, both operational and developmental.

What Is Good Enough For Your Game?

Same answer again. It depends. Apex Legends shipped without any skill-based matchmaking. Respawn had a skill-based matchmaking engine for Titanfall 2 they could have used for Apex Legends, and decided not to. When it became apparent that new players who found matches too difficult OR too easy were quitting more than players who had an average challenge, they successively shipped small changes that siphoned these players off to give them an appropriate challenge, and retention improved. It wasn’t for a full three years that they hit a point in the game where it was worth bringing in a full skill-evaluative model, and even then they found that a full performance analysis produced about the same effect as rating players on ‘damage dealt’. Because Apex has a high TTK and is latency tolerant, it was good enough.

So was this good enough for Balatro? All signs point to “yes”. The code isn’t running frequently, it’s easy to read, easy to maintain, and the game seems to be reliably handling 50+ status effects active simultaneously. In fact, I can’t think of any bugs I’ve seen anyone talk about that might be related to this code.

Would I have done it that way? No.

Would I, upon reaching the inflection point where there’s been significant investment in that method, advise refactoring? Also no.

It’s not efficient from a Big-O perspective, but why does it need to be? It’s within spec, and it was efficient from a design perspective because it allowed for rapid prototyping of cards before the design was locked in. And it scaled well enough to last to completion of the game. The code did what it needed to do at every stage of development.

So when people say it’s “bad” and say it should be [alternative solution], I have to ask; why do you need to? At any point in a development cycle, you should be doing the most valuable work that you can. At what point would refactoring that be the most valuable work, and what would be the benefit?

These are questions you should be asking yourself about every piece of work you commit to. This is not a college assignment where you get marks for approach. You are shipping a game. Do the work that enables you to achieve that.

Until next time.

// for those we have lost
// for those we can yet save

A woman was taking a walk through the forest when she came across a gate blocking her path. It stood four feet high, and from either side, a fence disappeared into the brush. She tried to climb over the gate, but as she did, her pants caught on a burr and tore, cutting her thigh. She cursed in pain, falling to the ground on the other side clutching her bleeding leg.

"This is stupid", she cursed aloud, "Why is there a gate in the middle of the forest? It is no taller than a child anyway, and on public land we should be allowed to move freely."

So annoyed was the woman that rather than continuing her journey, she decided to do something about the gate. Taking a deep breath out, she wrapped a hand around the pendant on her necklace and offered a prayer to Liber, god of wine and freedom, that she would impart the gift of freedom to whomever might find the gate. She picked up a nearby rock, and began smashing at the gate's hinges. After a few exhausting minutes, she had broken the gate from its mounting, and it fell to the ground with a crashing thud that echoed through the trees. Puffing, she dragged the broken gate to the side of the path, and collapsed on the leafy ground, exhausted.

"This gate was so heavy! Why would anyone build a gate like this in the middle of nowhere!?"

But over her pounding heart and churning breath, she began to hear another sound - the galloping thuds of a beasts hooves. She sprang to her feet and looked up the path, finding herself facing down a wild pig, five hundred pounds and four feet high, the same height as the gate, running at full speed directly towards her. Immediately realizing her folly, she began wrenching and tugging at the now-fallen gate, to try to reattach it, but it was too late. The hog slammed into her at full speed, sending her tumbling like a rag doll as it escaped its enclosure, heading towards the freedom Liber had offered it.

As she lay on the forest floor, half-unconscious and delirious in pain, she quietly offered a prayer to Feronia, the goddess of wildlife and health, that she would never again tear down a gate until she knew why it had been erected in the first place.

// for those we have lost
// for those we can yet save

Subscribe now

Hobbyists: you will lock yourself out of your Perforce server.

Anyone who’s been even remotely adjacent to any kind of programming has probably heard the name “github”, or at very least “version control”. Version control is a way to collaboratively store work and edit history on files to allow many people to work on the same thing at the same time while tracking changes.

In game development though, we mostly use Perforce, because of how it handles large files, and that much of our work involves binary files rather than plain text.

Hobbyists and people getting their first projects set up can get away with a default local perforce server, but if you want to start working on something from other locations, or get your friends to join in, then you’re going to need authentication.

“Sounds great”, you say, “I’m in”.

Perforce is really easy to set up and get going because it’s default settings are very open. A user will be automatically created for you if you try to do anything. Passwords aren’t required. That’s fine for running a private server on your network, but you want to share one with your friends, and you know better than to put a server on the public internet with no security.

So you set a password on your account - the only account - which is also the admin account. You’ll disable automatic account creation. You’ll set the security level to 1, to enforce having passwords.

Then you’ll forget about your game for six months, not log in, and forget your password, and you’ll be screwed because all the Perforce documents assume that you have the ability to log in as SOME other user, which in a studio situation you would.

So here’s the ACTUAL recovery process, for Windows Helix Server (aka Perforce).

1. Start Button → Services

   

2. Stop the Perforce server
   

   

3. Open a file browser to your Perforce Server folder. On Windows, that’s probably C:\Program Files\Perforce\Server

4. Move the db.protect file out of the folder to somewhere else. Don’t delete it. This will be recreated when you start the server again, but if for some reason you need to roll back, delete the new file and put the old one back. This is just for backup purposes.

5. Open a command prompt as Administrator

   

6. Usually when you use perforce CLI commands, you’re using the client (p4.exe) to send commands to the server remotely. However, you can’t log in with the client, because of all that security you put on it. So we’re going to use the server executable itself (p4d.exe) to rewrite its own configuration file.
   
   We need to pass two arguments to p4d.exe:
   -r “c:\Program Files\Perforce\Server” (or whatever your server folder is)
   “-cshow” (which is short for ‘config show’)

   

   This prints out the configuration options currently set. These two are our problem.
   
   dm.user.noautocreate = 2 (new users need to be created manually by admin)
   security = 1 (passwords are required)
   
   Sidenote: on Windows, you need double quotes around any of the config show, set or unset commands. (cshow, cset, cunset)
   

   We’re going to set those to 0, so we can create a user and log in.
   
   p4d -r "c:\Program Files\Perforce\Server" "-cset dm.user.noautocreate=0”
   p4d -r "c:\Program Files\Perforce\Server" "-cset security=0"

   

   Much better.
   

7. Now, you can restart the Perforce server. Mine is already running here:

   

8. Any p4 action now will create a new user. The simplest action is a “ping”. Use this to create a user, set a password, then log in with it. We use the -u argument to specify a username to execute as, then the ping command:
   
   p4 -u christina ping

   

   You can see there is no ‘christina’ user, until I perform an action claiming to be user ‘christina’. As soon as I do, the user is created. After that, I’m able to set a password, and then log in.
   

9. You may now use the newly created account (in my case, ‘christina’) to edit the password of your old account:
   
   p4 -u christina passwd oldaccountnamegoeshere
   
   So now we’ve got a new account, we’ve reset our old account, all that’s left is to bring back the administrator privileges.
   

10. Run P4ADMIN to open the administration console, and connect to your server with your new user. It should tell you that if you proceed, you will be the only super user in the system. Say yes. You may need to disconnect and reconnect after this for the UI to update with full super-user access. Congratulations! You now have full control of the server, and are free to restore your old account to superuser, or whatever else you’d prefer.

    

    Woohoo! You’ve done it.

11. Don’t forget to reset your auth permissions. These were mine, yours might have been different. Back to your administrator command prompt:
    
    p4d -r "c:\Program Files\Perforce\Server" "-cset dm.user.noautocreate=2”
    p4d -r "c:\Program Files\Perforce\Server" "-cset security=1"

WHEW. What a mission. Save your password somewhere next time, or keep a backup user with no real permissions except login, with a dumb password you can’t forget, and then you only have to do the db.protect step, as listed here.

Until next time.

for those we have lost
for those we can yet save

Anyone who’s worked in marketing knows that people’s favorite thing is themselves.

Don’t argue with me on this one, I can see your social media manager nodding along from here. Ask them about their favorite gaming memories, their favorite champion, their best whatever and your replies will be full for a week. So when you get a computer to draw beautiful pictures of people’s favorite thing - themselves - they’re more than a happy to fork over some cash. So now Lensa is sitting on a big pile of your photos and we probably won’t regret that in the future.

But now dipshits are claiming AI is the future of game development, and it’s going to make indie games all AAA-quality. So why are they saying so many dumb things this time?

They want jobs prompting for concept art

Unfortunately, they don’t know what they’re asking for, and if they did, they’d know that the AI generators they love are actually not a good tool for it.

To explain why, we have to ask: what is the purpose of concept art?

I’m not going to explain it, because Delaney King already has, and she did it better than I would have, in this thread, which you should read.

Of particular interest is the bit where she talks about how concept art can be supposed to convey how something works - it informs the next steps of production. AI image generators don’t understand how things work. They don’t understand a person, or how the idea someone has in their head of a particular 3D object represented in 2D should move. They only know that certain things go together. They don’t know a person should have four fingers and a thumb, just that pictures of people have stuff like that at the end of it, which is why AI routinely draws people with too many fingers, or recommends books that don’t exist.

The thread above demonstrates a concept art mistake - not thinking through how a character will behave in game. Driving, sitting, or shooting, for example.

Concept art is about understanding, and AI fundamentally does not understand - it correlates.

So with their primary pitch off the table, they accuse developers of not liking AI, or not understanding it. But that’s not true at all, because…

Developers are already using AI for things, just not that

Animation, for example. Have you seen FIFA ‘22? Traditionally with fast-moving games, you need to have short animations so your characters can be responsive at any time. Blending can help but the transitions out of long detailed animations often look weird and forced when it’s purely programmatic. But EA’s “HyperMotion” technology is trained on massive datasets of pro soccer, and now the machine learning algorithm knows how people actually transition between those moves, and can dynamically adjust to create realistic motion, because it learned how humans move. If I wasn’t paying attention, much of this in-game footage would look real.

A new technique called Adversarial Skill Embedding let AIs teach themselves how to do attacks, which then become dynamic animations. This shit is absolutely phenomenal. It empowers developers and animators to be able to key in precisely what they want but not have to be locked into just their premade animations or blends.

This stuff promises to make games so much more immersive as NPCs, enemies, opponents move realistically. Goodbye capsule skaters, no more ‘feet sliding through the air’, we can have a future where characters move in response to things because they know how to do that.

There’s so much cool stuff AI can do. We’ve barely scratched the surface. But we’re using it to solve our actual problems, and they don’t understand that because they don’t know what our actual problems are, because they are hypothesizing based on an imaginary version of game development they made up.

Be wary of anyone who claims to have a solution to your problems when they don’t understand what your problems are.

Until next time.

for those we have lost
for those we can yet save

The rise of “racing seat” gaming chairs washed a wave of flamboyance over our homes as desks became battle-stations. We measured, customised, and tailored them to our favourite colour combinations and to our bodies, just right for a gaming session or a stream. But as work from home became the norm, these neon bucketed thrones revealed their weakness - longevity. Our bodies ached in places they did not ache before, because we never sat in these chairs that long, or that frequently. They were simply not very good for extended continuous usage. And so, since the pandemic, we’ve seen a renewed interest in office chairs, because office chairs are designed with one very simple purpose in mind.

To keep you working for as long as possible.

They are not designed to look nice, or to feel nice. They are designed to keep you productive for extended periods of time by ensuring that sitting down for a long time harms your body as little as possible.

The thing is, there is a meaningful difference between not harming your body and having a healthy body. Setting yourself up for a healthy, happy life in which your body is not in pain requires a lot of work (and it may not even be possible if you have a disability). It requires routine, and exercise, and habit, and movement, and standing, and walking, and all sorts of things. Those things and how we engage in them largely dictate our starting state — how much health we have to burn sitting in a chair. How long we can assume the position. And so we must interrogate the difference between getting and keeping a healthy body, and merely lowering how much you’re harming your body. One of them is about taking actions that make things better. The other seeks to not make things worse.

And yet, the majority of our discussion and discourse around bodily health as it relates to working is not about that health. We mostly just talk about the chair.

It is little wonder then that when we talk about burnout and crunch, we talk about about minimising damage. We talk about the reduction of pain and reduction of the impacts of pain. We don’t talk about people’s trajectory through the gaming industries and their career paths through game development, or esports. We, like with the chair, focus on the thing causing the most visible loss of health instead of focusing on the work required to create a good life and a good career for workers as they transit in, through, and out of our industries.

Look at esports. Young people burn themselves out training, over-practising, over-playing, their bodies and minds laid waste. And so we hire performance coaches and trainers and mental coaches to help them devote themselves to their singular cause of performing. They take planned breaks with regimented recovery times to manage the burnout and plan their downtime for optimized efficiency to maximize their effectiveness for their singular focus of the game. Of output. Of productivity.

Just like the office chair.

And yet, in three to five years, they will quit. This will occur with such regularity that 23 year olds are considered “veterans”. Most will leave the gaming industry forever. Even if they don’t burn out, or become injured, they will leave. On the weight of averages, most will quit in, or before that time period. They are often damaged by their experiences here, set behind their peers, with an adjustment ahead of them to return to the regular world. They quit because the trajectory of their experience is not leading them anywhere good.

Just like game development, where most people leave in three to five years.

If you squint, it might look like your goals are aligned with executive management’s goals when they spend money on office chairs for our homes. They are looking after us, we tell ourselves. They are making sure we are healthy. But they are not. The company’s goal is to keep you as effective and productive as possible for the maximum amount of time, on a reasonable budget. The company’s responsibility under OSHA is to ensure you do not harm yourself by sitting whilst doing that.

It is on us then, to ensure that our workplace cultures are creating standards of normal that go further than simply ensuring we are not harmed by working. We — you and I — must both live by example and talk about how we live and talk about how we live by example, so that others can repeat it. So we can build places where people don’t just survive, but thrive. As game developers, our job is to create joy. If we wish to do that well, the experience of that work must also be one of joy.

We must take time off, and we must be seen to be taking time off. We must maintain healthy relationships with our workplace and our work and our productivity. We must identify first as a creator on our own terms, rather than an employee, a “rioter”, a “twitch staff”, or any of the failed spin-off monkers that imitators have attempted to have their workers identify as. We must be insistent on addressing the project management failures (and it is always failures) that cause crunch. We must be diligent in addressing the management failures that cause thrash, remove psychological safety, and fail to understand the needs and experiences of workers. We must stand up for people who feel they are “not established enough” to safely stand up for themselves. We must say the things that the juniors in our teams would not feel comfortable saying.

It will be unpleasant. It will be scary. You will be afraid. But in a few short years we have gone from a place where CEOs were praised for talking about how hard people crunched, to being eviscerated by thousands of developers and the media for insisting that people working 12 - 15 hour days, 6 - 7 days a week, “luv” it, and do it because they’re passionate. The world has changed. You and I can continue to change it.

If we do not, we are not looking after people. We are merely pumping farm animals full of antibiotics, instead of giving them an environment where they do not get infected.

Much of the advice we prescribe to others is an office chair. It helps them reduce the harm they experience. And that’s good, of course that’s good. But it’s not creating joy, it’s not creating spaces where we thrive. It’s not helping people grow through their careers.

Let us think further than harm reduction.

Let us imagine of a world where we are not within striking distance of being undone by furniture.

Let us create that world.

Subscribe now

for those we have lost
for those we can yet save

being locked in a bad work environment

is not like being chased by a tiger

that destroyed his cage

i have long forgotten the number of times ive been hurt or nearly killed at work

but i remember the ones that hurt my soul

I know, I usually cover deep technical dives into how games operate, but in a world where every major studio gets The Article’d, it would be remiss of me to not talk about the fact that studios are run by people, and that how those people operate is every bit as important as how their software operates.

To do that, we have to talk about biology.

The human body is a marvelous, resilient thing, capable of both incredible feats, and the ability to change in order to become capable of incredible feats. But evolutionarily speaking, it was built for survival. And to survive, it relies on the sympathetic nervous system.

Fight or Flight

When activated, the sympathetic nervous system increases your blood pressure and heart rate, dilates the pupils, dumps adrenaline, and ups the oxygen supply to your vital organs, readying you to fight for your life or run screaming into the woods. Fight moves you towards a problem. Flight moves you away from it. At its core, the sympathetic nervous system says “I CAN”.

The human body evolved and built itself specifically to do this, because most of the threats that governed whether we would live to reproduce had to be either killed, or escaped from.

But what if you can’t fight or flee?

For better or worse, the human body also built itself another survival mechanism that’s suspiciously suited to sitting in a design meeting with someone who gaslights you and seeks to undermine you at every turn, or to quietly attend class with someone who beats you. It’s not what it evolved for, but our biology has a nervous system behavior that happens when you must politely repeatedly comply with the social rules of interaction with someone who is actively harming you. We’ve all heard of the fight or flight nervous system activation — it’s what tells you “SHIT IS GOING DOWN. DO SOMETHING”. Fight or flight is a call to action; a gas pedal.

But in a workplace, you can’t use that gas pedal the way nature intended. You can’t upend the chairs of a meeting and barricade yourself with furniture, safe from your attacker. You certainly can’t leap over the table and choke them until the threat subsides.

So you slam on the brakes, despite what your body is telling you. What happens after that, is one of the lesser-known “F”s.

Freeze

If you’ve ever held the gas and the brake down at the same time on a car, you know what happens: smoke, lots of it. Do it long enough, and you get fire. First the parts start failing, and the vehicle itself fails.

Note: Before we go into the chart, it’s important to note that polyvagal theory is a simplification of the numerous complex physiological processes; it’s less a strict analysis of the operation of the body, and more a lens through which we can generalize and talk about the things we experience.

When you’re in a safe and healthy state, the parasympathetic nervous system is in charge, maximizing all the things you need to be a healthy, effective, social creature. When you’re not safe, the sympathetic nervous system takes over, arming you to deal with the threat.

But when the sympathetic nervous system fails to deal with that threat, things start to go wrong. When in sympathetic activation, the adrenal glands produce cortisol, which is basically your body’s alarm system. It sets you up to react to threats by increasing blood pressure, heart rate, blood sugar, clotting ability, as well as a bunch of other things. That’s great for outrunning a predator, or hunting your prey, but what happens if you don’t do either of those things? And if you end up just staying in that state of activation for extended periods of time?

The effects of long-term elevated cortisol levels are well-documented and too complex to go into, but let me know if this sounds familiar:

You’re tired, no matter how much sleep you get. Your pain tolerance goes up. You put on weight more easily. Unnecessary movement, like exercise, feels bad. You become less social. Your memory suffers. You have trouble expressing emotion. Your libido tanks. You get sick more easily. Almost like your body is trying to give you the best chance to survive something you can’t escape from.

You are in freeze.

Anyone who has worked in game development knows this state, regardless of the name they use for it.

This Is Not Burnout Discourse

What I’m trying to get at here is that there are very specific things that happen to the body when you are trapped in a situation that’s hurting you. It is a physiological state, not just a mental one. Here’s a different interpretation of the same chart.

In a healthy, normal state, you’re frequently flitting in and out of mild levels of sympathetic nervous system activation. When it’s short periods of exercise, intense gaming, or things that challenge you, the pattern of entering and exiting fight-or-flight is completely sustainable.

But when you’re constantly in fight or flight, your system is flooded with cortisol, and that has flow-on effects. And if you stay there long enough, you freeze completely.

In order to enter the Freeze state, you need to:

1. Encounter a threat your body tells you to kill or run from, and then;

2. Not kill it or run from it, and;

3. This state needs to either not be resolved, or continually re-entered.

In other words — you must be trapped, and unable to do anything about it.

In previous, non-games-industry jobs, I was almost killed twice, and was nearly (or actually) seriously injured plenty more — yet I suffered zero psychological damage from those experiences. Why? Because the sympathetic nervous system did what it was supposed to do, and got me out.

My body prepared itself to take action, I took action, and the problem was solved. My sympathetic nervous system screamed “DO SOMETHING”, and I did something. Pain is most likely to become trauma when we do not or cannot heed that request. And the reason that we sometimes don’t, is that we’re trapped in social situations where social order tells us we cannot simply sprint into the woods with no intention of returning, or hit someone with a piece of furniture.

To be clear — I am not advocating for fleeing into the forest or hurling the nearest ergonomic chair at your crunch-loving boss. But with the concept of how we end up in freeze in mind, what else can you learn from the chart?

Deactivation

The body is constantly attempting to normalize itself, and return to a state of equilibrium. It continuously breaks down things it doesn’t need, which is why you don’t stay drunk forever after you drink alcohol. But when the effects of activation outpace the normalization process, things get bad.

Anyone who’s designed a combat system can probably see where this is going. Your body primed itself for a hundred fights that never came, and loaded a magazine full of cortisol bullets. You’re continuously adding stacks of a berserker buff, then not consuming the flow-on status effects. And you’re adding stacks faster than they can time out. You’re being activated at a rate greater than your body can fix what being activated does to it.

When you entered freeze instead of fighting-or-flighting, the chemicals your brain dumped and the effects they had on your body didn’t just dissipate or disappear. And in order to return to normal, you’re going to have to stop adding stacks, and then expend, purge, or heal from the flow-on status effects – one way or another.

In short - the constant sympathetic activation is adding cortisol faster than your body can remove it, and so the effects accumulate, wreaking havoc.

To be totally transparent - even this is an oversimplification of a set of very complex processes. But using it as a lens through which to view and understand what happens to us without a degree in neuroscience, it can still help us wrap our heads around the problem.

There is no singular, universal, guaranteed way to return to normal after hitting that freeze point, but because this has physiological causes, there are things that are very likely to help in most cases, even if the exact path looks different for each of us. For some people, it might be trauma therapy. For others, it might be quitting a job, or moving, or both. For the rest, it might be breaking themselves open with a particularly emotional piece of music, then letting themselves feel and express all of the emotions and reactions they suppressed in the lead-up to the freeze state. You may need to punch, kick, and curse to the high heavens, screaming every turgid word of hate you held in when your needs, your hopes, and your safety were shattered. I recommend a punching bag, a pillow, or a bed, in that order. But be warned - it may not be enough to merely carry out these actions, especially if you’re still dissociated or disconnected - you may need to re-enter the state where your body screams “fight”, and burn the fuel it filled you with. This was my experience. It may not be yours. And exercise, however bad it feels to start, helps in almost all paths.

When It All Goes Horribly Wrong

Trauma complicates matters. It can leave you in a state of perpetual fight or flight, or keep you braced to enter it at the slightest trigger. For some, the exhaustion of the continuous fight or flight response can also leave you in a perpetual freeze. It can even end in C-PTSD.

The real dark industry secret of this article is that many of us just end up living in these states, not knowing what they are, and not understanding why two weeks of vacation doesn’t help. Even when we quit our jobs and take extended breaks to decompress, we often don’t get better, because the underlying issue hasn’t been addressed. The pain is quite literally stored in our bodies chemically, stuck operating in a state where we’re one step from breakdown, and we live trapped in a cycle where we can never get back to that safe and healthy state.

My articles usually include very little advice, and instead seek primarily to educate, but after diving into our collective pain, I can’t not talk about recovery.

First off: It is possible to heal. It won’t just magically happen though — there is no set amount of PTO or recovery time between jobs that will guarantee healing. Rest alone is usually insufficient. But there’s almost certainly a minimum amount of rest time each person will require to heal. That timeframe will be different for everyone. But you have to do the work. Get help. Be active in your own recovery. Your friends are good support. A trauma therapist is better. One that knows the industry? Better again — it’ll save you explaining things like “crunch” and “patch days”. If you can’t find one, this thread may help.

You may need to redefine your relationship with work. You will need to learn that the people who hurt you are not the only kind of people out there, and that sometimes, mild annoyance from a boss or coworker is just that — and it’s not a sign that you’re about to be blamed for something that’s not your fault, or held accountable while the people who created the situation are not.

The goals of all these is to:

1. Stop adding berserker stacks (stop creating unnecessary cortisol).

2. Remove the stacks you currently have (normalize excess cortisol).

3. Heal the damage caused by them (fix the flow-on effects of freeze).

4. Retrain yourself so that the pain you carry is not perpetually adding more stacks.

How To Prevent It

If you’re an executive reading this, you need to understand that this is probably happening to someone who works for you right now. Your corporate values won’t protect them from it. “Empowering” language and concepts can easily be weaponized against vulnerable employees. Convincing yourself that your space is “safe” will prevent you from seeing when it’s not. Ideas don’t protect anyone — only action can do that.

For workers:

Industry-specialized therapists can help you learn better communication, better conflict resolution, and better ways to handle when things go wrong. There are actions you can take to give yourself the best possible shot at having a good work environment. But ultimately, you can only ever be responsible for your own behavior, and there’s a limit to how much an individual contributor can affect in a workplace.

For managers, executives, founders, and owners:

You have to mitigate toxicity with robust process, with anonymous reporting and feedback, with project management designed to combat crunch, and with product management designed to prevent thrash. You have to design your work methodology intentionally to protect the people who work for you. There is no way around this. And since I know that some people will be reading this saying “But surely not HERE? We’re a family!”, let me disburse you of the notion that work “as a family” is a necessarily good thing. Those implied social and emotional obligations can further freeze people who need to fight or flee.

So let me give you all some clear, direct questions you can ask yourself about the place you work:

• Is it possible for employees to raise issues they have, without any risk to themselves?

• How does the company react when workers raise issues? What management practices do your managers adhere to that ensure staff are heard?

• How do the company’s performance improvement or disciplinary processes ensure that managers are not targeting vulnerable staff or people who raise complaints?

• What training is provided to managers? What expectations does the company have of its managers, and how do you measure their efficacy?

• Do you give teams the agency they need (agency is action, freeze occurs on inaction) to self-determine the people, practices, and tools that best suit their work?

• Is there any way that your corporate values could be misused? Could they be abused the way that Riot’s “default to trust” was used to hand-wave away sexual harassment? As in, “I’m sure he didn’t mean it that way”?

• How often does unplanned work occur? How do your processes and prioritization handle that “found” work? Do you bake additional time into your project planning to allow for things not going to plan?

• How often do employees work outside of standard business hours? How do you track it? How do your processes ensure that the majority of work does not escape standard business hours?

• How clear are the objectives for each of your teams? Can people trust that the targets and goals that are set for them will still be true in two months? If not, what effect do you think this has on their morale and general trust in the company?

• How do you instill a sense of psychological safety in your employees? (If the answer to this question is not something organizational, you don’t.)

• Do you use automation and workflow management in your task management software (e.g. JIRA)? How do these systems empower the teams that use them?

• Are the communication paths between your various teams well-defined?

• Does your accountability structure align with those communication paths?

• How do you ensure that promotion opportunities are visible and available to anyone who might be interested in them? How do you ensure that they are given fair consideration, accounting for bias?

• Is your organizational structure well-defined? For each of the areas of your product, who is responsible? Who is accountable? Who is consulted? Who is informed?

• Are employees consulted about changes that affect them, or merely informed?

• What structures and processes are in place to ensure that people are not misusing power in your organization?

• How many people who leave your company leave the industry forever?

• How many people who leave your company leave without a new job to go to?

Be honest with yourself when you answer these questions. The answers may be unpleasant, but that can be good. You do not solve problems by looking away from them. And even if you don’t give a shit about the people who work for you, there is no greater hit to the bottom line and to your deliverables and schedule than burnt out, traumatized staff that don’t trust management and will eventually quit (or be fired for voicing their concerns).

Mental health stipends and work-subsidized therapy will not help. Looking after staff is a company-wide directed effort that always flows downhill from the top. Whatever behavior is displayed in the most influential positions will be mirrored down throughout your management structure. The behavior we accept is the behavior we condone. It is up to the managers and the executives to maintain a healthy environment.

And if you’re a worker reading this, you have a list of questions you can take to your management to ask. And if they don’t have good answers, every company I know has bone-dry hiring pipelines, and the best way to get a pay raise is to switch jobs! Get the fuck out! No game or job is worth your health, either mental or physical.

I leave you with two images.

Until next time.

for those we have lost
for those we can yet save

Welcome back to Load-bearing Tomato.

This final part addresses the logic that underpins inter-system communication.

Now that we’ve established that NFTs cannot take items between games, and that NFTs don’t enable knowing what you own in other games, it’s time to get down to the most important thing:

The plans for NFTs in games do not make logical sense at a fundamental level.

Blockchains, at their core, are vehicles for establishing trust in an untrusted system. They are an immutable record of transactions that can be mathematically proven to have happened.

And that’s great for things like cryptocurrencies, where everything the blockchain knows about exists entirely within that system.

Wallet A has 5 BTC, Wallet B has 5 BTC.
Wallet A transfers 1 BTC to Wallet B.
Wallet A now has 4 BTC, Wallet B has 6 BTC.

The Trust Boundary

The system is self-contained — it doesn’t care about anything but the state of the wallets and transactions it contains. For this, blockchains do a great job of establishing trust. In order to formally evaluate trust, we use what's called a Trust Boundary: a line you draw between a system you trust, and one that you don't.

This is where systems like NFTs based on cryptocurrencies fall over dramatically. A cryptocurrency describes only itself. The second that the thing you are describing is off the blockchain (off-chain), you are no longer trusting what happened, you are trusting what someone said happened. Anything that occurs off-chain crosses the trust boundary, and thus, can't be trusted.

The lie of ‘items/skins as NFTs’ relies on a server that reports that a user gained an item. In this world of non-self-containment, we can’t think of a blockchain as something someone can trust, because anyone can write to it.

Instead, we need to think of it more like shared storage, like the hard drive of a shared computer. Remember all those warnings of the websites you log into that warn you ‘if this is a shared computer, don’t save your password’? There’s a reason for that. Now imagine your computer is in a public library, and anyone can save files on it, but like a blockchain, no-one can edit them after they’ve been saved. How do you know which files are safe to open? How do you know which files contain information you need? How can you trust any file that you didn’t create?

So, if you think about the ‘items and skins as NFTs’ idea, where do you draw the trust boundary?

Let’s think it through.

Who Do You Trust?

Anyone can mint an NFT of a Bored Ape JPG, but it’s not a real Bored Ape NFT unless it was minted by the BoredApeYachtClub, from contract address 0xaba7161a7fb69c88e16ed9f455ce62b791ee4d03. The Bored Ape site won’t list it, and OpenSea won’t show it under the Bored Ape contract.

Let’s put this back in the context of some games: Game A and Game B. You have the following system — two games, both storing items as NFTs on a blockchain. We’ve already established that these NFTs can only be item codes, and will not contain assets.

Game A has the items SWORD and BIG_HAT. Game B has the items SHIELD and BIGGER_HAT. They both agree to implement each other’s items.

Where do you draw the trust boundary?

Game A supports SWORD, SHIELD, BIG_HAT, and BIGGER_HAT.
Game B supports SWORD, SHIELD, BIG_HAT, and BIGGER_HAT.

But clearly this is insufficient. What’s important is not just the item, but the contract/game that minted it. If Game B plans to use an item from Game A, they can only trust that item if it was minted by Game A.

There’s an obvious reason why.

Fake Mints

If Game A decides that all items are equally trustworthy — regardless of which contract minted it — anyone can add anything to their inventory. They have opened the doors to fake items or worse. Let’s see that vulnerability in action.

Player X mints an NFT with an item BIG_HAT and adds it to their wallet.

Game A obviously should not trust this item, even though it supports BIG_HAT. That’s because it’s not BIG_HAT that is trustworthy, it’s BIG_HAT by 0xA.

The Actual Vulnerability Is Name Collision

That’s a malicious example, but the same thing can occur completely naturally.

What happens when Game B — a trusted contract — adds an item that also uses the code BIG_HAT?

Game A supports SWORD, SHIELD, BIG_HAT, and BIGGER_HAT.
Game B supports SWORD, SHIELD, BIG_HAT, and BIGGER_HAT.

Player X has BIG_HAT. But which BIG_HAT is it? In order to avoid confusion, each game needs to maintain a list that includes information about both the items it trusts and the game/contract that minted them.

Game A and Game B now have a list that looks like this:
0xA SWORD
0xA BIG_HAT
0xB BIG_HAT
0xB SHIELD
0xB BIGGER_HAT

“But Christina”, you ask, “you talked about using UUIDs to generate unique ids. Couldn’t you just use those, and then each game could store a mapping of UUIDs to in-game items?”

Good question! But even if you avoid an accidental collision this way, it doesn’t protect you from someone maliciously and intentionally minting an item with a “unique” string. And because NFT contents are public, anyone can inspect or clone them.

This isn’t a technological problem — it’s a logical problem that arises from using shared storage. You can’t trust everything on the blockchain, you can only trust things on the blockchain that come from trusted sources.

This logic error underpins every failure of blockchain to deliver the promised metaverse of interoperable items. There is no way around it, because untrusted shared storage is a bad plan. The “trust” that blockchain delivers does not ensure that the data is trustworthy. It only ensures that we have a record of what was posted, and by who. Whether or not we trust that data is entirely up to us.

That is the Trust Mesh Problem. And it cannot be solved. It can only be managed through choices that we, as game operators, make about who we trust.

So Who Do We Trust?

We already discussed that Game A’s developers need to do a lot of work to implement Game B’s items by hand, and that they'd need to do this all over again for every game they use items from.

So naturally, we trust those items from those sources.

Earlier, I asked you where you thought the trust boundary was. What was your answer?

Here’s what it actually is. As Game A, we don’t trust the blockchain. We don’t even trust the contents of our players’ wallets. We trust our servers, we trust items that we minted ourselves, and we trust items that were minted by specific contracts that we choose.

This reveals the real truth: Since what we actually trust is Game B’s contract, by extension, we also trust Game B. We trust the contract code, the server code that executes contracts, and we trust anything that they create or execute.

A game’s Trust Mesh is the network of external systems that it decides are a source of truth. Here’s our trust mesh in the Game A/Game B scenario.

The Trust Mesh

So we (Game A) trust Game B. But by trusting their inventory, we are also trusting their drop rates, their economy, their methodologies — everything that goes into the game that we choose to support.

This means that Game B can fuck us in many different ways. Not only can they fuck our game balance — by flooding our game with super-powerful items, for instance — but they can fuck us economically. If Game A chooses to support Game B's skins, and those skins are cheaper than Game A’s skins, that could decimate Game A's skin revenue. And Game A can't even sell Game B's skins to make up for it, because they can’t mint them. Like we already established, Game A and any other game can only trust Game B items that came from Game B's contract.

And there’s nothing you can do about it, because it’s a logic problem. If you allow Game A to mint and sell Game B’s items, any game participating in this item-sharing system now has to maintain a list of all valid sources for Game B items, or else Game A’s Game B items will be incorrectly be identified as fakes. This also means that any time a new game joins the sharing system, every participant in the system has to update that list in their game. An incremental change would then require exponential work to implement, which destroys the idea of this system scaling, and Game B just gave Game A another way to fuck them. Before, Game B could just make skins that might be more popular than Game A. Now, Game A would be able to literally sell Game B’s content, but cheaper.

This scenario also reintroduces name collisions, because now the combination of contract ID and item code are not enough to uniquely identify the correct item type. We’re back to requiring globally-unique item codes.

These issues decimate the metaverse promise, because every time you add a new game to the trust mesh, it gets exponentially more complex. In computer science, we refer to this as O(N^2), in what’s called “Big-O” notation. What does this actually look like if we try to do it for seven games instead of two?

The size of a full trust mesh is the number of participants (n) minus 1 (you trust yourself) squared, or (n-1)^2. With 10 games involved, that’s 81 trust relationships. With 100, it’s 9801, all of which must be maintained and kept in sync. And if any participant in that system retains the freedom to choose who it trusts, the number of hypothetical different trust states becomes (2^n), rising from 9801 to 1,267,650,600,228,229,401,496,703,205,376.

Good luck programming for those.

What About User Generated Content?

We’ve talked about the difficulties of assets before. For low-fidelity, objectiveless games like VRChat and Second Life however, there are standards you can use to make and import assets — at the trade-off of performance, fidelity, and freedom. These standards are unsuitable for modern AAA games, but let’s assume that we don’t care how badly our game looks or runs.

GLTF and other similar standards allow importing and using assets, but in order to allow UGC, we need to choose to trust anyone on the blockchain that claims to have an asset for our game. We’ve already discussed why that’s terrible; the problems start all over again, but this time, it’s the content that’s the issue.

Aside from the usual “Time-To-Penis” concerns (the amount of time between enabling UGC and someone using it to draw a dick), and people making things that are just bad (e.g. obscuring hitboxes, breaking silhouetting rules) we have a much larger problem: Shaders.

You might think that a surface in a game is just a texture, but it can actually be much more than that. Shaders are programs that generate the look of a surface. Textures are little more than simple images, but with a shader, you can do things like control how it refracts light, make something glow, or even simulate the liquid contents of bottles in Half-Life: Alyx. And now we’re saying that we’ll let people import shaders and execute them.

If you’re a programmer, you may commence panicking now.

Shaders are basically arbitrary code. In security terms, they are an RCE vulnerability — one of, if not the worst kind of vulnerability you can possibly have. You’re letting someone else run programs inside your game, on your players’ PCs. If your game loads a shader that you didn’t write, it could easily contain code to download child porn, or join a botnet and turn every player’s PC into a DDOS participant, or run an aimbot (it would be so profitable to make skins that contain aimbots in their shaders, I shudder even thinking about it). One guy even wrote a shader that runs an entire Linux instance.

You can never, ever let a client run a shader you don’t trust.

Here’s what our trust mesh looks like with UGC:

If we let users load anything at run time, we are choosing to implicitly trust them. And since we have decided that we are trusting things we don’t control, created by anyone, we arrive back at the core problem:

Trusting shared storage allows anyone to hack your game.

Quality control is gone. Anti-cheat is gone. Game balance is destroyed. The game economy is destroyed. It is all the hell of trying to buy an authentic item on Amazon, times a million.

The Cursed Design Problem

This is what we call a Cursed Design Problem: when you have two goals that are in conflict with each other, and you can’t have both.

Example:
You want to buy a two-seater sports car.
You also want to be able to transport four people.
You can’t have a two-seater car and transport four people. One goal must lose.

The logic error inherent to NFTs in games is a cursed design problem.

If you have user-generated, NFT-loaded skins, you can’t have security, stability, or performance.
If you have items coming in from other games, you can’t have economic integrity.
If you have immutability, you can’t have customer support fix things when you get hacked.

These are not technical problems — they’re logical problems. The design goals are in conflict with each other. They cannot be resolved without sacrificing one of them.

You cannot fix it with more code. A new ERC can’t fix it. A new token can’t fix it. The plan is at odds with itself, because it was never designed for this. It is the wrong tool for the wrong job.

—

This is the end. Hopefully you’ve come to understand why we don’t do this; it doesn’t do what you think it does, we can already achieve the same things using stuff that actually works, the outcome is worse, and the plan does not make sense.

I hope that by writing this, I will never have to explain this to anyone again. That won’t happen, but a girl can hope 🤞

for those we have lost; for those we can yet save

Today, we’re talking about communication.

People have become quite fond of saying that NFTs will enable games to understand what stuff you own, and let you load your gear from other games. As we discussed in part one, the idea of just plucking those assets off the internet is a fantasy. So, we accept that in order to use NFTs for items in modern games, a studio would need to pre-implement any actual assets and use the NFT to refer to them.

In the kind of modern, online games we’re talking about, each item is probably identified by the combination of two things:

1. A string that indicates what type of item it is (e.g. WEAP_ENERGY_SWORD_ULTRA)

2. An item ID that refers to a specific instance of that item (e.g. a UUID like f561e9cc-06b3-4399-a274-d1e431a84cac)

If you wanted to load an item from an NFT, the contents would most likely be, at a minimum, those two things.

Since we established that you can’t store the item’s actual game assets in the NFT, the pitch we’re left with is that the NFT will tell games what you own using these identifiers, and that will prevent games from messing with your inventory, give power to players, etc. etc.

But if you’re going to suggest that a new technology can enable something, you should first understand how the current technology works. In order to demonstrate this, I’m going to make up a new platform, like Xbox Live or PlayStation Network, called Games Network Live, for the HomeXperience platform. GNL and HX, if you will.

So you boot up your HX console, and tell it to log into GNL. What happens next?

Now, I have to warn you: this part is boring to most people. Which is weird, because this is the actual technical layer at which blockchains and NFTs operate, and it’s the one people are also “excited about”. It’s going to be long, involved, and complicated, but if you’re here, you care about that sort of thing, so let’s dig in.

Everything Is Just Websites, Kinda

Pretty much all modern online games are powered by something called Web Services, which are also referred to as APIs. They’re functionally identical to how your web browser loads a web page with a URL.

Your console can also make HTTP requests, exactly like the ones your web browser makes, to services that receive them. This time, it sends some data along with it — some JSON.

If the JSON looks familiar, it’s because it’s exactly like what NFTs use. Your login request JSON might contain your username and password, and maybe some other metadata about your login attempt. It might look something like this:

Then, exactly like your web browser, it receives a response. For your web browser, the response is a HTML web page and maybe some JavaScript, but for a web service, the response is usually just JSON.

Most importantly, the response contains an authentication token (or “auth token” for short), which is a specially encoded piece of text that the platform will use to identify you from here on in, so you’re not repeatedly re-transmitting your password. It’s cryptographically signed so you know it hasn’t been altered.

If you hit F12, or look at your cookies after logging into a game’s web site, you might find something that looks like the Encoded section above, and if you paste it into a decoder (like jwt.io), you can see what your actual token looks like. ✨HACKING!✨

So, why do you care about any of this? Well, because it’s the basis for most communication between systems on the internet, and we’re here to learn about how shit works. What NFTs do, from a game client’s perspective, is identical to any other web service.

So you have your GNL Auth Token - now it’s time to do something with it.

“The Login”, by J.R.R. Token

Thanks, I workshopped that.

So you boot up the newest, hottest game you’ve been playing the last few months, Call of BattleHalo, and you’ve just bought the latest DLC, Fate’s Cry.

Your console boots up Call of BattleHalo (hereafter COBH), and it logs into the COBH servers by sending it your GNL Auth Token. With this, it knows what your GNL account is, can validate that you are in fact logged into GNL, and is able to look up which COBH account is associated with it by checking its database. Most games use MySQL, Postgres, or some cloud-hosted version of same, but COBH uses Postgres.

So COBH accepts your GNL token and issues you its own authentication token, that it will use to identify you for the rest of your session.

So, now you have a COBH Auth Token, and you can start making the requests you need to play the game.

How Does It Know I Bought The Fate’s Cry DLC?

I’m sure you’ve guessed - it’s more HTTP requests.

When you sent your auth token to the COBH servers, it knows that you’ve logged in from GNL, so it sends a request to GNL’s purchase servers to ask it whether you’ve bought anything. There are a few methods of doing this, but we’ll stick with a simple one.

COBH maintains a list of your purchases, requests a fresh list from GNL, and then goes through and delivers anything that hasn’t already been delivered. This could be COBH virtual currency that goes in an inventory, or an entitlement record that says you own the expansion and can access it.

It might go something like this.

To recap:

• Your game knows it needs to check the GNL store for purchases

• It makes a request to GNL to ask what you bought

• It compares that to a list of what it’s given you already

• It grants you anything you’ve bought but not received

Using a remote source to understand what someone owns in a game isn’t new - it’s how all console platforms work.

More Data Required

When your game starts to load in, it makes some requests to various COBH services to get the data it needs, including:

• Social (e.g. friends list, guild information)

• Progression state (e.g. achievements, quests, level, data)

• Inventory (e.g. items, cosmetics, consumables)

This is the part you’re interested in.

The game client makes a request with its auth token to a game server API. The game server has its own secret token that it uses to make a request to an inventory server on behalf of the player. When the inventory server gets that request, it looks up the player’s items in a database, and the data weaves its way back up the chain.

Note that the inventory server does not need to send everything it receives from the database back to the game server. In fact, it’s normal not to. Items and currencies get deprecated all the time, and although games might perform migrations on the database to get rid of such things, there’s no reason they can’t instead filter them out in the inventory server.

How might that be different with NFTs?

It wouldn’t. Here’s how the same flow would go.

The same inventory server is the arbiter of what you get to have in-game. While it can’t remove things from your wallet, it can make them useless or worthless. A game company can immediately nullify anything you own. If they remove or block the item your NFT represents, then all you have left in your wallet is a JSON string that refers to nothing.

“But if the client makes that request and then sends it to the game server, a game company can’t interfere with it, right?”

No. This is incorrect for two reasons:

1. Never, ever, ever, ever, ever trust that what a player’s computer tells you is real. Anyone can do anything to it. You could make your client say you have every item in the game. Inventory cannot be client-authoritative if you want your game to be secure.

2. The inventory still requires interpretation by the game server. The game server can similarly just ignore or change anything you send it. You probably have dead, invisible items in the inventory of every online game you play.

What about items from other games or services?

It’s not meaningfully different than getting your purchases from GNL. When you earn an item by watching a Twitch stream, Twitch sends a request to that game's inventory server and tells it to grant you that item in-game.

I’ve simplified this a fair bit, but at a high level, this is how it works. It’s all just a bunch of requests flying around between services you’ve chosen to trust.

And trust is the important part here, because there’s functionally no difference between choosing to trust a particular service and choosing to trust NFTs minted by a particular contract address.

I’ve alluded to the Trust Mesh Problem before, but the core of it is simple:

Item Origin Matters

If, as the operator of COBH, I choose to honor items from another game, like the fictional Hail Of Storms (HOS), I should only trust those items if they were created by Hail Of Storms.

Which makes sense right? If I’m telling my game that the item WEAP_ENERGY_SWORD is a HOS weapon, then I should only trust NFTs minted by HOS. If some other game started minting NFT items containing WEAP_ENERGY_SWORD, I know they didn’t originate in HOS. Like right-clicking and saving a popular NFT, then minting your own with it, the contents might be the same but it is the source that gives it its validity.

If I trust HOS items from any other source, anyone could create fake HOS items, and I’ve just allowed anyone to add anything to my inventory that COBH supports.

So given that you’re loading HOS items, and they can only ever come from HOS, all you’ve done is added more steps, when you could just ask HOS directly. If you ever recognize HOS items from a source other than HOS, you’ve allowed anyone who can mint an NFT to hack their own inventory, so the blockchain serves no purpose.

I’ve added a second game in here, Per Requiem Inventorius (PRI) for illustration purposes.

For all that talk of decentralization, that sure looks a lot like centralization, doesn’t it? The fact that the storage is decentralized doesn’t actually change anything in a centralized architecture.

Here’s how it currently works today:

Looks pretty similar, huh?

COBH, HOS, and PRI are all free to dictate how their item exchange works, and design solutions that work for them. They can build exactly what all parties agree upon, without being kneecapped by an unnecessary choke point rife with counterproductive limitations.

In a future article, we’ll talk about what those limitations are, and why every possible version of a system like this is worse for them.

We’ll also talk about marketplaces, game design, and game economy health. Each of those topics raise their own issues, and any one of them is serious enough to kill any assertion that NFTs enable anything in games. But the future articles must wait for future days, and my hope is that if people can understand the inner workings of how they’re talking about, that they might focus on possibilities for the future that aren’t self-defeating.

Thank You For Your Service

So.

This was a fairly long and in-depth look into game services, and if you made it this far, I’m impressed - you care more about infrastructure than the average game-enjoyer.

But at its core, when people talk about NFTs and gaming, they’re talking about infrastructure, so that’s what I’ve attempted to get people thinking about here.

Next up, we’re going to be talking about the Trust Mesh Problem in detail, so stick around for the next article “You Can’t Fix A Bad Plan With More Code”.

for those we have lost; for those we can yet save