Godot: Easy to use game designer for non programer

visual scripting is planned at some point

On Wed, Jan 14, 2015 at 6:20 AM, RyanBram [email protected] wrote:

Hi, Godot Developers.

First of all I want to thanks to all of you for creating great game engine
with very permissive license. Your effort will help many developers and
students with tight budget to fulfill they dream.

With current status of Godot, open source gaming will has brighter future.
Unfortunately most of open source of game engine is designed with advanced
user in mind with little knowledge about programming. It still cannot reach
a beginner game maker.

My suggestion is to provide an easy to use game designer/editor with
intuitive GUI and predefined class to ease the task of new programmer. More
programmer means more user (because Godot user is game programmers).

I know one game engine which do this job well. It is writen from Ruby,
originally from Japan, and translated to English worldwide. It is called RPG
Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. Despite
the RPG word in front of its name, it is capable enough to create non-RPG
game with its built-in Ruby Game Scripting System (RGSS).

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

The following list is example of games made with RPG Maker engine:

1. Aleph (RPG Adventure) http://www.pioneervalleygames.com/
2. No Manatees Promised (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Card Game) http://rpgmaker.net/games/5808/
4. Earth Under Attack! (Shooter) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memories of Mana (Action RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - The Beginning (Horror) http://rpgmaker.net/games/6493/

I wish Godot engine become as popular as RPG Maker, because it has much
more features than RPG Maker. Beginner programmer just need an easy to use
interface. If it was success, Okam studio may become next GOG or Steam
which publish thousands of games created by inde developers.

Regards,Ryan

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - Not trying to downvote the idea, at all, here - it probably could be useful in the future, but I'm not certain visual scripting is an effective means of scripting. I can't say for sure, but I'd imagine the more complex games you posted most likely were scripted in text, not visually. It kind of seems like visual scripting is something new users use, surely, but that delays them in learning the actual tools they'll need to properly complete their projects. But it could make the engine more approachable, so I don't know.

It should also be possible for users to create a visual programming system all in Godot with GDScript as opposed to something that needs to be built into the engine, right? I'm not sure about that, though.

RPG maker seems to take more of a "Modding" approach, and if Godot will look more like RPG maker - people who have intentions to make different kind of games will turn away. So what you're basically suggesting is to make godot look more like GameMaker (which is understandable, many people want to make games but don't know programming) but there are limitations :)
What will probably happen is that Godot will get Nodal Behavior Graph editor, similar to what Leadwerks and BGE have. This works very well with GUI elements, the rest would require some research and tons of community feedback, to make it as easy and as powerful as possible.

@SolarLune , it is possible to build a game in Godot and add an editor on top that allows modding the game to every little detail (by using GraphNodes and rest of UI, very fun to play with), and would even allow to write some extra GDscript code on top, I think this is the best approach, to ship a complete game game (RPG, FPS, RTS) separately and allow tweaking every aspect of it. Constructors made in Godot.

@SolarLune: Visual scripting is useful when you work together with a
programmer, that can make block for you to put together to play with. This
approach in Unreal is useful. I don't think it's possible to replace
programming entirely (unless you are a masochist), but it could work for
some people to make template blocks for non-programmers too.

On Wed, Jan 14, 2015 at 4:23 PM, TheoXD [email protected] wrote:

RPG maker seems to take more of a "Modding" approach, and if godot will
look more like RPG maker - people who have intentions to make different
kind of games will turn away. So what you're basically suggesting is to
make godot look more like GameMaker (which is understandable, many people
want to make games but don't know programming) but there is a limit :)
What will probably happen is that Godot will get Nodal Behavior Graph
editor, similar to what Leadwerks and BGE have. This works very well with
GUI elements, the rest would require some research and tons of community
feedback, to make it as easy and as powerful as possible.

@SolarLune https://github.com/SolarLune , it possible to build a game
in Godot and add an editor on top that allows modding the game to every
little detail (by using GraphNodes and rest of UI), and would even allow to
write some extra GDscript code on top, I think this is the best approach,
to ship a complete game game (RPG, FPS, RTS) separately and allow tweaking
every aspect of it.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733.

Well, from what I know, Godot already has node-based UI code (for the animation tree and now the visual shader editor) that can, in the future, be used to create a 'logic' tree type.

However, one will have to note that GDscript will remain the way to go if you want maximum flexibility and making the logic nodes useful would require a script node for GDscript execution (for more complex and more advanced stuff).

UE4 right now cannot do everything in Blueprints without insane complexity, GameMaker expects you to use GML for maximum flexibility (through the use of code blocks), and the BGE requires scripting in Python for maximum power (through the use of code bricks). One cannot discount the usefulness of visual editing for quick prototyping and less complex logic situations, but it often cannot do everything that one can do in code.

visual scripting is planned at some point

Thanks for simple and positive response.

Everyone, thanks for commenting this suggestion. I believe an easy and visual editor never capable enough to replace coding by hand. I suggest this feature as complementary for regular coding not for replacing its position.

In RPG Maker VX Ace, most of advanced feature is coded by hand. An advanced programmers usually provide advanced modding script which value can be edited in GUI Editor by casual user (Character name, skill, portrait, sprite, etc). The Ruby Game Scripting System make it possible for monkey patching. This is why most script provided by advanced user will not replace original predefined class by RPG Maker developers to avoid compatibility issues.

For comparison:
KDE and GNOME projects never intend to replace the powerful Shell Commands in Linux, instead the projects just trying to fill the gap between ease of use and the power of Linux.

I smiled about that idea of Okam studio being like Steam... :))

On 1/14/2015 5:20 PM, RyanBram wrote:

Hi, Godot Developers.

First of all I want to thanks to all of you for creating great game
engine with very permissive license. Your effort will help many
developers and students with tight budget to fulfill they dream.

With current status of Godot, open source gaming will has brighter
future. Unfortunately most of open source of game engine is designed
with advanced user in mind with little knowledge about programming. It
still cannot reach a beginner game maker.

My suggestion is to provide an easy to use game designer/editor with
intuitive GUI and predefined class to ease the task of new programmer.
More programmer means more user (because Godot user is game programmers).

I know one game engine which do this job well. It is writen from Ruby,
originally from Japan, and translated to English worldwide. It is
called RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Despite the RPG word in front of its name, it is capable enough to
create non-RPG game with its built-in Ruby Game Scripting System (RGSS).

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

The following list is example of games made with RPG Maker engine:

1. Aleph (RPG Adventure) http://www.pioneervalleygames.com/
2. No Manatees Promised (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Card Game) http://rpgmaker.net/games/5808/
4. Earth Under Attack! (Shooter) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memories of Mana (Action RPG)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - The Beginning (Horror) http://rpgmaker.net/games/6493/

I wish Godot engine become as popular as RPG Maker, because it has
much more features than RPG Maker. Beginner programmer just need an
easy to use interface. If it was success, Okam studio may become next
GOG or Steam which publish thousands of games created by inde developers.

Regards,Ryan

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220.

Unreal actually has templates for projects whether you want to do a
visual scripting or a full scripting type of workflow... and even the
blocks of code for visual editing is accessible via visual studio and be
customized... :)

On 1/15/2015 3:44 AM, Juan Linietsky wrote:

@SolarLune: Visual scripting is useful when you work together with a
programmer, that can make block for you to put together to play with.
This
approach in Unreal is useful. I don't think it's possible to replace
programming entirely (unless you are a masochist), but it could work for
some people to make template blocks for non-programmers too.

On Wed, Jan 14, 2015 at 4:23 PM, TheoXD [email protected] wrote:

RPG maker seems to take more of a "Modding" approach, and if godot will
look more like RPG maker - people who have intentions to make different
kind of games will turn away. So what you're basically suggesting is to
make godot look more like GameMaker (which is understandable, many
people
want to make games but don't know programming) but there is a limit :)
What will probably happen is that Godot will get Nodal Behavior Graph
editor, similar to what Leadwerks and BGE have. This works very well
with
GUI elements, the rest would require some research and tons of
community
feedback, to make it as easy and as powerful as possible.

@SolarLune https://github.com/SolarLune , it possible to build a game
in Godot and add an editor on top that allows modding the game to every
little detail (by using GraphNodes and rest of UI), and would even
allow to
write some extra GDscript code on top, I think this is the best
approach,
to ship a complete game game (RPG, FPS, RTS) separately and allow
tweaking
every aspect of it.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-69978224.

I smiled about that idea of Okam studio being like Steam... :))

I also smiled in a positive manner.
Because it will be great for me as a gamer if there is a company as big as Steam with tons of games catalogue, open, and DRM Free, created by thousands of great game developers.

Unreal actually has templates for projects whether you want to do a
visual scripting or a full scripting type of workflow... and even the
blocks of code for visual editing is accessible via visual studio and be
customized... :)

Great if it will be available in Godot.

Regards,
Ryan

Hi Ryan

Have you checked out Construct 2? It is one of my favorite visual game designer and extremely simple to use.

Visual programming in Godot, i think will be somewhat difficult to do (as Godot does both 2d and 3d so the scope is much much larger.)
Also it will likely be built in much later when all the underlying blocks for the engine are in place.

I know reduz has his own roadmap for this but I hope that he doesnt prioritizes this over other editor/engine updates. I'd rather have Godot being used by beginner or semi proficient programmers than non programmers. But that's just me.

Hi Ryan

Have you checked out Construct 2? It is one of my favorite visual game designer and extremely simple to use.

I tried Construct 2. It is nice and awsome. The resulted games also cross platform, so it is a big plus. Unfortunately I still cannot find any tutorial for creating RPG games easily. For now I may stay with RPG Maker VX Ace and trying to port my game to many platform (including Android) with the help of MKXP Project.

Thanks for sharing. I am looking forward for visual programming in Godot.

Best regards,
Ryan

For visual scripting approach - you can take notes from gdevelop, multimedia fusion and construct 2. Those engines rely 100% on visual scripting. You still need to learn some syntax where expressions are needed, but the expression editor makes it extremely easy to find the right commands. These three engines give you the freedom to create any type of a game with visual scripting - as opposed to game maker and rpg maker.

Rpg maker is not really a good example, since it is extremely limited.
Node based scripting is very inneficient in terms of use of space- you will pan around and zoom in and out through a giant node graph. Compare that to construct 2, where everything is laid out in a clear fashion and its tight and easy to read - and you got a winner.

BGE is probably the worst example here, since it tries to combine a node based approach with logic blocks. I wrote about why this is bad:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

If you do visual scripting, please do not half arse it with a generic node based editor. If you want more non programmer folk to use your engine, do something with a better design - like construct2 or multimedia fusion.

