White House urges developers to avoid C and C++, use 'memory-safe' programming languages

[Kisai]

10 hours ago, Doobeedoo said:

I'm just here wanting good anti-cheat in games. 

Oh and proper coding so games don't run like crap.

Will never happen.

 

The entire reason anti-cheats exist is because the game client alone can't protect itself. Going all the way back to devices like the "Game Genie" for the 8-bit consoles, the vast majority of cheating is "go to memory address and overwrite value" or "go to memory address and overwrite value when this value"

 

More complex stuff is written explicitly to hack the program using trampolines. Like popular "combat log" programs either hack the memory of the game, or they insert themselves into the network code (Eg using NPCap), but they still need to get the encryption keys from the game binary, violating the license of the game. Likewise tools that edit the game assets( think wall hacks) often just replace textures or shaders of the game either before the game runs or at runtime.

 

Like some of the easiest "cheat" stuff out there requires no expertise, it simply requires one of these so called quality-of-life programs like a combat log that reads the damage being put out, and then you build the hacks off that program, exposing network and game client data you were not supposed to see at all.

 

Then you have spamming macros which are even simpler, they are just using OS's clipboard to do it. 

 

And as always, hacks are a two-way street. Whatever someone does to give themselves advantage, so can others do if you got it from someone else. That's why if you're gonna cheat at a game, you keep that to yourself. Most of these hacks get out because the person gave it to someone else (eg in their guild of the game) and it spread from there.

 

Personally, if I operated a MMO game, and someone was caught using cheat tools, i would turn the screws on them so that the game becomes intensely more difficult. Fine you want to cheat, see if you can cheat your way out of enemies with hidden armor values.

 

And that's IS, in a way how some MMORPG's have made it harder for cheaters to play. They stick harder monsters among the easy ones. Players who have leveled up significantly don't see a problem, but botters will routinely have their characters killed/despawn/teleported. This is why certain "death" effects make sense, even if they're extremely unfair. Like dropping the contents of the players inventory upon death ensures that bots can't just throw themselves endlessly at monsters, and world monsters HP regenerate when nobody is attacking them. As soon as that bot teleports, BAN.

 

Anti-cheat programs target known popular tools like auto hotkey and cheat engine. They have no idea if that program is being run on/against the game it's supposed to be protecting. Likewise, there are tools often built into keyboards and mice that do macros as well, and can be undetected if the actual keyboard or mouse is programmed and isn't coming from a macro program.

 

So the right solution there is to never trust the game client. But we keep seeing this problem because game developers use game engines that were not designed to operate that way (Eg Unity and Unreal were never designed as game clients) and instead send data to syncronize the game client with the server, instead of one-way broadcasting to the game client everything as it changes. Maybe as more people get gigabit ethernet this will change, but historically it's been this way because of bandwidth costs.

 

[StDragon]

2 hours ago, Kisai said:

Will never happen.

In theory, you could containerize the game with GPU acceleration. That should prevent anti-cheat as hacks would have to puncture kernel protected space to gain access into the container. And if this is a client/server game, the container could be stateless: meaning all changes would be stored online.

https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/gpu-acceleration

[starsmine]

33 minutes ago, StDragon said:

In theory, you could containerize the game with GPU acceleration. That should prevent anti-cheat as hacks would have to puncture kernel protected space to gain access into the container. And if this is a client/server game, the container could be stateless: meaning all changes would be stored online.

https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/gpu-acceleration

Hacks dont have to do ANY of that. 

[StDragon]

4 minutes ago, starsmine said:

Hacks dont have to do ANY of that. 

IF you wanted to cheat or grief, you could output to a KVM and let an AI bot control it. There would have to be an LLM trained for that game, but in theory someone could build it and throw the LLM game bot for anyone to download and run (assuming they have the compute resources to pull it off).

I don't think that's viable now for your average loser, but eventually with secondary GPUs and NPU hardware capabilities getting cheaper, perhaps in the not-so-distant future. It's an expensive way to go about it for sure, but theoretically doable without any "hacks" being done at the software stack in terms of exploiting code in running memory.

[starsmine]

3 minutes ago, StDragon said:

IF you wanted to cheat or grief, you could output to a KVM and let an AI bot control it. There would have to be an LLM trained for that game, but in theory someone could build it and throw the LLM game bot for anyone to download and run (assuming they have the compute resources to pull it off).

