Sign in to follow this  
rraallvv

Developing games with the Flow-based programing paradigm.

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

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

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