On Google’s AlphaGo

I thought I’d get away from critiques and reviews and serious stuff like that for a week and talk about a cool (or scary) development in AI research. I won’t talk about the details, so don’t get scared off yet. This will be more of a high level history of what happened. Many of my readers are probably unaware this even exists.

Let’s start with the basics. Go is arguably the oldest game in existence. And despite appearances, it’s one of the simplest. Each player takes a turn placing a stone on the intersections of a 19×19 board. If you surround a stone or group of stones of your opponent, you capture them (remove them from the board). If you completely surround other intersections, that counts as your “territory.”

The game ends when both sides pass (no more moves can be made to capture or surround territory). The side that has more territory + captures wins. There’s no memorization of how pieces move. There’s no rules to learn (except ko, which basically says you can’t do an infinite loop causing the game to never end). It’s really that simple.

And despite the simplicity, humans have continued to get better and produce more and more advanced theory about the game for over 2,500 years.

Let’s compare Go to Chess for a moment, because most people in the West think of Chess as the gold standard of strategy games. One could study chess for a whole lifetime and still pale in comparison to the top Grand Masters. When Deep Blue beat Kasparov in 1997, it felt like a blow to humanity.

If you’re at all in touch with the Chess world, you will have succumb to the computer overlords by now. We can measure the time since Deep Blue’s victory in decades. The AI have improved so much since then that it is commonly accepted across the whole community that a human will never be able to win against a machine at Chess ever again.

A few years ago, we could at least have said, “But wait, there’s still Go.” To someone who doesn’t have much experience with Go, it might be surprising to learn that computers weren’t even close to winning against a human a few years ago.

Here’s the rough idea why. Chess can be won by pure computation of future moves. There is no doubt that humans use pattern recognition and positional judgment and basic principles when playing, but none of that stands a chance against a machine that just reads out every single combination of the next 20 moves and then picks the best one.

Go, on the other hand, has pattern recognition as a core element of the strategy. One might try to argue that this is only because the calculations are so large, no human could ever do them. Once we have powerful enough computers, a computer could win by pure forward calculation.

As far as I understand it, this is not true. And it was the major problem in making an AI strong enough to win. Even at a theoretical level, having the computer look ahead a dozen moves would generate more combinations than the number of atoms in the known universe. A dozen moves in Chess is half the game. A dozen moves in Go tells you nothing; it wouldn’t even cover a short opening sequence.

Go definitely has local sections of the game where pure “reading ahead” wins you the situation, but there is still the global concept of surrounding the most territory to consider. It’s somewhat hard to describe in words to someone unfamiliar with the game what exactly I mean here.

san-ren-sei-opening

Notice how on the right the black stones sort of surround that area. That could quickly turn into territory by fully surrounding it. So how do you get an AI to understand this loose, vague surrounding of an area? One could even imagine much, much looser and vaguer surrounding as well. Humans can instantly see it, but machines cannot and no amount of a calculating further sequences of moves will help.

For years, every winter break from college, I’d go home and watch famous and not-so-famous people easily win matches against the top AI. Even as late as 2014, it wasn’t clear to me that I’d ever see a computer beat a human. The problem was that intractable.

Along came Google. They used a machine learning technique called “Deep Learning” to teach an AI to develop these intuitions. The result was the AlphaGo AI. In March 2016, AlphaGo beat Lee Sedol, arguably the top Go player in the world. It was a five game sequence, and AlphaGo won 4-1. This gave humanity some hope that the top players could still manage a match here and there (unlike in Chess).

But then the AI was put on an online Go server secretly under the name “Master.” It has since played pretty much every single top pro in the world. It has won every single game with a record around 60-0. It is now believed that humans will never win against it, just like in Chess.

More theory has been developed about Go than any other game. We’ve had 2,500 years of study. We thought we had figured out sound basic principles and opening theory. AlphaGo has shaken this up. It will often play moves that look bad to a trained eye, but we’re coming to see that many of the basics we once thought of as optimal are not.

It’s sort of disturbing to realize how quickly the machine learned the history of human development and then went on to innovate it’s own superior strategies. It will be interesting to see if humans can adapt to these new strategies the AI has invented.

Prismata Review

A few month’s ago I reviewed a game by David Sirlin called Codex. It is an attempt to convert a real-time strategy game, like StarCraft, into a card game. And it actually does a really good job (see the post for details).

I’ll try to not talk about StarCraft very long, because the words will be indecipherable to anyone who hasn’t played it (which is probably 99% of people reading this). There is a really old and interesting question about the game: if you strip away everything but the strategy aspect, is it still an interesting game?

This may sound weird to people unfamiliar with the game, because, well, it’s a real-time “strategy” game.

The first ridiculous thing when starting StarCraft is how much there is to learn. There’s probably close to a 100 hotkeys you have to know. There’s the tech tree structure. There’s around 60 units, each of which you should know cost, types of attacks, damage, health, shields, and what the spell-casting abilities are. Knowing those things, you’ll need to learn what counters what and why.

And you might be thinking, but I’ll just click through stuff during a game to find the information. There’s no need to memorize it. That brings up the other crazy aspect of the game: apm (actions per minute). You are going to have to have 200-300 apm (i.e. clicking or pressing a keyboard key 5 times per second on average for an entire 15+ minute match), so you just don’t have time to look stuff up during a match even though that information is available:

 

If you’re not a StarCraft player, hopefully you’re getting a sense of why the question doesn’t have an obvious answer. You have to play for months just to internalize the hotkeys and learn enough to get to the point of forming any sort of strategy.

If you strip out the memorization; If you strip out dividing the opponent’s attention and distracting them; If you strip out the fog of war; If you strip out having to execute 5 actions per second perfectly for an entire match: is there an interesting strategy game left? In other words, is the winner just someone who clicks faster?

Codex went a long way to answering that question in the affirmative. Sirlin brilliantly left in an aspect of the fog of war and tech trees. But the fact that it is a card game messes with the answer a little. There’s still some luck and some blind countering and some memorization to know what possible answers your opponent will have.

Okay, so this post is supposed to be about Prismata. To me, Prismata gives us a near perfect game for answering the question. There is absolutely no hidden information. All the units and their costs and their abilities are listed on the side at the start of the game. A beginner can play matches with slow enough time controls to carefully read all of this and formulate a plan before making moves.

As soon as your opponent buys a unit, it goes onto the board. So there is no random hidden information of shuffling it into a deck like Codex. Despite it’s appearance, Prismata is NOT a card game. There is no deck or randomness in gameplay at all.

The only randomness is in what units you are allowed to choose from during setup, and I think this is absolutely brilliant. In traditional strategy games like Chess or Go or even StarCraft, there are set openings that one must memorize to play at the top level because every game starts the same. This takes the strategy out of the opening.

In Prismata, every game is different. You have to look at the board you’ve been given and start planning a strategy on Turn 1. It’s a really exciting and fresh idea for a strategy game. It’s like if Chess or Go started with some randomized board state. You couldn’t go into a game with a plan to play a Queen’s gambit or the Kobayashi opening or something. You have to develop a plan on the fly based on the board. It’s a true battle of skill.

Before this review gets too far, I have to bring up the last comparison to Codex. Codex is a card/board game. There is no real online way to play. I played quite a bit by forum, and this might be tolerable for some people. The community is certainly very active, and you won’t have trouble finding a match. But it brought too much fatigue for me, and I stopped liking it for awhile.

Prismata is computer only (eventually through Steam and a separate client and web browser, though I’m not sure if all will continue to be supported after Steam release). If Codex had a computer version, it might compete for my attention. As it is, it’s a game that is played in person, occasionally.

Prismata has an excellent set of tutorials and basic bots and “story” to play through to get a newcomer up to speed. The game looks horrifically complicated, but it is actually very easy to learn and difficult to master. I promise if you play through the basic stuff, you’ll have a full grasp of the basics and even have a few basic strategic ideas. Do not be intimidated by a cluttered screenshot if this game sounds at all interesting to you.

Prismata is a game for people who like strategy and/or card games but who don’t like some of the ridiculous aspects of both. Many strategy games have too much hidden information to make good decisions or too much technical execution to execute a strategic plan. And card games, well, the online ones at least have way too much randomness. There’s also that super annoying way card games completely change every few months when new cards get released and you have to dump a ton of money into it to stay relevant.

Did I mention Prismata is true free to play? Since it’s not a card game, you’ll be playing the real game every game. Neither side will have an advantage merely from grinding out hundreds of hours or paying hundreds of dollars to unlock some legendary thing.

Right now, if you want to try it, you’ll need to request an alpha tester key here. It should release on Steam very soon, though, and I promise to reblog this with the link at the top to remind anyone interested.

A Critique of Brothers: A Tale of Two Sons

I recently got around to playing Brothers: A Tale of Two Sons. It’s one of those games I picked up forever ago, and it just sat around. I got it because it has to be one of the most critically acclaimed games I’ve ever seen. Giant Bomb and many, many other gaming sites gave it a 5/5 or very near such a perfect score.

I’m going to take a contrarian view, and I’m going to back up my claims with hard facts. Anyone paying attention and who knows about games should know better. I’m very confused as to how “experts” could have thought this game was good. I’m confused how “experts” could have even liked the game.

First, the game suffered from genre confusion. I’m all for experimenting with new, cross-genre ideas, but there has to be some content there at the end of the day. Was it a puzzle game? No. It fails on this front, because I never once had to “solve” something. From start to finish, the solution of how to progress was immediately obvious. Moreover, many of the puzzles repeated … several times … like, way too many times for a game this short.

Was it a platformer? No. The platforming aspects were too easy, and the stakes were too low. I think I died at one point because I accidentally let go of a trigger. That was my only death, and basically it happened because I itched my face or something. I got to repeat the task immediately with no penalty.

There is no platforming difficulty at all. In fact, many elements were downright bad on this front:

screenshot-brothers-a-tale-of-two-sons-climb-1024x592

brothers

The number of places where you must edge around a cliff or cross a narrow bridge got on my nerves. Not because I had to execute something challenging, but because the game designers clearly have no idea why other games use these elements. There is no risk of falling. The game won’t let you—I tried. So what’s the point other than to slow the player down? It’s more than an annoyance; it’s bad game design.

Basically, the game must be a story-driven walking simulator, because we’ve now determined it isn’t any of the other genres it’s crossed with. So how is the story? Oh, boy. Don’t get me started. It’s terrible.

First, it starts with a MacGuffin. This is already bad, mostly because we don’t even know what we’re setting off on our adventure to find. We only know it will magically save our father. That’s convenient. Where are we going? How do we know this cure will work? Don’t the writer’s know that MacGuffins are considered a cliche trope indicative of bad storytelling?

Then we haven’t even left our town and a kid is trying to stop us. Why? Our father is dying, and this kid doesn’t want to let us through. I get it. They needed an excuse to set up some “platforming puzzles” (that, recall, require no platforming or puzzle-solving skills). But you can’t have such a disgusting character with no motivation. I hate the term “ludonarrative dissonance,” because I’ve never consciously experienced it. But here I did. This conflict between gameplay and story already ruined the mood of the game in the first five minutes.

Another act of ludonarrative dissonance was when I got to this big castle that I couldn’t enter, but it had these perfectly placed pegs to grab on to (not quite the picture I wanted, but you get the point):

638766-brothers-a-tale-of-two-sons-windows-screenshot-brothers-tied

Really? This highly fortified castle has this convenient other way to scale it with perfectly placed pegs, just the right distance so that the rope randomly tied between the two brothers barely reaches. Is this a story game or a puzzle platformer? If it’s a platformer, we could overlook these huge narrative flaws. But it doesn’t work as a game in that genre. It’s a story game, but these scenarios wreck the suspension of disbelief for the story.

More succinctly, in the language of game design, these sections involve “environmental puzzles,” but the puzzles don’t occur naturally in the environment at all. This is bad game design.

And let’s not even go there with the deus ex machinas. Are you stuck and can’t actually progress? Yes? Oh, well, good thing a giant appears out of nowhere and just throws you across the ravine. Did you get to the top of the castle only to be at a dead end? Good thing there is a bird trapped in a cage that will fly you to the next area.

It gets worse. How is that bird still alive? It’s been trapped in a cage for who-knows-how-long, bleeding, without any food, and all the people that could feed it are dead. Are we really supposed to believe the bird is still alive?

