在游戏开发过程中，开发团队会收到各方的建议。 当然，提出这些建议的人大多数都是出于好意，他们都认为这些建议对正在开发的游戏有帮助。 然而，开发团队必须小心，不要认为纳入所有建议对于游戏来说就是最好的事情。 暂且不论这些建议是否都适合纳入，有时会存在相互矛盾的建议。 如果要全面接受所有建议，很容易陷入父子骑驴的尴尬境地。
在我之前负责的手游项目中，有这样一个例子：
我们的案例是一款市面上被称为“卡牌游戏”的游戏。 在这样的游戏中，玩家需要开发相当多的卡牌来玩游戏。 我们参考了市面上很多类似的游戏，最终设计了一个类似于《我叫MT》游戏的显示方式的卡牌列表：
【卡牌列表我叫MT】
在这样的界面中，会列出玩家持有的牌。 列表中会显示该卡的基本信息。 玩家可以通过点击列表中的任意一张卡牌来查看更详细、更完整的信息。 在此类游戏中，由于卡牌信息通常较多，详细信息有时会跨越一页以上。 玩家可以通过操作来切换显示其他选项卡的信息。
返回卡列表。 一般来说2d游戏素材，这类游戏中玩家所持有的牌数量都不会太少。 游戏的设计中考虑了滚动性能和玩家操作的便利性。 大多数游戏都会将卡牌列表分成几页。 设置某个数字作为页面显示数量的上限。 在我们当时的项目中，我们将这个数量设置为20。但是，这样的设置，随着玩家手中的牌数量增加，开始出现这样的建议：
“每页二十张卡片太少了。”
“当卡片太多时，页面就会被剪切太多次。”
这个问题立即在下次会议上提出。 会议期间，原设计肯定得到了支持。 这种显示方式虽然每页显示的卡片较少，但可以显示更多的信息。 对于用户来说，无需输入每张卡的详细信息，就可以获取一些重要信息。 信息。 当然，也有反对的声音。 他们建议将热门游戏《智龙迷城》的卡牌列表显示模式改为这样：
【龙之谜卡牌列表】
《龙之谜》游戏中的卡牌列表只显示简单的头像，而卡牌的简单信息则利用轮播的方式以最简单的方式依次显示在卡牌头像上。 这种设计每行至少可以显示五到六个头像手机游戏开发，所以在原来20列的显示行数的基础上，一页上可以显示100到120张卡片。 这种设计也被很多游戏所借鉴，很多热门游戏也采用了这种显示方式。
经过一番讨论，我们决定将项目的卡牌列表改为类似《Dragon Puzzle》的显示模式。 规划人员花了一些时间编写设计文档，美工人员根据这个需求制作了相关的材质组件，然后程序根据规划文档使用这些组件创建了想要的显示效果。 花了一段时间，将卡牌列表从原来的栏目格式修改为头像格式。
头像版本的优点是可以在单页上显示更多的卡片手机游戏开发，但缺点是由于头像的面积比列表小很多，所以上面能显示的信息较少。 数据采用轮播格式，这意味着用户必须盯着手机屏幕，等待轮到他们想要看到的信息。 果然，改成这个版本后程序开发，我们又收到了这样的建议：
“信息轮播的速度太慢了，需要很长时间。”
“还没来得及看，轮播已经转到下一条信息了，我得再等一轮才能再次出现。”
“如果想看卡信息，就得进去一一读取，非常麻烦。”
说实话，当我们决定将卡片列表从原来的栏目格式改为头像格式时，这些建议是我们预料到的。 因为头像式的显示方式本来就有这些缺点，所以我选择改成这样只是因为这样可以解决单页显示卡片太少的问题。
本来我应该理性地告诉提出这些建议的人，这些问题对于分身卡牌列表来说是不可避免的。 虽然选择分栏格式可以解决这些问题，但是单页显示的卡片数量太少。 ，所以我们选择了这种方法。
但当时我们并不知道发生了什么，但我们却像鬼一样做出了另一个决定。 我们决定在头像卡牌列表中添加点击显示简要信息/长按显示详细卡牌信息的设计。 这个决定让我们在这项工作上花费了大量的时间。 原本操作起来比较简单的卡牌列表界面，在这样的设计下变得复杂了很多。
最后，在内部测试的时候，我们终于醒悟了，发现我们根本不应该做这样的设计。 游戏设计时，很难让所有人都满意。 任何设计都会被一些人认为可以，而另一些人则认为不行。 如果你硬要满足每个人的需求，那你就是自找麻烦。 所以我们去掉了点击/长按的设计，留下了简单的头像式列表和点击头像后显示详细信息的设计。
