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.

Theseus: a 7DRL 2015 Completed!

Final Stats:

One week.
About 90 hand drawn 64×64 pixel tiles.
Over 2000 lines of code.
A completed one-hp strategy roguelike.

Proof that it can be beaten happened during my stream where I tested for bugs (quality isn’t the best):

Actually, I think I’ve finally gotten it balanced so that you should be able to win if you know what you are doing every time except for extraordinarily rare scenarios dictated by the randomness.

7DRL 2015 Success.

[Edit:] I’ve set up an itch page: http://hilbert90.itch.io/theseus
Download the game to play for free here: https://www.dropbox.com/sh/1ywjy7s3y72bq5k/AABOZWsPOFBYs0qgcxW5Ccqxa?dl=0

7DRL: Theseus, Alpha Testing Phase

Alright. I have to leave for the day. I’ve thrown a few more things in this morning at the last minute, and then built the whole game.

If anyone wants to test it and give feedback, that would be much appreciated. I’ll still do a lot of polishing tomorrow.

Sorry, as of right now I have a build that I’m 99% positive will work on any Windows 7 or 8 machine. Earlier probably works, but hasn’t been tested. I haven’t made any others (the opposite of my first game which people could only get to work on Linux).

I’ve learned my lesson. If I do this again, I’ll probably switch to Cocos2d-x, which is open source, and easily builds into any machine.

Types of things I’m looking for:

1. The whole thing crashes. If this happens, try to remember exactly what happened and leave a comment.

2. The setup doesn’t install it on your computer, but you are using Windows. Let me know something about your computer if this happens.

3. The game is too easy (for example, you consistently scale up too quickly and bash your way to victory with no thought).

4. You can let me know if it is too hard, but I probably won’t change that.

5. Anything else that seems reasonable to need a fix for being on Day 6 of developing a game (you can say the art is not polished, but that will just hurt my feelings … it’s Day 6 and I had a lot of other things to do for goodness sake).

6. The Readme didn’t have enough information.

Tonight or tomorrow, I’ll probably add 2 more items for reference of what will be added before the final release.

Thanks. Have fun.

I’ll think of a better way of distributing this later. For now, go here: https://github.com/wardm4/Theseus

Press Download Zip (button to right). Ignore all the files except the one called “Theseus.zip” Right click on that and save it somewhere (your Downloads folder or whatever). Unzip it and then double click on setup.exe. That will prompt a standard install.

Better yet. I’ve added just the zip to a Dropbox here if you don’t want to get the source code too: https://www.dropbox.com/sh/1ywjy7s3y72bq5k/AABOZWsPOFBYs0qgcxW5Ccqxa?dl=0