5.1.4 Cooldowns

Why Cooldowns Matter in Combat

Cooldowns are delays that prevent a player from using an action again immediately. In Roblox combat systems, cooldowns keep gameplay fair, readable, and more strategic. Without them, powerful attacks could be spammed, fights become chaotic, and players cannot predict each other’s options.

A cooldown creates a simple rule. After using an ability, the player must wait a fixed or calculated amount of time before using it again. This waiting period is the cooldown. In code, this is usually represented by a time stamp, a boolean flag, or both.

You will often connect cooldown logic to your melee or ranged combat abilities, and also to the UI that shows ability readiness.

Basic Cooldown Logic

At the core of any cooldown is a way to store whether an ability can be used. The simplest form is a boolean value that you check before performing the action, then set to false when used, and set back to true after some delay.

A very simple pattern looks like this:

local cooldownTime = 2
local onCooldown = false
local function useAbility()
    if onCooldown then
        return
    end
    onCooldown = true
    -- perform attack here
    task.delay(cooldownTime, function()
        onCooldown = false
    end)
end

This pattern is important because the ability is blocked at the very beginning of useAbility. If the cooldown is active, the function exits early. Only if the ability is available do you set the cooldown and continue.

You can also use time stamps. You store when the ability will be ready, and compare with the current time using tick() or os.clock().

local cooldownTime = 2
local nextReadyTime = 0
local function useAbility()
    local now = os.clock()
    if now < nextReadyTime then
        return
    end
    -- perform attack here
    nextReadyTime = now + cooldownTime
end

With this approach, you never flip a boolean back. Instead you always compare the current time with nextReadyTime.

Fixed vs Dynamic Cooldowns

Some cooldowns are constant. For example, a sword swing might always require a one second wait. Other cooldowns change based on conditions, such as the player’s level, how many combo hits they have, or whether they activated a buff.

For a fixed cooldown, you just keep one value like local cooldownTime = 1.5.

For a dynamic cooldown, you compute the actual value at the moment the ability is used.

local baseCooldown = 4
local function getCooldownTime(player)
    local level = player:FindFirstChild("Level") and player.Level.Value or 1
    local reduction = math.min(level * 0.05, 0.5)
    return baseCooldown * (1 - reduction)
end
local nextReadyTime = 0
local function useAbility(player)
    local now = os.clock()
    if now < nextReadyTime then
        return
    end
    -- perform ability here
    local actualCooldown = getCooldownTime(player)
    nextReadyTime = now + actualCooldown
end

This pattern allows you to tie cooldowns into your broader stat system, shop upgrades, or power ups without changing the structure of the cooldown itself.

Server Side vs Client Side Cooldowns

In multiplayer combat, cooldowns must be enforced on the server, not only on the client. If the cooldown only exists in LocalScript, exploiters can bypass it and send remote events as fast as they want. The server should always be the final authority that decides whether an ability is ready.

A common structure is to keep the visible feedback for cooldowns on the client, but the actual trusted check on the server.

On the client, you might send a request to use an ability when the player presses a key:

-- LocalScript
UserInputService.InputBegan:Connect(function(input, gpe)
    if gpe then return end
    if input.KeyCode == Enum.KeyCode.Q then
        RemoteEvent:FireServer("UseAbility")
    end
end)

On the server, you check the cooldown for that player and decide whether to allow the attack:

-- Script
local playerCooldowns = {}
local COOLDOWN_TIME = 3
local function canUseAbility(player)
    local now = os.clock()
    local state = playerCooldowns[player] or 0
    return now >= state
end
RemoteEvent.OnServerEvent:Connect(function(player, action)
    if action == "UseAbility" then
        if not canUseAbility(player) then
            return
        end
        playerCooldowns[player] = os.clock() + COOLDOWN_TIME
        -- perform server side attack logic here
    end
end)

The client can still track a local copy to show a cooldown bar or icon, but it should never be trusted for game rules. The server check is the one that prevents exploits.

Cooldowns Per Ability and Per Player

In a combat system, each player usually has multiple abilities. Each ability needs its own cooldown. A common approach is to store a table per player, keyed by ability name, holding the next ready time.

For example:

local playerCooldowns = {}
local DEFAULT_COOLDOWNS = {
    Slash = 1,
    HeavySlash = 3,
    Dash = 2
}
local function canUseAbility(player, abilityName)
    local now = os.clock()
    local data = playerCooldowns[player]
    if not data then
        return true
    end
    local nextReadyTime = data[abilityName] or 0
    return now >= nextReadyTime
