突然想写点什么

今天是锤子的新手机“坚果”手机的发布会,由于技术故障,发布会延迟了一些时间,有网友戏称“罗永浩重新定义了 7:30”。

我并没有完整地看完整个发布会,我也不是锤粉,也不是罗永浩的粉丝,得知罗永浩的一些相关事情大多是从《读库》的老六那儿偶尔听到一些花边新闻啥的,自己貌似看过老罗哪一年在海淀剧院的一个演讲,那会儿他的公司名叫“老罗和他的朋友们”,还是在做英语培训。

有一些感概主要是来自于看到锤子一步步地从零开始到现在这么不错的一个体量,成长为一家健康的企业,创造出来让大家喜欢的产品,很羡慕,当然也有一些唏嘘。

说得好听一点,我跟着之前公司的老板一起进入移动互联网创业的时候,老罗还在张罗着给自己的培训学校找教室呢。用我前老板的话说“我们起了个大早,赶了个晚集”,从 2010 年 5 月 18 日,进入 Android 开发这个圈子,从一款单机小游戏《黄金矿工——喜讯特别版》,到个人日程管理 APP《喜讯天天》,到移动互联网照片分享社区《画说》/《MARK》,一个人扛着整个公司 Android 开发的大旗横冲直撞,锤炼了自己的手艺,淬炼了自己的筋骨,拓展了自己的视野,长膘了自己的腰围。

随着公司在移动互联网社交领域的失败——前老板如此下的结论,公司集体转型到手游,开始担任项目经理,当然更多的角色还是主力客户端程序和救火队员,产品最终如期发布,事情也做得越来越顺手,但是由于期望过高,让《铁血战神》背负了太多,最终未能撑起让整个公司崛起的大旗,反而成为了我在前任东家的告别项目,今天还有玩家反馈说是《铁血战神》没法登录了,以前的同事在群里还感慨了好一阵子。

如今自己跟几个前同事自己立了一个摊子做手游,但是困难重重,有产品上的,有技术上的,更多还是人的困难,不当家不知柴米油盐贵啊。创业一年有余,方知世事皆艰难,唯有咬牙挺过去,兴许能有机会看到胜利的曙光。

回到感慨这个话题,感慨的是什么呢?感慨的是,“滴滴打车”和“锤子手机”已经从那个创业的死人堆里头爬出来了,而我可能又将再次被埋葬在这一波的寒冬。

记得首次在媒体上看到“滴滴打车”的报道时很不以为然,然后没过多久听到朋友说起自己打车有在使用“滴滴打车”(那是冬天,在北京这货很有用,可以让你不用在寒风中站在马路边等车),再没过几天被一个出租司机——张师傅推荐安装了”滴滴打车“,从此”滴滴打车”成为了我生活中必备的工具,因为当时每天加班都到 23:30 以后,大部分时间都是凌晨 2 点左右,这个时候“滴滴打车”每天让我能快速舒服地打到回家的车(那时我在北苑上班,住在天通苑,这个点这个路段几乎百分之九十的出租师傅都会选择拒载,因为路途短,就是个起步价,而且还是往城外方向走,回来肯定放空车),当时跟泰峰聊,移动互联网目前为止让我感觉到改变了我自己生活的有两个 APP,一是微信,二是滴滴打车。放个马后炮啊,当时看到每天报道说滴滴的技术不够强什么的,甚至看到过滴滴的招聘文章,如果那个时候真的这么坚定的话,也许可以加入滴滴做个开发人员呢,是不是?

在罗永浩说要做手机之初,看到很多报道,看到他跟很多人打嘴仗,当时只是觉得这些人怎么都觉得自己能做手机,真的有那么简单吗?持一种怀疑的态度,并不看好。当时我的同事张树立已经从前东家离开了,有一次吃饭听他聊起过他还去锤子手机参加过面试呢,不过最终的结果是他并没有加入锤子科技,选择了人人网。当时听他谈到去锤子面试的时候,内心其实是有一些小触动的,这个小触动是心想“如果我去了,被录取了的话,会是神马情况呢”这样的一种情绪。对于罗永浩这号人物,内心是很佩服的,例如在条件允许的情况下,坚决支持正版,坚持做公益捐赠,支持有理想的人去坚持他们的理想,,碰到让自己不爽的东西会触发处女座属性,这些都是我自己很欣赏的特质,我也是这么做的,从人格上来说,简直完美契合,而且他的演讲技巧简直让我拜服,人生的轨迹也足够精彩。能够追随一个这样的人去做些事情,即便最终未能获得普遍意义上的成功,我想也是成功的。

