Developing games with the Flow-based programing paradigm.

Started by
2 comments, last by rraallvv 8 years ago

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

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.

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

This topic is closed to new replies.

Advertisement