I'd like to see something like this implemented _only_ as a secondary way of programming. Visual scripting, as opposed to code, slows down productivity by a pretty big order of magnitude. It also tends to make debugging and refactoring far more difficult. The one major upside I can think of (beside for it appealing to non-programmers) is that visual scripting tends to be a great teaching tool if it would be able to generate, or at least show, actual GDScript code (IE. code.org). I don't think it would need to go the other way around (IE. GDScript to Visual). I think this would be a great way for schools to adopt Godot into their classes.

Here are two major differences between code and visual scripting that I think are the most important as far as approachability. This is coming from someone who won't touch visual scripting with a ten foot pole, but I do understand it appeals to some people :)

Code: Code tends to have specific syntax rules that need to be followed. My guess is that this tends to be the main thing that turns non-programmers off. IE. in GDScript you mush have a colon at the end of a function declaration, if, for, while loops etc. You must indent properly. You must use the var keyword when declaring a variable like "var myInteger = 1". For most languages, there tends to be about 3 or 4 primary syntax rules that tend to need to be followed and in my opinion aren't that hard to learn. After writing a handful of small scripts even an artist can learn them. I say this because I work with two very talented artists who worked on all three of the Age of Empires games with Ensemble Studios. One has written quite a bit of code in UnityScript and the other has now written a ton of code in C#.

Visual: You tend to get a dropdown menu for the method, variable, statement, etc. However, you must still know which functions, properties, etc that you're looking for and what they do and even sometimes how they work. You must still problem solve. You must still use variables and keep track of what they're doing throughout your script. You can still have logical errors just as easily as writing code.

I do think being able to actually write the code is ultimately a far superior way to go from a productivity standpoint. However, neither will make you a better/worse programmer. I do think visual scripting is a really good teaching tool, but if you don't know (or want to learn) how to structure things properly and especially how to problem solve, visual scripting won't help you one bit.

I would take a slightly different approach. Since godot editor is driven on itself - it is easy to recreate a similar editor interface in pure GDscript.

So my proposal would be to make a constructor scripted entirely in godot and ship it separately. This would allow programmers and non-programmers to work on the same project while using different tools. Only problem is that non-programmers will have to sometimes deal with both tools at the same time, but hey, I've seen worse xD Gridmap editor, shader editor, animation editor, code editor - can be recreated, while collada importer, convex generator, exporters - not that easily. Still feels like reinventing the wheel, but can simplify a lot of things.

Constructor core could be adopted to any game genre (FPS, RTS, GPS....) with downloadable content and stuff, and if it's community maintained - it will be easier to contribute, because everything is GDscript
It's not likely that there will be visual scripting in godot any time soon, but it doesn't stop others from creating a constructor on top of it. I've seen someone took Blender 2.5 and made a tool for designing interior.

I think that having multiple editors could fragment Godot's development. There needs to be one well designed central project for a visual scripting tool that builds on top of gdscript.

Dont be lazy and do your research. Look at other purely visual scripting engines. Compare their userbase (how popular they are), compare how flexible they are - the types of games that were made with them - be it on kickstarter, steam or other platforms.
Look into their design approach.

Then design it on paper. Dont just copy the node approach. Using nodes for shaders is ok, but when it gets to logic you end up with one hell of a mess to scroll through and try to figure out.

trust me, I tried everything. Unity's playmaker, Unreal's Kismet, rpg maker, stencyl, etc etc..
Construct2 comes ontop, along with multimedia fusion. Those are the most popular ones, with the most flexible approach. And they both have an asset market store.
They are extremely flexible and if you look into games made with them - there is a huge variety of genres.

If you get even smarter about this, you could team up with Gdevelop- another open source project that already has a visual scripting editor that makes html5 games.
Look into it's design and source code..

If we were to take a vote on this thread I'm quite sure it would be the completely wrong place because mainly programmers would show up for the vote.

A visual scripting system should be designed for artists, not programers. As much as I could complain about my utter dislike for things like PlayMaker on Unity, the truth is that artists love it. That's why it has almost 2000 reviews and is 5 stars. If the vote is to have something more like Construct 2's scripting then my vote is to not have visual scripting at all as I don't believe it will be of any real benefit since A) Programmers can program directly in GDScript and B) Many artists will be instantly turned off by it and just go elsewhere. I know, because my two artist friends, who both can code, were looking at Construct 2 and poking fun at the programming interface it has since it's almost the same as just writing code.

A visual scripting language should be very visual, not many words. It shouldn't look like code at first glance. It should be tailored to "visual people", otherwise there's no point in making it in the first place. Artists are used to, and tend to like, node graphs as they give you a visual sense of what your program is doing. Again, I don't like node graphs myself as I can't stand them, but I'm a programmer and my vote really shouldn't count in this area.

I agree with you that it should be designed for artists/designers.
But disagree on the logic that words=complexity.

If you sit someone down to teach them to use one of the two - construct2 will come up as the easier of the two. Why?
Because it is clearer than nodes. Much clearer. You have conditions and actions. You put the first in the left side and the other on the right side.
To add any of the two, you dont have to know commands. They are all listed there for you to add them- clear as a day. Each comes with an icon - which is a visual hint.

Playmaker and other node based systems require much much more learning, because hooking a node to another node requires you to first understand if you can connect the two. Its not simply condition--> action. Nodes are way more complex and lacking in visual hints. Where did you see icons in playmaker??
Its much easier to make a mistake in it. It is much harder to read logic in it.
https://www.scirra.com/tutorials/top
I would also argue that because C2 is a better designed visual programming tool, it has a much bigger community of active users than playmaker does - even though it is limited to 2d games at the moment. Much bigger number of video tutorials on the web (more people understand how to use it than playmaker), much more completed projects, a healthy active market place and forum, and most of all active communication between developers and users. So the developers know what the artist users want.

Construct users can simply take a screenshot of their event sheet and its clear as a day how they did it. Go to the forums see for yourself. I would argue that it has much more users than playmaker.

I would argue that it takes less work to setup logic in it than it does in any node based system.

I can see that you like them, but please at least try construct2 before declaring that it is a programmer's engine.
Look at their forum and user base. It has as much if not even more good rep than playmaker. It managed to get that good rep by being well designed - on its own- not by being a plugin for an already succesful engine . It is a pure visual programming tool that any artist can use. I am an artist and I tried playmaker- its harder than construct2. Go on C2's forum and try to convince them that playmaker is easier to use - just for a laugh. :D
Arent you a programmer yourself? You have contributed to github projects more than me. Doesnt that mean that you shouldnt make the statement which is easier to learn?

I understand your points from the perspective of a programmer. If I had to pick between the two I would go with the Construct model too. However, like I said, this is the worst place to make this decision because probably most if not all people who read GitHub mailing lists are programmers.

I've spent more of my career around artists than I have around programmers. While I've regularly done both for the last 18 years (and been passionate about both) I was professionally an artist before I was professionally a programmer. Not that I care that I even have a degree, my degree is in Digital Animation and Visual Effects. To the best of my knowledge, commercials I worked on still play after several years in Kansas City. I've worked on shots for Hallmark, Sprint, Radio Shack, Honda, and a few others I'm likely forgetting. I also had a lot of fun working on quite a few shots in "World Builder" with Bruce Branit.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden in the credits is me

I'm not saying this to brag, I'm saying this to make a point. I could be wrong, but as an artist who has spent a lot of time around artists I think I know what artists like. They don't tend to like things like Constructor very much. They tend to feel intimadated and choose an entirely different app. Artists in general have a very different minset than programmers. It's like when I talk to my friend Erik about technical things I'm trying to teach him, these words come out of his mouth pretty often, "Nate, I'm a very visual person, if you can't show it to me visually you might as well be talking to the wall".

There's a reason artists enjoy things like node based shader graphs as opposed to linear shader systems. They can visualize what's going on. I don't think I've ever heard an artist complain about not having a linear shader system in their favorite 3D application, but they complain regularly when they don't have a node based shader system.

There's a reason artists prefer apps like Fusion over After Effects. In pretty much every case they'll choose something node based over linear because it's more visual.

So, 2 more reasons why a node based system will appeal to artists:

1) They visually look far more appealing.
2) It fits within the design paradigm they're already used to. IE Shading and Compositing

That's really what it comes down to. If the artist is going to take one look and pass to the next game engine because the other one has node based programming, then Godot shouldn't have visual scripting at all, because there probably won't be more than a tiny handful of people who will use it and it just means more code maintainance from that point forward.

Are you sure you have any idea what Construct2 is? You are not even spelling its name correct.
It is not called "Constructor" .

I completely disagree that we should go with nodes because "It shouldn't look like code at first glance. "

It's more important how clear it is than how it looks. Clarity of what logic does is more important than how the editor looks at first glance. Construct2 does not look like code- the text is written in plain english and its obvious what an Action or a Condition does. People using C2 tend to be mostly visual people too.

An event sheet will always win against nodes- however you try to make it look. It can pack more information on the screen with less panning around - it's more obvious what the logic does. And the visual cues (icons) are much easier to find by the eye of the artist.
Nodes have no icons and a huge limitation of text.
So in a lot of cases a node is not even describing what it does clearly, because of how limited it is in size - forcing the design to use obscure terminology instead of plain english.

Another point:
An event sheet is read and executed top to bottom. This is obvious and predictable.
With a node network, your eyes will travel all over the place,they split into branches. It gets way more complicated.

Third person opinion stories on first glimpses and not actual user experience should not bare any weight here. I am a very visual person too, but one that has already used many visual scripting engines. It's an absolute pain in the neck to see people make an argument without using the actual engines for a while - with a small project for example.

I urge designers/developers/visual people of godot to actually try these engines on a small scale project and then get to conclusions. Enough of these third party stories. We need hands on research and logically stated case of why one is better than the other. Believe it or not visual people have some common sense too.

Offtopic:
On the example of Fusion vs Aftereffects - people prefer a node based approach to compositing, because using layers can get very cumbersome on a complicated scene where the same effect can be duplicated on many layers. With nodes you can have more flexibility in terms of compositing and just hook one effect to many layers. But nodes are more complicated than layers.

I agree with you on pretty much all points, but those points are still from the perspective of a programmer. If I had to use a visual scripting system all day I would pick the one that looks most like regular code. That's why I'm a big fan of teaching kids who want to learn how to program using code.org. I'm really a big fan of the style. It's good for teaching people who "want" to program how to program.

And yes, I said Construct wrong, sorry. No I haven't personally used it. But, it doesn't matter though because the scripting paradigm that it uses isn't a new concept by any stretch of the imagination, so my arguement isn't even about Construct itself. It's about that style of scripting as it pertains to artsists, not programmers.

