Thursday, July 9, 2015

Humble Bundle and Sunset

A Humble Weekly Bundle called Leading Ladies 2 ended earlier today. Maybe I should have posted about this bundle while it was still available, in the interest of not being a slowpoke. However, in retrospect, I'm glad I'm posting this after the fact. Even though this blog doesn't get many visitors, I wouldn't want to risk giving any free promotion to that particular bundle in any way. Mentioning it before now, even in a critical manner, might have had that undesired effect.

None of this has anything to do with the "leading ladies" theme of the included games, by the way. I have nothing against female characters or female protagonists in video games. Eternal Darkness: Sanity's Requiem, after all, was a brilliant game; Super Metroid was a brilliant game; Perfect Dark was a brilliant game. Sunset, however, was not a brilliant game. More importantly, the game's development studio (Tale of Tales) deserves no one's money.

The other games in the recently-ended weekly bundle, as far as I know, are wonderful; I know from first-hand experience that Trine 2 is a perfectly fine game. I also know that anyone who buys a pack of games from Humble Bundle can specify where every cent of his or her money goes: to Humble Bundle itself, to a charity (in this case the Girls Make Games scholarship fund via the Tides Foundation), to any of the developers of the games being offered, or to any combination thereof.

Unfortunately, I can only assume that the vast majority of customers do not bother with these options, and just use the default split (65% equally divided amongst developers, 20% to charity, and a 15% "tip" for Humble). Most customers probably just don't care, and what makes this especially bad is that the default settings will send money to the developers of all the games being offered, regardless of what a customer pays.


Typically, in any Humble Bundle, only a few games (in this case Trine 2: Complete Story, Lumino City, and Hack 'n' Slash) are available for any price (or a minimum of $1 for Steam-only games), while some more games (in this case A City Sleeps and The Marvellous Miss Take) are available to customers paying more than the average amount paid so far, and then some more games (in this case Gravity Ghost and Sunset) are available for a typically higher fixed price (in this case $12). As of the end of this weekly sale, the average amount paid was only $4.23; this means that the vast majority of customers didn't pay enough to get Sunset. However, the developers of Sunset still got money from every customer who didn't explicitly choose to put Sunset's share to zero in the options during payment.

More than 52,600 of these bundles were sold this week, the average paid was $4.23, and (as we can see in the image above) each developer gets approximately 9.3% of the revenue by default. If just about everyone used the default settings during payment (and "everyone" is probably a reasonably close estimate), the developers of Sunset raked in more than $20,600.00 during this sale. And this all happened after the previously abysmal sales of Sunset caused them to have a minor meltdown on social media in which they forsook commercial game development, whined about consumers and capitalism, and acted pretty childish in general.

Their oft-cited insults against "gamers" (shown below) are a joke, but still tasteless; moreover, they're the kind of joke that betrays the true feelings of the joker.

To paraphrase: "Ha ha, look how not mad we are; we're so chill that we're pretending to be mad as a joke! But really, we're incredibly mad."

And then there's this more serious quip:
And here's the best part of all:
In what universe could good video games (or a career in them) be possible without capitalism? But of course they hate the free market when they're the ones who put out the product which no one wanted.

I guess the point of this post is to remind people to be aware of where their money goes in the future. If you're paying less than $12 for a pack of games, there's no reason for any of your money to go to the developers of a game which is only unlocked for $12 or more, especially if those developers are talentless hacks known for being crybabies on Twitter.

Wednesday, June 3, 2015

Steam's New Refund Policy

Originally posted June 3, 2015; updated June 7, 2015 and June 8, 2015.
A shorter version of this article was also published on Gather Your Party on June 3, 2015. Read it here.



Original Post (June 3, 2015)


Just in time for the impending Steam summer sale — which is said to be starting next week — the Steam store has adopted a new policy regarding refunds and returns. In short, with a few very reasonable restrictions, you can get a refund on any game within two weeks of purchase as long as you've played the game for less than two hours.

Steam has, in the past, taken a lot of heat for its lack of a return policy. While many brick-and-mortar stores (at least in the United States) have incredibly lenient return policies (some not even requiring a receipt and thereby potentially opening the door to abuse), online stores selling digital content generally have a less-than-stellar track record when it comes to consumer rights. Actually, before now, Steam might have been one of the worst. Steam's customer support has a well-known reputation for being awful, and Steam developer Valve Corporation has had, for some time, an F rating with the Better Business Bureau. Pressure to implement a return policy has been especially strong from customers in the European Union (who have claimed, though perhaps erroneously, that they are legally entitled to refunds of Steam games according to EU laws).

The new refund policy is a huge step in the pro-consumer direction, and likely a much needed one after the paid mods debacle (which was so poorly received that the decision was quickly reversed). Personally, I don't think the idea of allowing mod developers to charge money for their work was such a fundamentally awful idea; free mods would surely continue to exist. Even if free mods had vanished completely as a result of Valve's meddling, it would have been more sensible to blame the modding community itself, rather than the company which merely provided what the mod developers were evidently so happy to use. In any case, Steam's reputation was damaged by that embarrassing fiasco. It's probably not wrong to speculate that the new refund policy is, in part, an attempt to repair some of that damage.

