BGE enhancement branch

Hi everyone, it’s been a while since I have posted on the subject of BGE development.
Recently, I have been developing support for Python-controlled logic loops in the BGE. After some additional thoughts regarding other areas of the BGE, and some consultation with prospective BGE GSOC projects, I’ve decided to host this on GitHub, in order to permit multiple contributors.

This branch facilitates an engine cleanup for the BGE

Deliverables:

  • Python API for updating engine components.
  • Isolation of SCA_ classes and methods from KX_ code.
  • Replace internal gameloop with a fixed timestep game loop.
  • Overhaul of Data API, including support to create new meshes and cleaner LibNew.
  • Python Collision API for Bullet (callbacks, contacts, modify existing logic bricks).
  • Python Physics API (for physics type and other data)
  • Update of Python API to provide properties instead of get/set methods, rename bge.logic to bge.engine, rename of methods to more pythonic names.
  • Complete separation of SCA systems from KX design, which would remove KX_GameObject.sensors, …,
  • Investigate component-esque architecture for scene.physics, object.physics, object.logic.

Brief
There were one or two other areas that I had wanted to include within this proposal, but I’m not yet finished with anything, so there’s space to add things as we go.

Ultimately, any contributions should meet one of the targets for the branch - if not, a separate branch should be established, as the smaller this is the easier it is to implement. At least for now, this branch will be designed purely for the Python API + update of SCA integration. Following this I will probably create another branch for the Data API, and another for collisions (or simply a patch).

What I would like
It would be very helpful if developers would be able to contribute, review and/or build from this branch. At present, I am unable to build successfully from the HEAD revision (if I recall correctly), nor my commit thereafter, thus I cannot guarantee that this works. (The functionality does work, but in a different build of Blender that I have from a while ago).

I hope that following this work, projects such as HIVE will be easier to integrate with the BGE - giving better GameLoop control for one, and future development will become easier. As I will have practically no time until the summer, this is more of an introductory post than a milestone.

Best wishes,
Angus.

Does that mean a separation of logic bricks from scripting?

My plan is either to completely remove logic bricks when using a Python logic loop, or to allow access to some form of logic manager to deal with logic systems.

Ultimately, when I say remove logic bricks I mean that they are no longer the “defacto” or expected logic system. This was the original design to some extent, but things have “snuck in” since then.

I still think there should be logic bricks. They attract a large amount of users because of their simplicity and effectiveness. They just need a major overhaul:
I think they should just work essentially as a “visual representation” of your python code. Each node should represent a certain line of code, and it should be grouped into functions, scripts, modules and classes. For example, an IF statement would lead into two nodes of true and false (I don’t know where elif would fit in though), then from there would lead to other nodes.
Adding a node would automatically add all the necessary python imports and the line of code.

I think I’ve badly explained myself, but I’ll try make a simple mockup some time :slight_smile:

It would be nice if there was like a function brick, as a blank brick with only a text box that you type in function name (when you begin typing it would open up a list of the available autocomplete functions), then if the function you typed in was valid, it would for example open up a number of text boxes with the number of available parameters for that function, and also adds number of node outputs = the number of returns in that function.
Not sure if this will work well in all cases but it seems complete to me as for function bricks.

I think agoose’s intended direction is to remove logic bricks if you choose not to use them. So you would have logic bricks (including the Python controller), nodes (once they’re implemented), and then this method of a single Pythonic game loop.

SolarLune is correct. Hive Nodes would use the Python gameloop control, or you could design your own.
It would be good to implement logic bricks in Python. Sjoerd (HIVE) has already started doing this in HIVE, so either a pure python solution or a HIVE solution could be very useful indeed. It would make it cleaner to work with the engine for one thing.

Would this help in producing a marching cubes videogame?

Without being rude, I cannot see how you could have asked that question based upon the proposal. The marching cubes algorithm is not a game, and it is a method of producing polygon structures from 3D surfaces described in voxels. The potential link I “could” make is that if you have this data whilst in the game engine, then provided that you write the algorithm to do so, you could then create meshes from this data using such an algorithm. Although, in itself the mesh API wouldn’t help to create this algorithm.

