Watching other games (specially D3 on consoles) I’ve seen that some processes are easily “hackable” through the gap between an action (E.G. Item Gabling) and the way/time the game saves such action to the savegame where the player progress is registered.
Of course this can be effect from console limitations (dunno) so if something goes wrong a simple quit to dashboard can save you from a bad gambling, a death, etc…
But on PC, well, we have at least 4 proc threads to spread game systems and I thought on implement a “constant” save file system, that will be registering all important things right when they occurs ingame. Of course I don’t want to “stuck” the entire gameplay each time this savegame is occuring (until because on some situations I predict that “savegaming” will almost occur on log like speed) so “threading” sounds like a good way to make all this happen on the game background without the player get noticed.
Is this a widely used solution or there is a most professional/cheap way to achieve this?
A “constant” save system like you describe cannot exist, there will always be gaps in between file writes as the data you want to save gets treated then buffered for writing. People trying to circumvent such a system can easily block writes to the file, introducing a “gap” to kill the executable. And you would want to avoid constantly writing to the disk to begin with – this is a guaranteed TRC fail on consoles, for starters. It’s going to bog down any other I/O you do (such as loading your actual game files). Not to mention people can still savescum the good old way by making a backup of their save and restoring it if things don’t go their way.
No matter what measures you put in place, people will find ways to circumvent them. The sooner you accept this, the faster you can move on to more important things.
Unless your an online game (which if you are all important data should be on the server) there is absolutely nothing you can do to prevent cheating (as the guy basically says above). All you can do is make it difficult enough so it can’t be done “casually” (such as avoiding text readable save files)
Besides people who hack your game genuinely love doing it- just let them enjoy the game in their own way. A lot of franchises enjoy success by enabling that.
I would love it if a game kept saving progress every second.
I would then just set up an LVM snapshot every second for my file system, and have my choice of when to rewind time to with per-second precision!
As the others have said: A user who cheats in an offline game is just cheating him/herself. If they’re doing that, then that’s probably what they want to be doing, and given that they paid you for the game, presumably you want your players to enjoy themselves?
If you have any kind of mechanism that depends on not cheating the rules, then you must implement those mechanisms entirely server-side, and not trust the client with any state or state updates.
You need to be more specific about the type of game you are setting up. This does not pertain to Unreal necessarily, but just good practice.
Online anti-hack is all on the server. The only files being saved to the client are configuration based and updates. Remember, even events such as collision events need to be server-side. Ultima Online, as an example, stored collisions on the client side, which was faster. Someone discovered they could modify their map files, and remove the ‘solid walls’. Soon after, collision events were moved to the server. The downside was ‘rubber banding’ where any lag against a collision object could register with the client to late and cause the player to bounce back. It is a necessary trade-off however, as people will use any and every chance to abuse a system.
You also want to encrypt your packet system. Since fast internet is available to lots of people, you can use a more complicated encryption method.
Depending on which kind of game you are creating, there are are going to be different methods of cheating. For example, a MMORPG, probably wouldn’t deal with aim bots. Go here:
Start learning how each kind of cheat on that list works. Build a few of your own. To block cheaters, you need to understand how their tools work at a fundamental level. Don’t just download and use one for ten minutes. Start building them. Understand the logic behind the tools and WHY they are useful. You will not just be stopping people from softhacking (modifying the software) but hardhacking (exploits and memory modification) as well. Aimbots for example, are not easily detected because they don’t modify packets or edit the core files of your game. This is why a deep understanding of how the tools work are important.
Games like Robot Unicorn Attack are not necessarily online, but require a constant connection to a server. If you are making a game where cheating would reduce your risk of syphoning income using micro transactions, you need to treat it like a Client/Server setup.
This applies to any game where you plan to do micro-transactions. Dead Space 3 is an example.
I am going to first echo what the others stated above. I once obsessed with keeping my players from cheating. This is a lost cause and an enormous waste of time. It is their game, they bought it.
Now, this being said, don’t make it easy for them. A simple one-way encryption on the save file should be enough to dissuade most cheaters. Personally, I miss the good ol’ days of cheat codes. Those were always so much fun and added so much more play time to a game. I mean, look at Skyrim. They give you a fully functional console. Does that damage Skyrim in any way? No.
If I found any game lighting my HDD light up like Christmas, I would be uninstalling and getting a refund.
The D3 Gamble Bug simply ruins the game (or at least what the designers thought), as example most of D3 is about get “a set”, IF you can gamble for it infinitelly…
I don’t have trouble on accept that a player will “cheat himself” offline, but it’s kinda hard planning any good evolution/endgame experience taking into account that a player could simply max himself out through cheating.
Any way, thanks by the advice, I’ll try to think on some mid term solution.