Parry based combat system

  1. I want the hitbox to detect if the player is in front of me if they are blocking

local Hitbox = workspace:GetPartBoundsInBox(hrp.CFrame *,0,-3),,5,5))
local Hit = {}
for i,v in pairs(Hitbox) do
if v.Parent:FindFirstChild(“Humanoid”) and v.Parent ~= character and not Hit[v.Parent] then
Hit[v.Parent] = true
local targ = v.Parent

					if targ:GetAttribute("Parrying") == true then
							Parried.Parent = targ.Humanoid
							character:SetAttribute("Stunned", true)
							character:SetAttribute("Stunned", false)
							game.Debris:AddItem(Parried, Parried.TimeLength)
					elseif targ:GetAttribute("Blocking") == true then
					game.Debris:AddItem(Punched, Punched.TimeLength)

I think I know what you can do to see if the player is infront of you. Have you used lookvectors before?

If you don’t know what lookvectors are ill explain it to you. Lookvectors are something we call “unit vectors” this just means it has a length of 1, sort of like unit rays. Like have you used vector3.Unit before? It’s like that sort of. So this is how you’d for example position a part 10 studs infront of its lookvector.

workspace.Part.Position = workspace.Part.Position + workspace.Part.LookVector * 10

Use a module script to keep track of the parry state as well as store a function for checking whether an attack was parried.

Can you please give me an example of this

A module script is a script that can be accessed by other scripts. This makes them useful for storing values that operations are preformed on frequently, such as health, stun, and things you’d have in a fighting game since they can also have functions stored inside of them, preventing the need to copy-paste the same OnDamage function to every single weapon.

I’ve written an example in this post.

yea i know how modules work but why would i store parrying in a module when multiple people will be parrying/punching etc

It’s not just one module that’s used globally (though that technically can be done, it’d be somewhat difficult to debug), every character would have their own modulescript for their stats.

so like in starter player???

I mean that’s kind of obvious? You could put them anywhere, really. Just make sure you can easily find who’s is who’s.

i mean yea i already did it, its kind of useless because why not just set up attributes when the player is added

Because ModuleScripts can:

  • Store variables in a much cleaner way than attributes.
  • Store a wider variety of variables than attributes, such as tables and newproxy()'s
  • Store functions that can be called, saving you from copy and pasting code.

The only downside is the fact it’s not replicated across server-client, but that is easily remedied with the use of remote events, if the client even needs to read those values at all.

1 Like