How To Approach all this?

im not gona give tomuch info oofc

Why? Everybody has ideas that they think are great; nobody will steal your idea. It's execution (actually building a thing that people want to buy) that's hard, not ideas. The more you share about your idea, the more specific advice you might get, which would help you build the right thing.

Anyway, it's unclear what you're trying to ask.

Are you asking about a general game server, that does the "run and gun" simulation sharing with all playes in the same game location?

Or are you talking about the specifics of persistent account data, character progression, inventory that follows the player through time, and so forth?

Those are almost completely different systems. The "gameplay" network protocol typically comes from some library that knows how to integrate with your game engine. If you use Unity, you can use something like Photon. If you use Unreal, you can use the built-in replication system. (If you're trying to build a big game as your first real project and aren't using one of those two engines, take a long hard look in the mirror and ask yourself what's wrong with you :-)

For the character persistence, you'll typically use some SQL server (MySQL, Postgres, Microsoft SQL Server, and so forth) or perhaps some document store server (Redis, ScyllaDB, Riak, Cassandra, ...) The gameplay server will receive name/password from the player, and will use this information to look up the character progression from the database, and inflate it to the gameplay code; the regular replication mechanisms will then make sure that the player sees what he's got. Just make sure that the server is authoritative on who gets to add what to their inventories -- having a message from the client that says "I picked up object X from the ground and added it to my inventory" is a really bad idea, because hackers will forge these packets to add whatever they want to the inventory.

WIthout knowing what you're actually trying to do, and what you've already tried to build and what you're stuck on in more specifics, I don't know how to give better advice. Let's start here:
- use Unreal Engine
- use the Unreal built-in networking/replication/RPC stuff for gameplay networking
- use some database you like for storing per-player character data; you're going to have to write some C++ to interface the database API with the game engine, unless you can find a plugin on the marketplace
- if you don't know which database to pick, try MySQL, because it is easy to install, it has plugins on the marketplace, and there are tons of tutorials online on how to use it. Just make sure all your tables are InnoDB, not MyISAM.

Thanks for that reply dude! and yea il try giving some more info now

3rd/1st person survival multiplayer game (pc) currently but then to work on consoles

Engine is unity
i already have it working with the unity multiplayer thing but i want something more dedicated with a database and yea preffs mysql as i know it abit

and about the persistent account data, character progression, inventory that follows the player through time, and so forth part

yeaa i want account details inventory health and all the current data to be stored in a db and be updated in real time? as the player progresses?

i hope i aint seemed like an idiot again and helped u help me????

like how do i get my game talking with a dedicated server i mean which is running like all the main client files / db along side and the client just uses a login client with all the map data and stuff like that but deals with no data stuff all that it server sided? is that the word "server sided"?

You can store data on a sever and set up a time to pass that information into the database for backup, and so forth. During real-time I normally would keep a server to client relationship going without calling to a database to update health. Using memory to store information is much faster than doing database calls for every little thing, and also more realistic in my opinion. You will need to setup a time to send all that information to a backup source in the event your server needs to shut down, crashes, ect... so your server will reload everything from that source back into memory.

If you've ever played an online game and the server crashed, but you were rolled back a day or two, that's usually because they didn't update the data to a backup source yet, but this also goes to show they're not making 10000's of database calls for every action, they're storing the information in memory server-side.

@hplus0603 Would be able to chime on this a bit more I'm sure, and please correct me if I'm wrong on any of the above as I'm far from an expert in client to server operations.

yeaa i think thats what i was thinking kinda i dont want there clients talking with the db? i want there clients talking to a headless version of my game which then inturn talks to the db? is this correct? like i know i probs sound like an idiot hahahah but sorry

18 minutes ago, Ryan Hopkins said:

yeaa i think thats what i was thinking kinda i dont want there clients talking with the db? i want there clients talking to a headless version of my game which then inturn talks to the db? is this correct? like i know i probs sound like an idiot hahahah but sorry

You 'should' never have a client that can have any form of Database access, this is extremely risky and puts the entire database at risk. Someone can strip all the database information from the client and gain access very easily. The server should be the only way your database can be accessed, and that server will send the result after being filtered to the client.

I would have the server hold all information in memory, and work directly with the client, but make sure your server has a way of backing up data.

sooo no to the client talking to the db but lets go back to how do i get the db storing the data and the client talking to it ect ect all in real time and regarding the backups? how would u approach lets say for example really simply manually on a daily basis

well not real time but like how u say have it like dump it?

like mainly how do i get my unity game talking to a dedicated server? which is running what ever it needs to run (please explain) and also the db "mysql" preferably? i know i probs sound stupuid here but yea! im clueless! and everyone has to ask these questions at somepoint?

Pick any off-the-shelf database, and there will be documented methods for handling backups. If you use a cloud provider for your database, they mostly have fully automated backups.

2 minutes ago, swiftcoder said:

Pick any off-the-shelf database, and there will be documented methods for handling backups. If you use a cloud provider for your database, they mostly have fully automated backups.

im aware of that part kinda im not that stupid

34 minutes ago, Ryan Hopkins said:

well not real time but like how u say have it like dump it?

like mainly how do i get my unity game talking to a dedicated server? which is running what ever it needs to run (please explain) and also the db "mysql" preferably? i know i probs sound stupuid here but yea! im clueless! and everyone has to ask these questions at somepoint?

I don't work with Unity unfortunately, but I would suggest starting here:

https://docs.unity3d.com/Manual/UNet.html

https://docs.unity3d.com/Manual/UNetClientServer.html

You'll want to be very familiar with how networking is handled using your engine. After you're able to establish a client server connect, then the final step is having your server access your database to read and write. You can look into:

https://docs.unity3d.com/ScriptReference/WWW.html

https://docs.unity3d.com/Manual/UnityWebRequest.html

to work with a script that directly connects to your database. Otherwise you'll want to look into script calling using C# directly. I rarely use C# and cannot offer much assistance regarding the steps. Possibly this video might help?

perfect thanks dude

No problem. I wish you the best in your progress.