Interested in Visual Scripting? Try GameFlow for a change...

Yeah good point, with visual scripting, blocking or whatever there's going to be a S*** tonne of expandable components to click through, that that example was trivial as well.

 

Great I need to concentrate on making my game

 

I do not think I have to "taking care" but thanks for the advice. What is good for some, perhaps not so for others, and I can tell, as I think you know, that have to know the experience with GF to know what we are talking about If not, they are only hypothesis about a product that is not known enough and criticism without too much argument.

It is not the same to see a video than to use GF.

 

I absolutely agree. However, the point was not much about GF in its current state, but such a thing would defy the spirit of visual scriptgramming as a RAD tool; I can also safely assume that @frosted is not one of those people that would be judgemental without facts - yet will be strongly opinionated and demanding of using any tool prior using.

I personally feel that GameFlow can grow a lot and has potential to become a leading tool for visual scriptgramming, but it is not there yet. With some extra ingredients, it will beat the living crap out of everything else (well... one exception, but that one will not be on Asset Store - as far as I know). However, if I would be invited a debate with GameFlow as ultimate tool today, I would filthify my undies if the audience had someone like @frosted and a Q&A session after. As I know which questions he could and would ask, just see those brown stains emerge and make me cry like a little piglet

 

I think there is a misunderstanding @xeleh has been crunching hours to make that fine 1.0 - and he got a lot of feedback about how some of his videos must be better - you know how frustrating that gets @frosted

I respect you both. No need to drown nothing

 

Ouch. My bad, I totally missed the uScript video and coincidentally there are 5 seconds of doubt/pause exactly at 9:40 in the GameFlow video I made for 2015. I will remove my post now, please accept my sincere apologies.

 

Deleted my response.

Misunderstanding happens.

 

The same thing happened to me, I thought the video was another. My sincerest apologies.

 

I kinda feel bad for the uScript guy now....

 

GameFlow extensibility API docs will be disclosed in v1.0 as promised.

 

I didn´t find anything about "animating values / variables". Is that possible, or is there any "build in action" for this ?

 

Well, there are many ways to animate (and there are also different kinds of "animations") - even without GameFlow The question is, what are you trying to accomplish? I work with GameFlow a lot, but to give you a real answer details are welcome. If it is not about GameFlow capabilities but a support question, I agree with @xeleh, that the GF forum is the place to be.

To clarify what you can do with GameFlow is for example sequence and trigger animations; if animating in your case means tweening - well, you'd be surprised how much you can do with minimal effort (look at the examples). You can also set the Animator state or Play an existing animation as a quick action. As animation can be created super simple or extremely complex (with animation events), there is a very powerful way to modify states by doing a Method Invoke action and selecting a GameObject with an Animator component. Try that

So, yes, there are buildin actions and one in particular is "very" overpowered. But you will find that most logic (with some exceptions of course) that aren't directly an action can be easily morphed into a GameFlow program - like you would do when programming in code. The difference would be that you can seamless tie them to state machines and don't have to repeat yourself.

 

Ok, i try the forums of GameFlow. I know you can animate variables / values via "animation" within unity itself. But this is too time consuming, in comparison if you have an build-in action which is like: "start value" , "end value" , "duration" and than store it into a global variable. Thats it ! This is how the workflow should be. I found out that there are tweeining options. But i can´t use them with variables (maybe i am wrong). Thanks samnarian. The last part i dind´t understand or better say, don´t know how to do it.

 

It will be often faster to get feedback from the developer and some more experienced GameFlowers. You'll like it

That sounds like a typical program you can setup in GameFlow quite easily; the question is not so much if you can do it, but how you will do it in GameFlow. You'll have to tell me what you want to animate. For example, do you want to move, rotate, color, tween or interpolate objects? Or do you want something more complex - and if so, what exactly?

I wonder what you mean with that variables. My guess would be properties, but you have to be a bit more specific.

All examples I've given are actions you can add. If you would search for "method" in the GF action menu, it will have Method Invoke. Select the GO that has for example an Animator component, and GameFlow will ask you which component you want to use - pick the Animator (it uses the recognisable icons and the type of component so that will be super easy). After this, you can select pretty much anything from the drop down for all the animator methods; again this is like the "I want to do very specific things" solutions.