Lastly, people claim the ending is really sad. They claim they were moved to tears. I couldn’t get past the shrieking woman singing that shrill song at the climax. It ruined the mood. Ending Spoiler:

On a more serious note, I’ve already mentioned all the reasons I never got into the story: ludonarrative dissonance, tropes/cliches, unmotivated characters, ruined suspension of disbelief, plot holes, etc. I just didn’t feel anything except relief the game was over.

On positive note, the concept could have been amazing. Part of what made the game easy was that the core concept was never executed to its fullest. You have to move one of the brothers with one hand and the other with the other hand.

The potential for some truly interesting and difficult gameplay is there. All they had to do was design parts where you have to move both at the same time in fairly precise and independent ways. Instead, they stuck to having you move both in parallel or one at a time. That was the main downfall of the game: It didn’t even deliver on its core innovative mechanic.

Overall, each element has much better games. For puzzle platforming, there are dozens of examples: Braid, Thomas Was Alone, Teslagrad, Super Meat Boy, Trine, and on and on. For story, there are dozens of examples: Gone Home, Bastion, To the Moon, and on and on. For atmosphere: Limbo, Dear Esther, Kentucky Route Zero, The Long Dark, and on and on. I see no reason why anyone should play this game under any circumstance. There’s just much better games on every front.

I know. The whole is better than the sum of its parts for some games. In this case, that is not true. In fact, many parts messed up other parts. What the critics and people who liked this game were thinking is beyond me.

PC Game Hidden Gems and Some That Aren’t

I had trouble coming up with a succinct title for this post. I wanted to go through some underrated games and some highly rated games that weren’t very good, because it’s been awhile since I’ve done any sort of game review post.

Tactical RPG’s

Underrated: Massive Chalice

Massive Chalice has a similar combat system to XCOM. It initially got some very poor reviews because of this comparison. Many called it XCOM-light or a less deep and easier version of that game. This is an unfair comparison, because most of the strategy and depth comes from the other part of the game.

Massive Chalice has you set up bloodlines from your characters. You know a bunch of traits and character flaws of the characters, and then you must marry them to produce children. There are so many factors and risk/rewards that must go into this.

Do you retire your best fighter so that in 20 years you have several of his children on the battlefield only to find out he couldn’t produce any children? Do you risk a sharpshooter with an alcohol problem staggering around the battlefield? Do you trust the numbers given to you by an overconfident person?

This game might not get you the 200+ hours that many put into XCOM, but put it on ironman hard mode and you’ll be in for a tough challenge. It has a lot of character and humor too. The initial hate it got was unwarranted.

Overrated: The Banner Saga

I know I’ll get hate for this one. This game has overwhelming positive reviews. I think they are unwarranted. This game claimed to have the big three things I’d look for in a game: great story, great art, tactical strategy.

It had one of those; the art is fantastic. I thought the story was thin. It mostly felt like a series of excuses to get to the gameplay. Travel, camp, stop at a town, sometimes drama, repeat. It is very Oregon Trail-like in this respect. I wanted something more than an excuse to be fighting, and that’s all it felt like to me.

The gameplay itself is quite poor. There is a tactical aspect, but it is largely irrelevant. Whether you collect resources or not, you’ll be fine. No matter how you level or play the characters, you’ll be fine. No matter how you position, you’ll be fine. Once I found this out, I stopped trying, and just attacked from wherever I was and won.

But the most important part where this game failed for me was how separate everything was. Story-driven games need to integrate that aspect into the gameplay for a rich and seamless experience. The story and the gameplay were completely separate, which created a disjointed play experience.

Roguelikes

If you are a longtime reader, you’ll know this is kind of my genre, so I’ll do two underrated games. For the most part, it takes a ton of time and feedback to make a great roguelike. This means most aren’t really worth sinking time into unless they are well-known. Here’s two that are well worth the time despite not being talked about as much.

Dungeonmans

This is basically a humorous version of the famous Tales of Maj’Eyal (ToME). To be fair, ToME is a more complicated game, but I think Dungeonmans improves on the ToME idea in several important ways.

First, it has a simpler skill tree system. This makes it more manageable for people who don’t want to spend 100 hours just learning what the different things do. It also has less classes/races, again, an improvement.

Dungeonmans has a randomly generated overworld. This makes repeated playthroughs more interesting than going the same places in the same order like in ToME. It implements an interesting persistence mechanic too. This makes the game beatable for more casual players (but there is an “ironmans” mode for the hardcore permadeath fans).

Longtime fans of ToME might not find what they want in this game (though I did!), but I highly recommend this game for the roguelike-curious who are scared off from giant learning curves like ToME.

Sword of the Stars: The Pit

This is one of the only truly modern roguelikes out there. It is hardcore in the most classic sense of the genre except for ASCII graphics. The game consists of pure dungeon diving. You go to the bottom of the pit to win. What makes the game so great is its inventory management.

Planning ahead and conserving weapons and understanding enemy movement is the key to success. Unlike Dungeonmnans, there is a good chance you’ll never win this on Normal mode (and there are still three difficulty levels above that!).

You have to become really good at the game to succeed. This takes patience and effort. This is what people like about roguelikes. If this sounds terrible, then this game isn’t for you. When you start, you will think the game is too hard to beat, but people who are good at this game can win on Normal more than 90% of the time. It’s not too hard—it’s you.

There is a “recipe” discovery mechanic that is pretty tedious, and this game gets a lot of negative feedback for it. I agree with that aspect of negativity, but it is a small matter that shouldn’t ruin the game.

Strategy

Overrated: Unity of Command

This is a small title, so I’m not sure it’s “overrated.” I saw it pop up numerous times while searching for good PC strategy games. The player reviews tend to be very good too. I could not get into this game at all.

The concept of the game is to advance your front in specific battles while not losing access to your supply line. I’ll admit the concept is clever in how realistic a scenario this is.

The simplification of the war strategy game genre down to its essentials makes getting started easier, but I didn’t find it deep or satisfying. It uses weird turn limits to artificially increase difficulty (more like a puzzle than a strategy game). Randomness plays too big a role as well.

Underrated: Endless Legend

I’m not sure this qualifies as an underrated, because Rock, Paper, Shotgun named it 2014 Game of the Year. Still, the player reviews remain mixed and often negative, so I’m going with “currently underrated.”

