Archive for February 24, 2014

The Beta: Before and After

The wave 2 cards are finalized and available for download, so I thought it would be interesting to look at how far we came during the beta. For this blog, I grabbed the oldest iteration of each wave 2 master I could find and put it next to its finalized version. This doesn’t include upgrades or supporting models, but it gives a good general sense of how each master developed, and gives some of you a glimpse behind the curtain at iterations that never even made it into the public beta. It’s surprising how little some of them changed, and others were rewritten entirely. It just goes to show how much the beta accomplished! (I would suggest opening these with Adobe Reader)


Lucius Before the Beta

Lucius After the Beta

Hoffman Before the Beta

Hoffman After the Beta


Jack Daw Before the Beta

Jack Daw After the Beta

Hamelin Before the Beta

Hamelin After the Beta

Leveticus Before the Beta

Leveticus After the Beta


Kirai Before the Beta

Kirai After the Beta

Molly Before the Beta

Molly After the Beta

Ten Thunders

McCabe Before the Beta

McCabe After the Beta

Yan Lo Before the Beta

Yan Lo After the Beta

Shenlong Before the Beta

Shenlong After the Beta


Colette Before the Beta

Colette After the Beta

Ironsides Before the Beta

Ironsides After the Beta

Kaeris Before the Beta

Kaeris After the Beta


Collodi Before the Beta

Collodi After the Beta

Dreamer Before the Beta

Dreamer After the Beta


Mah Tucket Before the Beta

Mah Tucket After the Beta

Ulix Before the Beta

Ulix After the Beta

Wong Before the Beta

Wong After the Beta


Designing Showdown


Originally posted in Wyrd Chronicles Volume 10.

Showdown is a fast-paced, bluffing card game. To find out more about it, watch the Tom Vasel review here. At the moment the Shodown game is set in a dark, futuristic world featuring the “Icons.” This was not always the plan. Showdown was actually originally designed to be a Malifaux product. However, at that time our Malifaux artists were busy getting art ready for M2E so Showdown needed a new theme. I am very happy with the dark, sci-fi theme that we ended up with. It’s a fun twist and something a bit different for Wyrd. But Malifaux is something I’m passionate about, so today I proudly announce that five new Malifaux themed Showdown decks are in the works. To celebrate this, I wanted to talk a bit about the Showdown design process.