The talk about matching state machines and animation is pretty much looking through the examples. As you are accustomed to PlayMaker style, it takes a moment to "switch" in the GameFlow mindset; but it will come - I promise. Once you get the hang of it, you'll won't be wondering about the how, but the when (more features).

The current state of GameFlow is 0.99b and according to the developer 1.0 should be around the corner. The GameFlow forum has a section with support, where you can submit feature requests open for discussions. After all, I am just an user like you.

No problem

 

Hm, just tried to explain that i simply want to animate a "value". If i go to GameFlow > Data > Variable i can generate a variable which contains a "float-value" f.e. Lets say i have a sidescrolling thing. It has to move with a constant speed (factor is a variable). Now if my player hits A, my sidescrolling thing slows-down. If my player hits B my sidescrolling thing accelerate. After 4sec it reaches its normal speed. This is why i need a animated variable build-in action.

 

All you would need is the Move action to achieve that and use the float variable you've created for the "animation" you describe. For the actual logic for interaction, you would only require a collision to interact with the variable which another action. That's it. You can extend the logic to the way how you please. Take a look at the GameFlow forum - it has tutorials that show how to do similar things with screenshots and videos.

So what you want is not only possible, it is quite straight forward to achieve with GameFlow.

 

I think what you are looking for is the Interpolate Value action. It works exactly as you need and even supports all the easing types available in GameFlow (Linear, Ease in Sine, etc.). You only need to remember that, because this is a time-based action that you want to execute asynchronously, you will have to put it in a separate Program that you can start on demand using the Execute Program action (notice the Wait toggle off), like this:



You will be glad to know that an improved version of the Interpolate Value action that can be started asynchronously directly (without the need of a separate Program) is already included in the next v1.0 update.

 

Yes, for the case of use exposed (sidescrolling) using the Move action would be definitely the most straight forward way.

 

Is there any proper benchmark on A/B performance comparisons between gameflow and doing the equivalent thing in C#? Do you know if its performance is better or worse than PandaBT? Is it GC friendly?

How well is it suited to handle a semi complex UI where not every screen can be prebuilt manually in the sceen and needs to be assembled semi-dynamically at runtime? Can I dynamically attach logic to objects at runtime? Would you say UI is well suited to be handled by gameflow? It's the area where I see the biggest appeal, because I hate dealing with UI and all time savings there I'll gladly take.

I have no strong opinions on visual scripting either way, but I always fear that using such 3rd party coding tools might backfire hard some day. E.g. how are the scripts saved? Are they files living somewhere, or is it all hidden away in the serialized data of objects? How likely is that to ever get broken by future Unity updates? How well does it work with GIT?

 

No benchmarks yet, but definitely on the roadmap. No comparisons with other products either. I always try to code in a GC friendly way -leaving it alone as long as possible- so I would say it is.

You can't attach logic at runtime, but your programs can be prepared to work like "controllers" that would control other objects (including dynamically generated ones) and make them behave as you need. The result would be the same.

Responding to all the UI questions. It depends on your requirements. With the currently available actions you can work with UI events, modify the properties of UI components and even instantiate UI components at runtime quite easily. For more advanced uses you would probably need specific actions that are still not available.

Regarding that, what I can tell you is that I am personally very interested in having a great support for UI because, like you, I hate dealing with UI. I really want automatically generated menus, easy button grids, etc... painless UI, you know. I have a focus already on the subject starting in v1.1 (to be released during the summer), so please stay tuned.

The scripts are living in a small DLL which is automatically included in your build. GameFlow stuff is saved in the scene and prefabs using Unity's own serializer which has some advantages and has proven to be robust enough considering that GameFlow started back in the days of the early Unity 4.x versions and the example scenes are still alive and kicking. In other words, while Unity knows how to upgrade their own scenes, your GameFlow logic is safe.

Control version with git is a different story, but you can still use it as long as you set the Asset Serialization mode to "Force Text" in Edit > Project Settings > Editor settings.

 