This is a 4X strategy game similar to the Civilization franchise. Unlike Civ, this has a fantasy setting on an alien planet. The art is stunning. The backstory for each faction is buried within the game play. This is the type of integration of story and game I was referring to above.

Each faction plays differently. You can choose to enter tactical combat if you wish or you can auto-complete the combat. The large-scale strategy is almost endlessly deep (you see what I did there?) from what to research, whether to build up cities or expand outward, making alliances, spying, attacking, defending, trade routes, trading, marketplace, completing quests, exploring, assigning heroes, and on and on. Any fan of PC strategy games that hasn’t checked this out is really missing a gem with this one.

Draw Luck in Card Games, Part 2

A few weeks ago I talked about draw luck in card games. I thought I’d go a little further today with the actual math behind some core concepts when you play a card game where you build your own deck to use. The same idea works for computing probabilities in poker, so you don’t need to get too hung up on the particulars here.

I’m going to use Magic: The Gathering (MTG) as an example. Here are the relevant idea axioms we will use:

1. Your deck will consist of 60 cards.
2. You start by drawing 7 cards.
3. Each turn you draw 1 card.
4. Each card has a “cost” to play it (called mana).
5. Optimal strategy is to play a cost 1 card on turn 1, a cost 2 card on turn 2, and so on. This is called “playing on curve.”

You don’t have to know anything about MTG now that you have these axioms (in fact, writing them this way allows you to convert everything to Hearthstone, or your card game of choice). Of course, every single one of those axioms can be affected by play, so this is a vast oversimplification. But it gives a good reference point if you’ve never seen anything like this type of analysis before. Let’s build up the theory little by little.

First, what is the probability of being able to play a 1-cost card on turn 1 if you put, say, 10 of these in your deck? We’ll simplify axiom 2 to get started. Suppose you only draw one card to start. Basically, by definition of probability, you have a 10/60, or 16.67% chance of drawing it. Now if you draw 2 cards, it already gets a little bit trickier. Exercise: Try to work it out to see why (hint: the first card could be 1-cost OR the second OR both).

Let’s reframe the question. What’s the probability of NOT being able to play a card turn 1 if you draw 2 cards? You would have to draw a non-1-cost AND another non-1-cost. The first card you pick up has a 50/60 chance of this happening. Now the deck only has 59 cards left, and 49 of those are non-1-cost. So the probability of not being able to play turn 1 is {\frac{50}{60}\cdot\frac{49}{59}}, or about a 69% chance.

To convert this back, we get that the probability of being able to play the 1-cost card on turn 1 (if start with 2 cards) is {\displaystyle 1- \frac{50\cdot 49}{60\cdot 59}}, or about a 31% chance.

Axiom 2 says that in the actual game we start by drawing 7 cards. The pattern above continues in this way, so if we put {k} 1-cost cards in our deck, the probability of being able to play one of these on turn 1 is:

{\displaystyle 1 - \frac{(60-k)\cdot (60-k-1)\cdots (60-k-7)}{60\cdot 59\cdots (60-7)} = 1 - \frac{{60-k \choose 7}}{{60 \choose 7}}}.

To calculate the probability of hitting a 2-cost card on turn 2, we just change the 7 to an 8, since we’ll be getting 8 cards by axiom 3. The {k} becomes however many 2-cost cards we have.

Here’s a nice little question: Is it possible to make a deck where we have a greater than 50% chance of playing on curve every turn for the first 6 turns? We just compute the {k} above that makes each probability greater than {0.5}. This requires putting the following amount of cards in your deck:

6 1-cost
5 2-cost
5 3-cost
4 4-cost
4 5-cost
3 6-cost

Even assuming you put 24 lands in your deck, this still gives you tons of extra cards. Let’s push this a little further. Can you make a deck that has a better than 70% chance of playing on curve every turn? Yes!

9 1-cost
8 2-cost
7 3-cost
7 4-cost
6 5-cost
6 6-cost

Warning: This mana curve would never be used by any sort of competetive deck. This is a thought experiment with tons of simplifying assumptions. The curve for your deck is going to depend on a huge number of things. Most decks will probably value playing on curve in the 2,3,4 range way more than other turns. If you have an aggressive deck, you might value the early game. If you play a control deck, you might value the later game.

Also, the longer the game goes, the less cards you probably need in the high cost range to get those probabilities up, because there will be ways to hunt through your deck to increase the chance of finding them. Even more, all of these estimates are conservative, because MTG allows you to mulligan a bad starting hand. This means many worst-case scenarios get thrown out, giving you an even better chance at playing on curve.

This brings us back to the point being made in the previous post. Sometimes what feels like “bad luck” could be poor deck construction. This is an aspect you have full control over, and if you keep feeling like you aren’t able to play a card, you might want to work these probabilities out to make a conscious choice about how likely you are to draw certain cards at certain points of the game.

Once you know the probabilities, you can make more informed strategic decisions. This is exactly how professional poker is played.

Draw Luck in Card Games

Every year, around this time, I like to do a post on some aspect of game design in honor of the 7DRL Challenge. Let’s talk about something I hate: card games (though I sometimes become obsessed with, and love, well-made ones). For a game to be competitive, luck must be minimized or controlled in some way.

My family is obsessed with Canasta. I don’t get the appeal at all. This is a game that can take 1-2 hours to play and amounts to taking a random hand of cards and sorting them into like piles.

I’ve seen people say there is “strategy” on various forums. I’ll agree in a limited sense. There is almost always just one correct play, and if you’ve played a few times, that play will be immediately obvious to you. This means that everyone playing the game will play the right moves. This isn’t usually what is meant by “strategy.” By definition, the game is completely decided by the cards you draw.

This is pure tedium. Why would anyone want to sit down, flip a coin but not look at it, then perform a sorting task over and over for an hour or more, stop, look at the result of the coin flip and then determine that whoever won the coin flip won the “game.” This analogy is almost exactly the game of Canasta. There are similar (but less obnoxious) bureaucratic jobs that people are paid to do, and those people hate their job.

Not to belabor this point, but imagine you are told to put a bunch of files into alphabetical order, and each time you finish, someone came into the room and threw the files into the air. You then had to pick them up and sort them again. Why would you take this task upon yourself as a leisure activity?

