基于浏览器的持久性游戏:要验证码还是不验证码?


12

我一直在(断断续续地)研究一个很老的pbbg。如果您曾经玩过Carnage Blender,那么您就会明白。

如果没有,那么这是一个简单的想法,它已经完成了很多工作:每天为一个玩家分配一定数量的“点”,并花费这些点来攻击其他玩家。积分会随着时间累积,直至达到一定上限。

积分系统旨在防止成绩过高的人完全超越休闲运动员。

对于屠杀搅拌机,CAPTACHA系统可防止用户使用被设计为每天以最少的精力每天使用其所有点的机器人或脚本对系统进行“游戏”。偶尔会显示一次随机的验证码,如果未通过,用户将被暂停一个小时。

我想知道的是如何使它对我的游戏更加用户友好。我认识到我必须防止这种不良行为,并且我可以轻松地采用相同的CAPTCHA方法,但是是否有更用户友好的替代方法?

最初的研究发现了Microsoft的ASIRRA,但蓬松/可爱的氛围无法与我想要的游戏主题配合​​使用。

更新
我最感兴趣的是标准“拼写这个单词”验证码的替代方法。我想尝试让优秀的玩家尽可能不间断地进行游戏。

我已经看到了我所谓的一次性验证码,就像问一个用户“ 5加6减2是多少?” 但这将需要大量的精力来编译足够大的问题数据库,以阻止恶意用户。尤其是因为打算经常使用CAPTCHA。

更新#2
正如Joe Wreschnig在他的回答中指出的那样,如果每天限制转弯,那么拥有一个验证码系统来限制机器人玩游戏的速度要比人类一点。我没有向我解释积分系统,这是我的错。实际上,每几分钟就会累积10或20分,而最高只能达到200分。因此,一个非常有竞争力的玩家可以每隔几小时返回一次并使用他的积分。我想奖励那些非常喜欢我的游戏的人,以至于他们经常回来。如果我阻止他们玩到第二天,直到他们获得积分,我就会拒绝那些原本会喜欢我的网络游戏的玩家。这样可以防止玩家不断花费积分,同时仍每分钟给他们分配一些积分。

这很容易被滥用。


1
重新更新2:您描述的积分系统目标简化了:“我想奖励平均每天玩2.4次以上的玩家。” 为什么?您为什么要关心他们一天只玩2.4次而不是一次?您说“我想奖励喜欢我的游戏的玩家”,但是无论我一天登录5次还是仅登录一次,这都不代表我对自己的游戏有多喜欢。考虑一下您实际上在这里做什么以及为什么这么做。然后找到另一种方式来做到这一点,这样您就不必想出每天2.4次的积分系统来鼓励您的玩家去玩机器人了。
doppelgreener

1
我希望您能真正认识到,每天需要2.4次访问才能获得最佳比赛效果,因此可以鼓励比赛,因为很多人无法做出承诺。甚至没有必要:您只能通过机器人和潜在玩家的疏远来实现目标!考虑一下《厌恶王国》(Kingdom of Loathing),这是一款非常成功的游戏,每天可以为您提供40个回合(包括物品在内)。上限为200,您一次最多可以等待5天。混沌王国做了类似的事情。双方都没有对频繁比赛给予任何特别的奖励,但是双方都每天都有多次登录的玩家。
doppelgreener

@Jonathan:通常,您关心人们是否平均每天登录x次的原因是,您需要根据已获得的广告费率使游戏盈利。KoL的获利策略是游戏内购买,因此不适用。

