Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Server solution for a simple Android game

Discussion in 'Connected Games' started by Milten2222, Feb 17, 2019.

  1. Milten2222

    Milten2222

    Joined:
    Nov 14, 2017
    Posts:
    7
    Hi all!

    I have spent quite some time trying to figure out, what server solution would work for a simple Android\iOS game that would not require a dynamic interaction of two users. I have never done server programming before and I want to start studying it little by little. The thing is I don't really know where to start and have a bunch of questions I don't even know how to google to get some proper results.

    For example, I see that games like Clash of Clans somehow register user, but they don't ask him to enter any kind of password. Do they use something like GUID just to give a player a random identifier and use it instead of a password? Is it safe?

    I have tried out and wrote some basic logic on PHP and nodejs, connected both to databases and managed to get my Unity app connect to them and get some data, but what troubles me is that nothing stops me from simply opening an url I use for requests and get them displayed as a plain text in my browser. So in theory, anyone could just open the website and get all of the data out of database or, for example, add a lot of invalid one. As I said, I am new to server programming, but I feel like it's not the right way to do things.

    What I want to do is to make a server with a database, connect it to my Unity app and make it so it's possible to read and write data both from Unity and from host admin panel. I also want it to be safe, so a random person could not just fill my database with some random invalid data. I don't need any fancy things like player position prediction etc, just want my database to store something like user data, scores they get for levels, maybe a leaderboard etc.

    Please, provide my some info about these questions. Any hints, links, books or explanations are highly appreciated.
     
  2. Milten2222

    Milten2222

    Joined:
    Nov 14, 2017
    Posts:
    7
    Anyone?
     
  3. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,038
    There are a lot of security implications with having a server and a client, as you've seen. The first rule of servers is: NEVER trust the client.

    If you trust the client for anything, you're hackable.

    That said, it's practically impossible to do that. You can still do your best, though.

    Anything that modifies data should be done server-side. If the user pushes a button to trade 3 gold for a sword, the client should send that information to the server, and the server should check that that's a valid transaction before handling everything and storing it, then sending the appropriate information back to the user(s). The client should *not* simply send commands that tell the server to remove 3 gold from the account and add a sword to it. The idea here is that if someone else wrote their own client, they could still play the game, but they couldn't violate the rules of the game because the servers makes sure it's all legit and handles the details.

    Under absolutely no circumstances should the client send direct database commands to the server and have the server execute them. Never.

    When it comes to a leaderboard, that means that either the entire game has to be handled on the server, or you need a way to determine if someone cheated. (The latter is much, much harder, but is sometimes the only option for action game, etc.)

    As for user ID, simple mobile games likely generate an ID serverside (either UUID or simply adding 1 to the previous user's ID number) and store it on the device. With some simple security, it's possible to prevent most tampering and theft of accounts, but to make it really secure is harder.

    There is a *lot* of discussion about these kinds of things if you Google for them.
     
    Milten2222 likes this.
  4. Milten2222

    Milten2222

    Joined:
    Nov 14, 2017
    Posts:
    7
    Thank you very much for your answer!
    Ok, so I have to do everything I can to just give the user data from database but not allow him to insert anything.
    I want to make a user registration and a progress save which will trigger each 60 seconds so I will still have to take data from user. If not for SELECT then for UPDATE queries.

    Currently I am registering user in this way:

    Send a request to a server that a new user should be registered.
    Get a response from a server with a new randomly generated user id.
    Save this id to a save file on a hard drive.
    Use it later to send post requests to a web-page that will execute UPDATE queries for this user.

    Is this solution any good? I mean, if a user id will be required to update data, then a hacker could just get his id from the hard drive, open the web-page and alter his user data...
    If each database has its own username and password, could it be helpful to store user data in a separate database just to make it so even if a hacker gets an access to this database, it will not get any other data? And is there a way to ensure that a save will wasn't edited?

    In theory, if I made as you told (like the client only sends an event that a "Buy armor for 10 gold" was pressed and then server decides what to do) than no UPDATE requests would be necessary, but it clearly would not work for a game that could be also played offline. I would have to save the data localy and then push it to the server...
     
  5. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,038
    If you allow the game to be played offline, then there's almost nothing you can do to prevent cheating. You could make sure the values are sane, but that's about it.

    Yes, if you store the user ID on the hard drive, someone could find that ID and access someone else's data. Even if you encrypt this info, it's possible for a skilled hacker to get it. In the end, the user has to be responsible for their own hardware.

    The separate database won't help.