koobas.hobune.stream
Best practice for a turn-based game
This is mostly a non-Unity question, but I have been thinking of using Databases instead of classic server-style way of communicating with a server, and I want to know if this method is practical or not. Here's what I've come up with:
In Unity, a certain player creates a room, generating a key for another player to be able to join it. Data about the room is sent to the database.
Another player inserts the key somewhere, calling the server for a potential room. If a room exists, both players are connected.
One new row is created in the database, containing information about each player (<1KB in total).
Whenever a player ends his move or does something that should affect the other player, this row is updated.
Each x seconds (with an upper limit, obviously affected by the delay) the information from this row is downloaded and managed in Unity and the game continues based on that information.
If for the sake of argument we consider the delay/limit value to be 1 second, then in a game of 5 minutes this means that there would be 300 download calls for each player, thus 600 in total, with up to 100 total upload calls regardful of the nature of the game. If 1000 players played constantly, that would create over 300.000 calls every minute. So my question is, how big are these numbers in reality? Have anyone tried this method or perhaps something similar? I hope this is not very off-topic. Thank you.
How large the overhead is depends on the size of the data that is downloaded. You send and receive packets. If you send a lot, it is going to take a long time. If you send them frequently, you'll need to download a lot of data. Let's say that the information you're sending per second is something the size of 500 Bytes. Running that 300000 times in 5 minute would be 150000 kB, or 150 MB, which comes down to 0.5 MB/s, which is quite frankly not that much, even the weakest server and network can probably handle that. Because the encryption and decryption of data is done by the client and not the server (I assume you want the server to just be a pointer, rather than control packets at the moment), it doesn't take a toll on it.
Now, I'm sure someone attempted this, but think of it this way - how much data are you going to be recording? 1000 players will record 150 MBs in 5 minutes if every second you send and record 500B. You will need to make the packets orders rather than plain data, just to edit a database, so it doesn't just add something like a new member in a stack (because what you wanna do is basically having a stack-based multiplayer), but simply edits the existing data for a turn.
Overall, I don't think the bandwidth is a problem. For testing purposes any computer acting as a server will do. However, if it's a 2 player game, I suggest you consider peer-to-peer and go from that.
Thank you very much for the well described answer. One more question that perhaps is out of your knowledge: how fast can the database iterate through its rows? As with 1000 active players (1000 rows) + let's say 100 players waiting to peer (as mentioned at step 1; another 100 rows), it'll give a total of 1100 rows, separated in two different tables. Considering each room has a unique key to be identified, does iterating through 1000 rows heavily affect the speed? Also, I forgot to mention that the data download/upload is done via PHP (similar to the Unity tutorial "Server Side Highscores"), though I doubt there is any better solution for this matter.
How fast it goes depends on what you do to go through (I assume you would have keys of the room acting as indexes, so have some sort of a hash table with info), and while I neither know the precise answer, there also isn't one. It depends on how fast your hardware and the managing program are. However, simply iterating through that data shouldn't be a problem. Think of it as a foreach loop with slightly more overhead.
The only question that remains is how fast do you want it to go? If you go super fast, then it will need a fast server if you have many players. $$anonymous$$y suggestion is to try and build it like HEarthstone - in Hearthstone, you can play things as fast as you can, but the speed has a limit - what the opponent sees is limited by, I guess, what the server sends. So technically, you could cap the speed if you ever saw it be a problem for the player that's waiting for their opponent's turn to end, and in that way, you're optimizing both traffic and overhead, while not making the playing player feel bad. Now, Hearthstone doesn't pause, but it sends things as fast as it can, and then if the servers are getting thrashed, it normally slows down. So it is flexible, really, but whether or not the servers are lagging is going to only be visible when the servers are really about to crash because the speed limit is high enough to mask everything else.
Overall, iterating through your "rows" would only be unbearably slow if you crunched a lot of data per tick or if you had some wild encryption checks going on. Even if those things happen, you can still optimize it by placing speed limits for the party that depends on the server to get information, essentially masking it.
