unity背包增加一个物品然后加个button_设计一个不需要技术直接参与的UI工作流...

最新推荐文章于 2023-07-16 13:00:27 发布

最新推荐文章于 2023-07-16 13:00:27 发布 · 192 阅读

文章标签：

#unity背包增加一个物品然后加个button

毕竟行为树现在已经比较普及了。既然技能，AI这类复杂的部分都可以分给策划通过类似蓝图的方式完成，UI逻辑这么简单的部分怎可能不行呢？

因为听说有公司在尝试，我之前自己也考虑了一下，但都是基于复杂指令式，确实有点麻烦（虽说再麻烦也麻烦不过行为树）。

MVVM

我一直对MVVM不太感冒，理由是就觉得它相比传统MVC的优化幅度有限。

但我却忽略了一点：MVVM虽然对于技术而言优化有限，但是面对非技术却不是这样。我们技术对于顺序指令，流程，赋值这些概念都非常熟悉，但是对非技术而言，这些东西都是陌生且难以接受的。

而MVVM呢？

MVVM的View部分要做的工作主要是这两点：

1.绑定某个组件的某个属性到到某个数据。

2.指定某个组件的某个事件执行某些指令。

这两个操作都是在控件面板上直接录入的，只是输入（或者选择）一个值。

尤其是1，本来以前就是要输入的，只是现在从固定值改成了一个变量。绑定最常见操作的是绑定文本框的text到一个数据，把内容显示出来。这种情况直接绑定通常不可行而需要用表达式（例如："数量："+{item.count}+"个"），也可能需要处理小数点截断（{item.count.toString("F2")}）,还可能会有一些数组下标，布尔运算。但这只是表达式和单层函数，学过数学都不难掌握。而如果稍微处理下词法联想（利用反射其实不难），则更加容易使用。

2需要添加事件监听，但一般都是按钮的onClick或者窗体的onCreate，具体的指令通常也只有一条，通常是“调用Model的方法”“打开窗口”“修改数据的某个值”。

这些虽然涉及到了编程的一些内容，但依然都是简单而且符合直觉的。

而MVVM仅通过以上两种设置就可以完成View方面的工作。

比如一个背包界面，就是窗体里有一个List组件。策划只需要设置List的数据项为"{DataCenter.items}"，然后在单个Cell的预制体的文本框，图标上设置数据项为"{data.count}"，"{data.icon}"，如果希望count为零的时候不显示数量文本框，则在文本框的visible属性上写"{data.count > 0}"。

需要排序？那么可以让技术提供排序方法，然后自己把数据项改为"{DataCenter.GetSortItems(1)}"。

需要筛选？那就再加个参数。

请注意，我并不是让策划完成所有的工作，而只是让他们完成View层的工作。像上面的数据排序，筛选，本来就不是View层的事情，而是Model层的事。而Model层依然还是技术负责的。

Model层还包括调用接口后产生的数据变化，比如使用道具产生的效果，金钱道具的变化，这些依然是程序员在做。而View这边要做的就是调用。如果产生了数据变化，则会通过绑定自然呈现到界面上。

如果需要用一个tab做不同类型道具的切换？那么可以创建一个Tabbar，数据项填好内容（这种固定数据直接填就是了），List的数据绑定改成"{DataCenter.GetFilterItems(filterTab.selectIndex)}"。

可以看到，到现在都还没VM什么事，因为只使用了全局数据。而如果不在乎View层和Model的直接耦合大部分情况也用不到VM，只有在数据不需要持久化的时候才会产生VM的需求，诸如竞技场临时刷出来的对战列表。这时候就需要在onCreate里调用一个接口，然后把接口获得的值指定到VM的一条属性上，然后再把这属性绑定到列表上。

但这个VM并不需要是一个类，直接在“窗体”上手动添加一条属性就是了，如果喜欢取成中文名也没事，反正除了这个View外没人知道它的存在。而这个东西和行为树的变量就是一回事，做过行为树的应当不难理解。

完整实现还需要一些细节，比如处理动画（数据变化的动画全依赖绑定不太现实，需要加入指令手动调用），states的实现，跨组件和窗口的VM，但都不困难，而且少见。

