Jan 152014
 

任天堂也许是我有记忆以来所知道的第一家游戏公司。

小学的时候,它是游戏机的代名词。那时候放假最大的欢乐就是和一帮小朋友一起把某个游戏玩一天(好吧,或者说被游戏玩一天……)。当时游戏很简陋,象素的画面,还没有存盘这个概念,只有“暂停”,而且刚开始还没有作弊,或者说各种“加强版”的出现,所以每个游戏玩起来都觉得难度很高,能完整通关的游戏少了又少,但还依旧乐此不疲。朋友间的对话就是如何打boss,甚至一些天马行空的所谓“隐藏” 元素也在坊间被各种传播着。回想起来,那时候的游戏真的很纯粹。

20年过去了,所幸的是这家当年崇拜的公司依旧还存在着,虽然活的并不能说十分的好,但至少也还能活下去。无聊查了下它的家底,结果发现任天堂是1889年创立的,风风雨雨已经100多年了,经历1战2战的摧残依旧屹立不倒,从这个角度它也是一家值得让人尊敬的公司。这家百年老店经历了多次转型,从传统纸牌到后来的电子游戏机,到家用终端,便携终端,虽然不是每次转型都能一帆风顺,但也跌跌碰碰走了100多年,实属不易。近几年的任天堂也是十分萎靡不振,股价跌到近10年的最低位,希望它能挺过来。但是,即使在家用终端一蹶不振的情况下,任天堂的游戏理念一直没变:做有诚意的游戏。

日本人很固执是地球人都知道的,所以做游戏也一样,一根筋,他的理念和苹果如出一辙:端到端的体验。绝大部分任天堂出的游戏都是精品,玛丽奥,塞尔达等等。每一代都堪称经典,也是成为很多人购买他们主机很大的一个原因。当然,在手机移动平台如此蓬勃的今天,任天堂依旧坚持只为自己的平台出品游戏是很受诟病的,然而“端到端交付”的概念在苹果得到成功之前,何尝不是被世人唾弃的呢?逆流而上的坚持有时候比顺势而为更难做到,也更值得尊敬。

反观中国游戏产业的发展,更多时候是功利过剩而耐心不足。几乎所有谈论游戏的人,关键词只有一个:盈利。为什么?也许是大环境导致国内现代人价值观只能通过经济价值来衡量,别无其他标准;也许是温饱问题不解决之前,谈理想谈包袱实在显得十分的苍白;也许金钱来的太容易,被人类的贪婪引导着走向更加的功利…… 总之,整个产业很少人为游戏的可玩性而保留着自己的坚持。更多的人选择去思考如何从个别“成功的模式”中进行复制,希望“复制”成功。

但是,我认为真正的成功,必须有自己的坚持。玛丽奥出现之前,没有如此有趣体验的关卡游戏;iPhone 出现之前,没有如此体验优雅的智能手机;Google 之前,没有如此顺畅准确的搜索引擎…… 几乎所有的产品出来之前,都被嘲笑过,都被踩得一文不值,但它们坚信自己是独一无二的,坚信路是对的。挺过来了,成功了,大家争相复制,却再也没有出现能够超越他们的产品。

有句网络名言:一直被模仿,从未被超越。很简单,却很实在。复制,可以出产品,但仅仅是保证了温饱,但不是成功的前提。必须走在时代的前面,必须比别人想得更多。总是回头看,看别人如何成功,最终只会是平庸。坚持,路必须是最难走的,但假如没有破釜沉舟的魄力和气概,成功真的就这么简单么?

最近,无意中又拿出了NDS,通关了一个3年前的游戏,当我看到最后的制作人员列表时候, 我震撼了。并不是我看见了多么牛逼的名字,而是他们把所有人的名字都放在里面, 足足播放了5分钟,并且不允许跳过。相比起通关的兴奋,反而这一个细节更触动了我。为什么?

首先,对制作人员非常尊重。只要是为游戏做出过任何贡献的人都会被记录,整个人员列表大到制作人, 小到助理无一遗漏。并且人物出场的时候是不允许跳过的,不得不说这绝对是影响玩家体验的,然而,这种坚持我想也只有一个非常有自信的制作团队才敢做。

其次,制作人员数量非常庞大,一个这样的“小”游戏,目测制作团队超过200人。日本游戏产业非常发达,导致日本市场比较封闭,许多大作都只是日本国内推出已经可以满足整个公司的发展需要。而由于市场已经充分竞争,所以各公司拼的就是只能是游戏质量。这么多人,只做一个单机“小游戏”,在国内是无法想象的。

