Redesigning the logic editor

This logic editor can be useful for HUGE game projects, lets say you made lots of things in all the layers, but you don’t have enough space to add the new features for your game, so with this, you can create many scripts, each script has its own logic editor, so you will have much more space to add features into your game, and it will keep your work more organized, so you don’t get confused.

What do you think? please share this to let the blender developers know about it.

Something similar to this



Are those plus thumbnails like folders for state actuator states?

I do not understand this pictures.

Do you mean to assign lots of individual files to a single object?

Scripts are text files, not logic blocks. If you want to grup logic bricks call it brick groups/brick sets/logic sets/behaviors/etc…

About the feature, we already have python, BGECore actually can simulate that in python assigning various behaviors to an object. Implementing this feature to Blender with logic bricks can be done too but I don’t know if it has much use, logic bricks are not for HUGE game projects.

I mean groups of logics bricks for every single object, so if you run out of space in all the layers of logic bricks, you can create another logic brick for the same object, it can be useful for huge games

step 1 - move existing logic bricks into node editor

step 2 - make groups color codable and collapsable and copy/pasteable

step 3 - allow inputs into the sensor from property nodes and outputs to property nodes , same with actuators.

example

Ray(set property target)-----------and-------------steering(steer to ray target)

this makes everything possible while maximizing the potential of existing bricks

Definitely into the NODE, to be able to draw around them with a line and name a group would
be amazing, more organized and get rid of the spaghetti

I came here looking for a thred for organizing logic bricks like in the node editor… looks like it is just another dream.
I hope they add node logic bricks like in UDK or just a way to group/divide bricks for visual purposes.

lol - who is “they”? :wink:

What would be good for starters is to have the logic brick setups become its own datablock type (so the setup for hundreds or even thousands of objects can be changed on a whim).

This would come naturally if it ever went to being node-based, but the BGE has a history of seeing almost all major projects hit a wall so I’m not counting on it for now.

The upper class elite

I think It should be who we hire,
by selling games,

but we have to do that first,

Tristan, Loki, Moguri, kupoman, and Hg1 have tackled some major projects,

this is not beyond them.

The resource section already contains some proposals with much deeper details how it can look like. Still nobody is going to implement any of the suggestions.

There are quite a lot of dreamers out there thinking a lot of noodles in the node editor form a big magically “make my game button”. I really doubt it will solve any issue, as it would not introduce something we cant achieve already. It is just another form of behavior description. You as game developer still need to know what you are doing. If you have no clue … the best tool will not help.

My critic on this thread is, that it tries to describe a vague idea. It is nice to see a proposed screen shot. Unfortunately to me it is not obvious what this should be. Without more details I cant imagine how to use such a system. I have more the impression that here is a big misunderstanding how the current BGE logic works.

I can understand that. The time I started with the BGE I was looking where to assign code to an object too. But it is not how not the BGE is designed of.

It’s not a ‘make my game’ button as much as a bunch of bricks also don’t form a ‘make my game’ button. You still have to learn how everything works and assemble the logic yourself.

With the right organization and grouping tools, nodes can also be clean while being more powerful. Group nodes for instance can even create a sort of ‘function’ that you can visually put together (can’t do that with bricks). I don’t think it is a good idea to deny anything that even slightly deviates from SCA as if it’s the final and eternal solution for game development (the concept has been around for nearly 15 years, try to convince users of other engines that the rest of the industry failed to find a more powerful and flexible solution in that timeframe).

I never denied the idea of other forms of programming. I deny the illusion that the existing way is not good and the non-existing tool will solve all problems.

The “clean” method sits in front of the monitor :eek:, but often suppressed by the quick and dirty one.

personally i not see sca so cool .

more over what i hate of it is that in ALL CASES are really “BLOKED” !!
for other 500 years sca still what is now!

at the same time i tried to make some visual node on the paper, and … seem all except easy, more over, increase the complexity a lot in the moment that you manage different output from a “bolean”.
(how and when an imput should be counted as trigger? of the other node…)

something of sca is to keep anyway, for example some kind of sensors have to run only once and in all case, (not “on call” that risk to be confusing and absolutely not performant)

i guess the tread suggest more over organization.

each script can be a property of the object rather than “used” from an object.
this mean that each object has a list of scripts (exactly as the list of bricks)
to find a script of that object you have to select the object, not select the right script in the HUGE(dirty) list of global scripts.

this concept will be extremely useful for each thing that a object use,
changing from “user that add mess in the global list” from the OWNER.
tremendly useful for:
material
mesh
textures
images
animations
sounds

that isa a problem of BLENDER , hugly organization , not object oriented.

should be 2 path explicitely and clearly separated-> GLOBAL(stuff of blend), LOCAL(stuff of the OBJECT ONLY)
the data saved as local should be completely unaccessible for other object.

for the code, shopuld be the same except for the fact that python is not an internal language of bge .
so, is better limitate the amount of code .

for all other stuff , have this very normal ability of save data as property of the object should be very normal.
this avoid a lot of work useless, conflict with names completely useless , UI much more clean,
and maybe(due to the UI much more better organized) the ability to make a game normal (not AAA) in a single blend.
without miracles of ingegnery.

Are you joking?

The logic bricks are applied to a single object. More object orientated is rarely possible.

bricks are perfectly OOP,
in fact, a sensor “Radar” is the sensor of the object , the object is the owner.
there are not conflict (or annoyng problem with names) with another object that use another “Radar”.
(there are not hugly global list of “radars” as instead happen for materials, etc with all problems of names, imagine what mess will be…)

removing the object is removed the radar.
to see the radar you have to select the object owner.

unfortunately this concept is not applyed to many other things where will be a lot useful.

see -> material, textures , animations , images , meshes, sounds, …and scripts

I think you should think in terms of what we can and can’t do now,
and what would expound on what you can do,

Nodal SCA would be the bridge between both worlds,

NODES and BRICKS, and would function almost just like thr current bricks,
however you can organize , group, color and copy paste, not to mention set properties if a sensor is true, as well as fallback, to a different value if a sensor is false,

if sensor is true set target--------and--------steer to target

if sensor is false and timer is zero set target to waypoint

this could all be coded quite fast in Nodal SCA.

Unity nodal logic system was not that great.If this happens.I want the blender game engines nodal logic system to be better.Have you played around with antares universe visual programming in unity.Very hard to use and worse than logic bricks.