I’ve asked my family this before, and the answer is always something like: it gives us something to do together or it is bonding time or similar answers. But if that’s the case, why not sit around a table and talk rather than putting this tedious distraction into it? If the point is to have fun playing a game, why not play a game that is actually fun?

This is an extreme example, but I’d say that most card games actually fall into this pure coin flip area. We get so distracted by playing the right moves and the fact that it is called a “game” that we sometimes forget the winner of the activity is nothing more than a purely random luck of the draw.

Even games like Pitch or Euchre or other trick taking games, where the right plays take a bit more effort to come up with, are the same. It’s a difficult truth to swallow, but the depth of these games is so shallow that a few hours of playing and you’ll be making the correct moves, without much thought, every single hand. Once every player makes the right plays, it only amounts to luck.

It’s actually really difficult to design a game with a standard deck of cards that gets around this problem. I’ve heard Bridge has depth (I know nothing of the game, but I take people’s word on this considering there is a professional scene). Poker has depth.

How does Poker get around draw luck? I’d say there are two answers. The first is that we don’t consider any individual hand a “game” of Poker. Obviously, the worst Poker player in the world could be dealt a straight flush and win the hand against the best Poker player in the world. Skill in Poker comes into play over the long run. One unit of Poker should be something like a whole tournament, where enough games are played to overcome the draw luck.

Now that we aren’t referring to a single hand, the ability to fold with minimal consequences also mitigates draw luck. This means that if you get unlucky with your initial cards, you can just choose to not play that hand. There are types of Poker that straight up let you replace bad cards (we’ll get to replacing in a moment). All of these things mitigate the luck enough that it makes sense to talk about skill.

Another card game with a professional scene is Magic: The Gathering (MTG). Tournament types vary quite a bit, but one way to mitigate draw luck is again to consider a whole tournament as a unit rather than an individual game. Or you could always play best of five or something.

But one of the most interesting aspects is the deck itself. Unlike traditional playing cards, you get to make the deck you play with. This means that over the course of many games, you can only blame yourself for bad drawing. Did you only draw lands on your first turn for five matches in a row? Then maybe you have too many land cards. That’s your fault. Did you draw no land many times in a row? Also, your own fault again. Composing a deck that takes all these probabilities into account is part of the skill of the game (usually called the “curve” of the deck).

Here’s an interesting question: is there a way to mitigate draw luck without having to play a ton of games? Most people want to play something short and not have to travel for a few days to play in a tournament to test their skill.

In real life, replacing cards is obnoxious to implement, but I think it is a fascinating and underutilized rule. The replacement idea allows you to tone down draw luck even at the level of a single game. If your card game exists online only, it is easy to do, and some recent games actually utilize this like Duelyst.

Why does it work? Well, if you have a bad draw, you can just replace one or all of your cards (depending on how the rule is worded). Not only does this create strategic depth through planning ahead for which cards will be useful, it almost completely eliminates the luck of the draw.

I really want to see someone design a card game with a standard deck of cards that makes this idea work. The one downside is that the only way I can see a “replace” feature working is if you shuffle after each replacement. This is pretty annoying, but I don’t see a way around it. You can’t just stick the card you replace into the middle of the deck and pretend like that placement is random. Everyone will know that it isn’t going to be drawn in the next few turns and can play around that.

Anyway. That’s just something I’ve been thinking about since roguelikes have tons of randomness in them, and the randomness of card games have always bothered me.

 

Should Roguelikes be Winnable?

A topic that I’ve been thinking about recently has to do with balancing roguelikes. If you haven’t heard the term balance before, it basically refers to making a game fair through adjusting values: enemy health, enemy strength, items you find, your health, your strength, and so on.

For a normal RPG, you balance a game so that a skilled player can win and so nothing feels unfair. An example of something an RPG fan might find unfair is an “out of depth” enemy that instantly and unavoidably kills you (this happens in many roguelikes).

Many developers and players think this is bad game design because the player couldn’t do anything about it. Why bother getting good at a game if you will just lose to unpredictable circumstances? The game cheated you somehow, and many players quit various roguelikes before getting better for exactly this reason.

This post isn’t so much on actual balance as it is on two distinct philosophies on the winnability of a roguelike. This is a design choice that must be thought about carefully in roguelike design, and it doesn’t even come up for other types of games.

The question: Should a skilled player be able to win?

Most modern game designers would laugh at this question. Their games are designed so that you don’t even need skill to win. Winning is the default position. Your hand will be held through the process. Checkpoints are made every step of the way so you can try something again if you mess it up.

This might be surprising to people not immersed in the genre, but many classic roguelike games have a steep enough skill hurdle that probably less than 10% who ever play will get a win (maybe even as low as 1%). Sometimes it can take years of playing a game to get good enough at it to win. But the game is balanced such that a really skilled player can win almost every time.

Think about that for a second. This is quite a feat. Here’s an analogy which isn’t perfect: think about running a 5 minute mile. Almost no runner (even ones that train very, very hard) achieves this. But once they do, they can reproduce it many times. This is what makes roguelikes great. The focus is on player skill and progression not on character progression. You get a sense of real accomplishment.

After I wrote this post, I did a search for the topic and found it discussed at the Brogue forums. It seems there isn’t an easy way to even define “winnable.” I’ll give you my definition in a bit, but I want to dispel the obvious one as not being a good one.

We already have to distinguish between the game being winnable and the winnability of a given seed (industry term for a particular playthrough). This is only weird for roguelikes, because the game is different every time you play.

One might try to define a game as winnable if approximately 100% of the seeds can be won with “perfect play.” But using perfect play is problematic in a roguelike because of the randomness. Perfect play means you play in a way that perfectly maximizes your chance of winning.

It isn’t hard to think of situations in which sub-optimal play will randomly luck into a win and optimal play loses the seed (e.g. you need magic reflection, so you check Sokoban, but encounter an enemy with a wand of death that kills you, but the unskilled player doesn’t check Sokoban and goes on to win).

This is kind of funny, because now we have a problem with defining winnable even for a seed. Should it mean: someone somewhere won the seed? This, too, seems problematic. I’ll try to explain why from the commentary at the Brogue forum discussion. One person claimed that at least 80% of Brogue seeds are winnable based on the fact that people got wins on around 80 of the last 100 weekend challenge competitions (not the same person).

