游戏设计课程之创造优秀的用户界面（17）

发布时间：2011-12-09 16:07:04 Tags：用户模式,用户界面,程序模式,颜色运用

作者：Ian Schreiber

什么是用户界面？

通常，我们总是会将用户界面（UI）与软件应用联系在一起。这个术语指的是软件中与用户具有直接交互作用的内容。它包含着用户可以随时获取的一些选择，这些选择如何显示于电脑屏幕上以及用户与电脑间的相互作用（通过鼠标/键盘，游戏手柄等）。一般来说，电子游戏的用户界面分为2个部分：输入界面（即玩家如何控制游戏）和输出界面（游戏如何向玩家传达他们行动的结果以及游戏状态的其它方面）。（请点击此处阅读本系列第1、第2、第3、第4、第5、第6、第7、第8、第9、第10、第11、第12、第13、第14、第16、第17课程内容）

如果你制作的是非数字游戏？它们是否也拥有游戏界面？当然，特别因为这种游戏缺少电脑对于游戏规则的控制，你更需要把握好它们的游戏界面。如果玩家并不理解非数字游戏规则，他们便会选择停止游戏。作为游戏设计者，你最不希望看到的便是你那精心雕琢的游戏机制和游戏体验因为界面问题而毁于一旦吧。

在非数字游戏中，用户界面是指游戏组件本身，它们既可以推动玩家与游戏进行互动（通过操控游戏组件）也可以用于接收反馈（通过观察游戏状态）。所以我们今天真正要讨论的话题是关于设计最后的游戏组件。

UI_simCity(from tintone.com)

用户界面设计

如何才能凸显你的用户界面？从两个方面进行分析：

容易使用。如果你已经知道了自己想要做什么，那么用户界面能否帮助你更加快速且轻松地完成预期任务？

容易学习。如果你是一款游戏的新玩家，你是否能够轻易地从用户界面获得相关信息，并了解自己能够在游戏中做些什么？

但是通常情况下我们很难同时权衡这两方面。举个例子来说，电脑上有一个特殊的“热键”设置（Shift/Art/Ctrl/Cmd组合键等）能够帮助我们更快速且更容易地执行一些普通任务，如保存文件或者在不同应用之间做切换。但是如果热键是完成任务的唯一方法（就像一些早久的文字处理器缺少菜单选项），那么用户便很难在第一时间学习并了解该应用。

在桌面游戏的信息表达方面，你也常常能够看到这种权衡点。对于资深游戏玩家来说，图表，附录，关键词，特殊标志以及图标等能够帮助他们更好地了解游戏状态，但是对于那些根本不了解这些标志的新手玩家来说，只会因此更加疑惑。你也可以用普通写法去描述这些内容，以此让新玩家能够对此一目了然，但是因此也会浪费那些已经掌握游戏规则的玩家的时间，强迫他们反复地吸收自己已经掌握的内容。

有时候，你也可以同时包含这两方面内容。现代软件应用便同时包含了热键和菜单选项，有些甚至还有“初学者”模式，即隐藏了一些高级功能让菜单显得更加简单，并让用户更容易了解软件。纸牌游戏《万智牌：旅法师对决》虽然包含了关键词，但是也通过插入式方法向那些有疑惑的玩家解释了这些关键词的意思。

好好考虑你的游戏机制以及玩家在遵循这些机制时需要做些什么。如何做更好地强调措辞表达而不会让新手玩家感到疑惑？或者如何做才能让资深玩家感受到更加流畅的游戏体验而不再只是反复记录一些内容或执行一些自动步骤的体验。

2个可用性模式

计算机应用的可用性有两个相关概念：用户模式和程序模式。用户模式是指用户（也就是玩家）对于计算机运作的看法。而程序模式便是指软件如何正常运转。（在非数字游戏中，“程序模式”是指设计者制定好的真正游戏规则，而用户模式则是用户对于这些规则的理解。）

问题就在这里。程序模式永远是对的。而如果用户模式和程序模式相互一致，也就没有问题。但是如果两者出现了分歧，那么当玩家尝试着去做一些事并有所期待时，往往只能得到相悖的结果。这种情况要是出现在电脑游戏中，将会挫败玩家的斗志，从而让评论者认为这只是一种“拙劣的游戏控制”。

