I’m currently working on an online multiplayer turn-based RPG, involving functionalities like registration, login, friends, invite friends.
Just asking for some directions, if anyone could share his/her experience through this, regardless of the technologies used. Mostly interested in the database side where you handle registration or login (session management), with user + pass, and with login tokens from fb, google, etc.
I have a “user” table with columns for pass and token, among others, but still there are so many possibilities for handling login/register that I don’t know what to choose to be future-proof. What I know from experience is that at least the “online status” part works best by doing a periodic request to the server to save a “last activity timestamp”.
Technologies I use
Client: Unity
Game Server: WebSocket4Net hosted on Google Cloud linux VM with my custom server logic DLLs
Database Server: PostgreSQL hosted anywhere (not decided yet where)
Database Interface Server: Currently, running on the same machine as Game Server. Using Npgsql to translate custom requests (RegisterRequest, LoginRequest, InviteFriendRequest etc) into database queries/
Any input from you guys would be much appreciated!
– Lucian
I rolled my own system. I don’t necessarily recommend that approach, but it is working for me, though I don’t use FB or other 3rd party account systems.
I have a login server which handles all account and character creation, as well as logins for existing accounts. It talks to the database server where those are created/stored.
I have a server I simply call the Tracker server which keeps track of every online player and what server they are connected to. When a player gets into the game, the server they connect to sends a message to the Tracker server that they player is connected to that server as well as some other stats (their exact latitude/longitude, ship they are in, etc). Every 3 seconds the server updates this information to the Tracker server, as well as whenever a player disconnects or moves servers.
The tracker server is then used for relaying private, group, and global messages. In my game players can join up into a “squadron”, which is a temporary grouping of players. Each player then can see what ship everyone else in the squadron is sailing, as well as distance from their ship even if the players are connected to different servers. This is all based on info the Tracker server is maintaining.
I used PHP years ago, before jumping onto SmartFoxServer which plugs into every database pretty easily and provides easy components to manage the signup and login phases. Took me less than I expected to move my old clunky php system to SFS.
What do you mean by future-proof exactly? What do you expect to change?
Seems like what I had in mind, mostly. I’m glad someone actually uses a similar approach in already-published games.
This helps. Thank you!
Number of users, but thing is I was also asking because I also don’t know what could change.
Just some general directions were what I needed. Like “Don’t do x, because I did it and Y happened”. You know, experience sharing.
Databases like Postgre can scale pretty high so I wouldn’t worry too much. The worst it can happen is that your game will grow massively and you’ll need a larger DB server which is a nice problem to have, after all.
In terms of dos and don’ts it’s usually common sense such as make sure your DB queries can’t be SQL injected, keep your game server and DB server connected via local network, if you’re storing passwords salt them, etc.
Oh and if you’re using salt make sure it’s random (no user’s data) and per-password.
The token-based auth is great for dealing with a non-web client like Unity, as well as communication between the services. The tokens can be passed around and used to authenticate and authorize wherever you need them. This allows you to have, for example, a separate server just for logins, which are critical, but also potentially subject to really high loads if the game is really popular and/or gets attacked. The rest of the system can keep running even if logins are temporarily down.
Generated the client API code (partially) using swaggerhub.
