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

Hey everybody,

Over the past years I have had my fair share of run-ins with plugins claiming to be the ultimate solution and that you don't need to know how to program in order to create something cool! Well many years later and some C# lessons later I can tell you that those promises are usually not quite true. They are nice slogans and designed to lure in the unaware. I have tried PlayMaker, uScript and a few others currently available on the Asset Store. All of them were rather disappointing in the end for various reasons.

Surely, this only reflects my experience and other people may have had a great experience with the mentioned above but today I want to point you to a visual scripting solution called "GameFlow". What I like about GameFlow is the fact that there is no special window in which you have to wire up your logic. In fact, it almost feels like a part of Unity as all logic happens in the Inspector. It's a matter of adding components. The Logic reads from top to bottom (with linking). This makes it pretty straight forward and easy to follow. For the first time in a long time I feel like this extension can actually help me do things I wasn't able to do previously (or at least not without a lot of help from others). As mentioned before, it does help a great deal to have at least a basic understanding of how C# in Unity works.

In any case, if you are curious please check out GameFlow currently available on the Asset Store at a introductory price of $20. Price will go up soon with release of 1.0

Asset Store Link to GameFlow: http://u3d.as/6r4

Be aware of the fact that it's currently still considered "Beta". There are examples delivered within the package to help you get started.

I also created some mini tutorials if you care to check them out you can find them all in one thread on the GameFlow forum: http://evasiongames.com/forum/viewtopic.php?f=7&t=130


Thomas

 

Here is the result of one of my quick tutorials. Was done rather quickly. Door mechanic only works if two keys (green spheres are collected).

 

Really looks like you've just moved the coding syntax from scripts to the inspector.

What's the advantage to doing this over straight scripting?

Really seems like the worst of both worlds to me.

 

Got to agree. This is Visual Scripting that's even somehow less VS-friendly than Code Blocks.

 

I also think this thread belongs in Assets and Asset Store, not in General Discussion. Surprising it was placed here by a moderator.

 

Reminds me of Blockly for web programming. https://developers.google.com/blockly/ . Or MIT's gameblox. Just with a Unity inspector UI instead of fully drag drop. Still pretty low level to all of the underneath API.

Obviously it isn't visual scripting, more like lego building blocks in the inspector, but it's probably a compromise between the regular coding and visual scripting. Being built in the style of Unity's inspector is a plus for anyone that's used to that window.

On any of these solutions though I think it comes down to the individual person's brain (whether it can handle large amounts of text, prefers lego puzzle pieces, or prefers node graphs). Whichever way your individual brain prefers should dictate what you use. Obviously each translation will cost some efficiency but most games can afford a little bit lost.

 

The creative director here at Simian loves it. He's had more results, faster with GF than using something more complicated.

Seems Unity's component based architecture naturally lends itself well to stacked logic like in Gameflow.
Pretty cheap too.

It is easier than programming because it does much more than just if/then

I think its OK, I've moved asset based discussions to general before. Sometimes it seems like spam for asset store forum (assets there should be posted by the authors otherwise it would run amok).

 

Well I was going to reply to the first 3 responses but then again, that would be a waste of time.

@greggtwep16 Well I still consider it visual scripting. It just doesn't have all the wires etc. In fact, I prefer it that way as it's less of a mess. Node based visual scripting tools such as PlayMaker or uScript really get hard to read/follow quickly. In GameFlow the logic is read from top to bottom (usually) and to me that makes it much easier to read and follow. Even an outsider who looks at your "block" can understand what you are trying to do. Sure as with most visual scripting solutions there may be some hit on performance but in most cases it's acceptable.

Thomas

PS: If you are responding to this thread make sure you do it in a civil manner. You can state your case but back it up with facts/past experience.

 

To me it looks really good. I've tried the graph-based visual script tools and they all claim "without any programming" and yet you end up basically writing programs just with a different visual presentation... having to create all the variables and do little calculations one at a time and basically not really saving a whole heck of a lot of time, plus all the horrible visual mess that they present. It's really hard to follow the program flow just looking at the thing, and it quickly becomes very complicated. Reminds me also of the animation state machines which are just a horribly complicated spaghetti mess.

What I want in a higher-level "programming" tool is basically to get much more "output" from much less "input". I don't want to have to be spending time assembling pretty graphs and dragging wires around, or even spending much time hunting through menus for the right action or whatever. This kind of tool needs really efficient usability. And it needs to automate a lot of stuff, not just for the sake of getting a lot of syntax-sensitive programming out of the way, or avoiding having to hunt through unity or C# documentation for the right commands to use etc (which is an inherent pain), but to just get rid of everything I don't "need" to be doing other than the core elements - the parts that really matter, the parts that actually influence changes. And that's where the user interface comes in to make it quick and easy to adjust those settings without having to create all the supporting structure and stuff.

I'm basically saying I like the design of GameFlow (probably will buy it)... mainly because it's just a simple user interface, somewhat "procedural" in its programming style instead of all the complexity of the whole object-oriented paradigm etc, it appears to give quick access to adjusting what matters without the gubbins of "managing" the interface, and I don't have to be so brain-dead about what the heck the visual representation means in terms of what happens. Just a nice simple flow of logic, little machines that just do little jobs and you can join them together. Not too low level, and doing plenty of "work" so that I don't have to. Thank you very much.