在桌面游戏中，如果用户模式和“程序”模式相违背，玩家可能会因此违反游戏规则而错误地进行游戏。有时候这会让玩家感觉到自己正在进行一种低等的游戏体验，因为游戏的某些方面已经失去了平衡。而有时候虽然玩家也会觉得游戏体验很棒，但是后来，当他们与其他玩家一起“正确”玩游戏时，他们之间便会出现关于规则的分歧。

user model(from otal.umd)

改变用户模式

我们经常能够在游戏测试中遇到用户/程序模式不协调的情况。就像是：在每一个测试小组中，总是会有些玩家在第一次接触游戏时出现一些错误。这就是不符合“容易学习”规则而造成的问题。

但是更严重的问题还是来自于违背“容易使用”规则的用户界面。就像是：一个或多个玩家总是会不小心违反游戏规则。你明确地向他们指明了要点，他们也相对地改正了自己的行为。但是当再次面对相同问题时他们却会因为忘记，而一次又一次地犯下相同错误。然后反复向你道歉，最终让玩家变成了一个“愚蠢”的角色？这应该不是你想要看到的吧。

在这种情况下，最理想的解决方法便是改变用户模式。也就是你需要因此改变玩家的期望值或行动以匹配游戏中的“正确”模式。但是不幸的是，这通常很难实现。因为人类是习惯性的动物。我们创建了与周遭世界相联系的心理模式，并牢牢依赖于这种模式。而改变模式是一个相对缓慢的过程，需要我们投入更多的努力，但是却很少人愿意在游戏中投入这种努力。

为了在我的课程中讲授这点内容，我列举了战斗机的设计故事。很久以前，有个军队注意到一种特别的飞机引发飞行员意外弹射（游戏邦注：即飞行员弹射椅会随机激活危害飞行员的安全）的频率远远高于其它类型的飞机。按照军用飞机的成本计算，这种情况的发生会引起高额的成本损失，所以军队便迅速召集了工程师以找出问题所在，但是最终却仍未识别任何可能的机械或电力问题。最后，有人提出从意外发生弹射的飞行员所训练的飞机身上找问题。而结果也证明这是一个非常棒的主意！因为所有在训练飞机上接受实战培训的飞行员所控制的节流阀和弹射椅都跟实战飞机上的设置完全相反。所以当这些飞行员在驾驶这种新飞机时，他们原来关于飞机操纵的心理模式已经牢牢根植于心中，新飞机的培训内容也很难改变这种模式。

识别用户模式

好吧，既然我们无法改变用户模式，那么当你发现用户模式与游戏相互矛盾时，你就应该改变游戏界面以适应用户模式，或者因此触发一个完全不同的新用户模式。但是，你如何能够第一时间掌握游戏的用户模式？

最快捷的方法便是主动询问。寻找一些正在玩一款与你的游戏类似的游戏的玩家。询问他们如何看待游戏的进程（或者他们将如何完成游戏任务，或者他们有何应对方法）。当你多问一些人之后，很快就能够得到明确的一致意见了。

另外一个识别用户模式的简单方法便是进行游戏测试。观察玩家何时玩游戏，记录他们何时开始出错等。

最后，如果你的游戏模式仍然趋于矛盾，你就应该好好考虑是那一环出了问题。只有在一切条件都出于相互平衡的状态下，玩家才能顺畅地玩游戏。

这是谁的责任呢？

有时候你会感到好奇，为何很多人会把可用性问题归咎于游戏设计者。毕竟，如果你创造了一款优秀的游戏，并设定了合理的游戏规则，玩家就有必要好好阅读并遵守这些规则。为何他们违背了游戏规则却变成了你的错？有些人真的很没有游戏天赋，或者说并未认真地玩游戏，而为何作为聪明的设计者你却需要为这些人的错误负责呢？

好吧，我需要澄清的是，首先，这并非玩家的错。他们也许是从别人那学习到如何玩游戏，或者他们处于一个容易分心的环境，所以很难一心一意地阅读游戏规则。他们可能根本就未接触到游戏规则，因为他们可能购买的是二手游戏，而已经略过了规则环节。可能规则的陈述并不是使用他们所了解的第一语言等等。如此可以解释为何如此多聪明，理性的玩家经常会违背规则的原因。所以千万不要贬低这些玩家的价值，你应该多投入点时间帮助他们更好地阅读游戏规则。

