August 19, 2016

pvp 游戏如何解决玩家匹配等待时间过长的问题

按局打的纯 PVP 机制的游戏,面临最大的问题将是,在一个玩家想找人对战的时候,找不到对手匹配。

如果游戏的在线玩家达不到一定人数,那么这个问题会恶化:等不到人和你一起玩、放弃等待、新的玩家更找不到对手。

像皇室战争、王者荣耀、炉石传说这些火爆的 pvp 游戏都属于迈过了线的作品,玩家不太愁等不到人一起玩,提升了游戏体验,聚集了更多的玩家。而当玩家群有限时,同类产品就很难竞争,只要在线用户掉到一定限度以下,很可能导致(无非找到对手)体验下降,更多玩家流失。

那么,有没有办法解决初期玩家过少的问题呢?

直观的想法就是没人玩 AI 凑。可 AI 并不是真人,和 AI 在公平规则下对战乐趣会少很多,且高水品 AI 开发起来也非常困难。最关键的是,一旦玩家乐于和 AI 对战(无论是因为对战本身的乐趣,还是可以刷分刷掉落),你会进一步失去在线用户。

阅读全文 "pvp 游戏如何解决玩家匹配等待时间过长的问题" »

August 11, 2016

群星的汉化及其它

最近一个月,玩群星(Stellaris) 有点着魔。不同于 P 社之前我最喜欢的维多利亚2 ,这个上手更舒服。是我玩过的把大战略和 4X 结合的最好的游戏了。我很欣赏 P 社这种尽力降低玩家门槛的做法,让大战略和 4x 游戏不那么高冷,普通玩家也能很快领略其中的乐趣。

这里有我写了一篇评测。大致谈了群星是一个怎样的游戏,如何快速入门。小提示:即使是新手,也推荐用铁人/疯狂模式。第一次玩只需要把银河调小一点就好了。这样乐趣才能充分体现出来。

这次 P 社的引擎革新后,汉化变得很容易了。之前,大多数人和我一样使用的 3dm 版汉化 mod ;但这个 mod 翻译的时候,译者并没有怎么玩游戏,所以很多地方用词不当,还有一些仓促翻译导致的错别字。我实在受不了老式的闷头汉化的模式了,发现问题反馈到修正的周期太长,所以就自己维护了一个汉化 mod 。

需要的同学可以直接订阅。个人认为,利用 github 做合作创作,对于做汉化这件事特别合适。这个 mod 直接放在了 github 上

游戏文本的版本更新,可以直接体现在 diff 里。路人发现有错别字也可以顺手提个 pr 。而我自己一般是在玩游戏时瞟见翻译的不合理的地方,立刻打开文本编辑器校对一下。也正因为如此,游戏里出现的 event 都特别仔细的阅读;群星的开发者真是脑洞大开啊,游戏里的 event 涵盖了几乎我所有阅读过的科幻小说,看过的科幻电影的梗。光这一点就值回了票价。

在群星发布前,我还十分担心,如果没有了维多利亚里那种厚重的历史感,一个科幻题材的战略游戏该如何给玩家代入感;没想到它是通过这个手法来完美的解决了这个问题。

阅读全文 "群星的汉化及其它" »

July 13, 2016

在 skynet 中如何实现多 actor 协作的事务

今天在 qq 群中,有个同学问,在 skynet 中,如果多个 actor 需要协作时,能否有事务来保证一系列操作的过程中,状态不会被破坏。

他举了个例子:

如果有一段业务逻辑是:

local a = skynet.call(A, ...)
local b = skynet.call(B, ...)
if a and b then
  dosomething()
end

如何保证 a and b 这个条件有效呢?也就是说,在第一行从 A 处获取状态后,还要向 B 查询一个状态;如果希望两者查询完毕,一直到 dosomething() 结束前,A 和 B 的状态都不要改变。期间,如果有请求发到了 A 或者 B ,最后都暂时挂起。

阅读全文 "在 skynet 中如何实现多 actor 协作的事务" »

July 11, 2016

Skynet 1.0.0 发布

经历了 5 个 RC 版后,skynet 终于迎来了第一个正式发布版 1.0.0 。

目前这个版本基于 2012 年 7 月开始编写的代码,几乎从一开始就以开源模式发展。我们可以看到 2012 年 8 月 1 日在 github 上的第一次提交,到上周一正式版前的最后一次修改,已经过去了 4 年。

1403 次提交;

59 个代码贡献者;

3962 个 star ;

1850 个 fork ;

579 个邮件列表订阅者;

1700 个 qq 群成员。

阅读全文 "Skynet 1.0.0 发布" »

July 06, 2016

一元购庄家如何作弊

今天见同事贴了张照片,是网易大楼前有人拉横幅声讨“一元购” 这个产品的。

我之前没有听说过,上网搜了一下,发现最近搞这个的满多。大概就是说,每个玩家出一块钱买一个很贵的东西。然后系统把这些人凑在一起抽签,抽到谁谁就拿走那个东西。

比如一部手机卖 5000 块,有 5000 个人想买,一个人出一块钱,最后也只有一个人拿到货,其他人都损失了一块钱。

这不就是卖彩票么?

当然凑不到 5000 个人也没关系,系统(庄家)可以买走大部分票,这并不影响个人参与者中奖概率。当然,前提是庄家没有作弊,抽签是公平的。

阅读全文 "一元购庄家如何作弊" »

July 01, 2016

如何只基于请求回应模式实现 MMO 级别的场景服务

在上一篇 blog 里,我谈到游戏服务器其实只需要使用 req/resp 模式就够了。有同学表示不太理解,认为服务器主动推送,或者说 pub/sub 的消息模式必不可少。

在聊天中我解释了很多,是时候记录一下了。

从本质上来说,如果你只是想把一系列消息发送到客户端,req/resp 请求回应模式和 pub/sub 发布订阅模式并没有什么不同。你可以把 req/resp 理解成一次性的,只订阅一条(或有限条)消息;如果需要维持这类消息的推送,需要客户端在收到消息后再次发起订阅。

这和 timer 定时器系统一样,订阅一个定期触发的定时器这种功能并非必要。如果你需要一个每分钟触发一次的定时器,完全可以在触发一次定时操作后,立刻发起下一次定时任务请求。它在功能上是等价的。

潜在的实时性影响是:如果规定必须在收到回应消息后,才允许发起下一次请求;那么一个事件发生后推送到客户端的延迟可能增加了最多 2 倍。即,如果你刚刚回应了一条消息,这个时候又发生了新的事件;客户端需要在收到前一个事件后再提起新请求,然后你才可以把后发生的事件通过新请求的回应包发过去。

降低这个实时性影响的方法也很简单,协议上允许在客户端发起请求后未收到回应之前再次发起请求即可。对应同类消息许多少并发的请求,要根据这类消息的实时性要求有多高来决定。无限提高允许的并发量没有太大意义,毕竟物理上的延迟不可能完全消除。

阅读全文 "如何只基于请求回应模式实现 MMO 级别的场景服务" »

June 30, 2016

skynet 的一个简单范例

之前已经介绍过,skynet 只是一个轻量框架,不是一个开箱即用的引擎。能不能用好它,取决于使用者是否清楚知道自己要干什么,如果是用 skynet 做网络游戏服务器,那么就必须先知道网络游戏服务器应该如何设计。

在 skynet 发布版中带的 example 中,有类似 gate watchdog agent 之类的服务,它们并不是唯一的用 skynet 构建游戏服务器的模式。我想另外写一个范例,示范依旧基于 skynet 但用不同的模式构建游戏服务器的方法。

我花了两天时间写了这么一个 sample ,放在 github 上

阅读全文 "skynet 的一个简单范例" »

Misc

Categories

Archives

Recent Comments