Creating what you’re describing is quite advanced. You would need to understand networking, network architecture, full-stack website creation, and web architecture. For now, I suggest storing any player data (name, level) on the player’s device and just sending it to the server when they connect. I’ll try to explain what creating something like this would involve.
The easiest way of describing networking is that it’s a lot like sending packets with information about the simulation (what buttons were pressed, that Nodes were created/deleted, name of the player etc.) over the post. The person that receives the packet is then responsible for interpreting it and applying it. This is low level networking.
Godot provides a standardised “form” that it fills out, puts it in the post. On the other player’s end, Godot also provides a way of receiving the packet, then interpreting the form inside, and applying any information to the simulation. This is high level multiplayer.
The way the host and player ‘establish’ this connection/postal route is not like logging in. It’s like sending a packet to the other player’s address with a note “hey i want to start sending you data, do you accept?”. The other player then replies “yes”. Only then do you start posting them the forms related to the simulation. There is no postal identity validation, and if you got the address wrong, you won’t know because you won’t get a response (this postal service does not return undelivered post - at best tells you the address does not exist).
Creating a player login via establishing a connection is the completely wrong approach. This connection is just a way to send packets between two people on the internet. It cannot validate identity, even half-reliably. To make it seem otherwise, you would need to do a lot more, like by creating your own identity management service/API/website.
Perhaps, it would help to understand some high-level architecture of existing services.
Roblox
In this analogy, networking in Roblox would be like having a warehouse in the middle. All players send packets to only this warehouse. A clerk (in the identity management service department) makes ensures they are who they say they are, and then also host the game.
First, the identity management clerk confirms they are who they are (e.g. via email + password + one-time passcode), then the player is sent a unique number (session token) to attach to all the parcels they send to the warehouse.
The warehouse also hosts the game (the authoritative simulation). This ensures players’ are who they say they are, the warehouse can receive these parcels more reliably, and the simulation cannot be manipulated by a malicious host (in theory). It also means that the more people want to play e.g. lumber tycoon, the more game hosts can be created and their parcels can be directed accordingly.
Importantly, making it difficult for the host to manipulate the simulation to e.g. give themselves free cash lets the warehouse sell in-game currency for real $$$.
Needless to say, you would need the time and money for a warehouse and its operations.
Minecraft
Minecraft, on the other hand, just has a an identity management clerk the players and server (optionally) check in with. When a player starts the game (not a realms instance - realms work like Roblox), they first check in with the clerk, and get this token. The clerk keeps track of where the player sent the information from.
When a player attempts to connect to the server, the server first checks the player’ address and token with the clerk, before letting them in (as long as the clerk confirms both are valid). Then, all the players start sending the data to the sever directly.
Now, the player’s level, inventory etc. are still provided by the server (allowing the host to change it) as it is extremely difficult and cumbersome (for both the host and the identity clerk) to ensure the simulation cannot be changed.
Creating an identity management service/website is a whole project within itself. You would need to know how to make it, and maintain it. This could be done (like you said) via Firebase or a HTTP API.
I don’t recommend learning how to do this if you want to make a good game. If you want to, a good starting point may be tutorials (for absolute beginners) about making a basic social media (e.g. twitter, blogging) website using a XAMP stack (PHP), ASP.NET (C#), Django (Python), or Node.js (JavaScript/TypeScript).
After this, if you wanted to make centralised game hosting… I’m not sure where to start to be honest. You’d need to know about virtual machines and/or containerisation (Docker/Kubernetes), and probably cloud hosting using e.g. Amazon Web Services (AWS) or their game tech. Then create a separate build of the game just for the server, and create the logic for creating new servers as/when players need them. Maybe running a ‘home-lab’ could be a good (and tedious) starting point?
Running something like Roblox/Fortnite is a genuine software engineering challenge that is worked on by teams of people. Most smaller games do not do this as it doesn’t necessarily add to the player experience.
I appreciate this may sound discouraging. I think it’s more important to focus making things that you can make and enjoying the process.
In my experience, in game/software development you try to create a prototype that barely works some of the time. As long as you have some sort of multiplayer, like the one provided by Godot’s high-level multiplayer, I think this is sufficient for now. Later, whether it be due to curiosity or necessity, you can add player identity validation by creating a basic HTTP API.
In the meantime, try to store any data (level, player) locally. Send it using an RPC (remote procedure call) after the player connects to the server.
Hope this helps! Remember to enjoy the game development process and keep an open mind in the directions it takes you.
Let me know if you have any questions.
