Graph Editor For Love2D.

[zorg]

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

Code: Select all

-- So it'd be more equivalent to this?:
dummy = function() end
-- Still, there's no guarantee that fn() returns only one value, not in lua anyway, so basically all functions have a, hardlimited in practice, but theoretically infinite number of inputs and outputs.

[pgimeno]

Dummy is an artifact of the way I imagined the UI would work, as you could only add an assigned variable if you have added a node for that value first. Empty would have worked just as well. The idea was that as you attach new nodes to one node, you could enter new variables for the assigned-to side. You should have at least as many RHS nodes attached as you have variables assigned. The UI would not let you insert dummy nodes in the output of an assignment node (or a for...in node) before others that are not dummy.

Code: Select all

--[[ For example: ]]--

local a, b, c, d = e, f

--[[ would translate to:

+-------------------+
| Local assignment  |
|                   .
|              [a]  o---- [Expression  [e]  ]
|                   .
|              [b]  o---- [Expression  [f]  ]
|                   .
|              [c]  o---- [Dummy/Empty]
|                   .
|              [d]  o---- [Dummy/Empty]
|                   .
|                   |
+-------------------+

while something like
--]]

local a, b = c, d, e, f

--[[ would translate to:
+-------------------+
| Local assignment  |
|                   .
|              [a]  o---- [Expression  [c]  ]
|                   .
|              [b]  o---- [Expression  [d]  ]
|                   .
|              [ ]  o---- [Expression  [e]  ]
|                   .
|              [ ]  o---- [Expression  [f]  ]
|                   .
|                   |
+-------------------+
--]]

The little circles in the original picture (I drew them far too small, sorry), and the dots in the above, are insertion points: when you attach a line there, it is promoted to a new circle that keeps the same position as where you inserted, and dots are created as well around it. And every circle on the right side of a local assignment has an associated assigned-to variable (you can leave the field empty to not add a variable, as in the a,b=c,d,e,f case). Hope it's clearer now what role the dummies are fulfilling.

Edit: Anyway, in the end it doesn't matter. While the AST approach is appealing for the UI coder because of the simplicity of coding it, it's really not very practical for the user of the UI, and as Nicholas has noted, an approach where the program flow "follows the arrows" instead of being top to bottom, would be much more intuitive for the user. I just still have my reservations about its universality and applicability to LÖVE.

[Nicholas Scott]

Ok, well here's a quick example of what the nodes will look like, this took me like 1 hour to finish all the dynamic placements cuz.. well my math kind of sucks, and I had to have a pen and notepad x3 https://i.imgur.com/wX6punq.jpg
Here's the video https://streamable.com/ohy5

I'm gonna go ahead and create the actual thing now that I have the create node function made

Edit: Here's another mockup of a node in action https://streamable.com/rn56

[Nicholas Scott]

I'm looking forward to seeing your mockup in LÖVE.

@pgimeno Here's my mockup, it's reasonably there and I'm going to work on the code generation next and all that nonsense. There's still a few bugs, but it's pretty efficient
https://streamable.com/sn3v

As you can see, the node titled "Event love.update" is as you can assume the love.update function, the one titled "print" is the print function, taking a string(Can take multiples, I can work on that when I get to implementing the actual function libraries) the one titles "Branch" is an "if-statement" taking a boolean, you could use other nodes such as a "<=" operator that takes 2 numbers and compares them, and an output pin of a boolean that could be plugged into the branch and the final labeled "Function MovePlayer" is an example of what a custom function you've added would look like.

[pgimeno]

OK, I got that far. But note that the part I have issue with is this, from your 2nd post in this thread:

at some point in time, be able to import lua files and turn them into nodes in the best way possible

Problem is, there are some language constructs that I don't immediately see how to convert to nodes. I've created a somewhat artificial example that draws a certain line (a parabola followed by a straight line) in a not very efficient way, with the goal to include some of the constructs I have difficulty figuring out how to translate to nodes:

