I would just like to know if a visual scripting solution such as Bolt has a faster workflow than actual C# scripting. I work for a company that creates 2D educational games and our deadline limits us to about 2 games per day. The games are not complex - they are mostly simple 2D clicker games. With scripting, I was able to push 1 game per day. The worst case scenario takes me 3 days to complete a game. I don’t want to invest in learning something that is going to be futile in the long run. So, my question is will visual scripting help make my workflow faster?
Any other recommendations would be appreciated as well.
If you are already comfortable programming in an IDE, no. They both accomplish the same thing more or less, it’s just a different way of interacting with the engine. It’s the same as using the GUI vs command line in an operating system. GUI is really convenient at first, but once you learn the command line it becomes much much faster to do stuff than clicking elements all over the screen.
When you consider the full workflow including testing and maintenance, as well as working with designers, in some limited situations certain types of visual scripting are faster. Controlling AI agents using visual FSMs or behavior trees is a good example. In a visual system, you can immediately see what state the agent is in and what transitions are valid, and often you can click on a state or transition to manually switch the agent’s behavior when testing.
Since the OP needs to crank out 2 games per day, most of which are similar to each other, templates would probably be more useful. You could set up a project/system where you just drop in text, images, and maybe a spreadsheet of numbers, and click a custom “build game from template” button to build the game without doing any coding specific to the game. For an extreme example of using templates to crank out games in Unity, watch Alex Schwartz & Ziba Scott’s GDC presentation: 1500 Slot Machines Walk into a Bar: Adventures in Quantity over Quality
Look at it this way; is it faster to double click on my computer and browse the drive and its folders or to hit the windows key on the keyboard and type in the program you’re looking for?
This. Visual scripting is best when it’s used in conjunction with coding. Just about every bad example of visual scripting out there is an example of what happens when you don’t do this. Visual scripting is intended as a glue logic at the very highest of levels and with as few nodes as possible.
If you need more functionality than can be provided with a handful of nodes then the intention is that you write a custom node that implements that functionality. Modern visual scripting tools do provide support for this without having to write code but for the most part you would use code to write custom nodes.
Visual scripting allows the artists and level designers to implement functionality in the game while taking some of the burden off of the programmer so that they can better focus on the aspects that they need to focus on.
If used appropriately in the right parts, sure. If you think you’ll just replace one tool with another and everything will magically get faster, probably not.
Think about the pros and cons of each in the context of your team or studio.
Do programmers get regularly asked to write simple logic for other people to be able to do their job? If so, then a visual programming tool to handle that simple logic might save time for both the programmers and whomever is waiting on them.
Do people regularly spend time writing code for things that could effectively be represented visually? FSMs and Behaviour Trees are common examples here. Moving to decent visual tools for these things can shift some of the work to non-programmers, but even for programmers being able to visually modify things and have the system just maintain itself is a real time saver. And visual representations of object state are a time saver for everyone. (“Why isn’t it going through the doorway?” “Ah, it keeps getting bumped back into ‘Cautious’ and backing away.”)
Are people doing stuff by hand that’s just application of simple rules? If so, a visual system to describe and aply those rules could be a real time saver. Terrain population systems are a common example here - anything below X height is underwater, anything with slope > Y is cliff face, and so on.
In other words, specifically consider how best to approach each task your team does, rather than trying to replace an existing solution (C#) with a generically better one.
“It makes simple things simpler, but also makes complex things impossible”. I’m half-joking here, though.
In case of visual scripting tool, making something very trivial likely is going to be faster than writing that in C#.
However, when you’re dealing with complex logic, you’ll hit scalability problems, and it will turn into a mess.
Basically, visual scripting tools have poor readability compared to text, are not supported by diff tools in source code repositories, and when you have a lot going on, you’ll get spaghetti from hell.
To prevent that from happening, the idea is to keep only very high level logic in visual scripts, and code building blocks for it in C#. Like @Ryiah said.
Pumping out 2 complete games per day doesn’t sound like reasonable expectations. This is a problem for the PM that signed off on that deadline though. Sounds like what you really need is a bigger team, or an actually realistic deadline.
And it seems unlikely you’ll find one that’s made to handle whatever exact thing these game need done.
Plus, making 1 game a day means you’ve got the process streamlined. The transistion time to a new one might be pretty long.
And Unity already has some of the advantages of visual scripting. The curve-maker can replace an equation, empty game Objects can be placed at points and adjusted to make boundaries.
With bolt you can do visual scripting in playmode what is much faster than having to exit every time and open visual studio and do your changes, save and compile and go back to unity and hit play and find the place what you are editing and repeat… this will save so much time when your project gets heavy and entering play mode takes time. Also there’s the disconnect when you have to work in a separate software and window if you use visual studio compared to bolt that is integrate to unity. Also with bolt you wont really have the problem with typing errors or if what you are doing is wrong you will be notified mostly immediately. You can also nest your code to tidy it up and create and share templates. But of course coding is more performant than visual scripting but fingers crossed unity visual script will improve that cap and maybe with code gen in the future.
Open Visual Studio? You know you can leave it open, right? You can even make code changes in play mode. You just can’t save them and test immediately.
As far as editing live, I think people do that with ScriptableObjects. You can tweak the data in there during playmode and have it stay. But not as flexible as being able to live-edit code.
This has generally been a big problem with visual-coding – tricky to call a function or cut&paste code. I think Scratch made some progress on this. Nice to hear other people are trying it. But this isn’t an advantage of visual programming – written code is way better at nesting, sharing and templates (unless you don’t know how, then visual clearly wins).
