I’m learning low-level networking and make basic multiplayer games just for sake of testing and learning and I was wondering about server side optimization.
At first I thought it’s best to make separate scripts and scenes for client and server but you can easly make error or bug this way with small differences between scenes. Then I learnt about headless mode that strips away all visual stuff and leaves only physics and code.
But it creates another issue, headless mode only disables rendering but all nodes are still in memory. Things like mesh renderers etc are still saved in nodes and loaded by server even though they are unnecessary.
For small games it doesn’t make much difference, but I try to learn best habits from beginning and I belive for larger scale projects it may cause problems.
So I wanted to ask if you have any recommedations on what should I do.
This is not the case in dedicated server exports, as the mesh/texture data isn’t present in the PCK in the first place. Therefore, I wouldn’t worry about it as it won’t be a problem once you export to a production environment with the correct settings in place.
Won’t having empty e.g. mesh instance 3d with placeholder mesh, still take up some server memory space? Or these values are so small they don’t matter?
And what about scripts, should I just make one script and divide it for client and server use. Doesn’t it make some kind of space for vulnerability for hackers to change code and send to server or via server? I’m not sure but having simple “is_server” check doesn’t seem safe and I think it could be modified somehow or am I wrong?
It will take very little memory, as PlaceholderMesh only stores a handful of properties such as an AABB for visibility culling. There’s no polygon data, which usually represents 99% of a mesh’s size.
If your server is well-designed (always validate client inputs, don’t trust what clients send), it’s not an issue in terms of security.
This whole post is an example of Future Proofing. You’re trying to plan for problems that may not exist in the future. I highlight this section because it shows that you don’t know how multiplayer @rpc calls work in Godot.
I strongly recommend that instead of spending all your time and effort thinking and talking about potential problems, you put that effort into making a working prototype.
If you learn how to use @rpc calls correctly, your server will not be vulnerable to attacks from outside.
@rpc calls are from high-level multiplayer api that godot provides, and I’m trying to learn making netcode by myself.
I agree, my question was a bit stupid since server checks each packet anyway, if client changes himself to server, only his client will think he is server but actual server won’t care about that.
I have working prototype, it’s only creating server and adding players to it and simple movement but I’m trying to build on top of it. Before I spent a lot of time mastering composition for singleplayer games, now I’m trying to implement that knowledge into networking, that’s why I spend time trying to learn good habits first instead of blindly hardcoding everything and hoping everything will be alright in future.
I don’t plan to make full game right now, rather I try to build systems and later I can build games like Legos with them. Usually, what works best for me when I learn is to look at other people examples and try to analise them. Problem is there is not much about low-level godot networking out there so I kind of have to figure out by myself.
Then the answer to your question is that you have to build all of those checks in. Godot does a lot of things to protect against script and injection attacks. You’re going to need to study up on Internet security, because that’s all going to be up to you. And frankly, it doesn’t matter how Godot does it.
So yes, you are going to have to create a server script, and re-implement multiplayer authority checks, and guard against things like objects getting passed as arguments and untrusted scripts running. Then you’ll have to create a client script.
Because low-level Godot networking is just Internet networking. And every I know who knows about that (including me) doesn’t want to mess with that because we know what a hugely deep rabbit hole it is, and how missing one little thing can ruin your game. So most people use Godot’s nodes and @rpc calls to handle it, or they use a plugin like Netfox to handle it.