其次，很多可用性问题看似是用户（玩家）的错，但却往往都是用户界面引发的问题，但是却可以进行修改。如果你的游戏更加容易操作，玩家也不会容易犯错了。作为设计者，你应该为你的游戏可用性负责，如此你将发现玩家会更加快速地掌握游戏，犯更少的错误，并且拥有更棒的游戏体验。

创建优秀的用户界面

既然我们知晓了如何识别糟糕的用户界面，我们又该如何创作出优秀的用户界面呢？一般来说，优秀的用户界面包含两方面内容：

符合用户的期待；

即时给予用户反馈信息。

如果游戏未符合用户的期待，那就是我们上述提到的用户模式与游戏模式出现了分歧。还有一种设计用户界面的方法：即时给予玩家反馈，让他们知道自己做的到底是对还是错（并且能够第一时间意识到自己做错了以及错误的原因）。

以下是从另一个角度去看待优秀用户界面：

让玩家更容易做对事；

让玩家难以做错事。

举个例子来说：假设你有一款拥有许多符号的桌面游戏。也许你只有一套标记去记录玩家的得分，并在棋盘周围设置分数轨道。也许游戏棋盘中有一张划分了不同区域的地图，而玩家在不同区域都安插了自己的军队。也许这里还有一个可进行采购和销售的全球市场，并且拥有一个市价清单以区分不同类型的产品。

虽然我们总是很容易混淆不同游戏数位，但是如果每一个符号都拥有不同的大小和形状，并且每一个符号所处的空间都有与之相对应的形状，情况又是怎样？如此，我们便能够更加明确地判断小符号必然行走在小规模的分数轨道上，星形产品标记必然归属于星形产品价格轨道，以此类推。

玩家要如何记得在每个轨道上调整不同产品的价值？在轨道右边的棋盘上明确写明规则总结能够帮助玩家更好地记忆。如何解决战斗问题？在军队位置中印上单位强度，统计值以及能力信息，而余下规则也会总结于棋盘上或者参考卡片上，再或者可以通过游戏前玩家间相互告知的方法解决。

当你开始设计用户界面时，可以参考以下过程：

首先，制作一份任务清单，帮玩家理清游戏路线，让他们能够更加轻松地面对游戏任务。

其次，特别留意那些常见任务，即玩家会频繁遇见的任务。而因为复杂任务的出现频率较低，所以不用特别在意。

反复进行游戏测试。

颜色的使用

合理使用的话，颜色能够帮助你更好地向玩家传达信息。这是一种非常有效的方法：颜色无需占据额外的游戏组件空间，因为组件本身就存在着，你需要做的只是为其上色。以下是游戏中颜色使用的一些小窍门：

人类的眼睛最容易捕捉到的两种颜色是红色和绿色，其次便是蓝色。所以这几种颜色总是较为突出，能够轻易地吸引人们的注意；但是如果你使用过分明亮的色彩则很容易造成玩家的视觉疲劳。

但是不要单纯地依赖于颜色，因为在你的用户中肯定也不乏色盲者。除了使用不同颜色，你还可以通过改变颜色强度（例如黑白两色也能给你带来不一样的效果）或者使用不同形状等方法去区分不同物体。

qrossfire-symbols(from joshblog.net)

利用色彩的一致性。如果你在游戏中使用同一种颜色去描绘多种物体，那么就说明这些物体之间具有关联性。例如我玩过的桌面游戏中，有五种不同的资源，而每一种都有独自的颜色；每一位玩家也拥有属于自己的颜色，并且玩家的颜色会与资源的颜色出现重合，但是相同颜色玩家和资源之间并不存在连系。如此设置会让玩家感到疑惑，他们会想当然地认为一个颜色的玩家必然拥有同种颜色的资源，但是事实却并非如此。

更多用户界面设计技巧

排名不分先后：

如果可能的话，采取自动操作或清除那些不包含任何有趣决策的任务。在电子游戏中玩家每次的点击或键盘按压，或者在桌面游戏中的掷骰子或翻转卡片都需要受到一些有趣动机的影响。如果玩家首先接收到的是一些维护任务而在后来才能感受到决策乐趣，你便需要思考如何做才能让简化这些无聊的流程了。

使用视觉隐喻。如此我们更能看清它们分别代表了什么。如果你的玩家控制的是一些代表人的角色，你可以使用一些人型棋子，总比使用木质方块好多了。不同的棋子会让玩家对游戏拥有不同的看法。

同样地，如果你在游戏中使用图标去代表特定的能力，也尽可能地选择类似于其代表形象的图标。

