Jump to content

  • Log In with Google      Sign In   
  • Create Account


Examples of Node Based Programming?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
30 replies to this topic

#1 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 01:55 PM

So, I have recently become interested in what I am, for now, calling "Node based Programming." My actually first encounter with node based programming was in Blender 3d, but I overlooked it because it is not good.

Recently I came across an app on the iPad called GamePress. It is a game engine that can make 2d games right on your ipad for free. Here is a demo:

GamePress:


And this is when the Eureka came! Game Press uses a node based system for programming. And I truly think that this is the best way to program games. One of the advantages is that your rendering can be tied in directly to the code of the program itself (because it would be node based too like Blender Cycles nodes). All of your graphics would be set up through the use of nodes.

I think nodes look the way that programs work. As I mentioned in another thread, that if we were to perceive a variable as a real life object it would be a container that stores values. A node looks like a variable already. Nodes also look like functions. Data goes through a wire to the function, and the function does something and either transmits that data through another wire to another function or it does not transmit that data.

I also think that node based programming could work for any language. I could see myself programming in c++ with a node based system.

So, what I am really wondering if there is anyone here who knows of any other uses whether present or past that use a node based system for programming. Anyone see the weaknesses or strengths of such a system?

I'd like to look into any such software that use a sort of node based system for programming (I presume there are some used for robotics programming).

Thanks.
Note: I will be updating this post with my discoveries also for people who are interested. I already am downloading one.

NODE BOX:
http://nodebox.net/

Node Box Opinion: After downloading node box and going through the brief tutorial on the website, I have to say this is a very interesting program. And I just got a major idea from using it. I have been looking for ways to procedurally generate graphics and animations and such. I think that a node based system will make this 1,000 times easier. Node box also lets you export these graphics to pdf which can be opened in Illustrator or Adobe Photoshop. It also exports mp4! Hmm, wonder if you can do animations.

It seems node box now lets you generate your own nodes! Haha. This is too awesome man. You can generate it using Python?! And it gets even crazier. You can build shader nodes! If this isn't the future of game programming, I don't know what is.
http://nodebox.net/node/documentation/advanced/programming-nodes.html

Node Box Demo:


NODEKIT:

NodeKit Opinion: I have yet to get started on this program. Just discovered it. I am also interested in another software they developed for the ipad but it is 39.99 called Tagtool. I believe it was made with nodekit, but I am not sure. I am downloading it from Sourceforge now. It is open source software.

NodeKit Demo:


DYNAMO (Autodesk):

Okay, so if Autodesk has their hands in it, you know it is worth noting. I am now downloading Dynamo which is an open sourced Visual programming software for design. This has to be interesting.

BLOCK V3 (Node based system for Autodesk Maya)

Demo:



Additional Stuff:

Programming with Nodes in Blender 3D:


Thread on issues of Visual Programming:
http://cs.stackexchange.com/questions/539/visual-programming-languages


Someone posted this link in a forum:

http://www.nevigo.com/en/articydraft/overview/

Edited by Tutorial Doctor, 09 February 2014 - 10:11 PM.

They call me the Tutorial Doctor.


Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 12400

Like
4Likes
Like

Posted 06 December 2013 - 02:05 PM

This is more commonly referred to as "visual programming" and was a bit of a fad about 20 years ago.

It failed, for a number of reasons, the most important being that expressing non-trivial logic in a visual language is a pain in the ass and far harder to untangle and debug than textual languages.

#3 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 02:48 PM

This is more commonly referred to as "visual programming" and was a bit of a fad about 20 years ago.

It failed, for a number of reasons, the most important being that expressing non-trivial logic in a visual language is a pain in the ass and far harder to untangle and debug than textual languages.

 

Thanks for the key word Apoch. I came across another new word for me, "generative design."

 

Node box is the first thing I have come across, and I have to say that it is very interesting. You can create your own nodes with python and it has some sort of svg graphics importer. So it seems you could use svg graphics as your shapes. Within the first 10 minutes of using it I have exported a png graphic generated with it, as well as an mp4 video made with it. 

 

