Easy to use game designer for non programer #1220
Comments
|
visual scripting is planned at some point On Wed, Jan 14, 2015 at 6:20 AM, RyanBram notifications@github.com wrote:
|
|
@RyanBram - Not trying to downvote the idea, at all, here - it probably could be useful in the future, but I'm not certain visual scripting is an effective means of scripting. I can't say for sure, but I'd imagine the more complex games you posted most likely were scripted in text, not visually. It kind of seems like visual scripting is something new users use, surely, but that delays them in learning the actual tools they'll need to properly complete their projects. But it could make the engine more approachable, so I don't know. It should also be possible for users to create a visual programming system all in Godot with GDScript as opposed to something that needs to be built into the engine, right? I'm not sure about that, though. |
|
RPG maker seems to take more of a "Modding" approach, and if Godot will look more like RPG maker - people who have intentions to make different kind of games will turn away. So what you're basically suggesting is to make godot look more like GameMaker (which is understandable, many people want to make games but don't know programming) but there are limitations :) @SolarLune , it is possible to build a game in Godot and add an editor on top that allows modding the game to every little detail (by using GraphNodes and rest of UI, very fun to play with), and would even allow to write some extra GDscript code on top, I think this is the best approach, to ship a complete game game (RPG, FPS, RTS) separately and allow tweaking every aspect of it. Constructors made in Godot. |
|
@SolarLune: Visual scripting is useful when you work together with a On Wed, Jan 14, 2015 at 4:23 PM, TheoXD notifications@github.com wrote:
|
|
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. |
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: |
|
I smiled about that idea of Okam studio being like Steam... :)) On 1/14/2015 5:20 PM, RyanBram wrote:
|
|
Unreal actually has templates for projects whether you want to do a On 1/15/2015 3:44 AM, Juan Linietsky wrote:
|
I also smiled in a positive manner.
Great if it will be available in Godot. Regards, |
|
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.) 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. |
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, |
RyanBram
changed the title
|
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.
If you do visual scripting, please do not half arse it with a generic node based editor. If you want more non programmer folk to use your engine, do something with a better design - like construct2 or multimedia fusion. |
|
I'd like to see something like this implemented only as a secondary way of programming. Visual scripting, as opposed to code, slows down productivity by a pretty big order of magnitude. It also tends to make debugging and refactoring far more difficult. The one major upside I can think of (beside for it appealing to non-programmers) is that visual scripting tends to be a great teaching tool if it would be able to generate, or at least show, actual GDScript code (IE. code.org). I don't think it would need to go the other way around (IE. GDScript to Visual). I think this would be a great way for schools to adopt Godot into their classes. Here are two major differences between code and visual scripting that I think are the most important as far as approachability. This is coming from someone who won't touch visual scripting with a ten foot pole, but I do understand it appeals to some people :) Code: Code tends to have specific syntax rules that need to be followed. My guess is that this tends to be the main thing that turns non-programmers off. IE. in GDScript you mush have a colon at the end of a function declaration, if, for, while loops etc. You must indent properly. You must use the var keyword when declaring a variable like "var myInteger = 1". For most languages, there tends to be about 3 or 4 primary syntax rules that tend to need to be followed and in my opinion aren't that hard to learn. After writing a handful of small scripts even an artist can learn them. I say this because I work with two very talented artists who worked on all three of the Age of Empires games with Ensemble Studios. One has written quite a bit of code in UnityScript and the other has now written a ton of code in C#. Visual: You tend to get a dropdown menu for the method, variable, statement, etc. However, you must still know which functions, properties, etc that you're looking for and what they do and even sometimes how they work. You must still problem solve. You must still use variables and keep track of what they're doing throughout your script. You can still have logical errors just as easily as writing code. I do think being able to actually write the code is ultimately a far superior way to go from a productivity standpoint. However, neither will make you a better/worse programmer. I do think visual scripting is a really good teaching tool, but if you don't know (or want to learn) how to structure things properly and especially how to problem solve, visual scripting won't help you one bit. |
|
I would take a slightly different approach. Since godot editor is driven on itself - it is easy to recreate a similar editor interface in pure GDscript. So my proposal would be to make a constructor scripted entirely in godot and ship it separately. This would allow programmers and non-programmers to work on the same project while using different tools. Only problem is that non-programmers will have to sometimes deal with both tools at the same time, but hey, I've seen worse xD Gridmap editor, shader editor, animation editor, code editor - can be recreated, while collada importer, convex generator, exporters - not that easily. Still feels like reinventing the wheel, but can simplify a lot of things. Constructor core could be adopted to any game genre (FPS, RTS, GPS....) with downloadable content and stuff, and if it's community maintained - it will be easier to contribute, because everything is GDscript |
|
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. 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.. 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. |
|
If we were to take a vote on this thread I'm quite sure it would be the completely wrong place because mainly programmers would show up for the vote. A visual scripting system should be designed for artists, not programers. As much as I could complain about my utter dislike for things like PlayMaker on Unity, the truth is that artists love it. That's why it has almost 2000 reviews and is 5 stars. If the vote is to have something more like Construct 2's scripting then my vote is to not have visual scripting at all as I don't believe it will be of any real benefit since A) Programmers can program directly in GDScript and B) Many artists will be instantly turned off by it and just go elsewhere. I know, because my two artist friends, who both can code, were looking at Construct 2 and poking fun at the programming interface it has since it's almost the same as just writing code. A visual scripting language should be very visual, not many words. It shouldn't look like code at first glance. It should be tailored to "visual people", otherwise there's no point in making it in the first place. Artists are used to, and tend to like, node graphs as they give you a visual sense of what your program is doing. Again, I don't like node graphs myself as I can't stand them, but I'm a programmer and my vote really shouldn't count in this area. |
|
I agree with you that it should be designed for artists/designers. 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? 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?? 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. |
|
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 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:
That's really what it comes down to. If the artist is going to take one look and pass to the next game engine because the other one has node based programming, then Godot shouldn't have visual scripting at all, because there probably won't be more than a tiny handful of people who will use it and it just means more code maintainance from that point forward. |
|
Are you sure you have any idea what Construct2 is? You are not even spelling its name correct. 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. Another point: 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: |
|
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. |
|
Graph nodes actually came from conceptual UML. You make graphical representation of code in a way that non-programming audience (project managers, consumers, artists) can understand. This is what UE4/Unity uses. This is something that everyone in the industry is aware of. Constructors usually take a different approach, and how good this approach is - is not defined by the number of users that uses it. There is always a learning curve everywhere, and Construct2 is not an exception. But let's not force C2 stuff into Godot without backing the arguments. Event sheet will become longer with more complex games, and end up wasting more space than graph nodes. Only "Add action" button has it's own row to itself. It's basically how a programmer would interpret a block of code. So it ain't that bad. I personally don't see why we can't have both, but devs already have enough to do so it won't happen any time soon. This is why I proposed a different approach that will evolve faster, pretty much driven by non-programmers in cooperation with programmers. |
|
Here's a better example to show that you can have more than one event per node. Also note that each node (or state) is non-blocking, so it will allow other node graphs to run concurrently:
|
|
But see, just by looking at your screenshot I have no idea what that logic does. What the hell is "firePrimary" and "fireSecondary" ?? 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. 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. Telling me I'm not backing my arguments is just a confirmation that you have no desire to look into construct2 or consider it's design as an alternative to nodes. It is sadly a waste of my time to convince you otherwise. |
|
@TheoXD 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 As far as not being able to see what's under a node until you click on it, once you've setup a node there's no real point in sifting through what you already know is there. I already know that I have left and right click and that they fire primary and secondary ammo. I already know what the primary and secondary fire nodes do. It hasn't changed since I made it, why do I have to see the details every time I look at it? So, now the underlying logic is just clutter. This is another reason why nodes are more artist and non-programmer friendly. They can break their specific logic into more general chunks. It makes it so they can get a big picture view and only worry about the details when they absolutely need to. I'm looking at an actual project for an actual published mobile game right now and almost every node graph is 2 to 4 nodes at most, so it's hard to show you a more elaborate setup when you typically don't need an elaborate setup. If you want elaborate, this is from that same app that was written by a person who is about as non-programmer as they come. This is one of the most complex graphs in the game. It controls the main player's movement: (That's another thing you can't do with blocks is make them look like Samus's ship, haha) Without any prompting, I just put up your Construct2 image on one screen and put the above node graph on the other and asked my wife (who is definitely not a programmer), "Which one would you want to use if you had to use it every day?", and she pointed to the node graph and said, "This one". I know that's not definitive, but the fact that it's less intimidating means I have far more of a chance to even begin to get her to learn it. If it looks intimidating she may shut her brain off before I even get her to sit down to learn the basics. Without pushing him toward one or the other, I also asked my artist friend yesterday (the same one who worked on all three Age of Empires games), who's been in the game industry for almost 20 years now, (and who has used Construct2) what he thinks other artists would prefer and he also said the node graph. Anyway, I really do enjoy the discussion but there's no sense in beating a dead horse, haha :) |
|
Yeah I do enjoy it too. No bad feelings :) Awesome Samus Ship btw. The more pictures you post, the more you support my case that nodes are visually harder to follow since they can split in branches and go in crazy directions. 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 :) 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. Lets not compare apples to oranges. 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. |
|
@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.. As much as I would like to see this issue score over 100 comments, devs will not read them all, best thing each of us can do is to make a PDF with proposals, and share them on mailing list. I don't see why we can't have different levels of abstraction, Graph nodes as top level, that can be represented in a form of an event tree. If this works then there will be no need to compromise. "@blurymind -- || -- And you both admit to be programmers." - I don't consider myself as only a programmer, do art too you know. I use my experience to look at things from an objective point of view. |
|
I'm not sure if it was missed, but I'm not just a programmer either, but also a professional artist. I think most programmers would really benefit by jumping into art for a while. It makes programming certain things make a lot more sense and it also helps bridge the programmer/artist rivalry, haha :) I know this is more ideal, and not so much practical for most folks. Here are some links to some of my work (look for Nathan Warden in the credits) World Builder (involved in about half of the shots) Teddy Scares (was involved in most shots) Hallmark Crown Center (The third shot with Santa) Here's a render of my Louie's building. If you watch World Builder you'll see some of the artwork that I ripped from it and put into the film. And here's an unfinished render of a Terminator 1 style HK Tank smashing Stephen King's Christine. Both of those models are done by me, but I don't think anything else in the shot was. And many more that I could name, but I think the point is made. :) |
|
Well those are amazing stills- but again you are doing this to give yourself more authority. This is not helping to logically support the idea that Nodes are better than Event sheet :) If you go with nodes, you will be like any other god damn 3d game engine out there that uses visual programming. I think that this is not a great idea for a number of reasons. -Recently Unreal made their engine free - its also multiplatform. It is a much more mature engine than BGE/Godot. So you are competing with them directly when copying their approach to visual programming. -Nodes are way less screen efficient than a logic sheet. They are harder to read/follow. -Scirra announced that construct3 will be multiplatform - the editor will work on windows, linux and mac. 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:
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) |
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?
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.
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.
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. |
|
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! |
kubecz3k
changed the title
|
Subscribing. I'm very interested in this as well! I know some scripting and don't really mind using it... but I so prefer connecting nodes over that when possible! Something like the logic bricks in Blender Game Engine, which act as visual shortcuts for Godot script functions as an alternative to writing them by hand... that would be a lovely feature and one I am actively waiting for. |
|
visual scripting really attracts a lot of creative people or people who don't wanna learn a new scripting language like gd script. i was looking at game maker is so damn popular and single most given reason is the visual scripting mechanic. |
|
Visual scripting is tedious, stupid and hard to use. I don't know of any visual logic building tool, which was main system for On Thu, Apr 14, 2016 at 8:33 AM, Rémi Verschelde notifications@github.com
|
|
I don't want to, but I have to say it, but that is a very narrow view of visual scripting tools, Sergey. As for games that have been fully made with them, some engines have completely opted out for them such as Construct, so you won't see any game out of that engine made with regular scripting. Other (more sane, imo) engine have plugins such as Unity and UE4. I personally really liked using both uscript & PlayMaker in Unity alongside my regular code because while some things are easier to code, many are easier to script out visually, particularly state machines because with a visual scripter like PM it gives you a lot of feedback with breakpointsw it's just so much easier to look at the project from a more scoped out view. |
|
The real thing about visual scripting in general, it is futile attempt to As for state machine - I was thingking about implementing this some time On Thu, Apr 14, 2016 at 9:09 AM, Aaron M notifications@github.com wrote:
|
|
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. 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. If you really wanna make Visual Scripting, make it like the Stingray Engine. You can create CodeBlocks in Visual and generate TextCode you can later modify, or write TextCode you can later use as Visual Blocks. |
|
I wouldn't say it's futile, but I would say that we're talking about 2 If you're running a studio, and you're making games with say 20-80 people, On the other hand if you have a cool idea and don't really know how to It's 2 different products, and if we argue about which one is more worth But we can have both, and I wouldn't discourage either one. A visual On 14 April 2016 at 03:26, Sergey Lapin notifications@github.com wrote:
|
|
You're just talking past me |
|
Awesome thread, lots of opinions 😁 Mine is simple. You are all right! Any of these ideas will be a great addition to gdscript 😁 I look forward to trying them out when they appear. |
|
I think gdscript could also do with some love to be more userfriendly. Some nodes are not documented fully . A lot have no descriptions. |
|
I think the documentation stuff is major PITA here, and that's it. On Mon, Apr 25, 2016 at 9:35 AM, Todor Imreorov notifications@github.com
|
|
Well, I have several thoughts on this. |
|
Just to add my 2 cents about visual scripting and why I don't like the idea: I think the ability to connect nodes in any gdscript file is far better, in terms of code management, and proficiency. For example, with visual scripting (or using an event sheet similar to C2), what happens if you have over 1000 functions? It will make it a lot worse I believe to navigate through everything. I am porting my HTML 5 Action RPG game right now into Godot (which is over 10k + Lines of code and far more than 500 functions). (It has basically every single feature Path of Exile has, except for animations and is multiplayer) There is no way this would be possible for me with visual scripting. I think we, and the godot developers here should focus more on features / bug squishing than a visual code event sheet. But that's just me :) Edit: As some others have said, maybe for smaller projects I guess... but anything big I just cannot see it being useful |
|
The event sheet in construct2 supports functions and they work just the same as godots. A simple filter/search box will solve all the fud you listed. But godot devs dont want to do an event sheet approach even if its popular atm. I get the impression that its more likely to get something akin to the blueprint unreal approach. That way programmers will benefit from a state machine editor added to their arsenal |
|
To organise visual scripting code in vonstruct2 , you put it into groups which can be collapsed. This is something that even gdscript can not do- you can not collapse blocks of code. So in some ways the event sheet does have advantages over godots gdscript editor. |
|
@reduz I was looking at Pure Data and the way they do it is very simple. Well check this out
As you can see typing "Bang" turns the generic object into a Bang object. What if visual scripting could simply become an extension of GD Script. Simply place a generic node and type Vector2 for ex and it will become a Vector2 object. So essentially each class/object is also a node. To run functions I'm thinking you can get another node that is not an object but rather a process node and you would type something like Vector2.dot and the node will turn into dot node with 2 inputs and 1 output. |
You did not disappoint :) <3 |
|
Since there is already VisualScripting, should this issue be closed? |
|
Yes. |
|
"I also smiled in a positive manner. |
|
Answering off-topic to a 2015 statement, come on :) |
and others
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:
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
The text was updated successfully, but these errors were encountered: