We made every effort to simplify and visualize our findings on the main pages, but this understandably could leave the more data-curious folks a tad unsatisfied. What does "Snowball” mean (i.e. definitions)? Why did they code a card for Tailor but not for Recover (i.e. methodologies)?
This series of posts is written for our more data-curious visitors. It provides an in-depth review of our SUD System, a catch-all term for the framework we invented to help anyone analyze the game of Smash Up. The SUD System (or SUDS) provides conceptual tools to wrangle new data and arbitrate analyses. We get data from all over the community and in a wide variety of formats, so we invented SUDS to be a kind of referee and rule book all-in-one. We’ll introduce the core concepts as they become relevant, starting with a series of posts on all the Effects. Then we’ll move on to Playstyles, then comes Synergies, and finally, Performance. Enjoy!
EFFECTS
Cards are a lot of fun to code and analyze, and wow the game is full of them. Granted, the whole of a Faction is greater than the sum of its cards, but Smash Up is a card game, so that's where our analysis begins. Card count metrics are supposed to be clean and simple. Would you like a count of minion cards? No problem. How about average minion power? Easy-peasy. You get the point. These stats are clean and simple, but they don't tell us too much about what it's like to play a Faction or what Factions work well together. We need to tackle the ability text, and that's where things get interesting.
After the basic attribute card counts and ratios, we move on to ability text string searches. This gives us clean and simple card counts for abilities that contain “Special:” or “Talent:” text strings. However, it doesn’t take long to see the text-string methodology is flawed. For example, America Chavez’s ability text contains the string “move,” but her ability doesn’t actually move anything. Uh-oh. If we're going to do this right (and without earning degrees in natural language machine learning), then we're going to need a a better way to code card abilities.
What we ended up creating was a list of things called, Effects. Effects are all the different ways an ability can affect the game. The keyword here is “affect.” All the Effects are verbs, because they categorize what cards do. The Effects themselves were identified and defined by performing a content analysis of every single card in the game. That’s just a fancy way of saying we went card by card and marked yes/no which Effects were present in the card ability.
We started with a blank slate of Effects - no Effects - and only created a new Effect category when an ability failed to map to an existing one. Then, abilities would pop up that challenged our understanding of the game and our Effects. Sometimes an Effect needed a small adjustment. Other times we were forced to split up an Effect, or merge multiple Effects, or finally create a new Effect altogether. Each time we made a change, it meant going back to review and recode cards. But eventually, the Effects were so clear and consistent that the process got easier and easier with every new card coded.
Next stop for the Effects series is the card Lifecycle!