Hopefully (and probably) for the better!
This project sounds great impiaaa!
I wish you good luck and hopefully you will do good with your hive implementation!
If I understand it right: You want to introduce a new Game Logic system based on Python. On top of this system you want to run Hive?
I think that’s the way it will pan out, yes. The Blender GE-Python bindings will be build to work best with Hive, though. Much of the integration structure is already in place in Hive but will need to be extended.
This it sounds a bit like the moguri’s component concept. A component acts like an Always sensor is constantly triggering a Python controller. But they are not integral part of the logic bricks (a bypass I guess) which allows the user to skip two clicks. A component belongs to a single game object. The benefits I see are
- it can provide predefined parameters via GUI and
- it is relative easy to setup (equally to setting up an Python controller).
The drawback is that it is limited to Python code without multi-object logic. (In difference to Groups which provide better inter-object logic and object encapsulation, but lack of user assistance)
Still the question is how do you want to fit Hive into the GameLoop?
How to connect GameObjects with Hive code?
I guess you do not want to have a single Hive setup for a complete game.
Do you have a sketch/overview/presentation how a user would use Hive within the BGE?
I mean something that explains how to connect Hive code with a Game Object, an animation or the scene.
I think the most asked question here is:
How to implement FPS mouselook (mouse base camera rotation + keyboard based character movement)?
How would a user implement this example with Hive? How would another user use this implementation and customize it for its needs (e.g. other keys, mouse based character movement)?
I really want to understand the outcome of such hard work and what the result is expected.
What can the new game logic system provide what the current system can’t?
I think newbies can benefit from the visual editor even if it looks as it provides the same level of abstraction as pure Python code.
What can Hive provide what the current system can’t?
Hi, this is ben2610, it’s been a long time. I’m back on BGE business this year by mentoring Spencer on his GSoC project. I am very pleased to see the interest raised by the hive project. I believe that the hive system has great potential and will become at some point the preferred method of logic programming in the BGE and also other game engine.
I’ve read the questions in this thread and I thought that I could give a quick overview of the hive system for those who don’t feel like reading the documentation 
The hive system must be seen as a programming language. The functions are nodes (bees), the syntax are connections between compatible pins (socket and plugin) and the node group (hive) constitute the whole program. As in all programming language, there is a compilation stage that converts the hive into an executable program. The compilation is done by registering callback functions: when you connect plugin to a socket, you tell the compiler to call the registration function associated with the socket passing the callback function associated with the plugin as argument. Of course both functions are bound to bee instances so that the registration is specific to one hive instance at runtime. Note that you don’t need to explicitly connect plugin and sockets all the time, many connections are done implicitly (based on name matching), e.g. the event handlers plugins that are automatically registered in the hive system.
At runtime, bees calls themselves directly via the callback functions. Hence, there is no big brother engine that interprets the hive. This has several key advantages:
- there is little overhead at runtime
- the compilation can potential go down to C++ functions calling themselves directly if bees are C++ optimized (a design document for writing C++ bees exists)
- global python optimization method can be applied
- a compiled hive can be used as a bee in a higher level hive
- there is no limitation is what you can do in the hive system, it’s a full blown programming language.
There are some drawbacks though:
- it’s possible to create a hive with a logic loop that results in stack overflow at runtime
- the only entry points to the program are events: if you want to write a bee that runs on every frame, you must write it so that it sends an event to itself.
- you don’t control explicitly the call flow: depending on the order in which the callbacks were registered (alphabetical order atm), certain parts of the hive will execute before others.
- adding custom python scripting must be done in compliance with the hive syntax, which is not easy to master.
However, the hive system is very flexible. I already discussed these limitations last year with Sjoerd and he was able to address some of them on the spot.
To answer a question about how the hive system fits in the BGE: it replaces completely the logic bricks; the logic step simply consists in calling the hive event dispatcher function that takes the events on queue and send them to all registered plugins. The logic step ends when all events have been dispatched. The events can be posted by the bee themselves or by BGE middle components that exist already (keyboard events) or will need to be implemented to provide the hive system with a rich set of events (e.g. bring rich physics events to the hive).
I hope I didn’t write stupid things in this description, if so Sjoerd can correct me.
The goal of this GSoC is to bring the hive system to a state where it can be used by non programmers to develop complex game logic with complete access to BGE components (physics, animation, scengraph, etc). For programmers, we will try to provide a framework to wrap automatically simple python script in a bee. It is an ambitious goal but with Spencer full-time and the help of Sjoerd it is achievable considering that a basic implementation for the BGE already exists. If some of you feel interested in helping, they are more them welcome.
As I’ve said before, this looks to be a very interesting approach.
My only concerns at present relate to the Blender Integration.
I am never one to like to completely change a system, and I don’t neccesarily believe that it would be in everyone’s interest to migrate to Hive.
For some, it may be faster to use Logic Bricks. For others the SCA concept may be a good introduction to the programmers mind path.
My proposal for your user interface was as follows:
- Enable the user to switch the logic engine, as they can with the render engine. This would disable the alternative logic system from execution, ensuring that there are no compatibility problems. This could be a hard task, so if this is not possible, I would still attempt to keep the systems side by side, rather than replacing the Logic Bricks.
- Modify the existing node window; renaming it to “Material Nodes”.
- Create a new node window named “Hive nodes” or “Logic Nodes”
- Use the same code base for material nodes to introduce Hive nodes, saving time and ensuring all programmers familiar with Blender nodes to work with Hive modifications.
Also make sure the overflow ends the game, not crash.
I have another, deeper modification, which may not be desirable but let’s just consider it.
It seems inefficient to have have two separate instances of an ultimately identical user interface.
Here is a separate design proposal:
- Move the Hive nodes into the existing Node window. Allow the user to switch between Game and Material nodes.
- Move the Game panel properties into a separate panel in the properties window.
- Rename the Game window (currently home to logic bricks, and without properties) to Game Logic
This reuses the node panel, and means that the user can find “hive nodes” where they would expect - in the node window.
It also means that the user can find properties where they would expect - in the properties window. I shall make some mock ups at some stage.
I agree with agoose,
it should be up to the user what system to use. otherwise the BGE would fork here.
The best of both worlds would be if both systems can coexist.
From experience of other systems like this (PlayMaker in Unity, for example) it does not grant a huge benefit to beginners / intermediate users as logic bricks do a great deal of work for such a simple system. For example, the constraint brick allows me to make a hovering object that keeps a certain distance from the floor- in PlayMaker this is much more complicated to set up as by its nature you have to build / organise things from scratch from lower level components.
I don’t know. I look forward to this as it is an exciting new development, but I also fear for it as it will form the core of the BGE ‘experience’. I suppose it will be a case of a balance between function and accessibility. Existing logic bricks are a good draw as they are simple, reliable and can do a great deal. If that changed to a system that is ultimately more flexible but required much more understanding it may put people off and wither the BGE.
I hope this does not sound too negative, I am actually very excited about this:D
PLease, for god’s sake, make the connectors nice and big, so they are easy to wire together.
The current node and logic block “wiring posts” are really hard to use for me.
What would be nice is if we could do a trick like: Select 1 node then hold control and select another to automatically connect them.
Or have it “daisy chain” with the right mouse button, or middle mouse button. User rightclicks on one to start the chain, then automatically wires to any other block you right click on afterwards.
I am not as dexterous as I used to be, and those microscopic posts on the current logic bricks make me want to cry.
There is absolutely no reason for it to be as hard as it is now.
This is looks very interesting and it seems can be really useful for non coders (like me :o). However the stability of current BGE are often still questionable, especially after BMesh release. I can’t even save a game as a runtime during BMesh release.
From my understanding, with the incoming of Harmony and Candy branch, BGE will probably need alot of works to make it very solid and usable. With this Hive system being implemented, will it be okay? More improvements like this for BGE are most welcome imho, but solid and usable engine is also very important. It’s kinda scary if user can’t fully use BGE for several Blender releases. There should be a way to avoid this right?
Is there any other game engine out there using this hive system yet?
I’m not in charge of the GUI, but I’ll see what I can do!
The Hive system’s been/being developed using Panda3D.
Try a newer build from GraphicAll. Many bugs have been fixed between 2.63 and the current build.
Here are some more hive system specifics, in addition to what Spencer and Ben already explained.
The hive system consists of three layers:
-
A component-based (code) programming framework written in Python.
This layer is designed to be very flexible: encapsulation, customization, object inheritance and exception handling are all supported at the component level. -
A parameter-based (data) representation that is converted into code
-
A visual representation which is generated from the data
Programmers can write new components (bees), and edit parameter data, in Python.
Non-programmers can configure and connect the components, and edit parameter data, in a GUI
The hive system is obviously still in development.
Since layers 1. and 2. are much more mature than layer 3., the hive system is, for now, much more usable from Python than from a GUI.
There is an external wx GUI to connect nodes, but it is really a simple demo.
The looks and workflow will be addressed at a later stage, when BGE integration is more mature.
The visual layer works on the data layer, completely separate from the node mechanics. Therefore, if there is disagreement on the looks, alternative GUIs can easily be developed.
The hive system in the BGE has its own mainloop, and its bindings are through the bge Python module. It runs independent of Logic Bricks, not interacting with them at all. So there is no conflict with Logic Bricks.
The hive system can run on top of any game engine (with Python bindings). It has also been bound to Panda3D
The hive system is event-driven, a bee will only run every tick if it is listening for “tick” events.
This is really exciting to me. I have spent a lot of time thinking about a node integration of logic. I have a lot of expectations about how it will be implemented. But for now, I will wait until you develop this further before I start discussing them.
I do have one question, will there be nodes that parallel current logic bricks? (like a keyboard input node linked to a motion node)
Also agreed here, because there are some here who would face a tremendous amount of work if they had to migrate all their games to use the hive system, especially if they have to redo all of the logic being supplied by hundreds of bricks and thousands of lines of Python code.
Having the two systems together would at least ensure that games made in earlier versions of Blender would run smoothly with all logic intact. One could perhaps even allow this ability to switch logic systems on a per-object level, so if you wanted to convert the logic to hive, you can do so one object type at a time to make any transition work go more smoothly (as the bulk of your game would still be working then which you allow to just test the workings of the object or set of objects in question)
This is an nice proposal, however my original proposal to separate the logic engines was primarily because i was concerned about timing issues which may arise by using different standards (Logic bricks / Python hive)
I think such timing issues have to be taken into account when implementing Hive. Bullet2 is a scene modifying system too and it works pretty well.
There might be some assumptions for efficient processing that might break when adding Hive, but this must be tested. It would be the responsibility of the “Implementors” to preserve the backward compatibility.
If anybody’s interested in the progress of the project, I just finished adding bare-bones sound support, which you can try with this blend than Sjoerd put together. You’ll need to have this and this checked out into Blender’s modules directory, as well as a build of the Swiss Cheese branch with the GE and some codec enabled. Use WASD to move, and the middle and left mouse buttons to attack. The middle-mouse button is the one with sound, but you can change that in the script pretty easily. You can also change what sound it plays.
Can’t wait to try it! I will let you know how it works!