Support a Minimum Roblox Engine Runtime

Feature Requests Engine Features
#1

As you age up in experience and move on to better tools outside of studio, it becomes harder to test your code without taking excessive amounts of time to load up Roblox’s runtime environment each time you press “Play”. Since Roblox requires an account for everything (even for the services you never use!), it’s impossible for me to properly move Roblox’s runtime out of studio. Surely, this is done by design to keep the developer tethered to the platform but, I feel like that philosophy should be revisited in order to remain viable to developers more accustom to non-Roblox-specific toolchains.

Today, no runtime outside of studio exists. Even when using Rojo. You have to “compile” your project source to a Roblox place file. Open up that file. Stream Rojo changes to opened place file and then, hit run. Even when you don’t need to render anything and it’s pure code logic. This is totally abysmal.

Ideally, there should be a very minimal runtime produced and supported by Roblox that allows you to run lua or luau in a contained Roblox-eques environment. In the literal sense, I run my code and it should be able to use and work with Roblox APIs in this runtime. It’s totally fine that some APIs can’t survive in this environment without a Roblox account. Namely, datastores, friends, groups, etc. That’s totally fine. This is not production and should not be treated as such. This is purely for quick-development. If I want to test my code with everything that Roblox supports, I can run my game the default way. However, for this request, I am simply asking for minimum APIs in a runtime that can survive without taking excessive amounts of time to render stuff I don’t need and to be able to pipe output to a console that I can see without physically being inside of studio.

To an engineer that might be reading this: The way that I would approach a solution is to bundle a lightweight CLI tool to studio and then have commands that run a slimmed down version of studio’s default environment. i.e $ rbxcli run --project {src folder} to run more than one file in a project. $ rbxcli run --file {file} to run one file. $ rbxcli build --project {src folder} to build a place file based on a project. $ rbxcli compile --project {src folder} to build and run a place file based on a project. You can expand this CLI tool to do things such as publish ($ rbxcli publish {path to place file} {--id=PLACE_ID}) but, this is not the scope of this request. The primary benefit of this approach is that you can create a CLI tool that can be adapted by external developers to be used on any other platform without having to directly maintain each subset. In this particular example, a subset would classify as a extension or plugin to a text editor such as Visual Studio Code or related. And would still appeal to those who use Vim or Emacs.

Side Note: I’m not entirely sure if this concept can survive on this platform yet because I have no idea how Studio is written or how closely-tied the “Roblox runtime” is to external services. But, this should definitely be a key-selling-point-feature if this platform wants to scale appropriately to more than just studio or to the wider game-developer audience not in flavor of being forced to use Studio directly.

19 Likes
Allow Opening Place Files without an Account
Introducing Account Session Protection
#2

roblox-cli exists, but of course they’ll never release it

5 Likes
#3

Is it dependent on an internal build of studio?

#4

I think code under it runs at BuiltInPlugin level so they’d have to modify it to, not, do that, and afaik, its just Luau with Roblox’s namespace and a DataModel.

#5

If that’s the case, sounds like it’s more of an addition to prod. Which means that it’s probably using undocumented stuff to work. I have a few ideas what it might be using but, I’d have to free up some personal time to be able to properly test my assumptions.

Outside of this though, it’s pretty dumb that it hasn’t been released yet. Roblox really needs to move in the direction of open source if they want anyone to take them seriously outside of just kids.

For example, Roblox doesn’t own an engine like frostbite or make money off of in-house produced titles. They offload that work to developers. There’s no real reason to keep useful utilities locked behind a glass door when they have a ton of resources allocated to directly supporting developers. I can understand the engine not being open sourced because it’s proprietary but, a tool not being open sourced when it has legitimate practicality to wider developer audience is borderline irrational.

It’s pretty ridiculous that a solution that would solve a ton of problems is locked away behind a gate for only internal use.

1 Like
#6

If you release something, it sets certain expectations on stability, usability and maintenance. And also on the surface of the product it must support (e.g. they would get bug reports on it if they add a new platform feature but haven’t reflected the tool to support said feature). Keep in mind we don’t actually know the current state of the tool, it could be very stable or it could be riddled with subtle bugs that engineers know how to work around.

It’s likely they haven’t released it for these reasons. It’s not free to open-source tooling like this that people are going to depend on.

Nothing ridiculous about this for that reason. It would still be cool if they can find a way to release and support it properly for external folks.

1 Like
#7

It’s been mentioned for a while now and seems to be an internal tool for all that time. You can make an educated guess that it’s somewhat stable. Otherwise, using it to test prod stuff would be extremely dangerous (Roact, etc). It doesn’t have to be perfect for it to be useful. But from a product standpoint, that’s far from the underlying issue.