再次,分工非常细,人员列表功能分组超过40个。由于如此精细的分工,让每个游戏的细节都能得到照顾,即使是玩家一般不注意的细节也是一丝不苟。游戏虽“小”,但绝对没有敷衍了事。

我想说的是,一个产品能否成功,并不是“不计成本的投入“就能够解决的,更多的是理念上的转变。选择一条团队认可的正确的方向,坚定不移的走下去,胜,则举杯相庆,败,则拼死相救。有人分析说,由于儒家思想的教育,中国人“恐惧失败”,所以做事畏手畏脚,往往事情还没开始,就已经开始想着自己的退路。没有自己的坚持,终将一事无成。

Nov 132013
 

上周听英雄三国介绍开发经验的时候,提到他们在开发C++ 程序时候的一个苦逼的情况就是debug 是通过打log、编译、重启的方式实现的。时序相关的bug 用这种方式可能是更容易发现问题,通常无可厚非,但在运营过程中,更多的时候我们都是通过gdb 实现调试和查bug的。那么gdb 最基本的原理是什么呢,一个老外写了一个很简易的debugger,并记录了一篇blog:

http://eli.thegreenplace.net/programs-and-code/how-debuggers-work/

从我的理解,gdb简单来说,就是通过一个系统调用 — ptrace 实现的。

debugger 作为父进程启动另一个进程(或者把自己attach 成为父进程),然后wait并期待接受子进程的SIGTRAP 信号。当信号发生的时候,父进程wait 退出,并检查是否子进程已退出,否则调用ptrace 得到子进程的各种信息。

ptrace 的第一个参数决定了debugger 可以得到的进程信息,可以发现 linux 提供的可检测的进程数据比较多,包括了查看TEXT 区、单步调试、查看寄存器、发送信号、查看用户态内存等等,基本上涵盖了我们日常debug 所需要的信息。

足够nb 的同学完全可以使用这个系统接口写一个自己的debugger 来。

Nov 132013
 

AI重构基本结束了,力所能及的可以改的已经改完,剩下的是代码的一些整理和优化,整体逻辑没有太多可以再动。

有几点记录如下:

  • 效果比功能更难搞。功能其实在1,2周前已经基本完成,但为了让客户端表现上更加顺滑,打磨花的时间几乎等于开发时间,这是有点在我的计划之外了,而且当前效果依然不是十分满意。打磨这个事情,是长期的了。
  • 异常分支考虑不周。AI 一放到外服,发现巨多Error,就是因为异常情况太多,没有考虑周全。例如entity 可能不存在场景中(佣兵),怪物被玩家搞到一些很猥琐的角落根本找不到位置可以走动,等等。一些特殊的情况在实现和自测的过程中很难考虑到,因此改起来也比较被动。
  • 需求总是超出意料。有些需求是在实现功能的时候没有考虑到的,例如Explore 不能怪物刚出生的时候就stand, 否则有点呆;召唤物又不能闲逛的太频繁,否则先得过于“好动”,因为它的速度非常快;追逐完了的闲逛也不能马上停下来,否则容易瞬移等等。这些也是很难在实现的过程中考虑到。某种程度上是第一点的一个延续。

后续要做的事情其实还有没实现的,例如策划想佣兵能够比玩家跑得更前面,这其实已经超出了现有AI 的范畴了,已经有预判的味道。现有的AI 只是能够根据某个条件作出反应,而无法做到预测,需要真的做到”智能”,AI 要走的路还非常的长。另外,部分战斗相关和佣兵相关的逻辑是应该剥离出来的,而这点依然还在排期当中,看8月份找个时间把它也改掉,那么AI 才可以说是改的七七八八,希望改完后架构能更清晰一些,为性能也做点贡献吧。

Nov 132013
 

走路模块的重构基本进入尾声,统计了一下代码,瘦身了一些,原有1583 行代码, 重构后500多行(另有400 行逻辑转移到独立的MoveEx组件)

