归档 2020

最后更新于 .

文章的标题不是我最早说的。
而是一个视频底下一大批游戏创作者们的心声。

那个视频,是 《黑神话:悟空》

当时看到这个视频的时候,我感动的热泪盈眶。
一方面,感叹于终于有人要做中国自己的3A游戏了。
一方面,也在叹息,那个人,终于也不是我。

这也是创业以来我第一次深深的自我怀疑:自己在做的这些游戏,算什么?

《矩阵危机》算是自己真正想做的游戏,实时多人对战,帧同步服务器,确定性物理引擎,随机地图。1年多的时间,我们也确实投入了很多。
然而,当市场验证结果不理想的时候,当我们发现方向出现问题的时候,我们只能选择更改方向。

给腾讯天美做外包,做h5小游戏上国内几大平台,现在又在做海外超休闲小游戏。

这些,真的是我当年出来创业的初衷么?

其实落差真的是挺大的。

不过能怎样呢?不是每个人都有机会去做那些光鲜无比的事情,即使我自己都看不上的超休闲游戏和其广告变现形式,我们也要承认很多厂商在海外赚的盆满钵满。

正经赚钱的生意,不丢人。

说起来,前段时间买量的数据倒是还不错,算是对我入门广告投放1个月的奖励吧~截图是美国区的。

不过Google Play最近把我们的应用给下架了,说是有windows恶意程序,我寻思一个apk里面即使有windows恶意软件也运行不了啊?
最近正在申诉,希望能尽快有结果吧,实在不行只能注册新的应用ID了。

而且比较恶心的一点是,一旦Google Play上被下架 ...

最后更新于 .

!!!本文含有《最后生还者2》剧透

记录一下最近的几个游戏吧,也顺便分享一下感受。

一. 《健身环大冒险》通关

先贴几张通关截图。

从今年2月份开始锻炼,一开始因为疫情在家办公,所以保持每天锻炼一次的频率,后来恢复上班后,保持两天一次的频率。

到7月24号完全通关,总共瘦了15KG。

极其推荐给想要锻炼身体的朋友。

二. 《最后生还者2》通关

这一代网上差评很多,虽然我对结局也有些抵触,但也还勉强能够接受。

且不说埃比中途放过艾莉一次(如果算上开头那次应该是两次)的原因,如果艾莉最终真的选择杀死埃比,那么要不要把勒弗一起杀死?

如果选择杀死的话确实可以永诀后患,但是埃比尚且知道放过无辜的人,如果艾莉反而杀死了无辜的勒弗,那不是艾莉比埃比更加残忍?

如果选择不杀的话,那么这场循环往复的复仇又什么时候能够终止?

更何况艾莉也开始有了自己的孩子,乔尔能够为了艾莉放弃全人类,那么艾莉能为了孩子做到什么呢?

但我也能理解很大一部分低分玩家的情绪,尤其对于和我一样有着一代感情的玩家来说,确实对于这样的结局是难以接受的。

乔尔的死,杰西的死,一个刚刚还活蹦乱跳的人,突然就在你眼前一动不动了。

你痛苦,你愤怒,你想复仇。

但偏偏,制作组让你去控制埃比,让你去体验埃比的痛苦,她又何尝不是失去了父亲,曼尼,欧文?

我印象最深刻的一点是曼尼死的那一段,当我看到曼尼死在面前 ...

最后更新于 .

发现想抽时间写博客实在是太难了,不过我觉得今天这一篇还是很值得写一下的。

熟悉我的同学应该都知道,我之前做了一款《矩阵危机》的产品,使用的是帧同步的技术。

简单画一下V1架构图:

  • Gateway

    网关服务器。

    负责客户端连接的接入,使用协议TCP。

    使用C++编写。

  • KcpProxy

    Kcp协议的代理服务器。

    客户端默认使用Kcp连接服务器,如果失败会自动回退到Tcp。

    使用C++编写。

  • RoomServer

    房间服务器。运行战斗逻辑,每个房间同时仅能运行一场战斗,帧率为15帧/秒。

    房间服务器与Gateway间通过Tcp连接,每个房间建立一个一条独立的连接。

    使用Python编写。

整个架构还是比较清晰的,但是里面有个极大的问题:性能

因为python的性能实在是太差了,对于RoomServer每秒15帧这种cpu密集型的业务场景完全不适合。

至于python的性能有多差,我当时做过一个简单的测试,同样的业务代码,c++是python性能的10倍左右。

可能直接说这个数字大家也没什么感觉,但是要知道换算成服务器的话,那就是10倍的服务器量,10倍的成本。

所以这也是要做架构升级的原因。

而升级的方案也有多种,其中一个方案如下:

其核心逻辑是将CPU密集的RoomServer放到Gateway中去,而额外多出来一组RoomController负责对Gateway和Room进行控制。

RoomController可以继续使用python实现。

这样的方案虽然解决了性能问题,但是却导致gateway的功能过于耦合,不是好的设计方案。