1
@乔:我会考虑一种替代性的广告/货币化策略,请记住,当我不疏远玩家时,由于玩家数量的增加,我实际上可能会展示更多的广告。如果我的游戏是成功设计,在那些参观,每天数次将这样做无论如何 -因为他们喜欢的游戏,他们选择,而不是因为游戏机制是透明迫使他们入如此做(注:这意味着斯蒂芬不会奖励“那些非常喜欢我的游戏的人”,而只是“那些我的压力技师在上面工作的人”
doppelgreener

Answers:


8

“有没有更人性化的选择?”

更人性化的替代方案是什么?在系统中设计的验证码是什么?

在机器人可以比普通玩家“更快”玩游戏的前提下,这听起来像是在防止机器人攻击。但是您也已经限制了用户每天可以执行的操作数,从而实现了相同的目标。因此,验证码似乎多余。

我鼓励您看一下《厌恶王国》的备用前端。它使用类似的每日轮流系统,并具有几种流行的替代前端,例如KoLmafia,在很多方面都与“装瓶”游戏没有区别。大多数玩家都觉得这些对游戏有所助益,即使是休闲玩家也是如此。它们使批处理操作变得更容易,使一些较慢的部分自动化,并为游戏内UI提供了更多选项。

如果您已经在游戏中进行了检查以确保AI不能简单地玩过比人类更快的游戏-并且通过每天轮流来进行检查-那么我建议您尝试鼓励游戏自动化,就好像您的设计是平衡,只能改善玩家体验。


1
很好的见识! 每天的营业是令人误解的,那是我的错。我将更新问题以进行详细说明。
斯蒂芬2010年

我越想这件事,就越喜欢。我将不得不再考虑一下,让这个问题在这里稍加讨论。
斯蒂芬2010年

1
例如,KolMafia的自动战斗系统非常有用,以至于它们实际上将战斗宏系统集成到了真实游戏中。
coderanger

我记得在RuneScape上,精灵有一些简单的问题,如果您答对了,他会给您礼物。
乔纳森·康奈尔

3

我永远不会费心去玩需要验证码的游戏:它们确实是一种可怕的做法,应该避免。

无论如何,您的游戏似乎比这还存在更深的问题:理想情况下,游戏不应使愚蠢的机器人受益,因此首先使用愚蠢的机器人毫无意义。如果无法实现,那将是一个设计问题,将没有真正的解决方案,只有或多或少的有效解决方法。

所谓“愚蠢的机器人”,是指没有做出任何有意义决定的机器人,而只是“农场”(在这里发生的事情)。智能机器人(例如瞄准机器人或国际象棋机器人)是完全不同的事情。

不过,假设您对制作具有设计缺陷的游戏的想法感到满意,那么仍有改进的空间。

接受一个事实,即您不能停止真正确定的机器人,而要专注于您唯一可以做的事情:使它无法使用机器人。如果人们没有理由使用机器人,那么他们将不会使用它们(如果他们仍然这样做,那将无关紧要)。

一种可能的解决方案是允许每周一次登录而不是每天一次登录。如果人们会忘记登录超过一个星期,那么他们不太可能对玩游戏真正感兴趣,因此他们将不会使用机器人来获得积分。另一方面,如果有人搞砸了,使得该机器人每周记录一次,然后在三个月后回来攻击随机的人,那么,您刚刚发现一个如此确定的人,无论如何都会打败您您选择的系统(当然,除非您选择一个无缺陷的系统)。

ps:不要犯下将更多的精力放在变通的设计缺陷上,然后首先解决它们的错误!


1
“理想情况下,游戏不应让愚蠢的机器人受益,”好的建议+1
Stephen

好的建议,但人类无法实现?
卡扎伊2011年

完全可以实现的,您只需要做一些实际的游戏设计,而不用编写随机代码即可。质量成本。
o0'。

2

我不会禁止失败的CAPTACHA一小时,这看起来很严酷,我只是阻止他们前进,直到他们成功完成CAPTACHA并允许显示新的CAPTACHA图像为止。

如果他们提出请求的速度过快,我也只会显示验证码,我会在每个请求上存储一个DateTime,然后将其与下一个请求进行比较,如果它少于2-4秒,则显示CAPTACHA,否则让他们去。您需要确定游戏,服务器和带宽的合理间隔。

您还可以每执行一次X次就执行一次“强制” CAPPTACHA,这甚至可以防止带有pause内置脚本的自动脚本,因此不会触发CAPTACHA的时间限制。


对。这些都是使CAPTCHA 更加用户友好的有效思路,并且如果我走CAPTCHA路线,那么我当然会实施诸如此类的概念。我正在寻找的是不错的选择,如果有的话。
斯蒂芬

用Flash或Silverlight编写游戏,这样机器人就很难控制您的应用程序了吗?
Nate

我对此了解不多,但是KingsOfChaos.com与您的系统非常相似(每分钟指向/转弯),您可以看到他们是如何实现的。
Nate

2

如果玩家花费点数来攻击其他玩家,并且点数受到限制,那么在我看来,明显的滥用是创建多个帐户。

如果您成功地将人们限制在一个帐户内,那么机器人的问题就在于,在您的系统下,人们可以在他们睡着或工作时将他们开除。

因此,鉴于以下限制因素:(1)僵尸程序没有优势(2)每天多次登录奖励用户

在我看来,理想的事情是将他们每天可以使用的操作数限制在合理的数量之内。

例如,您可能认为某人可以在8个小时内合理地多次登录,并适当地调整系统。否则有人可能会在早上去学校/工作之前进行检查,回家后进行检查,晚餐后再次进行检查以及上床睡觉之前进行检查。

确定您的“理想”用户在做什么,然后使积分系统对其进行奖励。


我会建立一个奖励一次性使用大量积分的系统。为此,我要在各个点上设置可变的充电率。每当您花费积分时,获得下一个积分的充电时间就会增加...因此,如果机器人花费的积分与其获得的积分一样快,那么获得下一个积分的时间就会越来越长,而如果一个人花了所有的积分当他们整夜积累到早上离开家之前的时间点时,他们将在下班/上学回家时(8-12小时后)将他们全部收回。


我从来没有想过根据使用情况而定的可变充电率。乍一看听起来很天才。我得考虑一下。TBH,它会奖励休闲玩家并惩罚硬核/死硬玩家,所以我不知道。
斯蒂芬

2

在游戏中,我建议将“验证码”替换为“益智迷你游戏”。不同之处在于所涉及的乐趣水平。除非您尝试了自定义的迷你游戏,但实际上仍然没有理由在游戏中进行验证码。在这种情况下,它需要更明智的策略。


1

正如Tchalvak所建议的那样,我会走“益智迷你游戏”路线,但是我会通过传递一些奖励,以使其更加人性化

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.