In a node based system you can have several conditions and events and functions contained within each node. You can then name the node something like Input, for example. Inside of it it will contain all joystick inputs and the user would tell it what event to use. IE. they would specify an event like "Fire". That event would cause a transition to whichever node they hooked it up to.

Here's a simple example you could have on a weapon that would simply handle the firing. Note that while it's simple, it's also powerful and it looks nothing like code:

On a final note, you could make block based scripting or node based scripting both look pretty good from an interface standpoint, so I won't waste my time arguing that point.

However, when I said "It shouldn't look like code at first glance." Many artists do care about what they're going to be looking at all day every day for an indefinite amount of time. They'll reject an entire app if it doesn't look appealing or if it looks intimidating. I'd say the block based looks intimidating and confusing to a typical artist. It looks like something for programmers, and it is.

@blurymind,

Graph nodes actually came from conceptual UML. You make graphical representation of code in a way that non-programming audience (project managers, consumers, artists) can understand. This is what UE4/Unity uses. This is something that everyone in the industry is aware of. Constructors usually take a different approach, and how good this approach is - is not defined by the number of users that uses it.

There is always a learning curve everywhere, and Construct2 is not an exception. But let's not force C2 stuff into Godot without backing the arguments. Event sheet will become longer with more complex games, and end up wasting more space than graph nodes. Only "Add action" button has it's own row to itself. It's basically how a programmer would interpret a block of code. So it ain't that bad.

I personally don't see why we can't have both, but devs already have enough to do so it won't happen any time soon. This is why I proposed a different approach that will evolve faster, pretty much driven by non-programmers in cooperation with programmers.

Here's a better example to show that you can have more than one event per node. Also note that each node (or state) is non-blocking, so it will allow other node graphs to run concurrently:

But see, just by looking at your screenshot I have no idea what that logic does. What the hell is "firePrimary" and "fireSecondary" ??
Now scroll up to the screenshot I posted of construct2.
On construct2 the condition on the left will read "on "R" pressed" or something that is in short plain english - with a keyboard icon next to it!

Show them both to an artist and ask them which is clearer.

Show us a more elaborate node setup as well :) The C2 screenshot shows entire game logic. Yours is only one event. Can you fit the same logic in one screenshot with nodes? I dont think so.

See the node example is obscuring information.
You have to select a node to see whats set inside it.
It is using obscure programmer terminology rather than human language ("Send event","Store results" what the hell?).
Construct2 shows everything in one place and it's understandable to non programmer folk. The point of visual programming is to get rid of the need to learn terminology.

I am not a programmer. I dont have any experience in writing actual code. Yet I can make a game with construct2 easily and to me using nodes is way harder- when it comes to a complete game.

I understand that everyone will always vote for whatever they already know how to do well. But as you admitted- you are a programmer and have not actually used C2. And I keep the statement that I am an artist with no coding experience- who has used both nodes and C2 approach.

I am giving you good logical arguments on why to use one over the other.
You are giving me statements such as "nodes are more visual" and "unreal uses nodes". Those are opinionated statements. And you both admit to be programmers.

Telling me I'm not backing my arguments is just a confirmation that you have no desire to look into construct2 or consider it's design as an alternative to nodes. It is sadly a waste of my time to convince you otherwise.

@TheoXD
I quite agree with you if I'm reading you correctly. It would be nice to have both as a seperate plugin/module. So, underneath would be actual GDScript, but you could visualize it using whatever you want. I think this is possible. The node based approach may need some flags like special comments to separate out nodes (IE. #node name="Input" and #endnode), but not that big of a deal since it would be automatic if you started with the node graph. I think the block approach would be straight forward.

Is something like that what you meant?

Like I said above, I really like the block/Construct/code.org method as it works really well for teaching programming. I just don't think it's a good fit for people who see programming as a neccessary evil.

@blurymind
The reason why it doesn't make sense is because you aren't familiar with it. When I look at the Construct image above I equally have no clue what's going on, not because it's bad, but because I'm unfamiliar with it.

As far as not being able to see what's under a node until you click on it, once you've setup a node there's no real point in sifting through what you already know is there. I already know that I have left and right click and that they fire primary and secondary ammo. I already know what the primary and secondary fire nodes do. It hasn't changed since I made it, why do I have to see the details every time I look at it? So, now the underlying logic is just clutter. This is another reason why nodes are more artist and non-programmer friendly. They can break their specific logic into more general chunks. It makes it so they can get a big picture view and only worry about the details when they absolutely need to.

I'm looking at an actual project for an actual published mobile game right now and almost every node graph is 2 to 4 nodes at most, so it's hard to show you a more elaborate setup when you typically don't need an elaborate setup.

If you want elaborate, this is from that same app that was written by a person who is about as non-programmer as they come. This is one of the most complex graphs in the game. It controls the main player's movement:

(That's another thing you can't do with blocks is make them look like Samus's ship, haha)

Without any prompting, I just put up your Construct2 image on one screen and put the above node graph on the other and asked my wife (who is definitely not a programmer), "Which one would you want to use if you had to use it every day?", and she pointed to the node graph and said, "This one". I know that's not definitive, but the fact that it's less intimidating means I have far more of a chance to even begin to get her to learn it. If it looks intimidating she may shut her brain off before I even get her to sit down to learn the basics.

Without pushing him toward one or the other, I also asked my artist friend yesterday (the same one who worked on all three Age of Empires games), who's been in the game industry for almost 20 years now, (and who has used Construct2) what he thinks other artists would prefer and he also said the node graph.

Anyway, I really do enjoy the discussion but there's no sense in beating a dead horse, haha :)

Yeah I do enjoy it too. No bad feelings :)

Awesome Samus Ship btw. The more pictures you post, the more you support my case that nodes are visually harder to follow since they can split in branches and go in crazy directions.
To me the added complexity of having to follow lines and arrows between blocks has always felt like extra work. I guess I should give nodes another try one of these days. If thats where godot will be heading.

Again you are giving us third person stories that are not really supported by evidence. Get the dude here and get him to tell us WHY he prefers one for the other :)
Then you will have a stronger case. I am not getting any logically sane points supporting the thesis that nodes are more straightforward so far.

yes it looks less intimidating at first glance because it is hiding a lot of the information. Your examples are much simpler than what is shown in the screenshot I posted. This is misleading.
Here is a video that shows hot to set up logic for a platformer in C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
skip the first minute :P

Lets not compare apples to oranges.
Code.org is a radically different approach from Construct2 - it looks more like Stencyl and has one of the disadvantages of nodes: Your conditions and actions are not clearly separated - so it is harder to figure out what you can attach to what. Well designed visual programming tools (Multimedia fusion, construct2, gamedevelop) all separate conditions from actions clearly for the user. This makes it much easier to build logic as they are organized for you by the software which is guessing what you might need and showing it to you at the right time. it also prevents you from making silly mistakes.

With nodes/stencyl/code.org you have to figure out which piece is a condition, which is an action. It takes more figuring out to set up your conditions the right way. What type of an information is coming out of a node? It takes more nodes to set up a condition some times- more learning how to hook them up.
Come on, do your research and actually use the other tools for a bit. Seeing all the non-node ones as more of the same is not helping.

@blurymind, your case is so far backed by the amount of users using Construct2, which is usually a result of the business model of the software and how good they are at marketing. Personal preference (your logical arguments) is not enough to force C2 workflow into Godot. But it's a good reference though.

If you would show someone how you would like to build your game (object-object relation) on paper or a blackboard, how would you show it? By writing an event tree? No. You would draw a conceptual view with nodes and lines, then think of them as classes, add functions, members..
I would agree that event table looks more like code, only interpreted by a programmer, and it can make users want to learn actual programming as they advance. I've noticed it has some terminology and learning curve too, you can't deny that. But shape recognition and object grouping is actually a real thing. I study a course about data visualization, and besides how boring it might get - it actually makes good points.

As much as I would like to see this issue score over 100 comments, devs will not read them all, best thing each of us can do is to make a PDF with proposals, and share them on mailing list. I don't see why we can't have different levels of abstraction, Graph nodes as top level, that can be represented in a form of an event tree. If this works then there will be no need to compromise.

"@blurymind -- || -- And you both admit to be programmers." - I don't consider myself as only a programmer, do art too you know. I use my experience to look at things from an objective point of view.

I'm not sure if it was missed, but I'm not just a programmer either, but also a professional artist. I think most programmers would really benefit by jumping into art for a while. It makes programming certain things make a lot more sense and it also helps bridge the programmer/artist rivalry, haha :) I know this is more ideal, and not so much practical for most folks.

Here are some links to some of my work (look for Nathan Warden in the credits)

World Builder (involved in about half of the shots)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (was involved in most shots)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (The third shot with Santa)
https://www.youtube.com/watch?v=biqBq3_Whqk

Here's a render of my Louie's building. If you watch World Builder you'll see some of the artwork that I ripped from it and put into the film.

And here's an unfinished render of a Terminator 1 style HK Tank smashing Stephen King's Christine. Both of those models are done by me, but I don't think anything else in the shot was.

And many more that I could name, but I think the point is made. :)

Well those are amazing stills- but again you are doing this to give yourself more authority. This is not helping to logically support the idea that Nodes are better than Event sheet :)

If you go with nodes, you will be like any other god damn 3d game engine out there that uses visual programming.

I think that this is not a great idea for a number of reasons.

-Recently Unreal made their engine free - its also multiplatform. It is a much more mature engine than BGE/Godot. So you are competing with them directly when copying their approach to visual programming.

-Nodes are way less screen efficient than a logic sheet. They are harder to read/follow.

-Scirra announced that construct3 will be multiplatform - the editor will work on windows, linux and mac.
However they are not open source.
https://www.construct3.com/

This created a wave of comments at the scirra community. A lot of the users want a number of things that godot can offer without the visual programming:
-Native exe files instead of html5 containers - for better performance
-support for 3d game development, using the event sheet style in construct to program it:
https://www.scirra.com/forum/construct-3_t90881

if they make a simple and understandable 3D editor like the 2D tool inside C2 i would totally use the heck of it

i tryied unity, blender, torque 3D, UDK, because they are the more advertised and the ones most of the so called famous devs use... and they share the same problems: they are not user friendly(at all) and if you never used a 3D game creation api before... well, you are 3Doomed (bad joke ikno)

the thing is, construct is very intuitive once you cover the basic and give you freedom to make complex 2D games, it gives you various paths to do the same result (not to mention that the event system MAKE SENSE to me); wich is the detail most of this other tools fail to cover or make it poorly