I don't think that's viable now for your average loser, but eventually with secondary GPUs and NPU hardware capabilities getting cheaper, perhaps in the not-so-distant future. It's an expensive way to go about it for sure, but theoretically doable without any "hacks" being done at the software stack in terms of exploiting code in running memory.

I mean, thats how people do it

[wanderingfool2]

5 hours ago, Kisai said:

So the right solution there is to never trust the game client. But we keep seeing this problem because game developers use game engines that were not designed to operate that way (Eg Unity and Unreal were never designed as game clients) and instead send data to syncronize the game client with the server, instead of one-way broadcasting to the game client everything as it changes. Maybe as more people get gigabit ethernet this will change, but historically it's been this way because of bandwidth costs.

Actually that is close to how the classical method of video games used to work.

 

The issue with modern games is that it's just not cost effective or they don't want to give hosting capabilities to the users.

 

The biggest cost about not trusting a client, and letting the server lets say validate is that you have to have the servers essentially doing the calculations; but that means there is a real world cost associated with it (more than just bandwidth).  It's why games stop doing it that way (also latency).

 

Unity and Unreal you can 100% do what you are talking about, I have a few friends who rebuilt a server side game like that in Unreal and it works really well and apparently was relatively easy.  The issue is it goes back to needing to host it and run the calculations for the verification of the physics (and also then you need to make sure you have things like deterministic physics etc)

[Kisai]

1 hour ago, wanderingfool2 said:

Actually that is close to how the classical method of video games used to work.

 

The issue with modern games is that it's just not cost effective or they don't want to give hosting capabilities to the users.

 

The biggest cost about not trusting a client, and letting the server lets say validate is that you have to have the servers essentially doing the calculations; but that means there is a real world cost associated with it (more than just bandwidth).  It's why games stop doing it that way (also latency).

 

Unity and Unreal you can 100% do what you are talking about, I have a few friends who rebuilt a server side game like that in Unreal and it works really well and apparently was relatively easy.  The issue is it goes back to needing to host it and run the calculations for the verification of the physics (and also then you need to make sure you have things like deterministic physics etc)

No, it isn't.

 

With Unreal, Unity, and most game engines designed for a single player experience, the entire game lives on the client end. The server has a "Copy" of the game state, but it's only working out of that state, it is unaware of inconsistency from the game client, all the checking is being done by the client end using the client's version of the data. This is why you can reverse engineer these games to create private servers. All you need is to grab the session key out of the launcher and tell it to connect somewhere else. That's another thing people do to cheat, is they save their session key from the launcher and run the game without it. This is also how MMO players accounts get taken over, because they run programs that they find online to cheat, and it's secretly passing that information back to a malicious actor. 2FA doesn't protect you here, and the server doesn't verify the ip address hasn't changed. And when you're on mobile that IP address can change frequently.

 

Session highjacking has to be married to the IP address, and when there are two computers sitting behind the same NAT, it becomes possible to have a second computer act as a proxy for the first, the server still sees only one machine. So things like wall hacks and aim proxies basically work on that principle.

 

Anyway, the point I'm getting at here, is that if game developers want to keep the hackers at bay, nothing can live on the client device. You run the launcher and all it does is relay input to a remote "game" state. The client keeps no state. There is nothing you can do on the client end to teleport, speed hack, wall hack, change the inventory items, use/consume items you don't have, steal cash shop items, by changing memory values or hacking the client on disk. Every time you launch the game, you pull down the initial 500MB or so that is the game client personalized for your device, and then the game progressively downloads other parts of the game only as you visit them. If something is especially competitive and sensitive, like PvP, then you stream that as video. That then makes number of cheaters go down to single digits, those who have two or three extra computers to run AI stuff in real time and have more money than sense.

 

You make it incredibly difficult to do various kinds of hacks by making it so that the client is personalized, unique to every player, the data it contains contains a unique signature when it communicates with the server, thus ensuring that even if you were to try and use pcap or cheat engine on it, the data is isolated to one player, and unusable by any other player. This can be as simple as shuffling the opcodes for the network packets so that overwriting data results in the connection being dropped, because it's no longer signed and the opcode table being lost, so any effort put into discovering the teleport opcodes or whatever is lost. 

 

