Easy to use game designer for non programer

[RyanBram]

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. 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).

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

1. Aleph (RPG Adventure)
2. No Manatees Promised (Arcade)
3. Ragarokk - Bestiarium (Card Game)
4. Earth Under Attack! (Shooter)
5. Terra (VisualNovel)
6. Memories of Mana (Action RPG)
7. Myhos - The Beginning (Horror)

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

[reduz]

visual scripting is planned at some point

On Wed, Jan 14, 2015 at 6:20 AM, RyanBram notifications@github.com 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.

[SolarLune]

@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.

[TheoXD]

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.

[reduz]

@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 notifications@github.com 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.

[Ace-Dragon]

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.

[RyanBram]

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.

[mamarilmanson]

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.

[mamarilmanson]

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 notifications@github.com 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.

[RyanBram]

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

[rishavs]

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.

[RyanBram]

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

[blurymind]

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.

[NathanWarden]

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.

[TheoXD]

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.

[blurymind]

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..

[NathanWarden]

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.

[blurymind]

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?

[NathanWarden]

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.

[blurymind]

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.

[NathanWarden]

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.

[TheoXD]

@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.

[NathanWarden]

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:

[blurymind]

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.

[NathanWarden]

@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 :)

[blurymind]

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.

[TheoXD]

@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.

[NathanWarden]

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. :)

[blurymind]

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)

[NathanWarden]

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.

[reduz]

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 notifications@github.com 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.

[blurymind]

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 .

[todheil]

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/

[godotengine]

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 notifications@github.com 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

[todheil]

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

[blurymind]

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 notifications@github.com 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.

[draxdeveloper]

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 notifications@github.com:

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 notifications@github.com 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

[draxdeveloper]

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 draxdeveloper@gmail.com:

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 notifications@github.com:

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 notifications@github.com 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

[TeddyDD]

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:

[blurymind]

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.

[blurymind]

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

[todheil]

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

[blurymind]

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 notifications@github.com 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.

[whoisda]

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.

[reduz]

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 notifications@github.com 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.

[blurymind]

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 notifications@github.com 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 notifications@github.com 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.

[blurymind]

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 blurymind@gmail.com 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 <notifications@github.com

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 notifications@github.com 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.

[whoisda]

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.

[blurymind]

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 notifications@github.com 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.

[blurymind]

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 blurymind@gmail.com 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 notifications@github.com 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.

[whoisda]

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.