if they make a 3D engine with the same flow and feeling i have using C2; then why not give it a try?

They have a huge userbase at the moment (that loves the event sheet style for visual programming, but wants these features) and some of it is ready to make a jump to another engine. There is big potential here for Godot to get lots of new indie developers on board - the ones that prefer this to nodes- the ones that are not using Unreal engine- which is now free and way more mature than godot.

If you go for it instead of nodes, you will be the first engine that supports full 3d game development with that vis programming design. You will be tapping onto a new userbase, instead of competing with Unreal (free), Unity (free version available)

Well those are amazing stills- but again you are doing this to give yourself more authority.

The stills and links are not proof of my authority but of the people I've worked with and that I'm not just making it up :) This includes some of my good friends who worked on some films that you might have heard of like Avatar, King Kong, Serenity, and shows like Lost, Revolution, etc... And some of my other friends who have worked in the game industry for over 15 years. All of which prefer a node based workflow over a linear, sheet based workflow. I could probably get a quote from 3-4 of them telling you that they prefer node graphs over logic sheets if you'd like?

Recently Unreal made their engine free - its also multiplatform. It is a much more mature engine than BGE/Godot. So you are competing with them directly when copying their approach to visual programming.

The visual scripting workflow is the last thing people are going to be looking at when comparing Godot to those engines. The first thing they'll notice is that Unreal supports DirectX 12 and OpenGL 4 and that their demos and examples look stunning, then they'll start looking at the other things. The major thing that Godot has over those companies is that it's FLOSS software and that anyone who uses it is equally a full owner of the software.

Nodes are way less screen efficient than a logic sheet. They are harder to read/follow.

While it's obvious by your statement that you haven't used a good node based setup, if you're worried about things like screen efficiency then you shouldn't be using visual scripting anyway, you should be using the real scripting which is already available :) I gaurantee you that anything visual scripting can offer you in terms of screen space regular scripting can do it as well, like collapsing code regions.

If you go for it instead of nodes, you will be the first engine that supports full 3d game development with that vis programming design.

There's a reason why engines like Unreal who spend a lot of time, money and research into their customers' needs aren't going with that form of visual scripting and chose nodes instead.

My view about this is that it all depends on the approach intending to be
solved.

Action blocks like Game Maker is interesting, but I think it is more
designed towards a replacement of programming.

The approach of Unreal is more like a complement to programming so
designers can work in the game themselves and take work away from the
programmer. This is a lot more useful in teams (Artists and Game designers
can use it fine) and is definitely the approach I would like to add to
Godot because fo this.

Due to Godot architecture, it would also be very easy to add so I will give
it a shot in 1.2

On Tue, Mar 3, 2015 at 4:37 PM, Nathan [email protected] wrote:

Well those are amazing stills- but again you are doing this to give
yourself more authority.

The stills and links are not proof of my authority but of the people I've
worked with and that I'm not just making it up :) This includes some of my
good friends who worked on some films that you might have heard of like
Avatar, King Kong, Serenity, and shows like Lost, Revolution, etc... And
some of my other friends who have worked in the game industry for over 15
years. All of which prefer a node based workflow over a linear, sheet based
workflow. I could probably get a quote from 3-4 of them telling you that
they prefer node graphs over logic sheets if you'd like?

Recently Unreal made their engine free - its also multiplatform. It is a
much more mature engine than BGE/Godot. So you are competing with them
directly when copying their approach to visual programming.

The visual scripting workflow is the last thing people are going to be
looking at when comparing Godot to those engines. The first thing they'll
notice is that Unreal supports DirectX 12 and OpenGL 4 and that their demos
and examples look stunning, then they'll start looking at the other things.
The major thing that Godot has over those companies is that it's FLOSS
software and that anyone who uses it is equally a full owner of the
software.

Nodes are way less screen efficient than a logic sheet. They are harder to
read/follow.

While it's obvious by your statement that you haven't used a good node
based setup, if you're worried about things like screen efficiency then you
shouldn't be using visual scripting anyway, you should be using the real
scripting which is already available :) I gaurantee you that anything
visual scripting can offer you in terms of screen space regular scripting
can do it as well, like collapsing code regions.

If you go for it instead of nodes, you will be the first engine that
supports full 3d game development with that vis programming design.

There's a reason why engines like Unreal who spend a lot of time, money
and research into their customers' needs aren't going with that form of
visual scripting and chose nodes instead.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-77017857.

I gave Playmaker a good try and must say that I liked it - more than unreal's kismet/blueprints.

In playmaker nodes are sort of like containers in which you place actions. Some of the actions are the Checking a condition that can lead to another node.

Since you make the node containers yourself and can name them, the actions in them are executed in a predictable fashion (top to bottom) - it is something I can live with. :)

Also actions that you place inside a node are actually standard unity scripts with visual inputs. So people will be able to write their own scripts and add them as custom actions.

Please look into playmaker and implementing a node based system that is more akin to it, rather than Unreal.
It's advantage is ofcourse that we can do more with less nodes, they are easier to read and debug, and are more predictable.

Here is an introduction of how it works:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

It is very flexible and allows the user to easily add and share game functionality - easy to re-purpose .

Fascinating discussion. Just want to point out another type/form of visual scripting other than nodes and C2's event sheet but blocks of script that fit together like puzzle pieces. Used in 2d engine Stencyl http://www.stencyl.com/

based on MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_()_(block)

and in Unity I personally use, Blox http://www.plyoung.com/blox/

I'm personally not convinced with the scratch-like "visual" programming. I
think it's pretty much just like programming.
The way Unreal does this i think is friendly to game/level designers

On Sat, Mar 21, 2015 at 11:57 PM, todheil [email protected] wrote:

Fascinating discussion. Just want to point out another type/form of visual
scripting other than nodes but blocks of script that fit together like
puzzle pieces. Used in 2d engine Stencyl http://www.stencyl.com/
[image: stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
based on MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_()_(block)
[image: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
and in Unity I personally use, Blox http://www.plyoung.com/blox/
[image: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84508001.

_OkamStudio_

Good point. To me blocks are the middle way between code lines and flow charts.

I do not like the scratch/stencyl way of visual programming. Its layout is
visually harder to follow than construct2 blocks and even nodes. It is
literally putting together puzzle piecse and it suffers from the issue of
figuring out which piece fits where. They are not straightforward to put
together

On Sun, Mar 22, 2015 at 5:46 AM, todheil [email protected] wrote:

Good point. To me blocks are the middle way between code lines and flow
charts.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415.

ok, i will not read everything now, but just my 2 cents on this topic.

event based engines are created to make prototypes and small game projects
engines like godot are created to make all kind of projects

So they are two different things with two different aprochs, they are two
different tolls

to be honest, i can't use they well. (event based tolls)

To me the better approach is two parallel tolls.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected]:

I do not like the scratch/stencyl way of visual programming. Its layout is
visually harder to follow than construct2 blocks and even nodes. It is
literally putting together puzzle piecse and it suffers from the issue of
figuring out which piece fits where. They are not straightforward to put
together

On Sun, Mar 22, 2015 at 5:46 AM, todheil [email protected] wrote:

Good point. To me blocks are the middle way between code lines and flow
charts.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752.

David Aguiar de Aquino Paiva

the only thing that would be useful is the "behavior" system of unity,
basically it's a script that make something, so this in godot would
translate as the possibility to add more than one script per node.
Of course, i could create a node an just clone it, but a script would be a
resource and then would be just load it to a node and add a behaviour (for
example, a jump script)
In the editor we could see the exports categorized under the script name.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected]:

ok, i will not read everything now, but just my 2 cents on this topic.

event based engines are created to make prototypes and small game projects
engines like godot are created to make all kind of projects

So they are two different things with two different aprochs, they are two
different tolls

to be honest, i can't use they well.

To me the better approach is two parallel tolls.

2015-03-22 6:49 GMT-03:00 Todor Imreorov [email protected]:

I do not like the scratch/stencyl way of visual programming. Its layout is

visually harder to follow than construct2 blocks and even nodes. It is
literally putting together puzzle piecse and it suffers from the issue of
figuring out which piece fits where. They are not straightforward to put
together

On Sun, Mar 22, 2015 at 5:46 AM, todheil [email protected]
wrote:

Good point. To me blocks are the middle way between code lines and flow
charts.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415
.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752.

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

Hey guys! Nice discussion is here :) I would like to add something.

First thing: I'm art student but programming is my hobby. I know Java, Python and (my favourite) Golang. But before I learn how to code (about 3 years ago) I tried almost every single program that claims it allows to "create games without programming". All these claims are nonsense.

I tried (in no particular order): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE and some others I don't even remember. And my opinion is: You can make a game without _writing_ code but no without _programming_. Even if you are using event sheets or nodes you still need to understand _logic of programming_. You have to know what is conditional, event, variable, string etc. So it's impossible to create game without programming. All that visual methods of coding are just different way to express logic that is in traditional programming languages. This whole argument may seem obvious but I assure you, I wasn't obvious for me at the beginning of my adventure with programming.

From this it follows my next consideration:

The best and most intuitive visual programming language I had found before I learned how to code is Scrach/Stencyl puzzle/blocks way. Here's why:

