Logic Nodes Tutorial for simple FPS controller [no longer recommended]

[Simonrazer]

Hello!
As a lot of people say that they don’t quite understand logic nodes, here is a overview of the basics on how to use them to create logic for your games.Let’s do this by creating a simple First Person Controller.

First, we need to have our character set up in Blender. For this tutorial, we are just going to use a box. Scale the box to a human’s size, make it a Rigidbody and set the shape to Capsule.
Next, parent a Camera to your Player and position it right there, where his face would be. Optionally set the FOV to 90.
Also a little place to walk arround on would be handy, so set up what ever you want. For me, a sunlamp, a plane and a monkey to jump on is going to cut it. Turn Rigidbody on for all objects you placed, and turn off “Dynamic” in the settings to make them static.

Your scene should now look something like this:

In the Render-tab -> Armory Player set the Camera to “Scene”, so when we hit F5 Armory uses the Camera to see through.

We want the body of the Player to move and rotate around the Z axis, and the Camera will only need to rotate around the X axis, and that you are able to move in all directions. To do that, open a Node editor and click the little controller icon. Most of the of this tutorial will play in this window. Click “+ New” to create a new Node tree and name it something like FPScontrolls.

We want the Player to move forward as long as we hold down “W”. So first create a “On keyboard” Node, set it to “W” and “Down”. Connect the (only) red output to the red input of the “Translate Object” Node. You can find these via shift-a -> Inputs / Actions or just search there for them.
This means that the “On keyboard” node will activate the “Translate Object” node as long as “W” is held down. All red in- and outputs work like that.
In the Object-field of the “Translate Object” Node, select your Player. When you click the Vector-field, you see the Vector in which the object is going to move(in order, XYZ). For now we are going to put in 0.1 in the Y-field, since my camera faces the Y direction.

To make this logic effect the scene, we need to have it assigned to any Object. We are going to keep it simple at just assign it to the box, by selecting it, going in the “Object” tab in the properties, scrolling down to “Armory Traits”, creating a new slot with the + icon, setting its type to “Logic Nodes” and selecting the tree that we created in the editor.

Your scene should look like this now:

When we hit F5, we should be able to walk forward and fall down into an endless pit when we reach the end of the plane.

To walk backward, left and right, we just need to copy and adjust this setup.
Select the two nodes, press Shift-D and move the new ones below the old ones. The position of nodes on the canvas doesn’t matter, only their connections. Set the “On keyboard” node to “S” instead of “W”, and in the “Translate Object” node, set the Vector to 0,-0.1,0. Repeat that with the according Values for left and right.

When we hit F5 now, we can move in all directions!

Now let us create the logic to be able to look around with the mouse. Create a “On Update” node (in the Event tab), and plug it into the input of an “Rotate Object” node. Set the object to your Player. If we were to set the Vector to 0.1,0,0, the Player would rotate every frame 0.1 around the Z axis.

We only want the model of the player to rotate on the Z axis, as said before. To do that, create a “Mouse Cords” node (input tab) and separate its “Movement” Vector (Vectors are always purple) with the “Separate XYZ” node (Value tab).

Now we have the value of the players mouse movement, but we need it to be a Vector to work with the “Rotate Object Node” For that, create a “Vector” node (Variable tab) and plug the Z-output of the “Seperate XYZ” node into its Z input. Leave X and Y at 0. Connect the “Vector” node to the “Rotate Object” node.

When we hit F5, we should be able to look left and right with our mouse, but it is inverted, and SUPERFAST.

To cancel that, create a “Vector Math” node (value tab) and set it to multiply. We want it to multiply the movement of our mouse with a negative number greater than -1. To do that, we put it in between the “Rotate Object” and the “Vector” node, set its second input to something like -0.01,-0.01,-0.01 and set the whole node to multiply.

And hooray, we can look normal to the left and right now!!

Here is how you file should look like now:

But now we have a problem: when you walk forward, you do not walk where you are looking at! For that to not occur, we have to multiply the players rotation with the speed he should be traveling at.
First we set up walking forward. To do that, we create a “get Transform” node (value tab), set the object to our Player, and hook it up to a “Vector from Transform” node. Set its mode to “Look”. Now multiply it with the speed you want the Player to be travel at (0.05 seems fine) with the “Vector Math” node, and plug that into the “Translate Object” node that gets activated by pressing “W”. Yay, you now can properly walk forward!

