作为 UI 程序员，我以我开发过的项目，谈谈我对这件事情的看法。
首先，我简单说一下 UI 组的开发流程。
- 前期：UX 设计制作概念图/动态图 – UI 美术制作相关素材 – UI 程序制作原型
一次迭代
- 中期：UX 制作二次方案 – UI 美术完善素材 – UI 程序完成基本功能，做出 0.1 版本
n 次迭代
- … UI 程序制作出最后版本
UI 程序的任务，在不同的迭代周期中，是会相应变化的。
前期阶段，UI 程序主要判断当前系统是否能满足需求，是否会存在内存上的风险（ UI 个体的数量，UI 美术的大小，UI 动画的复杂度 ）。
中期阶段，UI 程序是完成基本的功能，并和其他系统进行衔接。比如数据接口的衔接，读取用户输入或者是后端传入的数据。
后期阶段，UI 程序则是需要美化整个界面，并完成潜在的拓展准备。比如游戏上线后，界面内容会有更新，排版可能会发生变化。这种情况下，当前界面能否动态地相应变化，还是需要笨拙地被“人工调整”？又比如其他系统的数据或者逻辑发生了变化，那么当前的界面能否很好地处理错误，或者至少及时报错，让开发人员快速觉察到问题？
从我的个人认知中，程序拼界面和 UI 的原因，往往是以下几点：
1.界面和UI 背后的复杂游戏逻辑。
这一点对于美术和设计，可能存在一定难度。因为游戏中，往往一个界面，是游戏几个系统的信息交汇点。比如多人射击游戏的 Hud，诸如玩家的血量，子弹数目，特殊技能进度，敌人被击中后的 UI 反馈， 解锁成就的提示信息，小地图中的敌人位置，都需要及时向玩家反馈。这个过程中，我们需要完成很多任务。比如，玩家如果打开了子菜单，我们必须保存当前 Hud 的状态，从而玩家关闭菜单后，还能查找到之前的信息；如果同时几个消息被触发，我们必须处理各种消息的优先级，保证好渲染顺序。
2.UI 编辑器不是万能的
尽管很多引擎，能配置了 UI 编辑器。包括我们的自研引擎，也包含了对应的 UI 编辑器。但是目前来说，UI 编辑器的主要功能（ 以我接触过的 ），还是在于排版布局，动画编辑和简单的事件调用。尽管业界中，有些开发团队已经开发出了很强大的编辑器。比如 Division 的编辑器，能够模拟实际游戏环境运行，且所看即所得（ What you see is what you get ）。详见 Lessons learned creating UI for The Division GDC 2017。但我觉得目前游戏 UI 编辑器面临的最大问题是，无法处理随时在变的需求。因为使用 UI 编辑器带来的好处，除了让非技术人员参与开发，提高开发效率，另一个就是使 UI 规范化。可是游戏 UI 的需求是随时变化的。规范化的 UI 永远是一个可以靠近但是难以达到的状态。
作为游戏开发管线的末端，中间任何一个环节的更新，都可能影响到 UI 端。这就造成了，你上周刚给编辑器添加的新功能，到了这周，又显得捉襟见肘。如果正好这周是 deadline，那么最快速的解决办法，还是需要程序修改脚本/代码。
最后再谈谈两点：
1.UI 程序需要审美吗？
需要。我觉得作为 UI 程序，审美虽然不是必需的，但归根结底，它就是必需的。UI 程序至少要知道，自己开发的界面或者 UI，会不会存在美术或者排版上的问题。这个标准，你放在其他直接参与游戏内容开发的程序（ gameplay, render, AI ）身上，都是共通的。如果任务量大，没有时间学习。组内的 UI 美术/设计，不就是最好的老师吗？我最早的平面设计知识，就是来自于之前共事的 UX 设计师。从开发流程上来说，具备基本的审美，也能帮助程序、美术和设计之前的沟通。大家越能使用同一套语境沟通，沟通成本就越低。
2.UX/UI 设计需要做程序吗？
需要。以我们项目为例，我们之所以选择 lua 脚本语言完成 UI 逻辑，就是因为它的轻量和灵活性。很多简单的 UI 界面逻辑，是完全可以有 UX/UI 设计完成的。在我的假想中，比较理想的 UI 团队进阶版本，应该是：
懂审美的 UI 程序，开发更多的系统功能，用于支持 UX/UI 的设计。比如一个强大的 UI 动画系统。
懂脚本的 UX 程序，能够熟练使用 UI 编辑器和脚本，完成基本的 UI 界面逻辑。
总结起来，就是：
前线拼杀的 UI 程序士兵，拿部分时间开发军需。
参谋部的 UX/UI 设计师，也要会基本的射击。
来源：知乎 www.zhihu.com
作者：董晶晖
【知乎日报】千万用户的选择，做朋友圈里的新鲜事分享大牛。
点击下载
此问题还有 49 个回答，查看全部。
延伸阅读：
哪些游戏有着非常漂亮的 UI 界面？