• this solution is closest to the traditional programming. In fact it is just something like syntax sugar for underlying code (basically it's how Stencyl works) For me it's cleaner and easier to follow or create something that looks like colourful fancy code than graphs of nodes or cluttered event sheets that you can't put into nice structures like functions. For me _this_ is a mess
  Remember that this is just my opinion

*I think Scrach/Stencyl blocks are most visual and easy to follow method. They use colour extensively (and visual-minded people like colours) It's easy to remember that yellow = conditionals and loops, green = maths, blue = variables etc. Also It's looks like real code (in contrast to nodes) but friendlier.

Finally I don't think visual programming should be priority in anytime soon. There is plenty of more important things to do (whole roadmap + documentation) and I suppose implementing any of these system wouldn't be quick and easy. Godot is IMHO really easy to work as it is now. It contains lot of tools that can be used by artist in cooperation with the game devs (visual shader editor, animation editor, tilemap node).

BTW. I'd like to take this opportunity and thanks to all Godot creators and contributors. You did an excellent job :+1:

BTW2. I'm sorry for my English. I'm doing my best but I'm still making silly mistakes :cry:

be it construct2 or blox - either are nicer to me than those node graphs.

If the system uses nodes only as containers for actions (as states) - the way it is in Playmaker, then I will be ok with it.

The nice thing about both blox and construct2 is that the editor shows you all the available conditions and actions. It separates them for you and puts them in categories. That is a dramatic change in presentation that allows a non coder to do a lot with the engine straight away - without needing to know the names of the commands to do things.

if you use nodes for visual programming - the biggest challenge would be communicating to the user in what order events are being executed. In Unity - both playmaker and blox do that very cleanly.

In playmaker by stacking actions inside node containers (state - contains actions). In blox - where you have states that contain functions.

They give complete access to most of unity's features. This is really nice to non programmers.
blox has been further developed into "plygame" - another unity addon that has blox+ some custom made scripts that blox can access in order to create an entire rpg hack and slash style game.

Blox in unity is the same as Skrach/Stencyl blocks. There seem to be plenty of people here that like that style of programming :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Hope godot devs give it a try.
Btw the Skratch (https://scratch.mit.edu/) technology is open source! And others have been adopting it - not only stencyl. Google has been very interested in it too:
https://developers.google.com/blockly/

proposal - Why not try having the best of both worlds! Nodes for a state machine - blox/skratch/stencyl for expressions.
In an ideal world you would have nodes being used as State containers - like in Playmaker. But the state container's would have blox/stencyl/skratch like lego system that allows the user to easily set up the logic - no need to learn to write expressions that way - they are just ready to be dragged and dropped.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

One of the developers of iCanScript said this about their VS asset:

The technical advancement of iCS2 decouples it from being a Unity only product significantly increasing the market opportunities. The end vision is that iCS2 will be a development aid that can be used to create script for other game engines as well as standard Windows/OSX/iOS/Android applications.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

what a node mess iCanScript is!

In any case it's worth trying before I judge it. Maybe someone can get in
touch with it's developer?
If godot had a market place with opportunities for profit - like the one
unity does - maybe that would attract unity developers to make assets for
godot as well.

On Sat, May 23, 2015 at 4:24 PM, todheil [email protected] wrote:

One of the developers of iCanScript said this about their VS asset:

The technical advancement of iCS2 decouples it from being a Unity only
product significantly >increasing the market opportunities. The end vision
is that iCS2 will be a development aid that >can be used to create script
for other game engines as well as standard >Windows/OSX/iOS/Android
applications.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post-2124402

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104895405.

I think construct 2's event sheet are really easy to understand and program in.

As an artist who spends most of the time creating graphic for my living, learning a new language is very hard and time consuming. People say you can learn it in a few months but when you only have a 2 hours a day for yourself you can either choose to learn from scratch or create using a simple language. Also, being a visual person visual scripting makes more sense.

I've done programming in school and I can read and understand code easily but writing it takes time. I'm also trying to learn python which is easier but it will still take months to create something with it.

Construct 2's approach seems simple. For me it looks like:

1 Event: Action;

2 Event: Action;
: Action;

Its basically programming but in a very easily comprehensible way. If they had used just language instead of block I wouldn't have minded. Using this pattern its easy to create a logic for me.

Using nodes can go out of hand very quickly as things start to spread and you spend more time to look for the nodes then to actually code (As I understood from unity and playmaker).

So, If you are trying to implement a visual scripting please give a very serious thought to constructs event system.

You can also create the visual scripting system as an downloadable extension for people like us so those who prefer programming don't have to download that extra payload.

Great job with Godot looking forward to create great games on it.

My issue with Construct's approach is that it feels like programming, it
doesn't seem to be that much different
From a team perspective, i like Unreal's blueprint approach more because
it's more friendly to designers who have no idea about programming

On Sun, May 24, 2015 at 3:58 AM, whoisda [email protected] wrote:

I think construct 2's event sheet are really easy to understand and
program in.

As an artist who spends most of the time creating graphic for my living,
learning a new language is very hard and time consuming. People say you can
learn it in a few months but when you only have a 2 hours a day for
yourself you can either choose to learn from scratch or create using a
simple language. Also, being a visual person visual scripting makes more
sense.

I've done programming in school and I can read and understand code easily
but writing it takes time. I'm also trying to learn python which is easier
but it will still take months to create something with it.

Construct 2's approach seems simple. For me it looks like:

1 Event: Action;

2 Event: Action;
: Action;

Its basically programming but in a very easily comprehensible way. If they
had used just language instead of block I wouldn't have minded. Using this
pattern its easy to create a logic for me.

Using nodes can go out of hand very quickly as things start to spread and
you spend more time to look for the nodes then to actually code (As I
understood from unity and playmaker).

So, If you are trying to implement a visual scripting please give a very
serious thought to constructs event system.

You can also create the visual scripting system as an downloadable
extension for people like us so those who prefer programming don't have to
download that extra payload.

Great job with Godot looking forward to create great games on it.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159.

But your is the perspective of a programmer - someone who already knows how
to code.
It is better to look at statistics in this case - the number of
non-programmer users that construct2 has over the other visual programming
editors should speak for itself.

its also worth looking into the variety of games created in one style of visual programming over another.

Unreal does have a huge number of projects done in kismet indeed - but it is a much older engine than construct2 and a lot of them are just first person shooters

On Sun, May 24, 2015 at 10:15 AM, Juan Linietsky [email protected]
wrote:

My issue with Construct's approach is that it feels like programming, it
doesn't seem to be that much different
From a team perspective, i like Unreal's blueprint approach more because
it's more friendly to designers who have no idea about programming

On Sun, May 24, 2015 at 3:58 AM, whoisda [email protected] wrote:

I think construct 2's event sheet are really easy to understand and
program in.

As an artist who spends most of the time creating graphic for my living,
learning a new language is very hard and time consuming. People say you
can
learn it in a few months but when you only have a 2 hours a day for
yourself you can either choose to learn from scratch or create using a
simple language. Also, being a visual person visual scripting makes more
sense.

I've done programming in school and I can read and understand code easily
but writing it takes time. I'm also trying to learn python which is
easier
but it will still take months to create something with it.

Construct 2's approach seems simple. For me it looks like:

1 Event: Action;

2 Event: Action;
: Action;

Its basically programming but in a very easily comprehensible way. If
they
had used just language instead of block I wouldn't have minded. Using
this
pattern its easy to create a logic for me.

Using nodes can go out of hand very quickly as things start to spread and
you spend more time to look for the nodes then to actually code (As I
understood from unity and playmaker).

So, If you are trying to implement a visual scripting please give a very
serious thought to constructs event system.

You can also create the visual scripting system as an downloadable
extension for people like us so those who prefer programming don't have
to
download that extra payload.

Great job with Godot looking forward to create great games on it.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159
.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669.

Construct2's approach to programming is very similar to the one in
Clickteam fusion, which also has many users. The ease to it comes from a
number of things, even though it is similar to programming:

• Having all possible CONDITIONS listed and available to the user to select
  to add by clicking/dragging in plain english language - this is invaluable
  because they dont have to learn the magic words. They can just drag and
  drop them.
• Having all possible ACTIONS listed and available to the user to select to
  add by clicking/dragging in plain english language - this is invaluable
  because they dont have to learn the magic words. They can just drag and
  drop them.
• same goes when doing any sort of expressions in both setting up and
  action or a condition. When you write expressions, the editor is aiding you
  with an easy drop down list of things to get from existing objects in the
  scene. You do not have to learn how to get to those properties as they
  already are available within a couple of clicks.

Perhaps the best aspect of it is that it teaches non-programmers about
programming theory without the learning curve of learning a new programming
language.

On Sun, May 24, 2015 at 10:17 AM, Todor Imreorov [email protected]
wrote:

But your is the perspective of a programmer - someone who already knows
how to code.
It is better to look at statistics in this case - the number of
non-programmer users that construct2 has over the other visual programming
editors should speak for itself.

On Sun, May 24, 2015 at 10:15 AM, Juan Linietsky <[email protected]

wrote:

My issue with Construct's approach is that it feels like programming, it
doesn't seem to be that much different
From a team perspective, i like Unreal's blueprint approach more because
it's more friendly to designers who have no idea about programming

On Sun, May 24, 2015 at 3:58 AM, whoisda [email protected]
wrote:

I think construct 2's event sheet are really easy to understand and
program in.

As an artist who spends most of the time creating graphic for my living,
learning a new language is very hard and time consuming. People say you
can
learn it in a few months but when you only have a 2 hours a day for
yourself you can either choose to learn from scratch or create using a
simple language. Also, being a visual person visual scripting makes more
sense.

I've done programming in school and I can read and understand code
easily
but writing it takes time. I'm also trying to learn python which is
easier
but it will still take months to create something with it.

Construct 2's approach seems simple. For me it looks like:

1 Event: Action;

2 Event: Action;
: Action;

Its basically programming but in a very easily comprehensible way. If
they
had used just language instead of block I wouldn't have minded. Using
this
pattern its easy to create a logic for me.

Using nodes can go out of hand very quickly as things start to spread
and
you spend more time to look for the nodes then to actually code (As I
understood from unity and playmaker).

So, If you are trying to implement a visual scripting please give a very
serious thought to constructs event system.

You can also create the visual scripting system as an downloadable
extension for people like us so those who prefer programming don't have
to
download that extra payload.

Great job with Godot looking forward to create great games on it.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159
.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669.

Also look at it from the perspective of a designer who would like to learn to code complex logic and eventually get confident enough to learn to code. I see where you are coming from as you see the system will be used by a team of designers and programmers. I personally would like to use Godot as a single user and not in a team with a programmer like a lot of indie game developers. The event system is forgiving and feels more organised using groups when you have 1000+ events.

Other than this I've no problem with node system and if godot manages to create a system that is better than the current I'll use the shit out of it.

Also, If possible do create a search feature to find code blocks/nodes easily.

Note that Event sheets in construct2/clickteam eliminate the need to learn
syntax- so the user does not have to know where to put things - that is
very obvious. Conditions on the left, actions on the right. The order of
event execution is very obvious too.
Lego pieces in scratch/stencyl/unity blox are not as obvious, but are still
way better than the nodes nightmare presented in "iCanScript". Did you look
at their video tutorial. It is a super convoluted visual programming design
with a pretty steep learning curve. I think that even if you give it to a
programmer they will have trouble figuring it out

On Sun, May 24, 2015 at 10:33 AM, whoisda [email protected] wrote:

Also look at it from the perspective of a designer who would like to learn
to code complex logic and eventually get confident enough to learn to code.
I see where you are coming from as you see the system will be used by a
team of designers and programmers. I personally would like to use Godot as
a single user and not in a team with a programmer like a lot of indie game
developers. The event system is forgiving and feels more organised using
groups when you have 1000+ events.

Other than this I've no problem with node system and if godot manages to
create a system that is better than the current I'll use the shit out of
it.

Also, If possible do create a search feature to find code blocks/nodes
easily.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595.

They are not even selling "icanscript" at the unity asset store any more.
Look at sales figures there - which one of the available visual programming
systems is in use the most - and has complete projects.

I will just leave you with this video:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
It has 167 games made with clickteam fusion - by people who have no
programming experience.

Also look at successful kickstarter games made in fusion.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

need I also mention Five Nights at Freddy's (made in clickteam fusion):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
that game is a best seller. Here are some figures for you:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

The idea of a visual programming framework should be to empower an artist to create a game without needing a programmer - in the process learn a little bit about programming.

If you make one where the programmer is still required - then you haven't really made a visual programming framework - you have just created a state machine that programmers can set up for designers to use - for simple things in the game - but not for the core logic of the game. So you are not really going to create something that is as good and complete as the other visual programming tools mentioned here. You are not empowering the artists to set up logic and inviting them to learn basic concepts of programming. You are keeping them dependent on programmers and in the dark of those concepts.

On Sun, May 24, 2015 at 10:42 AM, Todor Imreorov [email protected]
wrote:

Note that Event sheets in construct2/clickteam eliminate the need to learn
syntax- so the user does not have to know where to put things - that is
very obvious. Conditions on the left, actions on the right. The order of
event execution is very obvious too.
Lego pieces in scratch/stencyl/unity blox are not as obvious, but are
still way better than the nodes nightmare presented in "iCanScript". Did
you look at their video tutorial. It is a super convoluted visual
programming design with a pretty steep learning curve. I think that even if
you give it to a programmer they will have trouble figuring it out

On Sun, May 24, 2015 at 10:33 AM, whoisda [email protected]
wrote:

Also look at it from the perspective of a designer who would like to
learn to code complex logic and eventually get confident enough to learn to
code. I see where you are coming from as you see the system will be used by
a team of designers and programmers. I personally would like to use Godot
as a single user and not in a team with a programmer like a lot of indie
game developers. The event system is forgiving and feels more organised
using groups when you have 1000+ events.

Other than this I've no problem with node system and if godot manages to
create a system that is better than the current I'll use the shit out of
it.

Also, If possible do create a search feature to find code blocks/nodes
easily.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595.

I don't think it's wise to push you into using a system that works excellently for another game engine if that's not the direction you would want to take.

On the same note I would like to see some more intuitive way that a visual scripting is implemented. Not using the messy nodes or time taking blocks(Android app creator) or too programming looking event system(which I prefer over everything else). Something that takes the best of all of them.

Maybe consult a usability designer to clear some paths and look at some numbers.

In the end it would be great to see a method unique to Godot which makes Godot a great engine which enables both a one person beginner design his first game in a week and a development team collaborating together to create a AAA game.

I'd be glad to see a system that would help me create wonderful games without changing engines and learning languages ever' so often.

Cheers.

I dont mind the nodes if they are done like the ones in playmaker - as
action containers (states).
Nodes there arent actually used to set actions or conditions.

If you however make them like "iCanScript", you have a complete mess.

1. it's hard to tell in which order events execute
2. Hard to figure out which node can be connected to which node
3. it takes many nodes and steps to set up a single action than it does to
   drag and drop it and set up an expression in it (construct2/clickteam style
4. where you get aided with the syntax - that is a great way to introduce
   somebody to programming without requiring them to read tons of
   documentation - everything is there for them in the drop down menu of the
   object).

On Sun, May 24, 2015 at 11:20 AM, whoisda [email protected] wrote:

I don't think it's wise to push you into using a system that works
excellently for another game engine if that's not the direction you would
want to take.

On the same note I would like to see some more intuitive way that a visual
scripting is implemented. Not using the messy nodes or time taking
blocks(Android app creator) or too programming looking event system(which I
prefer over everything else). Something that takes the best of all of them.

Maybe consult a usability designer to clear some paths and look at some
numbers.

In the end it would be great to see a method unique to Godot which makes
Godot a great engine which enables both a one person beginner design his
first game in a week and a development team collaborating together to
create a AAA game.

I'd be glad to see a system that would help me create wonderful games
without changing engines and learning languages ever' so often.

Cheers.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-104990083.

I vote for @whoisda in regards to something being innovated for/in Godot. However there seems to be three Visual Scripting schools: 1) nodes, 2) event sheets, 3) blocks. Of these three nodes seem to be leading the field in 3d environments. Speaking of which I've read somewhere an idea suggesting scripting/programing break out of a linear (text, blocks, event sheet), or horizontal (nodes) format and program in 3D using structures. Not sure how that would work but sounds fascinating.

