作者：Simon Dean

当我们最初开始着手设计UI时，我们考虑了什么类型的玩家会选择《Folk Tale》以及这些玩家类型各具有哪些信息等等。如果将城市建造，实时策略和RPG等游戏类型全都结合在一起，便会造成信息过载且不能传达给玩家有效的游戏体验等风险。倾向于RTS游戏理念的玩家不一定会接受基于策略的城市建造游戏玩家所习惯的深度信息，或者RPG玩家所喜欢的角色描述和定制机制。于是我们便认真分析了怎样的玩家类型会在《Folk Tale》中起主要作用，玩家在做决定时是遵循怎样的思维模式，并且在分类前需要获得那些数据和功能去执行这些决定。

从简单的开始，然后迭代，并在最后提升难度

我们都知道许多尝试着跨越多种类型的游戏有时候会做得太过火，所以我们希望《Folk Tale》的开发是一个迭代过程。我们将基于合适度去决定任何功能的添加与删除，如果时间不允许的话便会选择彻底抛弃。我突然想到的一个例子，即战利品是会像3D图像那样呈现出来（较为逼真），还是游戏打开一个带有各种图标的库存让玩家自己拿取（不够逼真）。每种执行的UI需求都不同，而定期改变的设计目标也代表着界面设计任务面对着重重挑战。除了在早期投入更多时间去绘制好看的UI外，我们还采用简单的矢量画法去勾勒UI。这不仅能够帮助我们尽早明确屏幕上的划分，同时也让我们能够快速测试迭代流。早前的一大原型突出了“高温度”设计，即占领屏幕的整个下面部分。而我们也很快意识到这一方法太浪费空间。因为在布局的设定上我们未拥有太多时间，所以我们便抛弃了这个方法。

商业现实

事实证明，决策将影响着其它开发领域，推动着有关演示版本的商业决策的制定，从而减少3D设计团队的工作压力，让他们有时间去执行其它任务。Jen带着决策加入了我们的团队，成为了原画设计师，并且她也同意在正式工作前为战利品和技能手绘一组图标。

图标设计

Layered Icon Workflow In Folk Tale（from gamasutra）

因为我们的开发方法论中坚持着迭代与改变，所以我和Jen基于制作方式设计了一个层面，区分了背景（也就是渐变填充），背景外汇（漩涡，闪光和烟雾），中景图标和光晕，前景外汇，加亮区以及轮廓光。这能让我们更轻松地进行再次上色（之后会要求的）。为了支持再次构造，Jen画出了整个物体而不是简单地勾勒一些轮廓。最后我们便能够基于更高的分辨率进行设置，并将最后的图标大小（在所有UI窗口都是47×47像素）调整到与未来设备相符合的规格（游戏邦注：即使是面对带有更高显示器分辨率的设备，如iPad 3或iPad 4）。

基于易用性进行设计

学习了网页易用性方法，我们在界面设计过程中添加了一些简单的内容去实现易用性。这些简单的内容包括在播放过场动画时提供暂停按键和副标题，让玩家能够按照自己的速度前进，并且游戏难度将提高玩家的满足感而不是带给他们压力。比起网页，游戏拥有自己的易用性要求，如键盘重分配和鼠标转位能够带给左撇子玩家更大的便利。尽管因为预算的限制我们不能实现各种创想，但是易用性却是我们做出的每个设计决策中不可忽略的元素。

绘制UI

在做了重要角色并完成了测试的功能设定后，我们便能够进行最后的绘制了。因为在展开Kickstarter募资活动前我们所拥有的预算并不多，所以我们并不能添加所有规划好的功能（如定制），不过幸运的是我们所添加的都能有效地传达给玩家他们能够在最终游戏中看到的内容。

The Final UI Design（from gamasutra）

特别的元素和数据层

