Most preferred / Best Frameworks?

Help and Feedback Scripting Support
#1

Hello!

I’m currently making a game with my friend. It’s our first game together and I’ve been wanting to dabble into frameworks. I’ve looked into frameworks such as Knit, but would like to hear more options!

I’m familiar with frameworks and scripting as a whole, just would like more input on what the ‘industry standard’ is!

#2

It might be worth noting that knit doesn’t support roblox parallel processing(at least in a conventional way)…

#3

My advice would be not to rely on a “Framework” but use a variety of quality tools that get the job done. However if you’d like to use a framework, Both Knit and Canary Engine are good frameworks.

In my main project I use the following open source assets:

These two modules compliment each other very well, they were made by @loleris so shout out to him for that.

Next, for my admin utility I use Cmdr made by @evaera its really useful when it comes to custom commands and helps make testing your game very easy and fast.

For my Ui:

The wisest developer knows not to rely on one framework but essentially make your own framework with many assets.

2 Likes
#4

You’ll be surprised that the “industry standard” framework for Roblox is: none!

You see, scripting is simply just a way for developers to interact with Roblox’s engine for their games to do stuff. Sure, there are some nitty gritty details about the language and API that you got to look out for, but generally speaking every property, method or signal you interact with in Roblox is already pretty abstracted away for you.

This is why frameworks are fundamentally flawed. Abstracting already abstracted APIs like RemoteEvents and ModuleScripts in the name of modularity and keeping convention. It’s quite pointless, and worse, hurts productivity and runtime performance. Just see how many mistakes Stephen makes in his tutorial.

The second and more drastic thing I’d like to mention is the unhealthy tendency for frameworks and OOP to make you splinter state and logic across multiple files. You split everything up into nice Singletons and Classes that expose interfaces that lets them talk to each other.

But wait! What if PlayerService.lua tries edits a field from AttributeService.lua? Well, now you’ve shared mutable state between multiple scopes. But isn’t that the same reason you’re told to avoid global variables? It is, since now PlayerService could screw with AttributeService and any other script that reads/writes from it. I would write more about this specific problem, but here’s a great video that goes more in-depth about this.

So, how are you supposed to organize your scripts then? Everyone has their own style, but the way I like doing stuff is having all logic packed into one Server.lua and Client.lua which have different segments of code for each element of the game.
do end blocks work fabulously with this.

-- Player
do
	local Players = game:GetService("Players")
	
	local Data = require(script.Data)
	local Analytics = require(script.Analytics)
	
	local function OnPlayerAdded(Player: Player)
		if not Data:CanGetData(Player) then
			Analytics:Log(`Failed to load data for Player {Player.UserId}`)
		end
		
		Data:Load(Player)
	end
	
	local function OnPlayerRemoving(Player: Player)
		Data:Save(Player)
	end
	
	Players.PlayerAdded:Connect(OnPlayerAdded)
	Players.PlayerRemoving:Connect(OnPlayerRemoving)
end

This way, modules like Data and Analytics simply act as extra abstraction for your logic. They don’t store or interact with state, so your flow of code is much more predictable.

Edit: The creator of Knit also actually made a blog about what he thought was fundamentally wrong with his framework! I recommend you check it out.

#5

I recommend functional programming if possible (and OOP for some cases), for Roblox at least. Most games on here do NOT require any sort of ‘framework’ and do well with just case-to-case scripts and modules.

Get the modules you need, use efficient and well-commented code and you should be fine. Figuring out the scope of your game first and fleshing out the actual gameplay is way more important.
All this ‘framework’ nonsense is just developers trying to sound smart and cool. It’s not like one-size-fits-all. Ain’t nobody need all that extra junk for just a simple game.