The mentioned visual scripting schools have been tested in practice and
already have users. I suggest on combining the designs of Playmaker and
blox in unity.

Nodes for creating a state machine.
Blocks or event sheets for creating the actions inside each node (state).

On Sun, May 24, 2015 at 1:56 PM, todheil [email protected] wrote:

I vote for @whoisda https://github.com/whoisda in regards to something
being innovated for/in Godot. However there seems to be three Visual
Scripting schools: 1) nodes, 2) event sheets, 3) blocks. Of these three
nodes seem to be leading the field in 3d environments. Speaking of which
I've read somewhere an idea suggesting scripting/programing break out of a
linear (text, blocks, event sheet), or horizontal (nodes) format and
program in 3D using structures. Not sure how that would work but sounds
fascinating.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105001411.

It would be great if we can use nodes and events together. Nodes can the states which if following a simple logic can be plugged into other nodes or can be containers for scripts/ blocks/ event sheets this way we won't have very large nodes and can also collaborate as a team. But this might be too much for the developer. Still the idea seems to be very neat.

It is kind of that way in Playmaker - people seem to like it a lot.
A lot of people here seem to also like stencyl as well - the technology is
open source and available at scratch github website. I shared it in a
previous post.

I would personally love to see ANY first steps in visual programming
direction. Even if the developer makes a state machine that works with gd
scripts - that would be an amazing beginning that even advanced programmers
would appreciate.

Then maybe after that we can have something visual like stencyl or
construct2 - that is like code - but much easier than code - inside the
states.

So actually these are two feature requests!

• One for a state machine (nodes)
• another for a visual scripting framework that replaces learning gdscript
  with drag and drop coding. But also is a nice step towards learning
  gdscript.

In the end the main developer knows whats best for godot's design.

On Tue, May 26, 2015 at 11:43 AM, whoisda [email protected] wrote:

It would be great if we can use nodes and events together. Nodes can the
states which if following a simple logic can be plugged into other nodes or
can be containers for scripts/ blocks/ event sheets this way we won't have
very large nodes and can also collaborate as a team. But this might be too
much for the developer. Still the idea seems to be very neat.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984.

i will check styencyl soon because i'm not familiar with it.
at this point from everything I saw/read, I can gather that:

1) Blueprint: Is great for game/level designers, but not that good for
visual programming
2) Stencyl: Is much better for visual programming, but unusable for
game/level designers

My experience making game was always on teams, so I can see 1) as being
very useful, but that also makes me biased. Are there that many people
interested in visual programming like in Stencyl?

On Tue, May 26, 2015 at 6:10 AM, Todor Imreorov [email protected]
wrote:

It is kind of that way in Playmaker - people seem to like it a lot.
A lot of people here seem to also like stencyl as well - the technology is
open source and available at scratch github website. I shared it in a
previous post.

I would personally love to see ANY first steps in visual programming
direction. Even if the developer makes a state machine that works with gd
scripts - that would be an amazing beginning that even advanced programmers
would appreciate.

Then maybe after that we can have something visual like stencyl or
construct2 - that is like code - but much easier than code - inside the
states.

So actually these are two feature requests!

• One for a state machine (nodes)
• another for a visual scripting framework that replaces learning gdscript
  with drag and drop coding. But also is a nice step towards learning
  gdscript.

In the end the main developer knows whats best for godot's design.

On Tue, May 26, 2015 at 11:43 AM, whoisda [email protected]
wrote:

It would be great if we can use nodes and events together. Nodes can the
states which if following a simple logic can be plugged into other nodes
or
can be containers for scripts/ blocks/ event sheets this way we won't
have
very large nodes and can also collaborate as a team. But this might be
too
much for the developer. Still the idea seems to be very neat.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984
.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105458142.

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

Is this a canonical example of what stencyl "code" looks like? If yes, then it seems like a horrible idea: it looks like a standard coding in visual wrappers for kindergarten. Come on, python is already easy enough for my wife to read it, so why not making an effort to learn the basics?

If you talk visual programming, then what Godot already has is much better - shader graphs or animation graphs: code wrapped up in visual nodes.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - another example of visual node-based programming (Sidefx Houdini, or XSI). It is mature and does not look like a kids toy, also reminds me of Godot nodes.

I liked the construct2 approach, but after looking more into scratch - it seems like a better choice for a number of reasons:

• The programming design seems to be more popular than construct2's
• It has already been established as a tool to help teach people a programming language
• It is open source and others have re-purposed it for their engine in the past

Stencyl developers adopted the open source "scratch" technology. It is not their design.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_(programming_language)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Examples of Scratch being used by other game engines targetted at non-programmers:

• Stencyl (most popular one) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• google blockly ( https://developers.google.com/blockly/ )
• The closest to Godot is Unity's "Blox" visual programming asset:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Instead of Lua, it generates C#.
  it's full documentation is here:
  http://www.plyoung.com/blox/
  and is sold here: https://www.assetstore.unity3d.com/en/#!/content/12859

It may seem like a horrible idea to experienced programmers, but it is the best way to teach non programmers how to write code or to simply empower them to program without knowing the magic words or syntax. Scratch makes them all available to drag and drop - forcing a correct structure with visual clues. Please watch the "Unity Blox" videos playlist I posted to see it in action. More than anything else, it has been proven in practice over and over again. It looks like the safest bet.

I agree with @reduz on his points that one is good at level design and the other at visual scripting and am no longer arguing to use one over the other.

Using both seems like the best approach. If not Unity blox, even if you look at Playmaker, you will see that nodes are really containers there- where actions can be stacked - very similarly to stencyl. You drag and drop them from a list!

"but it is the best way to teach non programmers how to write code or to simply empower them to program without knowing the magic words"

Then I don't understand what audience is this targeting. Is Godot aiming to compete with big-boys on the market (Unreal Engine, Unity, etc.) or teach kids programming/making games like Scratch does (https://scratch.mit.edu/)?

I know what nodes are (input -> function with params -> output), I disagree with the presentation.

Stencyl and Playmaker might be great at teaching kids how to code, but they have been used successfully by non-programmers (both studios and indie) to make successful games - sold on different platforms.
If you class Unity as the big boys, then you should know that big boys also do visual programming.
http://www.hutonggames.com/showcase.html

I think godot has a lot of features in place to be used by the big boys. A few features enabling smaller/indies could help with the faster adoption of the engine. And the open source nature and leanent licensing is very lucrative for starters.

@blurymind
I do _not_ argue against visual programming. I'd say Godot already has what it needs (ShaderGraphs): same visual approach could be extended to state-machine logic programming, or general programming. What I argue against is against adopting yet another visual paradigm (~scratch) which does not scare kids away.

as noted before it is not just for kids. But if even kids can understand and use it - then I think that is a good thing. Not something to be ashamed of.

The biggest point that I want to make here is that:

• the order of actions execution should be clear! Doing all logic with nodes can get very messy very quickly. So nodes should be used for states imo.
• Playmaker developers very cleverly anticipated that issue and that is why they have made it so nodes are action containers in which - very similarly to Stencyl- you drag and drop available Actions from a list:
  
  and stack events that way

What you end up is a very clean and efficient node set up!

I suggest that Godot devs give playmaker a try also.
Replacing the Event stack with Stencyl logic would make godot's approach to it much more flexible/powerful!.

It doesnt have to be only via a stencyl approach. I think you can enable experienced programmers to attach gd scripts to nodes. Having the option to use a stencyl approach to create gdscripts would be invaluable imo. It will invite many new users to the godot community.

@blurymind
Ok, but that's something different. Easy to use does not mean it should look like it's meant for kids.
Order of the execution and assisted filtering of suitable inputs/outputs for a given node are common problems for node-based workflows. Different software solves it differently.

You have to ask yourself - Do you want more non-programmers to use Godot? Do you want to make it possible for people who have no experience with gdscript to make something fun?

If the answer is yes - then the best way to do it is by giving them a visual scripting approach.
I am not suggesting to make nodes look like something made for kids.
What I am suggesting is to split this into two projects!

• Nodes used as a state machine -like in Playmaker! Programmers can name each node and attach gdscripts to it - with input and output they set up. So this is not for kids at all. In fact, this is a much more flexible approach for programmers that is much less messy.
• A drag and drop event sheet or blocks interface as an alternative way to generate a GDscript. So instead of writing a GdScript to attach to a node, non programmers can just stack actions from a list of all available events in godot - much like Playmaker. To take it one step further and innovate - instead of simply stacking actions, it would be even better to use Stencyl like blocks.

This way you have something that is useful to both programmers and non-programmers. They can both use the state machine (nodes) and non-programmers dont have to learn gdscript right away and use gdBlocks instead to generate a gdscript for a node (again - like in Playmaker).

@blurymind
I like that better. Also it is consistent with Shader node-graph vs Shader-text that is in Godot already.

SideFX Houdini has something called VEX (https://goo.gl/TMWNKk) ("vector expression" a c-like language that is meant for vector algebra). It is somewhat synonymous to gdScript. Also it has something called "VOPs" (http://goo.gl/Qpn2OE) (Vex Operators) - essentially visual wrappers of a subset of VEX, which looks very similar to LeadWerks node-graph image that you referenced above. In fact, VOPs can be turned into the text-script, if necessary (but not the other way around).

The co-existence of the 2 is quite natural and it does allow, even non-programmers, to create very messy and inefficient code ;)

I personally like the Blueprint approach because it's very game designer
like, but I insist that I might be biased.

I downloaded Stencyl two hours ago and played it with it. I might be
mistaken, but I think Stencyl is a good tool to learn because not only the
programming part is simplified but the engine part too. The combination is
good because it's a simple programming approach for a simple game engine.

But Godot is not a simple game engine (At least compared to Stencyl) so I
don't think simplified programming would be that useful. Stencyl relies on
a lot of harcoded game logic stuff that will simply not be available in
Godot, and trying to make it available will contradict with Godot goal of
being a very general purpose game engine.

The nodes and graph approach is more interesting in my opinion because It's
a lower level and more flexible way of doing things.

On Tue, May 26, 2015 at 11:29 AM, Vladimir Lopatin <[email protected]

wrote:

@blurymind https://github.com/blurymind
I like that better. Also it is consistent with Shader node-graph vs
Shader-text that is in Godot already.

SideFX Houdini has something cold VEX (https://goo.gl/TMWNKk) ("vector
expression" a c-like language that is meant for vector algebra). It is
somewhat synonymous to gdScript. Also it has something called "VOPs" (
http://goo.gl/Qpn2OE) (Vex Operators) - essentially visual wrappers of a
subset of VEX, which look very similar to LeadWerks node-graph that you
referenced above. In fact, VOPs can be turned into the script, if necessary
(but not the other way around).

The co-existence of the 2 is quite natural and it does allow, even
non-programmers, to create very messy and inefficient code ;)

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105543845.

What about action stacking in Playmaker and blox in Unity? Unity is not a very simple engine.

I think stencyl is not a very good example. It is better to look for examples in the unity asset store.

i tried to understand playmaker but failed, how is it supposed to work?

On Tue, May 26, 2015 at 12:16 PM, Todor Imreorov [email protected]
wrote:

What about action stacking in Playmaker and blox in Unity? Unity is not a
very simple engine.

I think stencyl is not a very good example. It is better to look for
examples in the unity asset store.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760.

checked the tutorial of playmaker, but it seems to be similar to stencyl in
the sense that it comes with a zillion predefined behaviors

On Tue, May 26, 2015 at 12:19 PM, Juan Linietsky [email protected]
wrote:

i tried to understand playmaker but failed, how is it supposed to work?

On Tue, May 26, 2015 at 12:16 PM, Todor Imreorov <[email protected]

wrote:

What about action stacking in Playmaker and blox in Unity? Unity is not a
very simple engine.

I think stencyl is not a very good example. It is better to look for
examples in the unity asset store.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760
.

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777.

_OkamStudio_

The closest in Unity to U4 blueprints is uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

People seem to prefer Playmaker over uscript- as it is easier to understand logic that has been set up. As you can see from screenshots- it gets very messy even for simple logic.

@reduz @okamstudio here is a playlist on playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
I think you should actually use it for a little bit. You can do predefined behaviours and scripts, but playmaker also allows you to access the engine's core features and make such behaviours from scratch yourself.

Yes, playmaker is a state machine and unity happens to come with a lot of predefined behaviors.
Godot also has them - they are built into the engine.
I still believe that you can actually create a script/behaviour from scratch by using unity's stencyl clone blox.

I think at last you need a programmer to make a proper game and this idea
is great that game designer make the game themselves but I think it is lots
of work that does not come handy in many cases . but if we have more
feature for editor it self like the platformer designer that someone else
mentioned in another issue or other useful things to make ui easy
friendlier .
On May 26, 2015 7:52 PM, "Okam Studio" [email protected] wrote:

checked the tutorial of playmaker, but it seems to be similar to stencyl in
the sense that it comes with a zillion predefined behaviors

On Tue, May 26, 2015 at 12:19 PM, Juan Linietsky <[email protected]

wrote:

i tried to understand playmaker but failed, how is it supposed to work?

On Tue, May 26, 2015 at 12:16 PM, Todor Imreorov <
[email protected]

wrote:

What about action stacking in Playmaker and blox in Unity? Unity is
not a
very simple engine.

I think stencyl is not a very good example. It is better to look for
examples in the unity asset store.

—
Reply to this email directly or view it on GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760
.

—
Reply to this email directly or view it on GitHub
<https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777
.

_OkamStudio_

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105565084.

here is a review at unity asset store for uScript:

Good tool, but hard to learn if a non-programmer... responses to help requests on the forums are very slow or dont exist at all..

Whatever ends up being in Godot, I think - if possible - it'd be a good idea to allow one-way conversion to GDScript. This would allow quickly setting up things visually, by designers and artists and such, and then allow the coders on the team to further tweak it and rework it without having to use the pointy-clicky.

@adolson That would be a much desired feature :)

this could be done, and could also be done with the visual shader editor
(which in fact, does generate shader code)
but i think the generated shader code will not be as readable as you might
expect :P

On Tue, May 26, 2015 at 6:33 PM, Nathan [email protected] wrote:

@adolson https://github.com/adolson That would be a much desired
feature :)

—
Reply to this email directly or view it on GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment-105670945.

@reduz Some metadata is expected.
Here's an example of conversion from VOPs -> VEX conversion, as indicated above:
:
And here's the full listing of the code, which, otherwise, in pure VEX looks like this:
@P += vector({0,1,0}); // take Position and add vector (0,1,0)

As you can see the amount of metadata is significant, but it is not difficult to separate the 2, possibly parse it semi or fully-automatic.

@reduz That's true. I wasn't really thinking about that. It will probably not be the kind of code most programmers would want to spend their time in. I could see labels becoming variable names and such, but I can't see too much else to mitigate the problem.

While I can't speak for everyone, if I see a mess of code I may take a few bits and pieces from it, but I usually feel inclined to just rewrite it. So, if that's the case this wouldn't be worth it for me personally.

You guys really went through the gamut of options. I have used Construct 2 and while it is neat, you can never touch any code to refine it and the options were rather limited. The tilemap update basically got rid of prefabs & therefore instancing too. The one I really liked was PlayMaker for Unity.

Something about it was very easy to keep grasp of your scope and what you needed to do. This is a really appealing factor, the whole reason I like to use visual scriptors is because of exactly this. I lose sight of what I was doing or what I need to do in textual code, but seeing how everything 'connects' has the absolute most benefit for me. NateWardog posted an example in a screenshot much earlier & blurrymind much more recently.

I say reduz, you go for it. For now, if you're going to bother, I would shoot for 1.3 or later and even then mostly focus on the frontend side of it. Then when it's ready later down the road focus on getting it to output readable code like Blueprint can, which I imagine would be very challenging. Please don't underestimate this one!

Subscribing. I'm very interested in this as well! I know some scripting and don't really mind using it... but I so prefer connecting nodes over that when possible! Something like the logic bricks in Blender Game Engine, which act as visual shortcuts for Godot script functions as an alternative to writing them by hand... that would be a lovely feature and one I am actively waiting for.

visual scripting really attracts a lot of creative people or people who don't wanna learn a new scripting language like gd script. i was looking at game maker is so damn popular and single most given reason is the visual scripting mechanic.

Visual scripting is tedious, stupid and hard to use.
I never see a good implementation. Visual people should draw graphics. I
know many people just can't write,
but this won't do them any good. Non-programming person doesn't mean
illiterate person.

I don't know of any visual logic building tool, which was main system for
game logic in any engine.
The visual way sucks in many aspects. Visual people usually consider
programming as "tech stuff"
meaning something in real of plumbing and hard work, and want to be above
it. This attitude
is usually because of some intellectual issues. I don't think this people
can be target audience
basically they limit their creativity.

