Hey, I’m an indie dev who’s working on something that will hopefully be a “live service-like” game at some point and I need to figure out how I’m going to deal with storing player information among other things.
I don’t have the budget to run a dedicated server so I will have to make p2p and listen servers work.
As a Blueprint Andy with some Python/JavaScript experience and lots of determination, backend and databases is unfamiliar territory for me so I need a nudge in the right direction
From what I understand on the topic, client to database communication is a big security risk so I cannot simply have the clients connect directly because this would require them to hold the authentication info to the database. Anyone could decompile the game and grab this sensitive info.
So I’m going to need a webserver that acts as a gatekeeper to the info stored on the database through some API.
Here ends the extend of my knowledge and the questions begin:
Do I have the right idea?
What exactly does the webserver need to do? Basically have code that handles the API communication? And then links this to a code that read/writes on the database?
What is stopping a malicious actor from telling the webserver to do what they want to?
What tools are available to me to make this as easy as possible? (Any plugins/software/services/database types etc that make the job easier?)
Are there any games out there that work like this?
In a system like this are there any pitfalls I should be aware of?
Appreciate any input!
Also if there is any learning material on the topic I should know about, please share:)
The biggest issue I see is “Listen Servers”. The host client is the server, so essentially some level of auth will have to be given to them to access the DB.
Game Server → Web Service API (Restful) → Database
Writing an API will help mitigate “some” of the security issues. This is the correct approach, but it’s usually a dedicated server that’s communicating with the API.
You could put the web server in front of the API.
Client/Host → Web Server → API → DB.
You’ll need a lot of security on this though. Request timeout logic, strict request/response protocols etc.
Thanks for the reply. Sorry for stupid questions, but how does any app in the wild that is in a clients hands deal with this issue?
Is there any point to having the web server then? I thought the API was what was limiting access to the database, and the webserver simply acts as an interpretor of what they need to do without giving too much authority.
Identify and authenticate the Host client. Simple requests to the API that do not allow for modification. Strict validation of requests and so forth.
I’ll assume you’ll be using Steam or EOS. Both of these will provide a way to identify each user. The userID can be used as a part of a key when making requests to the back end.
The Web server will stand in as a guard/validator. Host will request validation, web server response will be a token for future requests (limited life span).
Once validated and token received/stored the client can then do formal DB requests. Said requests will be filtered and validated by the web server. The web server will use the API to Get the requested data, then format the response.
This hides the API from the public (no direct access).
Requests to the web server without a token or ill formed tokens can be dropped outright.
web server will validate the token, then validate the request/params, then perform try/catch. format the response, and send.
I’ve been taking a closer look at EOS lately, specifically Player Data Storage and Title Storage in the Dev portal. Is it reasonable to think those are valid replacements for a third party hosted database like I was planning?
Honestly I only need to store a few data tables for stuff like Player Account Progression which are specific to each player and Ability Data which is game-wide so I can apply hotfixes and balance changes without needing to patch my game every time.
Do you have any experience with them? Seems super convenient if I can use them as a database and skip the part where I have to develop my own ecosystem. But I feel like I haven’t discovered the downside to using them yet, seems too good to be true considering they are free to use
The Player Data Storage is used to hold VERY small amounts of data that doesn’t get used to often in the game. Like maybe screenshots and such. This is because PDS saves THE ENTIRE FILE to their database (for some reason). AND it has very small read-write limits, so you can’t make use of them too often.
A RESTful api through Express.js is a very good start, but keep in mind EVERYTHING the players give you is the Devil’s Work. So, if the server is the player (which they are), it won’t be hard for them to modify values on their end with something like Cheat Engine BEFORE the api call is POSTed to save the data.
This is all speculation and I’m honestly guessing a bit because unreal engine takes too long to build to test this theory out and I already had to build it 13 times. If I’m wrong, DEFINITELY correct me on it!
I recommend building from source to be prepared for dedicated servers
I don’t see ever reaching those storage limitations with a data table. But 1000 requests per minute might cut it close, maybe? Not sure if those are 1000 request per minute for all users across the project or just that specific user.
I’m thinking of saving the player progression in a json file or similar and just reading and writing over the whole thing when I need it, which won’t be very often. Probably once on account login, and then when joining and ending matches I guess.
but keep in mind EVERYTHING the players give you is the Devil’s Work. So, if the server is the player (which they are), it won’t be hard for them to modify values on their end with something like Cheat Engine BEFORE the api call is POSTed to save the data.
These are good points, the plan is to have a matchmaking system that picks out a random player to be the server so any given player can never reliably be in position to cheat. Ofc if they have ill intentions they will eventually end up being the server and succeed, in which case I would have to rely on other counter measures
If im not mistaken, the limitations of the read and write for PDS is across the ENTIRE project. so, its 1k per minute for every user at once.
Lastly, the player that can cheat that is randomly chosen can still easily tamper with the values of the game and hack it. If its a pvp game, what stops them from using cheat engine to rewrite their score to a higher amount? lower the enemy score? infinite time? infinite resources? a server has TOTAL rule over anything, and youre giving that to just any client.
Like COD lobbies in the past, they are very susceptible to cheating, so be very careful!
If you want to use the Gold Standard for database management and dedicated server fleet, the answer seems to be AWS with its Gameflight system.
