Anti-Cheat / Glitch in game - unity3d

Currently I am working with a team on a Unity-based game. The game is still in development and alpha version.
Recently, we saw that the game was vulnerable to Cheat Engine, speedhack etc. Updates after updates, cheats are now stable. We also introduced the ACT or anti Cheat Toolkit of Unity. As the game is Unity-based, it is easy to implement ideas in the game.
Though "hacks" are stablized, "glitches" are not.
This is an open world Survival game and it consists of picking/dropping items. The glitch is that when two players pick the item together, (currently you have to press E while the crosshead is over the item to pick it up) the item gets duplicated. We have been working DAYS to fix it, but no fortune.
We introduced that a player cannot pick up an item when there is another player nearby. It looks odd and we want the game smooth. We also tried auto pick up item. That's our plan, but are there any more ideas what we can do?

If your concerns are players cheating by modifying memory values, as well as maintaining a synchronized game state to avoid problems like item duplication, you should look into setting up an authoritative server that will contain and update the "official" values and state of the game.
Basically, rather than storing values and performing actions directly on the player's computer, the game will send a request to the server of what it wants to do, and the server will perform the actions, update the official game state, and send the new state back to the player so their game is updated.
This will prevent memory editing because even if a player modifies a value on their screen (such as currency or health) the server contains the true value.
It will also prevent exploits like speedhacks, because rather than having the local game directly move the player when a key is pressed, the keypress will just send a movement request to the server, which will update the player's position, and send back the new position.
Finally, this will prevent item duplication, because when both players attempt to pick up the item, they will both send an item pickup request to the server. Whichever player's request arrives first will receive the item, then the server will update the game state so that the item is no longer on the ground, and the second player's request will be ignored, because the item they're trying to pick up no longer exists.
Simply put, the best way to prevent cheating is: Don't store important values or perform important actions on the player's computer.

Related

With Unity's InputSystem is there a way to discriminate between players when using c# events?

I am experimenting with Unity and have created a multi-player local coop environment. I have a Player Input Manger create a new player whenever a new device connects. These players have a Player Input component that is set to use c# events. Then I have some code that listen for the events and logs to the console. I want to be able to distinguish between players, but at the moment events get fired for every input on every device.
I have watched countless tutorials on the Input System, but local multiplayer never seemns to be addressed. All the solutions I can think off seem nasty. I can get it working with send, broadcast and unity's events, but I would like to know how to achive it with c# events.
I don't think you can through the event system, no.
However, if you use the Input Manager directly (i.e. Input.GetButtonDown()), then you can go into your project settings and set up the buttons and axes to be gamepad specific.
Essentially, what you need to do is duplicate all of the buttons and axes in the Project Settings Input Manager for however many players you want to support, and then go through them and set the Joystick index to a fixed custom value.
Then, instead of having, for example, a "Jump" button, you'll have "Jump 1" through "Jump 4", each unique to its own gamepad.
See the last entry in the Virtual Axes table for more info:
https://docs.unity3d.com/Manual/class-InputManager.html

Refresh rate of pose of Base Station in OpenVR

I am able to get the position of the base stations but this only updates once, while controllers and HDM are constantly updated. Is there a way to force the refresh so that I can get the position of the base stations (trackingreference) in real-time? thanks!
Technically there is, I'm talking driver side right now, but it kinda does nothing, tracking references are normal tracked objects after all so drivers can update their poses like normal with a vr::VRServerDriverHost()->TrackedDevicePoseUpdated() call and on init through the pose returned by GetPose()
Now, that should work, but it doesnt, even more most of the time custom tracking refences don't show up in SteamVR. what it does under the hood? no idea
Also commercial headsets might update their tracking reference's position only once on startup which seems to be the case

UNITY: Synchronizing variables across a network