过程中有几点想法,记录如下:

  • 计划赶不上变化。AI 的需求从来都是言传身教的,没有一个系统的文档来描述,我们需要怎样的AI,一直都是拍个脑袋,AI就实现。于是乎,无可避免的插入了很多冗余的代码,复杂度陡增。当需求沉淀下来之后,回头再看代码,其实很多都是废的,10个参数,也许策划最终会改变的只有1,2个,甚至乎大部分怪物都是不改的,直接copy,而代码中为此而做的兼容几乎就没有任何意义,还不如写死在代码中,对策划不可见。
  • 优先功能。由于一开始设计的时候,在没有数据的情况下考虑了一些非必要的性能优化,希望提前减少运算量,例如预先算好explore的路径,反而把代码搞复杂了。因为其实预先算好并没有太多的好处,最极端的情况是,算好了完整的路径,但刚算好,玩家来了,那么这所有的路径都是无效的, 要全部丢弃。看似是提前运算带来好处,但实际上是冗余的运算,聚集的运算反而导致压力更高。性能的提升永远应该基于数据,没有数据支持的性能优化,都只是漫无目的的大海捞针,做无用功而已。
  • 没必要的继承情愿不继承。为了继承ActionChase,各种子类重载父类的接口来实现自己的功能,这种无谓的继承,导致代码非常难看懂,因为不知道这个接口什么时候会被调用,而在看父类的时候,又不知道哪个接口会被重载掉而改变行为。这种无谓的继承关系,还不如copy 来的舒服。所以多用委托,少用继承确实是金石良言。
Nov 132013
 

AI 系统的最初的定位可能就是能控制怪物 做出一系列的行为。而随着产品的发展,最初的定位也许有所改变,而且在功能不断膨胀的过程中,初始的设计已经无法满足后续功能扩展的需求,需要重构。

而重构的方向我思考了一下,主要有下面几点:

1. BT 行为树定位更清晰。

行为树可以理解成有限状态机的一个升级版,主要职责是决定怪物当前该做的行为。而从我的理解来说,我们当前的AI模块的责任有点重,npc和怪物的所有行为都希望通过AI 来解决,包括战斗内战斗外,这就导致了AI 系统越来越臃肿,而且千丝万缕,很纠结。根据设计模式单一职责原则:不要存在多于一个导致类变更的原因。而我们AI模块交互的模块很多,例如战斗,剧情等, 这样就导致了AI的状态不可控。

于是我计划是把 AI 仅作为决策的判断者,真正的逻辑是由其他模块完成,例如行走,战斗等。 让AI 这层变得尽可能的薄,最终只保留条件和逻辑的判断。

2. 行走模块剥离。

这是上一点的延续和实现,现在AI 涉及走路的代码有1000的多行CPP 代码,状态维护也是在AI 内部, 所以假如出现问题,是一件很头疼的事情。根据运营情况来说,这块也是bug的重灾区,多次AI 导致的crash 都是出现在这个模块中。除了一些低级的内存管理错误之外,最大的问题应该是在于状态维护,当前走动过程中被中断之后的处理,寻路信息出错时候的处理,稍有不慎就是一个坑。而且由于剧情需要用到npc 走路,因此AI 破了个口,让剧情调用,这也引发了不少的问题。这个经验也告诉我们, 这种hack 方式的 功能实现可免则免,bug的温床。

3. 召唤物佣兵AI剥离

AI代码为了佣兵和召唤物做了许多的折中,多处都是判断是否有主人,是则XXX, 否则OOO, 单纯从面向对象的角度看,也是不雅的,而且参考第一条,这块也是需要改的。选择目标,是否进入战斗,释放什么技能,这些为了佣兵实现的功能都应该归入佣兵模块,由佣兵模块决定。开放封闭原则,对于外部模块的修改,对于AI来说应该是封闭的,而现在由于佣兵的改动,即要改变AI代码的情况是必须改变的。

AI 的水很深,暂时想到这么几点,后面会实践起来,做比说重要,能力有限,尽力而为。

Nov 132013
 

Clash of Clan, 从去年7月份推出以来,一直占据消费榜前十位置,算是IOS上游戏的又一个奇迹。一个产品的成功,因素很多,天时地利人和,游戏玩法设计不想去分析太多,网上很多,这里想从技术的角度去分析一下这个游戏。条件有限,仅能从黑盒的角度去猜想它。

先从底层开始,对于网络,我在游戏时注意到了几个现象:

  1. 要进入游戏后, 对网络连接并不是非常敏感,失去网络不会提示。
  2. 偶然会有“out of sync" 的提示
  3. 偶然会回档

