Development of Logic Node System (discussion)


#1

As far as I know, the development of the logic node system in Armory is going to start with the translation of the logic system in BGE to a node based system. Does anyone see any better way to expand or change this in order to get a better outcome for the engine during these early days or will GUI translation be enough during the early days to allow for concentration of graphics over other features like utilitarianism? At the very least it makes the learning of Armory easy as you can easily translate the BGE tutorials to apply to Armory at that point. Thoughts?


Build 5 is out!
#2

We can try to replicate blueprints from unreal engine


#3

Oh…ya that would actually make more sense. Unreal Engine is a more powerful engine and the logic system from that engine is rather awesome from what I remember since the last time I touched it.


#4

I’m already used to the BGE way of doing things, so I would actually preferred nodes similar to it or brand new nodes that don’t have nothing to do with BGE or Unreal :slight_smile: If it is to learn new stuff anyway might as well be something new.


#5

I’m actually talking about a short term fix when I suggested the BGE nodeification system. The quality thing to do is to take a look at the problem from scratch and see what you and the community reason is the best solution with the freshest eyes and most recent development in project management and game technologies. Short-term though, I would suggest just patching a system like BGE into Armory, where most of the code is already written and it’s under a license that works rather well for the legal side of things so it should help here.

I tried to get BGE logic to work in Armory and failed so having the ability to use any complete system now would allow me to develop games now and be able to provide solutions to bugs in something other than a contextless vacuum that exists currently. Obviously, no one is going to be developing a well-polished game with the engine this early on but through the process of trying to we can find bugs and move forward in a more natural organic way for human beings to work. The “work, work work, oh I found a problem let me fix/report it” method works well in comparison to the method now which, for me at the very least, involves being swamped by not knowing where to even start. Implementing a janky system in for this now goes a long way to making it much easier to be able to spot problems as well as allow proto-games and tech demos to actually start showing up.

I could keep going but the point boils down to this: short term gain of doing this now is worth medium term hassle of switching out later if it means developers can start developing because I and many understand the system BGE goes about now but the hybrid Kode/Armory method now is…much harder to get from ground zero. So, implement logic node system early please. Thank you.


#6

Event Sheets in Spark Engine and Construct 2 looks better


#7

Ya, the functionality of actually doing stuff is currently more important to implement than the graphics considering the state of graphics and functionality now.


#8

I’m actually really interested in building a powerful animation system that would make it very easy to modulate animation sequences.


#9

You should also check out Godot’s new VisualScript system, it’s a lot more powerful than that blueprints stuff. I don’t know about the rest. But in the end I’m a code guy so I don’t really prefer visual things when functionality is concerned :slight_smile:


#10

So regarding specific logic nodes being able to have nodes that have pre-built functionality in them like crouching or Jumping for example.


#11

I wanna see a curve node being implemented as well as a good time node. In BGE you can have a player jump by putting an Input node that references the action of pressing a button (in this case space) which would go into an and node (which does nothing but link in this particular case but technically it makes the function an “if this AND that then do this” instruction) and that would go into your action node; which would be to move a character constantly by a certain amount in one axis.

In Armory it would be nice to be able to have (eventually not necessarily in first implementation) a graph node that would allow you to say “when pressing this button move by this much on this curve”. It would allow you to have HUGE control over timing and controls with just one simple node in theory. The design of this node would have to be discussed but it would be beneficial.

Going back to our jump example, I could design the system so that the character moves up by a certain amount in one-quarter of a second then this much in the next quarter of the second and so on until they land. I could then go further by specifically having two different curves for each axis thus splitting things to allow for further control. I could then choose if I wish to model the curve going back down so I can have even more control. If you have a blending ability in effect to allow you to have the curve take into effect fighting against the physics engine and have the jump start out as the function graphed by the curve wins out against the physics engine in the first quarter of the second but the physics engine wins out on the second half; which allows you to have even more control.

Further, these curves should be able to take over and blend into each other. So, let’s say that you want your character to smash down in the middle of the jump in order to get a kill for enemies that they jump over. You can have it so that the curve holds true and another curve takes over for the force applied to smash back down when another button is pushed in the middle of the action.

I can go further but I think you get the point. This is one example of how to do node based logic in a finalized Armory.


#12