You can read the announcement and other details of the new policy on Steam's web site, but the key points (and their implications) are as follows:
  • Refunds can be requested "for any reason" (including general dissatisfaction).
  • You can get a refund within two weeks of purchase if your total playtime is less than two hours.
  • Failing to meet those requirements? Valve says "you can ask for a refund anyway and we'll take a look." So try it, and you might get lucky.
  • Pre-purchased products can be returned "any time prior to release" and up to fourteen days after release if your playtime is less than two hours.
  • Refunds on in-game purchases are up to the developer.
  • Some DLC might be non-refundable for various reasons (e.g., consumable DLC having already been consumed).
  • Money is refunded using the original payment method, if possible. Otherwise, the money goes to your Steam Wallet by default.
    • This means, in most cases, you can in fact get a "real" refund after paying with "real" money. Fears that customers will always be reimbursed in Steam credit, which must then be spent again on Steam, are largely unfounded and inspired by poor reading skills.
    • It also means, if you do make a purchase using your Steam Wallet, you will be reimbursed in Steam credit. The return policy is not a trick to turn Steam Wallet funds back into regular money. If that were allowed, they would simply allow Steam Wallet withdrawals instead. You can, however, request a Steam Wallet refund, and get your money back out of the Steam Wallet if you placed it there yourself in the past fourteen days.
  • Refunds are not allowed for anything purchased outside of the Steam store.
    • If you're concocting a stupid plan to acquire inexpensive or free Steam keys from third-party sources like Humble Bundle and then return them to the Steam store for a refund of the full retail price in order to get free money, it's not going to work.
  • Refund privileges will be revoked from individual users if the system is abused.
    • If you're thinking you can get away with buying and returning a game repeatedly in order to play it for free indefinitely, you're wrong. Valve isn't that incredibly stupid, and they will shut you down.
  • If you bought a game for full price right before the start of a sale, it's totally okay to return it for a full-price refund and then immediately buy the game at the discounted price.
    • Obviously, this means the refunded amount for any purchase is the amount that was originally paid. If you think you can get free money by doing the opposite of the above — that is, buying a game on sale and then requesting a refund when the price goes back up — you're out of your mind. Steam has a record of what you paid.
This looks pretty great, especially in comparison to the old policy of refusing refunds outside of extraordinary circumstances. Some might wish that refunds were not limited to purchases in the past two weeks or games played less than two hours, but at least this is a step in the right direction. There are some additional restrictions, as well, but they're all rather predictable and understandable, so it's hard to imagine this policy causing a lot of grief to consumers as long as Steam upholds its end of the deal.

However, while the response from Steam users has been mostly positive despite the restrictions, some independent developers of very small games (and those sympathetic to their situation) want the policy to be more restrictive. Allowing two whole hours of playtime before a full refund, they claim, is too much. As one indie dev puts it:

At least one games writer has also voiced her support of this viewpoint by suggesting a petition to change the policy:

While I can understand the concerns of those who develop very short games which might be completed in less than two hours and then returned, I also want to say "welcome to a real economy for the first time ever" and stress that refunds are a normal part of most business. The video game industry (or, at least, the biggest digital store on the PC end of it) is late to this party. Other industries have to deal with returns, and they do so without complaining. People wear clothes and then return them all the time. Of course, most people do buy clothes to keep them, which brings me to my next point: Not every customer is malicious.

Sure, customers can play through the bulk of an incredibly short indie game within the allowable refund time frame and then get a refund, but they can also engage in straight-up piracy with a negligible chance of getting in any real trouble at all. It doesn't mean they'll actually do either of these things. A satisfied customer probably isn't going to return a game that he or she enjoyed, even if doing so is legal. That's the action of a dissatisfied customer who doesn't want the developer to have any money. If indie developers (who seem to have so much faith in community-driven tools like Kickstarter and Steam Greenlight) can't get people to keep their games without asking for a refund, they might have bigger problems than the exact playtime cut-off point in Steam's return policy.

Three things still do concern me about the return policy:
  1. Steam only allows the actual players of a game to review it, and this is great because it prevents bogus reviews. However, the new refund policy makes it easier to abuse the review system. Someone who wants to write a bogus review can now do so without losing money. Just buy the game, play for a few minutes, review it and return it. I'm not sure what Steam can do about this, though. I certainly don't think people should be unable to review and return the same game. Whatever prompts a customer to request a refund might be exactly the kind of information which belongs in a review.
  2. Some games don't use Steamworks and can be launched from the .exe file without using Steam. In these cases, one could copy the game files elsewhere and keep the game even after uninstalling the Steam copy and requesting a refund. Again, however, I'm not sure what Steam can do about this. It's an inherent risk of selling DRM-free software. Humble Bundle and GOG both sell DRM-free games, and both have return policies which could be abused.
  3. Less importantly, as far as I know, there's nothing to keep someone from buying a Steam game, playing for a couple of hours to get its trading cards, selling those cards on the Steam market, and then returning the game for a refund. I'm not sure if Valve would even see this as a problem, considering that they make money from every Steam market transaction, but developers probably wouldn't like it. I'm guessing this is included in the types of abuse for which a person's refund privileges would supposedly be revoked according to the policy. (Update: It seems trading cards no longer drop within the first two hours of gameplay.)
Developers might worry about the first issue, but the potential for this kind of abuse only makes Steam's review system almost as unreliable as one which makes no effort to weed out non-customers, such as the user reviews on Metacritic. I'm not even convinced that Steam reviews were ever taken more seriously than Metacritic user reviews in the first place. Any developer worried about the second issue should already be using Steamworks or some other DRM, and the third issue is probably (update: now definitely) a non-issue. In any case, none of these things create a convincing argument for flushing consumer rights down the toilet.

Update (June 7, 2015):


Want more Twitter drama? Today is your lucky day. Yesterday, independent developer Qwiboo tweeted a graph showing a dramatic drop in sales of the game Beyond Gravity, occurring around the time that Steam introduced its new refund policy.

https://twitter.com/qwiboo/status/607234539262373888

