前段时间盛大的 英雄连ONLINE  封测，搞了个帐号，玩了一段时间。最近游戏里出现了一些利用交易BUG诈骗的事情，纷纷扰扰。联想到平时💮的工作，有一些想法，借此聊一聊做网络产品应该关注什𝓰么。

　　先看看游戏中出现的问题吧。

　　这是一个即时战略游戏，玩家角色可以购买或合成各种英雄，在游戏中召唤出来加入战斗，以提升自己的战斗力。所以，英雄，还有合成英雄的材料是价值的东西，并且可以通过游戏中的交易系统进行交易。
　　交易过程是这样的：玩家双方把自己的东西放在各自的交易栏里，互相查看确认后点“确认交易”，双方都确认后交易完成。其间如果一方确认，另一方更改了交易栏中的物品，则之前的确认状态会取消，需要重新点击确认。从这个过程我们了解到：玩家通过观察交易栏中的物品来确认交易是否可行；如果对方改变物品，我们仍然能选择是否继续交易，以避免偷换现象出现。从这个角度来看，交互设计上虽然简单，但是还是基本满足需求的。包括效率和安全。

　　但是现在出现的情况是：有些玩家在点击“确认交易”之后，自己的物品消失了，而对方交易栏中的物品并未交易给自己，这就是交易欺骗。盛大针对这个问题，很不负责任的解释为，是对方玩家换掉了交易物品🎉，而受骗方的玩家没有重新查看物品（空的交易栏？），就点了“确认交易”完成了交易，导致损失。

　　SD咬定点击确认发生了2次，并且把责任推给玩家，是很不负责任的短视行💖为，接着它就一厢情愿的发布了一个交易补丁：增加了一个确认流程，需要先锁定物品，然后再点确认，完成交易。增加一次点击，🌄通过交互行为来增加确认。

　　当时发布🌱的时候，我就跟朋友说，这不是一个能解决问题的方案，因为这是针对他们之前“玩家错误操作”的前提而做的改进，而他们对系统的BUG却不愿面🎀对。结果，果然晚上就又有被骗的事情发生。

　　试想， 如果他的交易系统的通讯分成两部分，1部分是玩家间的物品确认部分，1部分是完成交易的数据库操作部分。玩家间的确认是玩家的机器间通讯的，而交易确认的时候，是玩家分别与服务器通讯的，如果是这样设计的（其实很可能就是这样的）。那么问题就来了，玩家间的物品确认和数据库操作是不相关的。当恶意玩家给交易方发送虚假的物品数据包，包含了若干物品，而给数据库操作的时候，并不包括这些物品，那么就产生了漏洞。SD的数据包加密做的不够好，或者加密方式被泄露（不是第一次了）都会导致这样的结果很容易出现。
　　那么，为什么不是2个玩家的物品确认和交易数据操作都通过服务器端的通讯呢，一个很可能的解释就是：性能问题。这是在网络🦋产品的开发中最常听到的理由。

　　以上的可能性仅是假设，再来看看我们做产品设计的时候的一些问题。

　　1、产品设计中什么才是最重要的？

　　UCD设计理念被说了1千次1万次，说的都烂了，最后往往只被用来做擦鞋布。有句话用在目前所谓的UCD设计很恰当：正义！多少罪恶正假汝之名而行！我们做任何东西都要以用户为中心，但是真正去做的时候，UCD算个什么呢。为了商业目标，进行一些明显导致可用性问题的更改。为了减少技术难度，为了缩短工期，可以简化交互和视觉设计。为了性能问题，可以砍掉设计内容。上面那种假设，其实就是一个技术架构师，和产品经理，对用户的财产安全没有明确的概念𓃲而导致的。而在另🐼外一些时候，UCD却被堂而皇之的被用来做挡箭牌和杀手锏，大吹特吹。一字鄙之，浮躁。

　　2、视觉和交互在产品中起到什么样的作用？

　　很多时候测试或者使用中遇到问题了，那么，视觉，你这里这里这样这样改下，交互，你那里那里那样那样改下。
　　请问你了解过问题的本质和核心吗。
　　在上文的情形中，某领导对游戏设计的交互说，你这个确认太简单了，很多人不小心就交易错了，赶紧加个确认。
　　交互于是加了，然后视觉、前端、开发加班忙完了。然后呢
　　问题还是存在。
　　很多时候只看到表面，给交互和视觉太多的责任，而对技术等其他层面却宽松的多。
　　架构没做好就是架构没做好，规划没做好就是规划没做好。
　　交互和设计能在你的烂规划上做成好规划的结果来吗？

　　3、短期利益与长期利益，用什么样的态度面对问题

　　另一种可能，SD后来已经知道是系统有漏洞了，但是不负责任的公告已经发出去了，客服说辞已经一口咬定了，产品已经在测试准备上线了，不能有负面的东西出来！
　　好吧，那么首先自己对自己说，恩，这个问题就是玩家问题，然后对所有人说这个问题就是玩家问题。
　　然后这漏洞就一直存在。
　　然后呢。这产品就从半死不活到死为止。
　　就是这样。
　　你做产品的时候没面对过这样的选择吗
　　为什么不说明真实的情况，告诉玩家不要再交易了，并且关闭交易，清除坏玩家，监控并分析异常行为？
　　这才是负责任的产品，负责任的公司，负责任的态度解决问题。

　　最后想说一下，盛大在这个事情的处理态度和策略，都非常的不负责、不专业、不上路子。

　　原文：//www.blueben.cn/index.php/archives/813