The problem that I see why it hasn’t been released is that it’s using internal APIs that Roblox doesn’t want to expose publicly or because, more than likely, it distracts from a flagship product which is studio.

Maintaining support parity between internal and production would technically be on-par because the tool is used internally. There’s a guaranteed stream of support before it reaches prod. Therefore, it’s more likely that it’ll not work on a dev-build than on a prod-build because nomination and internal support would guarantee compatibility. The only reason it wouldn’t work if you were using features that don’t exist. Akin to using Python 2 code with Python 3.

If I were to write this myself, I would probably want it to use the default version of studio on that particular machine. Because, CLI = utility. I can’t imagine that it’s using an entirely different version because, support parity between two versions would be a mess to maintain. You’d have to update studio and then, update CLI to make sure there’s no breaking changes when you can just run a simplified version of what “run” does without causing too much hassle. Instead of just having the CLI pull different stuff from the a local build of studio which is much more safe.

Hopefully this makes sense. With that in mind, I think it’s just a simple act of “it’s not in our product vision”.

#8

There’s a lot of strong assumptions in this post that can’t really be verified. My point was moreso not to get stuck in a particular mindset and pushing for the feature from that perspective, because we don’t actually know why it’s not being released. There may be many other simple reasons for it that I pointed out above apart from just product vision.

1 Like
#9

Most deep technical aspects in any pre-compiled product can’t be verified unless you’ve seen source so that point is rather moot imo. Roblox has been at odds with 3rd party support since forever now. That’s why Rojo exists. Because Roblox didn’t want to put any effort to it and a former Roblox employee decided to put it out there.

As stated before, a CLI tool is just a utility. It’s not a product and should never be a product. It’s really weird, almost wicked, that a utility can’t be released and I don’t really see why it can’t unless you’re hiding certain things or it doesn’t fit your product’s vision.

When an internal tool is used to test a flagship product before it reaches developers, in my eyes, it’s considered stable and viable because if it’s not, you’re not really achieving much by testing against a broken tool. You’d be shipping a half-tested, almost broken product to developers. It wouldn’t make sense to even support something like that internally if it has almost no real use case.

Another thing to note is software packaging. If you’re able to run things headless, it’s more the likely possible to wrap it around a self-launched process. This would distract away from having to use both Studio and the site directly. Some aspects are tied to Roblox services so, I’d be curious to see if running headless still uses those services or disables them.

I would not be surprised if roblox-cli included a graphical element (via a flag) instead of just running code. If that’s the case, it would be pretty easy to create a place file, use roblox-cli and then, ship it anywhere but Roblox. I think that’s what they’re probably scared of.

Also, not that many people know how to use the command line so, this would only affect a handful of users in the beginning but, I’d argue is needed to help promote a better, quicker workflow. CI and other tools would be helped which would then, hopefully, translate to better stuff on this platform. As time moves on, I could see something like this translate well into external tooling and larger.

I feel like open source stuff has gotten hit with finding solutions that really could be solved by something like this. So, it’s not just setting a workflow back, it’s setting the open source community built around Roblox back.

Which again, doesn’t really translate well if you want to attract larger studios or more experienced people. Typically, and I speak for myself, we don’t like being locked to a singular set of tools and having pushback to do simple things outside of studio is very uninspiring.

—

This whole thing really highlights the challenges of being fully managed and tethered to a platform instead of being free to publish anywhere. In a typical game engine setting, the engine would be packaged with your compiled game and you’d be free to release it anywhere. The only real restriction is license terms which you have an idea of before you commit to a game. On this platform, you’re tied to it. The second you make a game on this platform and bring an audience, the audience is no longer just yours. It’s Roblox’s. It’s how they make money by tying experiences so deeply into the platform that they can’t leave.

It’s probably why open source has little to no support. Because if there’s a chance to decouple from the platform & retain services then, any rational developer would take it. Which goes against their revenue model.

If I were Roblox, I’d probably move to a licensed, fully managed solution because something would be really good and they’d be making a cut from licensing fees. We’d also probably get a whole lot better tooling. At some point, the maturity of the engine is going to outpace the purpose of the platform and the way that it’s handled. It’s just not at a point yet where you can visibly see it. Issues such as this do highlight some of those issues. This is outside the point if this feature request though and not up to me to decide.

#10

Honestly, with all this talk, I’d just recommend a --cli mode in Studio, where it’ll start a DataModel and run code without opening any UI, piping Luau output and errors to the console.

RobloxStudioBeta.exe --cli test.rbxlx

This way you still keep the Studio runtime and authentication stuff but dont need to start an entire application just to test code. The only problem is how it should kill the actual process, Roblox would probably have to expose ProcessService into Studio’s namespace

1 Like
#11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.