面对着游戏世界中如此多数据生成器（角色，建筑，自然资源，互动对象），早期的设计过程应该着眼于用例场景去明确玩家做决定和执行时所需要的数据和功能。因为我们需要从对象中获得数据，所以数据生成器将作为所需的空间元素，从3D游戏世界中将数据映射到2D UI平面上（即主UI的下方），并且在整个过程中它们都是处于摄像机视景和范围内。这时候如果空间元素离开了摄像机视景或超出距离范围，那么这一元素将再次在UI对象中循环。

考虑在大多数村庄中使用放大全景设置。即以大画面呈现出玩家做出各种决定的场景，如规划城镇建设或移动角色群。让我们将后者作为用例进行说明，如果玩家正在将角色从一个位置移动到另一个位置，他们便不会对每个角色的细节感兴趣。这时候我们可以抛弃一些不相干的数据和功能，如角色属性，名称，以及个人角色技能的访问等。实际上，这一用例只是要求我们去明确选择哪些单位。我们仍可以在压缩的空间（即在其它用例中）中传达有价值的信息（例如这是一次战斗演习），所以每个角色的头上将出现一个迷你状态图标，以呈现出该角色的健康状况和能量，并且在某些情况下这些图标也能呈现出角色所从事的任务以及该任务的重要性。比起文本指示，我们最好能够提供给玩家一些形状和颜色分明的视觉暗示。而对于受伤的角色，其健康指标将变成红色而不是绿色或者呈现出“13/50”。

随着游戏的前进，玩家将向一个群组下放命令，然后决定是否让一个角色脱离群组去接受专业训练。这时候的用例便会发生改变，即要求更多UI去执行决策。这时候玩家将会思考自己是否选择了合适的角色？他们是否是没有工作的农民？他们是否忙于一些有价值的工作而不应该被打扰？我是否需要在派遣这些角色去训练前采取一些有效的行动？这些都是玩家在极短时间内有可能产生的思维模式，而我们的目标便是确保拥有足够的数据能够第一时间解答玩家的这些问题。这时候我们仍然通过迷你状态指标去呈现出玩家的选择，并且还会弹出更详细的行动指标，即放大画面向玩家证实他们所选择的内容（包括名称，关卡，关键技能和命令）的准确性。我们从未使用过多数据（如角色属性或库存等）去对玩家施压，因为这与用例毫无关系。基于这种方式的分层数据能帮我们快速将信息与用例匹配在一起。

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

Designing UI For Hybrid Genre Games

by Simon Dean

When we first sat down to design the UI, we gave a lot of consideration to the types of players that would be experiencing Folk Tale, and the information needs each of their play-styles has. Combining the genres of city building, real-time strategy, and RPG, there was a risk of information overload and failing to deliver a positive gaming experience. Players gravitating towards the action found in the RTS aspects of the game might be put off by the depth of information a strategy-biased city-builder player might be accustomed, or the level of character detail and customization enjoyed by the RPG player. We set about analyzing the aspects of game play from each genre that would feature in Folk Tale, thought patterns players would have during decision making, and key data and functionality required to reach and execute those decisions before categorising everything into tiers.

Starting Simple, Iterating, and Ramping Up At The End

Being acutely aware that games attempting to span multiple genres sometimes strive to achieve too much, development of Folk Tale is deliberately an iterative process. Features are added and removed on the premise of natural fit, or dropped entirely if time pressures mean they are unrealistic to implement. An example that springs to mind was whether or not loot would fly out of corpses as 3D objects ( diegetic ), or if the player would loot by opening an inventory comprising of icons ( non-diegetic ). The UI demands of each implementation are very different, and regularly shifting design goals present a challenge for interface design tasks running in parallel. Rather than invest time in painting pretty UI early on, we adopted a simple vector-shape based approach to block out UI. Not only did this enable us to get any early feel for how much screen real-estate would be occupied, it allowed us to quickly test the flow of interaction. One of the early prototypes featured a “bottom heavy” design, occupying the entire lower section of the screen. We soon realized this was too clunky with a lot of wasted space. The decision to throw it out was made easier by the limited time spent on the layout.

Commercial Reality