还有一个方案就是将RoomServer直接使用C++重写,每个Room开一个线程 ...

最后更新于 .

发现每天的想法都很多,积极的,消极的。
但是当想要付诸纸笔的时候,却又不知从何说起。

所以这篇博客就当作碎碎念吧,想到哪就写到哪。

一. 生命的意义

最近经常在思考人生的意义,以前我觉得,人类可能是被圈养的,有人在一直观察着我们;或者可能是我们其实都是虚拟世界里面的角色,有人在操控着我们。
但最近我开始悲观的觉得,可能没有任何人在意我们。

文章的标题是《不如蝼蚁》,因为蝼蚁之于人类有时候还算是有趣的存在,毕竟我4岁的儿子有时候还是会饶有兴趣的看蚂蚁半天(当然我小时候也这样)。

而人类,甚至于生命这个整体,可能都是无人在意的。

当然,我作为生命中的一个独立个体,肯定是无法理解生命本身的意义的。

如果看过《失控》应该能理解我说的这句话,水滴是很难理解大海的。
水滴汇集成大海之后已经完全变成了不一样的东西,哪怕大海确实是无数的水滴。

所以,无论是我,以至于生命中的任何一个个体,都应该是无法理解生命本身的意义的。

但如果《失控》里说的是正确的话,那么有一条是可以确定的,生命是希望无限扩张的。

从海洋到陆地,从地球到太空。

而想要实现这一切的基石,是繁衍。

基于此结论,我之前产生了一个很奇怪的想法。那就是:

我生育了下一代,对于整个生命来说,是有意义的。

我觉得,对于大部分人来说 ...

最后更新于 .

是的,前一篇文章也说了,《矩阵危机》的版号被打回了。

为了团队的生存,暂时只能转去做外包了。

其实早在一年半之前,tam就跟我聊过,想做自研的同时边做着外包供血的事情。
只是当年自己心高气傲,说是专注于自研不要被其他事情干扰,其实也是烦外包的甲方太麻烦。

而今天《矩阵危机》的失利,我不得不对自己的产品和运营能力上打个X。
自信是对的,但自负是错的。

所以现在之所以愿意做外包,有几个原因吧。

  1. 训练团队。通过外包来储备自己的人才。
  2. 储备资金。一直烧自己的钱也不是办法,现在的资本也都不傻,游戏行业的资本退出又比较困难,所以对于游戏并不是特别看好,还是要能自己供血。
  3. 找到互补的合伙人。
  4. 等着自己真正准备好。

具体说说这次的外包项目吧,说实话作为第一个外包项目,直接就和大厂合作实在是累的够呛。

这次的项目要求的是帧同步对战,好处是他们提供服务器,我们只需要编写客户端就好了。
但偏偏这游戏是个多人实时对撞的游戏,所以对于物理模拟/手感的要求都比较高。

本来我是不打算过多参与这个项目的,所以让手下一个小孩自己写了半个月。因为需要用到物理引擎,但是又没有现成的定点数物理引擎,所以就用box2d+数据对齐来尝试解决,结果搞得一团糟。

最后甲方那边也急了,没办法,只能自己上了。

从当天9点写到次日凌晨7点,总算是把确定性碰撞库给搞定了。

之后又花了几天做成物理引擎,并且优化了手感。

好在之前有《矩阵危机 ...

最后更新于 .

前天,版号的代办公司在群里毫无征兆的发了这么一条消息。

那一瞬间,我其实有点懵,似乎还没有意识到这对我意味着什么,对《矩阵危机》意味着这什么。
旁边的同事还在有节奏的敲打着键盘,间歇的几句讨论,一切看起来都还在正常的运作。
我该怎么回应,怎么面对,我不知道。
我只能凭借本能,友好的感谢了为我们代办的公司,并期望下一次合作。

直到过了两天,我才终于能正常的思考这件事情。

是我的错。

事情的起因,是因为总局的审核人员发现了我们游戏在线上运营。

我说一下我们的实际情况吧

  1. IOS

    • 上线:上线AppStore
    • 支付:开通
    • 广告:开通
  2. Android

    • 上线:仅在TapTap和阿里积木计划开放测试
    • 支付:关闭
    • 广告:开通

而因为版号等待期间,我们基本没做任何推广,所以所有收入加起来不足500元。

所以整个事件的过程就是:

  1. 总局发现我们有上线运营,责令修改。
  2. 我们写收入证明,保证书,下架所有平台。
  3. 总局审核不通过,驳回版号申请。

我为什么说是我的错?
因为错在对规则不熟悉。
但凡我对这个行业再熟悉那么一点点,就不会犯下这个错误。

那版号打回对游戏的影响是什么呢?

  1. 游戏无法上线国内所有平台
  2. 国内无法签发行团队 ...

最后更新于 .

