Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Need info on advanced custom node writing

Discussion in 'Visual Scripting' started by ChaosCraft, Aug 7, 2022.

  1. ChaosCraft

    ChaosCraft

    Joined:
    Feb 8, 2022
    Posts:
    7
    Hi all, I'm just getting into the visual scripting system - we have a few places we want to use it, and I'm very keen to make it as friendly as possible for our writers and artists to use.
    This is leading me to want a much deeper understanding of how the entire thing operates under the hood.
    As a simple example, many system node types use different colours. I'd like to colour code a couple of our node types (and if possible, some of our connectors too)
    My main point is... Where do I find out about this? Can I pull the code base and walk the code myself? Will I need a PhD to understand it if I do?
    The things I most want to understand right now are,
    - How much further can I go in custom node design? Can I get into how a node is drawn etc, can I control port icons or colours (for eg, colouring Fail condition flows with a red arrow?), Can I add non-port configuration properties on a node type (i.e stuff that would be set in the graph inspector where it shows inputs not on the node block - and yes there is a good reason)
    - What are the various functions on the Flow and Unit types? Can I use flow to interrupt or pause a node while the rest of the game continues?

    I have a bunch of specific goals these questions relate to and I'll ask them in separate threads, but my main question is Where do I go for detailed documentation on how it really works? or is there somewhere I can get to the source code for it all so I can see for myself?

    I hope someone can point me in the right direction,
    Regards,
    Keith Ealanta (Chaos Crafter)
     
  2. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    355
    Hi Keith, documentation is indeed scarce. I actually found that adding UVS to source showing in VStudio gave me a dictionary of logic to try and figure out how it works. You show different items in the solution using the Unity preferences/settings somewhere (Packages: yes) As it's a package, this is the source code.

    If you really wanted full control over how a node is drawn, you would basically override it from scratch, but there is a lot to it if you want to fit within the framework design (alternatively just draw it as you would a normal editor inspector using the framework to figure out width/height etc).

    Changing colour is possible although it uses a weird colour mixer. You could however tag things with your own colour which might be easier, or really just draw from scratch (not sure if you can make your own custom ports with icons though, but maybe). Personally speaking, the whole thing is extremely flexible.

    Non-port stuff is pretty easy, you can have these show in the inspector, or show as a unit header.

    Co-routines are nicely integrated into UVS, whether calling custom coroutines or stop and wait until next frame etc. The various functions are basically C# in some form, optimised into a custom node.

    The cons: UVS works with reflection and is not meant for complex algorithms, or processing of 1000s of objects/arrays/lists. Better to use it as a switch per se. Custom code/packages, easily added into it, this creates a reflected node, which are much slower than a normal node. Wrapping into your own custom node would improve this. Currently issues building to IL2CPP and no idea if Unity are working on fixing it (missing AOT stubs for different things that rely on Editor assemblies).

    The pros: Messing around with various C# functions quickly and easily, changing things around without code. 'Mainly' zero reload time, plug and play. Unity and code modifications is a nightmare these days with reloading. Easy prototyping of different ways to do things, before converting back to code. In code this would be modifying 1 variable and waiting 10+ seconds every time, in UVS it's simply changing the variable on the fly.

    I would say it makes a great tool as it is, for prototyping, and also as an in-editor tool using a manual trigger (custom node out there, but I have also made an updated version that's compatible with newest UVS). Imagine batching different things in the editor, eg. find all X_sprites and swap with Y_sprites. Making that with code would be a little more funky.

    I don't think using it as a main engine for a game is the great idea unless it's simple and optimisation is unimportant, but maybe for switches like menu control, changing shaders, simple controls like player movement. But not high intensity maths. Mainly it might not be a good idea to use as a main engine, because a) there are some issues that need fixing, b) Unity haven't said where they are with it, whether it is actively being worked on. If they had news on that, they would share it, but as you know there have been a few 'changes' recently at Unity, so not sure how everything is affected.

    It's been a while since I was into it, but mainly I was working with custom nodes, trying to make things that might be useful. Had some people I felt enthusiastic around but they're gone now, so it's not the same. Hopefully the spirit of UVS can be revived, it only takes a few passionate people to do that. But I really would say, anyone making a game wants it to be optimised, but UVS can be used to test different ideas, fast (even have a simple-ish game running within it). A programmer can easily type that pseudo visual back into code, so I don't see why it can't be complementary to the whole project, as a tester, maybe as an engine, but ultimately as a designer/prototyper.
     
  3. ChaosCraft

    ChaosCraft

    Joined:
    Feb 8, 2022
    Posts:
    7
    Thanks for the response - in my case the game is not real-time, so there is plenty of time for code to execute.
    What I want is to build a set of tightly defined tools that our artists and writers can use to script the effects of playing a particular card - basically, each card can have a graph using custom nodes for all the processing. It should be perfect for that.
    I've been doing exactly as you suggest to explore what Attributes are available and to try to look at what I can overload on a unit, but given the approach of using a separate definition for the editor etc. - Well, basically there's a heap there, and it would be such a help if it was properly documented for the custom node coding. As I say, If I could read the source, I could (probably) work out how it all works and use it to full effect. As it is, I'm just poking bits and posting anything I find on the discord server for others. I'll admit I'm considering switching to uNode as that generates C# so it'll be easier to figure what is happening.
    Mostly just frustrated because this looks like it's pretty full-featured but is crippled by the assumption that it is written for non-coders, when one of it's best features is the ability to set up custom support for the team.
    If anyone knows who I might contact with access to the code-base, I'll try to jump through whatever hoops they require to get code access and to then start documenting what I find.
     
  4. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    355
    The code is all there in your packages. Add it to your solution in Unity pref/settings. A good place to look is in the framework/units for how they work, and the setup of baseclass Unit. Another good source is the addons where I spent alot of time learning (and speaking to the programmer who one day vanished).

    https://github.com/RealityStop/Bolt.Addons.Community

    I have heard uNode is pretty good so definitely another option. Also FlowCanvas. Definitely might be more stable, and actively developed.
     
    ChaosCraft likes this.
  5. ChaosCraft

    ChaosCraft

    Joined:
    Feb 8, 2022
    Posts:
    7
    Thank-you so much - I'm so used to everything arriving in dlls I never thought to go looking for the code in the libraries.
    .I expect that is going to make all the difference to me. (rolls up sleeves) Now to have a look at the unit class.