I was originally inspired to pitch Showdown to Wyrd after playing Yomi ( Yomi is another fast-paced card game focusing on bluffing. Each player has a deck of cards (which doubles as a regular poker deck) which represents a character in a martial arts battle. As soon as I saw the concept, I was intrigued because I saw the potential for Malifaux. If I could design a game that would fit onto a regular deck of cards (aside from the traditional games like Hearts, etc) then we could produce Malifaux fate decks which players could use during a game of Malifaux as their fate deck while doubling as a totally separate game. It would give Malifaux players something to do in between rounds at a tournament, while waiting for a pick-up game, etc. Additionally, if it was simple enough, it could help introduce more people into the Malifaux universe.

After playing and getting to know Yomi I got some ideas for where I wanted to take the design as well. In Yomi, each player plays a single card face down and then flips them up simultaneously. A “rock, paper, scissors” system is then used to resolve combat: attack cards beat throws, throws beat blocks and dodges, and blocks and dodges beat attacks. The winner assigns damage and play continues until somebody is knocked out. Based on that brief description play may seem random, but there is a lot of depth in reading your opponent, knowing the decks, and trying to get off combos. If you haven’t played it, I highly suggest checking it out. However, there were two things about Yomi I felt that I would personally like to see changed, so I set out to design a system that was inspired by Yomi, but created its own unique system.

My first issue with Yomi was that it involved a bit of tracking. Characters generally have between 80 and 100 health, and players need to keep track of where it is. This means that the game requires a pen and paper (or one of the slick Yomi play mats and a counter) to keep track of health. For Showdown, I wanted players to need absolutely nothing other than two decks of cards; this would make the game much more accessible after a game of Malifaux. So I came up with the system of using the Aces in the deck for health. Basically, each player removes the four aces from their deck at the start of the game. Every time they lose a battle, they flip one of their aces face up. When they have no more aces to flip, they lose. This solved my tracking issue in a neat little package, and allowed players to need nothing other than the cards. It also opened up some fun design space. As aces are flipped face up, they grant the player some special abilities, which created a fun “catch up” mechanic for a player who was getting steam rolled. It also created some nice variety in play, as the order in which your aces get flipped up will change up the game play. Finally, having such little health created a fast (15-20 minute), intense experience that was very enjoyable during testing and perfect for the “in between” space a game of Showdown was designed to fill.

The next place that I wanted Showdown to be differentiated from Yomi a bit was in the bluffing. Because Yomi only uses a single card during combat, knowing your opponent’s deck is critical. For example, if you know your opponent has a deck with a lot of throws in it, you will be more likely to play an attack. This is great, but for Showdown I wanted to emphasize knowing the player more than knowing the deck. To do this, I used a two card system. In Showdown, players each play one card face up, and then one card face down. This means that when you play your face down card, you will have some limited knowledge about what your opponent is trying to do, as you will be able to see their face up card. The two card system gave players just enough information about their opponent’s plan to make bluffing interesting without making it predictable. There is, of course, a bit more to it than that, and if you’re interested I would highly suggest watching the Tom Vasel video I linked above or checking out the free online rules.

I think it’s interesting that I was able to create an entirely unique experience by tweaking two of the dynamics in Yomi. This is a fun way to look at game design in general, and I think it shows the flexibility in the model of game which Yomi pioneered: a single deck, asymmetric bluffing game. Personally, I would love to see this catch on and become its own genre, much like the deck building games. But, even if it doesn’t, I’m proud to have helped add to this space.

With many of my decisions hinging on selling this as a Malifaux product (the fast play, the lack of any resources other than the deck itself, etc) I was a little hesitant to retheme the game. But once I saw the amazing sci-fi art that was going on the game, I was all the more excited for it. Even so, I can’t wait for the next five Malifaux decks we have in store for you.

I also want to note that I wrote this article from my perspective: David Hanold and Redd Cohen were instrumental in designing this game, and I don’t want to leave them out here. In fact, they designed the five Malifaux decks which are coming your way with only playtesting input from me, and they did an amazing job.

The Language of Games


To a certain extent, I see rules as a language. The strength of having clear, well-defined rules is that two players who have never met before can come together and play a game without any arguments about what their models do.

This is why I will never condemn a player for wanting the rules to do exactly what they say. Only when players interpret the rules as they are written, not as they think the rules *should* be, can a game accomplish that level of clarity. This goes back to the old argument of Rules As Written (RAW) vs. Rules As Intended (RAI). A player who wants to play the rules exactly as they are written is a fan of RAW, where a player who tries to guess what the designer intended is a fan of RAI. The issue with attempting to guess another person’s intent is that not everyone’s interpretation of that intent will be the same, so house rulings and patches crop up, making it more difficult for gamers from two different groups to play a game together. In other words, as time goes on and more house rules are made, those two groups of gamers will slowly evolve separate rules languages until they are ultimately unable to communicate.

Now, I have no issue with house rules, so long as players recognize them for what they are. If it isn’t obvious, I’m more of a fan of RAW than I am of RAI, although I would never judge another person for how they choose to play the game. I just think that playing the game as it is written leads to the least amount of confusion.

This may be a bit of a surprise to some of you, after all, I wrote the rules (well, good portions of them, it’s a group effort). Why wouldn’t I want people playing the rules as I intended them? And haven’t I been seen on the forums calling for a “common sense” interpretation of the rules? Doesn’t all of this point to more of a RAI point of view?

Not necessarily. While I most certainly would like the rules played as I intended them, I find that when people guess at my intentions they are rarely correct (no hard feelings – I probably wouldn’t be able to guess about your intentions either). Also, in my experience, telling the difference between RAW and RAI can actually be more difficult than it seems. Rules As Written tends to have the bad reputation of being the most lawyeresque, strict, knit-picking interpretation of the rules possible. I would argue that this isn’t always the case and that, frequently, Rules As Intended arguments end up being far more strict and counter-intuitive. Let me give you an example.

In this thread the following question came up: Does Lilith need to be able to draw Line of Sight (LoS) to a Silurid in order to target it with a Ca Action?

The reason for this question was that Lilith and the Silurid have the following abilities:

On Lilith: Master of Malifaux: This model is not affected by severe or hazardous terrain and does not need LoS to target models with Charge or Ca Actions.

On the Silurid: Silent: Models cannot ignore LoS or cover when targeting this model.

Taken at face value it would seem that Lilith would indeed need LoS to target the Silurid, as her Master of Malifaux ability is negated by the Silurid’s Silent ability. This makes the most intuitive sense, because otherwise there is seemingly little reason to have the Silent ability at all.

On the other hand, the argument was made that Silent stops models from ignoring LoS restrictions, but Master of Malifaux simply states Lilith does not need LoS. In other words, Lilith doesn’t ignore LoS, she simply doesn’t need it, therefore she can target the Silurid. At first, this would appear to be the proper RAW interpretation of the rules. However, I would argue that it is not.

This entire argument is predicated on “ignoring” a restriction being different than “not needing to adhere to” a restriction. Although slightly different wording is used, they do indeed mean the same thing, and that’s the important part. Because they mean the same thing in the literal sense of the English language (although not necessarily the exact wording used) the two rules do interact with each other, and Silent will effectively negate Master of Malifaux, forcing Lilith to draw LoS as normal. The best argument against this interpretation is that if the designers had intended these two rules to interact, they would have been sure to use the same language; in other words, it’s a Rules As Intended interpretation (and an incorrect one) which is the more strict and counter-intuitive of the two arguments.

I think I have shown how trying to guess the designer’s intent can actually lead to the less intuitive conclusion. But it begs the questions, why don’t we just always use consistent wording to avoid this? And when does strict wording matter?

Strict wording matters when you are dealing with game terms. Game terms are definitions which are strictly outlined in the rulebook and which have a different definition than the usual English definition. For example, in Malifaux, “killed” is a game term. When a rule says that a model is “killed,” it does not mean the model’s heart stopped beating, it means the model is removed from the table and drops any applicable markers. This is very different than the English definition, so we spell it out in the book, and it means something entirely different than other terms (like sacrifice). Placement is another game term (call out box pg. 51), because in Malifaux “placement” is different than “movement” (when in the literal sense placing something is generally going to involve moving it). Reducing damage is different than preventing damage, etc. When the rules use a specific game term, they are speaking very strictly about that term, and that term will be defined in the book. However, when the rules use the English language, they are referring to the literal definition of that language, but the exact phrasing isn’t as important (this is why “ignoring” a restriction is the same thing as “not needing” a restriction).

Alright, now we know when to adhere to strict wording and when not to. All that said, what about the first question, why not just use perfectly consistent wording in all rules which the designers intend to interact? Why use “ignore” and “does not need” at all? Why not just choose one and stick to it? Part of the issue is sheer manpower and deadlines. With enough people and enough time, we could certainly do a better job of this. But, even with infinite time and manpower, there are still very good reasons to rely on the English language definitions as opposed to making everything into a game term. I give an example of this in the thread I linked above:

This is hardly the only example in the rules (NOTE: speaking about the Silurid/Lilith debate), it’s just the one the forums have latched onto for the moment. For example, a model which is inflicting damage usually “deals” damage. A model which is taking damage usually “suffers” damage. Ideally, these would have been the exact same term. But it would have lead to weird sentences like this:

“When another model is suffering damage, this model may discard a card to force the target to suffer 1 additional damage.”

Compare this to:

“When another model is suffering damage, this model may discard a card to deal 1 additional damage.”

You can see the economy of space there, if nothing else. And, before people pick this apart and start trying to show how they could have used the exact same wording while saving space AND making sense, keep in mind this is only one example. You would have to do that hundreds of times, no two the same, and screwing it up even slightly means nobody understands the rule.

The dealt/suffer wording in regards to damage is just one example. And it’s one which could have a weird rules interpretation, if the RAI route is taken. For example, the Armor ability states:

Armor +1: Reduce all damage this model suffers by +1, to a minimum of 1.

This could lead to the argument, “If the designers had intended Armor to reduce damage from this *insert action or ability here*, they would have used the wording ‘suffer’ instead of ‘dealt.’”


Clearly this is not the interpretation we wanted (nor is it the correct one) so why did we leave ourselves open to it? Two reasons: grammar and card space.

Depending on which model is the subject of the sentence, the appropriate word changes. For example, if the model taking damage is the subject, then “suffers” is the appropriate word to use (i.e. this model suffers damage. The model being damaged is the subject). However, if a model is inflicting damage, then “deals” is the appropriate word to use (i.e. this model deals damage. The model doing damage is the subject). Keeping the wording consistent for all situations would have involved some creative writing to change the subject of the sentence, which would have led to some strange (but totally consistent) wording. Unfortunately, this wording makes less sense in the context of the English language, and English wins, because it’s what we speak. Ignoring the language we speak makes this game a lot less accessible to new players.

Economy of space is equally important. Ultimately, a card is a pretty tiny space in which to write a complex rule. You have no idea how many hours I have spent tweaking, rewording, and adjusting kerning to make the rules fit. That extra line or two does, absolutely, matter.

And, at the end of the day…nobody has ever (to my knowledge) made this argument about Armor (yes, I know, they will now. Shut up.) The rules are intuitive, players get it. And that counts for a lot.

Armor cat

Armor cat laughs at your rules arguments.

I think I have made my position about as clear as I can, but there is one more question I would like to address. Why don’t we just add a few extra lines to make the rules as absolutely clear as possible? Well, first is manpower and deadlines, of course I wish we were better at this. Even with unlimited resources, we still run into the card space issues I mentioned above. However, there is one more reason we don’t always do this: Every line is a line that can be misinterpreted.

I almost want to get that tattooed on me somewhere. It would just be awkward quoting myself.

Every line is a line that can be misinterpreted.

-The dude who’s elbow this is

I could write paragraphs about how each individual rule works. But somewhere buried in that paragraph would be a line that is either ambiguous or which people really want to mean something else, and a whole new argument starts. When writing rules, you just need to keep them succinct, clear, and then encourage the player base to interpret them with a grain of common sense.


After thought: how many pages are the official Magic the Gathering rules? If you don’t already know, take a guess before you click.

Running The Malifaux Beta


There are two key skills to game design; predicting human behavior, and running the numbers. Games are played by humans, so predicting how they will react in the game (and how they will feel about the game) is absolutely key. That’s not something you can figure out just by calculating statistics, because people don’t always make the logical choice (or even play a game for the same reasons). On the other hand, you don’t want a system that can be broken and manipulated, so you also need to run some hard numbers and know your statistics. This is important both so that you can make sure that the most intuitive choice is also the most statistically viable choice, and to make sure that six months after release someone who does understand hard statistics doesn’t release a net list that dominates your meta.

A single game designer only needs one of these skills; but a game will need people with both skill sets to function. I’d like to think I’m capable of doing the tight rope walk between both of these skills, I would argue they’re pretty much the only two things I’m good at. Luckily, running a public beta falls very heavily into one of these areas: predicting behavior.

The past four months of public beta have been a hell of a ride. If a beta like this goes bad, it can go VERY bad. Every time I mentioned to another game designer that I was running a public beta, I always detected a little bit of a cringe. All too often it can just turn into a non-productive hate fest that nobody wants to talk about once it’s done. I think we can all agree that was not the case for the wave two testing, but why not?

First, I need to give credit to the community. You guys are awesome. The Malifaux community is one of the most mature, respectful gaming communities out there, and I don’t know if I could have pulled this off with another fan base. Also, I need to give credit to the hard working moderators who kept an eye on things.

That said, we are all gamers. We were all on the internet. And we all showed up to the beta to argue a point. Even with an amazing community, that can be a recipe for disaster, so I needed to get ahead of the game. I needed to provide an environment where the great community we had could live up to its full potential.

First and most importantly, I set a schedule and I stuck to it. Updates would come once a week, every week, on the same day. This is something I instituted in the Showdown playtest, insisted on continuing during the wave 1 beta, and kept up here. Updates for this beta came every Tuesday. Even the day was no accident. I poled a number of people behind the scenes and found that Monday was the most convenient day for a beta update (followed by Tuesday). Unfortunately, Monday didn’t work for me, because most playtest games are played over the weekend and I don’t even see them until Monday, so Tuesday became update day. This gave me enough time to input the data, and gave the player base enough time to digest the rules before their games on the weekend. I stuck to this schedule rain or shine, posting updates on Christmas Eve and New Years Eve. I did post two updates at odd times in the morning the day before my daughter was born and the day we came home from the hospital (yes, we spent a week in the hospital, that was fun) but that was pretty much the only thing I let get in my way.

I kept to such a strict schedule because a predictable schedule is probably the best behavior management tool you can ever have. When people don’t know when things will happen, they get antsy and, worse, they get bored. People *want* to be productive but, if they can’t have that, they’ll always settle for a little destruction. I can’t point to examples of this in the beta because I didn’t let it happen but, after five years with the school district, I can assure you it would have (and no, I’m not comparing you to children. It’s just how people are. I’m the same way. How many horror stories start out, “So, I was bored one day…” Internet flame wars are no different.)

My next most powerful tool was allowing people to feel heard. I accomplished this in a number of ways. The first and most effective way to allow people to be heard in the beta was simply to put in the changes they were asking for. How many of you can proudly point to an ability and say, “That was my idea!” That’s an awesome feeling, even if you were just pushing for a slightly lower/higher stat. I say that this is the easiest way because…it’s the entire point of the beta. People showed up to influence the game, allowing them to see that influence kept the beta a positive experience. It’s what I wanted, and it’s what the players wanted (efficiency!). Now, that’s all well and fine when the ideas people were pushing were good. Obviously, that can’t always be the case. However, more than once I put a change in I knew would probably be removed just so people could tell I was listening, and try it out for themselves (and, hey, sometimes I was wrong and those things stuck).

Of course, sometimes I reached a point where this wouldn’t work. The suggestions were too varied or there wasn’t enough time to test things I knew might be dead ends. In these instances I jumped in, brain stormed with the community, and did a “mid-week update.” Basically, I tried to distill what people were saying and actively worked with them to come up with something when there wouldn’t normally be an update. This was beneficial when there were a lot of voices going in different directions. It focused the discussion and made it more productive, rather than simply allowing fifty different lines of argument to continue until there could be an update (which is obviously a recipe for negativity).

My final tool for allowing people to feel listened to was to simply…respond to them. I know this may seem obvious, but you’d be surprised how many professionals just don’t respond to emails or private messages. I tried to always respond (admittedly, at the height of the beta, with my daughter being born and spending a week in the hospital, I probably missed a few). Of course, I didn’t just wait for people to reach out to me. If I wanted a better understanding of where someone was coming from, I messaged them.

No matter how you do it, letting people know that they are being listened to is incredibly important. Because if they feel like they’re just yelling at a wall, they’ll get frustrated, worked up, and then just start yelling at each other.

My next tool was preventing escalation by hyperbole. Escalation by hyperbole is something you see a lot on the internet. One person comes in saying, “Yan Lo is a little weak.” The next person responds, “I’ve never seen him lose!” Cut to ten pages later and one guy claims Yan Lo shoots lasers out of his eyes and levels Tokyo on the weekends, and the other guy is claiming that Yan Lo is the worst model ever made and if he goes to print like this he will melt his models down into a point and jam them into his eye because at least then they’ll be able to deal damage. This sort of progression is terrible for the beta, both because it gets people insulting each other, and because it seriously dilutes feedback. I combated this sort of escalation in two ways.

First, I put a lot of emphasis on battle reports. This kept the discussion on hard facts (VP differences, models killed, etc). Hyperbole is a lot more difficult with the truth sitting in front of you. It also gave either side an “out” if they got into a hyperbole war. They could always just politely say, “Well, I’d like to see the battle report.” Of course, keep in mind, I’m only commenting from a community management point of view, battle reports were incredibly useful for a myriad of other reasons (which made them all the more efficient).

Secondly, I put a stop to the escalation when I saw it, and I never allowed any one thread to carry on too long. Usually, if I locked a thread where this sort of thing was happening, neither party bothered starting a new thread. The battle ground had been closed, and both parties wandered away. Granted, not every thread I closed had this problem, but any thread that goes on too long runs this risk, so I made a habit of pruning them. (This also made it easier for me to read feedback. Again, we’re back to efficiency. If you want to run a public beta by yourself, efficiency is something you’re probably going to want to keep coming back to).

Another great tool was recognizing passion for what it was. Sure, a lot of the time that passion was frustration pointed at me. And on occasion I got frustrated right back, and I had to say sorry once or twice. But, at it’s core, everyone was there for the love of the game. If I could take that passion and let people legitimately help influence the game, I won twice. I had one less person unhappy with me, and one more person helping me.

Finally, I encouraged people to give me feedback privately if they wanted. This allowed a number of people who weren’t comfortable with the forums to have a say. Opening this line of communication was very important. It allowed me to get feedback I may have otherwise missed out on while also preventing other, less productive, communication.

For most of the beta, I tried to maintain my distance. I didn’t want my opinions influencing feedback. If I came in and told people how to use a model, that’s how they would use it. Unfortunately, the players who get that model a year from now won’t have me sitting at their table telling them what to do. So, to a certain extent, I needed to let people struggle to see where the system broke. On the other hand, I sometimes needed to pop in and say, “test this.” Or, “calm down guys, here is the story…” When I worked for the school district I had a teacher who told me, “Everything is a moment in time, and you will need to make a judgment call. You won’t always be right, but you do need to make a call. Learn from it either way.” I definitely heard that voice in my head a lot during the beta.

Of course, there was a lot more to the beta. I didn’t even touch on…game design. Or analyzing data, or managing my time, or, well, a lot of things. But I think this beta was unique in how positive it was, and I wanted to spill some light on how I worked towards that. And, again, most of the credit goes to you guys. I provided an environment where the community could be productive, but you’re the ones who did it.

Anyway, this whole process was a great experience, so I want to wrap this up with a sneak preview of one of the first masters on which I had some say on the art direction and character.

Meet Ironsides

(Click image to enlarge)



Sleep Now In The Fire…