几/何/冰/川

我们在上一篇文章中提到了 MVC（Model-View-Controller）设计模式。在 Unity 中，MVC 模式通常体现在将游戏数据（M）和表现（V）分开，而 C 则负责管理输入和调度更新，在代码中更新 UI 的状态。 在这篇文章中，我将介绍另一种设计模式 MVVM（Model - View - ViewModel）。MVVM 是一种将用户界面与业务逻辑分离的设计模式，与 MVC 模式相比，MVVM 模式在 MVC 的基础上进一步解耦了 View 和 Model，取代 Controller 的 ViewModel 层（VM 层）作为中介层提供了数据绑定的能力，使 View 层可以自动同步 ViewModel 中的数据。 维度 MVC MVVM 核心思想 关注点分离 数据驱动视图 数据流向 单向（View → Controller → Model） 双向（View ↔ ViewModel ↔ Model） 耦合度 中（V 层与 C 层直接交互） 低（通过数据绑定解耦） 适用场景 简单UI交互 复杂数据驱动型UI Unity实现 需要手动更新视图 自 ...

MVC 模式的全称是 Model-View-Controller，即模型-视图-控制器。严格来说，MVC并不是GoF（四人帮）归纳出的一种独立设计模式，而是一种架构模式。这种模式常用于用户图形界面的图形 / 数据 / 逻辑分离，因此在游戏开发领域中常被用于 UI 相关的功能上。那么，什么是 M / V / C 呢？ M（模型） 模型层（M 层）负责存放数据和业务逻辑。 V（视图） 视图层（V 层）负责展示用户图形界面，是用户与之直接交互的元素。 C（控制器） 控制层（C 层）负责响应用户输入或事件，更新 M 的数据并让 V 展示的界面刷新。 使用 MVC 模式的目的是将 M 和 V 的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据可以分别用柱状图、饼图来表示。C 存在的目的则是确保 M 和 V 的同步，一旦 M 改变，V 应该同步更新。 Unity中的MVC 以上述框架为例，假设我们要做一个点击按钮更新金币数量（即点击一次金币数 +1 ）和清空当前金币的功能： Model（M） M 层是纯数据类，不继承 Monobehavior，主要作用是存放所有数据 ...

前言 这次学校工作室的考核任务（是的还是考核）是复刻一款游戏，给出了三个游戏选择（饥荒/杀戮尖塔/元气骑士）不过我都没有玩过，于是想了想我决定做一个简陋版的明日方舟。之前在b站看到过大佬仅耗时48小时开发出明日方舟的战斗界面，感觉好像也不会很难吧……就去试了！ 但是做了之后才发现其实是很有挑战性的一次任务。先上两张游戏界面的图（p1p2）！ 制作思路 场景： 最开始我的想法包括了五个场景：两个关卡、选择干员的界面、看板界面和登录起始界面（包括一些本地化的内容，工作量挺大的）。后来由于时间不够了就砍成了登录起始界面和一个关卡。 干员：2D骨骼/Trail Renderer 选择什么干员来演示比较合适呢？方舟并没有公开模型，如果要获取对应的gif会比较麻烦，而自己画角色好像也很麻烦。 纠结了半天我决定画三个自己的原创角色，并使用2D骨骼动画制作了相关的站立、战斗的动画（对2D骨骼感兴趣的同学可以在b站上找Michael老师的系列教程参考学习） 在干员战斗的时候你会注意到一些秘制特效，这是用Unity自带的组件Trail Renderer做的。这个组件很强大，如果加上一点代码能得到非常酷 ...

最近一款名叫“合成大西瓜”的游戏风靡空间，大家在真香之后都笑称自己为“西瓜人”，随后各种恶搞大西瓜的趣图、大西瓜bot更是接踵而至，甚至诞生了“合成大西瓜护肝版”、“合成小葡萄”、“合成大国家”等一系列衍生体…本文将主要探讨如何用Unity做一个“合成大西瓜”。 素材搜集 素材，或者说贴图展现了水果们的样貌。在这里如果把贴图替换成其他元素，比如说香蕉啦、波兰球啦一类的我们就能得到合成大国家等等的恶搞游戏。 这里为了简单（其实是我不会画）表现一下水果，笔者画了几个球，如图： 从左到右分别表示的是葡萄、小番茄、橘子、柠檬、猕猴桃、西红柿、半个西瓜和西瓜。游戏规则是两个等级相同的水果可以合成更高一级的水果，合成出西瓜就算获得游戏胜利。 这里在合成路线上省略了椰子、土豆等中间部分的水果，因为道理是一样的嘛就不画了（说到底还是因为懒惰 UI 笔者简单设计了一个UI，如图： 可以看到这个UI主要由三个部分组成。第一个部分是顶端的白色图片，这张图片将用于显示下一个出现的水果的图案；第二部分是左上角的分数，用来统计玩家通过合成获得的分数；第三部分则是左部、右部和底端的边界，都加上了碰撞器，防止水果 ...