GSoC project: Hive system for Blender: Nodal logic!

Hi!
I’m Spencer, and I’m going to be working on the Hive system GSoC project in the Swiss cheese branch. I thought I’d introduce myself and the project.
The Hive system, by Sjoerd de Vries, is a generic was to implement game logic. It uses nodes (called bees) to define behavior given circumstances. My job will be to build this into Blender, so that (eventually) we can have a more extensible and robust logic system for the BGE than the logic bricks editor. Here’s my formal proposal. For now, it will use an external editor, and will probably require knowledge of Python to use.
Feel free to ask any questions you have about the project!

Sounds great, I look forward to seeing how this goes!

One question: why would the user need to know Python to use the Hive system?

Fantastic! I loved the system of Logic Blocks, but this is looking to be a step in the right direction. How would this system allow for more extension to the blender game engine? I’ll definitely be watching this space.

Ahh, don’t replace my logic bricks! :o

There is not much documentation to see regarding Hive.

I had a quick look at the demo presentation. It looks more like a visual representation of Python code rather.
It more or less looks like a script language with a GUI editor.

I think you can “visual” program your python controller in opposite to write python code as text. Beside that the proposal does not tell much details.

Is Hive an own interpreter?
Does it convert it’s internal node graph into Python and/or vice versa?
How does it integrate into the Game Loop?
How does it integrate into the existing event system (SCA) of the logic bricks?

With Blenders Node editor it should look much better as in the demo. In the demo it seems to be pretty low level. Even the simple demo is not easy to understand.
Will there be some supporting workflow (auto-reorganize nodes, collapsing/expanding groups of nodes, encapsulation etc.)?
Just some thoughts.

In my understanding the principle looks very similar to the Microsoft Visual Programming Language (VPL)", of which a summary description is found here: http://msdn.microsoft.com/en-us/library/bb483088.aspx and which is mainly oriented to robotic applications.

I think it would be useful to have a similar programming environment in blender, in particular if components (“bees”?) and functions can be customizable in python and reusable. I mean as an alternative, not necessarily a replacement, of the existing logic bricks.

I hope you will keep us up to date about your progresses.

It seems pretty interesting, the only thing i dont want to change is the GUI (i mean an intuitive gui is needed.)

In its first stages, Python may still be needed to help bind Blender functions to Hives.

At the moment, Python can be used in the BGE, but at least some logic bricks are needed to bind them together. Part of the project will be to add Python bindings directly to Blender so that’s not needed. Also, Hives (Node groups) and custom Bees (Nodes) will be able to be compiled to Python to be re-used and shared with others.

The Hive system “compiles” node systems into Python, to be run by the game engine.

I’m not completely sure yet. What I think will end up happening is that every node will be run every frame, and custom nodes will have some “update” function.

It will run alongside the existing system.

That’s the job of the GUI designer, which will be for later. If you want, you can try the wx GUI now, though.

Ah, thanks mb10! And like you say, it would be nice to have this as an optional extra to logic blocks.

This sounds like a Hive controller beside the Python controller

This method will not just bypass the event system it completely removes it without a better method. In terms of performance regardless what system is used any code should only run if needed.

A controller executes ONLY on event from sensor.
Actuators can be enabled and disabled. They run between this signals without additional trigger.

It might be worth the create a HIVE actuator too. For unknown reasons the BGE does not have an Python actuator.

Wait, I’ll need to know Python to use this?

Just like with many Blender projects, functionality comes before user-friendliness. I think Python knowledge will only be required for the first few weeks during development. After the project’s done, you shouldn’t have to see any. :slight_smile:

Thanks for clearing that up. Will everything that was in Logic Bricks be in this? What’s the advantage? Can someone please give an example? Sorry for my confusion and thank you.

I think the goal is to, eventually, replace logic bricks. It will be a while, however, until it becomes a complete and usable replacement. Sensors and actuators will become nodes, not the other way around. Like mb10’s example, it’s supposed to be a visual programming language for the BGE that anyone can use.

In my opinion, this is a different system. The SCA game-loop is just one implementation of game logic. The Hive system may be different, however - depending on what it defines as a trigger. I believe each node calls the others when needed, however in order to do so they need an initial trigger. It is at this point that they are required to run every frame to poll a sensor. I would treat it as a differing system to logic bricks.
However, my major concern will be in how the two systems can run alongside each other.
See this example:

SCA:
A property sensor detects a property equalling x. It then proceeds to move the obejct x units.

Hive:
A property is changed from y to x, waiting a small duration then changing back to y. In this event, the SCA may detect the change, whereas there is no net change.

although this is the worst example i can think of, i am worried about the differing time frames. In any case, if the HIVE system is solidly integrated, I would likely choose a Node setup over the logic bricks. Complex logic bricks systems can be slow, due to the non-linear method of processing. For complex systems such as inventories many people use Python, and again many of us run it every frame in order to handle various conditions. In this case, the Hive system would show no negligible difference between a or b, except b is cleaner.
I think it would be a good idea to separate the systems - as you can choose the engine in blender, also choose the logic system. Then, you could work on converting SCA setups to Hive setups.

The new system actually is a scripting system. Hive runs on top of it by creating Python scripts based on Hive node groups.

If it’s too confusing, here’s the way it works. A new scripting system will be put in place into the BGE. This will use Python, not Logic bricks, and can work standalone. If anybody wants to use Python completely, they will be able to quite easily. Then, the Hive system uses this new scripting environment to control the game engine. The Hive’s behavior is defined by nodes, which can also be written in Python (or C, if you’re daring :slight_smile: ) and put together by the end user with a nice interface.

Just one thing to say:
I loved it xD
Thanks for that great GSoC project!

In the last year was started one other project about nodal logc bricks (about hive too I think) but it was canceled in middle.
I hope this one keep active until the end xD
Good Luck!

Duplicated post (remove please)

Yes, that was a different system, however Hive is based off the concept, so it is useful!

Interesting stuff, I really like the idea of being able to use just python.

One question: how will this affect logic performance?