• 第六次作业


    1.游戏后端设计?

    1、引导的发起

      后端关注的是引导,因此,后端只要各种事件触发一个引导,把这个引导ID发给客户端,就完成了引导的发起。

      客户端收到服务端发的引导ID,就会获取这个ID对应的步骤列表。然后播放这些步骤,等待玩家交互完成。

      2、引导的结束

      当前端执行完引导步骤时,把引导ID通过一个引导完成的协议发送给客户端,这样好吗?我觉得这种做法是不安全的。

      如果是通过客户端来通知服务端引导完成,会出现2种情况:

      以强化装备为例子

      情况1:先请求强化装备,再请求引导完成。

      可能在你请求强化装备的时候,这个请求发出去了。但是突然断线了,引导的请求没发出。这时候。下次上线,他还是会让你引导。但是,你可能已经没了强化材料。玩家卡死。

      情况2:先请求引导完成,再请求强化装备。

      请求引导完成发出,断线,请求强化没发出。然后玩家下次上线,不会再经历引导。

      或许聪明的你会想到可以把引导ID带在强化装备的包里面,一次请求完成。这样是可以解决上面两种情况。

      但是,这样,相当于,就把强化装备和引导耦合了。而且,以后可能有升级技能的引导,那么你升级技能的协议也要带上引导ID。这样设计无疑不是最好滴。

      因此,通过客户端来通知服务端引导完成是不靠谱的。应该由服务端自己的内部事件来触发。

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

      这时候服务器就可以判断当前是否有强化装备的引导。有的话判断是否满足完成条件。满足就完成引导。

  • 相关阅读:
    Linux
    数据库
    第一篇文章
    解决VMware虚拟机Ubuntu 无法上网问题
    mybatis之sql标签与include标签
    第一个只出现一次的字符
    位运算 -- 只出现一次的的数字
    Oracle递归 start with...connect by...prior
    MyBatis中#{ }和${ }的区别
    表的转置 行转列: DECODE(Oracle) 和 CASE WHEN 的异同点
  • 原文地址:https://www.cnblogs.com/5xxx/p/5376516.html
Copyright © 2020-2023  润新知