Question though, do you think that if there was a way to solve the "non-trivial logic" aspect of visual programming, that it would be the better way to program? 

 

The GamePress app on the ipad seems to be appealing to people who also use the Codea app (which is more useful for non-trivial programming than GamePress.) Just image if it expanded its nodes also. You can even create particle systems and sound effects from within the app. And they are both procedurally generated. 

 

I think I might actually be using node box for my game menu elements. And this is only the first software I have found so far. 


Edited by Tutorial Doctor, 06 December 2013 - 02:49 PM.

They call me the Tutorial Doctor.


#4 SeanMiddleditch   Members   -  Reputation: 1866

Like
2Likes
Like

Posted 06 December 2013 - 03:33 PM

What you're talking about is commonly used in a subset of games. Both shader editing and game logic event scripting is often done in a node-based visual language of some kind in many higher-end engines. As ApochPiQ notes, these tools are a pain in the ass to use for more advanced needs and typically have some way to insert "real code" into them for these cases.

Question though, do you think that if there was a way to solve the "non-trivial logic" aspect of visual programming, that it would be the better way to program?


This is a topic under active research by many large companies and universities. I'm sure you could generate a lot of opinions on a little forum like this one but this is hardly the place to expect any kind of expert opinion on core computational science research topics. Lots of people are trying to show that visual programming languages can be used for non-trivial work but there's no consensus on any of them actually being "the future."

#5 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 04:20 PM


these tools are a pain in the ass to use for more advanced needs and typically have some way to insert "real code" into them for these cases.

 

Yes, I think this is even why Game Maker has a "real code" feature. I do think Node Box has a real code feature also. 

 

Even the ipad App "Editorial" which uses a sort of snippet system has a "real code" feature. 

 

It seems it would take a stroke of genius to break free of textual programming. So much of our communication is done through either spoken language or written language. But then the information we speak or write comes from the information we have gathered through seeing and hearing. 

 

When I look at a long page of programming, I cannot see the program that well. When it is compiled and run, I can then see the product of the program. 

 

It just seems that a node based system can be more representational of what actually happens both at the hardware level and software level. Things such as memory allocation and pointers and such. It would certainly make low level programming a lot easier. 


Edited by Tutorial Doctor, 06 December 2013 - 04:21 PM.

They call me the Tutorial Doctor.


#6 rpiller   Members   -  Reputation: 634

Like
1Likes
Like

Posted 06 December 2013 - 04:21 PM

I've heard of these being called flowgraphs and Kismet for UDK is one program that allows you to design your logic visually. Have a look at it because it's pretty cool and powerful. Many programmers don't understand how it's "better" than coding, but to a game designer, these tools are amazing and allows for much faster game mechanic development/testing.

 

I'm a believer that this is the future of programming. Text based commands will always exist because at it's core that's what is running these flowgraphs, but I think flowgraphs will eventually become the way the majority of people program (and it'll open up programming to an entirely new audience). I'm a programmer of 15+ years and I think this way. That often gets other programmers upset with me, but with everything having touch screen functionality and Windows really pushing touch screen on their PC OS, and visually being able to tell what things are at a glance simply by shape & color, (aren't shapes and colors more fun smile.png ), I just think this is the future.

 

From what I've seen, the biggest failures of "Visual Programming" are the ones that more use your normal Windows OS controls like dropdown boxes, and such to make links between components and all of that. I agree that method is horrible, but flowgraphs use color and shape to represent things which makes it much better. It uses lines to show the flow where some of these other visual programming languages in the past didn't. There is a big different between some of these "visual programming" tools.

 

Alice is one that many people use as an example but I'd say take a look at Alice http://en.wikipedia.org/wiki/File:Alice-2-screenshot.jpg and then take a look at Kismet http://www.gatheral.co.uk/images/blog/udk_warehouse_kismet_onoff.png. It's like night and day. Kismet at this time is higher level, but it could be lower if they designed it that way.

 

 


