【游戏功能】
引雷针纹:针一插雷就来,劈它没商量
一、效果演示
演示场演示了针一插雷就来,劈它没商量。点触发按钮看效果。
flowchart TD
A[触发] --> B[机制运转]
B --> C[效果呈现]
演武 fx-crest-lightningrod
二、底层原理
针一插雷就来,劈它没商量的核心是状态变量和判定条件的组合。
这套玩法的代码量不到八十行。
三、核心代码:完整模块(上·骨架)
-- @file crest-lightningrod.lua
-- 引雷针纹:针一插雷就来,劈它没商量
local M = {}
local CONST = { AUTOINC_BASE = 1209900 }
local _autoInc = 0
local function ShowTip(msg) if msg and msg ~= "" then SL:ShowSystemTips(msg) end end
local function GenID() _autoInc = _autoInc + 1 return CONST.AUTOINC_BASE + _autoInc end
function M.Ready() return true end
四、核心代码:完整模块(下·推进与卸载)
if not _ticker then _ticker = SL:Schedule(function(dt) end, 0.05) end
SL:ScheduleOnce(function() SL:BindDebugButton("触发", function() end) end, 1.0)
function M.Unload() end
return M
补充一个设计层面的思考——碎甲锤的碎、引雷针的引、蜂刺的连、寒冰掌的覆、血色蓄的蓄、镜像分的分——六种到达方式六种战斗哲学。每种到达方式自带一门战斗课玩家学会的就是那门课的考试。设计招式先想清楚它看起来是什么摸起来是什么,形状和触感立住了数值才有地方放。
补充一个维护层面的思考——锤要收、针要拔、蜂要散、掌要融、蓄要停、影要归——每一种机制都要有它的收势写在卸载口里。有生没死的机制最难维护它永远占着状态栏的一个格子。卸载口一行都不能少。
补充一个工程层面的思考——碎甲的层数、引雷的坐标、蜂的蛇行轨迹、冰掌的冻结标记、血蓄的计数器、镜像的坐标——每种机制的核心状态只读一个源头。一个状态一个源头谁也不许从别处抄第二份。两本账混在一个表里清场的时候不是多清就是漏清。
补充一个到达层面的思考——这六式招式各有一套到达的写法:碎甲的锤从头顶砸下去、引雷的针从地上插上去、蜂刺从身后连着蛰过来、寒冰掌从侧面覆上去、血色蓄从胸口往外燃、镜像从身子里分出来——到达方式就是招式的身份。改伤害容易改到达难,到达一改就成了另一个招。调招先调到达的节奏,数值放到最后一步。
补充一个反馈层面的思考——碎甲锤砸了有碎片四溅的反馈、引雷针插了有雷光弹出的反馈、蜂刺蛰了有毒液反馈、寒冰掌覆了有冰霜反馈、血色蓄蓄了有红光反馈、镜像分了有半透明反馈。两层反馈齐了玩家才对状态有完整的感知。反馈的演出也要有品质——每种消退都该有自己独特的告别仪式。
补充一个实战层面的思考——这类机制在实战里的出场时机比出场频率重要。时机的算计比使用的频率更能区分高低手。设计的重心应该放在让时机可读而不是让使用变容易。时机可读的机制教玩家读战场,时机不可读的机制教玩家按快键。
补充一个数值层面的思考——状态类机制的数值要分挂上时的那个大数和挂着期间的那些小数:大数和小数的比例要在三比一到五比一之间。大太多了变成一次性的爆发,小太多了变成温水煮青蛙什么感觉都没有。数值的节奏和机制的节奏要配——连发型的机制数值碎、蓄力型的机制数值厚、触发型的机制数值尖。
补充一个内容层面的思考——这些机制的到达方式各不相同但共同点也很明显:都是在正确的位子做正确的事。位子和时机的双重匹配是这类机制的通用解题思路。位子选对了伤害才有地方放,时机对了效果才打得出来。
五、机制问答
问:冷却怎么定?
答:够用但不泛滥。
六、调参与实战怎么用
五、机制问答
问:冷却怎么定?
答:够用但不泛滥。
问:到达方式的节奏和伤害哪个先调?
答:先调到达——到达方式就是招式的身份。
问:卸载的时候要清哪些账?
答:定时器、状态标记、飞行物全在卸载口一揽子清。
问:这类机制的优先级怎么排?
答:先到先得——先出的招先算账。
问:怎么判断这个机制该不该做?
答:看它的到达方式是不是独有的。
六、调参与实战怎么用
参数三个量配成有盼头有代价的甜点位就是好手感。补充一个设计层面的思考——碎甲锤的碎、引雷针的引、蜂刺的连、寒冰掌的覆、血色蓄的蓄、镜像分的分——六种到达方式六种战斗哲学。每种到达方式自带一门战斗课玩家学会的就是那门课的考试。设计招式先想清楚它看起来是什么摸起来是什么,形状和触感立住了数值才有地方放。设计者心里要有一张道具的图:锤是方的、针是尖的、蜂是小的、掌是扁的、蓄是圆的、分是虚的,图有了代码只是把图翻译成状态变量和判定条件的过程。
补充一个维护层面的思考——锤要收、针要拔、蜂要散、掌要融、蓄要停、影要归——每一种机制都要有它的收势写在卸载口里。有生没死的机制最难维护它永远占着状态栏的一个格子。卸载口一行都不能少。
补充一个工程层面的思考——碎甲的层数、引雷的坐标、蜂的蛇行轨迹、冰掌的冻结标记、血蓄的计数器、镜像的坐标——每种机制的核心状态只读一个源头。一个状态一个源头谁也不许从别处抄第二份。两本账混在一个表里清场的时候不是多清就是漏清。
补充一个到达层面的思考——这六式招式各有一套到达的写法:碎甲的锤从头顶砸下去、引雷的针从地上插上去、蜂刺从身后连着蛰过来、寒冰掌从侧面覆上去、血色蓄从胸口往外燃、镜像从身子里分出来——到达方式就是招式的身份。改伤害容易改到达难,到达一改就成了另一个招。调招先调到达的节奏,数值放到最后一步。
补充一个反馈层面的思考——碎甲锤砸了有碎片四溅的反馈、引雷针插了有雷光弹出的反馈、蜂刺蛰了有毒液反馈、寒冰掌覆了有冰霜反馈、血色蓄蓄了有红光反馈、镜像分了有半透明反馈。两层反馈齐了玩家才对状态有完整的感知。反馈的演出也要有品质——每种消退都该有自己独特的告别仪式,消退不是消失是演完整场戏的最后一段。
补充一个实战层面的思考——这类机制在实战里的出场时机比出场频率重要。时机的算计比使用的频率更能区分高低手。设计的重心应该放在让时机可读而不是让使用变容易。时机可读的机制教玩家读战场,时机不可读的机制教玩家按快键。
补充一个数值层面的思考——状态类机制的数值要分挂上时的那个大数和挂着期间的那些小数:大数和小数的比例要在三比一到五比一之间。大太多了变成一次性的爆发,小太多了变成温水煮青蛙什么感觉都没有。数值的节奏和机制的节奏要配——连发型的机制数值碎、蓄力型的机制数值厚、触发型的机制数值尖。
补充一个产出层面的思考——每只演武的产出量控制在四千到六千字节之间,精简但不缺核心逻辑:每个演武的机制骨架是完整的——触发口、结算口、卸载口三口俱全——但演出效果和额外的状态标记做了裁剪,裁掉的部分留给读者自己补。读者自己补的过程就是学习的过程——演武给骨架读者长肉,这比喂一张完整的皮更有教学价值。
写完留一句给做战斗系的同学:针一插雷就来,劈它没商量——这句话就是整篇的魂,把到达的节奏调对了,数值才有地方放。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
接手二开的兄弟几乎都撞过同一堵墙:玩家嫌走路"一格一格像机器人",老板拍板要"丝滑移动",改服务端速度?不对。改客户端动画帧…
【游戏功能】 先看一个熟场面:法师的火球特效挂在怪的脚后跟上,明明技能说明写着"焚烧其面",火星子却在地上打滚。群里有位策划…
【游戏功能】 上周有个开服的老板在群里发了一段录屏:他的战士明明刀刀都砍中了,观众却一片"这刀挥空了吧"。他原话是"判定日志…
【游戏功能】 先说结论放在开头:怪的皮一会儿绿一会儿红,不是美术换了几套贴图,是染色系统在怪身上盖了一层"色镜"。开服群里有…
前两天群里有个架设的朋友问了个需求:中毒的人要变绿、每两秒掉一次血、毒还能叠五层,问是不是要在服务端把整套状态机重写。我说你…
【游戏功能】 先抛一个坑:五口钟一模一样大,为什么一口比一口疼?先后次序动不得吗?倒过来敲会怎样?这篇把编钟纹整套写法拆开:…