A little help regarding these nodes?

So, I’ve been learning C++ which has given me some knowledge into understanding the logic behind the logic node setup and allows me to read it fairly easily. However, I am not good enough to be able to detect what is there and what is simply a missing feature. Does anyone know how to change the input in a way that allows me to press different buttons for different tasks? I essentially just need to understand how to change a node to be able to take a particular button command.

After looking at the node system, it’s clear that it isn’t fleshed out enough to really do a lot. Now, that’s like saying the sky is blue. Obviously, at this stage this is going to be the case. The system is still being built. Just giving a friendly reminder that the very well established programming systems in place are always there for your back so it isn’t like Armory has no programming capability (quite the contrary) and if you’ve been looking to use the node system because you don’t know how to program…I’m afraid you’ll either have to wait or learn a programming language to really have a fleshed out programming experience. Looking good on the development though. By the official build, this shouldn’t be a problem anymore.

I merged your 2 topics into this one.

Sorry about the logic nodes - it’s one of the main limitations mentioned in the manual: “Very few logic nodes implemented”. As mentioned, new nodes are continuously added each new build.

1 Like

I understand. Hey, you’re currently a one man band and I’m still working on my programming skills so I’ll be no help to ya yet. If I were to say, I think the nodes are probably the most needed thing right now followed by the animation.

I also would like more logic nodes. Graphic wise it is already super powerful (more then BGE and B4W in my opinion).

But currently, just like B4W, it lacks logic nodes since they focus more on graphics. Just like in B4W, Armory currently deals only with graphics unless I would be a programmer, which I ain’t.

I wish Armory would focus a little more on game logics then graphics, since its already pretty much there.

I consider B4W as a web engine, not a game engine. I currently consider Armory a cross platform real-time graphic engine. I wish it would be more a game engine and I could start wiping up games in it if there would be more logics.

Any games that are created don’t start with graphics, rather with prototype with simple shapes and dummy characters to plan the interactivity.

You cannot tell if your game idea is good until its playable. Its hard to work the other way around, would be a huge waste of time in most cases. The only real way to know if its good is to prototype it.

I use BGE because I like the fact that I can quickly create a prototype and play it. That way I know if my idea is good or not and I don’t waste much time that way :wink:

I wish Armory would focus a little more on logics simply because I believe more people would use it. A lot of games have simple diffuse only graphics (hand painted textures) which in most case is a lot faster to do then highly graphically intensive realistic games. A small team or a one man studio will usually opt more for the simpler path :wink:

Afterall, a game with good graphics and bad gameplay is a bad game. A game with fun gameplay and poor graphic is still a fun game…

So please, more logic nodes!!!

1 Like

I feel similar to Jano3D. I’ve been lurking for a while but have yet to contribute to the project because so far it seems to be focusing mainly on visuals and not enough actual game creation.

So far Armory’s graphical capabilities are looking great but its kind of discouraging how little info there is on actually making playable games including logic nodes.

That said, I’m continually impressed by Lubo’s output and dedication and hope now that he’s doing more with the nodes, more information concerning creating playable games emerge.

Thanks!

1 Like

Ya, I’ve been getting the same feeling but I still felt it was too early to really bring it up. However, this does seem to be the current number one biggest problem with Armory. Graphics are nice, but I think it is time to focus heavily on actual game development.

These posts are helpful, thanks for giving more attention to this. I am not sure about the minimum set of nodes required to make it usable at least for prototyping (100-200?) - it will still be a continuous job of adding more, but I will double down on this. :hammer:

@Sirgeorge The majority of messages I receive are about interactive archviz and rendering - which then puts more focus on rendering instead of logic. That is the reason it’s not as easy to predict ‘number one biggest problem’ - everyone has different use cases and needs (which is exciting). However, I can not wait to build games too!

Yeah! more nodes, more nodes. I can’t wait to start working on a game prototype.

I am actually more in favor of less nodes* and more True Programming With A Nice Debugger. Call me old fashioned but I prefer proper text tools over node trees. (you can’t do version control with merges on node trees) What I hope for is a Unity-style ECS inspired system, so I could tweak parameters on-the-fly, but have the freedom of writing everything in a proper language.

*:but I still like nodes for very simple and very quick mockups, I just don’t want them for anything that would take more than 50 LOC in a proper language.

Programming is important in any game. That being said, Armory already has an IDE fused into itself and working while the node system is not as far along. Is there anything on the coding front that you would want that currently doesn’t exist in Armory.

Well, its not because Nodes are used that programming cannot be used. I think both can be used. Non programmers like me can make quick interactivity and leave the super complex stuff to programmers. Sort of like UE4 does it with blueprint or even Unity with Playmaker. You can use both.

The main reason why this is helpful is that artists can take off the simple tasks off the hands of programmers that really helps saving time as well as the ability to quickly test things out.

So far, its already pretty amazing what Armory can do, I can’t wait for it to be just totally usable to create game (production ready).

In time :wink: As always, amazing work done by Lubos and his one man army :slight_smile:

1 Like

True, I just don’t want nodes to fall victim to feature creep. Simple functional (“pure” functional) programs would be ok, but it shouldnt try to do everything an imperative language does.

(Btw learning a scripting language is not really hard and has a bigger payoff in the long run.)

On that topic, what if nodes were just a wrapper around some Haxe functions? That way they could easily be modified by a text editor and even converted to proper source files.

Textual representation could be Haxe code with some metadata in comments. I’m sure there is a parser that could be used to then transform it back. Malformed parts that cant be “nodified” could be wrapped in script nodes.

I could just as easily say to any programmer, 3D artwork and animation is easy to learn. But I’d be plain wrong.

Programming ain’t easy to learn depending on how your brain works. I’ve been doing 3D for 17 years now, been trying to learn programming ever since I started 3D. Still can’t code. I can understand code, I can take someones code and tweak it to do what I want (python), but I can’t create code from scratch because I don’t think like a programmer and probably never will…

So I get what you mean, however, I disagree. However I do agree that whatever nodes that can be used should still be editable in code. Isn’t a node a code snippet anyhow? So I really don’t see why it wouldn’t be usable both ways just like UE4 does it with blueprint or Unity with Playmaker.

As someone that has been learning both, I can say that it does depend on your brain (I’m lucky enough I can get both) and the basic understanding of programming under any programming language is hard while picking up new ones seems to be like candy. I’m still relatively new to the programming space but I opened up a little bit of Javascript the other day to take a peek and found it much easier to follow along after I figured out the basic understanding of how programming in general works while learning C++. As for the Node “feature creep”, I think that getting the same functionality that BGE has out of the logic editor they have in node format is a good place to start and I don’t have any real concerns with the node system once that basic item becomes a reality. When the parody is reached with BGE’s logic system, I feel that animation would be the next big concern.