Weekly Update #68

#1

Hey everyone it’s time for your weekly update. On the coding side the last week has been pretty productive. Flavien made a good amount of progress on merging the rest of the game with the new networking code. At this point most of the game has been ported except for planets – which is obviously a rather important omission. The reason planets haven’t ported yet is because one last big technical challenge remains.

In-editor materials for a station pylon

Previously, before Flavien embarked on rewriting our networking code, all of the collision detection was done on the client. This was pretty straightforward because a player can only ever be near a single planet at any given moment in time so the game only generates geometry for planetary terrain patches that are visible. Unfortunately, as is customary to prevent cheating, we had to move all collision detection to the server during a multiplayer game. The problem is that the server must handle many players, we want to support hundreds, who are all traveling extremely fast around any number of planets. This means the server must constantly regenerate highly detailed geometry for the surfaces of multiple planets just in case something happens to run into it. It gets even worse once you add bullets into the mix.

In-editor materials for a station strut

Unfortunately, before we can finish merging the new networking code and release the next patch we need to resolve this last problem. We have several ideas for how we can address it however it’s going to be tricky and will take some time. Aside from that a good amount of progress has also been made on the new UI. Getting the path rendering code production ready is nearly complete and, assuming all goes well with benchmarking, work will finally begin soon on text rendering.

In-editor materials for a station hex tower

Lastly the art team is still hard at work on the destroyer, land base, and station materials. Kristian took some time to create a new pre-rendered video of the land base command center alongside the NPC hauler which we hope you’ll enjoy. That’s all for this week, until next time!

In-editor materials for all 3 station pieces

18 Likes
Weekly Update #71
#2

Cool cool. Especially the Art. Stations look a lot less flat now with the brown/dark orange accents.

@inovaekeith why does hit detection block the new networking system from being merged? Is it so closely intertwined with the rest of the networking?


I think I and many others have posted some ideas concerning hit detection in the past, you probably came up with these already but eh, need to post something from time to time. One or a combination of following could work:

  • Client Player Hit/Collision detection
  • Distributed Client Other Player Hit/Collision detection
  • Low Quality Server Hit/Collision Detection
  • Low Quantity Server Hit/Collision Detection

And yes. If nobody is near another player I also don’t see another way other than have the server generate sanity checks and thus terrain. Unless you don’t care … I mean how far does one need to be from another player to be able to warp trough a planet, or hide bellow the surface?

I think the least resource intensive would be to leave Hit and Collision Detection at the client and do sanity checks. As soon as something is wrong, kick the player most probably responsible for something being wrong. Remove player instead of trying to restore sanity.
Sanity checks would only need to happen very infrequently and with quite low accuracy as they aren’t used for gameplay but just to check if someone is cheating. They could also only be made when server load was favorable. The devs have talked about a recording system. If that is running constantly, one could even go so far to let the sanity checker use data from the past when resources are available and check if they are plausible.

I think letting the client do most of the work is one key to get a higher amount of maximum players per server.

8 Likes
#3

That’s an interesting one. Sanctions would require some persistent identity for each player that they cannot easily replace. For example, a Steam account. You can have multiple, but they take time to set up. Certainly an IP address is not enough to identify players.

One nice thing about it is that it could be considered ironclad. “We’re recording the entire session and run automated review tools to identify cheating.” You’re not given a chance to be sneaky when nobody is watching. The server operators are always watching.

At that point, clients can be considered trusted and you can do all sorts of interesting things.

4 Likes
#4

We do have the benefit that permission to play Battlescape is tied to the account the game was purchased on. Unless they decide to go F2P, it should be pretty easy to block suspicious accounts from playing. So unless people want to pay loads to buy loads of different accounts to cheat on, it will keep away the main casual culprits.

Sadly, there will always be a few who try it. I don’t understand the urge.

1 Like
#5

On Discord there was some more Talk.
I pointed out that a sanity checker has a lot of benefits, like I implied it could be run in a completely separate thread and would not need to be in sync with any of the other game systems. All it needs is snapshots of the match state (one or multiple depending on the method used) that could be cached or saved.
It also would allow to implement a lot of more kinds of sanity checks. Like against speedhacks and such.

One kind of cheat is a lot harder though and many games, even CS:GO have problems to counter that. And that is stuff like Wallhacks. There a third party program just reads out the position of the enemy, circumventing game mechanics that would usually block knowledge of such position. This does not alter communication with the server or the game in any way. Just providing an unfair advantage.
So how could that be sanity checked?
One way would be to have the clients send data if they see another ship/object and have the server lower the update frequency of said object. If two players close to each other do send different “visible” states one of them probably cheats. Still, they don’t have to change the visible state to read out the position of the object out of the memory. So, right now, I don’t see a way to mitigate this tactical advantage without doing line of sight calculations on the server.

Like this examples, there are sadly a lot of different ways people can cheat and hit detection is just one part of it.

Anyway. Isn’t this all a little preemptive? We know this should be a competitive game and cheaters can totally destroy such incentive. But performance is also quite important. I would maybe more understand if you would think now about how to design the backend in order to combat aimbot and wallhack. But collision? NoClip? Really? That’s a super obvious hack and some moderation is enough to ban people that do that in competitive matches.
I don’t see how the needed resources on the server and the huge inefficiency of doing it on a cpu would stand in relation to that.

#6

I just wrote a lengthy post about all sort of clever things that could be done. Then I realized that if the game has client side recording then players can just email a recording of suspect behavior to a server for review by moderators. The moderators of my ARMA server will accept video recordings of misbehaving players, having a built-in feature to record actual game data would be a huge improvement over that.

One really nice bit about this is that recordings only impact the recording player, not the server at all. There are no issues with regulating how much server resources a given player can burn while reporting problems and so on.

If anyone is concerned about recordings being hacked, then when a recording is being made, the server is notified. The server can then record the time interval, total bytes sent, and any other statistics that it cares to keep about the recorded interval. If the recording sent by the player doesn’t match up with the server’s understanding of the recorded interval, the moderators can know that the recording was manipulated. That would increase the trust level of recordings another notch. I don’t see that being a burden on the server at all.

Then INS would need to convince Twitch to let players upload data recordings instead of video. At the time of submission, Twitch would contact the game server to verify the data recording. After that, it would allow anyone with Battlescape to replay the recording.

Until some incompatibility in data recording formats rendered them useless. Thus the beauty of video standards.

#7

The difficulty with relying on community reporting is having effective moderators to sift through claims and information. Particularly since your average player can find it difficult to tell if a person is cheating, a better player, or just lucky. Rage against other players could lead to a lot of false reports (unless it’s blatantly obvious).

I’m thinking of my experience in Battlefront. Unfortunately, it is not moderated well and cheaters are a real problem. Particularly visible-enemy hacks and the occasional damage hack. But sometimes it’s difficult to tell if they actually are cheating. People have even raged at me before when I’ve happened to kill them a couple of times in a row simply because of the paranoia.

1 Like