This looks pretty bad. Perhaps the refund policy is hurting independent developers more than I expected. Then again, this particular graph doesn't prove much. If you look up the game's Steam store price history on the third-party price-tracking site SteamPrices.com, you'll see that a special offer ended at approximately the same time:


The full price of the game is only $1.99, but this 50% discount knocked it down to only $0.99 (which is pretty significant). This information was omitted from Qwiboo's tweet, which also fails to show sales data from before the special offer began. So, wait a second, is this indie dev seriously misrepresenting the sales data to argue more convincingly that Steam's new refund policy is bad for developers? I mean, sure, we would expect sales figures to drop a bit when a refund system is put into place, but the graph originally tweeted by Qwiboo does nothing to prove that the decline in sales is the tragic result of a new return policy rather than the predictable result of a special offer coming to an end.

Bored and unable to sleep in the middle of the night, and not really bothered by the possibility of making enemies, I went and pointed this out on Twitter:

What I had stupidly failed to realize was that, hours earlier, Qwiboo had actually posted additional data which is much more informative, as it shows the recent sales decline in comparison to other times when a discount went away:

https://twitter.com/qwiboo/status/607269536623042560

Their sales always rise and fall as discounts come and go, as expected, but this game's sales do seem to go lower than ever at the very end of the graph (which is when the refund policy was introduced). When I saw this newer graph, I posted a correction to my Twitter feed:

Unfortunately, I doubt Qwiboo ever noticed it; almost immediately after my first tweet, this happened:


Oops! Sadly for Qwiboo, the act of blocking my account didn't really do anything except hide my tweets from Qwiboo and prevent me from seeing their page while signed in. It prevented no one else from seeing my criticism, and in fact only made it slightly harder for me to find out about that second graph which led me to post a correction. I'd feel worse about the whole situation if not for Qwiboo's reaction.

Anyway, I guess the takeaway here is that some independent developers might have been right to fear the new refund policy on Steam. At least some of them, Qwiboo included, really are losing sales.

I still do, however, stand by what I wrote before. The new policy is a strongly pro-consumer move. Steam might need to work hard to prevent abuse of the refund system, and they might even need to add more restrictions regarding what can and cannot be returned in order to make this work for everyone, but I won't be convinced that allowing refunds is a fundamentally bad thing just because developers had gotten used to an economically abnormal situation which was truly bad for paying customers.

While it was unfair of me to imply bad things about Qwiboo before doing enough research to see their updated sales graph, I'm still not sure if anyone should feel bad about their current sales predicament. Here's why: I haven't played Beyond Gravity. I don't know what it's like. How long is the game? How fun is the game? Is it well made? Does it suck? Sure, maybe the game is so short that people really are able to abuse the system by playing every bit of the game within the allotted two hours and then requesting a refund. On the other hand, maybe the game is being returned simply because it's bad, and maybe those previously higher sales figures represent a lot of dissatisfied customers who would have returned the game if they could have done so. I can't rule out that possibility. I just don't know.

Furthermore, I'm sure a lot of people are currently using the refund system as a risk-free way of trying a game, but I still don't know that this is a bad thing. There should be a risk-free way of trying a product before putting down the money. More specifically, I believe every game should have a playable demo, and certain people in the industry disagree but their reasons for disagreeing are thoroughly anti-consumer. They are afraid that players will no longer want to buy their games after playing demos; in other words, they want to prevent customers from having the ability to avoid products with which they would ultimately be dissatisfied.

If people are trying and returning full games as a substitute for playable demos which don't exist, the developers or publishers are to blame for not supplying playable demos. If people aren't keeping the games after trying them, it's only because they're able to make more educated decisions about their purchases, and wishing to deny your customers this opportunity is the same as hoping that your customers get tricked into buying things they don't like. That's pretty terrible.

A person who likes a game is still going to keep it. A person who returns a game for a full refund obviously didn't like the game and is dodging a bullet. A developer who complains about refunds, and who has no evidence that the system is truly being abused, perhaps needs to focus on making a better game instead of complaining.

My advice to developers is this: Make good games that won't be leaving customers with a desire to get their money back, and (although I hate to say it) make sure you implement some kind of DRM if you're uncomfortable with the risk of not doing so.

Update (June 8, 2015):


I'm a little disappointed that people keep on retweeting and quoting my first tweet about Qwiboo (in which I hastily made a judgement based on limited information) while my second tweet about Qwiboo (in which I corrected my erroneous implications) is being ignored. But I guess that's just how Twitter works sometimes.

Anyway, I'd like to mention another independent developer now. They've gotten quite a bit of attention after reporting a dramatic loss in sales following the introduction of Steam's new refund policy:

https://twitter.com/puppygames/status/606391655483211776

They had more to say as well:




Puppy Games is the developer of stylish faux-retro/arcade-style games Revenge of the Titans, Droid Assault, Titan Attacks!, Ultratron, and the upcoming Basingstoke. I've played the first four of these games, which I bought back when Puppy Games was featured on Humble Bundle, and I actually like this developer's work. I really enjoyed Titan Attacks! and Ultratron, the latter of which I've played for a few dozen hours in total. Because of this, I'd be a little surprised if Puppy Games' recent drop in sales were truly the result of returns by legitimately unhappy customers. Then again, I realize that this developer's games are not everyone's cup of tea.

In any case, despite how I feel about their products, I'm finding it really hard to feel bad for Puppy Games no matter how low their sales go. Long before the new Steam refund policy was announced — in August of last year, to be exact — Puppy Games posted a truly idiotic and somewhat self-contradictory anti-consumer rant on their blog, followed by an only slightly believable and still obnoxious "just kidding, it was all just a ruse for attention" post two weeks later. Regardless of how serious they were when they called their customers worthless, and regardless of what hidden intentions prompted them to write such intentionally inflammatory garbage, the whole ordeal pretty much cancels out any sympathy I might feel for them now.

