Promoting heavier use of logic bricks; what is needed to make this more practical.

Game Engine Game Engine Support and Discussion
1

Okay, over the years I’ve heard of arguments in support of both logic bricks and Python, some here say that using the logic bricks more can be a good thing because it makes the game run faster (which in the case of benchmarks is true). However, I would hazard to guess that one reason why Python is still by and large the most flexible option is due to some of the limitations within the brick system that make them less practical than they could be.

If I and others were to use logic bricks more, they should have options and functionality that would make them far more flexible than what they are now, there’s a number of things missing or could be added that could increase their usefulness by several-fold and allow one to make more use of the native-C++ code that they run, including, but not limited to…

  • -Logic bricks as a datablock type, this is a big one, and the fact they aren’t put them at a bit of a disadvantage compared to Python when changing game logic. If you have dozens of scenes already with common objects then you know it’s a bit of work to copy the new logic brick setup to all of them. (and as far as I know, there’s no addon out there that spiders through the entire game looking for objects of a certain type and changing their logic).

  • -Ray sensor: Any reason why we can’t fire any in a global axis yet, RayCast() is currently more convenient because you don’t have to rely on a vertex-parented empty.

  • -Motion sensor: The ability to type in properties for the speed instead of just numbers, there are many cases where fixed numbers just won’t cut it. The use can be increased by allowing the typing of equations.

  • -Property actuator: Allow the use of object attributes and also allow properties to have a value equal to another object’s attribute, so if I want to assign propSpeed to the executing object’s Z-speed I can, same with perhaps assigning three properties to myObject.worldPosition[0,1 and 2]

  • -A lot of input fields throughout the whole brick system: Functionality where it will accept attribute data endemic to the sensor or another object rather than a fixed number or object. Say I want to use the parent actuator to parent the object to Ray.hitObject or I want to rotate an object based on objectB.worldOrientation.

  • -Allow property sensors and the bricks in general to work with global variables stored in bge.logic, currently, the only way to access them is Python and greatly reduces the usefulness of bricks in terms of maintaining game-wide data.

  • -POSSIBLY: Add functionality to allow the use of lists and dictionaries within the logic bricks (which would include new property types like ‘list’ and ‘dictionary’ to go along with that).

That’s all I can think of for now, it will be interesting to hear some of your replies (I’m looking at you Monster since you often promote brick use). The purpose really is not necessarily allow one to not need Python in all cases, but allow the logic brick system to become far more powerful and thus creating a lot more cases where one can easily use them to do the heavy lifting in order to speed up a game. Now I am aware that some of this may already be covered through the actuator attributes editable through Python, but this would reduce the number of little scripts needed for small logic setups and also make it a lot easier for beginners to make some truly complex game mechanics.

2

These are all very good,

1- I would like would be- “apply force over time to move to target” -aka a physical motion with a number of frames,

2-(also a set of properties in every object that are synced like mass, velocity, orientation,
linear velocity, scale, and texture…)
and changing the property changes the actual object, so editing mass can set mass,
then I could do just about anything with logic,

3-also track to nearest of this property would be a huge help
like Sdgeoff’s script but built in,

3

I like Unreal Kismet’s node based approach and Blender’s node editor is great. So why not marry the logic editor to it.
And then a super node (ex. advnaced material node) that exposed everything a KX Game object is made up of. These nodes could have input and output flow. Game properties would be more useful with that kind of tinkering.

4

That would be great,
add in that stock properties list as a panel with links in and out…

5

All good ideas, that would go a long way towards making logic bricks more powerful. How about make every parameter for sensors and actuators accept a property instead of a fixed value, and add support for vector, matrix, and game object properties? And, as you mentioned, the property actuator would have access to attributes of the parent object as well as those of other objects, so it could store the values of those attributes in properties. A property math actuator that allowed you to use multiple properties as inputs into an arbitrary mathematical function, and stored the result in another property, would be incredibly useful.

However, even with all those improvements, logic bricks would still remain useless for constructing chains of sequential logic that run in one logic tick. But, in most cases, you don’t need that kind of logic flow. I wonder how these proposed changes would impact performance, though.

Also, logic bricks are in desperate need of a better, more flexible user interface. Making them into datablocks would be a big part of that, but also things like grouping, rearranging bricks, hiding bricks, highlighting certain elements, etc.

6

Most of the issues with logic bricks could probably be dealt with when logic nodes come around, like doing more than a single simple Sensor > Controller > Actuator game logic line. Implementing properties for usage and more complex data types would probably fit better in a node layout than the current brick setup, as well, as you wouldn’t be locked to a single 3-brick line of logic for complex code (like you would use with a list or dictionary).

EDIT: However, the individual logic bricks could probably still use work (unless the node editor is just out-and-out better, and allows for a better workflow, better visual programming, and more possibilities than the logic bricks. If that’s the case, then maybe the logic nodes would simply replace the logic bricks altogether).

7

Motion actuator having support for properties as values…
easy throttle, easy physics walk cycles, easy … Everything motion…!!

8

Ace Dragon, thanks for the effort to collect these ideas :).