end
local function setCooldown(player, abilityName)
    local now = os.clock()
    playerCooldowns[player] = playerCooldowns[player] or {}
    local abilityCooldown = DEFAULT_COOLDOWNS[abilityName] or 1
    playerCooldowns[player][abilityName] = now + abilityCooldown
end

Each time the player uses an ability, you first call canUseAbility, then after performing it you call setCooldown. This gives you independent cooldowns for each ability. A heavy attack can be locked out while a lighter attack remains available.

You might also want shared cooldowns, where using one ability affects others. For example, using a dash might put all movement abilities on cooldown. In that case, your setCooldown function sets multiple entries at once.

Cooldowns and Animation Timing

In combat systems, cooldowns need to feel connected to the animations. If the cooldown ends before the animation finishes, players might press the button and see nothing happen because the character is still locked in a previous animation. If the cooldown ends much later than the animation, the move can feel sluggish.

A simple approach is to base the cooldown on the animation duration. Suppose your attack animation is 0.7 seconds long. You might make the cooldown equal to or slightly longer than that animation.

If you have a reference to an AnimationTrack, you can read its Length and use that to set your cooldown.

local animationTrack = humanoid:LoadAnimation(attackAnimation)
animationTrack:Play()
local cooldownTime = animationTrack.Length + 0.3
nextReadyTime = os.clock() + cooldownTime

This helps the combat feel tight and responsive because the cooldown respects how long the character is visually committed to the attack.

Communicating Cooldowns Through UI

Cooldowns that are invisible are confusing. Players need to see when an ability will be ready again. Typical patterns in Roblox combat games include greying out ability buttons, showing a fill bar, showing a countdown number, and playing a small sound or flash when the ability becomes ready.

On the client side, you can receive information from the server about the length of a cooldown and the time it will be ready. Then you update the UI each frame to match.

Suppose the server fires a remote event to the player after an ability is used:

-- Server Script
RemoteEvent:FireClient(player, "AbilityCooldown", "Slash", os.clock(), COOLDOWN_TIME)

On the client, you track it:

-- LocalScript
local activeCooldowns = {}
RemoteEvent.OnClientEvent:Connect(function(message, abilityName, startTime, duration)
    if message == "AbilityCooldown" then
        activeCooldowns[abilityName] = {
            start = startTime,
            duration = duration
        }
    end
end)
RunService.RenderStepped:Connect(function()
    local now = os.clock()
    for abilityName, info in pairs(activeCooldowns) do
        local elapsed = now - info.start
        local ratio = math.clamp(elapsed / info.duration, 0, 1)
        -- use ratio to update a UI bar or image transparency here
        if ratio >= 1 then
            activeCooldowns[abilityName] = nil
        end
    end
end)

By separating the server enforcement and client rendering, you make your cooldowns secure and visually clear.

Handling Queues and Input Spamming

Players will often spam keys. Your cooldown code needs to react to this in a predictable way. With a strict cooldown, every key press during cooldown simply does nothing. You can also choose to remember the last input and trigger it when the cooldown ends. This is called buffering.

If you implement buffering, you can store a flag that the player attempted an action during cooldown, and then check that flag as soon as the cooldown finishes. This must be done carefully to avoid unintended extra attacks.

A minimal buffer approach is:

local onCooldown = false
local buffered = false
local function tryUseAbility()
    if onCooldown then
        buffered = true
        return
    end
    onCooldown = true
    buffered = false
    -- perform attack
    task.delay(cooldownTime, function()
        onCooldown = false
        if buffered then
            tryUseAbility()
        end
    end)
end

This makes the game feel more responsive for players who hit the button slightly early, but it can also make combat more automatic, so use it carefully.

Balancing and Tuning Cooldowns

Cooldown values have a large impact on how your combat system feels. Extremely short cooldowns create fast, aggressive gameplay. Longer cooldowns push players to time their actions and to coordinate with teammates. Balancing cooldowns is mostly a matter of playtesting.

Some basic tuning ideas are useful. Powerful abilities with high damage or wide area effects usually need longer cooldowns. Defensive abilities like shields often get medium cooldowns. Small mobility actions like short dashes can use short, frequent cooldowns.

You can also add modifiers like cooldown reduction stats, temporary buffs that reduce cooldowns, or penalties that increase cooldowns after large mistakes. These systems use the same core pattern, but adjust the value you add to now when you compute nextReadyTime.

By treating cooldowns as part of your combat design instead of just a technical delay, you can shape how your Roblox combat game feels, from slow and tactical to fast and flashy, while still staying readable and fair.