从这几点来看,网络模块不是使用的稳定的长连接。由于手机的特殊性,手游的网络质量是无法保证的,假如使用tcp 连接,将会使游戏在一些网络不好的情况下体验非常差,例如经常出现需要等待连接恢复等异常情况,那么对用户的体验来说就是致命的。而且,从玩法设计上,COC 的体验更偏向单机化,建筑和升级等都是完全的个人行为,玩家之间的直接交互仅限于clan 内。网络对核心的玩法并没有非常直接的影响,这也就决定了它必须把网络问题对玩家的影响减到最小。他们选择了短连接(或者是可靠的UDP)。

而从游戏整体的逻辑驱动来看,我认为它分为了2部分,城市建设部分是事件驱动,而战斗部分则是基于帧驱动的。例如上面提到的第二点就非常明显的暴露了他是需要客户端和服务端的时间是尽可能同步的,但是为了不依赖网络,他们也做了一些取舍。因为没有玩家间的强交互,也不需要保证玩家间的公平性,它并不是类似War3 那种多人RTS 常用的严格帧同步,在下面一段我会阐述我的理由。因为平时在自己城里面的逻辑是完全玩家个人行为,类似单机,不需要帧同步,仅仅是事件驱动,以致客户端的修改“尽可能”到达服务端即可。这里说的是”尽可能“,因为我碰到过“回档” 的情况,如:第一次进入游戏,安排了builder 去工作,第二次再打开的时候发现根本就没有开始,一切又回到了上一次进入开始时候的状态,而这种情况往往出现在我wifi 到3g 切换的过程中。 从这点也再次印证了上一段所说到的,为了保证用户体验,它并没有严格的依赖手机的网络质量,可能为了从安全性的角度出发,它情愿失去客户端上的修改,简单粗暴。

为何我认为战斗部分是帧同步呢? 因为战斗的整个过程是纯客户端本地运算的。这点可以如此验证:先关掉手机的3g,以保证只有wifi 连接。开始一场战斗。战斗的过程中,把wifi 的wlan 接口拔掉。这个时候,你会发现你可以完整的打完一场战斗,客户端的金和气也会刷新,但是会卡战斗结算界面。这个时候即使恢复网络,重新进入游戏,会发现死掉的兵还在兵营里,金和气也没变,那场战斗就像没有发生过,白打了。由此证明客户端是有一套完整的战斗系统包括AI的实现。战斗结果可能会在过程中发送到服务端去,但是即使没有收到也不会影响客户端的逻辑进行,以保证战斗效果的流畅。那么战斗结果如何校验呢?那就必须有一套客户端和服务端都完全的操作序列及时序来保证了。

保证客户端和服务端战斗结果一致性的方法有很多,为何我猜想他们是基于帧的呢? 因为这个实现起来会更简单,KISS原则。我们知道COC 有个很强大也是很吸引人的功能是战斗回放,默认保存5个,它可以完全重现对方进攻的过程。我们不妨猜想一下它的实现方式是这样的:

  1. 战斗前服务端同步一下当前帧(从那里开始问题不大,默认每场都从0开始也可,只是要保证这个时刻服务端和客户端都在一条起跑线上)。
  2. 然后开始记录每次玩家的点击,数据类似(FRAME,TYPE,POS),FRAME是操作时的帧,TYPE是操作类型,例如是放步兵还是弓箭手还是法术等,POS是操作的场景坐标。

由于COC 对玩家在战斗中的操作进行了非常严格的限制(只能放兵,而不能控制),基本上这个三元组的序列即可描述一场完整的战斗。整个战斗的过程均是完全由AI来驱动的,而且由于设计上完全舍弃了随机的因素,所有的数值均是确定值,而玩家的唯一输入仅有上面提到的三元组,那么战斗是所有演算均可在服务端和客户端分别演算,结束时只要校验一下客户端的结果即可。一切均在一个沙盒中完成,假如没有收到客户端结果,服务端的数据不会改变,于是也就出现了上面提到的“回档”现象。而由于使用了帧驱动的方式,那么战斗回放以及加速播放也就轻而易举了。

对于战斗结果还有一个冲突问题,他们也是没有解决的。就是为了让体验更加流畅,因此可能客户端在战斗过程中失去网络连接,并且结束时候也无法恢复的情况。而在这个时间差之间,假如服务器上的数据产生了改变,例如断线后玩家上线产生了其他操作、甚至被另外的玩家攻击过了等,那么就会出现数据不一致的情况,而且这个数据冲突很难解决。COC 的方法依旧简单粗暴,它完全放弃解决,那场战斗就宣判无效,重新进入游戏你的数据不会有变化。这个可以通过进入战斗对玩家数据加锁的方式来防止并行,并且他们也这么去做了,于是就会出现某人正在攻击你的登录画面,但是由于手游的特殊性,这个问题COC 出到现在3.54版本也没有完美解决。

