Card games are indeed on an upward trend. Hearthstone basically showed the world that a polished cross-platform freemium collectible card game could be a huge success. True to form, many similar games appeared to (try to) carve out their own slice of that burgeoning pie.

The thing is that competitive card games have been around for decades. Magic: The Gathering, the grandfather of the genre, is nearly 25 years old. Hearthstone really only took major advantage of the digital space to handle all of the upkeep that most players normally have to do for themselves. Instead of dice, counters, pens and paper, all of the fiddly details are handled by Hearthstone and the player can focus primarily on the interesting and fun bits.

The design for a card game follows a few core principles. Like many tabletop games, they are basically all about resource management and the interesting decisions based on managing those resources. There’s also an inherent randomized element to them, meaning that each match will likely not take the same path. The important takeaway is to provide the player interesting choices at each step of the play process.

Understanding what resources the player must manage is the most important element of card game design. Common resources that the player must manage are (along with examples from Hearthstone) in parentheses:

Each card must have some sort of cost (usually in per-turn resources) and effect. The gameplay emerges from the player deciding which cards to play. The power of the effect must be proportional to its cost. This defines the game’s power curve. One of the most valuable skills a player or designer can cultivate is the ability to evaluate a card’s power to cost ratio.

Cards generally have a number of different qualities to distinguish them in addition to cost. Examples of one or more qualities that may occur on a card include:

Look at the above three cards that each cost one mana. They are each one-time use cards, but Mirror Images remain on the field until the opponent removes them. Arcane Missiles and Breath of Sindragosa can potentially take resources from the opponent (by killing or damaging enemy minions), while Mirror Image grants its player more resources (two taunt minions).

The synergy of specific card combinations is where the nuance and fun comes in. Cards that selectively work together make it much more difficult to find an optimal way to play the game (i.e. “solve” it). Players must be able to recognize which cards and abilities work well together in order to grow in skill. Sindragosa’s summoned Frozen Champions work especially well with Frost Lich Jaina’s new hero power. It presents the opponent with a bad decision - help the mage player by breaking the frozen champions and adding legendary minions to her hand, or let the mage use Icy Touch on the frozen champion herself and get a free water elemental out of it.

The main resource in most card games, however, is just more cards. Typically, in any given competitive card game, whoever gets to play more cards will tend to win because it means that player has acquired and spent more overall resources. This is called “card advantage” and it is a central axiom to all card games. Thus, the better cards tend to be those that require more than one card to answer, and weaker cards usually provide effects that don’t require cards to answer. This helps provide a baseline for card design. A card like Sindragosa brings two additional legendary minions with her, making her a very strong card to play.

As you might have begun to notice, a lot of these observations about card game design are not specific to Hearthstone, but common to most card games in general - Magic, Gwent, Shadowverse, Yugioh, Pokemon, and the like. Developing a card game requires understanding these kinds of core design principles while still maintaining the usual things - theme, interface, constructing an experience for the player, etc. Those readers with good memories might recall that I wrote some pretty nice things about [Hearthstone’s user experience a while back]. Those observations still apply quite strongly. But any card game is about managing resources and exchanging those resources strategically to put oneself at an advantage over an opponent. It’s up to us as designers to create systems to enable players to make those interesting and strategic choices.

Got a burning question you want answered?

I’d like to try to generalize this question a bit more. This is what I am getting from your question:

There’s so much to learn out there, but not all knowledge is equal. What knowledge is more valuable to prospective employers?

To answer this, I’ll use an analogy. Let’s say that you are looking to hire a musician in order to commission some music for a project. You’ve narrowed it down to two candidates.

Candidate A has composed music for a variety of genres, having credits collaborating with multiple artists in hip hop, pop, R&B, rock, and even worked with a classical symphony once before. Candidate A also has a background in music theory and is familiar with the construction and structure of music.

Candidate B is the lead singer for a reasonably successful Bon Jovi tribute band. The candidate is definitely talented, has good pitch control, does a mean performance, and encyclopedic understanding of the music of Bon Jovi. This candidate is mostly self-taught, and has tried making various adaptations of Bon Jovi songs to some other styles. However, this candidate doesn’t have much experience with any other types of music besides Bon Jovi, and never without a Bon Jovi setting.

Which candidate would you choose?

The answer should generally be “It depends”. If I want music that is very much focused on the hair band 80′s-style rock-pop, I’d probably hire candidate B. If I wanted a more broad set of music, I’d hire candidate A. However, I would say that candidate A has a much better overall hireability rating than candidate B, if only because candidate A has a better understanding of the concepts and fundamentals of music than candidate B. More studios would be likely to hire candidate A.

If I hire you, I want you to become useful to the team as soon as possible. Learning to use new tools and languages is part and parcel of the job. I’ve had to learn to use dozens of new tools, languages, and engines to become useful to the development teams I’ve joined over the course of my career, and I’ve never had issues with this. But I’ve certainly seen others struggle when they lacked understanding in fundamentals and have instead focused on the specifics of the tools they were learning.

It’s generally easier to teach someone who knows how to construct a building how to use a new kind of screwdriver than it is to teach someone who already knows how to use that screwdriver how to construct an entire building. The only exception to this is when I am looking specifically for a screwdriver expert.

In order to understand what a progression system is used for, you need to understand the concept of gameplay loops. Let’s use Call of Duty as our example today, since it’s a great case of a non-RPG game that successfully integrated a progression system into their gameplay.

I’ve written some about microtransactions before, including talking about things like positive externalities, and I have mentioned before that a lot of the main issues with microtransactions are just unfamiliarity and conservatism… players like what they are used to, and the thought of a free to play game that is paid for by some in small pieces places them outside their comfort zone. If that’s what you’re interested in reading about, I suggest you click the link and read that.

I’m going to go a different way today, however. Today I’ll stand on the soap box a bit and give some of my own observations. There are several features I would like to see other developers incorporate into their F2P models to help bridge that comfort zone from non-paying player to paying player. I’ll go ahead and go into a few of them here today.

It’s trickery, and it’s actually a pretty interesting trick. What you’re seeing is the combined effects of shading and normal mapping. 

Shading is when the renderer uses positional data to calculate the color of a particular pixel on screen. There are a number of different techniques for this with differing results. Here is the first one, using a technique called “Flat Shading”. Flat shading is when the renderer adjusts the color of a polygon surface based on what it determines the color of the center of the polygon is.

You can pick out the individual polygons pretty easily here, right?

Now we’ll switch to a different shading technique. This one is called Phong shading. Instead of using the center of the polygon to determine what color the polygon is, the renderer will take the color value from the corners of each polygon and interpolate between them and the color value from the center of the polygon. This results in shading that is much more gradual and smooth, as you can see here:

If you look closely, you can see that the number of polygons here actually hasn’t changed. You should still be able to pick out the vertices along the outline of the “sphere” here. But it certainly looks a lot rounder, doesn’t it?

But this still has issues, because we might have something that’s very polygon-intensive, like a cobblestone street. This poses a problem - we want streets to be flat in terms of polygons, because it’s a street and you walk on it, but it should still visually look like cobblestones. You don’t want to spend extra GPU cycles rendering extra polygons for the street when you could spend them on hair or fingers or facial expressions or something, but you don’t want it to look flat either. So how do you fix this?

Have you ever seen the movie Indiana Jones and the Last Crusade? There was a scene in the movie where Indy has to take a step out into what looks like a bottomless gorge:

But he’s not really stepping onto a bottomless gorge, is he? If you look closely, you can see it. When you change the angle of the camera, you can easily see what’s actually going on:

The step of faith here is actually a cleverly painted (and flat) bridge to make it look like there’s a huge drop. From the viewer’s perspective, it looks 3D even if it actually isn’t. And since we have a computer fast enough to do all the calculations for us every frame, we can make it calculate what the 3D surface would look like from different angles and repaint it on the fly, even if the polygon we’re displaying is actually still flat.

This is called bump mapping (or often normal mapping, which is a specific kind of bump mapping). The way it works is that you apply a texture like this to the polygon, but instead of being directly displayed on the polygon, it’s used by the renderer to determine the way the pixel at that point should look in terms of height, even if the polygon is flat at that point. It simulates a bunch of different heights or depths, even though the polygon is still actually flat. The result is what you see to the top right - lighting as if it were bumpy or pock marked, but without actually needing additional polygons to get the visual effect.

The results of this can be pretty interesting. Take a look at these. This is a model with a lot of polygons in it to create a bunch of different shapes:

And here is a completely flat polygon with a normal map based off of the above shape applied to it:

You can see that the stuff that really sticks out far like the cone doesn’t look right, but the stuff that only pokes out a little bit like the donut and the hemisphere actually look pretty good for taking up no additional polygons at all. If you looked at both of them from directly above, without the side angle view, it’d actually be pretty tough to tell them apart without touching them. And that’s the point - it’s a way to fake heights and depths without adding extra polygons. This is why it works best on flat surfaces like walls and the ground that you view from (nearly) straight on:

These are both flat polygon roads, but the right side looks a lot more like it’s made of real stones than the left. There are other effects also at play, like specular maps (which are used to calculate how shiny/reflective or dull an object is) and more, but they also operate on the same sort of mathematical principles.

It takes a good artist to create the proper map textures for 3D models, and it takes a graphics programmer with a solid understanding of math to create the renderer that can do all of the proper calculations to take those maps and figure out exactly what color each pixel actually is. I will say that it can be pretty fascinating stuff.