What is LuX?
If you’ve used scripting in BrickBit before, you’ve probably seen us refer to it as Luau. That isn’t going away, but we’re starting to give BrickBit’s scripting environment its own identity.
It’s called LuX.
LuX is BrickBit’s Luau-compatible scripting environment. The idea is pretty simple: keep the Lua/Luau syntax people already know, while building an API specifically around BrickBit.
That means code like this will still look familiar:
local Players = game:GetService("Players")
local player = Players.LocalPlayer
print("Hello, " .. player.Name)
We aren’t making a completely new language just to make things different. LuX is still based around Luau, and existing .lua and .luau scripts are something we want to keep compatible with.
What we are changing is everything around the language.
Right now BrickBit scripting has grown in a few different directions. Client scripts use things like game:GetService(), workspace, Instance.new(), Vector3 and Color3, while hosted server scripts currently use the separate Bridge API.
It works, but having two completely different ways of scripting the same game isn’t where we want to leave it.
LuX is our plan to clean that up.
Over time, we want Studio, the client and the game server to share much more of the same API. A system such as Players should feel like Players everywhere instead of requiring one API in a client script and another API on the server.
We’re also going to keep expanding what scripts can actually do. Better instances and events, proper replication, more services, improved UI scripting, stronger datatypes, better networking, more complete physics APIs and much better autocomplete are all areas we want to work on.
One of the biggest parts of LuX is going to be Studio itself.
The script editor should know what is available, show useful autocomplete, explain functions and properties, warn when something only works on the client or server, and use the same API information as the actual runtime. The docs and Studio shouldn’t disagree about whether something exists.
We also don’t want to pretend BrickBit is Roblox.
There will be familiar names where they make sense, especially because being able to move Luau knowledge between platforms is useful, but LuX is going to be BrickBit’s API. If BrickBit needs something different, we can build it properly instead of forcing everything to copy another platform.
Nothing is suddenly being broken or replaced today. LuX is the new name and direction for the scripting system we already have, and we’ll be improving it piece by piece rather than throwing out existing games.
For developers, the main things to know right now are:
LuX uses Luau-compatible syntax.
Existing .lua and .luau scripts are staying.
Current client scripting continues to use the BrickBit client API.
Current hosted server scripts continue to support Bridge.
We’re working toward a more unified API between Studio, clients and servers.
The documentation will be expanded as LuX grows.
This is one of the bigger parts of BrickBit we want to improve over the next few updates.
More LuX documentation and scripting changes are coming soon.
It’s called LuX.
LuX is BrickBit’s Luau-compatible scripting environment. The idea is pretty simple: keep the Lua/Luau syntax people already know, while building an API specifically around BrickBit.
That means code like this will still look familiar:
local Players = game:GetService("Players")
local player = Players.LocalPlayer
print("Hello, " .. player.Name)
We aren’t making a completely new language just to make things different. LuX is still based around Luau, and existing .lua and .luau scripts are something we want to keep compatible with.
What we are changing is everything around the language.
Right now BrickBit scripting has grown in a few different directions. Client scripts use things like game:GetService(), workspace, Instance.new(), Vector3 and Color3, while hosted server scripts currently use the separate Bridge API.
It works, but having two completely different ways of scripting the same game isn’t where we want to leave it.
LuX is our plan to clean that up.
Over time, we want Studio, the client and the game server to share much more of the same API. A system such as Players should feel like Players everywhere instead of requiring one API in a client script and another API on the server.
We’re also going to keep expanding what scripts can actually do. Better instances and events, proper replication, more services, improved UI scripting, stronger datatypes, better networking, more complete physics APIs and much better autocomplete are all areas we want to work on.
One of the biggest parts of LuX is going to be Studio itself.
The script editor should know what is available, show useful autocomplete, explain functions and properties, warn when something only works on the client or server, and use the same API information as the actual runtime. The docs and Studio shouldn’t disagree about whether something exists.
We also don’t want to pretend BrickBit is Roblox.
There will be familiar names where they make sense, especially because being able to move Luau knowledge between platforms is useful, but LuX is going to be BrickBit’s API. If BrickBit needs something different, we can build it properly instead of forcing everything to copy another platform.
Nothing is suddenly being broken or replaced today. LuX is the new name and direction for the scripting system we already have, and we’ll be improving it piece by piece rather than throwing out existing games.
For developers, the main things to know right now are:
LuX uses Luau-compatible syntax.
Existing .lua and .luau scripts are staying.
Current client scripting continues to use the BrickBit client API.
Current hosted server scripts continue to support Bridge.
We’re working toward a more unified API between Studio, clients and servers.
The documentation will be expanded as LuX grows.
This is one of the bigger parts of BrickBit we want to improve over the next few updates.
More LuX documentation and scripting changes are coming soon.
3
0