名将三国Q数值策划部分逆推

一月 7th, 2010 — 11:21下午

距离上一篇日志更新过去了5个月了,我为什么要开博客啊啊啊啊啊…<囧>…好吧,离2012年世界毁灭时日无多了,少说废话,直接进入正题。

Image00372

明天是名将三国公测的日子,这是一款类似于DNF的横版过关类MMO,宣传上九城砸了大把的银子,还以购买2亿Q币奖励DNF玩家为题材进行了一次网络炒作,效果还不错。而这次宣传里一个亮点就是引导小游戏“名将三国Q”,一个以名将三国为题材,仿”推推”的无操作格斗类游戏(格斗居然不要操作—  —)。此游戏目的有二:其一,这款游戏上手极易,可以吸引不少的轻度玩家,给还没进入名将三国的玩家一个大概的认识,再进入名将三国时就会有一种熟悉感。其二,维持封测、内测老玩家的热度,保住人气。之前大部分网游,封测内测完了之后总需要几个月的时间收集bug、玩家意见等进行调整,而玩家不可能每天都上官网来看看开服了没有,久而久之不少玩家热度没有了,或者找到其他同类化网游替代,于是玩家就流失了。而名将三国Q可以让老玩家解解馋,每天登录能战5局。开服日期一确定,立即以公告的形式每天出现在游戏的界面里,新老玩家立马知道啥时候开服,开服人气一高涨,游戏就成功一半了…

当然,以上都是建立在这个小游戏足够吸引人的前提下的,而名将三国Q无疑做到了,精致的画面、简单的上手及黏性强的系统,实在是对九城又刮目相看了。然后,venjet决定逆推一把游戏里的数值。 Continue reading »

Comment » | Game Design

数值策划常用数据库语句

九月 23rd, 2009 — 5:46下午

数值策划常常要与数据库打交道,最常见的就是每过一段时间针对游戏日志信息进行统计分析。这篇可以算是一个备忘录,venjet用到什么不容易记住语句就把它记录到这里,以后找起来也方便。对于数据库熟悉的不需要看,对数据库不熟悉的需要学习一下基础知识。所以,这篇应该算是自用的备忘(路人甲:那拜托你设成private啊private…)

1 常用函数

count()-计数

sum()-求和

min(),max()-最值

avg()-平均值

day()-取时间字段的天值,同理还有month(), year()…Access有DateValue()函数,可以根据字段内容转换成相应格式的日期。

hex()-十进制转为十六进制

left(a,b)-返回字符串a左起b个字符的部分。同理还有right()(关于中文字是1个字符还是2个字符的问题,与数据库的定序(COLLATE)有关,用的时候问下程序就行。)

举例

SELECT count(*) as 计数,sum([Money]) as 总和,min([Money]) as 最小值,max([Money]) as 最大值,avg([Money]) as 平均值

FROM dbo_MoneyLog_2009_05

WHERE ((dbo_MoneyLog_2009_05.[why])=”任务添加”) Continue reading »

Comment » | Technology

合成概率与玩家心理

九月 21st, 2009 — 2:15下午

venjet标题党的习性再度发作,不起一个这样的名字就浑身不舒服…打住,先看例子:

给玩家一份材料,情况1:合成装备A有70%的概率成功;情况2:给玩家两份材料,合成装备A有35%的概率成功。这两种情况是否一样?

从总体上来看,70%的情况下,合成10次,会有7个成品,而20次,35%的成功率,也有7件成品,对于产出来说是一样的。但对于玩家来说就有较大的区别了:情况1失败的几率是30%,情况2完全失败的概率是(1-35%)^2=42.25%,比情况1多了12%的失败率!造成这种情况的原因简单来说是情况2合成两次,因此有三种可能:失败两次、成功一次、成功两次,而成功两次的概率把成功一次的概率“吃”掉了,所以失败的概率更高,其实也就是正态分布的问题。这个例子里,显然30%的失败概率更容易让玩家接受。以下是两种不同概率下的产出分布,X轴是成品的数量,Y轴是出现的几率。情况1合成10次,情况2合成20次,期望是7件成品,可以看到情况2较情况1更为分散,而情况1更容易达到我们的预期。

compound-probability

Continue reading »

1 comment » | Game Design

Dogma 2001:游戏设计师的10个教条

七月 25th, 2009 — 6:52下午

啊,被挑战了…

事情是这样的,Lars von Trier和Thomas Vinterberg这两个丹麦导演在吃饱了撑着没事干认真审查了电影业发展的情况后,觉得电影发展已经越来越依靠各种技术带来效果而忽略了电影的本质,于是提出了一个挑战“Vow of Chastity”(守节誓言),包含十条近乎荒唐的教条,venjet就不贴在这儿吓人了,有兴趣的去这里看。遵守这十个教条并通过认证的电影可以挂名“Dogme”(丹麦语,教条)电影(比如1,2,3),如果不知道Dogme这事的话,常常被人误认为“小成本制作”…顺便一提,Dogme 95的官网已经挂了…

然后,前牛蛙工作室首席设计师Ernest Adams仿照Dogme 95对所有的游戏设计师提出了挑战——Dogma 2001,同样也是十个教条(传送门):

  1. 设计文档不应提供任何对目标机器内部部件的说明。控制设备和显示器可以在讨论操作界面时提及,最低系统配置应由程序师在开发过程中决定。(这点venjet比较赞同,不过似乎目前国内也都是主程说了算…)
  2. 禁止任何形式的3D硬件加速。可以使用软件渲染的3D引擎,但必须保证游戏在640×480分辨率、16位色深SVGA模式下帧速达到20帧/秒或相当的水平。 Continue reading »

2 comments » | Game Design

小议游戏的双层计算结构

五月 11th, 2009 — 9:53下午

游戏魂的论坛上看到了某个网游公司的一道数值面试题,如下:

很多游戏的角色数据采用双层计算结构
第1层——等级、力量、敏捷、智力、精神、耐力等等
第2层——攻击力、攻击强度、防御力、格挡、生命、法力、韧性等等
问1    你认为双层数据之间的逻辑关系是什么
问2    说明这种双层计算结构的优缺点

venjet是在鼠年快结束的时候出生的,也就是牛年快开始的时候,所以爱钻牛角尖…(不许怀疑我的逻辑)

很明显,这道题如果找一个能说服自己的答案的话,还是很容易的,比如用双层数据的话人物属性面板好看一点,各种数据更直观一点,公式看起来有深度一点,爆好装备的时候属性可以更多一点,玩家加错点的机会更多一点,设计技能道具的时候能用的数值也多一点…

而且我们可以举一个简单的例子来说明单层结构也能实现双层结构的功能:

———————————我是双层结构的分割线————————————

假设,战士的力量为P,攻击力计算公式:最终攻击力Att=P*系数+各种加成(武器,道具,技能等)

法师的耐力为Q,防御力Def=Q*系数+各种加成

假设该游戏所有攻速都一致,用个简单点的加法伤害公式:伤害Dam=Att-Def

———————————我是单层结构的分割线————————————

守方伤害Dam=攻方力量P*系数+攻方各种加成-守方耐力Q*系数-守方各种加成

区别仅仅在于是否有一个地方显示最终攻击力和防御力…

真的是这样吗?以下是思考时间

……
Continue reading »

1 comment » | Game Design

Back to top