Collaborative project, brainstorming.

[anth]

Here's an idea I had in the past but I never started it up:
- Make a gametype where players can level up in some way.
Levels will only provide sidegrades and not direct advantages (let's say, items to start with 150 HP but weapons doing only 80%-90% of the damage, balanced stuff like that).

Agreed, that is THE feature that makes a lot of other shooters fun to play.

And the gametype would support both to have a local database (UScript based)

Even a very basic database system would be VERY hard to make using pure uscript (unless you completely ignore the performance impact of interacting with the DB)

As for cheating, it should be dealt with from the server rather than from the client. Anyone can tell if someone is blatantly cheating thus the same behavior can be detected from a server-side mod.

That has been tried many many times before. The only thing you could _TRY_ to detect on the server side are aimbots and even that would be a terrible idea. You could write a mod that detects impossible changes in viewrotation, but then again, what is impossible? The server doesn't know anything about your clientside configuration. It doesn't know your fov, mouse sensitivity, axis speed, mouse resolution and more importantly, it doesn't know you. The best you could achieve using such a mod is to train the server to get to know you. The server could analyze and keep track of your past behavior so it could raise an alarm when there are sudden changes in your behavior. And even that would require vast amounts of processing power (which is always a problem since all uscript code runs in the server's only thread) and storage space. Most other types of cheats (triggerbots, radars, wallhacks, ...) cannot be "detected" on the server side because the server lacks the necessary information.

One thing that the server could do a better job at is speedhack detection. Speedhack detection is however built into the game by default but the game does allow deviations from the "normal" speed in order to offer a smooth gameplay experience to everyone, including players with low bandwidth and/or high packetloss. These days, now that nearly everyone has broadband and ok'ish connections, the game could be a bit stricter in this regard.

But it should also have a client-side one just to reinforce any server-side findings.

UTPure does a great deal of setting reinforcements. I do agree that (temporarily) enforcing settings is a good idea to prevent players from getting an unfair edge.

Furthermore, a hack is as possible as the server allows it to be. Good server-side based architecture avoids the vast majority of hacks completely

Even in the ideal scenario where every server and client has infinite processing power and bandwidth and NO latency, this is not true. In the ideal scenario, you could run the entire game server-side and only collect input from the client. This is the hardcore version of what is now known as streaming a game. Unfortunately, the ideal scenario is not possible. Nowadays there are servers with sufficient processing power to render everything serverside and most servers AND clients have sufficient bandwidth to pull this off. But even then, you still have to deal with the fact that there will be latency on your input processing, which is simply not acceptable (even 1ms of mouse lag is noticable to nearly everyone).

I do agree that good design can go a long way in avoiding hacks but UT IS in fact fairly well designed in this respect. The game DOES not send anything to clients that they do not need (the main thing that comes to mind here is player positions). Player positions are only sent to you when you are SO near that you can hear them OR when they are in your line of sight. And obviously, the game needs to be slightly conservative here. It does send a slight bit of extra information as to avoid weird effects for players with high latency. If the native source were available, you could eliminate the need the send player positions for players that are near to you but not visible. This requires a bit of extra processing power and server side logic but it would eliminate wallhacks. Besides this, there is very little you can do on the server side to make cheating harder.

[JackGriffin]

Super interesting post, I've read it several times now. Coming from anyone else I'd argue a couple of points but instead I suppose I'll have to change my position then

One thing I might bring up is the comment

Even a very basic database system would be VERY hard to make using pure uscript (unless you completely ignore the performance impact of interacting with the DB)

because (please forgive the reference) Dane's Universal Soldiers mod used *extensive* UScript databases and it ran smoothly because the checks were properly placed. US was the sort of game that's been brought up in this thread as appealing as it had it's own leveling system, weapons, player classes, etc. and it ran very well on server. The only noticeable lag was at game end when all the DB's were sorted. This was necessary though but didn't impact the game experience.

The response here is amazing BTW. Higor, I hope you get something going here because you certainly have interest that's only going to grow. What do you guys think of a gametype similar to Wildcard's Gauntlet? It's got a dash of Invasion, some Survival mixed in, you could easily code a bunch of level-specific awards as well as player classes (I'm thinking RPG lite here). It would be twitchy and fast-paced, you could use arrays of weapon mods depending on the server you wanted to run, and cheating would be as attractive as it is in all the team-vs-monsters games. The added bonus is you could use almost any map that's pathed.

[Feralidragon]