Let’s digress to make the problem with the above analysis clear. Suppose we make a game. Flip a coin. If it is heads you win and tails you lose. Under the perfect play definition, the game is not winnable. In other words, perfect play does not guarantee a win. Under the definition that some person somewhere was able to win, it is winnable.

Here’s where things get interesting. If we think about what percentage of seeds can be won, we better find out that the answer is 50%, because this is our expected percentage of games a player that plays perfectly would win. But in the above Brogue analysis, the commenter takes a pool of players and asks if any of them has won. This should greatly inflate the win percentage, because it is like taking 5 coins and flipping them all at the same time and seeing if any were wins.

To get around this subtlety, I’ll call a game winnable if a single skilled player can get a win streak of say 10 or so. A good example of this is NetHack. The vast majority of people who play will never get a win ever. But Adeon has a win streak of 29, and many people have streaks of 10. This proves that it is a game that can be won basically every time (and many consider it so easy they self-impose crazy challenges and still win).

Other famous roguelikes that have this same philosophy are Tales of Maj’Eyal (on normal/adventure at least) or from the “roguelite” genre The Binding of Isaac (where people have 150+ win streaks).

At this point you’re probably thinking, what other philosophy could there be? No one could possibly want to play a game for which you work really hard for 1,000 hours learning to make all the best moves, and yet the design will still have you lose to random impossible scenarios. It wouldn’t be fun. It would be pure frustration.

But people do this all the time in other types of games. The best example I can think of is poker. It takes a huge number of hours of training to become good enough to make roughly the best plays. You can be the best in the world and still lose due to the inherent randomness. You can only see how good someone is through long-term averages.

One way to think of this philosophy is: losing is fun, winning is more fun, winning every time is too easy and boring. Traditional roguelikes are fun, because you get in seemingly impossible situations but with enough skill you can think your way out. You can have a lot of confidence that you will basically never be randomly put in an impossible situation. Losing is your own fault, and you can get better from it.

If you take this alternate philosophy, the fun comes from the fact that you don’t know if a given situation is impossible. Maybe you just weren’t good enough. Balancing so that there are impossible situations makes it so that the top of the skill curve can still feel challenged.

I think the biggest difficulty with balancing in this manner is that a highly skilled player may never reach a 10 streak, but they should probably still be able to win something like 6 or 7 of those 10 games. This would be a very difficult balance to achieve. It is much easier to make it winnable.

Roguelikes already have a very small market. Part of what keeps people interested is that when they lose, it is their own fault. They don’t feel cheated. A game that was upfront about containing a large number of impossible seeds would probably narrow the market even more. One way to mitigate the pain would be for the game to keep track of your monthly win percent. That way you can track your progress.

I haven’t heard of this before. I’d be curious if anyone knows of any roguelikes that fit this design philosophy. The two that come to mind are Sword of the Stars: The Pit and Brogue. Both feel like you can just not find the items necessary to get a run off the ground. But I’m not very good at either, so it could be player error. There are people with about 2500 hours of play in The Pit, so I’d be curious to see if they could get a 5 streak on Normal mode (most refuse to play that difficulty since they’ve won on much harder).

Basic Game Programming Part 3

Here’s an experiment to try purely in C++ (or the language of your choice). Print any character you want on a blank terminal screen at a specific location (say 10 characters over and on the 4th line). This is a crucial idea in game programming, because even something as simple as using the arrow keys to move something around a screen requires you to do this.

You’ll find it gets tedious quickly. Let me guess what you came up with. You have two auxiliary functions. One of them prints “\n” an appropriate number of times to move you to the correct line. The other prints a bunch of ” ” to move you over. It works.

Now suppose you want more information on the screen like health remaining or an inventory list. You can’t use that method anymore, because it depends on where the cursor ended during the last thing you drew. This, in turn, depends on information that could be changing (Health: 9 vs Health: 10 places the cursor one more space over).

Matters get even worse if you want to draw something on the right edge of the screen, because you have no idea what the player is looking at. One could use a standard terminal size, another could have maximized it to fullscreen. This changes the number of spaces on a line.

Until you actually try to do these things, or at least seriously attempt a thought-experiment doing it, you will never appreciate why adding an external library to handle this stuff is important. There are tons of these in existence, but probably the most common and universal ones are built from SDL (we will definitely not get into that today).

The simplest for C++ is probably ncurses. It stands for “new curses” and has a pretty interesting history (the name implies there was a curses). It effectively emulates a terminal, which sounds ridiculous at first (why not just use the terminal!) until you think through all the problems above. Today, we’ll make an “@” symbol move around the screen using the arrow keys.

For our purposes, the two most useful functions in the library will be clear() and mvaddch(). As we saw last time, clear() was annoying because it was OS and terminal dependent. Since ncurses emulates a terminal, there is one function that clears the screen independent of OS. The function mvaddch takes 3 arguments, the first two are ints and give the y-coordinate and x-coordinate where you want to place a character, and the third argument is a character that gets placed in that location.

Even though I want to think in terms of x and y coordinates, mvaddch actually takes the row then the column number. This means you put in y first and x second and the y-coordinate counts down from the top of the screen which can be confusing to new users of ncurses.

At this point, we understand the structure of the game loop, so you should basically be able to fill in the rest of the program. There are quite a few subtleties, though, so I’ll go slowly through it.

The only variables I need this time are the x-coordinate and y-coordinate, so I’ll make these global. I started it at (5,5) randomly. We get input using getch(). This returns an integer, but we don’t need to worry about what that integer is. Since we are using the arrow keys we can use KEY_UP, KEY_DOWN, etc which are integers corresponding to the correct arrow directions. Also, using integers is nice rather than characters, because in C++ we can more cleanly write a bunch of “else if” statements with a “switch.”

This lets us make the whole Update() function by changing the x and y coordinates depending on which arrow direction was pressed.

void Update() {
	switch(userInput) {
		case KEY_LEFT:
			XPOS = XPOS - 1;
			break;
		case KEY_RIGHT:
			XPOS = XPOS + 1;
			break;
		case KEY_UP:
			YPOS = YPOS - 1;
			break;
		case KEY_DOWN:
			YPOS = YPOS + 1;
			break;
	}
}