最后总结一下以上几点,我猜想COC的程序底层设计大概如下:

  • 网络非长连接。但尽量可靠
  • 建设场景事件驱动 (包括定时器)
  • 战斗过程帧驱动(弱同步)

由于完全是黑盒猜想,仅仅是个人观点,不太准确欢迎大家多多指点。对于匹配系统以及战斗AI的想法会以后以另外的文章补充

Dec 122012
 

看了下云风的一篇新的博客,是关于SC2的编辑器,觉得有点一意思,就细读了一下: http://blog.codingnow.com/2012/10/sc2_editor.html

里面说到了一种和我们现在的实现有点不太一样的AI 实现方式,主要的特点就是触发器都是全局的,然后下发指令到各个npc,让它去执行。

这点和英雄三国的AI 实现方式比较像,也是通过指令队列来做的,但是他们好像更彻底,连玩家的操作也是用指令队列的方式。我认为也许和游戏的类型有关。

咋一听这种方式的时候, 感觉还挺靠谱的,貌似在消耗上会比我们当前少一些,好像一个场景只需要一个定时器去处理时间即可

但是细想一下,可能不太合适,有那么几点:

  • 定时器的消耗无法消除。虽然是指令的形式,但是还是需要每个npc 挂定时器来处理队列逻辑。而且全局的事件统一处理,本身数据量也并不是小,复杂度不一定比现在的低。
  • AI 的行为抽象不好描述。比如要实现复杂的AI: 近身了,用冲锋击晕对方,然后后退,用远程AOE 秒杀。这样复杂的连续行为,用这种方式也许并不好描述
  • 性能上不一定有优势。在逻辑需求没有变的时候,用两种方式要做的事情应该是一样的,因此消耗并不会因此而减少。

我还是觉得sc2 选择的这样的AI 处理方式,是根据它的游戏性质来决定的。越是直接的抽象,一般来说越好理解。它想去模拟的就是一个人机对弈,全局AI 恰好就是这样的抽象,基本上是对博弈思考过程的模拟。假如可以选择的话,可能会出现激进的对手,保守的对手,而这种性格一般来说都是全程的,我这一战想要一个激进的,那么他一般都是全程激进的,因为需要做一个改变战略的决策AI,我想是非常难做好的。 而我们并不是想要这样,我们希望的是每个怪都是独立思考的,同一个场景内的不同的怪都是可能表现出不一样的性格,而用这种全局的实现方式就不是非常科学了。做应该是可以做,但这个抽象实在是很别扭。

Dec 122012
 
  • requirejs
    • require,
    • define
      • If the module has dependencies, the first argument should be an array of dependency names, and the second argument should be a definition function. The function will be called to define the module once all dependencies have loaded. The function should return an object that defines the module. The dependencies will be passed to the definition function as function arguments, listed in the same order as the order in the dependency array
  • client
    • index.html
      • <canvas id="background"></canvas>
        <canvas id="entities"></canvas>
        <canvas id="foreground"></canvas>
    • js/main.js
      • 开始游戏 app.tryStartingGame(name);
    • js/app.js
      • start:this.game.run
    • js/game.js
      • setup
      • run
      • connect
      • tick
    • js/updater
      • 逻辑帧:更新数据,逻辑
      • 根据逻辑设脏数据, 如各种updateXXX接口
    • js/renderer
      • 渲染帧
      • drawEntities:只渲染脏的。sprite 决定image
  • 网络
    • websocket: gameclient.js
    • 协议json,bison
    • 协议定义:gameclient.js 类型不多。
  • 资源:
    • img 分了3个文件夹,具体看:game.js:320
    • sprite目录下的json对应了各个怪
Dec 042012
 

本人是个电影控,自然而然也就是高清控,因此无法忍受rmvb 的这种骑兵格式,不是h264 的片源看着就浑身不舒服。很不幸的是多少还有点苹果控,于是用了apple tv 和mbp 这两个坑爹的货,于是mkv 就无法在itunes 上播放,必须转换格式。

看高清的都知道,一个文件动辄就6,7G,1080p 的就是10几个g,“转换格式”这东西是不可能忍受的,特别是在家里那台E2600 上,必须是半天才能解决的问题。

