Which visual scripting tool to pick considering... [see thread]

Hi!

I'm new here and looking for help in making a most important decision for my new indie project. I'm aiming for a commercial release and working alone, and I'm unfortunately pressed by time.
Working with a limited budget, saving as much as possible for the promotion and not being a coder, I considered using an appropriate Unity visual scripting tool (abbreviated to VS for future references).
Now, to this day, several options stand before me. Playmaker, uScript, Antares Universe Vizio (is the name really that long?), Brain Builder, etc., most of which many of you are familiar with I guess.
But before asking which one is better, I need to point out what are the limitations and goals:


- I am not a coder: I know nothing about "classic" code syntax, not even a shred of C#at the moment, and don't have time to learn anything of it.

- I know VS: I already worked with some perhaps obscure tool called Virtools several years ago, and although I never approached what they called VSL, I do have the structural logic required for building such projects (I globally get what "raw" code does, I just suck at syntax and knowledge of specific functions in C#, C++, Java, Lua, etc.). Best case scenario? A tool that acts in a similar way (with flux going in and out from left to right, plus parameters and vars visible with entries and exits above and below "building blocks".

- Game oriented: A tool designed for games first and not just plain interactive stuff, with a solid showcase of game use.

- Short learning curve: Based on my former experience with Virtools, plus assuming the game concept is clear and solid enough and the development can be started ASAP for a planned 2.5~3 months of production, by the end of November, the game should be in mid beta period and allow for the initial phase of press coverage. So time alloted to learning the core of the tool could only be limited to one month tops I figure.

- Well documented tool: If there's no community, no forum or wikia, no videos, I'll obviously pass.

- Should allow a gold release: 90 to 100% of the project's code should be handled through that tool and only that tool. The concept is generic enough so that even the bits of originality shall not create problems.

- Extendable through C#: Preferably, new behaviours/actions could be added as mere C# scripts identified as behaviours/actions by the tool. Likewise, vanilla/official behaviours/actions should be readable by any coder who knows C#.

- Tolerable performance: The game project isn't requiring absolute high speed performance in terms of fps, it's rather static due to the nature of gameplay. So I can afford losing a bit of performance on that side, as long as I can properly manage such things as object pooling and recycling, memory dumping, draw calls, etc.

- Compatible: This VS tool should work with many other third party Unity plugins, including essential ones that allow for the management of in-app purchases, ad integration (banner, interstitials, videos, cross promo), statistics, social networks, leaderboards and unlockables, player testing, extra peripherals, etc.

- Good interface: Should be easy to navigate (by mouse or with arrows, zoom in/out) and read (best placement of blocks, capacity to make groups, leave notes, good use of colour schemes, links don't make a mess on the screen and easy to differentiate, active flux should leave plenty of clues about current state).

- Maintenance: As vague as it sounds, whatever the VS tool generates "behind" each action block shouldn't create a mess of code and, if C# is indeed produced with the visual block only being a convenient appearance (or wrapping bag for all to see instead of the code), allow for said code to be cleaned later on without finding oneself stuck, for a lack of better words. If bugs can be generated by the VS tool, of course a modicum of debugging suite would be appreciated, as long as it's not too complex to understand.

- $150 or less: Explicit. A slightly more expensive tool can be considered if it really surpasses others by a substantial margin.

- Multiplatform: Project is aimed for iOS, next Android, eventually web and WP8. All will be done on Unity.


With all this information, I dearly hope some members will be able to give me a hand in chosing the most sensible solution.
Just in case, other threads related to the same topic tend to either be too old or too focused on one tool or comparing only two tools, and sometimes they still don't get detailed enough.
Here, I believe I sufficiently dwelved into my project's requirements so as to give you guys the best information.
Best thread I found was this one, but it's a bit dated and too general.
If I missed a crucial and fresh enough thread going into all these details, please feel free to provide a link.

My first impression being that Playmaker is most popular, but has a logic of its own that seems detached from how Unity runs with scripts. It's hard to explain, but it doesn't feel like a plugin as much as it looks like a whole different system that just integrates "inside" Unity's UI. This could worry me since I'm not sure about what kind of limits are inherent to this system and when you reach them when you'd like to do something not necessarily available with the default action blocks. Some people also made a difference between Playmaker's visual management of functional state machines, while apparently other tools really are C# scripts, albeit unreadable, but with a nice VS GUI that is the point of VS.
Obviously, this thread inquires the experience of some developers who might find their experience somehow similar to what I'm involved in right now.
Many thanks!


TL;DR

Which VS tool is best suited for making a simple "classic" indie game from A to Z and ready for commercial release +ads +IAP +leaderboards +unlockables, all by myself, while I'm no coder at all?

 

With all those +'s (+ads, +IAP, etc.), go with PlayMaker. It has the widest support for other products, and the biggest library of extra action blocks. Since you're just one person, you're almost certainly going to use more Asset Store products for ads, IAP, etc. or at least extra action blocks. If you ever need to contract a programmer to make a custom action for you, they're most likely to be familiar with PlayMaker.

The first post of the PlayMaker thread lists many of the commercial-quality games that use PlayMaker (Hearthstone, The Forest, Dreamfall Chapters, etc.).

 

Thank you Tony for your answer.
I'll probably stick with PlayMaker for the time being. I had seen the projects that made good use of it but wasn't sure how far PlayMaker could handle an entire project.

If I understand how it works, plugins need to be built in a specific way in order to be compatible with PlayMaker. I had the feeling that other (true?) VS tools didn't suffer this requirement. For example, uScript providing blocks which seem to be real C# code meant that it could run with any plugin (aside from potential inter-plugin conflicts which are inherent to any plugin), but the code generated that way wasn't meant to be read by a programmer so it would be close to gibberish: it would work fine, but one shouldn't hope having the uScript-generated code to be intelligible.

Also, was it the right place where to post this thread?

 

As a point of curiosity, what do you think of the arguments presented there:
http://themaddoxcorner.blogspot.fr/2011/04/visual-scripting-and-coding-for-games.html

 

They all need to be built in a specific way in one respect or another in order to interface properly with the visual scripting editor. I don't think any particular visual scripting solution has an advantage here.

I think it's as good as any. I've seen several threads on this topic in this section, and to my knowledge the moderators haven't suggested a better section for them.

It's just my opinion, but I agree with most everything except the value of generating C# code. Just because a tool can create real C# code doesn't mean it should, or that the code is readable or manageable outside the tool. (I'm talking in a practical sense in a full-scale project.) Not to knock uScript at all, but the C# code wouldn't be a compelling reason to choose one tool over the other. You can get into plugin compatibility issues even with raw C# code.