Network: Assign Inputs to player nodes

[fairhat]

How do you assign the inputs to the player nodes on the server side?

Your example is a bit too complex to understand where you actually bind these things together.

Also: It would be nice if you would share a demo where the server does not participate actively in the game (has no player that he controls) since in server authoritative games the server usually is just a spectator.

[fairhat]

Sorry, another:

You say that the server should use "Input.get_custom_bool(...)" to retrieve the value. However, using input.is_pressed just works fine in the server too? Is that how its intended to work or could using is_pressed lead to unwanted behavior?

the deeper i dive into your addon the more i'm thankful that this exists, lol. something like this should be integrated into godot by default

[Kehom]

Ohhh. Ok. Well, let's go a bit back. Which example are you looking at? The project contains two examples that use the networking system. The one named "network" is similar to RTS games, where you select units with the mouse then command then to move into another place. The "mega demo" is similar to a shooter game.

In the first case I'm using a bunch of "custom input data" while the in the second case absolutely no custom data. The network.register_action() function is meant to tell the network system that you want to replicate a mapped (through the project settings) input. This function allows you to specify if you want the data to be dealt with as a simple boolean (you set the second parameter to false) or analog data (second parameter true).

When you use non custom data registered as boolean you simply use the input.is_pressed(). During the replication, all of those booleans are encoded into a single integer, using the smallest possible number of bytes. In the case of the mega demo, where I register 3 actions as booleans (jump, sprint and shoot), those will use a single byte within the encoded input data.

Also: It would be nice if you would share a demo where the server does not participate actively in the game (has no player that he controls) since in server authoritative games the server usually is just a spectator.

I have been thinking about doing something like this but it will probably be in a separate project and I will have to fix a few bugs before.

the deeper i dive into your addon the more i'm thankful that this exists, lol. something like this should be integrated into godot by default

Thank you for saying this, it really means a lot to me! Still, I don't think something like this should be integrated by default, mostly because there are cases where this system is way too much for the requirements. And probably it will not be enough for some others.

BTW, I'm not sure you have checked my written tutorial regarding this entire addon pack, which can be found at http://kehomsforge.com/tutorials/multi/GodotAddonPack/ Specifically for the networking: http://kehomsforge.com/tutorials/multi/GodotAddonPack/part02/ In it I do describe a lot of the concepts used on both demos that use the networking system.

[fairhat]

Yea, i'm reading the tutorial though it would be easier to follow if you added some UML-type diagrams that explain the overall architecture of your plugin. I might just do it once i fully understand how it's working. If it's okay i might ask a couple more questions soon.

Thank you for saying this, it really means a lot to me! Still, I don't think something like this should be integrated by default, mostly because there are cases where this system is way too much for the requirements. And probably it will not be enough for some others.

Well synchronizing inputs (just to name one of the features) over the network could be useful for many cases.

[Kehom]

Yeah, I have been thinking about adding more images into my tutorials. I feel those help a lot with understanding things.

It's more than OK to ask more questions! :)

Consider some very simple case games where there is absolutely no competition, only cooperation. While authoritative servers are still valid for those cases, maybe they can be way too much and allowing the client to decide at least it's own character's state may be acceptable. In this case, it would not be necessary to send input data to the server, but the actual state of the client's character.

Or, consider a game like chess. You don't have to send input data at all! You just send the algebraic notation to perform the synchronization of the game state.