如题,在群里面已经讨论几次了。猫大和母哥的看法都是不要用状态机,并建议我多看看demo。
但是我现在还没有get到点,先把这个话题放到论坛。看看大家的意见。轻喷。
举个例子【在创角界面点击返回按钮】。
那么可能是返回选角界面(从选角界面点击创角),可能是返回登录界面(从新号登录进来直接创角)。
返回选角界面需要关闭创角界面,释放创角场景的美术资源。加载选角场景的美术资源,打开选角界面。
返回登录界面,需要关闭创角界面,释放创角场景的美术资源。打开选角界面。
如果按照现的方式,在OnClick或者事件响应中,需要处理以上逻辑,还需要在component记录是从哪儿来创角界面的。代码庞大,阅读性较差。
如果是状态机管理。只需要做一次状态切换。(并且一般状态机机制本身会记录从哪个状态切换而来)
创角状态的OnExit会负责释放创角美术资源,关闭创角界面
选角状态的OnEnter会负责加载选角美术资源,打开选角界面
登录状态的 OnEnter会负责打开登录界面
代码清晰,拆分得很细,而且复用性高。
例如,假设我是从GamePlay中返回登录,那么打开登录界面的这个操作亦是由登录状态的 OnEnter来处理。我不需要写第二次,只需要做状态切换即可。
然后,母哥和其他同学提到了用Scene即可。
那么问题来了:
如果想实现类似OOP框架中状态机对游戏主流程的管控, 在ET中是不是就是用CurrentScenesComponent来模拟状态机的状态?
目前看demo中的CurrentScenesComponent仅仅只是服务于游戏内地图。如果将其扩展到例如:
启动
热更新
登录
选角
创角
选角
加载
游戏中
….
这么多的Scene类型,分别管理自己业务的component,是否符合ET的设计思想?
然而我依然得到了否定的回答。 可能我还需要继续看demo来悟道吧。 问题先抛在这里。哪天我悟了,再来自问自答。