July 28, 2014

sproto 的实现与评测

这个周末,我实现了上周设计的简化版 protocol buffers 协议 ,并重新命名为 sproto

在实现过程中,发现了许多编码格式上可以优化的地方,所以一边实现一边做调整,使结构更适合编码和解码,并且更紧凑。

做了如下改动:

由于这个东西主要 binding 到 lua 这样的动态语言中使用,所以我不需要按 Cap'n Proto 那样,直接访问编码后的数据结构(直接把数据结构映射为 C/C++ 对象),所以数据对齐是不必要的。

编码时的 tag 如果要求严格升序也可以更快的处理数据,减少实现的复杂度。数据段也要求按持续排列,且不准复用。这样可以让数据中有更多的 0 方便压缩。

把 boolean 数组按位打包的意义也不太大(会增加实现的复杂度)。

暂时先不实现 64bit id 的类型。(以后再加)

最终的 Wire Protocol 是这样的:

阅读全文 "sproto 的实现与评测" »

July 24, 2014

设计一种简化的 protocol buffer 协议

我们一直使用 google protocol buffer 协议做客户端服务器通讯,为此,我还编写了 pbc 库

经过近三年的使用,我发现其实我们用不着那么复杂的协议,里面很多东西都可以简化。而另一方面,我们总需要再其上再封装一层 RPC 协议。当我们做这层 RPC 协议封装的时候,这个封装层的复杂度足以比全新设计一套更合乎我们使用的全部协议更复杂了。

由于我们几乎一直在 lua 下使用它,所以可以按需定制,但也不局限于 lua 使用。这两天,我便构思了下面的东西:

阅读全文 "设计一种简化的 protocol buffer 协议" »

July 23, 2014

给 skynet 增加 http 服务器模块

一直没给 skynet 加 http 协议解析模块是因为这个领域我不熟悉,而懂这块(web 开发)的人很多,随便找个人做都应该比我做的好。世界上的 web 服务器实在是太多了,足见做一个的门槛也不高,我也没什么需求,所以就这样等着有需要的人来补上这一块。

但这两天实在等不了了。我们即将上线的一款游戏,运营方要求我们提供一组 web api 供运营使用。固然我们可以单独写一个进程挂在 nginx 的后面,并和 skynet 通讯,但游戏开发组的同学觉得不必把简单的事情做的这么绕。监听一个端口提供 http 协议的服务又不是什么特别麻烦的事情,结果就打算直接在 skynet 里提供。

阅读全文 "给 skynet 增加 http 服务器模块" »

July 15, 2014

skynet 消息服务器支持

周末终于把上周提到的 短连接服务 实现了。由于本质上是一个消息请求回应模式的服务器,并没有局限于长连接还是短连接,所以不打算用短连接服务来命名。

用户的登陆状态不再依赖于是否有连接保持,所以登陆服务也顺理成章的分离出来了。

用户先去统一的登陆服务器登陆,获得令牌,然后去游戏服务器连接握手。如果用户和游戏服务器的连接断开,只需要重新用令牌握手即可,不必重新回登陆服务器登陆。

当然用户也可以重新登陆,清除登陆状态,完成一个传统意义上的下线再上线的过程。

阅读全文 "skynet 消息服务器支持" »

July 11, 2014

计划给 skynet 增加短连接的支持

不基于一个稳定 TCP 连接的做法,在 web game 中很常见。这种做法多基于 http 协议、以适合在浏览器中应用。

运行在移动网络上的游戏,网络条件比传统网络游戏差的多。玩家更可能在游戏进行中突然连接断开而导致非自愿的登出游戏。前段时间,我实现了一个库来帮助缓解这个问题

如果业务逻辑基于短连接来实现,那么也就不必这么麻烦。但是缺点也是很明显的:

每对请求回应都是独立的,所以请求的次序是不保证的。

服务器向客户端推送变得很麻烦,往往需要客户端定期提起请求。

安全更难保证,往往需要用一个 session 串来鉴别身份,如果信道不加密,很容易被窃取。


即使有这些缺点,这种模式也被广泛使用。我打算在下个版本的 skynet 中提供一些支持。