But you don't see a lot of this because running TLS 1.3 on the network connection requires an enormous amount over overhead, and limits the devices that can run it, so that's why you end up with silly rot13-like XOR bit shuffling.

[Doobeedoo]

13 hours ago, Kisai said:

Will never happen.

 

The entire reason anti-cheats exist is because the game client alone can't protect itself. Going all the way back to devices like the "Game Genie" for the 8-bit consoles, the vast majority of cheating is "go to memory address and overwrite value" or "go to memory address and overwrite value when this value"

 

More complex stuff is written explicitly to hack the program using trampolines. Like popular "combat log" programs either hack the memory of the game, or they insert themselves into the network code (Eg using NPCap), but they still need to get the encryption keys from the game binary, violating the license of the game. Likewise tools that edit the game assets( think wall hacks) often just replace textures or shaders of the game either before the game runs or at runtime.

 

Like some of the easiest "cheat" stuff out there requires no expertise, it simply requires one of these so called quality-of-life programs like a combat log that reads the damage being put out, and then you build the hacks off that program, exposing network and game client data you were not supposed to see at all.

 

Then you have spamming macros which are even simpler, they are just using OS's clipboard to do it. 

 

And as always, hacks are a two-way street. Whatever someone does to give themselves advantage, so can others do if you got it from someone else. That's why if you're gonna cheat at a game, you keep that to yourself. Most of these hacks get out because the person gave it to someone else (eg in their guild of the game) and it spread from there.

 

Personally, if I operated a MMO game, and someone was caught using cheat tools, i would turn the screws on them so that the game becomes intensely more difficult. Fine you want to cheat, see if you can cheat your way out of enemies with hidden armor values.

 

And that's IS, in a way how some MMORPG's have made it harder for cheaters to play. They stick harder monsters among the easy ones. Players who have leveled up significantly don't see a problem, but botters will routinely have their characters killed/despawn/teleported. This is why certain "death" effects make sense, even if they're extremely unfair. Like dropping the contents of the players inventory upon death ensures that bots can't just throw themselves endlessly at monsters, and world monsters HP regenerate when nobody is attacking them. As soon as that bot teleports, BAN.

 

Anti-cheat programs target known popular tools like auto hotkey and cheat engine. They have no idea if that program is being run on/against the game it's supposed to be protecting. Likewise, there are tools often built into keyboards and mice that do macros as well, and can be undetected if the actual keyboard or mouse is programmed and isn't coming from a macro program.

 

So the right solution there is to never trust the game client. But we keep seeing this problem because game developers use game engines that were not designed to operate that way (Eg Unity and Unreal were never designed as game clients) and instead send data to syncronize the game client with the server, instead of one-way broadcasting to the game client everything as it changes. Maybe as more people get gigabit ethernet this will change, but historically it's been this way because of bandwidth costs.

 

I just meant it that big companies for esports game should put more effort into developing better AC though. As we've seen even kernel-level one is not a silver bullet but just invasive piece of software. At least get good enough AC that can caught anything up to DMA cheats. 

 

For example the "combat log" in WoW combat log api gives a ton of game info for addons that use it to work. Especially combat addons. These are allowed of course, but certain combat addons like WeakAuras basically can do anything you can think of in terms of combat and automation. Which in a way is another heated game discussion, thus it's kinda stupid as addon plays for you really and makes it mandatory to use in the end, which is dumb, as in a way game is designed around it.

This is a topic that is tough by Blizzard words, as if they would ban such combat addons it would break a ton of addons relaying on api access for different uses.

Now, some certain info that was too much, they have limited separately and removed from combat log so it's not visible anymore. 

But yeah, this is an MMO and with addon support. I was mainly talking about online fps games that can be more locked down in terms of third party stuff.

 

On the macro side in WoW yeah, that also can be iffy, some macros just broke gameplay, acted as interrupt bots, or quick 1-2 executions and such. Luckily they limited such actions and some straight up don't work anymore. But new things as game evolves get discovered so once it gets abused and gets attention it gets fixed.

 

I get cheats and AC will be a cat and mouse game, but for esport games more effort needs to be put, because it's really easy as it looks to circumvent current ACs. Aside from DMA cheats which go lower then kernel level but cost a ton to set up and all, but at least a much larger barrier vs easier cheats.

 

