Gender breakdowns in Super Smash Brothers

I am not the biggest Super Smash Brothers fan, but I'm a big one. I've owned every game, watched the documentary, and embarrassed myself in front of non-nerds. I'm not a hardcore smasher, but I really enjoy the series.

I was curious: how many of the characters are female? I'd hardly call this a "big data" problem, but I took a crack at it.

First, I took a look at the character counts; how many characters are there per game?

Character counts graph

Based on this, there are an average of 15 new characters per game, and if that trend continues, the next game will have 65 characters! A second-order polynomial curve of best fit gives an estimate of 61.25 characters. I've found myself overwhelmed by the latest game's offering of 50 characters; what will a number in the 60s feel like?

Next, I split characters into four groups: unambiguously male (henceforth referred to as "male"), unambiguously female (henceforth referred to as "female"), androgynous (like Pokémon), and characters whose gender you could choose (like Villager). There are more males in the series than any of the other groups combined:

Gender breakdown for all games

This looks a bit bleak. Perhaps things have been getting better over the years? If you break things down by game, though, it's unclear what's going on:

Gender breakdown by game

You see a different trend depending on what numbers you look at. On one hand, the number of female characters increased from 1 to 8 and the number of "choose" characters increased from 0 to 5. On the other hand, the first game was 75% male, Melee was 65% male, Brawl was back up to 76%, and Smash 4 was 62% male. It's hard to see a strong positive trend.

Nintendo should rename the game to "Smash" and have more diverse characters!

Footnotes

I made a number of assumptions while going through this data. Unless you're quite interested in the minute details of this post, I'd skip this:

  • I didn't include any of Smash 4's DLC characters.
  • Duck Hunt: The Smash Wiki entry says that the off-screen hunter "is supposed to represent the player" and therefore varies with gender, so I placed Duck Hunt in the androgynous category. The dog is male, so you could argue that I mis-categorized.
  • Ice Climbers: players can choose which character is controlled, so I placed Ice Climbers in the "choose" category. This could be in the androgynous category, or its very own category.
  • Pokémon: while some Pokémon are considered masculine or feminine by some, their genders are unspecified in the Smash games.
  • Pokémon Trainer: I counted Brawl's Pokémon Trainer as one male character, but one could consider this three androgynous characters.
  • R.O.B.: I didn't think R.O.B. had a gender but the SmashWiki says he's male.
  • Rosalina & Luma: I sorted the pair as "female", but one could debate that the Luma is male and should be sorted elsewhere.
  • Sheik: There's debate about Sheik's gender. I chose Sheik to be female throughout this post because the Smash series refers to Sheik as female, but there are plenty of interpretations, all of which are probably offensive to somebody. I apologize to anyone offended by this choice.
  • I didn't include data from the Project M fan mod.

I wrote some code, made some CSVs, and used Apple's Numbers program when writing this post. You can find all of those files here.

Programming languages and their ecosystems

There was an article called "Ruby is defined by terrible tools". I haven't enough Ruby experience to know whether its thesis is true, but one quote really stuck out for me:

Programming languages cannot be considered separately from their ecosystems.

I totally agree with this, almost to the point where the language itself is secondary to the tools. "Softer" things can go a long way to making a language good to work with: package management; documentation; tooling; community.

Personally, I feel this way about Node. I don't find JavaScript a pleasure to work with, but the Node ecosystem is solid.

How to clear all inline styles from an HTML element

In short: set the styles to the empty string to clear all styles (for example, myElement.style.cssText = "";).

As a front-end developer at Braintree, I deal with the DOM a lot. For reasons I could bore you with, I needed to use JavaScript to clear all inline styles (but not styles applied from CSS) from an HTML element.

After trying a few less-than-ideal solutions, I found a one-liner that solved the problem: all I had to do was set its cssText to the empty string, like this:

myElement.style.cssText = "";

That cleared all inline styles! As far as I can tell, this worked in every browser I tested (though I didn't test less than IE8).

Hopefully this little trick can help you.

Overwriting document.head in strict mode on Safari

In short: you can't overwrite document.head in strict mode if you're on Safari, so be careful with your polyfills.

This is a pretty niche post, but I ran into this problem today.

document.head is a convenient reference to the <head> element that you can reference from JavaScript. Unfortunately, like many convenient features, not all browsers support it.

Luckily, it's an easy fix. Mathias Bynens has a helpful post where he shows how to polyfill it. It's a one-liner:

// Credit to Mathias Bynens for this line!
document.head = document.head || document.getElementsByTagName('head')[0];

This has the nice benefit that it works in all browsers, old and new...except for Safari when you're in strict mode.

Safari (both on desktop and on iOS) will throw an error when you try to overwrite document.head if you're in strict mode. This means that the following function will always throw an error:

function polyfillDocumentHead() {
  'use strict';
  document.head = document.head || document.getElementsByTagName('head')[0];
}

Now that we know that this is an issue, we have a couple of options.

  1. We can use a second example from the original blog post:

    // Credit to Mathias Bynens again!
    document.head || (document.head = document.getElementsByTagName('head')[0]);
    

    This will only reassign it if it isn't defined, which shouldn't happen on Safari. Unfortunately, linters will complain about this line by default (that includes JSLint, JSHint, and ESLint). You can use your favorite linter's "don't lint this line" feature or disable the checks for that entirely.

  2. You can never reassign document.head and simply assign it to a new variable.

    var head = document.head || document.getElementsByTagName('head')[0];
    

    If you're encountering this problem in a CommonJS environment (like Browserify or Webpack), you can use my new document.head npm module. It works just like the above, but it might save you from having to write the line above every single time. You use it like this:

    var head = require('document.head');
    

    The whole module is one line!

  3. We could sidestep this problem entirely by using a selector library like jQuery.

And there you have it: properly shimming document.head when you're in strict mode and on Safari! I do not expect this niche post to make it to the front page of anything other than this blog.

Pietime, my entry to JS1k 2015

For the uninitiated, JS1k is a JavaScript code golfing competition. To quote its about page, entrants "submit a self-contained demo in 1024 bytes of pure JS, which in turn may use various web technologies." In other words: see how much you can fit into just one kilobyte of JavaScript code.

There have been some incredible entries. 2013's winner might be my favorite, but there are plenty of other amazing submissions. It's almost spooky to see how much one carefully crafted kilobyte of JavaScript can produce nowadays!

I've been entering since 2013, but I actually placed in the top ten this year! You can check out my submission here. It lets you tell time using a non-traditional method: pie charts.

Many of the lessons of Daniel LeCheminant's four-kilobyte StackOverflow clone were helpful when squeezing my entry into the byte limit. Perhaps the biggest lesson was unintuitive: repeat yourself! The JSCrush JavaScript compressor can better compress repeated code than fewer characters. That's why my code has lots of lines like this:

canvas.c.beginPath();
canvas.c.moveTo(s / 2, s / 2);
canvas.c.arc(s / 2, s / 2, s * 0.45, 0, 2 * Math.PI);
canvas.c.stroke();

I could've used with, but that turned out to compress worse than repeating myself like that. That was surprising to me!

Give my submission a look if you'd like, but definitely check out the other entries from this year—there are some really cool ones.