If roblox does add such a thing, then I honestly will use this framework because I think the origination is really outstanding.
I would also like if it’s possible to instead of client and server names for the modules, it’s part of the name of the system. For example, CameraSystem = folder, CameraClient = client modulescript, CameraServer = server module script and then it checks the names for client and server at the end of the string. The reason I would like to see this feature is because at the top I can more easily find it instead of seeing client client client server server server.
Can you link to where you found this information? I am super curious. Is it in the RunContext post? I don’t want to disprove you or anything, I just would like to learn more if this is infact how it works.
I’m not sure about the new RunContext feature but roblox’s default replication system never sends serversided code to the client. You can check any leaked place and you’ll see that server scripts won’t have content or there will be a comment saying that the exploit couldn’t decompile it’s bytecode.
Your request has been added! You can now name modules what ever you’d like. Just make sure that it ends with the type of module. For example, CameraClient, WeaponClient, CameraServer, and WeaponServer. The string detection is only checking the end of the string.
Hey! Would you mind explaining how I would implement something where a system would run a function when a RbxSignal goes out? Such as a .PlayerAdded event in my case. Formatting and logic-wise.
local signal = BULLFROG.createBindableLink()
-- I'm assuming your using a bindable event
-- the "..." are your arguments
signal.Event:Connect(function(...)
-- do stuff
end)
-- To fire a signal you just do this
-- the "..." are your arguments
signal:Fire(...)
Hello, I’ve gotten interested in this framework and I’m considering using it. I really like the organization it gives by using the RunContext feature, and I like how it’s pretty simple to understand, unlike other frameworks. Anyways, I’ve got a couple of questions before I use it:
How would I go about making tools using the provided example setup? I’m guessing that you would need to make a new system for every unique tool, but I would like to know just in case I do it wrong or inefficently.
What are the submodules mentioned in the “Systems” section of the documentation? I didn’t find any further explanation of the submodules in there.
Thank you! Ill go ahead and answer some of your questions.
There are many ways actually that you could create tools. You could do a class based system where you have a melee weapons system and a ranged weapon system. You could do a table and determine the tool type at run time, there are hundreds of ways.
Submodules are just sub modules of the client and server. I will need to add to the GitHub repo some details about this. It basically just allows for more finer organization and breaking down of scripts. If youve ever heard of ECS or Entity-Component-Systems then its similar to that.
Im trying to keep this framework as simple as possible. I too thought other frameworks were super overkill for what they are trying to accomplish. My goal with this framework was to be as simple as Love2D. Provide you the basics and let you get creative.
This is a wonderful idea! I will work on creating a place that is public and it can have examples on how everything would tie together!
That would be a right answer if all the game’s actual code wouldn’t be found on module scripts in replicated storage which the client is actually able to see.
Right, I have since updated it to function differently. It is far more secure now. I have actually developed multiple small games using Bullfrog. It does some stuff to delete the server side code from the client.
Thats up to you to decide. I created this kind of for myself. I found Knit to be really heavy and it comes with a lot of dependencies, such as promises for example. I have nothing against promises, but I wanted something more lightweight. Thats where I came up with Bullfrog. It has zero dependencies and the Link system is just a simple wrapper for Remote Events and Functions. There is nothing complicated about it, its must easier to just jump in and start. I would also like to mention Bullfrog is specifically designed so that all of your code can be placed inside of one place, ReplicatedStorage. Bullfrog does some stuff on startup to prevent clients from seeing the server code. Also having everything in one place makes using a Rojo workflow a lot easier. Nothing is disjointed across from StarterPlayer to ServerScriptService. Everything is inside a systems folder. It just makes things a lot more organized!
I see on bullfrog you store the value returned by systems modules on a table, so you technically could then destroy the modules to be able to hide the code from exploiters using “Dex” and things like that, since you already have saved the value there would be no need to keep the modulescript there, of course this would require constant memory usage since you shouldn’t be able to remove the systems from storage. At the cost of using more memory you could hide all the code from all your systems.