Yes, some games punished cough cheaters with difficulty trolling, some SP games some online like self damage, but yeah, first need to properly identify them. Funny Blizzard doesn't care about bots in WoW as much, they ban a lot, but oh is it not enough and they keep popping. 

 

The mouse/keyboard macro thing, I know earlier days in Apex you could make a macro that would turn a semi auto weapon in to fully auto my executing fast macro. Or better yet two binds same execution repeatedly. That got fixed, as they limited some extra binds but also in code how fast such a weapon can ever fire.

 

The engine side though, at least for popular online games like esports ones, they don't use Unity or Unreal engine, some less known UE but whatever. It's usually old engines or newer proprietary ones. On top of using some know AC too.
I know for some games, some things are client side some server side, so not sure how that transitions into making AC for it vs making good netcode too.

[Mark Kaine]

On 2/29/2024 at 3:04 PM, Doobeedoo said:

I'm just here wanting good anti-cheat in games. 

Oh and proper coding so games don't run like crap.

i mean that last part is just not happening... 

[Kisai]

12 minutes ago, Doobeedoo said:

 

The engine side though, at least for popular online games like esports ones, they don't use Unity or Unreal engine, some less known UE but whatever. It's usually old engines or newer proprietary ones. On top of using some know AC too.
I know for some games, some things are client side some server side, so not sure how that transitions into making AC for it vs making good netcode too.

Unreal and Source/Source2/GoldSrc originate from a time of dial-up, which meant that multiplayer games only ever transmitted the player coordinates to the "host" or "server", this is why you keep seeing games based on Unreal having limited numbers of players, because the game engine still essentially operates that way. Every player has a local copy of the game and it's environment, and only transmits player coordinates to each other though the server. The server only tracks player coordinates and if players are alive, pretty much. It has no checking if the players have line of sight, obstacles present/destroyed, fall damage, etc. That is the client telling the server that happened. If the client never says it ran into a wall, then the player can pretty much wall hack through everything.

 

"Hi server, I shot player XYX, from distance 0" and suddenly that player just hits the ground like they were shot at point blank range. 
No checking. In at least one game I played this was so incredibly obvious because you'd be clear across the map and suddenly you'd be flung all the way to in front of the hacking player and die. Again, this is because the server just trusts what the client sends it. 

 

And many MMO's work that way. If a game hasn't been properly setup to disable nagle and disable delayed ACK's on both ends you can even have a situation where a player has unrealistic client-server response times below framerate (eg 16ms) where the server naively expects 200ms packet pacing. So when you play a game that has frame-rate level twitchiness it's entirely possible to "han shot first" in a situation where two or more players are in close proximity but the person with the lower 6ms latency gets the kill.

 

Memory safety won't help if the players are able to just overwrite the memory with external tools. Which is why you only really have three solutions

1. The client is dumb and only accepts broadcasts, all logic is performed on the server (Eg your button presses are transmitted verbatim to the server, the client only interpolates movement/animation on your side, the true state is still owned by the server.)

2. The client is a video receiver, to a remote session.

3. The client is virtualized inside a blackbox VM. So the player can only "send input" the to blackbox, and can't access any of it's files or memory without violating the integrity of the VM which would then just self-destruct. Disincentivizing the player from tampering with it. 

 

None of these prevent locally macro USB devices or AI from mimicking a player. It just keeps the BS "quality of life" cheats away from the script kiddies.

 

And in regards to WoW/FFXIV combat logs, these are cheats. Period. They allow the player to see information they should not be able to see, and the only way to keep that away from the player is to not transmit the data you don't want it to see it in the first place, or obfuscate the actual packet information so that players have to rewrite their cheats every time the game pushes an update. It is not a secret that combat logs are cheats and also enable more damaging cheats in the process. But these tools (WoW's communicates through an API, FFXIV's from hacking the network data with pcap) and players openly talk about parsing like everyone does it.

 

It's just straight up broken windows theory. You either over-assert control on rule violations and boot some of the most profitable players off the game, and in turn their guilds/friends/etc, or you under-assert control, and people just assume the company doesn't give a care.

 

Thor is a former employee of Blizzard and has some fun insight to this too.

 

[Doobeedoo]

23 minutes ago, Mark Kaine said:

i mean that last part is just not happening... 