技术宅的唯一解法就是DIY了

搜了半天资料。发现mkv 和mp4 有一个非常巧合的共同点,就是视频编码都是标准的h264, 仅仅是音频从ac3 变成了aac, 那么就是说itunes 是可以解码h264 的,仅仅是无法解ac3, 那有没有可能是只转换音频而视频仅仅是重新打包呢?

格式转换软件网上一堆又一堆的山寨货,包括播放器也是一堆又一堆,但音视频编解码这种如此高级的算法,是不可能被所有山寨程序员所掌握的,因此大部分仅仅是自己做了个UI 来坑骗广大网友而已, 其实核心一般只有一个,一般来说都是来自ffmepg这个开源项目。

最赞的是它还是跨平台的,直接提供命令行二进制包,那么问题就迎刃而解了。

整个过程只需要一个指令: ffmpeg -i input_mkv -vcodec copy -ac 2 output_mp4

其中-ac 2 是把音频信号转换成 2声道的,因为ffmpeg 的aac 编码器还比较低端,只能支持2 声道,而无法支持6声道,因此需要强制转换。

测试过几个7g的 mkv 电影,转换速度在15分钟之内,非常符合我的预期,而且不需要demux 再remux 的过程,均是同步进行的,非常的爽快

PS:在linux 遇到点小问题,就是ubuntu 上的ffmpeg 已经被标志为obsoleted, 需要使用它的分支avconv , 参数有些许的不一样,而且需要装libavutil-extra-51的包,但过程基本雷同,还是比较方便的。

Oct 152012
 

懒了,好久没更新,今天帖一篇。

现在所有人的生活都离不开手机,只是有的人只拿它来打电话,但有的人比较依赖它,程度不同而已。

很多人和我说,对手机,没什么需求,只要打电话发短信就可以了。我其实觉得这只是他还没有体验到手机的方便而已。因为据我的观察,他是有上网和娱乐的需求的,只是平台是pc,操作系统是windows,并不是完全没有需求,但为何没有转移到手机上面呢? 我的结论是:他还没有一台好用的手机。

试想一下,假如你所有的需求都可以用一台随身的设备满足,那你为何还要固定在那台臃肿的pc 上呢? 当你可以边走边写代码,随时随地都可以调试的时候, 你还会窝在LCD前面码代码么? 也许最终的乐趣就只剩下敲击机械键盘的那种爽快感而已了。当然,我们现在的手机离这样的应用场景还有很长的距离,但我觉得只是时间问题而已。

扯了些乱七八糟的,回到题目,用户体验, 主要是想说下我这周的观察。最近在电信的霸王条款的强迫之下,我又有了一台android。周末儿子拿来玩,1分钟不到,他发现自己玩不动了,果断放弃,跑去ipad 了。小孩是不知道什么是品牌的,他也没有太多固有的操作习惯可言,但完全不用教,他就自己能打开ipad, 点开app, 退出,再点另一个app…. 这说明了什么?这就是用户体验!android的用户体验不好,很多人用很多理论去分析,而我不懂太多理论,事实胜于雄辩,一个2岁小孩玩,看他能否操作,高下立现。

Don’t make me think! 这个就是用户体验的最高境界。一个好的软件,根本不需要什么新手教程,不需要什么说明书。这点上,很多产品都做得并不到位,就例如汽车。想起当年我还真把我第一辆车那本几百页的说明书啃了个七七八八。但我想我再也不会这么做了,第一是各种车的操作差别都大同小异没这个需求,第二是这个体验实在太差了!游戏其实也是一个道理,不知道哪位还记得自己玩超级玛丽的时候,有没有谁教过你,我想大部分人都可以在5分钟内上手。死第一次的时候,你就会知道,乌龟是可以杀人的,当吃第一个蘑菇的时候,你就知道,蘑菇是可以变大的… 玩游戏,用软件的人都不是傻瓜,人的学习系统就是在各种负反馈的情况下达成学习目标的,过多的正反馈反而会让人觉得烦。现在我玩网游,假如前5分钟,我都是在被“引导”的话,我基本上会关掉这个游戏,md, 那帮人是在侮辱我的智商么?

在同质化严重的今天,产品能否脱颖而出,主要看体验,当然,价格也是个关键因数,毕竟很多人是情愿牺牲一点体验,但换来更便宜的价格的。这也是个权衡,看TA更看中的是什么了。