It would certainly make low level programming a lot easier

 

 

At this point in time it would not. The reason being it can take a lot of nodes, and so screen space, to represent something that maybe 15 lines of code does. That's one reason why people say it's a pain in the ass to use.


Edited by rpiller, 06 December 2013 - 04:30 PM.


#7 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 04:33 PM


The reason being it can take a lot of nodes, and so screen space, to represent something that maybe 15 lines of code does

 

Good point! That was what I saw with Game Maker (even when I was looking for visual programming). It was much shorter to write a line of code than having to use all these connections and stuff. That is why I think the Editorial app uses a snippet system. Yet it does allow full python programming, which makes it that much more powerful. 

 

And you are right about it opening up programming to a whole new audience. Looking at the responses to even the Game Press app, people who have never programmed a day in their lives can get a game up and running in a matter of minutes. 

 

Then i saw the responses of people who use the Codea app the ipad. They were looking for power and flexibility. Thing is, quite a few of them saw how powerful it is. And a lot of them wanted to know if they could export an ipa version of their game (I suppose this is against apples's terms though). I truly believe I can make a full featured game with Game Press' node based system. 

 

Also, I just watched a video on Node Box. They have several versions. They have a version called Node Box OpenGL. This version is more textual. The company has been pushing Node Box 3 (the one I downloaded) because perhaps they see the future benefits of developing such a system. 

 

I am glad to see that someone with your experience can see how this type of programming might be the way of future programming (as you said, especially with touch based devices and things.) 

 

I will be doing more research into this. 


Edited by Tutorial Doctor, 06 December 2013 - 04:34 PM.

They call me the Tutorial Doctor.


#8 NightCreature83   Crossbones+   -  Reputation: 2485

Like
0Likes
Like

Posted 06 December 2013 - 05:17 PM

 


these tools are a pain in the ass to use for more advanced needs and typically have some way to insert "real code" into them for these cases.

 

Yes, I think this is even why Game Maker has a "real code" feature. I do think Node Box has a real code feature also. 

 

Even the ipad App "Editorial" which uses a sort of snippet system has a "real code" feature. 

 

It seems it would take a stroke of genius to break free of textual programming. So much of our communication is done through either spoken language or written language. But then the information we speak or write comes from the information we have gathered through seeing and hearing. 

 

When I look at a long page of programming, I cannot see the program that well. When it is compiled and run, I can then see the product of the program. 

 

It just seems that a node based system can be more representational of what actually happens both at the hardware level and software level. Things such as memory allocation and pointers and such. It would certainly make low level programming a lot easier. 

 

I dont believe we will ever get away from textual programming for the none trivial problems, there is just not a clear way of presenting a node graph that does something complex, sub graphs help but then you are staring at a magic box in the graph until you open it and see whats underneath.

 

The closest thing I have used that is useful in a graph based approach are petri nets and thats only a modeling language to show how systems interact with each other.

I think we are stuck with text and that's because math is thought that way and fundamentally programming is a math based activity.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#9 ApochPiQ   Moderators   -  Reputation: 12400

Like
1Likes
Like

Posted 06 December 2013 - 05:38 PM

Visual programming was "destined to be the future" in the early 1990s when I started programming. It wasn't a correct prediction then, and I doubt it's a correct prediction now.

 

There may be aspects of programming that become "less" textual, and/or drift away from file-oriented code; in fact I'm working on such a language project right now. But overall, I think the fundamental principle of expression programs using comparatively terse textual symbols is here to stay.



#10 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 05:44 PM


I think we are stuck with text and that's because math is thought that way and fundamentally programming is a math based activity.

 

I think math is easier seen in a node based system actually, when you think of how original math was done. Node based systems are used to do very complex graphical computations as in Blender's cycles. They have the Add node and the Multiply node, which we would understand textually as a function, but in a node based system as a node that takes however many input values and adds them together and outputs the result either to another node or to another function or whatever else.

 

From the video of NodeKit that I posted he shows how he can look at the flow of the nodes as text also (that setup just feels right). It is like opening the hood of your car to see what is underneath and tweaking things a bit if you need to. I mean, they actually used NodeKit to produce the app TapTool which is currently on the ipad and can do some pretty neat things from what I am seeing. 

 

I have always been one to think outside the box. But at least in this case, I am thinking within the box. 


They call me the Tutorial Doctor.


#11 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 06 December 2013 - 06:07 PM


It wasn't a correct prediction then, and I doubt it's a correct prediction now.

 

It depends on how far in the future they were thinking. 

 

What we now call "Apps" I had the idea for a while ago, before the first mobile iDevice was even made. I have been into software for a while now (not as long as perhaps many people here) and have been researching all sorts of software and reading documents on all sorts of technologies (ever heard of 3dfa?) hehe. 

 

My term for "Apps" was "Single Task Programs." I actually had a bunch of these single task programs on my computer. I didn't need a whole program that can do 1,000 different things. Maybe I just wanted to do one specific thing, but do it really well and quickly. Then, if I need something else done, I go into another single task program that will do that thing for me. To me, this was a faster way to work. Each program was for one specific task. This meant it was much lighter and loaded quicker. And it is easier to add features to that task than to have to edit a whole software. 

 

Even now, this should be the focus of App designers, but I see a lot of app designers aren't doing things this way. They want it all in one app. I would surely like to see a graphic design suite in an App setup with 3 distinct apps that all flow together. Each app does it's task and exports to another app. 

 

I mean, how much flow do designers have in their workflow? It seems that it is all chopped up and spread across various software, IDEs, libraries and APIs sometimes. So some people thought to make custom software to do their tasks. 

 

This is the main reason NodeKit was created. 

 

It is kinda like how Apple transformed the way people use phones. They did it "right." If a node system were done right, I can see it being the future of programming for games, video, sound, graphics etc (and it sort of is used already, just at a more proprietary level.) 


Edited by Tutorial Doctor, 06 December 2013 - 06:08 PM.

They call me the Tutorial Doctor.


#12 rpiller   Members   -  Reputation: 634

Like
0Likes
Like

Posted 06 December 2013 - 08:36 PM

I agree that if someone comes along and implements a flowgraph system well, then it can make all the difference in the world. I've thought about making a flowgraph system that's like Kismet but has C++ features and the flowgraph interpreter would be a C++ source app. You'd be able to make class like structures/sub flowgraphs, and all the basic math nodes, variables, etc.



#13 swiftcoder   Senior Moderators   -  Reputation: 8101

Like
1Likes
Like

Posted 07 December 2013 - 07:48 AM

Visual programming is more usually termed Flow Based Programming. You will probably get more current results using that as your search term.

 

You would probably also like "live programming" (see this Microsoft research project for a soft introduction). It retains many of the benefits of node-based programming, while behaving more like a textual programming language.


Edited by swiftcoder, 07 December 2013 - 07:50 AM.

Tristam MacDonald - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]


