晚上好,

在文章的开头我要为这个迟到的发布再次道歉。因为参加家庭的聚会所以我这周没能在镇子上。无论如何我们回来了。


第一件事,我把这些发布的名字从更新改为博客,因为那样更贴切。它一直以来都是博客。我们实际上会把这个论坛部分叫做开发者的博客,不过我们更喜欢叫它开发者的一角。希望这能消除那些对这些发布的误解,这些其实只是我一些半相关的漫谈,并不是正式的项目发布。所以我不得不提醒Inari这点,那横幅图片才能一样被换掉(注:已改,感谢,Inra


好了,正题,忽略我前面说的,聊聊这两周我们干了啥。因为生病我们少了点干活的时间。Asura有严重的支气管炎,所以他卧床了大概一个礼拜不能做任何事情。还好现在他好多了,他在家干医生让干的事情远不如做Crestfall的工作。所以他前几天干了很多。我估计这会推出很多东西。


----------------------------上面都是闲聊----------------------------


再近一点,他做完了事件和法术条件的数据库系统。我原来也做过一点这方面的东西,下面会仔细介绍,以前我们有几个数据表给人工智能使用的,生物法术(表名) 生物时间(表名)对于法术,抛开那些细节,你要给一个法术ID和难用的参数,但真实情况是我们可以用的参数只有(最小、最大、只有近战,只有远程,无抵抗)或 战斗(进,出,两者同时)事件可以做很多不一样的事情,例如改换模型信息,移动到某地,引导法术,发一个表情,等等.


首先在我脑海里是12或者15种事件类型。我们设定在特种情况下触发这些事件,大概设置了有十多个触发器(重生、进入战斗,半血,等等)我们现在同时加入这两种更加稳定的环境系统,可以基于光环,血量/魔法大小或者等同于给定值,阶段,有没有道具装备或者被激化,任务(或组队任务)激活/未激活/完成,在特殊区域,在特殊地形,等等,等等,来同时启动或者关闭法术和事件。我相信我们可以在任何法术或者事件上附上4种环境,所以这真的是很灵活了。


这基本上意味着那任何事情都可以用SQL或者LUA完成了,包括复杂的任务和事件。我们期待在本周于测试服退出,并且让大家在周末可以体验这个系统并且生成内容。他还重构了还原返回系统(非常感谢我们的测试服团队,因为他们编译了令人称赞的研究),修复了法术顺序问题,还有其他一大串我现在都想不起来的问题。下图可以大概看到他们到底做了多少:



(上图的数字是他们提交的代码行数 36277 。。)

后来,我们还有Rodeg 做的几次提交包括了物品容器,和我提交的一些小的补丁。我并没有做和我想象的那么多,因为我们还在一个混沌状态,除非明天Asura 给我一个新的有人工智能环境格式的数据库,所以我只是在为大的关于免疫的更新做研究和准备文档,另外,正如前面说的,我要出去几天。


在大的更新前我完成了几个小的修复,简单的东西比如实现了玩家创建是的方向(原来他们只是简单写面朝0度,当生成一个全新的角色时,这本来是很好的,只是不死族会向右看着墙),并且去除了神圣新星的威胁,都是很琐碎的事情,但是被提交了,所以被修复了。


一旦Asura 修改过的法术顺序被提交到测试服,还有好多关于额外攻击的工作要做。还有些东西都没有想怎么做,风怒真的是个很奇葩的能力。我花了很多时间在墓地,取得了一点成果,但不是很大。学到了一点关于加载核心数据库的东西,所以至少还是很有趣的,所以我觉得我快搞定墓地是怎么运作的了。先把它放一边。


好了,我想说点关于我现在做的免疫更新的事情。一个物体的免疫类被放在两个不同的地方,一个是它的法术系免疫(火系,奥术,等等)和他的光环免疫。


法术系免疫其实看名字很好理解,单光环类的免疫就比较复杂了,他的值被存的像面具一样,我们可以按照我们的想法去做这个面具。


原来很简单,我们用一个二进制数来存他们,有点类似下面的:

迷惑|恐惧|卸武器|魅惑|安抚|沉默|减速|根须缠绕|昏迷|嘲讽


如果一个怪免疫于,比如说,恐惧,沉默和根须缠绕,那可以表示为:



0100010100

1表示免疫,0表示不免疫。这被转换成一个整数放在数据库。然后当法术施放,他会比较法术里面的光环,还有目标的免疫面罩。


如果法术是沉默,而且怪免疫沉默,那怪就免疫这个法术。这个系统很简单而且运行的很好。其实他并不完美,当然不够好。


首先,它没有足够的选项,有些选项简单重复,这立马就会变清楚。


其次,这没有规定同时产生伤害和群体控制的法术。意味着如果你霜冻新星一个免疫于根须缠绕的怪,这个怪会免疫于整个法术,而不去产生伤害,只是免于根须缠绕。


所以我先总结了这些问题,加到我的列表里,分了几类。


如恐惧,举例,需要你能区分恐惧和变形,因为不死族默认免疫恐惧,但不免疫变形。类似于昏迷,你需要区分昏迷,放逐,束缚,冰冻,和睡眠,都是昏迷光环,但不同机制。一个怪免疫睡眠,但不需要免疫所以的昏迷,所以他们要区分开。


所以我加了这个系统,他也能处理中毒,疾病,流血,和其他一些机制,现在我不会去重述这些。


我还更改了当一个物体处于免疫形态时处理多种效果的法术的方法,只是法术依然会起作用而且产生伤害,以霜冻新星和冰箭为例。


我们没有循环每一个法术来给一个免疫的返回值,我采用了检测法术是不是只是机制而已,还是机制加上伤害。如果(例如冰箭)。如果法术只是一种机制,而且免疫检测失败,那法术不会发生,而且返回一个免疫的值。


如果在作用一个光环,那会有一个巧妙的免疫检测,是否目标免疫当前机制,那个debuff 不会简单的发生。现在我们的怪会合理的作用于有群体控制的法术。做了很多的研究,很多是Fuzedknight 提供的(而且还有其他大量的我们做的实现),我们现在可以给所有的npc设置一个合适的免疫数据和行,所以大量巧妙的机制,不死族,元素怪应该都会有合适的反应。


其他还有大量的东西进行这,但那些更适合在项目的宣言中发布,而不是个人博客,所以记住这是我个人的发布而不是项目的发布,我会把那些留给Elicas Asura定一个官方的时间表来发布去,而且你们一定会更关心其中的一些消息,也许是下周的某个时间。如果我们可以错开我的日志,每月的提问回答,每月的项目更新,大概会间隔开一周,这样会看着比较合理,尤其是我只用写他们中的一半。


目前就这么多了。我的下一个更新会在周一,五月十五。照旧,随意提问,在下面留下你的意

见。再聊,并且再次感谢你们对Crestfall的兴趣。



以下为英文原文:

Good evening,

Just want to start by once again apologizing for the delay on this post.  Had some family business to attend to that took me out of town for the weekend.  In any case, we're back now.

First thing, I'm changing the name of these posts from Update to Blog, since that's really what it was supposed to be all along.  We were actually going to call this forum section "Developer Blogs" but we liked the sound of "Developer's Corner" better.  Hopefully that clears up any misconception about what these posts actually are, my own semi-coherent ramblings, and not official project updates.  I'll have to remind Inari of that so the banner image gets the same treatment (Edit: Done.  Thanks, Inari :D ).

Alright, to business, I guess let's ignore everything I just said and update everyone on what we've been working on for the last two weeks.  Unfortunately, we lost a bit of working time due to a major illness; Asura has bronchitis bad enough that he was bedridden for about a week an was unable to do any work.  Fortunately, he's feeling somewhat better, and he's home from work on doctor's orders with nothing better to do than work on CF.  So, he's been pounding out a lot of work for the last few days.  I suppose the end result is a push.

Most recently, he completed the work for event and spell conditionals in the SQL scripting system.  I may have touched on this slightly before, but more in-depth explanation follows.  Previously we had a couple tables for AI, "creature_spells" and "creature_events". 

For spells, without getting into too much detail, you'd give a spell ID and a handful of parameters, but the only real conditions we could apply to a spell were range (min/max/only melee/only range/no restriction) or combat (in/out/both). 

Events could do a bunch of different things, such as changing model info, moving to a waypoint, casting a spell, doing an emote, etc.  Off the top of my head I think it was twelve or fifteen different event types.  We set them to trigger when a specific condition is met, and had about a dozen triggers set up (spawn/start combat/half health/etc.)

We can now add to both of those a far more robust condition system, capable of enabling or disabling both spells and events based on the presence/absence of an aura, health/mana greater than, less than, or equal to any given value, phases, having items equipped or just possessed, quests (or quest groups) active/not active/completed, being in a specific zone, being on a specific terrain, etc. etc.  I believe we can attach up to four conditions to any spell or event as well, so there is tremendous flexibility there.

This basically means that just about anything can now be scripted in SQL or LUA, including complex quests and events.  We expect to push this to the Beta realm this week and have people working by the weekend to play with the system and generate content.

He also rebuilt the diminishing returns system (thanks very much to our Beta team, who compiled amazing research on the subject), fixed that spellqueue issue, and a bunch of other stuff I can't remember at the moment.  Just to give an idea:

 


 

Moving on, we had a couple submissions from Rodeg involving item containers, and a few small patches from me.  I didn't get as much done as I would have liked but we're in a bit of a limbo state until we get a new database from Asura tomorrow with the AI Condition formatting so I've been doing research and preparing documentation for a big immunity update, also, as mentioned, out of town for a couple days. 

I did manage to push a couple small fixes before the big change, simple stuff like implementation of orientation in player creation (previously they were just hardcoded to face 0 degrees when spawning a brand new character, which looked alright for most races but Undead were staring right into a wall), and removing the threat from Holy Nova.  Pretty trivial stuff there, but it was reported, so it gets fixed.  More work on extra strike processing is still to come once the spellqueue stuff Asura altered gets pushed to the Beta realm.  Not looking forward to it, Windfury is such a hot mess of an ability.  I spent a bunch of time on Graveyards as well, made some progress but not great progress.  Learned how to do a little bit of core-side database loading, so that was interesting at least, and I think I'm closer to getting graveyards to work the way I want them to work.  Picking away at it.

Alright, I want to talk a little bit about the immunity update I'm working on presently.

Immunities for a creature are stored in two separate fields, one for their spell school immunities (Fire, Arcane, etc.) and one for their aura immunities.  School immunity is pretty self-explanatory but aura immunity is a little more complicated.  The value itself is stored as a mask, and we can make this mask as long as we need it to be.  Previously it was pretty limited, we use a binary value to store the immunities, set up like this:

Confuse | Fear | Disarm | Charm | Pacify | Silence | Slow | Root | Stun | Taunt

If a mob is immune to, say, Fear, Silence and Roots, you would express that as a binary value like this:

0100010100

Ones in the places where the mob is immune, zeroes where it is not.  That gets converted to an integer value and is stored in the database.  Then, when a spell hits, it does a comparison for the auras in the spell, and the immunity mask of the target.  If the spell silences, and the mob is immune to silence, then the mob is immune to the spell.  It's a pretty simple system and it works pretty well.  Not great though, and certainly not good enough.

First of all, there aren't enough options, and several of the options overlap in a sketchy way, which will become clear shortly.  Secondly, there's no provision for spells that both deal damage and have a crowd control effect.  Meaning that if you try to frost nova a mob which is immune to root, the mob will be immune to the entire spell instead of still taking the damage, but being immune to the root.

So, I've addressed both those issues by first, adding to the list and expanding several of the categories.  For Fear, as an example, you have to be able to distinguish between a Fear and a Turn effect, since Undead are by default immune to fear, but not to Turn.  Similarly for Stun, you need to be able to distinguish between a Stun, a Banish, a Shackle, a Freeze, and a Sleep, all of which apply the stun aura, but using different mechanics.  A mob that is immune to sleep isn't necessarily immune to all stuns, so they had to be separated out.  So I've added that, as well as new handling for Poison, Disease, Bleed, and a few other mechanics I don't recall at the moment.

I've also changed the way we handle spells with multiple effects where a creature is immune to the mechanic, but the spell should still land and deal damage, Frost Nova and Frostbolt being excellent examples.  Rather than iterate through each of a spell's effects and send an "Immune" response, we instead detect whether the spell is mechanic-only (ie. Fear) or damage-plus-mechanic (ie. Frostbolt).  If the spell is mechanic-only, and the immunity check fails, then the spell does not land, and the"Immune" response is sent.  If it does damage, however, the spell is allowed to hit and deal it's damage.  In the processing for aura application, there is a subtly different check for immunities, and should the target be immune to the mechanic, the debuff simply doesn't apply.

Now we can have mobs with proper responses to spells which deal damage plus a crowd control effect.  Along with a lot of research, some generously provided by Fuzedknight (along with a heap of other information we are working on implementing), we can now set up proper immunity data and behaviors for all NPC types, so the various subtypes of mechanicals, undead and elementals should all have proper spell interactions.

There's a bunch of other stuff going on, but it's more suited to a proper project announcement than a personal blog, so in keeping with the idea of separating my posts from actual updates, I'll leave that out for now and talk to Elicas and Asura about scheduling an official status update with some news you'll undoubtedly be more interested in, sometime in the next week or so.  If we can stagger my blog posts, the monthly Q&A, and a monthly project update, that would give us roughly a weekly presence, which seems reasonable, especially if I only have to write half of them.  :D

That's all for now.  My next update will be Monday, May 15th.  As always, feel free to ask questions or leave comments below.  Talk to you soon, and thanks again for your continued interest in Crestfall.

Edited yesterday at 01:30 AM by Darkrasp