Here's an idea I had in the past but I never started it up:
- Make a gametype where players can level up in some way.
Levels will only provide sidegrades and not direct advantages (let's say, items to start with 150 HP but weapons doing only 80%-90% of the damage, balanced stuff like that).

Agreed, that is THE feature that makes a lot of other shooters fun to play.

Yeah. The thing with leveling, is that to do so people have to invest time and by the end of it they expect a feeling of achievement. Many players do not leave their games exactly because of the already invested time and since they can still draw fun from it (me included in that regard relative another game).
Furthermore, high level players are always more trusted than low levels when it comes to cheating. If the level up is long enough, a legit player will hardly start cheating.
It's possible of course a cheater going all the way up in leveling, but then we can just ban the account, and it's fairly effective.

And the gametype would support both to have a local database (UScript based)

Even a very basic database system would be VERY hard to make using pure uscript (unless you completely ignore the performance impact of interacting with the DB)

Depends on the kind of DB. Relational databases are rather easy to pull off if we consider the following from the start:
- the kind of queries
- complexity of the schema
- values grouping and sharding
- indexing
- the size it may get

If kept simple, an UScript based DB can be pulled off to just store accounts, levels and a few other relational things. I did something similar with my mod.
Anything more complex than this has to be stored in an actual real DB system, like PostgreSQL (my personal favorite).

As for cheating, it should be dealt with from the server rather than from the client. Anyone can tell if someone is blatantly cheating thus the same behavior can be detected from a server-side mod.

That has been tried many many times before. The only thing you could _TRY_ to detect on the server side are aimbots and even that would be a terrible idea. You could write a mod that detects impossible changes in viewrotation, but then again, what is impossible? The server doesn't know anything about your clientside configuration. It doesn't know your fov, mouse sensitivity, axis speed, mouse resolution and more importantly, it doesn't know you. The best you could achieve using such a mod is to train the server to get to know you. The server could analyze and keep track of your past behavior so it could raise an alarm when there are sudden changes in your behavior. And even that would require vast amounts of processing power (which is always a problem since all uscript code runs in the server's only thread) and storage space. Most other types of cheats (triggerbots, radars, wallhacks, ...) cannot be "detected" on the server side because the server lacks the necessary information.

One thing that the server could do a better job at is speedhack detection. Speedhack detection is however built into the game by default but the game does allow deviations from the "normal" speed in order to offer a smooth gameplay experience to everyone, including players with low bandwidth and/or high packetloss. These days, now that nearly everyone has broadband and ok'ish connections, the game could be a bit stricter in this regard.

Furthermore one could code a bot to act like a human... I am not saying it's easy. For instance, you rarely can catch closet cheaters for instance, how much do you bet that some of the high names in the player base are in fact closet cheaters?
But at least for the blantant behavior a server-side one can be implemented, for the ones the client-side anti-cheats do not get caught using their means, since they don't evaluate behavior.
I say this because I play BLR, and players are only as unhappy as their suspicion if someone is cheating, and truth of the matter is that one can be cheating, but if he does it quietly everyone keeps up the fun. However a blatant cheater ruins an entire game.
How many players caught by ACE were actually making the game "unfun" for everyone else? Most of the time, players have no idea that cheaters are getting booted and keep playing, hell, many cheaters even keep a low K/D ratio just to pass along unnoticed lol

Even not knowing the player, I think we all agree that there are impossible human feats: keep snapping 90~180º over and over for kills, hitting the same point relative the player collision, etc, etc.
Of course, there's no 100% effective way to avoid cheating, but we can make it at least tolerable enough for one to keep playing a game (that's how CoD and many other games go). As a FPS gamer myself, I mind more a guy snapping all over and killing everyone rather than a guy that keeps a low profile and doesn't kill much for example, it's mostly a matter of ruining an entire game or not, as after all we play games for fun, and people are only as picky as they are suspicious of things.

Furthermore, a hack is as possible as the server allows it to be. Good server-side based architecture avoids the vast majority of hacks completely

Even in the ideal scenario where every server and client has infinite processing power and bandwidth and NO latency, this is not true. In the ideal scenario, you could run the entire game server-side and only collect input from the client. This is the hardcore version of what is now known as streaming a game. Unfortunately, the ideal scenario is not possible. Nowadays there are servers with sufficient processing power to render everything serverside and most servers AND clients have sufficient bandwidth to pull this off. But even then, you still have to deal with the fact that there will be latency on your input processing, which is simply not acceptable (even 1ms of mouse lag is noticable to nearly everyone).

