What ways are there to teach users the rules to a game?

Question

I'm trying to find all the different ways I can teach a user the rules of a card game and considering which is the best way to do this.

I am building an application that allows users to play a number of card games with friends, with strangers or against the computer. The interface is the same for each card game but, obviously, the rules of each game are different.

Assuming the users are familiar with the how to use the application itself (i.e they know how to play cards, how to add new players etc) how should I show users the rules to each specific card game?

Here are some of the options I've considered so far:

---

1. Step-by-step walk through

^{download bmml source – Wireframes created with Balsamiq Mockups}

My first thought is to take users though a step-by-step walkthrough of the rules showing some examples along the way. This is a bit slow and takes users away from a fully interactive interface. This could be quite slow and only be marginally better than a page of written instructions - I can imagine a lot of users skim reading and clicking through next rather quickly.

---

2. Tooltips

^{download bmml source}

Users could go through the same experience as the walk through but inside a real game. The advantage would be seeing real life examples. The big downside of this is that other users would have to wait a lot longer while the learner reads the tooltips (perhaps overcome by playing first game with bots). Also, if this were using real game logic, it would be much harder to explain rules about rare or random events that may not present themselves during the game.

---

3. Trial and Error

^{download bmml source}

The harsh approach would be just to explain rules only when users break that rule. This would mean keen users can jump straight in and only be interrupted when they can't perform specific actions. I'm worried this may be frustrating without any initial overview. Perhaps it could work if accompanied by a written set of rules. It also has similar problems to 2.

---

I'm looking for more ideas/suggestions since all of the above seem to each have their own disadvantages.

Are there any options I haven't considered? Is there an augmentation of one of these ideas which would make it better?

Answer 1

It would really depend on how complicated this game is, but luckily there is a great example of card-game UX in a game called Hearthstone.

Their approach would most likely take more work than you'd like to put in, which is to have a series of tutorial games against AI. They are carefully sequenced to introduce elements at a learnable pace, and while it feels completely interactive, there is usually only one valid choice at a time. It is a bit like your third example, as they expect you to play the correct move (mostly obvious) and if you try to do something else, it redirects you with a dialog.

One element you can adopt from them is highlighting playable cards. I would incorporate this technique with a combination of all of your examples. First, a succinctly written "3 Easy Steps" sort of approach to give the user a general outline of the game without any of the specifics. This would be presented similarly to your first example, and it should be concise and clear enough that you would get it on a glance without even trying to read it.

When the game starts, all playable cards might be highlighted or treated differently. You could even have a "recommended" tooltip for beginners. When an unplayable card I would bring up a tooltip instead of a dialog so that the user can quickly make the correct play.

One thing to be very considerate about is the wording. There is no need to explain the entire rule in the tooltip. For example, "Otherwise, you can play any card in your hand" is not relevant at the moment. That knowledge may come in handy later, but you can just present it later if the user can't figure it out.

The dialog may come into play to introduce any new elements that are critical to understanding the mechanics of the game, or are generally unintuitive.

There are a lot of specifics to this that may or may not work with your particular application, but hopefully there are some ideas here that sound plausible.