上面用的是文本表达式，也可以换成蓝图式连线，哪个更方便就不好说了。

拆分的必要性？

上面的做法其实是将以前UI程序的工作分成了两份（View和Model）,而以前确实都喜欢把这两部分混在一起按系统分工。

首先，这种分工本来就是不合理的，因为Model很容易对应多个View，如果按View派活，很容易导致每个人重复写Model部分的代码，除了浪费时间，修改时想同步也更加困难。为了避免重复就需要相互协调。既然这样，干嘛不把Model部分的工作拆成单独的工单呢？

在合理的逻辑分割下，Model的逻辑和具体UI基本没什么关系。比如上面说的道具排序筛选，这显然是一个必定要做的功能（而且代码可能就是从上个项目拷贝的），即使UE案子没出来，只要道具系统设计好了就可以开工。Model还有很大部分逻辑是服务器接口的调用逻辑，而调用完后，对Model内数据的修改也是和UI无关的固定逻辑，这些都可以在UE案子出现之前开工甚至完成。至少，可以并行。

而且，就我自己的经验，写这部分逻辑是非常快的，因为没有其他因素的干扰，且测试简单，我平常自己写UI都是把这部分和View分开写的。甚至于，理论上让服务端来写效率更高（因为连沟通都省了）。所以，即使是后来提的需求，把它现写出来也是比较快的，不耽误事，就和我们写行为树节点一样，不满足需求再加一个结点就是，根本不是事。

而如果View部分是策划来做的，在定好服务器接口后，技术的工作就可以立即结束了。后面无非是根据需求补充一些方法。技术这边都可以用自动单元测试确保正确性。后面的界面优化，和美术的沟通，最终测试都变成了策划的事情，这样技术的人力成本就会大幅降低。

并不只是将工作转嫁给策划

首先，其实就算仅仅是将工作转嫁给策划这样做都是值得的，因为两者的人工成本不同。一件事情如果谁都做可以，干嘛不让便宜的人做呢？即使这样的人不好招不好养，你给他涨到技术的工资还怕他不做吗？

这样做一个是减少了沟通环节。平常一个界面，相关的策划，美术，技术都必须了解整个案子才能工作。但技术假如只需要管Model层，他就不再需要了解整个案子了，只需要了解到服务端的程度就可以了。而后续的调整，修改，有非常大的概率是不用修改Model的，这些修改需要协调的人数就降低了。而且，在通常的工作中，策划和技术的沟通其实是最多的，而且还需要详细的流程文档，能够把技术从中拆出来，减少的可不止三分之一的量。

而且策划的原型设计部分本来就存在大量重复劳动。都是拉框填字，为啥不直接在成品里拉框填字呢？做完截个图放到文档里，美术再PS重新拉框填字，然后技术再拿着美术的图再来一遍拉框填字，这是何苦呢？美术重做一遍可以是为了设计效果，技术在来一遍（而且还不能复制文本）就是纯粹浪费时间了。如果策划一开始就是在引擎里搭建的界面，美术重新设计后，就可以调整而不是重做了。

而在这个设计原型的过程中顺便把逻辑实现了不更好吗？反正都要填文本就填个对的不成么？

当然，更重要的还是迭代过程的简化。后期你只是想改个文本都要写文档找技术改？迭代过程的简化就可以有更多的迭代次数，便能够得到更高的质量。

由策划负责UI并没有增加流程。拼UI的部分代替了原型设计部分，而根据美术要求和技术的跟进修改UI的部分则和策划本来做的验收部分合在了一起（自己验收自己），流程其实大幅减少了。

但这样做其实还有附加的作用。

有很多正确的事，想凭借人的自觉是难以实现的。比如说View和Model分离，即便是这种非常政治正确的事，真想贯彻推行其实不容易，只要他们还可以写到一起就会总有人写到一起。

所以，你把这部分内容分给策划，会让他们必须做分离。

这就和fgui的独立界面编辑器一样。虽然拼界面这事怎么看都不该技术做，但因为fgui技术压根不安装编辑器，策划也就只好自己做了。

技术现在连view都不管了，那拼界面这活技术就更不可能做了，这有助于让事情走上正轨。

以前三方各自重拼一次界面的模式实在太蠢了。