The purpose of Volt is to simplify the game development workflow as well as provide more power to game developers. Many people will create their own frameworks specific to their games but there are a few public ones that exist such as Volt, Aero Game Framework, and Knit. They each have a different feature-set but aim to make scripting a large-scale game easier.
Volt in its current version does this in a few ways. Firstly through imports. Volt has a really nice import function that allows you to require() modules in a seamless manner. Secondly through executables & bridges. Bridges act as a wrapper for and remove the need for RemoteEvents and RemoteFunctions. Executables use these bridges to run code similar to server & local scripts. The key difference is that you have control over how these executables run. You define which executes first, second, third, etc. On top of this executables can communicate with each other. Right now in Roblox if you had two server scripts and wanted them to talk to each other whether it be by calling a function or passing a value you have to create a BindableEvent or BindableFunction. This is tedious work that executables solve by making themselves public to other executables.
Like @nodoubtjordan mentioned it’s interesting in that it’s unique. Volt doesn’t attempt to completely replace server & local scripts but rather provides a more powerful alternative. This is something I personally haven’t seen anywhere else and I really don’t know how it will pan out. Maybe the idea is too strange for people to become accustomed to or maybe it really is as good as I think.
Regardless, try it out and try to familiarize yourself with it. Feel free to give me any feedback!
I’d say interesting, but the documentation is very lacking. Check out AGF & Knit documentaries for inspiration. Also, you should add a few libraries RoStrap because some of them could be useful.
Yeah this was a fear of mine when I posted this. I tried to go as in-detail as possible and thought the crash course video might help but there’s really a lot to unpack. I have little experience with GitHub pages but have been doing research and will hopefully get a site up and running built with docsify for more in-depth documentation. As for RoStrap I’ll definitely include a surplus of libraries from there in the next update. Thanks for the feedback!
Yes, but why reinvent the wheel when there is literally an official method to do this? (and likely more reliable if one day Roblox devices Players.LocalPlayer should return a non-falsey value on the server for some reason)
I was honestly unaware of the IsClient method but I think I’ll implement it as it’s a bit cleaner in terms of readability and this is meant to be an open source project.
For readability and functionality purposes. Using a forward slash based directory system looks clean and inherits the style of Unix & Mac file systems. Is there a different way you believe is more user-friendly?
I guess it’s a stylistic choice, but seems against the Lua standard of using dots. Personally, even if the resources taken up for string manipulation are negligible, I’d go with dots. I know Roblox’s intellisense is garbage, but they might fix it in the future.
Quickly create executables with this plugin. Executables can be tedious to create and the plugin simplifies the process. Type your executable name in the UI and hit Create. You’ll get yourself a new folder with two generated client & server executables containing base code to work off of. They also will automatically append .Client and .Server to follow Volt naming conventions.
It’s a bad idea in the extremely rare case of someone with the name LocalPlayer joining the game. I’ve seen games being broken because players, who had their names coincidentally be the properties or events of the Players service, broke the whole server handler.
It’s bad practice not to use IsClient.
Game frameworks act as ways to simplify game development and provide tools to make game development easier. Volt is a general-purpose framework. Let’s say you were making a money system for your game. You want the server to handle and store player money. You want the client to be able to get how much money a player has for let’s say a Shop GUI. Normally you would have to write a lot of code to get this done. You would have to write a module for storing the player money data, a server script for handling the remote function for getting player money, then also write a way for the server script to interact with the module storing the data. Don’t forget about actually having to create and organize all these scripts and the remote function.
With Volt you can do all this in two scripts. And organizing? Volt provides a nice path system that will simplify game:GetService('ReplicatedStorage'):FindFirstChild('Something'):FindFirstChild('SomethingElse') down to 'Something/SomethingElse'. Using the Volt framework you have one script for your money that handles storing it as well as registering bridges, a Volt feature for communicating between the client and server, and another script for your client that will just handle your GUI.
There’s a nice in-depth example over here you can check out if you want to see something similar in code.
@Trickstaarz Since you asked the same question feel free to read this
Await() function to wait for an executable being executed after to complete. Helps break the strict linear control flow and allow for web-like branching out. This is the first in a series of methods to help accomplish this.
function import(location)
local args = location:split('/')
for index, object in next, game:GetDescendants() do
if object:IsA('Folder') and object.Name == args[1] then
if not args[2] then return object end
if object:FindFirstChild(args[2]) then return object:WaitForChild(args[2]) end
end
end
return nil
end
What’s New
GitHub