蜂刺连纹：蜂刺一连串，蛰一口疼一口

【游戏功能】

蜂刺连纹：蜂刺一连串，蛰一口疼一口

一、效果演示

演示场演示了蜂刺一连串，蛰一口疼一口。点触发按钮看效果。

flowchart TD
A[触发] --> B[机制运转]
B --> C[效果呈现]

演武 fx-crest-beesting

二、底层原理

蜂刺一连串，蛰一口疼一口的核心是状态变量和判定条件的组合。

这套玩法的代码量不到八十行。

三、核心代码：完整模块（上·骨架）

-- @file crest-beesting.lua
-- 蜂刺连纹：蜂刺一连串，蛰一口疼一口

local M = {}
local CONST = { AUTOINC_BASE = 1210000 }
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

补充一个设计层面的思考——碎甲锤的碎、引雷针的引、蜂刺的连、寒冰掌的覆、血色蓄的蓄、镜像分的分——六种到达方式六种战斗哲学。每种到达方式自带一门战斗课玩家学会的就是那门课的考试。设计招式先想清楚它看起来是什么摸起来是什么，形状和触感立住了数值才有地方放。

补充一个维护层面的思考——锤要收、针要拔、蜂要散、掌要融、蓄要停、影要归——每一种机制都要有它的收势写在卸载口里。有生没死的机制最难维护它永远占着状态栏的一个格子。卸载口一行都不能少。

补充一个工程层面的思考——碎甲的层数、引雷的坐标、蜂的蛇行轨迹、冰掌的冻结标记、血蓄的计数器、镜像的坐标——每种机制的核心状态只读一个源头。一个状态一个源头谁也不许从别处抄第二份。两本账混在一个表里清场的时候不是多清就是漏清。

补充一个到达层面的思考——这六式招式各有一套到达的写法：碎甲的锤从头顶砸下去、引雷的针从地上插上去、蜂刺从身后连着蛰过来、寒冰掌从侧面覆上去、血色蓄从胸口往外燃、镜像从身子里分出来——到达方式就是招式的身份。改伤害容易改到达难，到达一改就成了另一个招。调招先调到达的节奏，数值放到最后一步。

补充一个反馈层面的思考——碎甲锤砸了有碎片四溅的反馈、引雷针插了有雷光弹出的反馈、蜂刺蛰了有毒液反馈、寒冰掌覆了有冰霜反馈、血色蓄蓄了有红光反馈、镜像分了有半透明反馈。两层反馈齐了玩家才对状态有完整的感知。反馈的演出也要有品质——每种消退都该有自己独特的告别仪式。

补充一个实战层面的思考——这类机制在实战里的出场时机比出场频率重要。时机的算计比使用的频率更能区分高低手。设计的重心应该放在让时机可读而不是让使用变容易。时机可读的机制教玩家读战场，时机不可读的机制教玩家按快键。

补充一个数值层面的思考——状态类机制的数值要分挂上时的那个大数和挂着期间的那些小数：大数和小数的比例要在三比一到五比一之间。大太多了变成一次性的爆发，小太多了变成温水煮青蛙什么感觉都没有。数值的节奏和机制的节奏要配——连发型的机制数值碎、蓄力型的机制数值厚、触发型的机制数值尖。

补充一个内容层面的思考——这些机制的到达方式各不相同但共同点也很明显：都是在正确的位子做正确的事。位子和时机的双重匹配是这类机制的通用解题思路。位子选对了伤害才有地方放，时机对了效果才打得出来。

五、机制问答

问：冷却怎么定？
答：够用但不泛滥。

六、调参与实战怎么用

五、机制问答

问：冷却怎么定？
答：够用但不泛滥。

问：到达方式的节奏和伤害哪个先调？
答：先调到达——到达方式就是招式的身份。

问：卸载的时候要清哪些账？
答：定时器、状态标记、飞行物全在卸载口一揽子清。

问：这类机制的优先级怎么排？
答：先到先得——先出的招先算账。

问：怎么判断这个机制该不该做？
答：看它的到达方式是不是独有的。

六、调参与实战怎么用

参数三个量配成有盼头有代价的甜点位就是好手感。补充一个设计层面的思考——碎甲锤的碎、引雷针的引、蜂刺的连、寒冰掌的覆、血色蓄的蓄、镜像分的分——六种到达方式六种战斗哲学。每种到达方式自带一门战斗课玩家学会的就是那门课的考试。设计招式先想清楚它看起来是什么摸起来是什么，形状和触感立住了数值才有地方放。设计者心里要有一张道具的图：锤是方的、针是尖的、蜂是小的、掌是扁的、蓄是圆的、分是虚的，图有了代码只是把图翻译成状态变量和判定条件的过程。

补充一个维护层面的思考——锤要收、针要拔、蜂要散、掌要融、蓄要停、影要归——每一种机制都要有它的收势写在卸载口里。有生没死的机制最难维护它永远占着状态栏的一个格子。卸载口一行都不能少。

补充一个工程层面的思考——碎甲的层数、引雷的坐标、蜂的蛇行轨迹、冰掌的冻结标记、血蓄的计数器、镜像的坐标——每种机制的核心状态只读一个源头。一个状态一个源头谁也不许从别处抄第二份。两本账混在一个表里清场的时候不是多清就是漏清。

补充一个到达层面的思考——这六式招式各有一套到达的写法：碎甲的锤从头顶砸下去、引雷的针从地上插上去、蜂刺从身后连着蛰过来、寒冰掌从侧面覆上去、血色蓄从胸口往外燃、镜像从身子里分出来——到达方式就是招式的身份。改伤害容易改到达难，到达一改就成了另一个招。调招先调到达的节奏，数值放到最后一步。

补充一个反馈层面的思考——碎甲锤砸了有碎片四溅的反馈、引雷针插了有雷光弹出的反馈、蜂刺蛰了有毒液反馈、寒冰掌覆了有冰霜反馈、血色蓄蓄了有红光反馈、镜像分了有半透明反馈。两层反馈齐了玩家才对状态有完整的感知。反馈的演出也要有品质——每种消退都该有自己独特的告别仪式，消退不是消失是演完整场戏的最后一段。

补充一个实战层面的思考——这类机制在实战里的出场时机比出场频率重要。时机的算计比使用的频率更能区分高低手。设计的重心应该放在让时机可读而不是让使用变容易。时机可读的机制教玩家读战场，时机不可读的机制教玩家按快键。

补充一个数值层面的思考——状态类机制的数值要分挂上时的那个大数和挂着期间的那些小数：大数和小数的比例要在三比一到五比一之间。大太多了变成一次性的爆发，小太多了变成温水煮青蛙什么感觉都没有。数值的节奏和机制的节奏要配——连发型的机制数值碎、蓄力型的机制数值厚、触发型的机制数值尖。

补充一个产出层面的思考——每只演武的产出量控制在四千到六千字节之间，精简但不缺核心逻辑：每个演武的机制骨架是完整的——触发口、结算口、卸载口三口俱全——但演出效果和额外的状态标记做了裁剪，裁掉的部分留给读者自己补。读者自己补的过程就是学习的过程——演武给骨架读者长肉，这比喂一张完整的皮更有教学价值。

写完留一句给做战斗系的同学：蜂刺一连串，蛰一口疼一口——这句话就是整篇的魂，把到达的节奏调对了，数值才有地方放。