To make matters worse, in regards to refunds, they tweeted this yesterday:


Personally, I like their games, as I mentioned already. However, this doesn't mean I agree with the way they've rudely dismissed the very sensible notion that perhaps developers who don't want to see their games returned should try harder to make games which people want to keep. At least they were being more sensible earlier today:


So, regarding implementation: Even if the refund policy recently introduced on Steam could use some fine-tuning, any revenue lost due to legitimate refunds is not something for which anyone should apologize. Happy customers typically don't request refunds at all, and unhappy customers deserve to get their money back, so refunds are justified almost always. The system can be abused, but I doubt this is the case for Puppy Games. It almost certainly isn't a case of players returning the games after finishing them, because (with the possible exception of Titan Attacks!) the games have more content than one is likely to see in only two hours. Maybe people are buying games to try them, and maybe Steam will eventually come out and say that this counts as abuse of the refund policy, but I still think it's fair when no playable demo of a game is made available.

I doubt I'll be updating this post again unless Steam's policy changes, so to close it out, I'll post some more tweets. First, here's some evidence that the refund policy isn't so bad for every independent developer:




Finally, some wise words from the HuniePop Twitter account:

Thursday, May 7, 2015

The Critical Hit Paradox

Occasionally, while browsing 4chan's /v/ or a similar board, I'll see a thread beginning with the following game-themed math problem:
"You hit an enemy twice. At least one of the hits is a crit. Assuming a 50% crit chance, what is the probability both hits are crits?"
A crit, of course, is a "critical hit" and so a 50% crit chance is rather high, but that's not important. This is basically a variant of the second question of The Two Children Problem, also known as the Boy or Girl paradox:
"Mr. Smith has two children. At least one of them is a boy. What is the probability that both children are boys?"
We could also ask the same question in terms of coin flips:
"Two coins are flipped. At least one comes up heads. What is the probability that both coins come up heads?"
This last version, in my opinion, is far less contrived than one involving critical hits or child gender. Any variation of the question, however, is bound to lead to extensive debate despite its seemingly trivial nature. The question as written is ambiguous, hence the controversy surrounding the original formulation of the Boy or Girl paradox, and hence the nauseating debate that ensues whenever the game-themed version of the problem is posed to the denizens of /v/. The person starting the thread always knows this will happen, too. Much like the moving portal paradox, this problem serves little purpose other than to cause trouble and to make people angry.

But I'm more intrigued than angry. Why exactly does such a seemingly simple question cause so much confusion? Why are different people so absolutely certain of so many completely different answers? A math problem like this should have one unambiguous and provable solution, but I count three common answers on which people seem willing to bet their lives: 1/4, 1/3, and 1/2.

In an attempt to lessen the confusion, I will attempt to explain the justifications for each of these answers below. First, however, I'll summarize what we know to be incontrovertibly true about the given scenario. And, because this is a video game blog, I will be working with the "critical hit" variation of the problem, even though I think coin flips are easier to explain.

The Facts (and One Assumption)


The problem, as written, specifies a 50% critical hit chance. In other words, each attack has a 1/2 probability of producing a critical hit (or "Crit"), and a 1/2 probability of producing a non-critical hit (which I will call simply "Hit"). We are given no other combat-related probabilities, so we will have to assume that "Crit" and "Hit" are the only possible results of an attack (i.e., we cannot "miss" or anything else). This seems reasonable, as the problem is very obviously meant to be a variant of the Boy or Girl paradox, and the original question which is the subject of that paradox does not allow any genders other than boy or girl.

In summary, the possible outcomes of a single attack (with associated probabilities) are
Crit - 1/2
Hit - 1/2
Therefore, if we were simply to attack twice, we would expect the possible outcomes (with associated probabilities) to be
Crit Crit - 1/4
Crit Hit - 1/4
Hit Crit - 1/4
Hit Hit - 1/4
where we have listed Crit Hit and Hit Crit separately to preserve information about the order of the attacks (in case we need it) and, perhaps more importantly, to demonstrate more clearly that getting one Crit is twice as likely as getting two Crits. Alternatively, if we really don't care about the order in which the attacks took place, we could write the very same result as
Two Crits - 1/4
One Crit - 1/2
No Crits - 1/4
but the probability of getting two Crits remains the same, and getting one Crit is still twice as probable.

No matter how we write it, one should note that the set of outcomes described above is based solely on the stated 50% critical hit chance for every attack. Let's not forget that we also have some additional information about a particular pair of hits. According to the problem, we hit an enemy twice and at least one of those hits is a critical hit. However, we are not being told which hit is critical.

If we were told that, say, the first hit is critical, the probability of two critical hits would be exceedingly easy to find: It would simply be the probability of the second hit being critical, so 1/2 would be the answer. Equivalently, in terms of our four equally probable outcomes (see above), we can see that two of them would be ruled out, leaving only two equally probable outcomes remaining:
Crit Crit - 1/2
Crit Hit - 1/2
Hit Crit
Hit Hit
Unfortunately, this is not how the problem is phrased. We are only told that at least one hit is critical — it could be one or the other, not necessarily the first — and because of this, depending on how you understand the question, you might get an answer which is very different from 1/2.

Guaranteed Critical Hit: The "1/4" Interpretation


