看到CSDN一直在更新(他喵的,改版后昨天还连个写博客的按钮都找不到),今天发现它在【创作中心】下面加了一个写博客的下拉TAG,我们独立开发者还有什么理由不努力
不是CSDN内部的人,貌似母公司集团也快干不下去了,屡次听到内部人员说清盘的消息
但重点不在不停更新(内容是很重要没错,但不是核心),其实所谓核心的CSDN早就做到不停服更新,比你牛逼的人还比你努力,所以也没法偷懒, 写些分享吧,虽然这些分享和某大厂的核心模块还差很远,但不积跬步,无以至千里。
2个截然不同的FSM,你选哪个??
有一个是很很简单的FSM,就像某博主或者书上写的FSM,某上市公司,知名工作室的出品,游戏也上线很久,很商业化的游戏的FSM,但很容易死循环,扩展麻烦
另一个是国外的FSM,经历多个版本依然稳健,可在多个平台使用,每个平台都有坑,学习曲线陡
国外的月亮到底是不是就比较圆??
UML图
直接是下面插件的机构分析图(应该是最好的手势插件了。。。)
状态机的重点不在状态Action,而核心在于状态“引擎”的维护
(其实大家一直滥用的协程coroutine也是基于状态机,所以你在协程上栽的跟斗就和所有用的不好,设计不好的状态机的问题一模一样)
有无办法避免问题
/// <summary>
/// Fires when state is updated, use this instead of Updated, which has been deprecated.
/// The gesture object has a CurrentTrackedTouches property where you can access the current touches.
/// </summary>
public event GestureRecognizerStateUpdatedDelegate StateUpdated;
protected virtual void StateChanged()
{
#pragma warning restore 0618
if (StateUpdated != null)
{
StateUpdated(this);
}
}
private void EndGesture()
{
state = GestureRecognizerState.Ended;
StateChanged();
}
很简单的逻辑,基本是个中国人都会。。。。。
欲避免踩坑,关键在于“不要改”,要做到不要改,首先,得抽象好,状态机,或者基础类都需要抽象(理论上如此)
但实际上是,问题总是改不完,也解决不完,解决不了问题,解决提出问题的人才是最好的方法
这也是很多团队,UML图用很好了,设计很好了,有架构“大佬”啦,结果代码还是写烂
总结是:
整已个状态机还是必须的,是一个必须的代码结构,但FSM还无法简化分享,主要是我一直用的2019.3,运行倒是正常
(运用ECS,自定义render pipline等,导致跨平台打包编译不过,也很卡)
这样的代码分享出来套用到自己的游戏或项目中就是灾难
之后我也会分享2019最新特性的项目
参考插件
如需学习状态机可参考Unity的插件