• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Tutorial Doctor

Examples of Node Based Programming?

30 posts in this topic

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:
http://www.youtube.com/watch?v=OZUNhviJLr8

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:
http://vimeo.com/54523585#at=85

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:
http://www.youtube.com/watch?v=HCwnCQuyjJo

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:
http://www.youtube.com/watch?v=LI6mcUH30bI


Additional Stuff:

Programming with Nodes in Blender 3D:
http://vimeo.com/13495148

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
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites
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."
2

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

 


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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites


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. 

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
1

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites


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

1

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites


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/

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites

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.  

0

Share this post


Link to post
Share on other sites

Visual approaches are fundamentally limited by the expressiveness of visual constructs, and the available screen real-estate

 

3D modeling programs are a visual approach to 3D modeling without having to type the code for a box to render it on screen yourself. I don't have to learn DirectX or OpenGL to model a cube. I can just hit the "Cube" button. 

 

This example makes 3D modeling sound trivial, but we all know that 3D modeling programs are very powerful. Why should everyone have to learn OpenGL and such to create a 3d model? Even though these 3d modeling programs are created textually, we interact with them visually. It would be the same for a node based system in programming. There wouldn't be any additional limits by simply changing the way we interact with code (which is really what is happening).

 

So I'd have to disagree that Visual approaches are fundamentally limited in the way you describe. 

Edited by Tutorial Doctor
2

Share this post


Link to post
Share on other sites


I can just hit the "Cube" button.

And when you want a fish? I highly doubt there is a fish button. How about a giraffe button? When do you have too many buttons?

 

But regardless, that's not what I'm getting at. A 3D modelling package is a comprehensive tool for a particular type of task. What exactly is grep, in isolation? Grep doesn't really do anything interesting without all the magic of cat and pipes and awk and sed and cut and file descriptor redirection...

 

It's a ridiculous amount of work to try and squeeze all that functionality into a single visual tool. Current graphical shells (Windows Explorer, Gnome, Mac's Finder) still pale in comparison to the power and expressiveness of the textual Unix shells that significantly pre-date them.

0

Share this post


Link to post
Share on other sites


When do you have too many buttons?

 

Any other model would be a manipulation of the primitive geometry. The thing is is that nodes can be made. 

 

I understand that there is no getting away from text. I remember using the LittleBigPlanet logic system and quickly realizing that it needs textual info. Everything was visual. You had to visually represent numbers even. It was terrible. 

 

On the other hand you have entirely textual systems (what we see in our IDE). A node based system would be a merger of the two systems.

 

Again, the NodeKit software I think is the best implementation of such a system. 

0

Share this post


Link to post
Share on other sites

Quote


It's a ridiculous amount of work to try and squeeze all that functionality into a single visual tool.

 

 

If you are selling the product then it may be worth the work.

 

 

 

 

Quote

Current graphical shells (Windows Explorer, Gnome, Mac's Finder) still pale in comparison to the power and expressiveness of the textual Unix shells that significantly pre-date them.

 

 

 

And yet throughout the world graphical shells are used way more commonly (in terms of all computer usages) than the consoles. There will always be text programming, but just like in graphical shells for OS's, the majority of programming (I think) will be visual/graphical at some point. Like the mouse changed graphical OS's forever, so will touch screens for the PC/mobile change programming. We are very early in the touch screen life. We just got our first PC touch screen focused OS last year with Win 8.It's going to take a few years before using touch screens for our PC becomes the normal, and then the other things will follow including (I think) more node based visual programming. Today visually programming with a mouse isn't as smooth of an experience as doing it with a touch screen, and since almost all programming done on the PC vs mobile devices, this is the beginning.

Edited by rpiller
0

Share this post


Link to post
Share on other sites
I've been programming for a damned long time.

I've seen a lot of trends rise and fall, and heard countless predictions about the future of software development. I've even made a few such proclamations myself.


People suck at predicting the future, and they suck even harder at predicting the future of a relatively nascent discipline like software development. My money says that virtually every definitive statement about the future (or even trends) in this thread will turn out to be false.

We can talk about what we'd like to see, but stating predictions as facts is a bit disingenuous.
2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0