Good question. Problem is often that "performance" is measured in a way (like doing a LINQ vs vanilla to iterate over an octree), where you look at the footprint and processing time. Comparing the "performance" would really be opinionated. But I will be mean for a second; code always you so much control, you can never beat "code", as it allows you to uglify and hack. That might be a win for some, or even mandatory - yet this does not apply for 90% of the logic you have to design. However, I would love to see an actual face off with some scenario's to see the real difference. My bet is that the trade off will be minimal during runtime, unless it is hackified, fugly code versus GameFlow.

That depends on how dynamically your dynamic logic is. So far, I've faced zero to no problems. And yes, you can dynamically attach logic to objects at runtime. If there is a need to do certain things in code, GameFlow has the Get/Set Script Property and Method Invoke in place to tailor that. As far as I know, custom actions are going to be there soon, so extending the UI can be easy peasy.

Everyone hates UI. You can't be healthy if you don't. There are three UI solutions within Unity and it is driving everyone nuts.

GameFlow handles all interaction in for my UI and makes it easier to keep logic in places where I want them to remain. The only thing that I do is often pivot the RectTransforms and add components to Canvas (like Scaler and Group), but that is just my favorite workflow. Tweening works like a charm (and quite more fun actually).

Unity can have its bugs in weird places. Code gets broken with ease between migrations. Like all tools there will never be a carefree ride when it comes to Unity. You can't even depend Editor won't be broken (like the Animation Preview for assets). I assume that Unity does some form of QA and the actions in GameFlow live within that realm. However, the good thing is that during a migration, the API updater doesn't require you to restart Unity again or trigger a full re-import with GameFlow. Thus say all patches between 5.6 to 5.6.1p1. I won't lie; I've seen so far two bugs that are cosmetic in nature, but with the awareness 1.0 is around the corner, I wouldn't care less.

Using Git would be a bit different using GameFlow than with code - but only when S*** hits the fan. You are pretty much taking the same road only you are not watching every car passing by. In my perspective - but most people would disagree with it - it is a good thing to work with your logic to maintain snapshots over tiny commits. Even though tiny commits are beautiful in code, it would be counter effective when doing visual scripting. The Feature Branch Workflow practice would be a good fitting candidate for using with GameFlow. Work smarter, not harder.

You can create logic that is GC unfriendly in code as well in GameFlow. Most actions will be economically smart. If a beginner in C# would start using GameFlow, it would be like GameFlow being a senior developer who implements the logic for them. So, in that regard, it is GC friendly. Certain scenario's could certainly be further optimized, but most wouldn't give a heavy penalty. There are elements that perform better as GameFlow components than if they would be scripted without optimisation.

GameFlow actions live inside a DLL, which is efficient. You are practically already optimising 150+ actions using GameFlow you would otherwise have to implement in code. This is the "Don't Repeat Yourself" in a nutshell. The only way to counter that in code is to have the same actions in a DLL somewhere and start writing your own text based clone. Which can be a personal preference, but when your game grows, so does your codebase. GameFlow is a package you do not need to maintain

@Martin_H you should give it a spin. It is an awesome asset. If you can't mix it with your current project, it will be your best bet must-have tool for prototyping.

 

This looks interesting. Can you use GameFlow to control Mecanim animations, say I wanted to create a character controller? What about Tween nodes with ease-in and outs? Do you have documentation with all of your Actions so I can read more about them?

Thanks.

 

Thanks guys. All the information helped me a lot. @xeleh...this is exactly what i was searching for. Also glad that it will be updated in vers. 1.0. Great.

 

Thanks a lot for the detailed answers @xeleh & @samnarain, much appreciated! Sounds like I should give it a try some time . I'd probably focus on using it for UI at first, and see how well that works out for me. If I should decide to go back to pure code, UI seems a bit more self-contained than my other gamelogic things, and also I have little to none UI work done already that I'd be making redundant.

@xeleh: I'm sure you've heard that question a lot before, and are already a bit sick of it, but... since it's relying on a DLL, what do we do if let's say you get kidnapped by aliens and a Unity update breaks compatibility? Is the sourcecode for the DLL included just in case?

 