If you try to plug the same Vector into the backwards “** Translate Object**” node, you will have to multiply it by -1 first (also with the “Vector Math” node)

To be able to walk properly to the left, we have to use the “Right” mode of the “Transform to Vector” node. Duplicate the old one (shift-D) and set it to that, and also hook the “get Transform” node back up to it. Multiply the vector again with the speed (and -1 for going right), connect the Vectors to their according “Translate Objects” and voila, that is fixed, too.

Your setup should now look something like this, I collapsed the *-1 nodes to save space.

No for looking up and down, I want to use a new Trait. Click on the little + icon at the bottom and name it something like FPScamera, and apply it to the Camera the same ways as with the other Trait.

We again want to get the the mouse’s movement with the “Mouse Cords” node, separate the Vector whit the “Separate XYZ”, but now we need to plug the Y output of the separating node into the X input of the “Vector” node. You multiply this again with the preferably same Value in the same way as we did when we set up the Z axis looking, and plug that Vector in a “Rotate Object” node, whose Object is set to the Camera and is being activated every frame, so into the red input goes an “On Update” node.
And now we should be able to look up and down!

Your Camera trait should look something like this:

Now we have to fix the issue that you can potentially break your neck when trying to look up, or sticking your head into yourself when looking down. We fix this checking every frame if the Cameras rotation is high/low, and then if it is, set it to its own rotation, but with the rotation’s vector’s X value set to a maximum/minimum.

To get the Camera’s rotation we use the “get Rotation” node (value tab) and set its object to the Camera. We again need to separate this vector with the “Separate XYZ” node. To check if the X value is above a certain Value, we use a “Gate” node (logic tab), which is being activated every frame by “On Update”, and is set to “Greater Equal”. Plug in the upper input the X value of the Camera’s rotation, and in the lower input the X rotation of the Camera when looking straight up, which is form some reason 3. You can plug this in by creating a “Float” node (variable tab).
The gate node only activates the node(s) being plugged into, when the condition being set is happening at that moment, and it also is being activated through another node (for ex. on update, on keyboard)
Now we connect a “set Rotation” node to it, set its object to the camera, and use as Vector the current Y and Z values of the camera’s rotation, and the maximum rotation you should be able to look up, so 3, as X value, in a new “Vector” node.
To also fix this when looking downwards, we can use the same setup wit a two changes. The “Gate” node is being set to “Less Equal”, and the the minimum Value needs to be 0.
Now you shouldn’t be able to break your neck!

And your Camera Trait should look like this:

Thats it for now! Maybe I will do a followup with jumping, global variables and perhaps shooting, depending on if I have time for that.

[Simonrazer]

Here the .blend fps.blend (667.5 KB)

[Jano3D]

That is crazy complicated for a simple FPS controller! In BGE its 3 or 4 clicks

[v3ny]

Here is what it looks like in BGE logic nodes

[Simonrazer]

The main reasons for it being so complicated compared to BGE is that BGE already has some build in stuff that you do not have to manually do, most effecting in this case is that the translate node is (currently) not able to use the objects local rotation for movement with a click of a button, or that there is a prebuild looking component, so you basically do not have to do anything in BGE.
Yes, logic nodes still have to improve, mainly node groups would be very handy, but I think implementing logic bricks would be a waste of time, since they are very limiting in the way you do things (Imo).

[v3ny]

I agree with the general consenus, we want the best most powerful system… both systems can co-exist, use the power of nodes for complex things. The system in place now is a barrier to entry.
The big time waster with Armory is trial and error. The documentation is so lacking that you have to spend more time testing to see what works than actually making things (imho). I downloaded your example, there is no way for someone to know why you did what you did with the nodes. not intuitive whatsoever.

The most simple method is always the best. The BGE way is supremely intelligent in this regard. The Current armory nodes should be used for game intelligence, not game controls.

