godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

C# | New Special Camera Node for writing Multiplayer with separate dedicated server #6375

Open adainx opened 1 year ago

adainx commented 1 year ago

Describe the project you are working on

I was trying to make a proof-of-concept project for myself. It is simple game where I wrote C# Dedicated server using System.Net and System.Net.Sockets (It's not Godot's ENEt system!!). I'm using Godot 4.0 beta 17 mono build, Client is C# too. Everything works perfectly, each players can control themselver expect one problem. I tried many solutions to overcome this problem (for example: making current for player camera, but from Godot's DOCs we know that: Only one camera can be set as the current).

Describe the problem or limitation you are having in your project

When new player connects, the other players that already on server start to look through the camera of new one connected. New camera become current (Camera3D.MakeCurrent();). Players still control their Player.tscn, but only one camera available to be set. This problem doesn't exist in Godot's Enet Multiplayer, but I like I said before I didn't want to use Godot's Enet MP System.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I wonder whether it's possible to create new camera node that will allow create multiplayer where player can have each camera for themself.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

When creating and spawning new player, he will use new camera node that wont change to new one. So every player will use their own camera in their Player.TSCN

If this enhancement will not be used often, can it be worked around with a few lines of script?

Godot starts to become more and more popular, and I think a lot of developer will start to look to create their multiplayers projects using Godot.

Is there a reason why this should be core and not an add-on in the asset library?

This is about adding new Camera node. If it's possible to made as an add-on it's cool. But I didn't find anything, I think it's something that should be and work out-of-box.

Screenshot I made. As You can see, both player looks through one camera, even though they are both have their own. Like I said, it happens because when new player comes to the scene, his camera becomes current.

multiplayer_camera

Thanks!

AThousandShips commented 1 year ago

Are you running both players on the same window? Are you making a split screen project?

adainx commented 1 year ago

Are you running both players on the same window? Are you making a split screen project?

No, I run it in multiple instances. But I also tried exporting project and running it from created game .EXE. No, it's not split screen, I tried to make simple multiplayer project. If I misunderstood Your questions, please tell me about it.

AThousandShips commented 1 year ago

You probably need to use replication and spawning, as you can absolutely have different cameras in networking, but hard to tell without knowing how you actually make the networking work

Haven't done networking myself much but I suspect the solution is to have the other players use a different node than the one of the player locally, or just make the camera on those not active in that copy, so player 1 in session 1 has camera active, and player 2 in session 2 has camera active, and so on.

adainx commented 1 year ago

You probably need to use replication and spawning, as you can absolutely have different cameras in networking, but hard to tell without knowing how you actually make the networking work

When player spawns, in the root node of 3d scene and in remote tab in Godot appears new Player scenes which is (PackedScene), and when new node appears previous player node lose it's current check. I can try to make more screenshots or set Server and Client repository visibility to public, if it helps. But the problem is definitely with the camera, it's written in Godot's Docs that only one camera can be current. Indeed, while the game was running I tried to recheck current setting cameras from one player node to another and it return to be checked again and not checked to the first player. I also tried to make it from code in method where player spawn to set _player.camera3d.MakerCurrent();, but it only helped me to make cameras set to the last player connected. Sorry my English might not be perfect.

The reason why I decided to create this proposal is because I tried everything that is possible and nothing helped me. Most of the solution is for Godot ENEt Multiplayer System.

AThousandShips commented 1 year ago

Why do you need to set all cameras to current? You should only make the camera of the player current, not of the remote pawns, on each client only one of the nodes is the player?

adainx commented 1 year ago

I do not set all cameras to current (but funny to notice I tried it too). I was trying to make current for new client and for his player scene when spawns in the world. Yes, on each client only one of the nodes is the player. It works only for one player (client), not for all, if it didn't I think players wont be able to control their CharacterBody3D, but everything is good with controlling (movement).

AThousandShips commented 1 year ago

That is very strange, sorry misunderstood what you said, setting the correct camera as current in each client should work, but I can't tell much without actually seeing the method you're using

adainx commented 1 year ago

I can set either Server or Client repository to public. It's very simple projects. I'm just thinking, that You might don't want to spend time looking for the code and how it works OR I can just put screenshot of Player.TSCN-scene nodes structure and put the code contain player spawning, later (later because it's night to me now).

AThousandShips commented 1 year ago

Sounds good, I'm sorry for misunderstandings it was quite late for me as well, I'm almost certain this functionality is possible but if it isn't it is definitely a bug rather than a missing feature