I do agree that good design can go a long way in avoiding hacks but UT IS in fact fairly well designed in this respect. The game DOES not send anything to clients that they do not need (the main thing that comes to mind here is player positions). Player positions are only sent to you when you are SO near that you can hear them OR when they are in your line of sight. And obviously, the game needs to be slightly conservative here. It does send a slight bit of extra information as to avoid weird effects for players with high latency. If the native source were available, you could eliminate the need the send player positions for players that are near to you but not visible. This requires a bit of extra processing power and server side logic but it would eliminate wallhacks. Besides this, there is very little you can do on the server side to make cheating harder.

Notice how I used "vast majority" and not "all".
Also, I was not referring to aimbots and trigger bots (or even macros for that matter which can be directly built into the freaking mouse lol). Those are the ones that must be actively worked over.
I was mostly referring to stuff like damage changes, recoil and accuracy pattern hacks or even wallhacks and radars, since they are only possible because the server is projecting info in their positions or accepting them blindly, hence I saying that an exploit is as possible as you allow it to be. Aimbots are possible because you receive the mouse input from the player for instance, it's an exploit that is allowed by the server by its inherent interactive nature.
I only talked about this because of the annoying high number of mods and games around where developers simply did not care or did not gave a damn to, and you often find obvious exploits in their stuff simply due to bad architecture.

Practical example: again in BLR: afaik, the recoil and accuracy are controlled from the client-side of the network because they are random. Result: recoil and accuracy hacks are possible, by nullifying them completely and having a freaking laser instead of a SMG.
Solution: the recoil and accuracy are pre-determined by the server and sent to the client. -> good server-side based design and would avoid such hack completely
For instance, this is exactly what I do in my own ZP system, to avoid such hacks, whereas the same kind of hack will simply trigger the shot to be either ignored or be normally shot as without ZP and with the current server accuracy.

These are the kind of things I meant as far as good server-side architecture goes.

[anth]

Furthermore one could code a bot to act like a human... I am not saying it's easy.

In UT there are plenty of bots that emulate human behavior. The most popular ones have been doing it since before they went native. CSHP did in fact make a decent effort to spot inhuman behavior such as 180° turn-kills.

For instance, you rarely can catch closet cheaters for instance, how much do you bet that some of the high names in the player base are in fact closet cheaters?

There used to be quite a few of them I'm guessing.

How many players caught by ACE were actually making the game "unfun" for everyone else?

I have no idea. The primary goal of ACE is to make sure that everyone plays with the same untampered game. There are many things that can trigger a tampering check however and cheating is just one of them. We can argue about how well ACE achieves this goal but I wouldn't say that there's something wrong with the thought.

Even not knowing the player, I think we all agree that there are impossible human feats: keep snapping 90~180º over and over for kills

Even in 1999 there were players who could do this over and over again without using any external "help".

hitting the same point relative the player collision, etc, etc.

That wouldn't be detectable server side. Just because you're always aiming at the same relative point doesn't mean you'll hit the same relative point. Unless you're playing zeroping which I've always thought of as flawed by design. And even then, you can _easily_ adapt a cheat to behave more human-like in this respect.

I was mostly referring to stuff like damage changes, recoil and accuracy pattern hacks or even wallhacks and radars, since they are only possible because the server is projecting info in their positions or accepting them blindly, hence I saying that an exploit is as possible as you allow it to be. Aimbots are possible because you receive the mouse input from the player for instance, it's an exploit that is allowed by the server by its inherent interactive nature.

Damage changes? Accuracy hacks? These kinds of things can't be tampered with if you design your weapons right... none of the standard weapons can be tampered with in this way.
Recoil is another thing, due to latency there's no way to force a weapon to have recoil without making it feel unnatural. So yes, this is a client-side effect/animation/... whatever and can easily be tampered with. But then again, UTPure could (and does) prevent tampering with these things using pure uscript.

I only talked about this because of the annoying high number of mods and games around where developers simply did not care or did not gave a damn to, and you often find obvious exploits in their stuff simply due to bad architecture.

Agreed and once again, the prime example here is zeroping.

Practical example: again in BLR: afaik, the recoil and accuracy are controlled from the client-side of the network because they are random. Result: recoil and accuracy hacks are possible, by nullifying them completely and having a freaking laser instead of a SMG.

There's no reason to control accuracy on the client side unless it's zeroping.

Solution: the recoil and accuracy are pre-determined by the server and sent to the client. -> good server-side based design and would avoid such hack completely

