How hackable is unity?

[Callan S.]

I was thinking of how unity can speak with a database, but kind of in spurts with a gap in between of say 3 seconds.

I was thinking of what if you had a high action game, lots of bullets, etc, but you still only sent whatever data through every three seconds or whatever time, with stuff in between simply regulated by the application of unity?

I mean, even if it is hackable there are probably things that could be done to check the data that does come through and see if it's abberant at all, in terms of what would, on average, normally happen when the application monitors the action.

Not like it's all well beyond my capacity right now anyway, but just thinking!

[Chris]

I'm kind of confused with what you mean by Unity when you are talking about databases. The Unity player is probably very easily hack-able. Even if there aren't any decompilers available, which I'm sure there are. Hex editors could still work wonders.

You shouldn't look at Unity as the only way a user can interact with your server. I could very easily send your server a request as if I'm Unity player using another program and attempt to break my way into your system.

The server therefore needs to constantly check what the user is sending it. The most logical way to control what the user sends is to limit what the server can understand. I've developed a system that only sends buttons pressed and mouse movements made from a web browser to the server.

user hits button -> event sent to server -> server takes action depending on button pressed and responds -> users display is updated

As for the speed. With normal one-way requests this would be dramatically slow. That's why people invented sockets.

As for the database end of things. A database such as MySQL isn't made for developing fast action games on. Not only is it impractical, it's a huge work around. You could simply store user information in a buffer, other processes can then access the information needed (nearly) instantly. Once a round is completed, you can then store details in a database such as kill count etc.

[hallsofvallhalla]

correct, if you use a DB for unity to store player data then it needs to be a level end type of data or after certain events. Like i was using post methods and PHP hot the database after every action like mining and such. Not for combat. Onbe game I had it where only if you completed the level would you get anything you earned from the level. Made DB traffic far less.

[Callan S.]

Thanks guys (nice icon, halls!)

It's pretty much what I figured.

I'm thinking action game as in sending no data at all for most key presses and events - 99% it's handled by the unity application. Every few seconds or as you say, maybe end of level, it passes on, say, a score value. What I'd do is make sure the score cannot be more than X amount. So even if someone hacks it, best they can gain is X amount (and I'd put in some monitoring code to watch people who got constant perfect X amount, as a bit of monitoring on that).