One fairly common interpretation of the problem (with which, for the record, I strongly disagree) is that "at least one Crit" is some kind of gameplay mechanic which is enforced during combat. In other words, in this interpretation, it is predetermined that we are guaranteed one Crit when attacking the enemy twice. Take care to note, by the way, that this is not simply a misunderstanding of what "50% Crit chance" means. Rather, it's like this: The first attack has a 50% chance to produce a Crit. If it does, the second attack then has a 50% chance to produce a Crit. However, if the first attack instead produced a regular Hit, the second attack must then produce a Crit in order to fulfill the requirement.

In other words, Hit Crit is assumed to be the only possible outcome after an initial Hit, and so it has the same probability as that initial Hit. Meanwhile, Crit Crit and Crit Hit are both possible outcomes following an initial Crit, and they share equally the probability of that initial Crit. The probabilities are, therefore,
Crit Crit - 1/4
Crit Hit - 1/4
Hit Crit - 1/2
so the probability of two Crits — and thus our answer to the question — is 1/4.

If you have Python installed, you can easily verify this result for the "guaranteed Crit" scenario using the computer simulation below. The variables first and second represent the first and second attacks, respectively; the Boolean values True and False represent Crit and Hit, respectively; the variable double keeps track of how many times we get two Crits; and the variable trial is a counter for the while loop, which iterates 100000 times. With all this in mind, the algorithm should be self-explanatory.

# Guaranteed Critical Hit (100000 trials)
import random
double = 0
trial = 0
while trial < 100000:
    first = random.choice([True,False])      # first = random
    if first:                                # if first = crit:
        second = random.choice([True,False]) #     second = random
    else:                                    # if first = no crit:
        second = True                        #     second = crit
    if first and second:                     # if two crits:
        double += 1                          #     count double
    trial += 1                               # count trial
print("Chance of two crits: "
      + str(100 * double / trial) + "%")


This simulation will indeed return a result of approximately 25%.

However, the fact that I got a computer to spit out this number does not mean it's the correct answer to the question. The algorithm used in this simulation and the logic used in the preceding discussion are based on an interpretation of the problem which, in my view, is severely flawed. There's no evidence that the statement "at least one of the hits is a crit" is any kind of gameplay rule to be enforced during combat. There's no evidence that it was predetermined before the attacks took place. All we know is that the statement turns out to be true for a particular instance of two attacks.

Furthermore, the notion of a guaranteed Crit makes no sense when we've already been told to assume that the Crit chance is 50%. This interpretation of the problem forces us to say that the Crit chance is sometimes 50% and sometimes 100%. Worse yet, while a strict reading of "50% Crit chance" would normally lead us to assume that the result of each attack (like a coin flip) is independent from the result of any other, in this solution we are forced to admit that the result of the second attack depends on the result of the first attack.

Fortunately, the next two interpretations avoid all of these problems by dropping the dubious assumption that a "guaranteed Crit" exists in gameplay.

Partial Information Provided: The "1/3" Interpretation


Another common interpretation of the problem is as follows: The two attacks take place with no restrictions other than a 50% Crit chance for each, calculated independently. The fact that we have "at least one" Crit is simply information which then happens to be true for this pair of attacks in particular.

As stated previously, when attacking twice, we should expect the possible outcomes to be
Crit Crit
Crit Hit
Hit Crit
Hit Hit
all with equal probability. Now imagine that, upon attacking twice, we don't know the actual result of each individual attack. This information has been hidden from us. All we know, after the fact, is that we happened to get at least one Crit in the process. Perhaps the game simply tells us so, or perhaps we were able to figure it out because our total damage for both attacks is known to be above some threshold. In either case, of all the possible outcomes, this only rules out Hit Hit.

In other words, of the four equally probable things that could have possibly happened, we know merely that one of them did not happen. The remaining three possible outcomes still have equal probability, and so those probabilities are
Crit Crit - 1/3
Crit Hit - 1/3
Hit Crit - 1/3
Hit Hit
Our answer to the question, therefore, is that we have a 1/3 probability of getting two Crits. It really is that simple.

As with the previous interpretation, we can use a computer simulation coded in Python to verify the result for this scenario. The variables first and second again represent the first and second attacks, respectively; the Boolean values True and False again represent Crit and Hit, respectively; and the variable double again keeps track of how many times we get two Crits. Note, however, that the variable trial does not simply count how many times we run through the while loop. It actually counts the number of runs in which we get at least one Crit. (These are the trials which are considered valid for the experiment, and the while loop runs until we have 100000 of these valid trials.) Therefore, the final result is the proportion of two-Crit trials to at-least-one-Crit trials, expressed as a percentage. In other words, the result is the percentage of at-least-one-Crit trials in which we get two Crits, and that's exactly what we want to find.

# Partial Information Provided (100000 trials)
import random
double = 0
trial = 0
while trial < 100000:
    first = random.choice([True,False])  # first = random
    second = random.choice([True,False]) # second = random
    if first or second:                  # if at least one crit:
        trial += 1                       #     count valid trial
        if first and second:             #     if two crits:
            double += 1                  #         count double
print("Chance of two crits: "
      + str(100 * double / trial) + "%")


As expected, this will give a result of approximately 33%.

Partial Result Observed: The "1/2" Interpretation


Yet another common interpretation begins much like the previous one: The two attacks take place with no restrictions other than a 50% Crit chance for each, calculated independently. Therefore, in general, we should expect four possible outcomes, each with equal probability:
Crit Crit
Crit Hit
Hit Crit
Hit Hit
This time, however, information about the result of each individual attack is not completely hidden from us. We need only check the result of an attack, and when we do this for one of the attacks, we see that it happened to be a Crit. In other words, we are not merely being told that we got at least one Crit in the process of attacking twice. We are actually discovering this fact by sampling the data, and seeing that one particular attack — either first or second — did indeed produce a Crit. Having ascertained this, we've then ruled out two of our four possible outcomes. We are left with either
Crit Crit - 1/2
Crit Hit - 1/2
Hit Crit
Hit Hit
or
Crit Crit - 1/2
Crit Hit
Hit Crit - 1/2
Hit Hit
depending on which attack we checked, and it doesn't really matter which. Once it has been established that a particular attack resulted in a Crit, the probability of getting two Crits depends entirely on the Crit chance of the other attack. The answer, therefore, should be 1/2.

