游戏开发中,客户端与策划同学的设计需求约定

 

不好的需求设计,是程序员总是说 “实现不了” 和 “祭出菜刀” 的原因之一。

不好的需求设计,破坏程序整体架构,让程序员在没做之前就联想到即将到来的大量重构,感觉蛋疼头大,从内心深处反感抵触。

不好的需求设计,增加劳动量,让程序员996,干一堆没技术含量的杂活。

不好的需求设计,带来 “以后还要改” 的可能性。(程序经常会抱怨策划同学总是不提前多思考;而策划同学也确实总想着 “先这么做,做出来看看效果,不行再改”,不珍惜程序的劳动成果)。

-------------------------------------------------------------------------------------------

NRatel设想一下,

如果程序(客户端)能够为策划提出一些设计准则,一条一条明文地列出来,双方在早期达成共识,

就能有效地避免扯皮事件的发生。

-------------------------------------------------------------------------------------------

1、约定提前设计通用UE。

         问题:UE风格杂乱、操作方式杂乱。总是因一些细微差别,让界面难以复用。浪费大量时间和精力。

         推荐:设计通用的普通确认框(单按钮、双按钮、是否带叉关闭、是否点击空白处关闭)、设计通用的购买/消耗资源确认框(显示资源数量)、设计通用的奖励确认框(要考虑超多奖励的情况)、设计通用的Toast提示、设计通用的奖励Toast、设计通用的规则说明弹窗、设计通用的道具框。。等等

2、约定时间显示格式。

         问题:格式不统一,表现在分隔符不同、精度不同。如:时而 YY年MM月DD日,时而 YY.MM.DD,时而YY/MM/DD,时而 MM月DD日 HH:MM:SS。

         推荐:严格统一分隔符(有多语言需求的避免使用年月日时分秒)、固定1~3种精度供选择

3、约定倒计时的显示格式(常见于活动)。

         问题:格式不统一,表现在分隔符不同、时间较大时表现不同。如:时而 HHHHH:MM:SS,时而 MM月DD日HH时MM分SS秒。

         推荐:严格统一分隔符(有多语言需求的避免使用年月日时分秒)、使用 HHHHH:MM:SS 的方式最简洁方便,使用自动切换显示当前前2~3位精度的方式最优雅(如 0年1月3天15时23分39秒,显示为 "3天15小时23分",当倒计时至 0年0月0天10时20分30秒,显示为 "10小时20分30秒")。

 

 

猜你喜欢

转载自blog.csdn.net/NRatel/article/details/89000835
0条评论
添加一条新回复