本来下午一直在纠结用什么设计关卡地图的事,中间还考虑过使用excel,但是发现很难用。后来美术随口说了一句,用瓦片地图怎样?我说那个只能固定格子来排列吧,他说可以不用的。我这才去试了一下,果然可以。

Tiled 有如下几个很方便的功能,跟大家分享一下。

  1. 对象层创建的对象,位置是可以不严格按照格子来定位的。

    这里有几种选择:

    1. 将地图的属性中的格子大小调小。比如我们认为1米对应100像素,那么一个1.8米的人就是180像素高。

      如果我们认为对齐的精度只要到10像素即可,那么就可以将格子大小调整为10x10。

      之后选择 视图 -> 捕获 -> 对齐网格,或者移动对象的时候按住ctrl,就可以实现对象位置自动对齐网格了。

    2. 就是希望自由定义位置,那就什么也不用改。

  2. 对象支持类型以及属性

    这样对编程就非常方便了,代码可以通过对象不同的type来区分大类,之后再以对象name来区分小类,然后再通过属性获取具体的数据。

    对地图编辑也非常友好,因为不同的类型可以设置不同的颜色,这样编辑的时候就非常清晰了。

    值得一提的是,对象类型是不绑定在单个地图上的,所以如果需要创建多个地图的话,是可以公用对象类型的。

  3. 对象支持模板

    这个也是对于编辑多张地图非常重要的事,非常幸运的事,tiled支持了它。

    1. 首先要在 视图->视图和工具栏->模板 这里打开模板。
    2. 之后随便创建一个对象,比如一个hero。再其上点击鼠标右键,选择保存为模板hero.tx ...

最后更新于 .

一. 简述

我们用最精简的模型来描述一下帧同步。

客户端检测服务器的逻辑帧 -> 拿到逻辑帧 -> 进行处理 -> 处理出结果 -> 完成本次逻辑帧处理 -> 表现层将处理结果渲染到屏幕上 -> 结束

客户端检测用户操作 -> 打包成action -> 上报到服务器 -> 结束

在此基础上,客户端可以通过缓存帧,平滑帧,预测,插值,等方案优化表现层的效果及手感,但是底层模型是一样的。

比如缓存帧就是客户端检测到新的逻辑帧之后不立即处理,而是先缓存到一个队列中,等到满足一定数量之后,才对队列popFrame进行处理。

而平滑帧,则是在缓存帧的基础上,将popFrame的操作做成定时操作,从而抵抗网络波动导致逻辑帧到达的时间间隔不一致问题。

帧同步游戏一定要分为逻辑层和表现层。

表现层怎么折腾都可以,但是逻辑层必须保证确定性。

那么哪一部分属于逻辑层呢?

拿到逻辑帧 -> 进行处理 -> 处理出结果 -> 完成本次逻辑帧处理

打包成action -> 上报到服务器

所以,平缓帧的实现方案中,才能用普通的 ...

最后更新于 .

是的,现在是凌晨2点,而我还在写这篇博客。

因为从4月份开始,苹果的这封邮件里面的错误就必须得处理了。

Dear Developer,

We identified one or more issues with a recent delivery for your app, "PandaDemo" 0.1 (232343). Your delivery was successful, but you may wish to correct the following issues in your next delivery:

ITMS-90809: Deprecated API Usage - Apple will stop accepting submissions of new apps that use ...

最后更新于 .

最近把unity升级到了2019.3.4f1。
至于为什么要升级,em。。。好吧,我承认我是馋她身子(笑)。
毕竟我两年前第一次接触unity的时候就觉得UI丑了,而这次终于新版本换了扁平化的UI,深得我意,没道理不升级啊。

但是没想到,这就是恶梦的开始。。

其实半年前我们原来的客户端研发还在的时候,就尝试升级过unity,但是后来回退了,而现在,我切实知道什么原因了。

这里主要是通过几个案例,来分享一下定位bug的分析过程,以及我这几年总结的一个定位bug的杀手锏。

一. Android平台Spine动画失效,游戏内全是白块

如图:

这个问题是当时回滚版本的主要原因。

因为自己对unity不是很熟,对客户端代码也是刚接过来,所以这个问题查起来也是一头雾水。 由于没有办法通过看代码来定位问题(看不懂),所以我们只能用别的方法了。

先把能解决的解决一下:

  1. 升级spine的运行库版本。
  2. 升级spine编辑的版本,重新导出动画。

但是很遗憾并没有解决。。
不过这里说个题外话,这里的升级还是很有用的,官方确实了改进了unity2019.3的兼容性,从而很方便的解决了局内物品白块和局外某个英雄动画无法播放的问题。

OK,先来看几个现象:

  1. 虽然都是使用了spine动画,但是局外动画没问题,只有局内动画有问题。
  2. 局内动画使用像素风格,并且支持皮肤换装;局外动画为正常风格,不支持皮肤换装。

从上面的现象可以思考几个问题的可能性:

  1. 像素图片的Filter Mode ...

每月存档

去年

2019

明年

2022