与同类型游戏保持一致。在角色扮演游戏中，红心代表生命值，蓝色水滴代表魔力。为何要这么做？因为其它游戏就是这么做的，而你的玩家也会想当然地如此理解你的游戏。

不要想着“这个太晦涩了，我们可以在手册中详细解释。”记住，你的玩家不一定拥有手册，或者不一定会去看手册的内容。所以你需要尽可能地让用户界面足够一目了然，然玩家根本不需要借助手册的帮助。

经验教训

创造一个优秀的用户界面是一种不同于核心系统设计的技巧，但是却是个值得我们深入学习的技巧。你需要记住，用户界面设计是一个非常广阔的领域，而我们在本篇文章中讨论到的还只是一点皮毛。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Level 17: User Interfaces

If you have made it to this point, your game is hopefully coming along nicely and you are approaching the final stages of design. You may still have temptations to mess around with the mechanics, especially given the short time period allotted for the Design Project, but at this point I want you to settle on something that is at least “good enough” so that you can experience the later stages of design.

Once your mechanics are complete and the game is playable, balanced, and meets your design goals, the last thing to do is figure out how to construct the final version. This is not simply a matter of drawing up some art for your cards and board and sending it off to the printer. There are some considerations to be made concerning the user interface of your game, and those considerations are what we will talk about today.

Readings / Viewings

Read the following:

Challenges for Game Designers, Chapter 16 (Creating a User Interface)

Cooperation and Engagement, a Google tech talk by game designer Matt Leacock. This video actually ties together a lot of the concepts we’ve talked about in this course, from difficulty levels and flow states to the iterative process to game narrative, and it should serve to solidify those concepts using the concrete example of Pandemic, one of the best-selling hobby games of last year. But what I really want you to pay attention to is how Matt presents his iterative work on the design of the game components themselves, such as how he determined the shape, orientation and color of the cards. The actual talk is only 30 minutes long, although there are an extra 20 minutes at the end from audience Q&A.

What is a User Interface?

Normally, we think of the term user interface (or UI) as it applies to software applications. This term refers to the parts of the software that interact directly with a human. It covers things like what options are available to the user at any given time, how those options are presented on the computer screen, as well as the physical interactions (mouse/keyboard, game pad, etc.). In general, with video games, the UI is divided into two parts: the input (that is, how the player gives commands to the game) and output (how the game communicates the results of those actions and other aspects of the game state to the player).

What if you’re making a non-digital game? Is there a UI? Of course there is – and if anything, it is more important to get it right, since you don’t have a computer automatically enforcing the game rules. If the players don’t understand the rules of a non-digital game, the only recourse is often to stop playing. As the game’s designer, the last thing you want is for your brilliant mechanics and carefully-crafted play experience to be ruined because of an interface issue.

In non-digital games, the UI is the game components themselves, since they are both how you interact with the game (through manipulating the game bits) and receive feedback (by viewing the game state). So what we are really talking about today is designing your final components.

User Interface Design

What makes one UI better than another? We generally talk of two things:

Ease-of-use. If you already know what you want to do, how fast and easy is it to perform your desired task correctly?

Ease-of-learning. If you are new to the game, how easy is it to figure out what you are allowed to do and what information is available to you?

In practice, there is often a tradeoff between these two. For example, on computers, the presence of special “hotkeys” (Shift/Alt/Ctrl/Cmd key combinations and the like) saves time by making it fast and easy to perform common tasks like saving a file or switching between applications. But if these are the only way to perform that task (as is the case with some older word processors that lacked menus), it makes the applications difficult to learn for the first time.

In board games, you often see this tradeoff with how information is presented. Charts, tables, keywords, special symbols and icons – all of these make it much easier for an experienced player to get a quick summary of the game state, but they can be confusing and intimidating to the novice player who does not know what these things mean. The alternative, writing everything out in longhand, makes it much easier for a new player to see immediately what everything does… but it also makes the game take longer for players who already know the rules and do not need them repeated in full on every card.

Sometimes you can include both. Modern software applications include hotkeys and menu items, and some even have a “beginner” mode that hides advanced functionality to keep the menus simple, making the software much easier to learn. Card games like Magic: the Gathering include keywords, but then explain those keywords in parentheses for players who do not know what the keyword means.