:expressionless:

???

You mean marching using physics ?

I can do that,

Do you mean AI’s?

I can do that with python,

What do you mean?

I think that a node graph that allowed for PyNodes with input links and output Links and Or Logic would be amazing,

if your PyNodes linked to Cython, then we really would not need logic bricks at all,

however logic nodes are just visual representations of functions, that are C.

with “Cython” and python and some visual editors, you could make any logic brick on the fly,

or share them as a text block that is converted into a brik

Ah. Toggling logic bricks, python and HIVE would be amazing. I would imagine that changing them half-way through a game would be impossible though (the same way in Unity you can’t just suddenly change scripting language) unless with some hectic conversion.

Do you intend on implementing multi-threading into the logic/physics? I see a lot of people have been enquiring about this lately on the forums.

Looking forward to seeing this, and would be glad to help test some builds. I don’t think I’m skilled enough to contribute to the coding, however I might be able to give some useful feedback.

I’m currently evaluating the scope of the project. It might be that I don’t remove logic bricks entirely, and that I just try and clean some code along the way. The ideal solution is create a more dynamic API within C++. One such place is the scene converter - rather than having Bullet and Logic Brick conversion code sitting in one place, create callbacks for conversion that can be subscribed to.
Ultimately this then warrants implementing a component architecture, as I’ve considered before.

Marching cubes with physics.And with ai it would be even better with that.The ai would have to avoid obstacles you make and know to fall into holes you make in the environment.Could you provide a blend demonstration or do you have time?

Being able to script without the need to adding logic bricks is a plus.

LogicBricks replaced with a more advanced FlowGraph system ? Why does it take 3 logic bricks to make a cube rotate ? Why there is no option for scale ? Why did they forget to include the scale when they included the location and rotation ? First of all it’s annoying to have to lay tons of bricks just to get some basic stuff going. People expect to have a finished game by the time they put the 3rd logic brick in place.

Sounds like a plan!

Based on your README on Git, I should create a separate branch for the KX_GameObject cleanup? Yeah, I’ve been lagging it on setting up my branch on GitHub. I noticed you also mentioned the LibLoad system which is good since I share similar thoughts about the LibLoad system.

So relevant to yours, I’ll branch from yours to do the KX_GameObject cleanup and once I get to it, push LibLoad changes into your branch. And I’ll setup another branch from yours, for my VideoTexture enhancements/refactor.

If HG1 can get on-board also…

EDIT: Eh, I like using scons :stuck_out_tongue:

The update() needs to run independent from the render() and the frame limiting needs nanoseconds timer. Right now there is no way to control the update rates independently. If I want the logic or scripts to run at 60fps while the drawing/rendering to run free , can I do that with current version ? What if I want to set different limiters for each area independently ? The logic bricks function based on blender units instead of degrees/second. I need the object movement in the scene to remain the same even if I decide to change the framerate limit later.

Sounds great! I’m also looking at a component system branch, but that is for another day. (it’s coming along nicely in bare form now).

The current cleanup branch is functional for Python control , but it needs some error catching support when the engine ends, and one or two other things. I think the main goal of the cleanup is to fix isolated systems rather than the entire structure, which can be partially addresses in a component architecture.

Sent from my Nexus 5 using Tapatalk

In this example the monkey is spinning at different speeds , if the frame rate is changed. That’s just wrong. If you set the fps to 60 in goes at one speed , and then at 120 fps it rotates twice as fast. It need to rotate at the same rate , independent of the renderer. Slow computers or fast computers , it should still rotate at the same rate. Needs to be degrees/sec and units/sec not degrees/tickrate or units/tickrate. And for that you also need high resolution timer in nanoseconds.

You guys should make video tutorials about the code cleanup cause I want to see. Maybe we can spot the bugs in the videos later.

Attachments

TickRate.blend (237 KB)