Heh, sad thing really. Aside from corporate nonsense from some big companies, there is definitely a lazy coding side as well, unfortunately partially due to higherups but yeah. But, for certain esports competitive games, some less known that are also programmed really well, can run up to 1000fps and look decent too.

[Doobeedoo]

26 minutes ago, Kisai said:

Unreal and Source/Source2/GoldSrc originate from a time of dial-up, which meant that multiplayer games only ever transmitted the player coordinates to the "host" or "server", this is why you keep seeing games based on Unreal having limited numbers of players, because the game engine still essentially operates that way. Every player has a local copy of the game and it's environment, and only transmits player coordinates to each other though the server. The server only tracks player coordinates and if players are alive, pretty much. It has no checking if the players have line of sight, obstacles present/destroyed, fall damage, etc. That is the client telling the server that happened. If the client never says it ran into a wall, then the player can pretty much wall hack through everything.

 

"Hi server, I shot player XYX, from distance 0" and suddenly that player just hits the ground like they were shot at point blank range. 
No checking. In at least one game I played this was so incredibly obvious because you'd be clear across the map and suddenly you'd be flung all the way to in front of the hacking player and die. Again, this is because the server just trusts what the client sends it. 

 

And many MMO's work that way. If a game hasn't been properly setup to disable nagle and disable delayed ACK's on both ends you can even have a situation where a player has unrealistic client-server response times below framerate (eg 16ms) where the server naively expects 200ms packet pacing. So when you play a game that has frame-rate level twitchiness it's entirely possible to "han shot first" in a situation where two or more players are in close proximity but the person with the lower 6ms latency gets the kill.

 

Memory safety won't help if the players are able to just overwrite the memory with external tools. Which is why you only really have three solutions

1. The client is dumb and only accepts broadcasts, all logic is performed on the server (Eg your button presses are transmitted verbatim to the server, the client only interpolates movement/animation on your side, the true state is still owned by the server.)

2. The client is a video receiver, to a remote session.

3. The client is virtualized inside a blackbox VM. So the player can only "send input" the to blackbox, and can't access any of it's files or memory without violating the integrity of the VM which would then just self-destruct. Disincentivizing the player from tampering with it. 

 

None of these prevent locally macro USB devices or AI from mimicking a player. It just keeps the BS "quality of life" cheats away from the script kiddies.

 

And in regards to WoW/FFXIV combat logs, these are cheats. Period. They allow the player to see information they should not be able to see, and the only way to keep that away from the player is to not transmit the data you don't want it to see it in the first place, or obfuscate the actual packet information so that players have to rewrite their cheats every time the game pushes an update. It is not a secret that combat logs are cheats and also enable more damaging cheats in the process. But these tools (WoW's communicates through an API, FFXIV's from hacking the network data with pcap) and players openly talk about parsing like everyone does it.

 

It's just straight up broken windows theory. You either over-assert control on rule violations and boot some of the most profitable players off the game, and in turn their guilds/friends/etc, or you under-assert control, and people just assume the company doesn't give a care.

 

Thor is a former employee of Blizzard and has some fun insight to this too.

 

Yeah as far as fps games I've played them all, saw quite many meme hackers over time. Like the last UT alpha that got cancelled, early on it didn't have AC just report system you'd do manually and would later be viewed via replay heh.

Though still, most prevalent and harder to detect/bad is in fps games unfortunately. 

 

As for MMO like in WoW combat log is there for many reasons, addons are allowed and API access is partially limited where they see fit. Problem is, some combat addons just do way too much, yet are still allowed, because guess why, because they created mechanics around the addon for the game and pro competing guilds use the addon as the addon maker is involved in all of that. How great. Makes raiding, basically script gaming so much dumber regardless of how many mechanics or hardness of them is in the game. Wish they banned such combat addons, many do. It's bad for the game. But it's not cheating officially as it's supported.

But in this case it's just a mandatory tool to play the endgame properly. Which ok. In PvP which I'd focus as far as cheating, at least in general no issues here, not like in fps games that's for sure. Aside like mentioned some macro/script in game use that has support for that, but that gets hammered if discovered disruptive.

 

And in fps games I guess maybe go with never trust client side. But that's more for game network programmer as enough of stuff there to read on.

 

But true that for WoW they don't want to full on go on bots and those people, profit over all.

[wanderingfool2]

8 hours ago, Kisai said:

No, it isn't.

 

With Unreal, Unity, and most game engines designed for a single player experience, the entire game lives on the client end. The server has a "Copy" of the game state, but it's only working out of that state, it is unaware of inconsistency from the game client, all the checking is being done by the client end using the client's version of the data. This is why you can reverse engineer these games to create private servers. All you need is to grab the session key out of the launcher and tell it to connect somewhere else. That's another thing people do to cheat, is they save their session key from the launcher and run the game without it. This is also how MMO players accounts get taken over, because they run programs that they find online to cheat, and it's secretly passing that information back to a malicious actor. 2FA doesn't protect you here, and the server doesn't verify the ip address hasn't changed. And when you're on mobile that IP address can change frequently.

First, while Unreal might have started out as an engine for a single player game it very much is a multiplayer engine these days.

 

What you are describing is how modern games effectively handle the net code.  It's cheaper to do than the old school method, which does cut down on exactly what you are saying.

 

The old school games would have a server that is actually processing all the inbound communications (key presses/actions) and running them on the physics engines and sending updates to the client (who also then runs the physics engine on the current state to effectively interpolate the motion to create more smooth motion accounting for the delay).

 

Like I said, this is how the old school method works (and the old school games would sometimes let you actually host the server as well, with the main server essentially just being a connection client).  The method actually works decently well in that any aimbots can't snap to positions on the client and the concept of lag switches doesn't work.  Again though, what I am calling the old school method was largely abandoned when the studios realized that they had to front large server costs to effectively host games.

[Mark Kaine]

1 hour ago, Doobeedoo said:

some less known that are also programmed really well, can run up to 1000fps and look decent too.

yes, there are still games that run well, but generally "runs like crap" is more a feature and marketing tactic, "look how we fixed this bug!"  Stockholm syndrome/ carot and stick tactics at full work (because sadly its working, people *will* buy the next "runs like crap" game as long the advertising and influencers tell them so)

[PocketNerd]

9 hours ago, Kisai said:

With Unreal, Unity, and most game engines designed for a single player experience

Ummm, you do know that the Unreal engine was born from Unreal Tournament, right? A MULTIPLAYER game?

[starsmine]

2 hours ago, Mark Kaine said:

yes, there are still games that run well, but generally "runs like crap" is more a feature and marketing tactic, "look how we fixed this bug!"  Stockholm syndrome/ carot and stick tactics at full work (because sadly its working, people *will* buy the next "runs like crap" game as long the advertising and influencers tell them so)

What?

I swear sometimes. No one wants their game to run like crap, its not a marketing tactic outside of very rare instances and even then its more of an oversight

New features are more expensive to run, they have not been optimized. No developer is willing to drill down on a feature for years to optimize it when they could build new features for the game instead. This isn't even a dev being bad. 

And IM usually the one who chafes first at the modern dev mentality of lack of optimization, but this is some crazy way to think that shows one has very little idea what they are talking about with software or hardware development. 

 

  

2 hours ago, PocketNerd said:

Ummm, you do know that the Unreal engine was born from Unreal Tournament, right? A MULTIPLAYER game?

Unreal is a single player game.
Unreal engine was built for Unreal

Unreal Tournament came after.

[Brooksie359]

4 hours ago, Doobeedoo said:

I just meant it that big companies for esports game should put more effort into developing better AC though. As we've seen even kernel-level one is not a silver bullet but just invasive piece of software. At least get good enough AC that can caught anything up to DMA cheats. 

 

For example the "combat log" in WoW combat log api gives a ton of game info for addons that use it to work. Especially combat addons. These are allowed of course, but certain combat addons like WeakAuras basically can do anything you can think of in terms of combat and automation. Which in a way is another heated game discussion, thus it's kinda stupid as addon plays for you really and makes it mandatory to use in the end, which is dumb, as in a way game is designed around it.

This is a topic that is tough by Blizzard words, as if they would ban such combat addons it would break a ton of addons relaying on api access for different uses.

Now, some certain info that was too much, they have limited separately and removed from combat log so it's not visible anymore. 

But yeah, this is an MMO and with addon support. I was mainly talking about online fps games that can be more locked down in terms of third party stuff.

 

On the macro side in WoW yeah, that also can be iffy, some macros just broke gameplay, acted as interrupt bots, or quick 1-2 executions and such. Luckily they limited such actions and some straight up don't work anymore. But new things as game evolves get discovered so once it gets abused and gets attention it gets fixed.

 

I get cheats and AC will be a cat and mouse game, but for esport games more effort needs to be put, because it's really easy as it looks to circumvent current ACs. Aside from DMA cheats which go lower then kernel level but cost a ton to set up and all, but at least a much larger barrier vs easier cheats.

 

Yes, some games punished cough cheaters with difficulty trolling, some SP games some online like self damage, but yeah, first need to properly identify them. Funny Blizzard doesn't care about bots in WoW as much, they ban a lot, but oh is it not enough and they keep popping. 

 

The mouse/keyboard macro thing, I know earlier days in Apex you could make a macro that would turn a semi auto weapon in to fully auto my executing fast macro. Or better yet two binds same execution repeatedly. That got fixed, as they limited some extra binds but also in code how fast such a weapon can ever fire.

 

The engine side though, at least for popular online games like esports ones, they don't use Unity or Unreal engine, some less known UE but whatever. It's usually old engines or newer proprietary ones. On top of using some know AC too.
I know for some games, some things are client side some server side, so not sure how that transitions into making AC for it vs making good netcode too.

The issue is that trying to just slap on a kernel level anticheat at the end of the game development cycle is a pretty awful solution to anticheat. Ideally you would code the game in a way that has anticheat built in like added checks built in and also not giving clients data that could be used for cheats. In know for league of legends they don't give any data on what is in the fog of war to clients until slightly before stuff becomes visible. This means at most a map hack would only give info on the very edge of the fog of war which makes it mostly useless. Compare that to starcraft which stored the whole distribution of enemy units on the entire map making map hacks basically let you know where everything is. Granted for it to be really good you would want a good red team that have intimate knowledge on game hacks so they could figure out issues and ways to avoid or mitigate them during the making of the game. Granted that likely costs more than simply slapping kernel level anticheat and call it a day so it is understandable why companies don't do that often. 

[wanderingfool2]

1 hour ago, starsmine said:

What?

I swear sometimes. No one wants their game to run like crap, its not a marketing tactic outside of very rare instances and even then its more of an oversight

New features are more expensive to run, they have not been optimized. No developer is willing to drill down on a feature for years to optimize it when they could build new features for the game instead. This isn't even a dev being bad. 

And IM usually the one who chafes first at the modern dev mentality of lack of optimization, but this is some crazy way to think that shows one has very little idea what they are talking about with software or hardware development. 

Could depend on what he was trying to get at.

 

While not really marketed, there is a large push to get a game out the door (and fix it in post essentially).  This often can lead to optimizations/proper testing to not be done so they effectively have done things that make the game run slower with the intent that it gets out the door quicker.  What was it, I think one NVIDIA employee once said that some of the AAA titles coming out weren't even calling the critical functions in the correct order (and it effectively was up to the NVIDIA driver patches to fix the issue).

 

Actually to bring back to the topic abit, this also is how some of the vulnerabilities from C/C++ can be introduced...rushing the developers to hit an artificially short timeline because it looks better, and then just fixing the bugs after the fact [and to some extent it allows for additional service contracts etc].  Rushed timelines leading to oversights in code development.

 

1 hour ago, starsmine said:

Unreal is a single player game.
Unreal engine was built for Unreal

Unreal Tournament came after.

I got to sit in at a lecture once with the Scimitar engine developer.  One of the take-aways was that game engines, while they might be developed to handle tech for one game aren't truly designed for a singular game.  They are developed for a set of games/ideas.

 

By looking at the history of UE, it seemed like the concept of adding network capabilities happened early on during the development.  So while yes, Unreal was a single player game that doesn't mean Unreal Engine was built to accommodate single player...in fact it seems as though the development process always had the goal of adding networking capabilities.

 

Anyways, that is also a moot point, because by the time future generations of UE came out it was clear it would capable of online games as well so it would have been worked into the design of the engine.

[Doobeedoo]

3 hours ago, Brooksie359 said:

The issue is that trying to just slap on a kernel level anticheat at the end of the game development cycle is a pretty awful solution to anticheat. Ideally you would code the game in a way that has anticheat built in like added checks built in and also not giving clients data that could be used for cheats. In know for league of legends they don't give any data on what is in the fog of war to clients until slightly before stuff becomes visible. This means at most a map hack would only give info on the very edge of the fog of war which makes it mostly useless. Compare that to starcraft which stored the whole distribution of enemy units on the entire map making map hacks basically let you know where everything is. Granted for it to be really good you would want a good red team that have intimate knowledge on game hacks so they could figure out issues and ways to avoid or mitigate them during the making of the game. Granted that likely costs more than simply slapping kernel level anticheat and call it a day so it is understandable why companies don't do that often. 

I mean for sure, though afaik they did that kernel level AC from the start, but it's not perfect as implied. 

Though aside from mobas in SC it's really not an issue, more like you will come across is smurfs though. But fps games primarily. those are quite the issue.

[Mark Kaine]

3 hours ago, starsmine said:

No one wants their game to run like crap

then they wouldn't use crapware like "UE" to begin with...

 

3 hours ago, starsmine said:

its not a marketing tactic

well, it is, look up Stockholm syndrome. (this is just a variation of that)

 

3 hours ago, starsmine said:

outside of very rare instances

oh, i mean, that's a welcome change, acknowledging that these predatory tactics exist at least...

 

3 hours ago, starsmine said:

even then its more of an oversight

well, i mean that's the excuse of course, but in most cases unlikely... people are addicted to updates and "long time support"...

 

i don't even blame the companies,  i would probably do the same, when people love their snakeoil, give them snakeoil... who am i to stop them!  

 

[starsmine]

26 minutes ago, Mark Kaine said:

then they wouldn't use crapware like "UE" to begin with...

 

well, it is, look up Stockholm syndrome. (this is just a variation of that)

 

oh, i mean, that's a welcome change, acknowledging that these predatory tactics exist at least...

 

well, i mean that's the excuse of course, but in most cases unlikely... people are addicted to updates and "long time support"...

 

i don't even blame the companies,  i would probably do the same, when people love their snakeoil, give them snakeoil... who am i to stop them!  

 

UE is not crapware

This is not a variation of stockholm in any way shape or form

Predatory? like outside of Crysis 2 and its misuse of tessellation where its possible to argue because they wanted it to be "but can it run crysis 2" I cant think of any examples. The game didnt sell well and it was a black eye on CryEngine and cryware even though crysis 1 was one of the best optimized games to have ever come out and cryengine is solid (if unwieldy)

The fuck are you talking about with these last two points?

[williamcll]

At least Rust is there

[leadeater]

14 hours ago, wanderingfool2 said:

I got to sit in at a lecture once with the Scimitar engine developer.  One of the take-aways was that game engines, while they might be developed to handle tech for one game aren't truly designed for a singular game.  They are developed for a set of games/ideas.

Generally I think a lot of people have misconceptions about what a game engine is and with a lot of games being very similar also using the same game engine reinforces that, erroneously. You'd think Unreal Engine for a good while there was only suitable for and dedicated to FPS games or "open world FPS like games". But really you could make a chess game with it.

 

It's a little foolish to dedicate so much resources in to making a game engine, a tool to make games, to be only suitable to make one or a few limit games. The only company I know of that did that consistently for actual decades was Squaresoft/Square Enix and they have "recently" given those endeavors up.

[hishnash]

1 minute ago, leadeater said:

It's a little foolish to dedicate so much resources in to making a game engine

It all depends on what you need, if your just making an engine to support a single game and you can scope that engine to just what you need for the game it does not need to be that large or complex and engine, and you might well end up spending more time coding tooling around the engine that help you create the game (stuff that does not run on the users machines) than the engine itself.   

if you want to create a generic engine and the tooling to help you build a generic game then that is a massive project. 

[hishnash]

15 hours ago, wanderingfool2 said:

Actually to bring back to the topic abit, this also is how some of the vulnerabilities from C/C++ can be introduced...rushing the developers to hit an artificially short timeline because it looks better, and then just fixing the bugs after the fact [and to some extent it allows for additional service contracts etc].  Rushed timelines leading to oversights in code development.

Many of the bugs I have seen in c++ code bases came from having many differnt sets of devs coming in and out on a project. C++ is such a vast langue that there is at least 5 accepted ways to do anything you might want.. so without some clean guidance once you move code base between many groups of devs it becomes a complete rates nest that is impossible to track and reason with.