Look at all the mechanics in your game, and what players must do in order to follow them. Are there any cases where your wording could be clearer for first-time players? Are there situations where experienced players of your game feel like they are doing excessive book-keeping or note-taking, or performing multiple automatic steps, where it would be possible to streamline the experience?

The Two Models of Usability

In usability for computer applications, there are two related concepts: the user model and the program model. The user model is how the user (i.e. the player) thinks that things should work. The program model is how the software actually works. (In non-digital games, you can think of the “program model” as the actual rules of the game as intended by the designer, and the user model is what the players think the rules are.)

Here’s the thing. The program model is always right. If the user model and program model match one another, there is no problem. If the two are different, the player is going to do something, they’ll expect one thing to happen, but another thing happens instead. With computer games, this leads to frustration, and reviewers will say the game has “poor play control” (often without fully understanding why).

In board games, if the player model and the “program” model are different, the players will just play the game incorrectly. Sometimes, this means the players will have a suboptimal experience, because some aspects of the game will feel unbalanced. Other times, the players will have a perfectly good time, but when they later play the game with other players who are playing the game the “right” way there will be rules arguments.

Changing the User Model

It is common to see a user/program model mismatch during playtesting. Here is what it looks like: with every playtest group, the players always do one particular thing wrong the first time around. This suggests an ease-of-learning problem.

A more serious case is an ease-of-use problem with the UI of your game. It looks like this: one or more players accidentally do something wrong in the rules. You point it out to them, and they correct their behavior. But then they forget, and they do it wrong again on the next turn. And the next. And the next. And your players apologize to you for continuing to get it wrong, and they feel like idiots.

In cases like this, it would be ideal to change the user model. That is, you’d like to change your players’ expectations or actions in order to match the “correct” model of the game itself. Unfortunately, in practice, this is effectively impossible to do. People are creatures of habit. We build up elaborate mental models of the world around us, and we rely on those models greatly. Changing a model is a slow process that requires great effort on the part of a person, and most people are not going to put that kind of effort into your game.

To illustrate this in my classroom courses, I tell the story of the design of a fighter jet. Once upon a time, the military was noticing that one particular type of aircraft had a much higher-than-average number of accidental pilot ejections (that is, the pilot’s ejection seat was activated when the pilot did not intend for that to happen). Given the cost of military aircraft, it gets very expensive when something like this happens, so they had a lot of engineers study the problem to figure out why the seat was ejecting, but no mechanical or electrical problems could be identified. Eventually, someone got the bright idea to look at the aircraft that the accidentally-ejected pilots had trained on. It turned out that in all cases, they had trained on an aircraft where the positions of the throttle and the ejection seat controls were reversed! So, when the pilots got in this new aircraft, they had already formed a mental model of where all the controls were, and no amount of training on the new aircraft could change it.

Identifying the User Model

Okay, so we can’t change the user model. That means if you find a mismatch between the user model and the game, you should change the game’s interface so that it either conforms to the user model, or change the interface so that it is different enough that it triggers a different user model. But how do you know what the user model is in the first place?

Thankfully, this is pretty easy to do. The easiest way is to ask. Find people who play games similar to the one you’re making. Set up a situation for them, and ask them how they think the game would work (or how they would accomplish some task, or whatever you’re trying to figure out) if they had to guess. Once you ask a few people, a clear consensus will emerge pretty quickly.

Another pretty easy way to identify the user model is to playtest. Watch when people are playing the game, and make note when they do something wrong.

Lastly, if your game’s model is nontrivial, it is probably wrong. Other things being equal, people will assume simplicity.

Whose Responsibility Is It, Anyway?

You might wonder, in some cases, if usability issues are really your problem as the game designer. After all, if you create a good game and you give a complete and correct set of rules, isn’t it the responsibility of the players to actually, you know, read the rules and follow them? If they play your game wrong, how is that your fault? Some people are just stupid or careless, and certainly the brilliant designer should not be held accountable for these people. Right?

Well, first off, it may not be the player’s fault. They might have been taught by someone else. They might be in a distracting environment, so they can’t give the rules their undivided attention. They might not have the rules; maybe they purchased the game second-hand and the rules were missing. The language the rules were written in might not be their first language. There are any number of reasons why a perfectly intelligent and rational person might have difficulty. So, don’t just write these people off as not worth your time.

Second, most usability failures feel like a mistake on the part of the user (player), but they are actually a UI issue that could be fixed. Consider: if your game were easier to use, it wouldn’t let the players make mistakes. As the designer, take responsibility for the usability of your game, and you will find that players are learning it faster, making fewer mistakes, and generally having a better time.

