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!