Once again, we can use Python to write a computer simulation verifying this result. As in the other simulations, the variables first and second represent the first and second attacks, respectively. Each of these two variables will be assigned a Boolean value: True or False, representing Crit or Hit, respectively. The variable double keeps track of how many times we get two Crits. Finally, the variable trial is a counter for the while loop, which iterates 100000 times. For each trial, the program picks the first or second attack at random (because it should not matter which attack we sample). That attack is then set to Crit (to reflect our finding that the sampled attack is a Crit), while the other attack is randomly set to Crit or Hit (to reflect the fact that its result is unknown).

# Partial Result Observed (100000 trials)
import random
double = 0
trial = 0
while trial < 100000:
    gotCrit = random.randint(1,2)            # pick 1 or 2
    if gotCrit == 1:                         # if picked 1:
        first = True                         #     first = crit
        second = random.choice([True,False]) #     second = random
    elif gotCrit == 2:                       # if picked 2:
        second = True                        #     second = crit
        first = random.choice([True,False])  #     first = random
    if first and second:                     # if two crits:
        double += 1                          #     count double
    trial += 1                               # count trial
print("Chance of two crits: "
      + str(100 * double / trial) + "%")


The result given by the simulation will be approximately 50%, as expected.

Comparison of Solutions


Now this is a conundrum. We have three different answers — 1/4, 1/3, and 1/2 — and it's not just because I'm bad at math. The discrepancy doesn't result from any simple arithmetic blunders; in fact, the Python simulations prove that these numbers aren't just coming out of nowhere. Each of these answers follows directly from a different interpretation of the problem, and all of these interpretations seem to make some sense.

The "guaranteed Crit" interpretation, however, seems to makes the least sense. As explained before, the idea that a guaranteed Crit is predetermined (and that this requirement should be enforced during combat) is an additional assumption not stated in the problem. It's also inconsistent with the stated assumption of an independent 50% Crit chance for each swing. This alone, in my opinion, is enough to lay this dubious interpretation to rest and say definitively that 1/4 is not the correct answer. Besides, the problem discussed here is clearly intended to be a rewording of the second half of The Two Children Problem, for which 1/4 was never a candidate answer.

That original problem is actually a set of two questions. As they are stated on Wikipedia:
  • Mr. Jones has two children. The older child is a girl. What is the probability that both children are girls?
  • Mr. Smith has two children. At least one of them is a boy. What is the probability that both children are boys?
The answer to the first question is very obviously 1/2, because we know the older child is a girl. The probability Mr. Jones of having two girls therefore rests entirely on the probability of the younger child being a girl:
Boy Boy
Boy Girl
Girl Boy - 1/2
Girl Girl - 1/2
The answer to the second question, though it turned out to be controversial, was originally supposed to be 1/3, because we only know that at least one child is a boy. The scenario in which Mr. Smith has two boys is one of three equally probable outcomes, because all we can say is that not both of the children are girls:
Boy Boy - 1/3
Boy Girl - 1/3
Girl Boy - 1/3
Girl Girl
The competing answer to the second question is 1/2 yet again. Why two answers? It depends on how we find out that "at least one" child is a boy. The answer is 1/3 if Mr. Smith simply tells us that he has at least one boy (or, equivalently, not two girls). However, the answer is instead 1/2 if we have seen one of the children and observed that he is a boy, because then we can say that the probability of having two boys depends entirely on the gender of the other child.

If you've been paying attention, you know this is exactly what's going wrong with the critical hit problem (which, as we can see, is almost identical to the Mr. Smith question). We're getting two very different answers — 1/3 and 1/2 — depending on how we find out that we got at least one critical hit. Our intuition tells us this shouldn't matter at all, so we're tempted to say that our preferred answer (whatever it may be) is true regardless of how the information is discovered. However, we've already seen that this is not the case. Each of the two answers is totally correct if you read the problem a certain way.

Let's take another look at the "partial information provided" simulation:

# Partial Information Provided (100000 trials)
import random
double = 0
trial = 0
while trial < 100000:
    first = random.choice([True,False])  # first = random
    second = random.choice([True,False]) # second = random
    if first or second:                  # if at least one crit:
        trial += 1                       #     count valid trial
        if first and second:             #     if two crits:
            double += 1                  #         count double
print("Chance of two crits: "
      + str(100 * double / trial) + "%")


The assumption in this interpretation of the problem is that, after a particular instance of two attacks, the game has simply told us we got at least one Crit. In the simulation of this scenario, we are essentially counting double-Crit instances in a pool of 100000 attack pairs, but in building that pool, we're only considering attack pairs for which there was at least one Crit. The result of this simulation proves without a doubt that, of all attack pairs producing at least one Crit, 1/3 of those attack pairs will produce two Crits.

Now let's take another look at the "partial result observed" simulation:

# Partial Result Observed (100000 trials)
import random
double = 0
trial = 0
while trial < 100000:
    gotCrit = random.randint(1,2)            # pick 1 or 2
    if gotCrit == 1:                         # if picked 1:
        first = True                         #     first = crit
        second = random.choice([True,False]) #     second = random
    elif gotCrit == 2:                       # if picked 2:
        second = True                        #     second = crit
        first = random.choice([True,False])  #     first = random
    if first and second:                     # if two crits:
        double += 1                          #     count double
    trial += 1                               # count trial