Building a Good UI

Now that we know how to identify a bad UI, how do you design a good one? In general, a good UI does two things:

It does what the user thinks it will do; and

It gives the user feedback so they know what it did.

If the game doesn’t do what the player thinks it will, that is a problem with the user model not matching the game model, as we’ve already discussed. But there is one other aspect to designing the UI: giving the player immediate feedback so that they know what they did is correct (and, in the unlikely event that they did something wrong, they will immediately see that it is wrong and understand why).

Here is another way of looking at what a good UI does:

Make it easy to do things correctly; and

Make it hard to do things the wrong way.

Here’s an example: suppose you have a board game with several kinds of tokens. Maybe you have one set of markers that keeps track of player score, using a scoring track around the edge of the board. Maybe the game board has a map divided into provinces, and players have military units that are placed in the provinces. Maybe there’s also a global market with goods for purchase and sale, and a separate track for each trade good that lists its current price.

It would be easy to get all these different game bits confused. But what if each token was a different size and shape, and each space on the board matched the shape of the token that was used there? All of a sudden, it becomes a lot easier to figure out that the small square tokens must go on the small squares of the scoring track, the star-shaped goods markers go on the star shapes of the trade good price tracks, and so on.

How will the players remember how to adjust the trade good values on each track? A rules summary printed on the board right next to the tracks makes it easy to remember. What about how combat is resolved? Unit strengths, stats and abilities can be printed on the military units themselves, and the remaining rules can either be summarized on the board or on a quick-reference card or other player aid given to each player at the start of the game.

As you go about designing the UI, here is a process you can follow:

First, make a list of tasks that players need to accomplish in the game. Make it easy to do those tasks.

Second, pay special attention to the most common tasks, the ones that players are doing over and over. Difficulty and complexity of a task should be in proportion to how rarely it is used.

Iterate through playtesting.

Use of Color

Color is a great way to convey information to players if done well. It is efficient: color takes up no additional space on a game component, because the component is already there; all you’re doing is coloring it. Here are a few quick-and-dirty tips for thinking about color use in your game:

The colors that normal human eyes detect most easily are red and green, followed by blue. These colors will tend to stand out more… which can be good for drawing attention, but bad for eye strain if you use fully-saturated bright colors.

Don’t rely on color alone; a nontrivial portion of your audience has some degree of colorblindness. Vary the intensity of colors as well (so that if, for example, photographed with a black-and-white camera, you would still see a difference), and use different shapes in addition to different colors. By having things differentiated in multiple ways (different shape, different color, etc.) it makes it really obvious that those things are distinct from each other.

Use color consistently. If you use one color for several things in a game, those things should be related. Some board games I’ve played, for example, have (say) five different resources, and each one has a color; but each player also has a color, and some player colors and resource colors are the same, even though there is no relationship between the green player and green resources. This kind of thing can confuse players who might think that a particular resource is owned by their opponent when it isn’t.

More UI Design Tips

In no particular order:

Automate or eliminate tasks that don’t involve interesting decisions, if possible. Every click or keypress in a video game, or die-roll or card flip in a board game, should involve the player doing something that is interesting to them. If the player first has to do a bunch of upkeep tasks just to have the privilege of making interesting decisions later, see what you can do to streamline the boring stuff.

Use visual metaphors. They make it obvious what something represents. If your players control a bunch of pieces that represent people, using people-shaped pawns is clearer than using wooden cubes. Compare the pawn images below. Each has a very different effect on how the player views it.

Likewise, if you use icons in the game to represent certain abilities, choose icons that look like the concept they’re representing (if you can).

Be consistent with similar games. In an RPG, red hearts probably mean life or hit points, while blue drops probably represent mana or magic power. Why? Because that’s how everyone else does it, and your players will assume by default that you do it that way too.

Don’t just say “well, this is confusing, so we’ll explain it in the manual.” Remember, your players may not have the manual and they may not read it. Try to make your UI intuitive enough that your game doesn’t even need a manual.

Lessons Learned

Giving your game a good UI is a skill that is separate from core systems design, but it is an important skill to learn. Keep in mind that, as with most things in this course, UI design is a huge field and we are only going to cover the very basics. There are entire courses (and even college majors) devoted specifically to UI, not to mention hundreds of books, and I encourage you to seek out these resources after this course is over.