但是,我们终归还是那只留在了井底的蛤蟆,我们有痴心妄想的权利和欲望,但是没有跳出井口的能力和远见。也许未来还有更加美丽的风景在井口出现,我想什么时候要是能老腰一拧,纵身一跃,跳出那井口,站到井沿儿上去看那风景,甚至成为那风景,那个时候再感慨一声“你也有今天啊”,多么美好啊。

Unity3D 中 CapsuleCollider 碰撞挤压将对象挤到空中的问题

这几天一直在尝试着修改各种战斗中的 Bug,优化一些战斗细节等等,然后发现了在某些怪和主角对抗的时候,有的时候主角会莫名其妙地被挤到空中去,有的时候是怪在攻击主角的过程中把自己给挤到空中去了。你说这能忍吗?显然不行,对伐。

然后就开始使劲浑身解数尝试着在不同的状态下,主动控制怪和主角不要离开地面(通过动态获取目标所在位置点的地表 Y 坐标值,然后设置为目标的 Y 坐标),可是这又谈何容易呢,先不说这么做合不合理,优不优雅了,这一眼看上去就不是啥好招啊,而且实际上并没有找到为神马会出现相互挤压就会把某一方给挤到空中去的原因,那么我们肯定不能善罢甘休的,对伐?

接下来我们来看两个图: capusle_collider_1动图 1 capsule_collider_2动图 2

上方的动图 1 中,我们看到绿色的 Capsule 朝着红色的 Capsule 快速移动,并且在移动的过程中与其发生了碰撞,碰撞之后绿色和红色的 Capsule 错开,然后绿色 Capsule 继续运动了一段时间。从动图 2 中,我们能看到绿色的 Capsule 在与红色的 Capsule 碰撞之后继续运动的过程中,明显有被挤到空中的情况。咦,貌似我们已经发现什么了呢。

那我们再来对比一下这两个 Capsule 的设置值,到底是哪个参数导致的呢?

capsule_collider_inspector_1 capsule_collider_inspector_2

从上面的两张图对比中来看的话,其实只有一个 Capsule 的 Scale 调整了 Y 为 2,同时 Y 坐标也因为 Capsule 变高了所以变高了。如此一来,这个绿色的高个子的 Capsule 在与红色的矮个子 Capsule 发生碰撞和挤压的时候就会因为质心过高而被挤到空中去。如果希望避免这种情况,可以考虑将所有的 Capsule Collider 的中心点值和高度值都统一设置。

Unity3D 中 Mecanim 动画切换与 AnimationEvent 的关系

在我们的游戏中,我们使用了 Mecanim 动画中的 Generic 动画类型,几乎所有的动画切换和融合,我们都直接交给 Animator 自行处理了。省事倒是省事了,随之也带来了一些不可预知(其实是自己能力不足好吧)的问题。

今天我要分享的是一个这样的问题,例如主角正在进行 A 动作,此时受到攻击通过 Trigger 设置,切换到 B 动作,主角的 AnimatorController 中并没有直接从 A 动作过渡到 B 动作的 Transition,A 动作和 B 动作都是可以从 AnyState 直接切换的,也就意味着 AnimatorController 会自动根据当前动画的状态从当前播放的动画过渡到目标动画中去。

在 A 动作还没有播放完的情况下,我们通过设置 Trigger 的方式将 A 动作切换到 B 动作,而 A 动作上又绑有一些 AnimationEvent,这些 AnimationEvent 会在动画执行到对应的时间轴的时候触发回调,用图来表达,最好不过了。 mecanim_transition_animation_event图一中的这种情况,OnSkillEnd 这个 AnimationEvent 是不会被回调的,而在图二中,OnSkillEnd 这个 AnimationEvent 就会被回调。因为每个从 AnyState 出发的 Transition 都是有过渡时间的,如果绑定的 AnimationEvent 所处的时间轴在动画过渡时间之内,那么就会触发这个 Event,否则就不会回调。

关于 Animator.SetTrigger 的一些迷思

近期一直在修改各种战斗中碰到的问题,其中有一个问题,让我困扰了很久,大概场景简单描述一下,有一天我们的策划同学给我反馈了一个问题,问题是这样的:

如果主角在战斗副本中一直按住攻击按钮进行攻击的话,貌似一直都处于霸体状态,小怪命中主角之后,能看到主角在掉血,但是主角几乎不会播放受击后仰的动画,让人觉得主角很 Bug,小怪完全不是对手。