Again, latency is a huge issue here. Even at low pings it'd be VERY easy to make this feel unnatural.

[Feralidragon]

How many players caught by ACE were actually making the game "unfun" for everyone else?

I have no idea. The primary goal of ACE is to make sure that everyone plays with the same untampered game. There are many things that can trigger a tampering check however and cheating is just one of them. We can argue about how well ACE achieves this goal but I wouldn't say that there's something wrong with the thought.

It was meant as a rhetorical question... the point I was trying to make is that cheaters are caught in a daily basis, but most players don't even notice them. This is something that happens in every FPS game I have ever played with an anti-cheat.
But anyway, I am not saying that ACE is either doing it right or wrong. Personally, I think what ACE does is great, and yes, I do know that it checks for calls that should not occur in the client (my mod is affected by it for instance to due to some client-side effects which modify with the player view rotation, FOV and such).

Even not knowing the player, I think we all agree that there are impossible human feats: keep snapping 90~180º over and over for kills

Even in 1999 there were players who could do this over and over again without using any external "help".

I don't think we're talking about the same snapping here. I also snap here and there for headshots, but they are short snaps while rotating, sometimes lucky ones. Anything in the range of "not in FOV" is unlikely, and downright impossible if done too many times (you can't possibly aim at something you don't know it's there...).
Did you actually see those players next to you playing the game like that? Or is that from online players you considered legit?
I ask this because I can't count the number or players that tried to make a live stream of their game to prove they didn't cheat, only to be used as evidence of otherwise later on as some of the shots were mechanical snaps.

hitting the same point relative the player collision, etc, etc.

That wouldn't be detectable server side. Just because you're always aiming at the same relative point doesn't mean you'll hit the same relative point. Unless you're playing zeroping which I've always thought of as flawed by design. And even then, you can _easily_ adapt a cheat to behave more human-like in this respect.

Depends, I don't mean the same precise point, even the nature of replication and compression of data affects this. I meant a small area, as again blatant game ruining hacking is what I am mostly worried about. Is all I am referring about, not the ones in the "legit or hack" error margin.
Any cheat that emulates human behavior is hard to catch, if not sometimes impossible by their behavior alone. But then again, there's nothing besides client-side anti-cheats that can catch these and players don't notice and keep having fun nonetheless.

I was mostly referring to stuff like damage changes, recoil and accuracy pattern hacks or even wallhacks and radars, since they are only possible because the server is projecting info in their positions or accepting them blindly, hence I saying that an exploit is as possible as you allow it to be. Aimbots are possible because you receive the mouse input from the player for instance, it's an exploit that is allowed by the server by its inherent interactive nature.

Damage changes? Accuracy hacks? These kinds of things can't be tampered with if you design your weapons right... none of the standard weapons can be tampered with in this way.
Recoil is another thing, due to latency there's no way to force a weapon to have recoil without making it feel unnatural. So yes, this is a client-side effect/animation/... whatever and can easily be tampered with. But then again, UTPure could (and does) prevent tampering with these things using pure uscript.

I only talked about this because of the annoying high number of mods and games around where developers simply did not care or did not gave a damn to, and you often find obvious exploits in their stuff simply due to bad architecture.

Agreed and once again, the prime example here is zeroping.

Practical example: again in BLR: afaik, the recoil and accuracy are controlled from the client-side of the network because they are random. Result: recoil and accuracy hacks are possible, by nullifying them completely and having a freaking laser instead of a SMG.

There's no reason to control accuracy on the client side unless it's zeroping.

Solution: the recoil and accuracy are pre-determined by the server and sent to the client. -> good server-side based design and would avoid such hack completely

Again, latency is a huge issue here. Even at low pings it'd be VERY easy to make this feel unnatural.

Doesn't make sense, does it? That's exactly my point. I am not referring to UT alone, mind you, but to all games in general.
Game developers often open the exploits themselves to make their stuff the easy and straightfoward way.
There's a reason why you would want recoil and accuracy from the client with lag compensation rather than ZP:
effects, it's as simple as this, effects and nothing more.

Once you hit the fire button, you want to see your weapon fire immediately and effects must be accurate, so the reason why BLR may have done this is just that.
Calculating the recoil by affecting the view rotation, and the accuracy from the client ensures that the client-side effects are consistent in his end, then you send this info over to the server and it does the rest.
Why they would do this? Because it's faster and easier to implement, plain and simple.
Problem? Huge exploit.
Solution? Pre-calculate a list of recoil/accuracy pattern, send to the client and let him loop over a pseudo-random list so effects are as consistent as possible, and do the actual validation from the server.

Do you understand now what I am trying to get at? It doesn't make sense to me and it doesn't to you either, but this is what mod and game developers do.
They focus the gameplay and shuffle the whole security concept aside.

Latency is not a problem if you tell the client *what* he must do and *when*. Latency is just a slightly variable delay, nothing more and nothing less.
This is the main point I am trying to make with making things secure from the server: doing things the right way from the start security wise. There are always going to be one exploit or another, but they will be reduced to a narrow list that can be better tackled later on rather than relying in external tools completely all the time for everything (wasting said hardware resources such as processing as you pointed out earlier).

So to be perfectly clear: I am not trying to argue that you can catch all the cheats in the world with the server, what I mean is that architecture is downright the most important thing, following by detecting what's blatant and ruining from the server, and then by last the additional client-side anti-cheats stuff to make cheating harder at all.

[Higor]

Let's stay on topic ok?

And anth, I need to have a word with you later. (Regarding movement-bots, and how to kill them off for good) (and regarding a bug in ACE)


EDIT 2:
Weapons with aim error?
Easy, don't give the client control.
Give the client a random seed, when selecting the weapon and update it when player stops shooting.
That random seed will make the 'simulated' shots work exactly the same as on the server, END OF STORY.

(Seven Kingdoms II and many other games employ random seeds for random events, and games don't desync)

[Feralidragon]

Let's stay on topic ok?

I must say that although a bit of the discussion went a bit offtopic (sorry about that), the rest and the point I was trying to make belongs to "methodology" and "security", and thus is pretty much on topic.
I kinda started this up to whoever joins this to consider to build code properly with security already in mind rather than postpone it or even forget about it, specially if you're going to build gametypes, HUDs and whatnot.
I know you know this, but if this is a collaborative project, whoever joins should know this kind of stuff from the very start.
But anyway, you started the topic, so manage it as you deem best, I am not going to add anything more.

Weapons with aim error?
Easy, don't give the client control.
Give the client a random seed, when selecting the weapon and update it when player stops shooting.
That random seed will make the 'simulated' shots work exactly the same as on the server, END OF STORY.

(Seven Kingdoms II and many other games employ random seeds for random events, and games don't desync)

It's not any different from pre-calculating the actual values and send the array so the client can loop over them, as some games don't offer the possibility to control the seed, and UT happens to be one of them (unless you go native obviously), and I am not sure about UDK either (in which said game was made on). But yeah, if a random seed is available, is preferable, I give you that one.
However, it's not that easy, games can actually desync: tickrate, lags, packet loss, etc. Depending on the architecture, tickrate may or not be a problem, but the last one is definitely tricky, and it still happens rather often nowadays, specially during busy games.
Furthermore you cannot compare RPG and RTS games against a FPS, the gaming speed and network activity are on far different levels. Some game publishers learned that one the hard way.

[Wises]

How about Radar / wall hacks blocks?

Is this done server-side.. in which case the players positions are only sent to other players. If they can be physically seen at that point of time in the map?..

Rather then sending player vector positions constantly to all players . . Somehow check for player visibility prior to sending co-ordinates?

Also theres sound factors of course.

Idk.

[Cronoloop]

Just wanted to know: is there hope for this Betrayl game mode to be released or what happened to this project? Maybe there's another thread I'm missing?

[Higor]

I'm way too lazy to make a decent HUD for it, and I'm trying to finish this public build for Siege...

The project link is here:
https://www.dropbox.com/sh/2z95r9klaoqva83/MTd__wdXHz
I shouldn't host or redirect it, while the game mechanics is nearly finished it still needs a whole lot of interface additions but it's a nice experience to play among friends and Botz (corresponding botz core not yet released)

EDIT: I assume you already know how to build these sources if you wanted to try it.

[Cronoloop]

I did it once, but now I forgot.
But no worries, hopefully someday, someone, could finish it

From what I know, Betrayal need a lot of info to be displayed on the HUD, so I understand. Thank you anyway Higor, would love to play this with your botz

[Higor]

- Betrayal project now on spotlight (1st position project on my list).
(Opening thread later)

- Obfuscator now has a second actor that grabs obfuscated names in the name-table and assigns random readable strings.
This makes it possible to export readable scripts and with proper batch text replace on exported UC's, a project can be fully decompiled.
Yes, told ya I was gonna make that code do somewhat the opposite