print("Chance of two crits: "
      + str(100 * double / trial) + "%")


The assumption in this interpretation of the problem is that, after a particular instance of two attacks, we checked the result of one attack and saw that it was a Crit (and this is how we know that we got at least one Crit). In the simulation, we are again counting double-Crit instances in a pool of 100000 attack pairs, but this time the pool consists of attack pairs for which a particular attack — either first or second, at random — was determined to produce a Crit. The result of this simulation proves without a doubt that, of all attack pairs in which a chosen attack is known to produce a Crit, 1/2 of those attack pairs will produce two Crits.

It seems 1/3 and 1/2 are both correct answers. They're just answers to two slightly different questions which sound very much the same.

Bayes' Theorem


For more fun (and just as many answers), we can attempt to solve the problem using Bayes' theorem, which states
P(A|B) = P(B|A) * P(A) / P(B)
where
P(A|B) is the probability of event A, given that event B occurs
P(B|A) is the probability of event B, given that event A occurs
P(A) is the probability of event A
P(B) is the probability of event B
Once again, if we're attacking twice with a 50% Crit chance, we must consider four equally probable outcomes:
Crit Crit - 1/4
Crit Hit - 1/4
Hit Crit - 1/4
Hit Hit - 1/4
So let's say A is the event that we get two Crits. The probability of this occurring alone is
P(A) = 1/4
Now let's just say B is the event that we get at least one Crit (or, equivalently, the event that we do not get zero Crits). The probability of this occurring alone is
P(B) = 3/4
Meanwhile, the probability of getting at least one Crit, given that we get two Crits, is obviously
P(B|A) = 1
Now Bayes' theorem gives the result: The probability that we get two Crits, given that we get at least one Crit, is
P(A|B) = (1) * (1/4) / (3/4) = 1/3
On the other hand, we could instead say B is the event that a chosen attack is observed to be a Crit. The probability of this occurring alone is
P(B) = 1/2
Meanwhile, the probability that one attack is observed to be a Crit, given that we get two Crits, is obviously
P(B|A) = 1
Now Bayes' theorem gives a different result: The probability that we get two Crits, given that a particular attack is observed to be a Crit, is
P(A|B) = (1) * (1/4) / (1/2) = 1/2
Even when we turn to equations, a subtle difference can change the answer.

Conclusion


So which number — 1/3 or 1/2 — is the correct answer to our problem? I think I've proved quite enough times that 1/3 and 1/2 are each absolutely correct given the right assumption about how the stated information was obtained. However, considering the critical hit problem's roots in the Boy or Girl paradox, I think I'm going to have to choose 1/3 as the better answer. Despite the ambiguous wording, the whole point of Martin Gardner's original 1959 version of The Two Children Problem was that the two questions should have two different answers: 1/2 for the first, and 1/3 (not 1/2 again) for the second. The critical hit problem discussed here is based on the second question.

Even without author intent as backup, the decision to choose 1/3 over 1/2 is not at all indefensible. Getting an answer of 1/2 requires us to make an additional (albeit minor) assumption: that a particular attack results in a Crit. The problem, as written, only asks us to consider that we get at least one Crit. If we simply accept this stated fact, without taking it upon ourselves to imagine how that information has been revealed, we get an answer of 1/3 as explained before.

Friday, April 10, 2015

The Benefits of Cowardice

Recently, I've been playing a lot of the Gauntlet-style PC game Hammerwatch. Like The Binding of Isaac, my other recent indie game obsession, Hammerwatch came into my game collection by way of a dirt-cheap bundle whose other games I haven't touched. My digital game collection is filled with perhaps too many of those bundle B-sides — games which I only own because buying an entire set of games happened to be the cheapest way to get a single game which I actually wanted (most often thanks to Humble Bundle, Bundle Stars, and similar sites). I tell myself I'll get around to enjoying these incidental purchases eventually, but life and video games don't often leave time for each other, so it rarely happens. Sometimes takes me quite a while even to try the games I bought on purpose. For instance, I didn't actually get around to playing Hammerwatch for several weeks after the bundle went on sale.

And now, according to Steam, I've spent over 50 hours playing it. There's the first problem with Steam: It permanently records my playtime, without any option to reset the count, and displays the information publicly unless my entire profile is made private. The only way to avoid the shame of my friends knowing exactly how much of my life has been wasted is to play a game in offline mode (or run the game outside of Steam entirely if possible). The other problem with Steam is that it taunts me with achievements. Oh, sure, I can ignore achievements in a bad game. I won't play garbage just to increase the number of unlocked achievements shown on my profile. But any good game with achievements is just begging for 100% completion, and as an occasionally obsessive completionist, I often can't resist. Any set of challenges or unlockables will do the trick, in fact, but achievements — being (like the playtime counter) public and permanent — are particularly good at keeping me playing a difficult game past the point where I might otherwise have given up.

It was exactly for this reason that I found myself playing Hammerwatch's unreasonably punishing survival level, completion of which is related to two achievements (one for medium difficulty and one for hard). After the first few attempts, I began to suspect it was virtually impossible to beat, at least on my own. Hammerwatch is a multiplayer game but, having no friends currently playing the game and having no desire to play with strangers, I had been flying solo up to this point. My brother owns Hammerwatch, so I could have enlisted his help, but he hadn't played in a while and had never accumulated as much playtime as I had. He would have been rusty, at best, and might have been little more than dead weight in a game of survival with shared lives. So I continued playing survival mode on my own, determined not to let two little achievements stand in the way of total victory.