As before, our draw function clears the whole screen and then draws everything. Because of how ncurses works, nothing will be drawn to the terminal until refresh() is called. This is basically so you can store a whole bunch information about what is going to be displayed, and then it can work out how to display it separately:

void Draw() {
	clear();
	mvaddch(YPOS, XPOS, PLAYER);
	refresh();
}

The only thing left is to initialize a bunch of stuff, but the content of the program is really that simple. I commented the initialization lines so you can see what they do, but for the most part, you’ll just copy and paste that whole chunk in every use of ncurses.

#include <ncurses.h>

int XPOS = 5;
int YPOS = 5;
char PLAYER = '@';
int userInput;

void Update() {
	switch(userInput) {
		case KEY_LEFT:
			XPOS = XPOS - 1;
			break;
		case KEY_RIGHT:
			XPOS = XPOS + 1;
			break;
		case KEY_UP:
			YPOS = YPOS - 1;
			break;
		case KEY_DOWN:
			YPOS = YPOS + 1;
			break;
	}
}

void Draw() {
	clear();
	mvaddch(YPOS, XPOS, PLAYER);
	refresh();
}

int main() {

	//Initialize ncurses

	initscr(); //Tells it to make a terminal screen.
  	clear();   //Clears the screen.
  	noecho();  //When user types input, it doesn't appear on the screen.
  	cbreak();  //Typed character is immediately available.
  	keypad(stdscr, TRUE);  //Standard screen.
  	curs_set(0);  //Starts the cursor at (0,0).
  	mvaddch(YPOS, XPOS, PLAYER); //Draw '@' in the initial location.
  	refresh();  //Updates the screen to display the '@'.

	while(true) {

		//Input()
		userInput = getch();

		Update();
		Draw();

		if (userInput == 'q') {
			break;
		}
	}

	endwin();  //Closes the terminal screen.

	return 0;
}

This will probably be the last post in this series. I have one more topic I could do (decoupling the draw loop from the game logic loop). For the most part, you should now be in a position to look up tutorials on using fancier stuff like Unity or Monogame.

The problem I found with those tutorials is that they focus solely on how to use their engine and not on what these underlying components of the engine are (and why they exist). Hopefully after these posts, these concepts make more sense allowing you to more easily jump in.

