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

[blurymind]

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

[todheil]

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.

[blurymind]

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

[whoisda]

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.

[blurymind]

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

[reduz]

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

[madjestic]

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.

[blurymind]

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.

[blurymind]

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!

[madjestic]

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

[blurymind]

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

[whoisda]

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.

[madjestic]

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

[blurymind]

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.

[madjestic]

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

[blurymind]

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

[madjestic]

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

[reduz]

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

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.

[blurymind]

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.

[reduz]

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

On Tue, May 26, 2015 at 12:16 PM, Todor Imreorov notifications@github.com 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.

[godotengine]

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

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

[blurymind]

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.

[mohaalak]

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

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

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.

[blurymind]

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

[adolson]

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.

[NathanWarden]

@adolson That would be a much desired feature :)

[reduz]

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

[madjestic]

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

[NathanWarden]

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

[mischiefaaron]

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!

[MirceaKitsune]

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.

[ghost]

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.

[slapin]

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

[mischiefaaron]

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.

[slapin]

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

[SiENcE]

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.

[punto-]

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

[mischiefaaron]

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.

[zatsme]

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.

[blurymind]

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

[slapin]

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

[Algorithmus]

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.

[ghost]

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

[blurymind]

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

[blurymind]

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.

[ghost]

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

[ghost]

visual scripting is planned at some point

You did not disappoint :) <3

[bojidar-bg]

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

[akien-mga]

Yes.

[Elmapul]

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