Use basic tools for basic things is what I say. Definitely not a waste of time. Show me something that can’t be done with BGE easier than current or even future Armory nodes. Just looking at our two examples, which way seems like the right way to do it. BGE logic brick methodology is far superior.

Also, armory nodes are not scale-able. Think of how many more nodes need to be added to the player object in your example. The principle for programmers of writing code so that anyone else can come in and look at your work is lost with Armory nodes. Nodes are supposed to make things more simple

I’m here to make games, not reverse engineer the logic system.

[Jano3D]

Nodes are great for certain things. Just like in UE4, but nodes also has limits. Certain things cannot be done with nodes and still requires codes. Same goes for BGE logic bricks.

The idea behind using the logic bricks is simply due to the huge amount of people using it would have an easy cross over. From there they could simply use logic bricks to create the simpler stuff quickly and efficiently. And for the more complex stuff use nodes or code.

I can create very complex games using only logic bricks and very minimal python.

So far, there is no types of game play I wasn’t able to reproduce in BGE using mostly logic bricks.

[Blood_and_Chrome]

Let me be the first to say Thank You! @Simonrazer
I’m the furthest thing from a programmer, but I’m committed to learning and training my brain to think in those terms, and having this logic node system as an intermediary to scripting, which I’d like to come to grips with as well, I’d like to encourage you to do more of these tutorials. Also, I reckon you’d also do well to make them in video form, though that’s only a suggestion and totally up to you.

[EndSSGames]

Wow, what a difficulty!
In BGE does this in seconds, in addition to the Addon FPS SETUP
in one click creates the basic fps
I think it’s a pity to use the logic nodes, you’ll have more work on simple things, imagine on complex things!
I just wanted the graphics of the cycles I think is incredible!

in my opinion, I think it is not worth losing all the addons until the ones I did to improve the chart in the BGE
I think I should add the LOGIC BRICKS too, so we’ll have PYTHON, LOGIC BICKS and Logical Nodes

so also improve the watch code and more new options!
I’ve been in blender since 2011!
and besides python I use logic bricks enough for simple things, really ARMORY will have Big Disadvantages!

I think I’ll continue with BGE!
I was going to buy the closet plus I went to have another look here to see if it really worth $ 50!
Now I know it would be a waste of money!
If you ever implement the logic bricks in the arsenal, I’ll buy it!
I always look at this!

[EndSSGames]

that’s right!
In addition to losing the excellent complements that the BGE has!
Get to know the FPS CONFIGURATION, with this in one click, it creates a simple and better fps than in seconds!

The armor still is not worth it!
I was drooling with the graphics that can create in the armor beyond good optimization, but not worth losing everything just by the graphics!

goodbye armory!

[Naxela]

First off, Armory is still in a preview state - It’s under continuous development. BGE is almost 18 years old having been coded by a large community. Armory is…what, 2-3 years old? With version 0.1 only having been released a few months ago, having been mostly coded by one person. - The nodes system is prone to evolving, and who knows, in the future the node setup for an FPS might looks like this:

With that being said, Simonrazers excellent tutorial isn’t as complex as it looks, and the end result is well working and quite simple - he just goes well into detail explaining each step and why.

As for Logic Bricks vs Logic Nodes, I’d say the node-oriented way of doing things is vastly more versatile than the SCA (Sensor-Controller-Actuator) way of doing things, but that’s mainly because of the possibility of grouping nodes through different node trees, not to mention of the possibility of branching out through an infinite canvas of an endless chain - Logic Bricks due to it’s nature only go through the 3 instances, which becomes just as much of a brick hell as the nodes, but at least nodes can be grouped and instanced.

In the end if you have any aspiration of becoming a professional game developer, you’re best of learning to code. You’ll be doing yourself a big favor. Especially once your game becomes even slightly complex, the possibility of abstraction, object oriented programming and classes can make your life so much easier. Logic Nodes and Bricks are good for fast prototyping, but IMO final production games are better off being coded.

[Simonrazer]

Started working on a Look node, but currently have a problem that when you look the quaternion system also rotates you on the global y axis, which should not be so for an FPS controlles, and I can’t find a way to get arround it.

that will happen currently and thats not good:

Can someone help Here? Will upload to Logic_pack once finished

[Jano3D]

