Jump to content
  • Advertisement
Sign in to follow this  
rraallvv

Developing games with the Flow-based programing paradigm.

This topic is 891 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I came across FBP while searching for a Polymer web component to add a visual scripting tool to the brand new IDE Cocos Creator for Cocos2d-x.

 
Since FBP seems to have gained some attention lately thanks to Flowhub.io and NoFlo, with additions like runtimes for the Arduino, GTK desktop or python. I wonder whether  it is feasible to start using those tools for developing games.
 
For the game developer it would be just a visual scripting tool that wold work for anything, including the back-end, with support for extensibility and integrated  with collaboration tools that we already are familiar with.

Share this post


Link to post
Share on other sites
Advertisement

I wonder whether  it is feasible to start using those tools for developing games.

I don't know about those tools in particular, but flow-based programming has been popular in games for a long time :)

Share this post


Link to post
Share on other sites

Most of my engine's core functionality (e.g. communicating position of an object from physics to graphics, animation bindings, sound DSP processing) is abstracted as data flows between arbitrary object pairs. In the editor, objects declare their input and output connectors and the user can drag to create connections between them. An "entity" is just a collection of objects with their connections (also encoded as small objects). Each data flow connection can be set to update either before or after a specific engine subsystem, and the engine batches the updates in the correct ordering based on the connectivity between objects. Each batch, if large enough, can then be broken down into disconnected "islands" that can be executed in parallel on a thread pool. 


In theory, nodes in the graph can perform arbitrary math/logical operations so it could be used to implement more complex logic or used as a more general-purpose multimedia processing system.

 

A hard bit in implementing something like this in a large system is that the number of possible type interactions is O(N^2). To avoid that you must decouple the two endpoints of a connection, such as by writing the data to an intermediate temporary storage before reading it on the other endpoint. A connection consists of two Connector subclasses with read() and write() methods, plus a Connection subclass that contains the temporary storage. Then, the number of required connector types is just O(N). My system has over 50 node types so this a big win in code size.

Edited by Aressera

Share this post


Link to post
Share on other sites

@Hodgman @Aressera

 

Thanks for your comments.
 

I was worried at first about the overhead and memory footprint mostly due to the messaging system and multiple threads, but now I am more confident. Also the developers of MicroFlo seem to have embedded the FBP runtime in the Arduino and the Embedded Linux, that speaks a lot in favor of FBP, since typically those devices have much more limited capabilities than most gaming devices.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!