#14 rpiller   Members   -  Reputation: 634

Like
0Likes
Like

Posted 07 December 2013 - 09:32 AM


It retains many of the benefits of node-based programming

 

 

I don't think (for me anyway) a huge benefit of node based programming is seeing your code actually run, but more just seeing your code with more visual hints as to what you are looking at. It also helps remove the idea of "syntax". Flowgraphs generally all work the same in connectivity. I know probably 10+ languages that I actually use all on at least a weekly basis. I find myself mixing the syntax up between them all the time. It's rather annoying. Why in the world do we accept all the different syntax's that exist when we all know it's the logic that matters?

 

I equate this to Window based OS's vs console based. I think we all agree that using the console can be more efficient but you have to spend way more time learning the specific commands of that console based OS. Each one may have different commands and let's just face it, we are visual creatures. Some may be the same with slight differences and if you switch between them all the time it can be a pain. With Window based OS's you can visually just make things out and work them out by looking with your eyes. Guessing what to type is a lot harder.

 

There were way more technical people back in the day that wouldn't leave their console based commands and hated using visual OS's. You weren't looked at as a series tech guy if you didn't use console commands. Doing things visually was for "kids". Along came Windows and 30 some years later that's just not the case anymore. I think the same will happen with programming and we are just in the starting years of it getting good. I'd equate visual languages like Alice to be like Windows 3.1. It's a little visual but not what Windows 95 was at all. Alice is considered visual programming but it's NOTHING like Kismet. Just like Windows 3.1 is nothing like Windows 95.

 

