感觉这个问题挺好玩的，虽然我不是游戏行业人员，但我是个程序员，所以我对这个问题也挺感兴趣的。我觉得似乎很多策划承担了太多的东西，是因为公司人少分工太粗么?我没恶意的哈 希望你们都能轻松点
我从我的角度来分析一下这个问题 当然肯定会有很多遗漏 这是必然的
只考虑单电梯情况
需求提出:
实际情况就是某客户提出我这栋楼需要一个电梯 满足楼内各种人员上下楼需求
游戏的角度就是策划提出在这里放个电梯 满足玩家上下楼需求
需求分析:
这个需求虽然很空泛 但是电梯的功能毕竟很简单也很明确 楼有多少层 电梯内安装电话摄像头 电梯载重神马的细节这里不考虑 所以 可以跳过这步
概要设计:
不考虑硬件 只谈程序
1运行方向
a电梯空车待命静止时收到请求 如果是同层外部请求直接开门 如果是异层请求 缓冲3秒 3秒内如果没有增加其他请求 直接向请求楼层运行 如果3秒内增加了其他请求 根据当前所在楼层及各请求方向 按照最短运行距离原则决定方向 比如楼共20层 现在停靠在15楼 10楼先按了一个向下请求 接着3秒缓冲时间内17楼按了一个向上19楼按了一个向上 显然先向上运行较好 这样一个初始的运行方向就出来了 至于那个最短运行距离怎么去预估显然是详细设计里的
b电梯运行停靠时收到请求 在继续运行前保持原方向不变 关门命令发出后缓冲3秒(假设3秒时间够把门关上 这个3秒不用太纠结 只是一个假设的数字) 3秒内如果有同层外部同向请求直接开门 异向后面说 缓冲时间结束后如果原运行方向上的楼层有内部或者外部同向请求或者外部异向请求并且车没满 继续原方向运行 否则反向或者暂停待命
这里要注意一点 如果停靠时或者关门命令发出前请求队列已经空了那就回到a种待命状态了 先清除方向 然后以a的方式决定方向
c电梯运行时收到请求 这个对运行方向不会有影响 因为方向是在启动前决定的 但是对停靠有影响 比如现在5-6层之间向上运行 突然来了个6层停靠的请求 那肯定要先计算6层停靠位置能不能停的下来 我没这方面的知识 最短刹车距离有多远我不知道 反正够停就停不够停就当错过去直接加入请求队列就完事
2停靠
a内部请求停靠 如果请求停靠的楼层在运行的方向上就停 如果不在就等着掉头
b外部请求停靠 如果运行方向上有同向的外部请求那该层预计停靠 运行方向上有反向外部请求 按照xx原则进行优化 当然在停靠前如果已经满员则取消外部停靠请求 比如从1层向上运行的时候 5 6 8层外部都有向上的请求 结果到第五层上满了 那6层如果没有内部的停靠请求 自然就取消在6层停靠的计划 如果7层没的下8层也不用停
所谓的xx原则是指 比如下班时是以下楼为主
下楼人数较多 在电梯向上运行的过程中是否在运行方向上只有向下请求的楼层停靠 因为这个楼层可能先按的 但是可能因为上次往下时客满没停 那就按先后顺序在电梯向上运行的时候就给他停靠先上来占位 免的后面继续满员又被跳过去
详细设计:
我觉得策划该做的在上面已经结束
从这里开始就应该由程序去完成 程序设计师 程序架构师 高级程序员。。。不管你是写程序的框架还是写程序的逻辑 我觉得都是程序员 只要你写代码你就是程序员 这个程序员指的是角色而不是职能或者职位 怎么去设计代码结构 把上面串出一个完整的逻辑 显然由专业的程序员来完成更合适 由策划去完成 那逻辑大部分情况下肯定很臃肿 待命情况下同时多个请求是先往下运行还是先往上运行更节省 我想没有几个策划能写出这个算法逻辑吧 还有那个运行方向上的反向外部请求是否停靠的问题 这个是可以优化的(别说电梯不处理 我之前所在的地方就实际存在这种停靠方式) 但也不是策划擅长的东西 如果策划要在这上面花时间 我觉得你们的程序真的可以走人了
最直观的例子就是自动寻路了 策划顶多告诉程序以最短或者最优路径行走 遇到河是绕过去还是趟过去 遇到石头是绕过去还是跳过去 或者是只能走游戏里的路 我觉得这个问题策划只能考虑个大概不可能很全面 程序应该有一定的领悟能力 如果策划考虑的很详细 以策划为主 估计多半情况下都是人物走到河边才沿着河边去寻找桥然后绕过去 但是一个好的程序肯定是提前就绕过了障碍物 懂算法的策划应该没几个吧 而且你考虑的多了 我自然就按照你说的去做 有漏洞或者不完美这也是你的责任 因为我就是按照你说的做的 所以有些东西还不如推给程序 责任由他来担 那样他就会有一堆疑问来问你 考虑不详细也是他的问题 你还可以挑他刺 这代码写的真垃圾
我从我的角度来分析一下这个问题 当然肯定会有很多遗漏 这是必然的
只考虑单电梯情况
需求提出:
实际情况就是某客户提出我这栋楼需要一个电梯 满足楼内各种人员上下楼需求
游戏的角度就是策划提出在这里放个电梯 满足玩家上下楼需求
需求分析:
这个需求虽然很空泛 但是电梯的功能毕竟很简单也很明确 楼有多少层 电梯内安装电话摄像头 电梯载重神马的细节这里不考虑 所以 可以跳过这步
概要设计:
不考虑硬件 只谈程序
1运行方向
a电梯空车待命静止时收到请求 如果是同层外部请求直接开门 如果是异层请求 缓冲3秒 3秒内如果没有增加其他请求 直接向请求楼层运行 如果3秒内增加了其他请求 根据当前所在楼层及各请求方向 按照最短运行距离原则决定方向 比如楼共20层 现在停靠在15楼 10楼先按了一个向下请求 接着3秒缓冲时间内17楼按了一个向上19楼按了一个向上 显然先向上运行较好 这样一个初始的运行方向就出来了 至于那个最短运行距离怎么去预估显然是详细设计里的
b电梯运行停靠时收到请求 在继续运行前保持原方向不变 关门命令发出后缓冲3秒(假设3秒时间够把门关上 这个3秒不用太纠结 只是一个假设的数字) 3秒内如果有同层外部同向请求直接开门 异向后面说 缓冲时间结束后如果原运行方向上的楼层有内部或者外部同向请求或者外部异向请求并且车没满 继续原方向运行 否则反向或者暂停待命
这里要注意一点 如果停靠时或者关门命令发出前请求队列已经空了那就回到a种待命状态了 先清除方向 然后以a的方式决定方向
c电梯运行时收到请求 这个对运行方向不会有影响 因为方向是在启动前决定的 但是对停靠有影响 比如现在5-6层之间向上运行 突然来了个6层停靠的请求 那肯定要先计算6层停靠位置能不能停的下来 我没这方面的知识 最短刹车距离有多远我不知道 反正够停就停不够停就当错过去直接加入请求队列就完事
2停靠
a内部请求停靠 如果请求停靠的楼层在运行的方向上就停 如果不在就等着掉头
b外部请求停靠 如果运行方向上有同向的外部请求那该层预计停靠 运行方向上有反向外部请求 按照xx原则进行优化 当然在停靠前如果已经满员则取消外部停靠请求 比如从1层向上运行的时候 5 6 8层外部都有向上的请求 结果到第五层上满了 那6层如果没有内部的停靠请求 自然就取消在6层停靠的计划 如果7层没的下8层也不用停
所谓的xx原则是指 比如下班时是以下楼为主
下楼人数较多 在电梯向上运行的过程中是否在运行方向上只有向下请求的楼层停靠 因为这个楼层可能先按的 但是可能因为上次往下时客满没停 那就按先后顺序在电梯向上运行的时候就给他停靠先上来占位 免的后面继续满员又被跳过去
详细设计:
我觉得策划该做的在上面已经结束
从这里开始就应该由程序去完成 程序设计师 程序架构师 高级程序员。。。不管你是写程序的框架还是写程序的逻辑 我觉得都是程序员 只要你写代码你就是程序员 这个程序员指的是角色而不是职能或者职位 怎么去设计代码结构 把上面串出一个完整的逻辑 显然由专业的程序员来完成更合适 由策划去完成 那逻辑大部分情况下肯定很臃肿 待命情况下同时多个请求是先往下运行还是先往上运行更节省 我想没有几个策划能写出这个算法逻辑吧 还有那个运行方向上的反向外部请求是否停靠的问题 这个是可以优化的(别说电梯不处理 我之前所在的地方就实际存在这种停靠方式) 但也不是策划擅长的东西 如果策划要在这上面花时间 我觉得你们的程序真的可以走人了
最直观的例子就是自动寻路了 策划顶多告诉程序以最短或者最优路径行走 遇到河是绕过去还是趟过去 遇到石头是绕过去还是跳过去 或者是只能走游戏里的路 我觉得这个问题策划只能考虑个大概不可能很全面 程序应该有一定的领悟能力 如果策划考虑的很详细 以策划为主 估计多半情况下都是人物走到河边才沿着河边去寻找桥然后绕过去 但是一个好的程序肯定是提前就绕过了障碍物 懂算法的策划应该没几个吧 而且你考虑的多了 我自然就按照你说的去做 有漏洞或者不完美这也是你的责任 因为我就是按照你说的做的 所以有些东西还不如推给程序 责任由他来担 那样他就会有一堆疑问来问你 考虑不详细也是他的问题 你还可以挑他刺 这代码写的真垃圾