I actually started to design a system like this recently which was going to be geared towards 2D only which was going to have little machine parts you could just quickly choose and join together with simple procedural programming structure, to just get basic stuff done like moving objects around and setting up basic AI and stuff. It looks like this system is not far off from that. Good job. Ultimately I don't want a tool that just "maps" all the basic unity functions into a user interface where I end up having to spend even more time choosing basic scripting commands from some dropdown menu, I want it to function mostly at a higher level than that, make some assumptions for me ie be a bit more specific to a specific use case so that it can offer more relevant automation, and then give me some way to get into the "advanced" breakdown of lower-level stuff if I want it.

It's all about saving time and making it all easier and quicker to develop, without getting bogged down in all the pain of programming. Who wants to program really, anyway? Programming is one of the most offputting parts of making a game, drudging through documentation and hunting down bugs and trying not to forget a single character that breaks the program or trying to figure out how to code it etc. Some people love it, ok, but it just takes so much time and effort. I want to see results and I want to see them much sooner! So I'll check this out, it looks good to me.

 

@greggtwep16 GameFlow fully supports drag and drop of blocks and fields, but the really good part is that you can also use the keyboard to compose programs very quickly. You have to see it in action; the usability is strong with this one

Allow me also to remark that GameFlow is indeed a visual scripting (or programming) tool because VS is not only about boxes and arrows. That is only a popular trend but there are other paradigms that fall in the VS category.

 

That's pretty much on point right there! Couldn't have said it any better. I have done already much more by myself with GameFlow than I previously had with PM or uScript or whatever other solution out there. I'd love to hear your thoughts if you decide to buy it.

Thomas

 

I think it actually looks quite interesting because it seems to better fit in with Unity dev in general and it will likely be much more intuitive and therefore productive for artists and others who don't want to code.

Overall great job in approaching the "problem" from a different angle and producing something unique!

 

I am an artist myself. Over the past years I dug into C# for the simple fact that I wanted to have at least a basic understanding of how things work. This is of great help if you're looking into visual programming. As stated before I am able to now quickly test out some ideas without having to waste a lot of time wading through Unity's Scripting API.

 

I've heard from people who never coded in their life that they managed to easily learn the basics of unity's api when they first started coding.
I'd advise you to take a few days to learn it as it will greatly boost your productivity.

 

My immediate thought upon seeing it was that it reminded me of Unity's Event System. You could almost treat that as a visual language if you made the right classes for it.

I've generally seen a mixed bag in the Getting Started section. Some people haven't had a problem memorizing the API and some people are struggling to do so.

Regardless in my opinion it's never going to be a matter of a few days for anything more than the basics.

 

I tried uscript once, didn't really like it. This looks slightly better, less clutter UI. But once I got snippets working with sublime nothing is faster.

 

If you paid attention to my first post you would know that I have some basic C# knowledge. Without it, even Visual Scripting would be difficult.

 

TL;DR
I've told the developer many times his marketing sucks. If you do try it, check out the examples. There are certain features that you might find very useful. The party keeps on going and going. Really. In my opinion it belongs to the must-have assets.

EDIT: If you already have the tools that satisfy your needs and allows you to achieve the things you want to, you will be opinionated about it. Tools solve problems. You'll probably want a better hammer than a screwdriver. If your hammer is C#, don't be too picky about screwdrivers not being efficient to bash smurfs nails into plywood. If your hammer is PlayMaker, UScript or BlockySomething, you might want to look at a better hammer: GameFlow.

None. But I feel happier while working and am creating logic that I orchestrate and compose. I will be honest - there are features that can be improved, but I've seen the potential - I do not have a moment of doubt it will work out. Over the half of my current logic has been ported to GameFlow. Have done this with minimal effort. It is intuitive and its examples are just amazing. I can focus on game logic, which I admit are just plain better now after the port.

Oh wait. I've one for you. Can you comment out something in your typical coded MonoBehaviour, while being in Play Mode and uncomment something else and see that change happen? There are going to be three kind of answers on this:

1. Dunno. (or bla bla bla bla bla bla bla unicorns, flying horses, reptoids)
2. No.
3. Yes, given your entire game state is serializable, and static values are all lazy loaded, maybe at the next update call. Just takes one other piece of logic though to break everything.

Proof of Concept:

Code (csharp):

1.  
2. using System.Collections;
3. using System.Collections.Generic;
4. using UnityEngine;
5.  
6. public class NewBehaviourScript : MonoBehaviour {
7.  
8.     // Use this for initialization
9.     void Start () {
10.  
11.     }
12.  
13.     // Update is called once per frame
14.     void Update () {
15.        Debug.Log("uncomment me while being in Play Mode");
16.     }
17. }
18.  

You can toggle logic on and off in GameFlow during Play Mode. You can't add new actions, but that is not the point. Very useful for debugging or comparing mechanics and see how they react.

Love those. If you could only make some about Params, Macro's and GameFabs.