Armory so far is just not user friendly, but also not artist friendly unless you have a programming background.

I agree that nodes are great and all because UE4 has them, and its all they are talking about. But, its not artist friendly, I’ve been trying to learn Blueprint for over 4 years now and I still can’t do something simple with it because I am not a programmer at all. I can do minor python stuff, but nothing very fancy, and mostly copy and paste from other codes, not creating it from scratch.

Nodes are great for programmers, not for artists. Artists don’t think the same way programmers do. Programmers think logically, artists think freely. The easy BGE logic allows for quick plug and play, if it doesn’t work, try plugging it somewhere else and it usually is easy and when you aren’t really the logic type, you can most of the time figure it out by simply trying different stuff. In Armory when I try that, I usually crash either Armory, or completely hug down my machine.

I really thought at first that Lubos was going the BGE logic bricks way. But now that its all Logic nodes, I am also bumbed out and probably wont use Armory at all. I can so far do much much more in BGE then in Armory (maybe not graphic wise, but not all games need to look realistic).

I will still check from time to time, but thus far, I still prefer BGE, and will most likely stick with BGE and UPBGE for my games, but I don’t know what Lubos has in store for the future of Armory, so I’ll check from time to time, but its pretty much disappointment for me so far trying to use Armory.

[Naxela]

@Simonrazer
Can you upload the code somewhere (github perhaps)? I might take a look at it once I get time

@Jano3D
I’m not sure BGE bricks necessarily should be a first priority, but I don’t think it’s unthinkable that BGE bricks might be supported in the future, maybe with simple trait activator of some sorts and from there slowly add the various logic bricks inside the Game Logic editor:

[Jano3D]

Naxela If that can be done, that would be a great idea, would definitely work for me and it would definitely help winning over the BGE fans/users to use Armory.

[v3ny]

One more kick at the horse 25 days later

I haven’t seen anything I disagree with here other than not understanding why logics are not considered and being implemented. Is the problem that the code supporting bricks is difficult / not fun to work with?

Past:
Bricks for Rapid prototyping, they’ve been around for so long, so many people are familiar with them easy for artists simple and powerful. Bridges a lot of important gaps IMHO.

Present:
Logics for Rapid prototyping, more programmer centric infinitely configurable and customize-able. These are no brainers, it’s a flexible methodology although it does get into spaghetti country.

Future:
For max control, manageability in teams when the project scales to epic size, speed …code is the answer.

[Xico]

Think BGE is a dead horse really. This, looking from outside because I never used it and would never pick it up, reminds me of some random logic programming for kids I saw somewhere. Very dated and crude in my limited pov.
Holding on for something new to become something old won’t change things. I don’t like kha mostly because I come from openfl and the deviation from the flash api irks me but I won’t hold out for it to become openfl.
You say artists with a programming background are the audience but then separate programmers and artists further down, that pov is also limiting. You state what artists and programmers think like and it is different… that’s just what you think the division is and what you think those two groups think like. That’s projection.

[Philip_Knobody_Fong]

Well, I am a true artist, here let me show you how artist think, I develop methodology in UV modeling and creative way to scramble texture map against piracy, I have 30 years of working experience from conventional art material, sculpturing all the way to rich-media, 3D mechanical modeling technique won’t work well in organic model and took me 10 years to figure out how to solve the silly UV mapping issue.

With this technique, I destroy the UV texture map and re-apply with my original file, even if the realtime 3D scene were to reversed engineered, the UV mesh is a mess

[the_beginner]

Encryption for textures <3

[Jano3D]

Well, now that Steam takes BGE games, I don’t see why its a dead horse.

Maybe for you, but for many, BGE is the way to go. We all have our opinions. However, most projects I see done around blender or as extension of blender that are said Game Engine like Blend 4 Web and Armory, are focused on graphics rather then game play.

If the game play is crappy, you can have all the nicest graphics in the world, it still wont make a fun game. But you can have an awesome game play with crappy graphics and that is a fun game.

In BGE, yes the graphics are still limited, but there ain’t no limits as to what can be done using Logic Bricks & Python. Most python codes are already out there, easy to grab one and modify it to suit your need.

But just like you its just my opinion