I have been working on a fighting style game for some time now which features mechanics like blocking, parrying, and status effects but I feel that the current way I am handling is very poor and will not be good in the long run.
Currently I am using the creation of new named boolean objects parented to players to handle combat interactions. For example, upon getting hit with an attack a new boolean value named “Stun” will be parented to the character. There is an OnChildAdded event which listens and checks the name of these booleans to change the walkspeed of the character whether it be a boolean named “Stun”, “Block”, or “Sprint”.
As I continue to work on this project it seems that more and more things begin to conflict with each other such as an old “Stun” boolean firing a ChildRemoved event which sets the players walk speed to an inappropriate value.
Another thing I am lost in approaching is a status effect system which is more reactive than proactive. For example if a player is under the status effect of being on fire then I do not want to create a loop which damages them for x amount of time while under the effect as its duration may be prolonged or decreased through in game means. I would rather a system where the game reacts to the fact that the player is now on fire and begins to damage them and stops or continues as long as the player is on fire.
I am currently considering looking into creating a data table for every player instead of booleans but would like further input on this and if anyone could direct me toward any services which would be helpful in achieving the desired effect as many resources for creating quality fighting games are very scarce.
function damage_player(plyr: Player)
if stun_check then plyr:SetAttribute("Stunned", true) end
if plyr:GetAttribute("Stunned") then
plyr:FindFirstChildOfClass("Humanoid").Walkspeed -= 10
-- some code
end
end
I’d probably approach this with coroutines or asynchronous threading, if I were you. They’re not the same thing, but they’re synonymous enough for what you’ve described.
A coroutine implementation might look something like this:
function damage_player(plyr: Player)
coroutine.wrap(function()
some_effect(plyr)
end)()
while plyr:GetAttribute("EffectStrength") do
plyr:SetAttribute("EffectStrength", plyr:GetAttribute("EffectStrength") - 1)
end
end
… that way you can do things essentially simultaneously.
I wouldn’t suggest this. If I’ve interpreted what you’ve said correctly, then that’s a lot of memory and a lot of editing values constantly, which isn’t the best for performance.
Let me know whether these approaches suit your game!
Nah I was about to say the same thing, attributes solves that childremoved issue + much easier to manage. I would stay away from specifically storing gigantic tables of player info because any leak onto client with that information could lead to a TON of security issues in the future, if exploited. Coroutines are slightly complicated tho if you’re new to them so make sure you read up on it’s documentation on its proper/more external use @Buket_exe
Thank you for the input. I think using attributes is probably a good way to achieve the desired goal and I think that using coroutines is a good way to approach the status effect system.
My explanation was probably poor but I had meant that a new table with the player states would be created and assigned to a player when they joined and would be removed when the player left which I thought would be fine however I do think that attributes can achieve the same thing in a much more manageable way.