Yes you can, however the Mecanim specific actions are in 0.99b limited - but not cumbersome at all. I've tied GameFlow to player input, logical state machines that collaborate with Mecanim quite easily (especially if you are familiar with it).You can at this point use Method Invoke on the Animator and control Mecanim pretty easily from GameFlow logic. Could that be improved? Sure, and I would totally advocate for it. I've heard that the next release has some additional candy in it, including Mecanim specific actions.

Many actions that are revolving around motion have tweening logic in a dropdown Very easy.

The actions are incredibly self explanatory. Examples and documentation, are included with the asset. Generic documentation is located on the GameFlow website.

You can easily combine GameFlow with code. As I said before, it is one of those must-have tools. You just have to give it a fair chance. I was quite opinionated, but I got converted. Now I bug the developer a lot


In case you missed it, look at the OP first posting; if you like to save some pennies...

Nope. Also think that the reason for requesting source code is a little bit overrated. But those are my thoughts I rather have a DLL from a developer who takes great care in making things work than having source code that would only serve a false sense of security. I actually prefer the DLL

 

You've been lucky with your purchased assets then. Many asset authors will make the statement that their asset is one that is important to them and is a serious commitment. Most of them hold true to this statement too but some of them disappear for one reason or another.

For assets that only provide a minor service or that don't need to be present for the game to function it isn't too important but for everything else some of us are very hesitant to buy an asset without source. We've had the misfortune of being stuck with a broken asset we had to replace the functionality of.

 

What do you do? You PRAY... you pray for the souls of those reckless aliens which would probably die by my lightsaber... and then, once I return to Earth, we can get to an agreement about the source code if you really (really) want to have it because no, it is not included (and I have good reasons for that).

 

I remember Shader Forge getting fewer and fewer updates was the primary reason I had to switch away from it. Bugs were going pretty well unfixed and there was no way to dive in and fix them myself. It's the main reason I had to switch to Amplify Shader Editor for all my production stuff. SF just wasn't worth the effort.

 

My commitment is this: If I ever decide to discontinue the development of GameFlow for a reason different to an acquisition, I will disclose the source code.

That's ME!

 

Normally I dotPeek the DLL.

 

Wow sure are a lot of these visual scripting tools hitting the market, anyways i can only afford to purchase one. So between GF, Uscript, and Playmaker which one would be the better option???

 

GameFlow, no doubt. I think there are enough reasons here and in the Gameflow's forum.

 

If you can only afford to purchase one of them then uScript ($135 for the non-gimped edition) is likely outside of your budget since it is more expensive than GameFlow ($20) and PlayMaker ($65) combined. Currently PlayMaker is one of the more popular options because it's already integrated with many third party assets, but GameFlow is very affordable.

 

I think your money is best spend on GameFlow. You can thank me later

Thomas

 

@samnarain, @xeleh, @Thomas-Pasieka: Ok, I bought it and will check it out when I've got a bit more time on my hand to dive in. Thanks for all the in depth explanations. I'll bug you guys when I hit the first roadblock ^_^.

I wouldn't have the faintest clue what to do with it even if I had it. Ideally I'd want the source just to be open so that in case you suddenly vanish or die, someone more experienced than me can pick up the torch if necessary. That has absolutely nothing to do with you personally, I just don't feel comfortable "betting" on any one product that is made by only one person, to be maintained forever. For things that are very critical to the game I'm making (like the actual gameplay logic) I find that to be too risky. I'm not using many assetstore assets, but of those all are either something with source access or not too big a deal if they die. E.g. if Shaderforge becomes useless my shaders made with it will still work and if necessary I could still dig into the code manually and make changes if needed. Redoing all my UI work would suck, but it seems like a much more sane risk to me compared to making the bulk of my game in something I have no control over. I may have trust issues when it comes to software .

 

Dang, i'll buy Gf and uscript basic first to test the waters, that's $20 and $40 bucks a pop.

 

You can have source code and still a S***ty supported asset. The idea I have with Asset Store is to buy versus develop. I am not against source, but maybe my enterprise background doesn't mind to use a black box package as long as I can trust the source (who has been active in the Slack community and I find very trustworthy).

Perhaps. Usually when you purchase an asset for a specific Unity version, it should work. If not, you can contact the developer. Else, you can contact Unity. If you buy something from a douche funny software pirate like truebones person, you might get duped. But I think that most packages that have been a) promoted in the community (GameFlow was on Level 11), b) active in the community c) doing it for while... my bet is that @xeleh is on of the people who will not disappear (he does need a shower once in a while I guess).

Yup, and I think you should always be critical and aware of what you buy. If no source is a show stopper for you that is totally your decision (it is your money after all). My philosophy goes two ways; if I won't get support, I want the source. If I get support, I don't want source, I want a fix

ROFL

Ouch, so you are basically saying on a public forum you are researching for educational purposes the contents of a DLL and not breaking an EULA that could possibly mean a revocation of your Unity license, out of healthy curiosity with no intent to alter or change the code? And that the link is only a reference to a possibly method of doing so? (sorry, I just couldn't resist...)

Luckily @xeleh owns a lightsaber and I put my money on the fact he would make some arrangement about the disclosure of the source or a reliable maintainer if it comes to the point his Jedi batteries run out.

GameFlow duh. If you're budget was to get Playmaker, you even had money left to spend on other cool assets too.

I thank you now!

Awesome! Love to hear your experience with it. And you know how to find me on the Unitydev Slack, so you can bug me and others in #visual-scripting with questions too.

I also have another solution for visual scripting that supports 100% transpilation to C#. To be honest, I've never truly examined the generated code for changes and such. And the solution has no support Still it beats uScript and PlayMaker any day. However, the power of GameFlow lies in other areas. But I hope you will discover this through experience on your new journey...

 

Let me know how you feel between the two - love to hear experience and comparisons.

 

Having access to the source code is about being able to troubleshoot a potential problem yourself in the event that the author has either disappeared or is unable to assist with a problem in a timely fashion. Real life events can happen when you least expect them.

Yes. Having access to the source is an additional degree of documentation in the event that the official docs don't do a sufficient job of explaining what you're supposed to do. Easily understood code is well written code.

One of my most recent examples would be Rewired. It's a fantastic asset but the info necessary to use it in an advanced way was simply all over the place. It ended up being faster to peek into the DLL than it would have been to find the info in the documentation.

For the record obfuscation doesn't really slow me down in this task because it doesn't obfuscated the parts that I need.

 

Sure thing

 

Will do! Though I have to find a new way to use slack first, since it decided my browser is no longer cool enough to work in it. I'm using waterfox and keeping it up to date, so I don't quite understand why it stopped working. Might have to try the desktop app after all or get an extra browser for slack.

 

Would love to hear what you guys think if you have purchased GameFlow! Check my GameFlow Diary if you haven't already if you're getting started: http://evasiongames.com/forum/viewtopic.php?f=7&t=130

Thomas

 

I only very briefly played around with it. It looks like a great entry for Unity beginners because opposed to coding while learning the API, you here have your lists of things to choose from, that largely have the same names as in the API. You can more easily discover what is even possible. And since it's not the noodle-network kind of visual scripting, but instead uses logically structured blocks, I'd say this looks like a decent way for non-coders to learn coding in a fun and accessible way. The switch to C# should be easy after getting proficient Gameflow imho.

Since I already know my way around the commonly used parts of the api, can write code from scratch and have some experience doing so, of course I'm way slower getting things done with a system I'm not used to. That's to be expected. Whether that's something I could catch up on with practice I can't say, but I doubt it - at least for the common tasks. I'm not sure about UI, since I'm very inexperienced still working with UGUI from code. So this is something where I still have hope of getting a boost in productivity from.

I like some of the convenience functions I've seen, like getting a random point in a collider. But I'm missing the smoothDamp functions from the Vector3 and Mathf classes.

What I found quite frustrating was trying to do something like 3 nested for-loops that in the inner loop instantiate some object at a coordinate calculated from the variables being iterated. That's literally 1 line of code if you don't care about it beeing a rather long line, but it seemed to require a huge number of Gameflow blocks to replicate.
If you feel I must have done something wrong (which is quite possible), I'd be interested to see the most straight forward implementation of something like that.

Sometimes I just wanna test something with a quick throwaway script, and for that I could see gameflow being useful too. I feel like this kind of approach is generally better suited to "one off" scripts, than complex 500+ lines of code classes that bundle the functionality of a whole group of objects. E.g. my weapon class has over 600 lines including comments and blanks, with over a dozen parameters exposed in the inspector, I don't think I want to ever replicate something like that with any visual scripting tool. I'm sure it's possible though if you set your mind to it.

When it comes to "architecture", I have no clue what Gameflow can or can't do. Like, can I make singletons with it that can get called/accessed by other objects? Can I access my coded singletons from Gameflow scripts? I'd be impressed if it was actually possible to mirror the architecture I'm using, but I wouldn't expect it from a visual scripting tool. And I'm certainly not starting to try and convert my codebase into Gameflow scripts now, that would be insane and was never my intention.

My testbed for Gameflow currently is a newly started prototype for a possible future project. I haven't tried using it on UI in my main project yet (which is my primary goal), because I haven't conceptually thought the UI part through yet.

 

I assume you are currently are on 0.99b. The good thing is that you are already trying to do "beyond the beginner", which is good for GameFlow to grow. The power in 1.0 is the ability to create custom actions. In your case, being able to code C#, would mean that the one line of code could be replicated easily into one GameFlow action. GameFlow 1.0 is around the corner. Really, it is very near. I think a feature request for that should definitely be part of the actions that are part of the "standard" library of GameFlow.

It is a perfect tool for Rapid Prototyping.

I agree; but this is where the synergy should be. There are things that are best suited in a code library. But such classes and methods are often reused, consumed and build on by other light-weight objects. GameFlow allows you do that. Even though many would prefer a "pure play", I personally prefer a hybrid approach.

It is a good start to begin with. I love to see you share the things you are missing; especially in a form of features with objectives you like to accomplish.

When I first played with GameFlow, I tortured the developer with countless questions; things I would prefer to work like I would code. But it requires a new way of thinking. I could tell a lot about how I am working with GameFlow in this matter, but I think it would only be more confusing as my workflow is just batshit crazy.

 

The author just posted some news on the upcoming big 1.0 version which you might want to read if you're interested!

http://evasiongames.com/forum/viewtopic.php?f=4&t=177

I am very much looking forward to it (already beta testing 1.0 currently).

 

Thx for Info ! Will take a look

 

No actually it's the laws of math. Creating visual tools that can even come close to what a good developer can create is probably more like 20 years away. For many of the same reasons why Siri can only answer the most basic of questions. It's a very hard problem and economics has little to do with it. We aren't even close really to algorithms that can solve general problems and think in abstractions like a human can.

A better approach generally for games, is have a good developer create a well abstracted architecture, like say an entity component system, and then wrap that in good visual tooling. It goes back to it's easy to create tools for narrowly defined problems. That is where they shine. But to use it in a general way, to create most of your game logic with them, will break down quickly.

 

That is correct, but we are not talking about that here. Visual scripting is not about replacing programmers, it is about enabling a different -yet non exclusive- way of programming. A way which can be good enough for people not wanting to mess with coding, which is proven to be really good for quick prototyping and which eventually will be proven to be also good enough for production. In other words, visual scripting already allows for easier, shorter and cheaper development cycles. Economics has a lot to do with those.

That is exactly GameFlow: a collection of combinable abstraction layers wrapped into a very friendly and extensible visual tool that will integrate quite well with your own or 3rd party scripts. Some developers refer to GameFlow as "a swiss army knife". I hope some day you give it a try, your feedback will be very welcome.

 

Hi!
How is the beta testing going?

 

Hi @_xeleh_ and @Thomas-Pasieka
I tried to contact you on Facebook and forum but i didn't get any reply, and forum down frequently. I have many visual scripting but Gameflow is my favorite and i have using it for many projects. And now, i have a brand new project, i am afraid using gameflow because there is no update for last year. So please tell me Xeleh if you're still active supporting gameflow and i will using it with no worries...

Thank you, your asset very good, need to spread the word that gameflow is another powerfull tools