LÖVE

This is more or less a discussion zone for anyone who's interested in this topic. Now let's say some stuff right off the bat, I'm working on this atm, more or less getting the idea goin, markin down ideas and letting my brain put it all together and run through the most optimized ways of implementing certain things, we all know this won't be for some people, but some people will love it Basically it's going to be this

Now anyone who's used UE4 will get this and to those who don't, just go watch a quick youtube video about "Unreal Engine 4 Blueprint Editor Basics" and you'll get the idea pretty quickly. I'm gonna make this but I'd like a bit of input from the community, let's start off with the basic questions, you can answer below or don't x3 You're choice

• C++ or Love2D? Should I make this in C++ or should I go for the all pure and clean Love2D route?
• Should this be centered entirely around Love2D or should it be done for Lua in general?
• Should I focus on the looks first or just get the function there?
• Are you interested in contributing to the UI of the program...? Cause I suck at art
• (Not a question but still) Let's do this together as a community, we should make this a project all of us can enjoy and follow

Quick Note: If you need to get a hold of me and I'm not on the forum(I don't care if it's an emergency or if you just wanna talk about the project and contribute) you can get in touch with me in a few ways, the most reliable will be >>discord<< but you can also get in touch via >>steam<<

Is it going to be a code generator? If so, speed is not that important, therefore it'd be much easier to do it in LÖVE. If it's going to be a substitute for Lua, then probably C++ would be a wiser choice, since interpretation needs as much speed as you can get.

I'm not familiar with UE4, but I'm remotely familiar with Blender's nodes. To get a better understanding of the task at hand, I'd like to see some ideas regarding how to convert the API into boxes. For example, accessing the methods of a class instance like Body or Shader or File. Or how to handle dynamic lists of tables.

pgimeno wrote:Is it going to be a code generator?

Yes it's going to be, in it's most basic form, a code generator that allows you to; Create new projects, edit old projects and, at some point in time, be able to import lua files and turn them into nodes in the best way possible(I'm still working that part out as it's going to be allot of code to interpret the code and build nodes based off of it. But basically the way I'm planning on doing this is having the base lua function calls built in and having plugins for various different things (Gmod's function calls, Love2D's calls, event hooks, etc.) So you could potentially create a plugin for an entirely different engine if you so wish to do, but I'll be hoping to have it work off of plugins.

Edit:
TL;DR: Builds code based off of the nodes, creating functions and variables will be as basic as clicking a button on the UI and editing those functions nodes.

Well, there's a straightforward way: the program can simply be the representation of an AST visually (with the ability to manipulate it). To read a program, parse it into an AST then represent the tree. Generating the program from the graph is then easy.

But I'm afraid that such a representation would not be so intuitive, because the flow is not the same as what I've seen in Google examples of UE4. It'd be more like another way to write a program. A root node for a function, for example, would have as many outputs as commands the function has at the first level of indentation, so to say, and execution would proceed in sequence one output at a time, like a program's execution proceeds line by line, rather than following the left-to-right flow like what I've seen in UE4 examples.

If that's acceptable, then it's fairly easy to create.

pgimeno wrote:Well, there's a straightforward way: the program can simply be the representation of an AST visually...

That's a good idea, however as you said, it isn't that much more intuitive, I basically want to build it from the ground up in a graphing sort of way, like when I started in UE4, I opened the graph and it was so easy to pickup(Even though my understanding of C++ at the time was rudimentary.) and that capability and how easy it is to see the flow of the program is what I want to recreate for love2d(or any other lua platforms for that matter)

Well, I don't immediately see how to parse an arbitrary program into a format other than an AST.

I've made with Inkscape a mockup of how this program: https://github.com/love2d-community/LOV ... _modes.lua could look like with a simplified form of an AST (allowing arbitrary expressions to be entered, rather than adding a node for each operator, for example). Here it is: http://www.formauri.es/personal/pgimeno ... mockup.png. Looks and UI are not important at this point, only organization. That tree is easily convertible into a program.

I think that the first thing to do is to study the viability of the project. And I think that for that, it's necessary to come up with ideas about how to express language concepts such as variables, instances, tables, iteration...

pgimeno wrote:Well, I don't immediately see how to parse an arbitrary program into a format other than an AST.

Well this isn't that big of a thing, as AST is a pretty decent form of doing what you're thinking of, but what I'm thinking of is a more user friendly design and I can do a little demonstration of what Unreal does with this concept and what I think is the way to go with this, and really it's not that difficult to go from the nodes(As Unreal has build it) to actual code, as each node has it's own set form of code that it needs to execute, the only thing that matters at that point is the execution order(Which can be gotten from the execution line), here's a quick idea of what I'm intending:

Actually x3 I'm gonna go ahead and throw up a quick example in love and show you what my intentions are, gimme a few I'll add another post when I've finished the example!

pgimeno wrote:Here it is: http://www.formauri.es/personal/pgimeno ... mockup.png. Looks and UI are not important at this point, only organization. That tree is easily convertible into a program.

I think that the first thing to do is to study the viability of the project. And I think that for that, it's necessary to come up with ideas about how to express language concepts such as variables, instances, tables, iteration...

In my mind, one important lua-like thing i'd bring over to this representation would be scope. All types of scope.

One way i could think of doing this is using tabs, at least two; one for the "global" scope (of the main thread), one for main.lua's file scope (, and probably going deeper into do...end, function, and iterator scopes). Probably all of them could optionally be collapsed into one node on the screen. This would be instead of the "lines" connectors on each node.
This would mean using "getGlobal" nodes if one would want to use globals, though this would also make it fairly simple to see what does and doesn't exist in each scope.

I know the image you linked is just a mockup, but when the project would be at that state, it could actually show the "name" for a function call's arguments, for example, instead of just "args", or shift-clicking them bringing up a help bubble with synopses/functionality.

Also, i don't see the use case for the Dummy node as such; calling it nil would make sense in that that way, it would be assignable since it's a built-in type.

@zorg, "Dummy" is there because, when you have in Lua something like a,b=fn() you have one source value and two target values, and in the graph you'd add a dummy source node to let you enter another target node without generating code. It's not really equivalent to a,b=fn(),nil so I didn't use nil.

@Nicholas Scott, I still need to see the viability of converting an arbitrary program into the form you have in mind. I don't see how certain concepts can be expressed that way. I'm looking forward to seeing your mockup in LÖVE.

There was something of this sort already a while back: The Blueprint Machine