Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Playmaker, NodeCanvas, FlowCanvas or Makinom... Request Guidance

Discussion in 'General Discussion' started by GarBenjamin, Jan 23, 2016.

Thread Status:
Not open for further replies.
  1. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Hey folks.

    The TLDR Version

    For an experienced programmer which of the following do you think is best and why?

    PlayMaker
    NodeCanvas
    FlowCanvas
    Makinom

    I am especially interested in hearing from folks such as @BoredMormon, @Ryiah and others who are programmer-oriented. However, I'd appreciate hearing from non-programmers who have experience with one or more of the above (especially if you have experience with two or more of them for comparison purposes).


    The Story (The "I've got some time on my hands" version)

    I've always had a real challenge getting my head into the Unity Way of working. Meaning popping in and out of the Editor.

    I definitely see the advantages of using the Inspector and do take advantage of that to customize object settings.

    Been programming a long time and a lot of it was very low level. So it was just a huge change and I am devoting this year to making the transition.

    My latest moment of eureka has me thinking maybe the way for me to really get my head into this is to just take the massive step of going nearly fully visual.

    By this I mean something that will keep me in the editor doing the majority of work. See I think it is the fragmentation of jumping in & out of the editor that I dislike. For me personally it feels like "stop points" of continually changing task. Back & forth. And I would prefer to either be one or the other.

    Up until now I have always chosen the other. To spend the absolute minimal time possible in the Editor. Basically just creating prefabs & setting up audio & visual assets and then I am done. No more time in Editor except to hit Play (and that is when I tweak inspector values). Beyond that, all of my time is in VS or MonoDevelop or sometimes Notepad++ if I already have that open.

    Anyway, I have been investigating on the asset store and researching online and have narrowed the choices down to Playmaker, NodeCanvas, FlowCanvas and Makinom.

    Now I realize that with any of these tools I will still need to write some custom scripts or even modify their scripts. I have no problem doing that.

    I'd rather not spend the money (about $250) and the time (maybe 20 hours?) just to test each of these firsthand.

    And this is where you come in.

    If you have experience in using these which do you think has the least performance issues while offering the greatest amount of "out of the box" components / actions / functionality?

    Thanks so much for your time and guidance! :)
     
    Last edited: Jan 23, 2016
  2. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Avoid playmaker and visual programming tools. Waste of time, lots of underlying problems.
    http://va.lent.in/should-you-use-playmaker-in-production/

    The ONLY area where visual programming tools are useful is when you're writing ai behavior trees. And even in that case writing node code in normal programming language makes more sense, plus behavior trees are not "node-based visual programming".

    Aside from that single area, visual programming tools are a crutch for people that can't write code. And you have some programming experience, as far as I know.

    ------

    If you want explanation, then so far I have not seen a visual system that could beat old coding approach. I have experience dealing with Unreal Engine 4, and after working with that, I can tell that I hate blueprints with passion. The main issue is that in any visual system it takes too much effort to make even the simplest thing, and 5 line of code can turn into screenfull of spaghetti. It is not worth learning. You literally gain nothing.
     
  3. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Thanks for sharing your opinion. I actually agree with you and have mentioned that on these forums many times. I'm a software engineer both as a hobbyist and by profession for a long time now. And I have always found writing code to be the most logical and simplest way of doing this stuff.

    What I am doing now is well basically think of it as I am wanting to "broaden my horizons" so to speak. I realize using one of these tools will likely slow down my development a fair amount. Normally, I can develop quite quickly because again it is all just code. Define some goals break them down. Define states break down into tasks. I honestly think it doesn't get any simpler than that.

    BUT... that is all I know because it is the way I have been doing things for the past 30+ years. Just software engineering. Writing code. What I want to do now is explore the alternative and see if that helps me to better connect with Unity.

    It just seems to me like Unity is almost ideal for visual programming. I mean the thing is set up to be pretty visually oriented as it is. I just don't use that stuff such as the Animator and so forth because I've always built my state machines in code.

    Honestly, looking at Unity though I am a bit surprised it doesn't actually come with something like Playmaker or FlowCanvas built into it. Because these things seem to be exactly along the line of how the Unity engineers were envisioning the system when they built it. Very visual. Scene-based. Drag and drop. Yet it stops halfway.

    So I want to explore if bringing in the other missing half will make it all come together better and be more logical to work with. Because otherwise I don't see why they just didn't make some DLLs basically just a framework like many of the other things I have used in the past. Just link to the libraries all code and never even bother with the Editor period.

    Anyway, thanks again. I want to get some input from people who have and are using these assets.
     
    HogofSteel likes this.
  4. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Can't help you here. I watched a bunch of tutorials on Play Maker when I first started Unity. It looked pretty cool. I promised myself that I would buy it with my first $75 of revenue from games. Turns out making that first revenue actually takes a long time. So when it came time to spend the money I was already a competent C# coder. So I've never actually used any visual scripting tools.
     
    eterlan, Xtro and GarBenjamin like this.
  5. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    I used playmaker for fun. I recommend it if you want to make a game of programming your game. But if you're actually programming something then it's probably not a good idea.
     
    stain2319 and GarBenjamin like this.
  6. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    I have not seen or heard of any "visual programming tool" that works. Making programs from flowcharts sounds fun in theory, but in practice it results in unusable spaghetti and code that is harder to read and extend than text. I suspect there's some fundamental flaw with the whole visual programming idea.

    Well, In that case, I'd advise to look into Animator Controllers, animation state machines, StateMachineBehavior's, and humanoid animations in mecanim, plus into HumanBone-related data.

    That will do you more good than tinkering with playmaker.

    Also, I'd be extremely surprised if your own state machine can beat built in animation controller capabilities. It is not perfect, but it is not something you can quickly create yourself as a "toy project".

    It is a pity that unity doesn't have Unreal's Montages, though.
     
    GarBenjamin likes this.
  7. theANMATOR2b

    theANMATOR2b

    Joined:
    Jul 12, 2014
    Posts:
    7,790
    Hey Benjamin - my 2 cents.
    If you read the biased article based on the original Playmaker plug-in that neginfinity linked to I implore you to also read the lengthy comments on that article to get a proper perspective from more than one persons slanted opinion.
    Not to dismiss the article or the writer - but in my opinion it's not a fair/balanced representation of the tool nor what can be accomplished using it - without reading the comments and additional links below.

    I'd also direct you to the Playmaker website http://www.hutonggames.com/
    and to the Playmaker forum thread here http://forum.unity3d.com/threads/pl...ing-for-unity-30-off-until-next-update.72349/
    which provides several examples that Playmaker is a solid production tool for non-coding artists as well as programmers, and can be used to develop complete, bug-free, successful games, beyond what other people want to say.

    With that said - I think you'd find Playmaker cumbersome and just another layer of abstraction that requires you to work the way it was created - rather than allowing you to create the way you prefer - via code/scripts.
    I state this last point knowing how you prefer to work, your workflow and knowledge base.

    You may also consider in your research behavior designer.
    There are also several threads comparing different visual scripting tools on this forum, which ultimately steered my decision (as a non-coding artist) to purchase Playmaker.
     
  8. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,616
    I find it interesting that jumping between your code IDE and the Unity editor feels like a stop point for you. To me, as a cider, they're part of the same environment, joined at the hip as far as making stuff in Unity is concerned. If one is open then so is the other, and switching to my IDE window feels little different to switching tabs inside Unity.

    I don't want to discourage you from trying out new tools and workflows, and would love to hear about the experience afterwards. That said, I'm not sure how adding a visual scripting tool will help you get used to "the Unity way". It seems to me that it'll add another layer of abstraction, a new dependency, a new learning curve, and move you away from a skill you've already honed well - writing code as text. At the end of the day its what code you write that matters, rather than how you write it... right?

    Perhaps I'm not entirely clear on what parts of "the Unity way" you find challenging?
     
    Joel_Dittrich, Kiwasi and GarBenjamin like this.
  9. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,965
    While I do own PlayMaker (during some random sale a year or two ago), I've never taken the time to try it out.

    Have you heard of or considered Script Inspector? It's an IDE but it's integrated into Unity.
     
  10. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Thanks for all of the replies. I appreciate it.

    Done some more research in the meantime and am leaning towards NodeCanvas.

    Before I get it though I am going to try out ICode which is very cheap and looks interesting as well.

    @angrypenguin I definitely hear what you are saying and I have no clear answer for it either. Other than I am trying to change my frame of mind about development. Until Unity I was used to always working in just code. There was no editor (well other than a code editor and I was used to Notepad for years). Heck even back in Blitz3D and Direct3D there was nothing but pure code. Sure you had to go into other tools for 3D modeling and so forth (or just get models in md2 or .X format) but those were completely separate tasks usually done (by me anyway) in separate dev sessions.

    I am so "into the code" that when I first opened Unity I almost just closed it and forgot about it. I was expecting just a framework, code libraries to work with. I had the same experience when I checked out GameMaker Studio. Opened it and closed it within a few minutes.

    So the best way I can explain what I am hoping to achieve is to expand my view of development to encompass working inside these modern visual IDEs with more of a visual workflow. It probably won't make sense to anyone else because it is just a personal challenge I am focusing on. :)
     
    Last edited: Jan 24, 2016
  11. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,149
    I posed a similar question a while back. To date I have bought 0 assets, and in the mean while I've been building up my own sublime snippets specifically for unity.

    I think I made the right decision. I was close to being almost sold on blox2 but the more I looked at it, the more I realised it just does simple things you already know how to do, like quickly move a box using WASD, but instead of pulling up the api you have a visual click box.

    The only thing I can recommend to trial without buying, is probably blender or unreal, in blender you have what I would imagine to be a very similar way of creating gameplay with noddles in its game engine. It's wonderful to begin with, but after time it doesn't do what you need.
     
    GarBenjamin likes this.
  12. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    I tried out ICode last night. Seems to have a lot of functionality. Definitely is a huge difference to work with. Although it actually reminds me of a program I tried a long time ago on the C64 Gary Kitchen's GameMaker that allowed you to build an entire game with a joystick.

    -----------------------------
    NOTE: If anyone wonders what this C64 thing is people mention from time to time on these forums. Here is a good recent video on it by a guy who recently quit his job to focus on it full time.

    -----------------------------

    Anyway, it will take some getting used to for sure but I am going to spend an hour or so today playing around with it. If it doesn't I will just return to my normal way of developing.

    I guess a big part of why I am doing this is because it seems like I am always missing something about Unity, GMS and so forth. Something that others see and like. I am trying to find what that something is so that I can appreciate it too.

    Normally, my work on games starts with some doodles on paper and then some time spent messing around with diagramming. I think of all of this as basically doodling just to lay out some ideas, define behaviors and so forth.

    I haven't done that in a long time and have been basically doing this stuff while I am developing. Recently, I decided to get back to my old habit. For example a couple days ago I was doodling for the enemies in my FPS Action Adventure game.

    The flowcharts and stuff won't make sense in a pure form as far as implementation goes but it is just a way for me to get my mind centered on the task at hand. Like I said... doodling. This is just how I always started on the process of bringing a game to life.

    After this I would then create some diagrams for state machines or simply do flowcharts. This kind of thing I have always found to be a very simple and powerful way to design and find flaws before jumping into implementation. So I used to start every project this way. The past couple of years I have just jumped in and relied on refactoring heavily to handle any bumps in the road.

    So anyway... I do think getting back to my old routines will help a lot.

    And maybe because I am so used to doing this kind of thing on paper or with dedicated diagramming tools is perhaps the reason I have some kind of block about doing this stuff inside game dev kits. Like my brain may say "wait a second you don't do this stuff here. You have never done this stuff here." I don't know. Maybe I am just insane. ;)

    Anyway, so I am going to spend some time with ICode today. If that doesn't click I will just return to what I was doing in the past that worked for me. However, I have hope that maybe I can make this modern visual development stuff click for me at least in some small way.
     
    Last edited: Jan 24, 2016
    Ryiah likes this.
  13. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,521
    GarBenjamin likes this.
  14. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,670
    I've used PlayMaker, Node Canvas, Makinom, ICode, plyBlox, and GameFlow fairly extensively since I maintain integration packages for them to work with the Dialogue System and Love/Hate. (Gavalakis actually maintains the Love/Hate Node Canvas package.) They're all good, and they all have their particular strengths. PlayMaker is a straight-up FSM engine. plyBlox is like Scratch for Unity. Makinom places more emphasis on larger functional subsystems. Watching a couple tutorial videos on each will give you a good idea of how each works.

    That said, PlayMaker has the biggest user base and forum full of answers, the most integration packages with other Asset Store products (which is nothing to scoff at if you want to stay in the Unity editor rather than code your own integrations), and the most finished games behind it (Blizzard's Hearthstone, Dreamfall Chapters, The Forest, Dear Esther, etc.). So you know it can get the job done. That's not to say the others can't; they're all made by great developers who provide excellent support, so if the features of one of them appeal to you more than PlayMaker, certainly give it a try.
     
  15. zenGarden

    zenGarden

    Joined:
    Mar 30, 2013
    Posts:
    4,538
    I use Uscript basic, it is very similar to UE4 Blueprints but lot more easy to use. You can create variables in the graph and modify values, and it is more easy to view and read than Playmaker.
     
    GarBenjamin likes this.
  16. robahouston

    robahouston

    Joined:
    Jul 3, 2012
    Posts:
    16
    Makinom is not the same thing as playmaker. I can't speak to the other softwares, but playmaker is a visual scripting while makinom uses an events system that mimics something that playmaker can do but is limited to what its original design is capable of. Where playmaker can literally make anything the same way you can code something to do whatever you want in a game, makinom is limited to a series of available categories. I am a ORK framework poweruser and makinom takes the events system in ORK and juices it on steroids, and in fact the two are rather complementary of one another but in no way require either one to accomplish your goal.
    Really makinom is for people who don't want to code at all and playmaker is for people that want to code but don't want to learn how to write it correctly but still want to understand how code syntax and logic functions work, there needs to be a base understanding of coding/scripting to really utilize playmaker in my opinion. Also, playmaker is the closest thing to blueprints that unity is going to get for the foreseeable future. Blueprints is an UE 4 visual scripting solution that is bonkers good. I would suggest giving it a look.

    Hope that helps.
     
  17. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    As I was transitioning from writing my own behavior tree implementation in another C++ engine, I found it time-consuming to implement the system, and also time-consuming to implement the code to use the system. I didn't want to spend more time to write my own behavior tree visual editor in that engine, and this was about the time I was transitioning to Unity.

    I discovered Behavior Designer first, spent a couple of weeks of evaluation, and was satisfied with its implementation, its ease of use, its developer (@opsive) support, and its performance, as well as developer benchmarking. I had a couple of requests implemented in a very quick turnaround. I decided to also evaluate NodeCanvas, since it was on sale at the time. @nuverian is also very good at support. The main thing that turned me off of NodeCanvas though, is that it tries to do too many things, and that concerns me for performance and stability. The irony of that though, is that I am using NodeCanvas for its DialogueTree system, which is very good.

    And finally, I bought PlayMaker on another sale, messed around with it for a few minutes, and have not yet turned back to take another look at it. It felt like the overhead was just way too much for anyone who is more efficient with writing code in a text IDE (Not only that, but I'd rather use my all 10 digits instead of just 2 digits on the mouse, because I need to save them for FPSs and RTSs ;)). I would only use it if I was really bored, and not serious about shipping my products.
     
    Last edited: Mar 2, 2016
    jay-jin likes this.
  18. PolyMad

    PolyMad

    Joined:
    Mar 19, 2009
    Posts:
    2,350
    And this should answer all those who say a game can't be completely (or almost) realized using visual scripting.
    Come down your pedestal: straight coding surely gives a lot more performance, but most games do not need all that performance and can be realized with visual scripting, giving a lot more space to creatives to realize their ideas without getting mad at learning language syntax and quirks.
     
    AGregori and HogofSteel like this.
  19. zenGarden

    zenGarden

    Joined:
    Mar 30, 2013
    Posts:
    4,538
    Playmaker is states with transitions, each state has linear actions, this is not comparable to a visual scripting using nodes you can connect anywhere.
    Those similar to Blueprints are Bolt and Nottorus (or Uscript but Bolt is chaper and lot more advanced).
     
  20. theANMATOR2b

    theANMATOR2b

    Joined:
    Jul 12, 2014
    Posts:
    7,790
    This is about 75% accurate because it doesn't take into account variables and global variables.
    However agree with Bolt and Uscript being very robust and versatile based on my hands off research. ;)
    I'm looking forward to seeing the first complete Bolt game release.
     
  21. DavidJares

    DavidJares

    Joined:
    Dec 18, 2016
    Posts:
    50
    I have playmaker, Gameflow, and Flowcanvas & Nodecanvas. Flow/NodeCanvas is a Gamechanger for me. Its an additon! to my scripts , NOT a replacement. Its main strengths are in my eyes : Very well implemented & fluid interface, everything makes sense - is kept minimal but still very polished, helps to watch the flow of your programm and its data visually, ENCOURAGES Experimentation ( Changing Nodes / Code DURING PLAY MODE ) ( Can you alter scripts during play ? ) . No Compilation Times after each change !!. Its fun to try things out. I use it for Orchestration of the smaller systems. Helps me to make things even easier. But for Algorithms or any concrete more complex functionality Id stick with my scripts. ( Actually , in the last time I use scriptable objects a lot =). But, I like to call those scripts from FlowCanvas if it makes sense. Digging deeper now into NodeCanvas the next days. I really can only recommend to have this tool in your toolbag. From the ones that I have it is my absolute favourite. Helps to look at thing differently and more visually. It supports me instead of getting into my way. If you don't want to use it in the game itself, it will at least help you prototyping much quicker because you can ITERATE FASTER!. Good n8
     
    HogofSteel likes this.
  22. Jingle-Fett

    Jingle-Fett

    Joined:
    Oct 18, 2009
    Posts:
    614
    I see this is an old thread. @GarBenjamin I'm curious where you're currently at with things, which tool did you end up using?
     
  23. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Ha ha... WELL... I tried a couple and as you might suspect they made the experience worse for me. Makes sense. I am text programming oriented and found visual programming to be very tedious.

    Honestly I simply switched to something that better matched my experience and preference. Haven't used Unity in a long time. I now do all of game dev in App Game Kit 2 (poor name choice imo because it actually supports Windows, MAC and Linux desktop, and web in addition to mobile and is centered completely around a programming api).

    I have used it with both the AGK BASIC (do the majority of my development in this BASIC now in fact which I find quite refreshing) and with C. It can actually be used with various languages such as the built-in BASIC or C, C++, Python, C# and soon to be Java/Kotlin.

    I'm just used to programming everything without so much focus on visual stuff as in working in a GUI editor setting up prefabs and things. For some perspective when I first tried Unity several years ago I was trying to use it by creating a new project directly inside Visual Studio linking to the Unity dlls. Checked online and finally launched the Unity editor looked around and didn't see any code editor or anything that looked remotely like a programming environment so shut it done.

    Obviously I did return later and work with Unity from the Editor for a few years. Normally in development I am used to building tools as needed and again everyone was talking about how powerful the Editor was and seemed to all build their tools in it as well. To me that just complicated and confused things like why I do I need to always be in this Editor? i guess it just "felt wrong" to me. Not that is wrong. It is just not my natural way of developing. And my own ambitions are quite modest too so am sure that has something to do with it.

    There you go another of my books. And it isn't meant to tick anyone off. Just giving the long answer to your question.

    TLDR: If you like visual GUI-based stuff probably any of the visual programming tools are good. For me I thought by going full on visual GUI-based perhaps that would help me better connect with the normal Unity workflows (like go extreme full-on gui-based then revert back to normal Unity and it would seem much less gui-based).
     
    Last edited: Jun 26, 2018
  24. Jingle-Fett

    Jingle-Fett

    Joined:
    Oct 18, 2009
    Posts:
    614
    Well that's good that you found a tool that works for you! About the visual programming, the tool I found that works best for me is Node Canvas since you still have to write your own code and plug it into the FSM/BT, so it's an enhancement to your code rather than replacement. Of course that still involves the aspect you said was giving you trouble, of switching between code editor and Unity.

    I don't know if you've been following what's been going on with Unity lately, but if you haven't already you might want to take a look at Unity's new ECS. It's in beta so it's still missing a lot of Unity's built in systems like physics (so you'd have to implement them yourself). But it uses more or less the same approach you used in your old Alien Vampader project.
     
    GarBenjamin likes this.
  25. ben-rasooli

    ben-rasooli

    Joined:
    May 1, 2014
    Posts:
    40
    Visual Scripting is not a replacement for text-based scripting. It's just a helper. You're already using it whenever you use unity built-in Animation System(Mecanim), Timeline, Shader Graph or even the Inspector. You can try understanding the Visual Scripting better and how to use it to make your workflow cleaner.
     
  26. HeadClot88

    HeadClot88

    Joined:
    Jul 3, 2012
    Posts:
    736
    I like bolt and version 2 of bolt looks awesome :)
     
    GarBenjamin likes this.
  27. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    LOL! Wow this is an old thread. About 3 years ago I was in fact exploring these options. I purchased one or two or maybe it was three. And tested. It was not good for me. Might be very good for others.

    I ended up going even more extreme to throw out the Unity Editor and built-in systems and did enjoy development like that more. But ultimately I shifted development to something else and enjoyed that more.

    Interestingly recently (last month) I tested out Construct 3 which is all GUI-based and visual programming based. Made a simple Christmas platformer game in 4 days. I found it to be shockingly logical and easy to work with. It's weird really because I also tested many others from Gamemaker Studio to UE and I can't even remember them all.

    But I think it just comes back to that every person needs to find that one thing that clicks. For me that is either just straightforward programming with a good game api or using Construct 3 if I want to easily take advantage of built-in systems and such. Actually just started a second game project in it which will be my 2nd paid game release at some point.

    Anyway I think for someone so used to code and doing nearly everything themselves or at least for me personally Unity was just far too extreme of a jump to make. However the more I use Construct 3 the more some of the Unity Way of doing things makes somewhat more logical sense to me. So I think perhaps in time I might even return to using Unity for a game at some point because I will have found a bridge from "my way" to "Unity Way". Maybe. It is possible.

    A more important thing may be where is @neginfinity? It seems he was here around Christmas but I haven't seen him post in the time I have been back here. Maybe just busy making a game. :)
     
  28. zenGarden

    zenGarden

    Joined:
    Mar 30, 2013
    Posts:
    4,538
    Perhaps making a triple A game lol
     
    Zarconis and GarBenjamin like this.
  29. crawfis

    crawfis

    Joined:
    Jan 30, 2014
    Posts:
    114
    So I will give an old fart (and academic) perspective. I was at SIGGRAPH '85? where the ConMan paper was presented, the precursor to almost all visual scripting work. Perhaps one of the best visual scripting systems was a Visualization tool called AVS (not to be confused with AVS Express). SGI and IBM had similar tools later. AVS had 4 categories: Importers for importing data, Filters for modifying data, Mappers for creating geometric models from the data and then renderers. The key point I want to make is that these were very high-level constructs. AVS Express and most of what we see in Visual Scripting tutorials are very low level (floats, Vectors, etc.). The former is very useful IMHO, while the latter is useless (especially for programmers). What I would like to see are tutorials that use blocks at a very high level. These can be written in C#, so you have both. AVS was ruined and the company folded when they listened to their customers (National Labs and supercomputing centers) and focused on performance and low-level control. The nice easy to use and experiment with interface now become complex for loops, etc.

    So, try state machines for an NPC where each node is a behavior (patrolling - many possible variants), on alert, etc. Or have nodes that are Cinemachine states and the graph switches between cameras at a high level.
     
    mihaelys, eterlan, AGregori and 3 others like this.
  30. sxa

    sxa

    Joined:
    Aug 8, 2014
    Posts:
    741
    Even old farts should check the dates of threads before posting.
     
  31. crawfis

    crawfis

    Joined:
    Jan 30, 2014
    Posts:
    114
    @sxa I knew it was old. I came across it on a search and others will as well.
     
    mihaelys, eterlan, AGregori and 5 others like this.
  32. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    We use node canvas for our AI, we use it strictly as behavior tree, all code is written in c# and the tree is used to Marshall the state. Also our AI is a hybrid between utility AI and classic behaviour tree AI
     
  33. DavidJares

    DavidJares

    Joined:
    Dec 18, 2016
    Posts:
    50
    own and used them all. flowcanvas! . easy to use, easy to extend so to make your own nodebased subsystems with it etc.
    well documented, well structured code. rock solid.
    no question for me, I payed full price and I would instantly do it again.
     
    AlejMC likes this.
  34. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
  35. AlejMC

    AlejMC

    Joined:
    Oct 15, 2013
    Posts:
    149
    First of all, thanks a lot for not getting discouraged regarding "necro-posting" or nasty comments followed after that. I'm seriously against locking (or self-censoring to post) threads on an on-going/on-topic subject because tools are not static in time, what started as an issue might have been resolved 50 post and 2 years later. I always go towards the end of the threads and I'm happy to see updates.

    3 years after the thread started update IS IMMENSELY valuable, because it might contain not only an opinion of what to use but a valid verdict of how those three previous years of using the aforementioned tools might have been.

    With that out of the way, yes, I seriously agree with your take. High level navigation is in my opinion a natural fit for visual graphs... the only one I have taken a stab at was Bolt because I got a coupon from the developer at the time (very nice of him) however, while it was quite powerful, it was hard to listen to standard C# events from outside a graph. I just wanted to handle high level menu navigation on a graph, nicely see in visual form where the user is at and where he/she can go to with the transitions that would allow it to happen. It ALMOST works... but like you say, it would be great to see tutorials on this specific use case.
    Low level handling of info like vector3s? yeah, it's nice that they are there for minor tweaks over the intended high level graph but I think it's secondary.

    I have bought afterwards uNode and DoozyUI for "whenever I have time™️" but it looks like I should give a try to flowCanvas according @DavidJares. If you have anything that you would like to add (time-permitting that is) for these 'high level' mindset or a warning to be aware of, would be greatly appreciated.
     
  36. crawfis

    crawfis

    Joined:
    Jan 30, 2014
    Posts:
    114
    In response to @Alejandro-Martinez-Chacin. I went through Unity's new tutorial on their Visual Scripting (aka Bolt) in 2021. I was pretty dismayed at the fact that events are single callback delegates. It did not appear you could Fire a custom event and have many small scripts respond to it. The result was spaghetti graph code in their simple tutorial. As an expert programmer, I found it very difficult to program and impossible to debug when things didn't work. I think the confusion between Graph, object, scene and persistent variables will overwhelm a on-programmer. Funny, I had to break my OO way of thinking and trying to reuse a "unit". Really need to think of these as statements in a programming sense (just bulky and fat).
    For Scripting, I would require multi-delegate events (true C# events) and programming to interfaces. Probably some more. I have FlowCanvas and will try that next. Unity seems to have missed the mark.
     
    AlejMC and Deleted User like this.
  37. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Standard c# events are bad design too since subscriber and publisher by design gets coupled
     
  38. crawfis

    crawfis

    Joined:
    Jan 30, 2014
    Posts:
    114
    @MDADigital Not sure I understand your point. I think it depends on how you implement it. "Publisher" is just a dispatcher in most of my implementations. The real content provider just asks the Publisher to fire an event (e.g., OnCollision asks the publisher to let everyone know that a collision has happened). It may pass itself as a sender for some strange and hopefully very rare circumstances. The Audio engine, the logger, the FX can all subscribe to this event.
     
    AlejMC likes this.
  39. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    I mean true c# events. They are a anti pattern. Since the subcriber needs to know about the publisher. An event aggregator is better
     
  40. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    MDADigital is a big fan of DependencyInjection, and the advice you're responding to is given with assumption "dependency injection everywhere is good, coupling is bad".

    If your focus is on "Getting Things Done", then you do not need to heed this particular advice.

    Then you'd need to know about aggregator, or you'd need to know all types of events in the system. Which is pretty much the same thing as having to know about the publisher.
     
  41. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Haha, no. It's not the same thing. You publish a event anyone can listen.
     
  42. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    So, you have two buttons in your application, and in the name of great(?) good(?) you've hidden them behind an aggregator. How does the listener subscribe to a specific button?
     
  43. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    @UnityMaru, @zombiegorilla, would it be possible to close the thread or slice it into two? The original poster hasn't been around for a long time, and the opening statement is 5 years old.
     
    MadeFromPolygons likes this.
  44. crawfis

    crawfis

    Joined:
    Jan 30, 2014
    Posts:
    114
    I don't know where you are getting this Mantra or information, but I will say it is incorrect. C# events are a tool. How you use them can be good or bad. Using them as a hammer for everything, perhaps bad (similar to the mantra's singletons are evil). Forgetting to unsubscribe is an anti-pattern. In a good case, they greatly reduce the coupling (a good thing).
     
    HogofSteel, AlejMC and Deleted User like this.
  45. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    That reminds me that apparently some of the designers of C# originally worked on delphi. It kinda shows in the language: property existed in Delphi first, and events were pretty much a central part of delphi API.

    The event-based system in C# is quite similar to the delphi events, except Delphi (IIRC) couldn't multicast, while C# events can.

    Another similar system that comes to mind is signals/slots from C++/Qt, BUT in case of Qt those were implemented via a custom source preprocessor, as the language didn't have proper paradigm for the signal/slot model at the time.
     
  46. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    There is no way you can not make c# events an anti pattern since to subscribe to them you need to know the publisher. You can't uncouple them. No way around it. Even Anders have admitted they were bad design.

    Anyway to go back to topic we use node canvas today but we think about scrapping it for an entire code based approach.
     
    Last edited: Apr 9, 2021
  47. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Button named Save automatically gets bound to method named Save by convention. if property CanSave exists button will be disabled if you set this boolean to false. From the save method you can publish a saved event and anyone interested in this can subscribe
     
  48. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    Are you saying that you rely on object names (or even, Cthulhu forbid, reflection)?
     
    Deleted User likes this.
  49. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    How do you think unity hook up your serialized on click handler?
     
  50. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,554
    If unity does it for their scripting language, that does not mean that it is a good idea to do the same thing in your code.

    Relying on object names for creating bindings in majority of scenarios is a bad programming practice, which increases likelyhood of bugs in your code. Because you move possible compile-time error into runtime, and in doing so create a possible heisenbug, as runtime check can be missed, while compile-time one prevents the program from being run in the first place. That's the reason to use events instead of name-based central subscriber.

    In this scenario events are a better choice, because when you alter something that breaks the call signature, the error instantly manifests throughout your code.
     
    ippdev and Deleted User like this.
Thread Status:
Not open for further replies.