The cool thing is that video game development is driving the flow based programming movement.


Edited by rpiller, 07 December 2013 - 09:35 AM.


#15 swiftcoder   Senior Moderators   -  Reputation: 8101

Like
1Likes
Like

Posted 07 December 2013 - 10:02 PM


Doing things visually was for "kids". Along came Windows and 30 some years later that's just not the case anymore.

I'm pretty sure it's still the case. If I catch a co-worker manually renaming a hundred files because they don't know how to use bash + regex, I will laugh at them...


Tristam MacDonald - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]


#16 Chris_F   Members   -  Reputation: 1659

Like
1Likes
Like

Posted 07 December 2013 - 10:12 PM

I can't stand visual programming. It's used by all the major game engines and is treated like a selling point. I guess the idea is that because it is "visual" it is somehow easier for non-programers to use. There are just a few problems with that. For starters, why are you having non-programers program your game in the first place? That sounds like a recipe for disaster. Secondly, visual programming becomes a incomprehensible mess once you get past anything trivial. Lastly, you still have to actually learn how to program with the "visual" tools. You could just as easily spend that time learning how to program in a textual language. You'd not only be more productive when you set out to work on non-trivial things but you would also have acquired a skill that more easily translates into other areas.



#17 jbadams   Senior Staff   -  Reputation: 14829

Like
1Likes
Like

Posted 08 December 2013 - 12:28 AM

A couple more examples include Scratch, the events system in Construct 2, and PlayMaker.



#18 rpiller   Members   -  Reputation: 634

Like
0Likes
Like

Posted 08 December 2013 - 09:38 AM


I'm pretty sure it's still the case. If I catch a co-worker manually renaming a hundred files because they don't know how to use bash + regex, I will laugh at them...

 

Until a visual app comes along that helps. That's the point I'm trying to make. We generally always start out with just commands and then someone comes along and puts a visual to those and then in general it makes the functionality usable by people who don't know the commands or how to use them, or possibly even know that they are using them behind the scenes. That's a good thing in my mine.

 

It's a start in the right direction to make it more accessible. 

http://www.regexbuddy.com/



#19 swiftcoder   Senior Moderators   -  Reputation: 8101

Like
0Likes
Like

Posted 08 December 2013 - 11:01 AM


Until a visual app comes along that helps. That's the point I'm trying to make. We generally always start out with just commands and then someone comes along and puts a visual to those and then in general it makes the functionality usable by people who don't know the commands or how to use them, or possibly even know that they are using them behind the scenes. That's a good thing in my mind.

I don't think it is true, however. Visual approaches are fundamentally limited by the expressiveness of visual constructs, and the available screen real-estate.

 

Certainly, one can create visual tools to encompass any particular class of common operation, but there simply isn't room on the display to provide the entire functionality of the unix command line in visual form. And even if clever UI design can mitigate that problem, the iconography require to represent such a range of concepts will be no less arcane than the current textual interface.


Tristam MacDonald - SDE II @ Amazon - swiftcoding        [Need to sync your files via the cloud? | Need affordable web hosting?]


#20 Tutorial Doctor   Members   -  Reputation: 988

Like
0Likes
Like

Posted 08 December 2013 - 05:07 PM

A couple more examples include Scratch, the events system in Construct 2, and PlayMaker.

 

Those don't look like node based engines. They are visual programming engines, but I am speaking of node based programming specifically. Also, I have provided links of examples of node based programming that have been used to create not-so-trivial products.  


They call me the Tutorial Doctor.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS