Good Crunch, Bad Crunch

/

Over the last few months there’s been a lot of discussion about working conditions/crunch in the gaming industry, and I have some Thoughts about it. One interesting point from the Kotaku report on Rockstar and other articles is that different workers react very differently to the exact same conditions. Some feel creatively energized and passionately engaged, others experience serious and life-harming depression. Sometimes it’s Good Crunch, sometimes it’s Bad Crunch, and it depends both on the situation and the individual.

I don’t believe in strict 40 hour weeks at game studios because I believe in the power of Good Crunch. Collaborative creative projects are extremely hard to schedule correctly, mainly because creativity is so hard to schedule. I’m a programmer, so my work tends to alternate between simpler maintenance work and intense creative tasks like building new systems or solving hard problems. When I’m doing something complicated it’s much easier for me to work in large blocks of time at once, so working 10 hours a day can be 50% more productive than working 8 hours. And, sometimes those 10 hours feel pretty damn great.

There’s a reason that Game Jams usually have crazy hours, and it’s not because of cynical efforts to prepare developers for future industrial exploitation. People volunteer to crunch for 2 days to deliver a game no one will play because it feels good. The curiosity and learning parts of our brain are fully engaged and working at full speed. We have full control over a world of our making, and that kind of feeling is very hard to achieve in life (well, without being an unethical asshole). You can reach the same type of Flow as playing a hard game, but with the added chance to create something truly meaningful and impactful. This feeling is probably why most of us got into the game industry, and it’s literally one of the highlights of my life. So, I don’t want anyone to take this potential away from me or anyone else, even if it’s theoretically better for the industry. Crunch sounds great so far, what’s the issue?

Well, this only works if you have autonomy and control over what’s going on. On one end of the spectrum the Houser brothers at Rockstar has essentially unlimited control, they can literally decide the fate of hundreds of people because they want black bars on the cut scenes. On the other end, the typical QA analyst has very little control over the game or their own employment, and is largely at the mercy of corporate overlords. Everyone else in the game industry is somewhere in the middle, and I’ve had pretty strong autonomy so far so have often experienced Good Crunch. But, why would two developers with the same task load feel so differently about crunch?

It turns out actually having control isn’t what matters, it’s the perception of control. Many people overestimate how much control they have over the world, while anxious folk like me tend to underestimate it. As long as you agree with the creative direction of a game, or in the vision of the leaders, you feel like you’re the one in charge. When you’re “in tune” with the creative direction of a project, you’re working long hours because you care so much about the project. If you’re out of sync, you’re working so hard because the executives said something crazy and production didn’t do their job. Or, most often, it’s a bit of both. Generally, if workers don’t feel like they have enough buy in to a project, then expecting crunch from them is unethical and will cause significant human misery. And that’s what I mean by Bad Crunch.

One huge factor that drives loss of control is conflict with other responsibilities. Kids straight out of college are happy to work 60 hour weeks because they don’t have much else going on and crave the creative high. But once you have other responsibilities you can’t be happy “choosing” to work overtime, because you’re sacrificing too much of the rest of your life. Or, because entry-level QA analysts are generally not paid a living wage (due mostly to an oversupply of labor), it’s not “optional” to work overtime when your company makes it key to advancement. Or, if you have any disabilities (even a “minor” one) it can be impossible to maintain crunch hours without causing yourself permanent harm, no matter how excited you are. Personally, my anxiety means that working too hard for too long can really throw my life out of whack. This is not some rare thing, there’s a reason so many people burn out of the industry.

Let’s say that someone is willing to crunch, is able to do so without harm, and is creatively invested. They can still feel profoundly unsatisfied due to lack of autonomy over schedule and tasking. This arises because it’s impossible to schedule a collaborate creative project where everyone has the exact same amount of work every week, because of the complicated dependencies between tasks. The best way to deal with this is to schedule less than 40 hours per week for vital tasks and leave a buffer for other tasks. That way if an individual worker finishes their critical tasks early or on time, they can indulge their personal passion and raise the quality bar or improve some other aspect of the game. With a talented dev staff this will lead to high quality games and motivated development teams.

But, it’s much more common to schedule for 40 hours of tasks assuming everything works perfectly. Of course nothing ever works perfectly, so when you haven’t finished your critical tasks after 40 hours, you’re forced by social obligation to work 20 more hours to get everything done, and then if you’re passionate you may work even more to reach your internal quality bar. If you’re behind schedule because you estimated time poorly or you decided to spend extra time on quality, working the extra hours is bearable. But, if you’re behind because the producers ignored your estimates and were forced into an optimistic schedule by higher ups, you feel angry and bitter about it. I don’t blame most line producers because they generally don’t have much control over delivery dates or feature sets, it’s usually a more systematic issue.

Why are games usually behind schedule and over budget? It’s the same reason most government projects are: there’s no strong incentive to schedule realistically. When getting funding from an external publisher, or allocating resources for an internal project, projects with an optimistic budget/schedule will beat out projects with realistic ones. From the perspective of executives this makes sense: Why would you back the plan that sounds worse on paper? As long as a creative lead or producer doesn’t get labelled as a failure (switching companies usually resets this), unrealistic optimism is going to win out. This incentive gets picked up on by other producers (either consciously or not) and that optimism bleeds into the rest of the schedule. This manifests differently depending on the organization, but the result is the same.

Good Crunch is when you feel like you’re in control and are not causing yourself harm. Executives and lead creative types get to feel this way most of the time because of their degree of control and tendency to be extremely career focused. But for everyone else it’s only Good Crunch if it’s short in duration, flexible in schedule, and focused on something they feel creatively invested in. For the average worker this generally happens at Game Jams, on small teams, when starting a new project, or when close to delivering a game or major feature. But for other, very productive workers, there is no such thing as Good Crunch because of other restrictions/responsibilities in their lives. Honestly, I don’t think most executives/leads are deliberately harming their workers, but they are generally not willing/able to see things from the individual worker’s perspective because it is so different then theirs. But, cultivating a culture of forced crunch makes those workers choose between continued employment and mental/physical wellbeing, and harms companies and individuals alike. Even if they’re not doing it deliberately (and some are), they’re harming individuals without any cause or justification.

As an industry we need to stop pretending that crunch isn’t a problem, but we also shouldn’t pretend that it’s ever going to fully go away. The economic incentives for it are very strong, and trying to stop motivated workers from crunching will fail because it feels too good in the moment. But as an industry we must give workers as much control over the process as possible. Pushing QA to crunch is always wrong because they do not have the creative control or social power to handle it properly. Scheduling for perfection creates destructive tension between developers and production and creates wasted work. Allowing severe crunch for months on end is guaranteed to substantially harm workers no matter how passionate they are. It is unethical to perpetuate these practices, and those of us with clout in the industry must do what we can to improve it, for the health of the entire industry and everyone who works in it.


Stop Normalizing Player Harassment

/

Last week I was in San Francisco for the 2018 Game Developer Conference and I actually learned some things. This year I went with the Independent Game Summit pass, which got me into indie-themed talks on Monday/Tuesday as well as sponsored talks. I highly recommend the pass as it’s much cheaper than the full pass and the talks were high quality. It does sell out though, so you’ll need to buy it early. I’m always very interested in player psychology, so I enjoyed several sessions from the Advocacy and Fair Play Alliance tracks. The single best session I went to this year was “Microtalks in Player Behavior” presented by several academic and industry researchers, focusing on player harassment and negative/toxic behaviors.

Melissa Boone started with an overview of Microsoft’s research into player harassment. Many players reported developing a “thick skin” to deal with harassment but from follow up reports it was clear that it wasn’t really working. Voice chat was found to be particularly dangerous because it reveals traits like gender/background that are frequent targets for harassment. Also, many players wouldn’t bother reporting slurs because they felt like tattletales, due to how common they were.

Andrew Przybylski from Oxford reported results from an academic study into cyberbullying in mobile gaming. In a sample of 2k 14-15 year olds in the UK, 33% had been bullied in mobile games, with 9% being bullied persistently. Being male, nonwhite, and having a history of previous bullying made people more likely to be victims. 40% indicates they were significantly affected by the bullying but sadly only 4% reported the issue to the developer, as the vast majority of mobile games do not have any way of reporting issues like this.

Natasha Miller reported results from Blizzard’s research into player harassment in Overwatch. At the start of the investigation 90% of players reported receiving harassment while 50% felt that reporting was completely ineffective. They first tried sending emails to reporters after enforcement, but this had no effect on perception. They switched to in-game messaging and that was much more effective. They also added in-game warnings to perpetrators. Together, this improved perception of report effectiveness by 40% and reduced toxic chat by 25%. These numbers aren’t super solid because they could easily be confounded by changes in enforcement, which were not discussed. But it does match with what I’ve heard from Riot before where in-client messaging was key to creating change.

Katherine Lo gave a really interesting talk comparing industry approaches to player harassment with the D.A.R.E anti-drug program of the 90s, which was largely a failure. One of the negative effects of that program was by emphasizing that “drugs are everywhere” it helped to normalize the behavior and made teens who abstained feel socially isolated. Relatedly, exaggerating the scope of online harassment has been shown to specifically make men think the problem is less important. Also, by creating a policy of Zero Tolerance it groups minor issues with more severe issues, which can encourage progression from one to the other because they are “just as bad”. Lastly, programs that try to discourage behavior in teens from the top down do not generally work as they are naturally resistant to arbitrary authorities. It’s important for developers to establish that the judgement of a behavior not being socially acceptable is from peers and not from “game cops”. When giving out punishment transparency is also helpful as it makes it feel less arbitrary, reducing resistance. Katherine’s talk had the most interesting ideas but the least hard data and I’m really interested to see it expanded into some proper empirical studies.

Lastly, Naomi McArthur gave an update on player toxicity research from Riot. She discussed how personality factors and cognitive biases could increase toxicity but much of her research focused on the importance of ingroup/outgroup dynamics in causing toxicity. On a team of 5 players you want to create a social ingroup that is fighting against the enemy outgroup, but the pressures of ranked matches and game mechanics make this difficult. When a team of 5 had one premade duo it showed no more toxicity than with no duos, but 2 premade duos showed a 36 percent increase because it pitted the two duos against each other socially. Also she mentioned the importance of community norm perception. If players perceived that intentional feeding of kills to the enemy team was a “common problem” they were significantly more likely to take part in it themselves.

All of these talks hit on a common theme: If abuse of other players is perceived as normal, players are more likely to commit it. This makes sense because if something is seen to be socially acceptable by your peers, you’re more likely to do it. Punishments from above can help to reduce this, but can only go so far. The real key is to make it clear that the player’s peers do not approve of the abusive behavior. Sure, there are some dedicated trolls who actively enjoy violating social norms, but they are not the direct source of most of the abusive behavior in games. The research shows that the vast majority of players do not approve of player harassment, and game developers need to find ways to make it more clear that harassment is not accepted by the player community at large.

Game Jamming with UE4

/

As I'm just starting to get into Indie development after 12 years of AAA game development, I wanted to enter a Game Jam as quickly as possible. Luckily, The Idle Thumbs community organizes a regular game jam called Wizard Jam that was absolutely perfect for me. The rules and timeframe are pretty relaxed so I decided I wanted to spend about 3 days building a game in UE4, using as many of my own assets as possible. So, I decided to learn lighting, modeling, and animation and build a simple game. The end result is General Interest, a minimal RTS where you command an army of interest-earning securities to take over the market/colored terrain rectangle.

The game is nothing special, but I wanted to write up some of my thoughts on the process of making something for a Game Jam as it may help others. There are other resources for this including the UE Wiki and tons of video tutorials. Because I'm a programmer with limited art skills, most of this advice assumes some basic experience with coding in UE4. Anyway here we go!

Getting Started

When you're making a game for a jam you probably want the smallest amount of content and code possible, so when you make your project you need to be careful. I started with a Top Down C++ project because I was making an RTS, selected PC as target, and brought in starter content. After my project built I jumped back into the editor and started pruning things. First, you may want to delete much of the starter content. I ended up deleting everything other than the materials, but don't delete things you may want to use. Also at this point I went into the Edit->Plugins menu and disabled lots of plugins. The default setup includes things like VR that you won't want in your project (unless it's a VR game of course). This would also be a good time to enable any marketplace content you're going to use, I didn't end up using any for this project. Finally, make sure you go to the Edit->Project Settings page and fill in your project description details, as you're about to generate some code classes

The next step is to build out the framework for your game. As I am a programmer by trade I wanted some new base classes and structure, that I would then iterate on via blueprint subclasses. The easiest way to do this is to do File->New C++ Class. In my case I wanted a new Game Instance (which is a class that sticks around between levels so can be used for things like high score saving), but depending on your template you may need a new Player Controller or Character as well. Once you have your c++ base classes you should then make blueprint subclasses of all of them, which is where you will do the rapid iteration. Just making the classes isn't enough, you'll have to tell the project to actually use your new classes from the Maps and Modes page of project settings, or on a specific map using world settings. I had a title screen and several RTS maps so I ended up making two separate game mode blueprints.

Making Your Game

Okay, we have the classes, now to actually add stuff to them! What to do next depends on your game, but because I was making an RTS I decided to implement the hp/money generation in c++, the input handling half in both, and all of the visual/audio entirely in blueprints. So my first task was to make a Data Table base class:

USTRUCT(BlueprintType)
struct FInvestmentStats : public FTableRowBase
{
    GENERATED_BODY()
    /** Max/starting HP for this investment */
    UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Stats)
    float MaximumHP;
};

I added a bunch of stats here and made a separate structure for the terrain info. The next thing I started doing was adding a bunch of BP events and public variables to my Character subclass:

    /** Targeted character to interact with */
    UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = Control)
    AGeneralInterestCharacter* TargetedCharacter;

    /** Blueprint callback when hovered over */
    UFUNCTION(BlueprintImplementableEvent)
    void OnSetHovered(bool bInIsHovered);

Once I was done building out the C++ framework I then went back to the editor and started using it. I made Data Tables for my investment and terrain stats and filled them out with bad guesses at fun values. I then went into my Character BP subclass and started implementing all of my events. I then spent 2 days iterating by adding new events, implementing them, tweaking values, etc. How to build your game depends heavily on your game genre and your personal skill set, so look for more general UE4 information online if you need help with this part. There's one more step:

Releasing Your Game

Okay, you're happy with how your game works when you playtest in the editor, the final step is to get into an actually releasable state. This can be a bit confusing, so let's go through the steps:

  1. Test your game using Launch: If you use the Launch drop down and select your PC it will cook and create an almost-final version of your game. Things like cheats will still work, so you can look for and address any issues that may pop up. Notably it defaults to full screen.
  2. Change your cook settings: By default if you don't set anything up it will cook all of the content in your game, but that might pull in things you don't want and bloat your download. The easiest way to do this is to modify the List Of Maps to Include in the Packaging Settings. For a game jam game that's probably enough.
  3. Prune your cook content: I also turning on Exclude Editor Content When Cooking and Create Compressed Cooked Packages. This will break any uses of editor content like the built in sounds, though, so you may need to clone a few assets.
  4. Enable Shipping: If you don't want your users to have access to cheats, enable For Distribution. This isn't a huge deal for game jam games but it will also make your download smaller.
  5. Make a packaged build: To do this go to File->PackageProject->Platform. This will ask you where to save it, then it will take a few minutes to build and create a final packaged build.
  6. Test your packaged build: When you package it creates a Platform folder, and inside that a GameName.exe. This is a tiny executable that just launches your real one, which is in GameName/Binaries. Anyway launch GameName.exe and if it works you're good to go.
  7. Create a distribution package: This depends on where you are distributing, for Itch.io you want to make a Zip file called GameNamePlatform.zip, containing all of the contents of the Platform folder. You want GameName.exe to be in the topmost directory. You can safely delete the manifest, but you need everything else,
  8. Distribute it: For Wizard Jam this was dead simple because it integrates right into Itch. So I made an Itch account and set up my game page where I could upload my zip file. You want it to be "no payment", and make sure to select the right platform for your zip file. If you do this properly it will work from both the itch website and the desktop client.

And there you go! That's an overview of how I built my game jam project in UE4, skipping over all the hard-to-describe actually-making-the-game bits. If you have any questions or comments you can either email me or leave one here. Good luck with your game jamming!