As it turns out, decisions affecting other areas of development were causing anticipated slippage and resulted in a commercial decision for demo that the loot system would be non-diegetic, thereby reducing the burden on the 3D art team who’s time was required elsewhere. The decision coincided with Jen joining the team as concept artist, and she kindly agreed to hand paint a consistent set of icons for loot and skills before resuming normal duties post Kickstarter.

Icon Design

With iteration and change inherent in our development methodology, Jen and I designed a layer based production approach to icons, separating out background ( typically a gradient fill ), background fx ( swirls, magic sparkles, smoke ), mid-ground icon and halo, foreground fx, highlight and rim light. This would allow easy re-coloring should it be later required. To support re-framing, Jen would also paint complete objects rather than taking the shortcut of painting only the visible parts of a fixed composition. And finally it made sense to work at a higher resolution and resize down to the final icon size ( a consistent 47×47 pixels used in all UI windows ) to future proof for devices with ever increasing display resolutions such as iPad 3 and 4.

Designing For Accessibility

Learning from web accessibility initiatives, there are a number of simple things we added during interface design to help improve accessibility. Simple things like providing a pause button and subtitles during cut scenes, and allowing players to experience play at their own pace and difficulty can increase satisfaction instead of contributing to frustration. Gaming has it’s own set of accessibility requirements beyond those of the web, such as keyboard remapping and mouse inversion to help left-handed Gamers. While budget may prevent us from doing all that we can especially for demo, accessibility certainly factors in every design decision.

Painting The UI

With the important decisions made and the feature set frozen for beta, we were able to commit to the final paint over. With a tight budget prior to our Kickstarter campaign, we aren’t able to add all the functionality we have planned for the final UI ( such as customization ), but hopefully we’ve added enough to effectively communicate what you can expect in the final release.

The Final UI Design

Spacial Elements And Data Tiers

With so many data generators existing in the game world ( characters, buildings, natural resources, interactable objects ), an early part of the design process involves looking at use-case scenarios to identify data and functionality the player needs to support decision making and execution. Where data is required from an object, data generators are assigned as spacial elements on demand, projecting their data from the 3D game world onto a 2D UI plane that sits beneath the main UI, and only for the duration they are within the camera frustum and within range. The moment a spacial element leaves the camera frustum or goes beyond a distance threshold, the element is recycled in a UI object pool.

Consider a zoomed out panorama that takes in most of the village. It represents a macro view of world events where the player is most likely occupied with big decisions such as town planning or the movement of groups of characters. Taking the latter as our use-case, if the player is moving a group of characters from one location to another, they aren’t interested in the detail of each character. We can discard irrelevant data and functionality such as character attributes, names, and access to individual characters skills. In fact, the use-case simply requires that we communicate which units are selected. We can still communicate valuable information in a condensed space for other use-cases ( for example if this was a combat manoeuvre ), so each character receives a mini-status icon above their heads showing the characters health and power, and in some situations an icon showing what that character is up to if it is something important. It’s better to provide the player with a visual cue with shape and color than to display text indicators. So for wounded characters, the health bar should change to red instead of green instead of showing “13/50″.

Advancing the game a little, the player issues a group move command, and then decides they want one of the characters to split from the group and go somewhere to be trained in a profession. The use-case changes, requiring more UI to execute the decision. Have I selected the right character? Are they a peasant without an occupation? Are they busy doing something of value and should not be interrupted? Do I need to take corrective action before sending this character for training, such as healing them? These are all potential thought patterns that occur within milliseconds, and our goal is to make sure the data required to answer those questions is immediately available, and unpolluted by anything irrelevant. We still show the mini-status bars to indicate which character is selected, but the more detailed action bar for the character pops up showing a zoomed in portrait for visual confirmation that the correct player was selected, name, level, key skills and commands. We haven’t overwhelmed the player with data such as character attributes or inventory, because it would be irrelevant to the use-case. Tiering data in this way allows us to quickly match information to use cases.

I hope you’ve found this blog an interesting insight into the thinking and workflow that has gone into designing the Folk Tale interface.  If you have any questions or comments, I’ll be happy to answer them below or on our Facebook page.(source:gamasutra)