Hey Mazing, thank you for the reply and sharing your concerns. I thought the capabilities of the plugin would be obvious from the video or the docs, but often, they are only obvious to the developer of the tool.
This plugin is essentially a lightweight database management system. Small projects can benefit from it since it’s more convenient to edit data this way than manually in ModuleScripts. However, the benefits increase with the size of your project.
For clarification, here are some common use cases:
-
Managing variable values, of course.
-
View/select elements by categories by displaying dropdown properties as tabs.
-
The Search Tab is a great way to find specific items that might need changes. The more elements you have to manage, the more beneficial it becomes.
-
If your elements have images, you can actually see the image, rather than looking at a string like “rbxassetid://123…” in code and trying to remember what the image was.
-
You can edit data concurrently in Team Create – e.g., if another Roda user changed the name, price, image, or any other property of an item, these changes are directly synchronized with you.
-
You can lock the data file configuration or the editing of data itself to prevent accidental changes (also locks it for other Roda users in Team Create). This is a helper feature designed to enhance workflow efficiency, not a security/permission measure, since data can still be manually edited in the ModuleScript.
-
Templating - You can create data file configurations and copy these between projects, essentially like creating a schema in a database.
-
Integration with External Tools. For example export the data to your API, from there forward it anywhere else you need. Maybe something like a wiki website where you visualize your game elements. You can also import data back from your API.
-
Export the data to the DataStore and import it back, eliminating the need to edit the DataStore in different ways. It can be used for many kinds of elements (but NOT for player data. For player data there are better solutions out there like sleitnick’s DataStore Editor and similar). The limitation here is having tables as values of keys. Only primitives are supported. If you need tables as values, you would create separate data file configurations (tables) and then link the data at runtime. Like joins in a traditional relational database.
If you have just a few items or elements in your game with variable values in ModuleScript or in the DataStore, you might not see a great benefit from this plugin, other than it maybe being more convenient. However, if you have to manage 50, 100, 500, or more items or elements, then editing and adjusting stuff in code becomes painful.
A typical project in terms of data could look like this:
loleris’s ProfileService/ProfileStore for DataStore interaction.
The profile template would look something like:
local playerStats = {
money = 0,
level = 0,
-- ...
}
local items = {
{
id = 0,
amount = 0,
},
}
local ProfileTemplate = {
playerStats = playerStats,
items = items,
-- ...
}
The actual items database would be in a ModuleScript, managed with Roda
local module = {
{
id = 1,
name = "Apple",
value = 28,
image = "rbxassetid://12345",
-- ...
},
{
id = 2,
name = "Banana",
value = 30,
image = "rbxassetid://123456",
-- ...
},
}
I hope this is clearer now.
Before You Buy 
Get Roda 
