That will actually get rid of the large logic brick problem that its imposible to figure it out once youve made a long number of bricks. yo could have a filter (like the simple ones of excel with a scroll down menu with the names you have given to each sensor, and when you select one it will show also the controllers and actuators refered to that sensor. It wouldnt be a bad thing to do. Or maybe it will, i dont know, but it actually sound good of getting rid of the wire conectors and have them linked by name. But im more a creative mind than a competent programer, so no clue if it would be easy, medium, hard or nigthmare to make something like that.
You could have the name character,npc or other thing and then a blank name for the group of sensor and actuator that the user could put in.Of course more sensor and actuators could be put into a partcular group.I meant lets get rid of the and controller.Let the bge do it behind the scenes.I like the name logic groups.You have groups in blender.
Maybe we should should force them to place names on groups of sensors and actuators before they could use them or select from a named logic group.They already have named.I love that idea.
I don’t think you really want to get rid of the wires… that wouldn’t make any sense. How would any node or brick know which other bricks it was connected to?
However, how about layers? In addition to states you can pus some nodes on to a different layer.
Or groups, like we have in the compositor nodes?
So you put together a character and you have all the logic for the gun in a single group. Click on that group to expand it.
A group can have Custom input and output sockets.
I really don’t think performance is an issue for logic bricks or nodes. So you shouldn’t worry about the system mirroring too closely the underlying architecture. Instead they should be easy to use. Surely no one is going to choose visual programming over code for performance reasons. People want to use visual programming because it is easy to understand at first compared to writing code.
(Actually with sites like code academy I think you could learn python in a couple of weeks and be ready to go. I’m sad that I didn’t, but I suppose I did learn a lot by going the round about route).
I have thought about this quite a bit.
BluePrints
Data -> code step -> code step 2 -> output
could be achieved with
Sensor(using properties as inputs and can set properties based on True/False)
controller(mark execution step (1-10))
Actuator -Can use properties to adjust attributes
Could in fact fill the same role as blueprints, using the current logic bricks + dropdown menu’s that knew the properties in the object containing the sensor and the linked controllers object props and actuators object props…
These logic nodes could be placed in the compositor to make it easier to develop but use essentially the same guts.
The wires are not visible and neither is and controller.They are just added automatically but they remain invisible.Why have it visible at all.That is what i meant.
I don’t understand this idea at all. How can a block or brick or node decide what to connect to automatically? They can’t read your mind.
Perhaps what you want is more like a character node where all the behaviour is standard and you just change movement speed, hit points etc… like a wrapper? I suppose that kind of node could be useful for true beginners. I work with kids and I know they would find it very helpful to be able to just add a character with one click. Then they could learn more and start building their own characters from behaviour blocks.
The problem would be that a character in a side scrolling platformer is different to a top down isometric RPG…
Do you really understand what invisible means?Invisible means not seeable but actually there.That is what i want the and controller and wires to be.
Do you ever use different controllers? The controllers are supposed to be the logic part of logic bricks:
AND, OR, NAND, NOR, XOR, etc…
These are an important part of any visual scripting solution. That’s why they are always there and always visible.
If you want your character to jump, but not all the time, use the AND controller.
Add a keyboard sensor for the space bar and a property sensor which checks if a timer has run out. If both are positive then you can jump, otherwise pressing space does nothing.
How about if you want your character to take damage if they hit spikes or an enemy? Set up two collision sensors, one to detect the “spikes” property and the other to detect “enemy”. Use an OR controller. If either of them is positive you can activate the property actuator to reduce health.
If you want your character to do a special animation when jumping? Then you can use either an NOR or a NAND controller attached to a collision sensor with the ground property. When you character is not on the ground the animation will play.
It’s more difficult to show an example for some of the logic controllers, for example XOR but I guess there must be some use for them.
If you only use AND controllers or python controllers I can see why you might want to hide them, but if so you are missing out on a lot of the functionality of logic bricks.
Getting rid of the and controller is not a good idea.Unless you could have different types of each sensor that incorporate the and controller.
First of all, im no programer, just putting my own taste of gui and usability on the table, can come up with concepts but couldnt do anything beyond that cause i dont know how, so maybe my idea is not douable, dont know, but since we are debating it im going to leave it here.
Maybe we could get rid of the wires having Parent Bricks and Child Bricks for extended logic. You could add a “Parent Brick” that actually gets the hole bundle (Senson, Controller & Actuatior) all in one. With wire conecting for Child logic bricks for extended logic.
Defining actions for in game.
Example of how a Logic Brick would look like.
As for the GUI for using this we could have a Logic Group section, where you can create Gruops and sub groups, each parent group for being created has to be linked with a Object, Scene, or something that will interact within the game at some point, sub goups (folder) will embed to the parten group object. You can browse the groups and sub groups in the left menu and when you click in a subgroup where you have created some logic it will pop up in the logic editor the parent bricks and child bricks if there were some. if not the logic window will be empty.
This will allow i think a more efiicient way of developing games, you can get all your assets in layers and start creating groups of what ever you need, and have a visual backend of your game within the engine. That once you have organized it, you can start creating logic, bringing new assets and linking them with their logic group.
And for Python Logic you can add Parent Script brick and Child ones.
Well thats how i figure out a way of having a more optimized, organized and non coder (And coders also) user frindly gui and work flow.
Maybe its not posible, but posting it anyway.
Cheers.
This doc is still valid in my opinion -> https://www.blender.org/api/logic_editing_proposal.pdf
The logic bricks are moved to the nodes…
Yes this proposal + a ‘property node’ that can be set or get… sounds perfect.
edit: this is chase anything you see with a ray with a property enemy,
and save the hitObject as a property
Also -> I have a value node for input to axis but we need more input node types
String
Int
Yeah this has never been a problem for me. I tend to avoid tabs in editors so I can make proper use of my window manager / monitors. Not clunky at all.
… not to say there isn’t a lot to be desired. But it’s a decent workflow all things considered.
If that’s the document that started the logic bricks, I now understand how they did come out with such a bad system :D.
We could keep the wires.Maybe have the sensors that are added to the same and controller combine.So that there will be less wires.
You can avoid wiring in general by using a system other than nodes. When the dinosaurs ruled the world, I did the design of a software that required an interface made of combinable elements. Instead of using nodes I did end up using a model that nowadays could be exemplified by “Tappy The Turtle”.
Instead of having two components linked together to form a statement, you have one box with two (or more) slots and wiring becomes dropping an item to fill that empty slot. The box itself can be dropped into the empty slot of another box and so on and so forth.
Elements and slots had shapes that suggested to the user what could be combined together.
A problem with a system like that is that it starts to loose visual information when the user creates higher order combinations. It’s the same thing that happens with groups in the node material system, to keep the workspace clean you start putting stuff under the rug. That’s cheating :D.
It looks better than having a lot of wires.
moguri component tests are not using wires, I’ve also emulated these component setup using one python controller to loop and run the function call for all objects in the scene with each of their argument stored inside their own game property, the overhead aside it works like a charm when it came to maintenance because only one object needed any brick at all, I can eradicate the growing complexity and spaghetti mess outside my code(which by themselves are already spaghetti ;D)
I assume new users with zero coding experience will still likely find game property with some field for argument more easily to work with than growing wires of spaghetti
The Moguri components are in upbge.