游戏新手引导前后端代码设计2个要点

初学者引导好多游戏都是有。

但是有些做出来的不是那样称心。

有时引导卡住，又找不到难题。

其实很多时候与设计的制度相关。

文中假定引导是一种强制性引导。

一个引导由许多步骤(比如要游戏玩家点哪里，点哪里，这都是一个个步骤)构成。

1、引导的发起后面关心的是引导，因而，后面只需各种各样事件触发一个引导，将这个引导ID发送给客户端，就完成引导的发起。

客户端接到服务端发出来的引导ID，便会获得这一ID相对应的步骤目录。

随后播放视频这种步骤，等候游戏玩家互动进行。

2、引导的完毕现阶段端执行完引导步骤时，把引导ID通过一个引导完成协议书发给客户端，这样好吗?我觉得这种做法就是不安全的。

假如是根据客户端来通告服务端引导进行，会有2种情况：以强化装备为例状况1：先请求强化装备，再请求引导进行。

可能会在你请求强化装备时，这一请求发出去了。

可是忽然断开了，引导的请求没传出。

此刻。

下一次发布，他还是会使你引导。

可是，你可能会已经没了强化材料。

游戏玩家卡住。

状况2：先请求引导进行，再请求强化装备。

请求引导进行传出，断开，请求加强没传出。

随后游戏玩家下一次发布，再也不会亲身经历引导。

也许聪明的你都会想到能把引导ID带在强化装备的包里边，一次请求进行。

这样也是能解决上边这两种情况。

可是，那样，等同于，把强化装备和引导藕合了。

并且，可能以后有更新技能引导，或许你更新技能协议书也需要携带引导ID。

那样设计方案无疑不是最好是滴。

因而，根据客户端来通告服务端引导进行是不靠谱的。

需要由服务端自已的内部结构事情来开启。

比如一个强化装备的引导，客户端最终一定会请求服务端要强化装备。

此刻网络服务器就可以确定现阶段是否存在强化装备的引导。

如果有的话确定是否达到进行标准。

达到就完成了引导。