合璧连纹：双侠纹光一接，合击翻倍

【游戏功能】

线上事故引入：早上比武场炸了锅——两位侠客的合璧纹贴出来，说好的逢四合击一记翻倍，实战里两人各砍各的，合击数字一次没蹦过。录屏逐帧看，两个人的出手节奏各走各的表，合击判定按的却是另设的一张表——三张表三套时间，永远对不齐。修完把合璧连击整套写法重写成篇：唤友入场、轮流出刀、逢四合击、同帧演出，一段一段照抄能跑。

一、效果演示

演示场原本只有一位侠客。点「唤队友!」：二侠从左侧入场，蓝光罩体——两人开始轮流出刀，你一刀我一刀，怪头上数字连成串。出刀满四记，合击来了：双侠同帧扬刀，紫光炸开，一记四十的大数字砸在怪头上，屏幕跟着一震。再点一次按钮送二侠离场，单刀照旧——合璧的分量，进出一对比就出来。

flowchart TD
A[唤队友] --> B[二侠入场蓝光罩体]
B --> C[两人轮流出刀]
C --> D[每记命中计数]
D --> E{数到四了吗}
E -- 没到 --> C
E -- 到了 --> F[双侠同帧扬刀]
F --> G[合击一记四十]
G --> C

 fx-crest-duet

二、底层原理

合璧系统的机关是"同表同拍"——那场事故的根因就是三张表：甲侠一张出手表、乙侠一张出手表、合击判定再一张表。正解是把拍子收进一张表：每一记命中的计数只有一处，数到四的那一拍就是合击的拍，两人的扬刀动画、合击数字、震屏全挂在这一拍上。同帧不是两个人同时出手那么简单，是两个人在同一个结算拍里出招——演出同帧，账才同帧。
唤友是这套玩法的开关：队友在场，出手翻密、逢四翻倍；队友离场，单刀照旧。合击的四十要压得住分量——它是四记十四攒出来的一记重音，比四刀加起来多出一截，多的那截就是"合"的价值。演出的语言要成对：双侠同扬刀、紫光炸开、大数字、震屏，四件一起上，缺一件合击就轻了。幂尔框架这边计数收在一个入口，唤友送友各一个按钮，三张表的教训写进了结构里。

这套玩法的代码量不到一百行，难的不是两个人而是三张表并一张——拍子只有一个出处，合击才同帧。

再看合击计数的清零时机——为什么逢四合击之后计数继续走而不是清零重来？因为"逢四"的节奏感来自连续：数四、合击、数四、合击，玩家的心拍跟着计数走，合击是数出来的重音。清零会让节拍断一口气，玩家要重新找拍。计数只在队友离场时归位——离场重进是新的合璧，账才从头起。这条和乐队的节拍器一个道理：拍子不停，重音才有位置。

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

-- @file CrestDuet.lua
-- 合璧连纹 —— 双侠纹光一接 合击翻倍

local CrestDuet = {}

local CONST = {
    COMBO_EVERY   = 4,
    STRIKE        = 14,
    COMBO_DMG     = 40,

    AUTOINC_BASE  = 1199850,
}

local _ally     = false
local _n        = 0
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 CrestDuet.HasAlly() return _ally end
function CrestDuet.Count() return _n end

-- 命中结算：计数与合击同一拍
function CrestDuet.OnHit()
    _n = _n + 1
    if _ally and _n % CONST.COMBO_EVERY == 0 then
        ShowTip("合击!双侠同斩一记" .. CONST.COMBO_DMG)
        return CONST.COMBO_DMG
    end
    return CONST.STRIKE
end

四、核心代码：完整模块（下·推进与卸载）

-- 唤友送友一个开关
function CrestDuet.Toggle()
    if _ally then
        _ally = false
        _n = 0
        ShowTip("二侠退场——单刀照旧，计数归位")
    else
        _ally = true
        ShowTip("二侠入场!两人合璧，逢四合击")
    end
end

SL:ScheduleOnce(function()
    SL:BindDebugButton("唤队友!", function()
        CrestDuet.Toggle()
    end)
    ShowTip("技能已加载: 合璧连纹")
end, 1.0)

function CrestDuet.Unload()
    _ally = false
    _n = 0
end

return CrestDuet

五、机制问答

问：那场合击失灵的事故根因是什么？
答：三张表三套时间——出手两张、判定一张，永远对不齐。正解是拍子只留一个出处。

问：合击的四十为什么比四刀加起来多？
答：多出的那截是"合"的价值——四记攒出一记重音，不超一点合击就没了分量。

问：合击之后计数为什么不清零？
答：逢四的节奏靠连续——数出来的重音才踩在玩家的心拍上，清零就断一口气。

问：计数什么时候归位？
答：队友离场归位——离场重进是新的合璧，账从头起。

问：合击的演出为什么四件齐上？
答：同扬刀、紫光、大数字、震屏缺一就轻——成对的语言才撑得起"合"字。

六、调参与实战怎么用

参数层面三个量——合击间隔、单刀伤害、合击伤害。间隔定在四：二太密五太磨，四刚好是玩家数得过来的拍子。实战里这套同表同拍的骨架能搬去双人合技、援护攻击、连携奥义，全是多角色一张表一条线。常见坑两个：各角色各一张时间表，合击永远对不齐；合击伤害压得和普通刀一样，合了个寂寞。

补充一个设计层面的思考——这类伴随式数值的反馈要分成两层看：即时层是每一刀的飘字和小涨，延迟层是攒满之后的那一下质变。即时层管手感，延迟层管目标，两层各发各的，节奏就不糊。怕的是只有即时层没有目标，玩家砍着砍着就腻；也怕只有延迟层没有手感，攒的过程成了干熬。

补充一个维护层面的思考——带计时和进度的状态，卸载的时候要三清：计时的表清零、进度的条清零、演出的残留清掉。清不干净的这两种状态最会闹鬼——重载之后计时器双份跑、进度条带着旧值进新局，玩家看到的现象邪门到没法报。卸载入口一行都不能省。

补充一个工程层面的思考——伴随式系统的结算入口要收成一个：挨打走一个口、命中走一个口，涨多少、判满、给奖全在口子里办。口子收齐了，改数值动一处，查账看一行，回归测一个函数。结算散在流程各处是这类系统闹账的根，收口一次全年清净。

写完留一句给做合击系的同学：合击合的不是两个人的动画，是同一张表上的同一拍——拍子只留一个出处，"合"字才立得住。