好,这是一个很好的问题,在我听到这个反馈的第一时间里,我的反应是“擦,这不可能啊”,好吧,程序猿总是这般自信和分裂。实际上这肯定是可能的,而且正在发生,可是我们总是想选择不相信事实,在看着我们的策划同学演示了大概 3 分钟,我发现这尼玛就是有这个问题。那么肿么解呢?

先检查代码呗,各种检查,各种推演,最终发现有可能存在一种情况,那就是 Animator 同时调用了多个 SetTrigger 方法,设置了多个不同的 Trigger 的值,可能会导致这个问题,那么接下来就是验证了,因为实际的工程中触发个情况肯定不是那么必然和容易的,那么我们验证的时候就直接非常直接地通过代码的方式来验证就好了。

我们直接就在某一个按钮按下的事件回调中,直接通过 Animator.SetTrigger() 方法设置了两个动作差别非常大的状态对应的 Trigger,最终会发现 Unity3D 会自动融合这两个过程,例如我们在 Idle 状态的时候通过设置 Attack 和 BackOff 两个状态的 Trigger:Attack 和 BackOff,然后我们就会发现,主角会先往后仰几帧,然后继续 Attack 的动作直到其完整播放完毕。 unity3d_mecanim_set_trigger_myth测试结果是,会以当前触发的所有动画中播放时长最大的为主,其余的动画会在整个时间轴中对主角的动画综合地产生影响,所以一定要注意尽量不要让多个不同的 Trigger 在同一时间触发,因为 Unity4.6 版本未提供获取 Animator 参数列表的接口,所以我们得自己维护好 Trigger 列表,如果我们的实际需求中,不存在需要多个 Trigger 同时被触发的情况,那么记得在设置新的 Trigger 之前(当然也可以考虑优先级和权重值)将其他已经设置过但是还没有被 Animator 应用的 Trigger Reset 掉。

使用脚本在 Unity3D Editor 中完全删除 Prefab 中的 ParticleSystem 组件

今天碰到一个小问题需要通过脚本来批量将我们工程中的所有例子特效 Prefab 根节点的粒子发射器给干掉,那么好吧,开始动手吧。

执行一下,发现 ParticleSystem 组件确实木有了,但是留了一个小尾巴,就是我们在 Unity3D Editor 中查看被处理的 Prefab 时,还能在 Inspector 中看到一个 Shader 的小尾巴,如图:

default_particle_shader_tail

这个让我情何以堪啊,你知道的,我有轻微强迫症的,虽然貌似并不会影响程序的功能,但是我要是不知道原因,我岂不是很不爽,好吧,那么就对比一下手动将 ParticleSystem 组件 Remove 和通过我们这个脚本 Destroy 之后的 Prefab 文件之间究竟有甚么区别呢,这个时候就需要借助一下 Unity3D 提供的 binary2text 命令行工具了,Mac OSX 上这个命令还在这个位置 [Unity3D 安装目录]/Unity.app/Contents/Tools/binary2text,通常就是 /Applications/Unity/Unity.app/Contents/Tools/binary2text。使用这个工具将两个 Prefab 文件转成 Text 文件之后我们就可以使用文件对比工具来进行对比了(对比二进制神马的,真的让人很蛋疼啊,幸好 Unity3D 还提供了这么个鬼啊),对比就会发现,这个 Shader 是因为啥而存在的了。

compare_1 compare_2

左侧有红色文本显示的是通过脚本 Destroy ParticleSystem 组件之后生成的 Prefab 的 Text 文件,右侧的是手动通过右键 Remove Component 删除 ParticleSystem 组件之后生成的 Prefab 的 Text 文件,对比之下我们能发现左侧文件中说明了一些问题:

  • 第一处红色文本表示多了一个内部资源的引用,看起来很像是 Shader;
  • 第二处红色文本更是直接说明了问题,左侧表示有两个组件,组件的 Id 是 19935810,刚好与第三处红色文本描述对应;
  • 第三处红色文本描述的是一个 ParticleSystemRender 组件的信息。

这么一看就知道原来还有一个隐藏的 ParticleSystemRender 组件没有被移除掉,因为这个 Render 是依附于 ParticleSystem 才存在的,所以不会在 Inspector 中单独显示,而是作为 ParticleSystem 的子组件 Render 进行显示的。那么我们就再修改一下我们的代码就好了。

也就是需要独立地将这个 ParticleSystemRender 组件也给 DestroyImmediate 一下就好了。搞定,洗洗睡了。