Proposals
I suggest to open separate threads according the the BGE Proposals [collection of ideas to enhance the BGE] (formally known as Princ…“BGE Roadmap [Suggestions]”).
This way it is easier to discuss the single ideas and keep them separate from others.

Developers might pick up the ideas from the list and implement them (it really happened :yes: thanks for that).

New Bricks
I would really like to see ideas for new bricks. In general I think they should be as general as possible, so the majority of bge users can benefit from them. On the other hand they should not become to complex (see motion actuator).

The current presentation of logic bricks could be improved.
The handling of logic bricks can be improved too.

If you have ideas how, it would be nice to present them in a separate thread. I know it is a lot of work to do so. But one cluttered thread with several ideas will be lost pretty fast.

SCA
I believe the current Logic Bricks are very very powerful. They are just underestimated. Why I think so? Everyone uses them. (not that you had any choice :wink: ).

The SCA system is a very clever architecture that covers more than 80% of logic with just a few simple bricks.

But as written above it does not cover the remaining 20%.
You might know the 80:20 rule:
80% of your work is done in 20% of the time :evilgrin:.

I’m pretty sure the original designers of the bge have known about the limitations of the fixed logic bricks. So you can have your remaining 20% they went a very flexible way to introduce the python brick (=Python controller). It allows nearly all the processing but encapsulates into a logic brick.

Somehow they forgot to add a Python actuator, which partly hides the SCA architecture towards BGE/Python beginners.

I’m amused when I see that someone tries to build an own even system with Python. I was on the way to do this as well. I was thinking how to make it that flexible that I can separate logic from configuration. And do you know what … I got logic bricks ;). What surprise they existed already … with a nice GUI.

I’m looking forward to see your ideas of new or improved logic bricks.
Monster

9

To me the main issue using logic bricks is the fact that I loose track of all the noodles very quickly as my game gains complexity.
The functionality for highlighting the noodles was a big improvement but I don’t think that it is possible to improve on the issue any further within the current lb system.
I’m excited about the hive system which could give way more flexibility here especially when your’re able to group and name your bricks somewhat like you can with python code. But since hive creates python code the c++ speed increase won’t be reached that way.

10

Some things I would like to see in logic bricks:

Keyboard sensors detecting the state of keys (key held down, just released etc)- I think 2.49b had this.

Defining the arc of a radar /near sensor- and make the near detecting area spherical (or any shape you want)

Merge collision and touch sensors

Have the track to sensor use defined units of rotation rather than based on time, as well as limits (so the object will track up down only, left / right or full 3d (good for turrets etc)

Message sensors reading the message body (which is currently only accessible from Python)

11

Additions to the wish-list:
→ Controller to call binary modules written in C++/Java/C#/…
→ flag to module-controller to start module asynchronous/threaded
→ adding a module-controller that doesn’t already exist will create that including code for bound in- and outlets
→ “Next” / “Follow-Up” Actuator & Sensor - combination
e.g. || S: OnCollision → C: CheckConditions → A: Next & S: Next + S: OnKey[W] → C: AND → A: Motion ||
the Actuator should have a flag to say if the follow-up should be evaluated in the same or the next round
→ “State”-Sensor: reacting on entity:: creation, initialization, awake, update, sleep, deinitialization, destruction(, …?)
→ Option for S,C,A to select on which object/objects to act on (like having a control-object to control many equal object, you don’t wanna put bricks on all of them, you could put logic on the controller and then on options tell on which objects/groups to act/react on,
e.g. a group of fireflies, S:OnHit(any of group FireFlies) → C: And → A: Glow(the one) | or A: Glow(all) | or A: Death(pony) )

[I know that most of those stuff is already doable via SCAs and Python. But having it a bit cleaner and packed together seems nice. Also I don’t mind having different Sensors being able to do the same stuff. As long as it’s easier to use/understand or more consistent.]

→ grouping of SCAs
→ selection of SCAs → drag & drop to other object → option to move or copy over
→ saving of SCAs into & creation of SCAs from code-files

→ ability to pause game → continue normally or do just one step
→ ability to change properties (especially when paused)
→ visualize “flow” of commands through SCAs (“which why what when”)
→ profiling of SCAs
→ profiling of modules

12

I think it would be awesome if we could make new logic bricks like we make addons. Even if we lose the speed of C++ by making them in Python. The amount of logic bricks would explode and the best ones could be included in the trunk.

I know this is too much to ask for, but it would be great.

13

I think we need more raycast detour funtionality in the logic bricks.How about make logic bricks that would allow a character to learn from experience.

14

Have a “demo” brick area and a “trunk” brick area?

both?

anything that gets voted up to a certain level gets added to the trunk in C?

15

A logic brick that would let you switch from multiple navmeshs and reiterate through them even moving ones.

16

You can write heavy-lifting code in C/C++, wrap it in Python (for example with ctypes), and then wrap it inside Hive.

Hopefully, at some point, Blender will switch to PyPy, and all Python code should run about 10x as fast.

17

Anybody play “RPG Maker 2”? it had a good modular coding system, maybe we can learn from that. You could also make the rumble packs in the PS2controllers vibrate forever with that game, good if you had a stressful day.