Code: Select all

local points = {}

local x, y

do
  local x, y, v = 0, 0, 0
  while #points < 100 do
    points[#points + 1] = {x = x, y = y}
    x = x + v
    v = v + .1
    if v > 6 then
      v = 15
    end
    y = y + 5
  end
end

function love.draw()
  local linepoints = {}
  for i = 1, #points do
    x = points[i].x
    y = points[i].y
    linepoints[#linepoints + 1] = x
    linepoints[#linepoints + 1] = y
  end

  love.graphics.line(linepoints)
end

It's somewhat long, sorry. But it illustrates the following concepts that I don't see how to translate to nodes:

• Locality of variables.
• Dynamic loop.
• Dynamic list of tables.
• Multiple assignments to the same variable within a loop.
• Accessing fields of tables nested within a list.

Do you think you can make a mockup of how that program could be translated into nodes?

[Nicholas Scott]

Do you think you can make a mockup of how that program could be translated into nodes?

Idk about making a mockup of that exactly, I'll look into working that code out in a bit, currently trying to revamp "Thrandruil" GUI system to work with my nodes the way I want
But it's rather simple in all honesty, it can go line by line, use RegEx formats within the string to find certain keywords such as "local", "while", "function", etc. that says that the proceeding characters should extend some form of that function, if it's a "local" statement then the program knows that the proceeding text until a "," or a "=" should be used as the local variables new name, subtracting whitespace of course, and after the "=" it can then parse whether the variable type is a table, string, number, nil, etc.
Rather complicated RegEx formatting, which I'm not to amazing with, hence the reason I'm kind of putting that off until I actually have the ability to represent them as nodes and be able to debug that shit x3

[pgimeno]

The question is not about how to make the parser. I'm familiar with parsing. It's about how to represent certain language concepts in node form so that an arbitrary program can be represented in that form.

[Nicholas Scott]

It's about how to represent certain language concepts in node form so that an arbitrary program can be represented in that form.

I'm not really sure what to tell you man, I've taken up this project and I'm working on it, but unless someone show's interest, it'll probably be for my own personal use. All I can tell you is to look at Blueprints in Unreal and how successful it is in "representing" the C++ programming in "AST" format.

[Positive07]

Well then how can you "represent" that (or similar) Lua code to the one pgimeno posted?

If at some point you intend to "translate" Lua files into this Graph tree then you need to be able to represent all parts of the Lua language as nodes, lines or whatever.

Unreal is "good" at "representing" C++ because it just represents a subset of C++. with the syntax Unreal expects, it can't represent all of C++ code though... They use a reduced AST

Also don't expect an explosion of interest, every time someone proposes a new tool to aid development it has to prove that it is actually needed or somewhat better to existent ones.

Your tool may help newcommer but existing developers don't actually need it. In order to gain traction you must post a working prototype.

Note that even then it may not rise interest, as I said you have to probe that this is better than writing code in a code editor as most are used to. You decide if it's worth it... If you don't want to post it, then just don't

[pgimeno]

I have interest in the project, I just don't see how the nodes format that you have in mind is suitable for representing certain programming constructs. I can see how they can be represented in the AST-like form that I proposed. I showed it by taking an arbitrary example program and making a mockup of how I could imagine an AST-like representation in graph format, but which is actually not suitable for actual programming (it still had problems, but these can be discussed). Again, the program: https://github.com/love2d-community/LOV ... _modes.lua and the mockup: http://www.formauri.es/personal/pgimeno ... mockup.png

Maybe when I see the program I posted in the format that you foresee, the light bulb goes on and then I can contribute. So far I don't see how to carry on this project without significantly reducing the admissible Lua grammar, like Positive07 says UE does with C++.

At the moment, I still think that something Scratch-like is more suitable to making a Lua-based visual programming language than UE-like nodes where execution "follows the arrows".