The survival level in Hammerwatch works like this: Only one extra life is given to start. Waves of increasingly numerous and increasingly powerful enemies spawn to attack the player, while the eventual boss (the Crystal Lich) sits in the center of the map, invincible but able to shoot any player who comes too close. Vendors, reached by way of a portal in a hidden room, sell upgrades and extra lives, which can only be purchased with currency obtained by inflicting damage on a few large crystals placed around the map. Meanwhile, stalactites periodically fall to the floor in random places, doing serious damage to everything in a huge area; these can kill a player instantaneously. After about 45 minutes, the regular bad guys stop spawning and the Crystal Lich comes out to fight.

My first character of choice in the game's main campaign had been the paladin (equipped with a sword which deals damage in a wide arc, a shield which blocks most projectiles coming from ahead, and some other incredibly useful abilities). However, I had heard the ranger (equipped with a long-range bow and not much else of import) was the most viable choice for beating the Crystal Lich (whose homing projectiles travel almost as far as the ranger's arrows). Unfortunately, the ranger isn't as well suited to the pre-boss fight against huge waves of enemies. The paladin would have been better for that. I could only pick one, though, and I didn't want to play 45 minutes to get to the boss only then to find myself in a virtually unwinnable fight, so I was committed to using the boss-killing ranger throughout my solo attempt.

I died. A lot. I died dozens of times without ever getting a chance to fight the Crystal Lich. After all, the ranger (who deals damage at long range but in a narrow line as opposed to the paladin's wide arc) doesn't do well when surrounded, and getting surrounded in the survival level is all but inevitable. The one obvious benefit was the ability to farm crystals somewhat effectively without stopping. The ranger can shoot a crystal while approaching and then shoot some more while departing. Even so, I could never afford enough upgrades to stay on the winning side of the arms race for very long. Eventually, I'd always start dying faster than I could farm enough crystals to replace the lives I was losing.

Then I noticed that the hidden room with the portal to the vendors, although it's a cramped dead end, is actually very safe: Few enemies spawn in range to see the player, and stalactites don't fall there (except in the case of one scripted stalactite drop which destroys the portal at the start of the boss fight). Perhaps best of all, the nova-firing trap in an adjacent room is close enough that it will fire when the player stands in the hidden room, and this periodically damages a nearby crystal for free money (as does the occasional lucky stalactite drop). This free money isn't as much as what a player can get by actively mining the other crystals, so I had no intention of hiding in the hidden room throughout the entire pre-boss battle. Still, it was the best solution for the second half of the fight, during which any attempt at mining was likely to cost me more lives than I could buy with the money I had gained.

And by retreating to the hidden room when things got too hard, taking my free money like a welfare check while waiting for the boss to appear, I finally loved long enough to fight him. At that point, it was just a matter of fighting him from a distance while finishing off any nearby enemies left over from the pre-boss phase. I won.

Thus I was left with a somewhat viable solo strategy for the survival level in Hammerwatch, using the ranger:
  1. Don't destroy the nova-firing trap in the east room.
  2. Farm the crystals in the north (behind the green spike trap), west (behind the red spike trap), and center (near the Crystal Lich). Each should have enough time to recharge while you're farming the other two.
    • Don't bother with the crystal in the east (behind the blue spike trap); the active nova-firing trap makes it difficult to escape the room safely.
    • Eventually a crystal in the south will be made available, but that little room with two small openings is a death trap. Don't go there.
  3. Buy upgrades for speed, bow damage, and bow penetration. Buy an extra life when needed, but keep in mind Step 4 below.
  4. When things get too difficult (and you're dying more often than you can mine enough cash for the next extra life), go to the hidden room and stand just south of the portal, ready to shoot anything that comes after you. You are not totally safe here, so don't fall asleep.
  5. As you get free money from the crystal in the east (which should be taking damage from the nova-firing trap), keep on buying upgrades and/or stock up on extra lives, at your own discretion.
  6. When a stalactite starts to fall above the portal, get out of the hidden room. Avoid the boss until you've cleared the nearby remaining enemies.
  7. Fight the boss from a distance, coming a bit closer to shoot him and backing up to a very safe distance when he fires back. It will take a while, but if you can avoid the stalactites and any leftover enemies on the map, you'll win.
This cheesy strategy allowed me to beat the survival level on medium difficulty. Unfortunately, it wasn't so reliable for hard difficulty. After fighting and farming as much as possible without repeatedly dying, I was able to hide in the hidden room until the boss emerged, but the necessary task of clearing out remaining enemies during the boss fight became much more difficult. My damage output just wasn't sufficient to avoid being overrun once a group of enemies caught my scent, especially since the area of effect of the ranger's attack is constrained to a thin line.

Ultimately, I ended up playing with strangers to beat survival on hard mode, but even finding a suitable game wasn't easy. At any given time, I only saw one hard survival game (or none at all), and the first few games I joined were full of novices who didn't really know what they were doing. Even when I managed to join a game with more experienced players, lack of easy communication made things very difficult. By some miracle, however, I was eventually able to join a game with a couple of players (a warlock and a ranger) who were unbelievably good. Even when we were joined by a fourth player (a paladin) with no survival level experience, we weren't dragged down. I ended up getting killed before the boss was dead, but the other ranger lured the boss into a narrow hallway in which his attacks were blocked and finished him off.

So I got lucky. My advice for Hammerwatch's survival mode without friends? Try my solo strategy. If that doesn't work, I'm all out of suggestions, because you can't really count on finding a game full of expert players who are able to coordinate a victory with complete strangers. In other words: Good luck!

But, whatever. I got mine.