Ok, so I'm trying to implement networking for a school project. (Part of my team's final project)
It's supposed to operate on a turn-based system. IE, when a player is done, they hit "next turn" and they lose control, while the other player gains control.
So, to test my networking and get the basics going, I've made a little program that spawns a cube whenever a server is joined or created (so one cube for each player), and each player is able to move only their own cube.
So far, I can have the cubes moving around and their transforms are perfectly synced up on both instances of the game simultaneously, and each player can only control their own cube.
However, when I click "Next turn", the turn only changes on ONE of the instances.
According to this, it SHOULD be watching the turn change:
And this is my turncontrol code (It's a little sloppy for now until I find a hardcore way to set the code's player number depending on whether they're the host or client)
How the heck do I make sure that when I click "Next Turn", the turn changes in both instances, and how do I make sure that the cube's player number is dependent on whether they're the host or client?
That and I have the very strong suspicion that the assignment of a player's "player number" (IE, whether they're player 1 or 2) is being assigned locally (Not reflected across instances) as well, since each player can only move when the turn is set to 1 (Meaning that when both players spawn, they're both set to be player 1. :s)
Any assistance would be appreciated. Networking is completely new to me and I'm wigging out trying to wrap my head around it.

Using GameCenter for parallel turn based games?

I've played around with making turn-based games using GameCenter. I understand that by default, GameCenter assumes that out of a number of participants, at any given time, one player holds the "play baton", and that this player is the only one who can affect the current game state. Gameplay is asynchronous, i.e. whoever's turn it is can take their time, and the other players will be notified once it's their turn.
So far, so good.
Now I want to use GameCenter to implement a similar, but slightly different kind of turn-based game: an asynchronous game where, instead of a serial player succession, players make their turns in parallel, which are then consolidated into a new game state once all players have "turned in" their moves.
A good model game for this would be Rock, Paper, Scissors: both players secretly decide on their move ("rock", or "paper", or "scissors"). The order in which those are then submitted to the server is arbitrary; i.e. no player should ever get a "not your turn"-type error when they try to submit a move in an ongoing round. Once they both turned in their moves, all player choices are revealed, and the winner of the current round is determined/declared.
The question is: is it possible at all to use the GameCenter infrastructure for this kind of game, either by design or by work-around? And if so, what would be considered a good approach?
It is not possible to implement this with Game Center the way you suggested, but you can take an approach that will look as if you did manage to do this.
When you start a turn-based match, it's always the local player's turn. Either Game Center provides you with a blank match, or you will receive a match in which someone else already took their turn. There is no way to control this, so you need to be prepared for both.
The approach you can take is to have a player always take their turn before you show them anyone else's move. Only then do you check if in your local case, everyone has now taken their turn and you show the result. This will provide the illusion of what you are asking for. In the case of Rock-Paper-Scissors you can now decide the match outcome. The other player will be notified.
However, if not everyone has taken their turn in this round, don't show anything, update the game state as well, but tell the user you're now waiting for others to take their turn. You will be able to show the result when you are notified that it's your turn again, with a game state already indicating the outcome.

Do there any dev who wrote iPhone wifi/bluetooth multiplay before?

do there any dev who wrote iPhone wifi/bluetooth multiplay before?
Recently, I'm trying to make my latest game Doodle Kart to have mulityplay via bluetooth. But I found that there are hugh data need to share between the 2 devices.
-your car's position and direction
-your car's status(it is in normal state, it is hitting by bullet, it is falling into to hole....)
-CUP car's position, dicretion, and their status
-items position and status (pencil, bullet...)
I'm thinking about one device calculate all the things, and the other device just wait and receive the data to display on the screen. Does it make sense?
Hey, I should ask you the most important question first: Do you think it's possible to make bluetooth multiplay work on my game? It's just too much data need to share between the device.
Usually Multiplayer Games just share "events", like:
Player begins to turn left/right.
Player begins to accelerate.
Player shoots from x/y/z to direction x/y/z.
Item spawns at x/y/z.
Player aquires item.
The other parts just calculate the rest themselves as if everything would happen for them.
This reduces the data needed to transmit but requires periodic "full updates" that sync the game state again (i.e. every 10 seconds).
In short:
Transfer actions, not data.