所谓支持、想解决的核心问题其实是上述的第三点:身份验证问题;同时希望把复杂的登陆认证,以及在线状态管理模块可以更干净的实现出来。

我不打算基于 HTTP 协议来做,因为有专有客户端时,不必再使用浏览器协议。出于性能考虑,建立了一个 TCP 连接后,也可以在上面发送多个请求。仅在连接状态不健康时,才建议新建一个 TCP 连接。

阅读全文 "计划给 skynet 增加短连接的支持" »

July 09, 2014

一个游戏的想法

自从去年底,我们公司的主要开发力量转移到移动平台游戏开发以来,我们的第四款游戏也快上线了。

第一款游戏:陌陌争霸、算是有所小成。这款初期复制 COC 的游戏为公司未来发展赚到了一笔钱,可以供我们稳定发展几年了。目前正朝着自己的游戏特色改变。

第二款游戏,天天来战、从亡灵杀手中获得启发,我们努力寻找着适合触摸屏操作的动作游戏形式。目前已经在腾讯的应用宝平台开始做初步测试,测试数据还不错,想来可以收回开发成本了。

第三款游戏,小倩去哪儿、综合了 Monster Strike 的战斗模式和刀塔传奇的数值系统;目前在陌陌平台做小规模测试。在第一批用户中拥有了最早的粉丝。我个人也在这款游戏中花了十多个小时的时间,除了初期难度过于简单外,还是对品质很满意的。

至于第四款游戏,争取在两个月内推出吧。


因为正在进行中的项目开发都还算顺利,我就不自觉的构思后面的产品了。目前公司没有生存之忧,我们的客户端和服务器引擎都非常稳定了。那么下一款产品,我希望能尽量的原创,而不是过多借鉴已存在的游戏。

当然,这不是我的主业。在我们公司内部,也有策划专值在考虑这类事情,做项目预研。我这纯粹是个人兴趣所致。所谓游戏创意这种东西,只要没有实现,是最不值钱的东西。我也不介意公开写写自己的想法,算是整理思路、做个记录。


我对移动平台游戏的兴趣来至于 Tiny Tower 这个小游戏,但真正打动我的是 Clash of Clans 。它让我重新体会到游戏的乐趣。所以我一直在试图思考移动平台上的游戏应该具备哪些特点。

  1. 游戏要始终保持有 30 秒到 5 分钟的持续玩法。强制过长的连续游戏时间是不合适的。

  2. 在第一次接触游戏时,应该有至少 1 个小时的流畅体验。中间可以让玩家有少许的等待,一两分钟的等待可以加强玩家的期待感。但不适合连续 1 、 2 小时给玩家灌输新概念。要留给玩家自我思考的空间。

  3. 当玩家疲惫时,让玩家主动离开,但游戏内容是带成长的、且成长不是随玩家的暂时离开而暂停的。同时需要有游戏机制可以召回玩家。召回时间分布在 4 小时、10 小时、24 小时的周期。

  4. 当玩家因为睡眠而需要长时间离开游戏时、一定要制造使命感和紧迫感。需要自我要求在睡觉前完成游戏任务。

  5. 游戏中要有一定的可挖掘的技巧性。玩家可以通过改良自己的操作和规划而提升游戏水平。


下面记录想法之一(非常粗糙,同时有不少设计上的 bug 需要推敲):

阅读全文 "一个游戏的想法" »

June 23, 2014

Linode 服务真不错

今天才发现 linode 出了 10$ 一个月的服务,同时以前 20$ 的服务硬件全面升级了。

反正我的主机用不了这些,翻墙看 youtube 都用不了每个月 3T 的流量。决定降级,可以便宜一点。在 linode 的管理面板上找到了 Resize ,从 linode2048 换到了 linode1024 。马上就成功了。

然后立刻收到了账单邮件。说是因为这个月还有一周,这周的原费用是 $5.34 ,新费用是 $2.67 。退了 $2.67 到我的账户里。:)

再帮它打个广告吧。作为一个在中国生活的程序员,购买一个 linode (我的 referral code : 538bab39bc1265a2ce54115d1f86e2bc81e4d133 ),上 google 必备。

Misc

Categories

Archives

Recent Comments