HIVE development is currently paused whilst I start university. I have little time outside of my course and my job to develop it to the level it demands.
This does not mean that it won’t be developed. It’s quite an extensive system, which requires careful thought about future development. One particular case is that I would like for HIVE hivemaps to be functional in either Panda3d or BGE (and any other python environment) without requiring any node modifications. This requires some careful abstraction layers and consideration where features are not easily mapped between platforms.
On top of this, I’d like to do some serious refactoring, both in the initialisation routines (which are currently a bottleneck) and general code architecture, to improve stability. All in all, it’s not a small task, but as ever, I shall complete it (if that’s a feasible goal)!
I give this a 20 percent chance of actually making it in as a formally integrated plugin for the BGE.
I may sound pessimistic, but the track record of big-ticket BGE projects almost always ends with them slowly dying out. I’m tired of getting burned after getting excited about these types of projects (and the rather decently-sized todo list for this one done during one’s spare time doesn’t help). This has been in the making for nearly four years now, you can only say that for so long before you figure that its inclusion is unlikely.
My secret hope though is that the new group of people working on the BGE source can turn this track record around and actually get substantial development done, but it’s likely the last chance that the engine has if it doesn’t want to seen as something that’s imperative to remove from Blender.
To be fair, phase one of Harmony made it into Trunk. Though I regret not getting phase 2 polished enough for code review. It was at a pretty solid proof of concept stage, but unfortunately cleaning it up to a merge ready state was a large, and not nearly as interesting, task. As an aside, the work I did in Harmony was very helpful for my thesis. The Harmony project is still on my mind. I am often thinking of how best to take the prototyping/proofs of concept from Harmony and get them properly into Blender. This is complicated by my shifting thoughts on what I see as the future of Blender and the BGE. I am certainly not promising anything, but it may be about time I think harder about it.
Well the BGE needs a major shot in the arm in terms of development if it ever wants to be relevant again and possibly have a chance to remain a part of Blender (hence why I now lean to Godot, their big-ticket project items are actually getting done practically on a monthly basis).
Would it be possible to make HIVE easy to incorporate with other addons, such as Blend4web and BDX. So decouple it’s code from BGE and make it easy to use with other engines.
Ton annonced that BGE is going to lose support from the foundation as a game engine. So imo the future is in these other engine plugins.
Hive can here be a visual programming framework that they can take an advantage of. You should get in touch with the developers there and see if you can collaborate. Make it easy to adopt for other developers, get them to collaborate with you.
Running away from the focus of this section, fully support the idea of making a Fork of BGE, separating it from the Blender and making it a sort of add-on similar to Save the Run-time, that was the part by parting shot CRC to remove this native feature of BGE. So I think that will have a chance of becoming what your actual users want: a modern engine but with no claim to compete with the market but meet the needs of its actual members, most hobbyist.
As for the support of BF will BGE, the vast wasted was open during the game Apricot. After that, nothing more was said officially. Perhaps because the area of game desing is not so interesting in the eyes of BF, as it is open movies.
That is the reality. They say the blind as those who will not see. I fully agree with that.
The history of HIVE is somewhat marred by the GSOC project, which was, in essence a disaster. This is not something that the GSOC student can entirely be faulted for, because not only is Blender an extensive application demanding of dedication to become familiar with, but HIVE itself is incredibly deep, as applications go. Hence, the GSOC project was not something remarkably effectual in delivering an end result.
The important thing to note here is that in terms of active development time, HIVE hasn’t been focused upon in the last year and a bit. I spent some time over summer becoming familiar with its internals, and adding features to the Blender GUI and Blender bindings. These bindings did work, and it was at the point where I decided it would be initial release worthy, but the performance of dynamically bound HIVEs was particularly undesirable. Because HIVE hasn’t really been pushed in this regard, I am particularly optimistic that the startup routines can be improved, and I have corresponded with Sjoerd De Vries on this account. I am the “active” developer of HIVE, but I did not anticipate a large project to be demanding of my time, which has been the case with my current employment.
Usually development stalls on large projects because it becomes increasingly undesirable to work on them for reasons of incompatibility, instability or indirection. It is a trend because it either happens or it does not, and in honesty very few projects with any chance of success have actually been undertaken.
HIVE is the most extensible, practical and robust option for Nodal Logic that I have encountered, because it follows a multi-tiered design paradigm which naturally appeals to different levels of complexity (and capability). It separates the visual aspect from the functional aspect, and is built from the ground-up to avoid unnecessary state-management or dependencies outside of the local context. Hive also employs a backend for parametric data modeling (Spyder), which naturally lends itself to GUI support and a vast array of file formats.
If nothing else, my own interests in HIVE will be the driving force for it’s further development, when such a time is found that I am not forced entertain the possibility of attaining a low degree qualification in the process. That moment will come to be, but it isn’t currently the time
This is exactly the design behind HIVE. There is very little BGE code, there is an initialization stage, and particular BGE bindings. These bindings have been some of the trickier aspects to get right, because initially Sjoerd and I had different ideas as to the direction that the support across platforms should take. It was my argument that wherever two systems can be made to work seamlessly, such an option should be entertained. Of course, it is important to allow specific functionality belonging to the platform in question to be supported, so a secondary feature is to include a separate platform-specific collection of workers (nodes) and the relevant drones (interfaces to engine-specific systems) to support them. The BGE and Panda3D (the two target platforms at present) have vastly different interaction paradigms which make it tricky to achieve this in every case, however it is always possible to reduce the feature-rich behavior into a smaller subset of features (usually the BGE), so in many cases the Panda3D bindings will mimic the BGE paradigm (such as object relations etc).
Now, after writing a lot of hyperbole about if, when and why, I will finish with some time lines.
HIVE is not going to be finished in the coming months, nor will it ever truly be “complete”. However, to get to a user-friendly stage requires a few different steps:
Intensive design refactoring for #PEP8 best practices and in-line documentation.
Adding of docstrings to various API methods
Renaming of parameters to verbose, descriptive ones.
Functionality fixes for the GUI
Better state management, rework specific subsystems
This is the current bottleneck in the hive building, I’ve already spoken with Sjoerd on this front, and we have similar ambitions.
Of these steps, the first is quite important for small level fixes and rendering the code workable to larger scale refactoring. I will complete this over the next few months, with infrequent attention to development.
Thereafter, an intensive summer will aim to finalize the GUI refactor and libcontext overhaul.
In essence, whilst I share your reservations to jump at large, golden eyed projects, I will say that HIVE is a large project, and as such cannot be considered something to happen as trivially as overnight. The fact that four years may have elapsed since promises were made of Blender inclusion do not consider the fact that less than a quarter of this was actively focused upon achieving that goal, before the focus of the project was redirected, for intentional or circumstantial reasons themselves.
I was once propositioned by a company to split the BGE into its own codebase and to develop it. My response: they’d be better off writing a new engine from scratch (while using the BGE as a model). If the codebase were not so old and moldy, maybe. It’s one thing to make changes to the BGE code and it’s another thing to get patches in master.
If Blender had a C API, i.e. library, it would’ve been more convenient to write an engine around it, since the BGE is essentially Blender, just a modified form of it that currently coexists.
Personally, I briefly attempted it, but I was too lazy to mess around with the build scripts. Furthermore, it would’ve needed maintenance to stay in sync with the official Blender master (maybe wouldn’t be so bad?). To get mobile/WebGL support, would’ve practically been a rewrite and interfacing with Blender would be another major issue to tackle.
The real killer was I would’ve liked to eventually commercialize it, but there are few, if any, highly-successful GPL licensed engines (or GPL games for that matter). I’d say before we can see a successful open-source game engine, we need to see a successful open-source game first. Dual-licensing could’ve been a viable option but not possible in this case.
Now, it is possible if someone has the motivation. Fork Blender and strip out all the “Blender” stuff, etc. and keep blenderplayer. However, I think it hasn’t been done yet for various reasons. The Blender codebase is quite large now and would require a community effort to create and maintain a successful fork.
[QUOTE = Mahalin; 2829843] Eu era uma vez abordado por uma empresa para dividir a BGE em sua própria base de código e para desenvolvê-lo. Minha resposta: eles seria melhor escrever um novo motor a partir do zero (durante o uso do BGE como modelo). Se a base de código não eram tão velho e mofado, talvez. É uma coisa a fazer alterações ao código BGE e outra coisa é fazer os adesivos em master. Se Blender tinha uma API C, ou seja, biblioteca, ela já teria sido mais conveniente para escrever um motor em torno dele, uma vez que a BGE é essencialmente Blender , apenas uma forma modificada de que convive atualmente. Pessoalmente, eu brevemente tentou isso, mas eu estava com preguiça de mexer com os scripts de construção. Além disso, teria de manutenção necessária para permanecer em sincronia com o mestre oficial Blender (talvez não seria tão ruim?). Para obter suporte móvel / WebGL, teria sido praticamente uma reescrita e interface com Blender seria um outro grande problema para resolver. O verdadeiro assassino foi que eu teria gostado de eventualmente comercializá-la, mas há poucos, se houver, highly- sucesso GPL licenciado motores (ou jogos GPL para que o assunto). Eu diria antes que possamos ver um open-source bem sucedido motor de jogo , temos de ver um open-source bem sucedido jogo em primeiro lugar. Dual-licenciamento poderia ter sido uma opção viável, mas não é possível neste caso. Agora, é possível se alguém tem a motivação. Fork Blender e retirar todo o material “Blender”, etc. e manter blenderplayer. No entanto, eu acho que não foi feito ainda por várias razões. A base de código Blender é muito grande agora e exigiria um esforço da comunidade para criar e manter um garfo bem sucedido. Pedimos desculpas pelo breve tangente. [/ QUOTE]
Eu não sabia que o Blender / BGE foram tão integrado tal maneira. Agora eu entendo porque os voluntários dificuldtade muitos devs implementar recursos em BGE.
Aparentemente, é melhor eu esperar para a implementação de tal modo interativo e com a especulação vazia.
That said: If the nodal system was capable of generating proper BDX java files, for relevant objects in the game-space, I would be willing to provide an option to invoke the generator program on export, and to move the generated files where they need to be.
I’ve been working on HIVE over the summer, and I’ve made some good progress.
One of the challenges that helps to drive testing is to develop a user interface. The Blender PyNodes API is great, in that it permits in-blender editing of node systems, but poor in its implementation, the majority of the GUI code is written to overcome API limitations, which derive from the lack of programmer authority over UX controls. As a consequence of this, don’t use Edit / Undo. It isn’t currently supported, and in order to recover after performing such an operation, you should reload the blend (or redo, and hope for the best!).
All nodes in dragonfly and an SCA mockup test can be added from the GUI. This will be expanded to user-configurable directories in future.
Advanced nodes (with hive.parameter instances used to configure the builder functions (e.g variable number of input pins)) are configured using a GUI interface. Build class instance arguments are currently unsupported.
As it stands the GUI can import and export a hivemap file, and can parse a hivemap to produce a code-implementation of a Hive.
It is important to clarify how Hive2 differs from Hive1, and why changes have been made.
Hive1 was more mature than Hive2 is now, with a greater number of features. However, although it was a boon of the design that complexity was implemented on a level-by-level basis (layered design), it caused the code base to become overly complex, and tricky to extend. In addition, there were many aspects of this layered design that caused necessary headaches, particular restricted API access (X couldn’t do Y, Y couldn’t do X, etc…).
Hive1 was also very slow at startup, due to context matching.
Hive2 eliminates the connection startup overhead at runtime, complexity-by-depth and awkward ultimatum between “HivePython” and pure-python. Hive2 extends existing Python APIs relatively transparently, and consists of a two layered system (Hives & Bees). Bees now refer to components that build a Hive. A Hive can be the logic for a GameObject, or a single “node” within that Object’s logic tree; it’s a recursive definition. A Bee may be a Hive instance (hive nesting), allowing complex “hives” to be embedded inside other hives, eliminating the Bee/Worker/Segment/Drone distinctions of Hive1.
At the moment, there is little in the way of a standard library, or BGE implementation of game-nodes. This is for two reasons; the GUI is developing in parallel with the HIVE codebase and the standard library, and design references and concerns are currently being relayed by the current author, where I cannot infer what I expect Sjoerd-de-vries to have desired in a specific feature.
Yes, Hive2 is designed to be faster, with support for pre-configuration before runtime.
At the moment, Hive2 doesn’t have any BGE / Panda bindings, so it’s not ready for much advanced game use yet (Though, you could always add this yourself in a “hacky” manner until it’s ready, by writing hives that directly use the BGE API.
I’ve added a PySide GUI (Python QT) for a much more user-friendly editor.
I’ve also been working on a real-time debugger (or at least, a debugger with playback) to visualise basic IO of the hive nodes. This may need reworking later on, because strings can quickly take up large amounts of bandwidth, though this is done over a loopback network, so it’s not going to struggle.
There are a couple of things that I need to revisit, namely:
Hive parameters being used instead of instance args (e.g start value) - this is a waste of build time.
No support for bees within hivemaps (yet)
Blender PyNodes GUI nightmare
I also want to take a look at the current import practice for sockets and plugins when their hives are embedded inside another hvie… this feels a little clunky at the moment.