(For the record, these posts keep getting the C# tag even though I type C++. It autocorrects it upon hitting the publish button.)

Basic Game Programming Part 1

A lot of people think the best way to get young people into programming is through making games. I agree. Unfortunately, it is kind of hard to find the basics, so I want to do a series on it (Pygame is your best bet for a tutorial, but I’ve personally had bad experiences with it). This is definitely not meant to be some comprehensive tutorial. It is only meant to introduce some basic ideas.

There’s a lot of tools out there to make this easy (RPG Maker comes to mind). These tools allow you to make a fairly complicated and polished game without having any idea about how it is coded. Drag and drop images on a screen, and voila, a game is born. This defeats the whole point!

Other tools like game engines (Pygame, Unreal Engine, Unity, Monogame, Cocos, etc) are important to not have to deal with complicated graphics rendering or other hassles. These should be used in real life. For the purpose of this series, we will look at rudimentary simplifications of some of the things going on underneath these engines.

I will not assume you are comfortable with programming, but I also won’t explain the code much. I’ll assume you can look at the code and are able to figure out with some prompting what it does. The most important part of learning to program is learning the ability to look things up.

I’m going to use C++ even though I know most people learn Python or Java these days as their first language. But if you want to write cross-platform games, you’ll want to use C++ (Cocos) or C# (Unity and Monogame) or whatever Unreal uses. If you want a refresher, this game will only use cin, cout, variables, if/else. This should take less than 2 hours to learn from a reasonable tutorial.

If you have a little programming experience, there is a fundamental concept you’ll have to get used to called the game loop. It essentially looks like this:

while(true) {
    //Insert entire game here.
}

The game will infinitely loop through the instructions. For most simple games, this is overkill and uses a ton of unnecessary processing power. Also, without a professional game engine underneath, you don’t have a way to limit the speed at which it loops (30 times per second or 60 times per second). Don’t worry about any of this. Just know that you will eventually want this constant loop, so it is good to get used to it.

Let’s add a touch more detail now. The game loop roughly consists of three parts: Getting input from the player, Updating the game state based on that input, and Drawing to the screen whatever has changed from the update step. This is called the engine, because it keeps churning and puts the game in motion. If you use Unity or some pre-built engine, each of these parts will exist already (and will loop independently in parallel, but that is for another time).

Our game now looks like this:

while(true) {
   GetInput();
   Update();
   Draw();
}

Again, this is needlessly complicated for the game we will make, but it is worth getting used to this flow with something basic so you aren’t learning a whole new framework with something more complicated.

Now let’s describe the game. The game will display your health and the enemy’s health. The player will have 2 choices: Attack or Run. If you attack, you hit the enemy, in which case the enemy’s health decreases by some amount (we’ll make it random between 0 and 3). If you run, you leave the game (effectively a “quit” choice). The enemy always hits you.

If the enemy’s health reaches 0, the player wins. If the player’s health reaches 0, the player loses.

A part of the engine I didn’t describe is the initialization that come before entering the game loop. In this case, we might want to describe the setup and get the initial variables set up and call the Draw() function to get something on the screen.

There will be 2 variables: PlayerHealth and EnemyHealth. Let’s set them both to 10 to start. At this point I think we can write the first form of the Draw() function, which right now will just print out and label these variables and give the two options for action. Eventually, we’ll probably want to say who got hit, too.

void Draw(int playerhealth, int enemyhealth) {
  cout << "Your Health: " << playerhealth << "\n";
  cout << "Enemy Health: " << enemyhealth << "\n";
  cout << "a. Attack \n";
  cout << "b. Run \n";
}

This might look a bit confusing, but “cout” just means “print to the screen.” So each line of that is printing “Your Health: 10” (and the \n means “new line”).

Now let’s get the input. We’ll do something a little bad, but we’re just trying to get the flow down here. We’ll worry about “good coding practices” some other time. Let’s make the function Input() return the string the user inputs, so we can store it rather than modifying some global variable.

string Input() {
  string tmp;
  cin >> tmp;
  return tmp;
}

Again, “cin” just asks for the player input. The input is stored in the variable “tmp” and then gets returned.

The most complicated part of this is going to be the Update() function, but it isn’t so bad. Update() needs to say: if the player typed “a” we subtract the attack amount from EnemyHealth. If the player typed “b” we exit the loop. If anything else was typed, we don’t do anything and notify them it is not an option.

if (PlayerInput == "a") {
      int r1 = rand() % 4;
      EnemyHealth -= r1;
    }
    else if (PlayerInput == "b") {
      break;
    }
    else {
      cout << "This is not a valid option.\n";
    }

I used here a random number between 0 and 3 (inclusive) for how much damage the attack does. (Look up rand() for how it works. It is part of the standard library.) There isn’t much left, so I’ll give the whole thing now with some comments:

#include <iostream>
#include <stdlib.h>

using namespace std;

void Draw(int playerhealth, int enemyhealth) {
  cout << "Your Health: " << playerhealth << "\n";
  cout << "Enemy Health: " << enemyhealth << "\n";
  cout << "a. Attack \n";
  cout << "b. Run \n";
}

string Input() {
  string tmp;
  cin >> tmp;
  return tmp;
}

int main() {
  //Initialize the variables
  int PlayerHealth = 10;
  int EnemyHealth = 10;
  string PlayerInput;

  //Initial Information Drawn
  cout << "An enemy approaches... \n";
  Draw(PlayerHealth, EnemyHealth);

  //Game Loop
  while(true) {
    PlayerInput = Input();

    //Update Information based on input.
    if (PlayerInput == "a") {
      int r1 = rand() % 4;
      EnemyHealth -= r1;
    }
    else if (PlayerInput == "b") {
      break;
    }
    else {
      cout << "This is not a valid option.\n";
    }

    //Enemy attacks.
    int r2 = rand() % 4;
    PlayerHealth -= r2;

    //Break out of the game looop if won or lost.
    if (EnemyHealth <= 0) {
      cout << "You Win.\n";
      break;
    }
    else if (PlayerHealth <= 0) {
      cout << "You Lose.\n";
      break;
    }

    //Print out the Updated Info
    Draw(PlayerHealth, EnemyHealth);
  }

  cout << "Game Over.\n";

  return 0;
}

Here’s some features to add as homework. Now that the core is there, if you think of one thing and add it each day (15 minutes tops?), in 2 weeks you’ll have a pretty interesting and complicated text-based game. They don’t have to be these or even in this order. These are what popped into my head.

Excercise 0: Try cleaning up the current code so that Update() is its own function like Input() and Draw(). Don’t try too hard, because it is more complicated than it’s worth. You will encounter your first struggle with how to scope variables that all your functions want to know about. Also, breaking out of the while loop will become tricky.

Feature 1: Look up how to do random numbers. Make it so that you only hit the enemy 50% (or whatever you want) of the time. Make it so the enemy only hits you sometimes. This might be a 2 day feature if you are totally new to programming in C++.

Feature 2: Tell the Player that they hit the enemy and how much damage they did.

Feature 3: Make a “Title Screen” that tells you the game you are about to play.

Feature 4: Add some backstory to the introductory text.

Feature 5: Add more options for player input (different types of attacks that do different damage amounts).

Feature 6: Figure out where to clear the screen to not be so cluttered.

Feature 7: Ask if the player wants to play again rather than automatically closing the program when it is over.

That’s a whole week’s worth of exercises, and you’ll have a basic working game at the end. Next week, I’ll go through implementing these changes and maybe make a quick video to show that end result can look like a real-life, old-school text game.

Thoughts on ToME’s Adventure Mode

I’ve done several posts explaining why I think roguelikes are a great genre of game to play. It is probable that the most important feature of a roguelike for me is permadeath. For example, see this post for reasons why.

If you aren’t up on roguelikes, there are only a handful of games that standout as the “giants” that most people have heard of. One of these is called ToME (aka ToME 4; aka Tales of Maj’Eyal). There are more interesting features in ToME than could fit in a single blog post. Someday I may come back and post about these.

I’ll fully admit that my views on permadeath have evolved a bit, possibly due to my age. I think the older someone gets, the more likely they are to view losing all progress in a game as too punishing to be worth it. You tend to grow out liking the more extreme and hardcore elements of certain games.

Anyway, I stand by my original post. I’ll recall some key points. Permadeath is a great game mechanic, because it forces you to contemplate the consequences of your actions. It gives weight to the game. It makes you become better at it in order to win. You can’t just “save scum” until you get through a particularly difficult section.

Before you take this the wrong way, ToME is possibly the most well-balanced roguelike I’ve played. Every death feels like my own fault and not me getting screwed by the randomness. But when a game involves as much randomness as any of the great classic roguelikes, you are bound to get the occassional unavoidable death that is not your fault.

This becomes more and more pronounced as a game’s design is less thoroughly vetted for imbalances. Part of ToME’s excellent balance comes from people who have put in thousands of hours of play who can spot these things. The developer takes their opinions seriously which makes the game more fair.

ToME has three modes of play: roguelike, adventure, and explore. Roguelike has traditional permadeath. Once your die, you must start the entire game over. Adventure gives you five lives. Once those five are gone, you start the game over. Explore is deathless.

The main point I’ve been contemplating is whether Adventure mode ruins the permadeath experience of a roguelike. This will be a highly controversial statement, but I think it keeps all the original greatness of the mechanic and eliminates the negative aspects.

If you only have five lives, then each one is still precious. You’ll play the early game as if you only have one life, because if you waste one early, you will probably restart anyway. This makes the beginning just as intense as if you only had one life.

Let’s put it this way. If you don’t play as if you only have one life, then you will probably quickly lose them all anyway and revert to roguelike mode. So nothing really changes. In the middle and late game, if you are really good and don’t lose any lives, then it didn’t matter anyway. If you’re like me, you’ll probably be back to one life by that point and get all the benefits of roguelike mode.

It seems to me that Adventure mode merely serves to alleviate the annoyance and waste of time that comes from getting killed in one hit by some out of depth enemy that randomly appeared due to no fault of your own. It keeps all the intensity and pressure of permadeath, but gives some much needed buffer for the extreme amount of randomness of roguelikes.

I’d be quite happy to see some other roguelikes incorporate this as an option, but I’d also be totally understanding if they saw it as a compromise on the quality of the play experience.