I now mostly make my Roblox games using a tool I built myself, called Azul.

It's a sync tool between your PC and Roblox Studio. It basically allows you to edit your game files using your favorite code editor, and have the changes reflected in Studio in real-time.

But... why?

Explaining why Azul exists is actually a bit of a mouthful to explain, but I'll try my best!

A bit of history

Today, Roblox Studio's editor is decent. Roblox has had many years to polish and refine the experience, and what they have now is a very solid code editor that supports all most features you'd expect from a modern IDE, and it's extensible with some amazing plugins that can speed up your workflow a lot.

In 2017, things were a lot different. Roblox was finally starting to become a serious game development platform, and many developers were starting to treat it as such. However, Roblox Studio was still very much a "game maker" tool. The built-in code editor was very basic, and it lacked many features that more advanced developers were used to in other code editors.

These frustrations led a smart few to a novel idea:

"What if we could ditch the built-in code editor, and edit our game files with whatever we wanted?"

This is how many early "sync tools" were born: RbxSync, RbxRefresh, CodeSync...

These tools worked by watching your local files for changes, and then sending those changes to Roblox Studio. This allowed developers to use their favorite code editors, and have the changes reflected in Studio in real-time.

However, a lot of these tools were very rough around the edges. They were often buggy, and they didn't always work as expected.

This all changed with the release of LPGhatguy's Rojo. The creator had a very clear vision for what he wanted to achieve and, alongside a team of very talented contributors, he made it a reality. Rojo was a very polished tool that worked as expected, and it quickly became the de-facto sync tool for Roblox projects, developing into its own ecosystem of packages and plugins.

...But today isn't 2017. Roblox Studio, developers and even Rojo itself have changed.

How Rojo works

In principle, Rojo is a very simple tool.

It watches your local files for changes, and then it updates a special "project file" that Roblox Studio can read. This project file tells Studio how to map your local files to the game's hierarchy. For example, if you have a folder called 📂 server, you can tell Rojo to map all scripts in that folder to ServerScriptService.

In an ideal world, this would be ideal. Your filesystem is your source of truth, and Roblox Studio is just a dumb client that reflects the state of your files. However, in practice, this design has some glaring limitations.

What's wrong with Rojo?

If you ever used Roblox Studio, you might have noticed that it has some glaring differences from traditional files and folders. Objects like Parts, Models, Meshes... They aren't files, they're objects in a hierarchy. They have properties, they can be nested inside each other.

How does Rojo handle this? It makes you manually write down the structure of your game in the project file. If you want to create a new Part, you have to edit the default.project.json, and then tell Rojo where to put it in the hierarchy.

1// Example: Adding a new Part called "CoolPart" to the Workspace
2"Workspace": {
3  "$className": "Workspace",
4  "MyNewPart": {
5    "$className": "Part",
6    "$properties": {
7      "Name": "CoolPart",
8      "Anchored": true,
9      "Size": [4, 1, 4],
10      "Position": [0, 10, 0],
11      "Color": [255, 0, 0]
12    }
13  }
14}
15

This is a very tedious and error-prone process. It also means that you can't use Rojo to edit your game in Studio, because any changes you make in Studio won't be reflected in your files.

Partially Managed Rojo

This is slightly alleviated if you choose to use something called "partially managed" Rojo. Essentially, you can tell Rojo to only manage specific folders in your project, which means you can still manage some parts of your project in Studio, and only specific parts with Rojo.

However, this leaves you in an akward middle-ground where your filesystem has a "blind spot" for anything that isn't "managed". You're giving up the ability for the filesystem to dictate what your project is, meaning you have to manage your project in two places: the filesystem, and Studio.

This is a middle-ground many people choose to live in, but it can be a nightmare to manage.

Partially managed Rojo doesn't solve a problem I like to call "poisoned folders":

If you want Rojo to properly manage the "poisoned" folder, you'll have to either add it to the project file, create a .meta.json for the Folder, or move the BoolValue out of the folder altogether.

1// server/TestFolder/Folder/boolvalue.meta.json
2{
3  "className": "BoolValue",
4  "properties": {
5    "Value": true
6  }
7}
8

This is a very silly example, but you can see how this can quickly become a nightmare to manage, especially with datatypes more complex than just a true/false value.

Existing projects?

Support for using existing projects is non-existant.

Really. You just can't.

The only tool that allowed you to use existing projects with Rojo hasn't been maintained in 5 years. It's 6th anniversary is this May!

(Fun fact: My PR of rbxlx-to-rojo is one of the only ways to still use it!)

The "sync" part

In reality, Rojo isn't really a "sync" tool, is it?