I think the system in Animation Nodes deserves a look. If they had shared nodes that would be cool, although Armory can replicate or replace much of what AN is used for, but AN is not strictly real time, so it can get away with some heavier stuff being included. Either way, AN already has some nice math nodes.


#13

Hello,

i have found an interesting project about Blender Logic Nodes.
It’s for BGE but maybe it can be useful for Armory too ( it seems free and open source but check the license and/or contact the author).

Github:

Documentation:

http://www.tukano.it/applications/bgenetlogic/bgelogicnodes.html

http://www.tukano.it/applications/bgenetlogic/bgelogic_howto.html

Source and info:

https://blenderartists.org/forum/showthread.php?388143-DEAD-Blender-Plugin-BGE-Logic-nodes-Alpha


#14

Ya…that looks very interesting. Maybe you could use it to speed up the process of development. This is assuming that you’re ok with the license and giving credit.


#15

https://www.scirra.com/blog/195/event-sheet-improvements-in-construct-3


#16

These are awesome, very intuitive and easy to use.

https://blenderartists.org/forum/showthread.php?388143-WIP-Blender-Plugin-BGE-Logic-nodes-Alpha


#17

First off, I’m as big a fan of what’s going on here as anyone… pretty amazing. I’ve been downloading the latest builds from itch.io since early releases.

I suggest having a read through of the BGE Manual. Even if you’re familiar with it already, have a quick look and then think about what we’re trying to do here. (and by we, I mean Lubos :wink: ).

BGE README!

The logic BRICKS system is more like PLC programming with logic gates, sensors, controllers and actuators. Treating 3D environment like a machine… a control system methodology. Then if required, code is added on top to do the more complex tasks. Any new logic node system should be used as an addition to the BGE logic bricks… You can NOT simplify something that is already basic bare bones by using something more complex.

There is nothing else like BGE logics and it already exists in Blender and it could be a game changer for the industry… No way of exporting to anything other than a bulky slow desktop game and at that there are licensing issues for your content. (even though I say bulky, a BGE exported game is tiny compared to what comes out of Unity or UE4 Megs vs Gigs.)

It’s extremely powerful, you can prototype games rapidly - extremely intuitive. Anyone thinking about making a game should try BGE and realize how quickly you can prototype a fully functioning game… also tons and tons of online resources… not to mention again that it’s right inside Blender which we all obviously love… isn’t it the whole point?

The most powerful node visual scripting system for making games hands down is Blueprints for UE4, but this is a visual way to write C++ code . (I’m generalizing a lot here I know, sorry UE4 people). If you want to visually write software this is the way to go.

Unity has visual scripting the most popular 3rd party product is Playmaker, similar theme here visually writing code. Unity doesn’t come out of the box with visual scripting that compares.

UE4 and Unity have massive communities surrounding them.
BGE has a massive community surrounding it more like a dedicated fan base, since the games made in BGE have very limited means to deploy their games. IMHO BGE community is the Armory community its such a perfect fit… I thought this would be the direction Lubos would go, can’t understand why this isn’t the case…

Am I the only one seeing the huge opportunity being missed? BGE allows users to make a fully functional game as it is, right now in the easiest ways possible. We have something like 10 ready made BGE prototypes that could work in Armory and be released. Armory could go from zero games to many in the shortest period of time ever.

few, I digress. :wink:


#18

I couldn’t agree more with v3ny. Well said m8!


#19

Having support for the BGE logic blocks would be great. However it would require a substantial effort I’m affraid.

The current logic node system works in a similar fashion as the UE4 nodes. In UE4 the nodes represent C++ code, and in Armory the nodes represent Haxe code. Each node generates a piece of Haxe code which is then compiled into javascript for Browser (HTML5) builds, or C++ into native binaries for the Native builds.

Supporting the BGE logic blocs is certainly possible, but it would mean that each BGE logic block would have to be defined in Haxe code etc. Huge job to get done. But if there is enough interest I’m sure it will be done eventually. Armory is open souce, and it’s possible to start implementing and then send pull requests through Github to @lubos.


#20

100%!!

Is it possible for someone to build a simple example that makes one thing from BGE logic blocks work with armory.

One well documented example of the code required to make a BGE logic block to work.
Define a BGE logic in Haxe code etc.

Not to oversimplify obviously it’s a giant task, to see all the code that needs to be touched. Hopefully build a framework and workflow. Since we’d be re-building it in Haxe rather than building from scratch.