[Bf-committers] Node system for game logic

[Sjoerd de Vries]

> Dalai Felinto dfelinto at gmail.com
> Thu May 26 16:22:39 CEST 2011
>
> Hi Sjoerd,
>
> two quick questions:

> 1) any plans to license it in a non-viral license (e.g. BSD)?
> 2) how well does it do in terms of performance?
> 3) does it work for programmers as well?

That's three questions :-)
And very good questions, too. I am afraid that the answers aren't so quick...

> 1) any plans to license it in a non-viral license (e.g. BSD)?

In principle, yes. BSD is too promiscuous for my taste, but something
like the LGPL would be an option.
However, there are two big complications.
The first is that any software that is designed to run on top of the
BGE must be GPL because the BGE is GPL. I will work around this by
making multiple backends, a GPL backend for the BGE and non-BGE
backends for Panda3D, Python-Ogre, ...
The second concern is that the hive system seriously blurs the
distinction between code and data. The (L)GPL is not very well suited
to deal with data.
I have some ideas about a custom license, but some discussion would be in order.

> 2) how well does it do in terms of performance? If I remember correctly one
> of the good points of Benoit's proposal was the overall structure of C++
> code wrapped around Python but without necessarily running much Python
> code(at least to reduce the overhead of dealing with python types for any
> manipulation).

Start-up time can be as much as ten seconds, because all nodes are
connected before the hive is fired up. I have some ideas how to slash
it, but a few seconds will always be there.
As for run-time performance: I haven't tested it thoroughly yet, but I
expect no problems, because the nodes call each other directly (no
coordination engine). I don't expect much difference with a vanilla
Python port of your game logic.
Some overhead is added by the exception handling wrappers, but not very much.
In any case, for both start-up and runtime, a JIT such as psyco or
pypy should double or triple the performance.

If pure Python isn't quick enough, I have some plans to interface with
nodes implemented in C++, using boost and ctypes.
Finally, compiling the whole hive in Cython should also be possible:
the static typing of the connections should be very beneficial.

> 3) does it work for programmers as well?
> This layer of abstraction is also what permit programmers to access through
> a programming API (i.e. Python, but it would be lovely to see Lua supported
> as well) the same functionality that is available graphically .

Yes!
I also don't like toy systems that give you some nodes and that's it.
Creating your own nodes and interfacing with existing Python code is
essential.
In addition, you can also create entire hives using the Python class
statement, instead of visually.

What would you like to have for Lua support?
Modifying the node's internal state with a couple of Lua statements
should be easy enough with a good Python-to-Lua bridge. I can add that
to the system if you want.
Making calls into a Lua engine that has direct bindings to the BGE
(i.e. bypassing the hive system) would be much much harder.

>
> Thanks for sharing your project, it seems quite interesting (I need to look
> at it properly later though ;).

Thanks! :)
If you have any questions, don't hesitate to ask!

cheers

Sjoerd

> Dalai
> --
> www.dalaifelinto.com
> @dfelinto