On Thu, Apr 14, 2016 at 8:33 AM, Rémi Verschelde [email protected]
wrote:

Edit: I see you changed "RPG Maker" for "Game Maker", now it makes more
sense :p Removing my post.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209770726

I don't want to, but I have to say it, but that is a very narrow view of visual scripting tools, Sergey. As for games that have been fully made with them, some engines have completely opted out for them such as Construct, so you won't see any game out of that engine made with regular scripting. Other (more sane, imo) engine have plugins such as Unity and UE4. I personally really liked using both uscript & PlayMaker in Unity alongside my regular code because while some things are easier to code, many are easier to script out visually, particularly state machines because with a visual scripter like PM it gives you a lot of feedback with breakpointsw it's just so much easier to look at the project from a more scoped out view.

The real thing about visual scripting in general, it is futile attempt to
make programming accessible to non-programmers, which is totally wrong
approach.
Visual programming is harder that regular text programming. To make it
easier you have to write many blocks for each case in life in traditional
way and
let these people use them. These proven to be less effective that asking a
good programer to write code. The telling "programming is not a profession,
everyone can do it" is wrong. All attempts to programming without
programming is a waste.

As for state machine - I was thingking about implementing this some time
ago, but that won't help high visuals program.
This can be easily done for your game using tool script and node editor,
which is powerful tool, many people use it for game tools, like
game dialogue editors.

On Thu, Apr 14, 2016 at 9:09 AM, Aaron M [email protected] wrote:

I don't want to have to say it, but that is a very narrow view of visual
scripting tools, Sergey. As for games that have been fully made with them,
some engines have completely opted out for them such as Construct, so you
won't see any game out of that engine made with regular scripting. Other
(more sane, imo) engine have plugins such as Unity and UE4. I personally
really liked using both uscript & PlayMaker in Unity alongside my regular
code because while some things are easier to code, many are easier to
script out visually, particularly state machines because with a visual
scripter like PM it gives you a lot of feedback with breakpointsw it's just
so much easier to look at the project from a more scoped out view.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209776732

Slapin, you are right. But you forget that visual programming or programming blocks have a very low failure rate. It's because of the limitations.
It's basically the same when you take a very limited scripting language. You can't do a lot of mistakes.

I think this should be the aim to achieve, not the question whether Visual- or Text-Scripting!

If you wanna make programming better, make the tools better. Codehighlighting, Codecompletion, Codevalidation, Codetemplates, aso. Make the debugger better and make Liveprogramming.
I always searched for an stable Liveprogramming environment, but until now i didn't find it!

If you really wanna make Visual Scripting, make it like the Stingray Engine. You can create CodeBlocks in Visual and generate TextCode you can later modify, or write TextCode you can later use as Visual Blocks.

I wouldn't say it's futile, but I would say that we're talking about 2
completely different products.

If you're running a studio, and you're making games with say 20-80 people,
you're spending 6 figures in production costs every month, and you need an
engine to make your games, you want a certain product. In that case, you
don't care at all about the visual scripting tools, you care about other
things, like how productive your team will be with the tools of the engine
(since if they go over schedule for one month, you're out ~$100k). Those
teams have programmers, and they'll be a lot more productive writing code
than using some visual tool (look up Vicious Engine for an example of that)

On the other hand if you have a cool idea and don't really know how to
write code, you want another product, something to do a fast prototype that
you can show around and eventually give to programmers to make the actual
game.

It's 2 different products, and if we argue about which one is more worth
having, we have to acknowledge that. I would say that the visual scripting
tool doesn't really scale up to more than 1 person making a prototype. As
soon as you want to make a full game, or as soon as your team grows to 2-3
people, you already need a real programming language. So I like the first
example more as an overall goal (unless you want a 3rd product, which is
"the engine that you can use to make a full indie game that makes millions
without writing any code". That doesn't exist).

But we can have both, and I wouldn't discourage either one. A visual
scripting tool would help us in the long run, by creating beginner users
that will eventually work on the industry and be in positions to decide to
use godot for a real game, and that's good. Also, the CTO of Square Enix
asked us if the engine had a visual prototyping language, so that means
there's also a niche in big companies for that type of thing, probably ones
that value R&D and have long stages of
preproduction/prototyping/experimenting with new ideas, etc (he also told
us that our games looked like console games and asked (twice) which country
did we go to to learn how to make them :p ).

On 14 April 2016 at 03:26, Sergey Lapin [email protected] wrote:

The real thing about visual scripting in general, it is futile attempt to
make programming accessible to non-programmers, which is totally wrong
approach.
Visual programming is harder that regular text programming. To make it
easier you have to write many blocks for each case in life in traditional
way and
let these people use them. These proven to be less effective that asking a
good programer to write code. The telling "programming is not a profession,
everyone can do it" is wrong. All attempts to programming without
programming is a waste.

As for state machine - I was thingking about implementing this some time
ago, but that won't help high visuals program.
This can be easily done for your game using tool script and node editor,
which is powerful tool, many people use it for game tools, like
game dialogue editors.

On Thu, Apr 14, 2016 at 9:09 AM, Aaron M [email protected] wrote:

I don't want to have to say it, but that is a very narrow view of visual
scripting tools, Sergey. As for games that have been fully made with
them,
some engines have completely opted out for them such as Construct, so you
won't see any game out of that engine made with regular scripting. Other
(more sane, imo) engine have plugins such as Unity and UE4. I personally
really liked using both uscript & PlayMaker in Unity alongside my regular
code because while some things are easier to code, many are easier to
script out visually, particularly state machines because with a visual
scripter like PM it gives you a lot of feedback with breakpointsw it's
just
so much easier to look at the project from a more scoped out view.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/1220#issuecomment-209776732

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-209779422

You're just talking past me punto slapin, I mean, I never said anything about designers or simplification, but of ease of use even for programmers, which I have experienced it's usefulness. It's not like you can just tell me it's a waste of time when I've the anecdotal experience showing exactly the opposite. I much prefer the option being available _alongside_ scripting, you're acting like I can only choose one or the other and I'm forced to hand it off to my artist. Not the case at all.

Awesome thread, lots of opinions 😁

Mine is simple. You are all right!

Any of these ideas will be a great addition to gdscript 😁

I look forward to trying them out when they appear.

I think gdscript could also do with some love to be more userfriendly.

Some nodes are not documented fully . A lot have no descriptions.
Godot could make use of some helper functions to simplify development. Gamemaker gml is a good example:
https://twitter.com/uheartbeast/status/724326557108461568

I think the documentation stuff is major PITA here, and that's it.
The development itself is simple enough. The documentation and tutorials
are really needed. So just make your youtube account youseful (or blog, or
just post on forum),
that will do a lot of help.

On Mon, Apr 25, 2016 at 9:35 AM, Todor Imreorov [email protected]
wrote:

I think gdscript could also do with some love to be more userfriendly.

Some nodes are not documented fully . A lot have no descriptions.
Godot could make use of some helper functions to simplify development.
Gamemaker gml is a good example:
https://twitter.com/uheartbeast/status/724326557108461568

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment-214163012

Well, I have several thoughts on this.
You can make an engine easier to approach by including something like visual scripting, and that would be good for all the artists who wanted to get into making games but just have no programming experience, but that invites a whole other set of people--namely, people with no skills whatsoever. People for which moving to programming in a text editor is never going to be on their agenda ever, even if that means the final game will suffer. People who think the only thing hard about making a game is the programming, and that with visual scripting, suddenly, this restriction is lifted. This isn't uncommon either. Just look at all the popular engines that make certain things easier for non-programmers--tons of shovelware. I'm not saying you shouldn't include visual scripting because it means we run the risk of getting shovelware, but that it should be implemented in a way that discourages these kinds of people from thinking they can just use Godotengine to make said shovelware.
My other issue is that one of the things that Godotengine is good at, and lots of people like this feature, is that it works very well with git. The problem with visual scripting is that it's often saved in some binary format, and it's a nightmare to manage if you use any kind of source code revision. If you have to implement visual scripting, then it should be saved in a text friendly manner. And if that's impossible, well tough. I'd rather have project files in Godotengine in a format that is friendly with git than to have visual scripting that doesn't play nicely with git.
And judging by all the work that's required to implement a visual scripting system, and the fact that you can make certain types of games in Godotengine without visual scripting without any loss of functionality, efficiency or performance, what's wrong with just having it be implemented as a plugin? I don't really see any reason why it has to be a core part of the engine.

Just to add my 2 cents about visual scripting and why I don't like the idea:

I think the ability to connect nodes in any gdscript file is far better, in terms of code management, and proficiency.

For example, with visual scripting (or using an event sheet similar to C2), what happens if you have over 1000 functions? It will make it a lot worse I believe to navigate through everything. I am porting my HTML 5 Action RPG game right now into Godot (which is over 10k + Lines of code and far more than 500 functions). _(It has basically every single feature Path of Exile has, except for animations and is multiplayer)_

There is no way this would be possible for me with visual scripting. I think we, and the godot developers here should focus more on features / bug squishing than a visual code event sheet. But that's just me :)

Edit: As some others have said, maybe for smaller projects I guess... but anything big I just cannot see it being useful

The event sheet in construct2 supports functions and they work just the same as godots. A simple filter/search box will solve all the fud you listed.

But godot devs dont want to do an event sheet approach even if its popular atm. I get the impression that its more likely to get something akin to the blueprint unreal approach. That way programmers will benefit from a state machine editor added to their arsenal

To organise visual scripting code in vonstruct2 , you put it into groups which can be collapsed. This is something that even gdscript can not do- you can not collapse blocks of code. So in some ways the event sheet does have advantages over godots gdscript editor.

@reduz I was looking at Pure Data and the way they do it is very simple. Well check this out

As you can see typing "Bang" turns the generic object into a Bang object.

What if visual scripting could simply become an extension of GD Script. Simply place a generic node and type Vector2 for ex and it will become a Vector2 object. So essentially each class/object is also a node.

To run functions I'm thinking you can get another node that is not an object but rather a process node and you would type something like Vector2.dot and the node will turn into dot node with 2 inputs and 1 output.

visual scripting is planned at some point

You did not disappoint :) <3

Since there is already VisualScripting, should this issue be closed?

Yes.

"I also smiled in a positive manner.
Because it will be great for me as a gamer if there is a company as big as Steam with tons of games catalogue, open, and DRM Free, created by thousands of great game developers."
just look at gog, its an store that sells drm free games.

Answering off-topic to a 2015 statement, come on :)