I think that the term "visual scripting" is fitting, even though most people associate it with graphs. Some would say it belongs in visual programming as you are applying elements using point and click versus text-based programming. Tomato, tomato. I've not tried Code Blocks, so I've no opinion about it. Don't need to try it either - Gameflow satisfies the needs already.

I agree that it could easily fit in Assets and Asset Store. I agree it's also OK, and I don't mind it being posted here.

Zzz.

In my opinion, you are still programming - only using visual elements that you otherwise would have to "code". And I agree, it does a whole lot more than if-else. I still get surprised how much batteries are included.

Right there is the "confusion" - "without any programming" is an illusion. However, in context they mean "without programming in text". So, you are completely right. And they are not wrong.

But, I am going to be mean:



GameFlow is not any different. You are programming, only it will be intuitive and using visual elements instead of writing lines. You are creating logic that controls and manipulates data that gets interpreted. In that matter, GameFlow can be considered a "language".



However, it does its magic that is easy to adopt, easy to refactor and extend and which just fits with the Unity workflow: you add components where you tie your actions to.

I use a mix of tools to create my logic. I mix code, graphs and GameFlow. Together that's a kaioken times ten. It is not so much about if you do "any programming", it is about doing what you have in mind and make that work. For some cases that will be in pure code. Other cases that will a graph. For doing rapid prototyping and applying KISS/DRY - the intuitive style of programming - a visual scriptgramming (tomato, tomato) is priceless. No matter what you will look for, there will always be a learning curve. That having said, the one for GameFlow is pretty much as easy when learning Roll-a-Ball (which is, for the record - very very easy).

That is exactly why I am using GameFlow. And that is exactly what it will do for you. Once you get the hang of the basics (which is going to be a lot faster when you see UnityScript or C# for the first time, and even faster if you actually have coding experience in Unity), you'll see the great care the developer has taken to make things intuitive.

You should. It's cheap and one of the must-haves.

I love coding. I just prefer GameFlow to make things work for the mechanics that are often compact but tiny and customised.

I will allow it. And couldn't say it better. Well I already said it - that counts for something.

It is intuitive and also for people who do love to code. You don't have to hate code to love GameFlow.

I would add a few years the rest of their lives to those few days. Learning to code is never a bad skill and the music never stops.

Yes, because you have invested in learning programming from the ground up. You also know that scripts will grow fast or in abundance, which will clutter your Project view. Some logic is just better done with code. However, most logic is small and repetitive. This is an another area where GameFlow shines. You should give it a try.

 

I own GameFlow, and i like it very much from the early development. Also own PlayMaker. They both can interact very well together (throgh invoke f.e and so on).For me, the biggest win for GF, is how easy i can drag and drop many functions i need. Really simple. I´ve managed it without any tutorial, which means its well designed. On the other hand, PM for me is also a nice to have tool (it has really many usefull add-ons). But i have to say, if my project geting big, its a bit difficult to get the overview. To many wires, so called spaghetti. Have to take care about complexity.

Some wishes for GF would be: more functions, more add-ons. And one small easy feature request from my side is:
dockable "add Actions"-window. So i have my overview. And dockable windows of "tools", "data" & "programs". I am lazy and don´t like to click always on "add components" > "GameFlow" > "etc". I know i can type in a word into the searchfield. This works only if you know all these main functions. Which i definetly don´t know, because i am lazy. So i am curious when the 1.0 version will be released and what new features it will has inside

 

Have to admit I wasn't aware (or I had totally just forgotten which wouldn't be surprising) you could change code at runtime and immediately see the results of it without having to stop the game and restart it. Going to experiment with this concept a bit more but it's totally going in my toolbag.

You're likely also happy in the knowledge that once we C# fans have taken over enough to justify the removal of UnityScript you'll have a solution ready to go.

Edit: Yay grammar fail.

 

I can confirm that GameFlow was not inspired by Unity's Event System (introduced in 4.6, late 2014) because the design of GameFlow started earlier, in late 2012. Anyway they are not even close. GameFlow has adjustable listening ranges for events, easy flow control, variables and a long etcetera. Not to mention it plays in a league of its own in terms of usability. You simply won't get all that with a bunch of classes.

 

That I'll buy. In fact that could be a very powerful use case for this type of language.

 

No one really cares who inspired who. It's not uncommon for good ideas to come up multiple times in different places.

There certianly are similarities between the two systems. Both run on the idea of coding in the inspector instead of coding in text. Which the more I think about it, the more potential it seems to have.

I mean if it worked for Path of Exile, it might work for me too.

 

Like I was suggesting they only reminded me of Unity's Event System. Primarily due to the nature of existing in the Inspector.

That's why I said "almost". Keep in mind too that not every visual scripting language has the same range of capabilities any more than every coding language has the same range of capabilities. I have seen some very primitive attempts in the early days that wouldn't be too far from the Event System.

 

TL;DR
Tomato, tomato. I think that GameFlow is a solution born for the pragmatic desire to do things quickly, without moving out of the editor but keep focus on the thing you are working on. Just because things look similar and behave similar means they are similar. Take puppies and kittens. Both cute, but kittens become cats and cats rule the world.

I actually made a UnityScript transpiler (100% C# code and not those poor regexes as I've used for the Atom package) for Unity, and created a superset that allows delegates and such - it just matches my style of thinking. So I'll still remain a (probably the only) fan of UnityScript. I have a great respect for Bamboo for designing it. It just works very well as a prototype language. UnityScript is going to die. Asset Store vendors will not be able to publish with UnityScript/Boo for .2017. I find it sad, as I find it a well designed language that offers a flavour to the Unity ecosystem. But, I know when that day comes, the whole Slack channel will give their condolences to me Never the less, GameFlow does not replace UnityScript in a sense of obsoletion. It replaces code entirely - C# or UnityScript - for me.

In case you weren't aware, GameFlow has zero compilation time. Yes, I said it. Check your build times too. That is going to be fun. The performance penalty is for small, composite components minimal, the biggest eaters are skinned meshes with animation controllers anyway.

PlayMaker is a mature product, GameFlow is emerging. Eventually, PlayMaker will become a mess for a mature project, it is an all-in-one wonder. It shaves off a lot of time during prototyping or a first title, but you can not really move forward. In that spirit, GameFlow offers that visual scriptgramming for the balanced and experienced Unity developer. It is way easier to replace GameFlow logic with code if a segment requires performance or very custom logic - this will not be the case with PlayMaker. You will have to go back to the drawing table when you discover penalties at runtime.

Just to give you kudo's, I think it is a very good mentality not to exclude one solution for another, but you pick the tools that suit your needs.

Couldn't say it better myself!

I thought you would appreciate a solid argument
I've actually discovered a lot things that are possible with GameFlow that would be hell when doing in code. One of the very powerful features in GameFlow are Macro's. You can add hotkeys to logic to perform tasks in the Editor.

Now, this sounds "oh, I can do this in a Script easily". For one, you would have to do a lot of research grinding to make simple automated tasks. Like fixing your 200+ models and replace their materials. I've spend too much time on it, only to get frustrated and annoyed while all I wanted to achieve was changing a simple shader property over a set of things that would prevent me to click at least 1200 times, because Unity's importer decided change something really simple in the importer for the better - but didn't really rolled with my current assets. Script required nasty hacks and actually made Unity either crash or reimport. Both very, very scary and time consuming.

I did this with GameFlow in 3 minutes. Didn't need to check the Scripting Reference once (GameFlow functions have a one line description visible when you click on their title). Gameflow has already saved me hours of work and probably days in a tight deadline situation. No crashes, no reimports.

Don't get me wrong, sometimes you will need very specific and special editor-only scripts, but my point is that most times, you don't. Most times you just want to automated very simple and time consuming tasks, or change a bulk of assets.

You don't have to exchange the one for another. You can still write code where it is in your comfort zone. You'll just find that most of the work lies in those tiny pieces of logic, that could be done easy. Like when you add RectTransforms to Canvas objects (which actually can be done... quite easily with GameFlow too), you most likely click the 2D button and start creating an hierarchy (as they render based on their position as their child index). The more GameFlow extends, the less I am working with Atom.

Tomato, tomato. I think that GameFlow is a solution born for the pragmatic desire to do things quickly, without moving out of the editor but keep focus on the thing you are working on. Just because things look similar and behave similar means they are similar. Take puppies and kittens. Both cute, but kittens become cats and cats rule the world.

 

@samnarain I get what you're saying but once you've progressed past beginner it becomes more cumbersome than useful. One of my issues was bloat, again testing uscript here so may not be relevant, the other was it exposes too many functions.

I remember the guy in the youtube tutorial wanted to add a translate, typed it in, and it came up with a bajillion drop downs, in the end he still had to refer to the manual to pick the one he wanted.

[Skip to 9:40] LOL

My second issue is if you wanted to 'export' all that logic into code to make it more readable. If it did that, it would probably add a bunch of bloat which would take ages to strip down.

My third issue is, when you're coding you generally figure something out then reuse that bit of code time and time again. With snippets you can just set it up on keypress, whereas with visual scripts you have to know exactly the drop down you're searching for.

Fourth, it comes undone when you want to say do something like shoot a raycast and pin a texture to a wall with it facing on the normal. I mean, you probably could do it with visual scripting but it look hideous, and difficult to maintain.

Fifth, at some point you have to feed the node a 'hand written script' this might be a complex if else logic, where code trumps all.

Oh yeah and it is slow. Did I also mention it is slow, slowing the editor down. Mind you I think even monodevelop is slow as hence why I swapped to sublime text.

So is it for noobs who want to prototype quickly, yeah, but if you have snippets you could also prototype fast and it will be more readable.

 

You really shouldn't talk about yourself in the third person ya know

 

TL;DR
Prototyping is always, alway and always a crucial part of the game development process. Just because something doesn't work for you personally, means it is wrong. Don't try to make this a visual scriptgramming versus code discussion (it isn't, it is about visual scriptgramming, if you have tried GameFlow for that purpose and if so, what are your experiences).

Let me remind you a) you were a "noob" once b) that I do not consider myself a "noob" and find it quite useful. I don't mind you prefer code versus visual scripting. I do mind your words - probably without intention - that come across as condescending. Jesus tells me to be forgiving, so I'll forgive you.

Prototyping is always, alway and always a crucial part of the game development process. Beginner or expert, you will need to prototype. In fact, you would even prototype without being aware you are prototyping. It is the starting point before anything else happens. If you do not want to prototype quickly, you are doing it wrong - no matter if you do that in code or visual scriptgramming. In the case of code, you would certainly use snippets or a collection of mockups. No sane person would disagree. But we are not talking about code. We are talking about visual scriptgramming. Comparing apples with oranges is just as futile.

Or - you just prefer code versus visual scriptgramming. Like some people prefer visual scriptgramming versus code.

1. Not the case in GameFlow.
2. Not about GameFlow - keep on topic. Unless you are comparing them, and if you were, you would've concluded my previous point.

The point of visual scriptgramming is not about exporting / generating "editable" code. It would defy its purpose and it would come at a heavy cost - compile time. If I needed that amount of control, well, I would create a script.

Your thought process is almost like "If I walk, I can control my movement with total precision and accelerate exactly when I want and how much I want, I can catch every detail while I walk and control every possible scenario. With some effort, I can commute cheaply from A to B. It is good for my health and I find walking relaxing."

There is nothing wrong with that. However, then this happens...

"While you are walking you see people taking the bus. Those noobs are taking the bus. What a stupidity. They don't control where they can go or stop just where ever they want. Those noobs must be lazy or not care how healthy walking is. Why are those noobs spending money to ride the bus, that distance is only 20 minutes walking. What if they are hungry on their way to their destination. If they want to get out of the bus, they have to travel 5 minutes back walking anyway, so inefficient."

Even though you could be making valid points, other things happen.

It starts to rain. (Unity bugs, obsolete api, typo, badly implemented coroutines)
Traveling from A to B by bus takes 1 minute versus walking 20 minutes. (winning 190 minutes commuting back and forth five days - a happy wife/husband/both and no kids are being neglected)
Everyone taking the bus has had breakfast (because they slept well and didn't crunch the night before to fix 40 scripts that had bugs, obsolete api, typos and badly implemented coroutines)
It starts to rain for three consecutive patches days (Unity bugs, obsolete api, typo, badly implemented coroutines)
The people taking the bus have a bus card (the cost is minimal and the return of investment is time).

Are the people on the bus stupid, noobs or lazy? Or did they make a different choice based on their personal needs? If you can't answer that, let me help you: no, they are not stupid, noobish or lazy. In fact, like during the summer, some might choose to walk. Some might stop and get that delicious donut.

Just because something doesn't work for you personally, means it is wrong.

Again, you have assumptions. GameFlow has GameFabs. They are like visual scriptgramming pieces you can reuse. Working with DRY (Don't Repeat Yourself) and KISS (Keep It Simple, Savvy) apply in GameFlow. And with a Macro, you can set them up on keypress. It looks to me, you have not tried GameFlow at all. I might be wrong, though.

You mean like a sticky decal? Oh boy. @Thomas-Pasieka will probably disagree with that on so many levels. I can't see how something that simple (at least in GameFlow) would be hideous and difficult to maintain. In my opinion that is a typical use case I would use GameFlow for - as I would prefer to use a variety of settings for a range of weapons, have different visual aids (GameFlow has actions that include editor gizmos), create a GameFab and use Params to create a piece of logic that just works perfect as an encapsulated object. But then again, who cares about patterns and best practices! I would find it hideous and difficult to maintain when I would do this in code; especially when I decide later (it is called refactoring, in case you didn't knew) to add state machines to that piece of logic (more scripts....like, one for every state - unless you nest them into one - oh hmm losing readability here maybe...), have a debug version that is tuned for well... debugging (no, I am wrong - a shipload of #if UNITY_EDITOR's everywhere, that will be so beautiful).

You are trying to make this a visual scriptgramming versus code discussion (it isn't, it is about visual scriptgramming, if you have tried GameFlow for that purpose and if so, what are your experiences) Have you tried that abomination really cool social media Reddit? They have all these fantastic discussions where they keep repeating the same old X versus Y, where both are random. People usually "trump" there, especially about code. Back to the point - the fact that you can feed it "hand written script" makes the visual scriptgramming solution versatile and agile to integrate with existing codebase. I would never use a package that does not include that very important feature. GameFlow has it, and it is elegantly done.

I probably don't have the same issues as you. But than again I've often 10K+ of game objects in a scene, invested in a box with a lot of memory and probably do not have your amazing coding skills. But that was long before GameFlow. I have not experienced a difference in performance that is noticeable when using GameFlow for visual scriptgramming. Again, I doubt if you have used GameFlow at all.

 

How easy is this system to extend with my own actions? That could make it quite a powerful tool.

 

I am going to take a big leap of assuming that you mean "can I add my own action like DoBoredMormonThings plug that in". I think I've seen such action templates on the roadmap planned for version 1.3, but the developer @xeleh can answer if that's going to be soon and how that might get implemented.

Personally, I don't think that should be a #1 priority, especially as actions are tiny pieces of logic, and 95% of what you want to achieve can be done with the existing actions (150+) or integrate with finer control. I do see the added-value in it, though.

I am going to shock probably some GameFlow users, but I think it is worth it to show you how crazy you can go with GameFlow. So, for the first time ever - a screenshot of my layout when I design logic with GameFlow. To achieve what you desire, there are roughly 10 ways to do that, most common are using a GameFab, Programs, Commands that interact with Programs and varieties within these kinds. I made this example for you in a minute, where I set the target frame rate to 60 once the program started, that does a redundant check if the Game has started and create a screenshot, and converts a list of object (five colors) into a JSON string with a pretty output. I can either reference these by the Program Id, or by sending a command and selecting its human friendly method that I predefined as "bla".

GameFlow allows me to create logic that would require to type more, or remember exact snippets to achieve the same, it looks elegant you don't have to understand C#, UnityScript or Boo to understand what this Program does. You can replicate it this easy, extend it and make a better piece of logic. Did I mention zero compile time? Or that there I can create logic and profile its impact during Play Mode? (remember, I can toggle actions individually to be active or not...)

 

Exactly the reason why I had to clarify that GameFlow is not related to the built-in Event System, which we all know is quite limited... If the built-in Event System is a bike, then GameFlow is a Ferrari.

 

Quite easy if you have basic C# skills. In the next update (coming really soon) I am disclosing the documentation of the GameFlow API, which until now had been for internal use only. Adding a new action is a matter of extending a class, defining the action properties and overriding a method. Immediate and time-based actions are supported.

Oh, and one more thing...

GameFlow will generate the base code for you

 

Nice.

That's where I see the strengths of this type of system. Not in replicating low level code. But in allowing designers to work on high level code, while leaving programmers in peace to work at the low level.

 

Exactly. If you are a C# programmer you have two options:

A) You invest your time in a nonsense crusade against visual scripting tools with all those classic (and mostly no longer valid) arguments like performance, control, reusability, etc.

B) You understand that visual scripting is not a menace but a new great opportunity for C# coders because a whole user base is now in need for new high-level actions and new integrations with other 3rd party plugins.

If you choose A you will eventually lose the war because the only reason why we are still discussing is because this is a newborn generation of visual scripting tools. In 5 years there will be no discussion at all. Not my prediction, just the laws of economics.

If you choose B, welcome to the future.

 

I don't deny that the UX for gameflow is a S*** tonne better than uscript, but still some points remain.

1. You CAN prototype fast without visual scripting nodebased / blocks with your own snippets.
2. Maintaining logic in code is way easier/faster than vast code blocks or nodes, assuming you know how to code.

^^
Expanding on the point above, this is one primary reason why I never really jumped ship to unreal engine. Because c++ is so hard, or the examples are far and few between, I realised I would have to do everything in their visual scripting tool - and that irked me.

I mean at some point you want to make an entire game right? So the actions that you have prototyped in gameflow needs to converted to code, because well, I can't imagine a full game being made with just visual scripting, well anything non trivial?

What I'm saying is if you have the tools, in my case sublime snippets, to do that, why not use this. Rather than saying to me, it is not fast prototyping. Actually, I'm unsure of what point you're trying to make because we are not allowed to compare visual scripting with coding.

Using snippets is sweet! And for me, way faster quicker and easier and useful, in the long run.

BTW great use of story telling

Have I used gameflow ? No, have I seen a video on it, yes.

Has it changed my mind on my workflow, no.

See above points.

 

Additionally, you keep mentioning we are NOT comparing visual scripting with code. It is like comparing apples with oranges.

This is a very odd point. As gameflow creates game logic and so does code. What does your point even mean?

 

TL;DR
When you program, you are creating logic. So when a "coder", a "designer", a "project manager", or the "ceo" is creating logic - whether through code or GameFlow, they are programming. End of story. The "code trumps all" is just a sad old mantra.

The "next" update - is that going to be 1.0 or the first one after it?

That "replicating low level code" makes my eyes roll around faster than the Nested Prefabs promises. GameFlow can be considered a high level language. It is okay, some people need more time to let go of traditional approaches. That "designers" and "coders" fairy tale has always been a dumb separation anyway. When you "design" something is using an other skill than when you "program" (through code or visual scriptgramming). When you program, you are creating logic. So when a "coder", a "designer", a "project manager", or the "ceo" is creating logic - whether through code or GameFlow, they are programming. End of story. You can disagree with me on this, but that would only embarrass yourself.

My bet it will be less. Tools like these are versatile - they are not just for designers and C# is not just for coders. When I work on a project, I pick the best tool for the job. It is the reason why I have picked Unity. The "code trumps all" is just a sad old mantra. I have ported low level code, that would be otherwise more time consuming to maintain. I treat my development for logic with GameFlow as similar as I would do for C#, UnityScript and ShaderLab.

In case you didn't knew, testing in Unity is pretty poor when it comes to behavior testing - in fact it would require triple the amount of work. In GameFlow I can unit test individual GameObject's logic and test its behavior in a test driven way. Yes, 5.6 has some additional test candy, and you can work with NUnit. As a developer, I don't want to spend 5 days to research an outdated practice, to learn 10 days after it isn't always reliable and another 20 days later that it's only added-value to burn time. In that regard, I've already said how much potential I've seen when it comes to GameFlow. There is only one other package to overcome a very specific need in visual scriptgramming, but that's just because I'm very picky about 3rd party solutions. Besides, it integrates with GameFlow perfectly, so why bother

 

BTW the 'code trumps all' quotation wasn't meant to be taken in isolation, it was when you have a complex if else logic, code trumps all, rather than any visual block representation.

 

I usually like visual scripting assets, i used uScript, Playmaker, uFrame(not really visual scripting). Outside Unity i also used kismet and blueprints. I think blueprints is by far the best visual scripting i used, not only for it's scripting part but how well it is integrated inside the rest of the editor/features. I should also add that i'm an experienced programmer so my point of view might be different than from a designer perspective.

Anyway about Gameflow, i can't imagine myself going throw so many expandable area inside the inspector just to see what's going on in the logic... I already feel the inspector being hard to read sometimes on complex objects, this is going to drive me nuts :/

This picture is from earlier post


It shows one of my issue with it, not much logic taking more than half the screen and overall it's barely readable for a person who didnt actually made it. There is a bunch of drag and drop reference but no good way to read the flow. At least when i read a graph i instantly understand what is going on. Reading C# code is much easier than reading this for me.



Also the first picture on the store is that one:


Last time i went to the Gameflow page and saw this i instantly closed the page, i'm probably not the target for the tool but i dont see why anyone would think this is easier than writing a few lines in c#. I get you have your own actions but if that first picture made me leave there may be other potential customer that do the same XD


If it works for some thats great, may be the problems i see with it are not really a problem once you use it. But so far what i saw doesn't sell it to me, so may be there is adjustment to do on what and how you show the features so that someone like me may feel more comfortable to try it.

 

Holy crap. That 15 seconds there, where he can't figure out what function to use.

That's a damning example. Something definitely went wrong there.

Edit: To clarify due to misunderstanding, this video is on uScript not GameFlow

 

Really? I think you criticize because of boredom. Do not give arguments, only criticize that at 9:40 a little hesitates... It's a joke or the lords are extremely delicate?

 

No really, that's a serious problem. If figuring out what method to call is that difficult, something went badly wrong.

I am a big believer in visual scripting, and these kinds of problems are things people need to find answers to.

At this point, you are losing most advantage from "visual". You need to essentially be a programmer in order to figure out what function to use, might as while use a proper IDE.

 

Difficult? ... I do not think, I tell you from experience. I've been using gameflow for a long time and according to your comment you are not even allowed to think or sratch an ear while you look for the action?.

Before the arrival of gameflow I try to use playmaker and it is a terrible headache, I did not hesitate, I was directly looking at the screen without knowing what to do. I wish you could try it, you'd be surprised if you gave him a chance, with gameflow and no previous experience you can do things in minutes.

But anyway, opinions for all tastes.

 

TL;DR
C++ is a hard language and by watching a video tutorial on Roll-a-Ball to compare two approaches with real life use cases. An unexpected "WUT" moment.

Well, at least we are getting somewhere.

Yes, you can. Apples, oranges. You can do visual scriptgramming or code, or both.

You would have to invest in either a good library or create your own. Takes time. Also means maintenance. And if it works for you, than ... good for you? I use snippets and shorthands a lot for code - in fact, without shorthands and snippets, working in code in the domain of prototyping are essential. However, prototyping is a very messy process if you do it quick. Ask anyone who needs to clean up after (which usually gets omitted). Often entire parts have to be commented out, undo-redo-undo-redo again (not talking about the snippets, but talking about the process of prototyping). It's click-click in GameFlow. I don't have to worry about a lot of things. I can focus on what I need to do. And when things are messy (it is inevitable in prototyping), the clean up is a less dreadful task.

Even if you know how to code or to use blocks and nodes, you can create a mess. Maintenance comes with the territory and its speed is vastly depending on your workflow. My point is, you will be working easier and faster depending on your comfort zone. Your claim is that your comfort zone is easier and faster for everyone. And that's where I disagree. It depends on your design process, design principles, patterns, experience and objectives. Yours are different than mine. So telling me that your approach is "easier" and "faster" to maintain, while I have a different experience is... well, you are smart enough to code, so you could be smart enough to decode that properly with your brain. Let's try that.

For the record, I do know "how to code". In a variety of languages. Like assembler, C, C++, Objective-C, C#, Java, Perl, Python, Ruby, JavaScript (and all its abominations), UnityScript, PHP, Haskell, COBOL, Go, Idris, Er, Elixir, Xill, SmallTalk and heresies like ActionScript, ExtendScript and many others that should be burned . I also do know how to program in VPL's, like NUKE, Quartz, MVPL, webMethods Flow, Lombardi, SoftImage, Blueprints, CODE, Circuit and yes, GameFlow. And I disagree with your statement from a professional standpoint that "maintaining logic in code is way easier than vast blocks or nodes if you know how to code" as a generic view point. But, you must be right.

Funny though, as the two best visual scriptgramming solutions (no, the other is not PlayMaker) are made by people who do know how to code and have more know-how about the Unity engine than most game developers will ever have, made the choice to work in their free time to write and develop with passion what they have seen as a missing link in the chain. But than again, you must be right.

To prefer code is not a sin. To preach code over anything else is like being forced to listen to a someone claiming that the world is flat, because they can't see curvature, yet continuously use Google Earth to proof their point. Feel free to believe what you think, that is your right as a human being. Doesn't mean other people are wrong. But than again, you must be right.

But, but... snippets? Code trumps all? C++, the ultimate powerful OO language? Easy maintenance?



And here I thought you know how to code!

Just for fun, I am going to respond seriously after the C++ thingie. Hold on. I need a break to quit laughing.
Right, still smiling. That's won't go for a couple of hours I guess.

1. No, the actions I've prototyped in GameFlow I don't need to convert to code. In fact, they are production ready.
2. Well, I can't imagine how C++ is hard a full game is a combination of a variety of things. Models, audio, textures, shaders, dialogs, scriptable objects and scripts. It is not all about code. And technically, if I had the desire, I could create a full game with the tools I have at my disposal to create a game without leaving the editor once. But, I do enjoy coding too. And I use code for parts to have very specific and customized control. But that is what I choose to do by preference, not because of any limitation.

Sure, do whatever makes you feel happy. Heck, why use Sublime at all, just use Vim! That will be even faster!

I just love to quote myself.

Let me break that down for you.

- Everyone likes to prototype quick. So the job is done and can focus to flesh out the concept.

- Only the insane do not like to prototype quick. But, sometimes batshit crazy people make cool stuff and they might have their reasons. The sane ones prefer to do it quick.

- The topic is not about C++ code. It is about visual scriptgramming and if you have tried GameFlow to do it.

I can't really help you if C++ apples and oranges is a hard concept for you to understand though.

If all you can contribute is that "code snippets are better", yes, you should definitely not be allowed to compare visual scripting with code. But, as long as the moderators feel you are not derailing or sabotaging a thread, you go ahead. I've already made the point it is futile.

I don't think no video or arguments will change your mind. After all, you do know how to code!

 

I totally respect your preferences, but allow me to ask you for an exercise of imagination towards a better understanding of what GF is about. Now close your eyes and imagine that you want your code snippets to:

• Have the ability of use variables (and I mean runtime variables, not static values typed in the Inspector) with values coming from other snippets and without having to code those bindings specifically for each possible combination you need in your prototype.
• Be easily arranged in sequences without additional code.
• Be easily executed conditionally or in loops without additional code.
• Be easily included in a state machine without additional code.

Got it? well, that is barely the 10% of what GameFlow is giving you... end of the exercise.

That video is from 2015... things are now even faster, even quicker and even easier. In those days we had not even the nice keyboard support we have now, which is btw great for developers used to write code.

 

@samnarain You're quite the character...

Please state where I said for everyone. LOL

Someone who doesn't know scripting, yes I believe visual based tools is a good way to get into it. To develop into big non trivial games, no this is where I disagree.

You keep going on about apples and oranges with examples that segway into whatever allegorical story appears to be riding in your head. Why? Beats me, but if we can't compare visual scripting with coding, why are we having this conversation. logic = code, code = logic, visual coding = game logic, game logic = visual coding, dogs, bananas apples oranges whatever LOL. Let's compare, we're making games after all.

Does a game consist entirely of code? Of course not, where did I say that, you have models and animations and sounds and other stuff.

Again my point is, at some point, unless you're crazy or your game is trivial, you will want to convert that fast prototyping logic you just did in gameflow to code. So what's the point when you could have done so with snippets from the get go?

 

I agree with you. I am actually using a Blueprint-like solution for my other needs in visual scriptgramming. I think Unity is currently developing their own solution too.

I do abuse GameFlow for use cases where it feels handy. It will drive you nuts if you are going to make a lot of complex logic. You will most likely do what I do - that is combine the actions with code.

That is indeed a preference. I've also pointed out I use a graph tool. Sometimes GameFlow does not fix all. And sometimes code works better while working through. However, my process is mostly creating tiny pieces of logic and orchestrating.

Hahahaha! You have no idea! I actually have had exactly the same standpoint. I've been telling the developer continuously his marketing sucks. It really, really is an undervalued piece of work. The difference in GameFlow being easier would be like learning BASIC versus learning C#. But you are right, C# is not difficult to learn. For some people it will fit, for some people it won't.

Hehehe. This is not a tool for you. No visual scriptgramming will ever, ever, ever please you! Go away!

Wut? I am shocked.

That example was fugly.

I think you should be careful here, I can tell you that if someone can have solid arguments to crucify a solution like GameFlow as a skill set, that be @frosted. And he can crucify it - I could too from a coder's perspective. He has a solid point. A tool that is meant to be intuitive and makes you look for an option that should be a no-brainer to find (come on, a Transform..... that is just funny to look for it for even 4 seconds...).

Kudo's

 

Awww... I missed you too

 

@_xeleh_ I'm guessing you're the developer, so hats off, it looks like a great tool.

But after imagining all those scenerios I still prefer my snippet workflow better. Because I can prototype just as quick if not even quicker with my snippets than I could with gameflow.

 

I can do that in C++!

It's somewhere in your C++ snippets. I am going to ignore you now