Any tips on making a weapon system?

[Suitable_Jay]

I have recently decided to make a game with a whole bunch of weapons. I have never done this before so I am wondering if there is an easy way to make it with as less lag and confusion as possible.

I want is some system where I can easily add new weapons, and also effects such as swords and speed potion or something. I also want enchants to be able to go on the sword, and it also may be important to note that I want to potions that do ‘abstract’ things such as doubling effects or taking away effects.

My current set-up is simple:

First, there is the Weapon script which takes care of simple stuff :

If the tool is activated the WeaponCode fires a function specific for that weapon the Local WeaponManagementCode:

This would check if the player can do what the tool asked and makes sure the player has no No Fighting potion on or something.

If it passes then the module fires a specific event in my remote folder which notifies the WeaponEventCode:

And this does anything that is needed for the server-side.

I am not sure if this is the best way. So I’d like to know some of your methods.

If it is an okay method then can you tell me any tips on making weapons.

[SovereignFrost]

What I normally do is make a local script to control ALL of your weapons locally.
Using Character.Instance added, check if it is a tool and one of your weapons.
Have a main event for all of your weapons stuff and store a config module inside the weapon

I check all of the ammo data and stuff in the client (for visual effects) and verify it on the server.
Raycasting on the server and deal appropriate damage based on the config module (don’t let the client dictate settings!)

however do what’s best for you but make sure it’s secure!

---

um MoreCode as a script name is not the best thing to do if you’re going to be working a lot on the game

[Suitable_Jay]

I think I understand what you mean. I actually am not using Raycasting. I haven’t learned it yet. I just have this:

	local Object = Instance.new("Part")
	Object.Size = Vector3.new(1,1,1)
	Object.CFrame = weapon.Handle.CFrame
	Object.Parent = weapon.BulletFolder
	Object.Shape = Enum.PartType.Ball
	Object.CFrame = weapon.Handle.CFrame
	Object.Velocity = ((mousePosition.p - plr.Character.Head.Position).unit*weapon.Handle.WeaponStats.Strength.Value) + Vector3.new(0,weapon.Handle.WeaponStats.Strength.Value/7.5,0)
end)

lol pretty pethetic though.
I probably will learn it soon.

If I make one local script to control everything and use Character.ChildAdded() won’t that make lag because it will create a new thread whenever I equipped a tool?

Can you tell me how to verify? I have never put security in my games(because none of them got popular)

With the script on the server should I multiple remote events for specific things such as AK47RealoadedEvent or have one event for everything but add an identifier argument, or both such as GunRealoadedEvent?

Also I have MoreCode because Server Scripts that have only like nine lines of code bother me

[SovereignFrost]

one event for everything. i do animations on client. (reloading but do sanity checks in server)
disconnect your events when you unequip the gun

[Thegameboy (Delfino)]

In my opinion, a few things could be improved on. Here are my two cents:

First of all, I can see you’re using two main scripts for all of the weapons – the server and local scripts. In programming a program that doesn’t divide knowledge of the application across modules is called a monolithic program. It’s not seen as a good coding practice. It hinders scaling and debugging, since you’re constantly wondering where you happened to put some piece of code you want to modify / add on to.

Instead, try making each tool have its own server and local scripts. After all, each tool exists by itself, and doesn’t really need any direct input from the other tools. So it makes sense to give each their own thread, or script. Otherwise, you’ll soon end up with a big, 500+ line mess!

You will come across situations where the tool needs access to functions that other tools have. TheNexusAvenger has a good system of having a Resources module that exposes a function that takes in a name, finds a centralized location where its module is (e.g. under a folder named ToolResources under ReplicatedStorage), require()'s it, and returns it back to the script.

The Resources module also checks its own children for any local modules it may have (e.g. ProjectileCreator, that returns a function that creates and returns a projectile appropriate for this tool, like a rocket projectile), require()'s it, and returns it back to the script. This way, all common dependencies are centralized and if you modify one module, it will be reflected across all tools. The tools are open sourced for a reason – they’re a really good example of organization for someone learning to code weapons for the first time.

Also, doooo not have one remote event that takes in an identifier. Not only does this make your tools less transparent (which scripts are accessing this remote event?) and less portable, it also is just unnecessary. Use multiple, and scatter each under the tool you’re creating for. Again going to TheNexusAvengers’ example, he has a dedicated RemoteEventCreator module just for creating and getting remote events at runtime.

Last, the best way to detect if a player has equipped a tool is using the Tool.Equipped event.

[Suitable_Jay]

Reading your reply makes me sad because I am such a nub. I think I understand what you mean with two scripts for every weapon but I don’t completely understand the Resources module idea.

Is all of those scripts(Local Script, Server Script, Module, and modules in module) inside each weapon?

[Thegameboy (Delfino)]

Is all of those scripts(Local Script, Server Script, Module, and modules in module) inside each weapon?

The idea is that instead of having one big local script handling all weapons client code, you have individual local scripts for each of the tools. Each of these local scripts will handle only what they need to for that weapon. The same goes for the server scripts. Each tool has its own Resources module to fetch other modules that multiple weapons have in common.

As for the Resources module, it was only a suggestion. If you take the classic old Brick Battle tools as an example (like in Doomspire, you have rocket, superball, bomb, etc), multiple tools should have access to the same modules. Utility modules like input handling, remote creation, etc. that shouldn’t have to be manually duplicated each time you create a new weapon, since otherwise it would be very hard to make changes to those modules.

Imagine if you had 2 weapons: a sword and a slingshot. The sword and slingshot both need access to a module that damages the player. These modules have the same contents, but are copied inside of each individual tool.

Now let’s say you added a new feature to the slingshot and sword that didn’t allow players to damage their team members. You would add a check inside the damage module that wouldn’t allow a player to damage another player if they’re on the same team. It would be annoying to have to go into the module in each tool and add the code with that new feature, even if all you needed to do was copy and paste the new code. You may even forget to put the new code into each tool.

The best way to prevent this is to make sure they all share the same module. After all, the sword and slingshot both have one job in common: they damage another player. Why shouldn’t they share the same module for doing it? This is where the resources idea comes into play. It just grabs the modules that are in one big folder, probably in ReplicatedStorage, and returns their contents to the script that asked for it.

In other words, it’s just best to centralize everything. You shouldn’t have to keep repeating yourself throughout the tools, which is part of what makes modules so useful: they can be reused by multiple scripts. Hopefully this clears some things up.

[Suitable_Jay]

I think I understand somewhat now. I got one of @TheNexusAvenger model’s and am using it for reference. He puts the Resources module in the tool, but I think that’s just for the model.

I went through and read all of his code. I am not a pro but now I am finally beginning to understand complex code.