While Rojo likely started as a sync tool, it's evolved into what they call a "build tool", which means that its goal is to generate Roblox games from your filesystem. Rojo isn't trying to be a companion to Roblox Studio, it's trying to replace it.

This explains many of the design decisions that make Rojo a burden to use for people that don't want to replace Studio. We're just not the target audience, and that's fine! But the issue is that many developers in the community still act like Rojo is a sync tool, recommending it for "editing your scripts with your IDE", which is just not what Rojo is.

The ability to edit your game in Studio, and have those changes reflected in your files is a feature Rojo barely supports.

The market for Rojo alternatives

Unsurprisingly, I'm not the first person to complain about Rojo.

In the past few years, there have been a few attempts at making Rojo alternatives. The problem, is that Rojo is a very hard act to follow. It's a very polished tool that works as expected, with a tight ecosystem and a large userbase. Any alternative would have to be significantly improve upon Rojo, work with the years of Rojo projects that are already out there, and not completely alienate everyone else.

Roblox Studio's Script Sync

Roblox's official "Script Sync" is a very recent addition to Roblox Studio, and it's a very good tool. It allows you to edit your scripts in your favorite code editor, and have those changes reflected in Studio in real-time.

The issue is that it's very barebones. It's just a simple mirroring tool which you mostly set up manually (by right clicking a Script or Folder). While this is a good start and it works, it lacks many features that Rojo has, such as Package Manager support, or the ability to import existing projects from your filesystem.

Argon

Argon is a very interesting tool because it feels like a spiritual successor to Rojo.

If Rojo is the "Classic" way to build, Argon is the "Updated" way. It's generally much friendlier and easier to use, especially since two-way syncing is a first-class feature.

But there's a catch. Despite all its polish, Argon is still fundamentally a build tool at its core. It still relies on the *.project.json manifest. It still requires you to map out your hierarchy in a configuration file if you want to do anything beyond the basics.

While Argon makes the "Rojo way" much faster and more pleasant, it doesn't solve the core issue for developers who just want to sync.

Azul

So, seeing no one alternative, I decided to make my own tool, Azul! (pun on Rojo intended)

I wanted a tool that just worked, that didn't require me to change the way I worked, that worked with my existing projects, and that didn't require me to manage any project/meta files.

This is how Azul was born.

The Azul logo

Initially, Azul was supposed to be a "sourcemap builder", a patch on top of Roblox's Script Sync that let you get autocomplete support for your local files in Studio. However, it grew into a full-blown sync tool.

It's one-click to start, it just works, it's fast, and it supports all the features I wanted.

What I fixed

• Studio is the source of truth: Azul is very clear about the fact that Studio is the source of truth, and your filesystem is just a reflection of that. You can edit your game in Studio, and have those changes reflected in your files. You can also edit your files, and have those changes reflected in Studio.
• No more project files: It's just one command to start Azul, and it just works. No more writing JSON files, no more managing meta files, no more worrying about the structure of your project.
• Support for existing projects: Just point Azul to your existing project folder, and it will sync all the files in that folder to Studio. No more "importing" your project, no more "partially managed" folders.
• No more "poisoned" folders: You can have any type of object in your folders, because state isn't managed in your filesystem. Have Scripts inside tools, inside models, inside anything!
• Confusing conventions: I always believed the init.luau convention was very obtuse, because your Script's name and location no longer corresponds to its location in Studio, so I got rid of it. I actually made a lengthier post about this topic, if it piques your interest: A case against init.luau

What I took from Rojo

• Backwards compatibility: Azul has a compatibility layer for existing Rojo projects, so it can import your favorite Rojo projects and libraries just fine.
• Package Manager support: Azul lets you use Wally, pesde or any other package manager to manage your dependencies, and it will sync them to Studio properly.
• Filesystem -> Studio: Azul still supports the workflow of pushing projects from your filesystem to Studio, so it can still be used as a build tool if that's what you want. Turns out build tools aren't evil!
• Reproductible builds: Azul lets you generate reproducible builds of your game in a few commands, just like Rojo.

Closing thoughts

My goal with this project was to make something that I wanted to use, and I think I succeeded. Azul is the tool I use every day to make my games, and it has significantly improved my workflow. It's not perfect, and it still has some rough edges, but it's a tool that I enjoy using, and that's all that matters to me.

However, I also hope that Azul can be a catalyst for change in the Roblox development community. I hope that it can inspire other developers to think outside the box, to challenge the status quo, and to create tools that are better suited for their needs.

Rojo is a great tool, but it's not the only tool, and we deserve better than just one option.

If you're interested in checking out Azul, you can find it on GitHub, and let me know what you think!