Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Cheats and Open Source
#1
The Problem
As rampant as cheating may be in regular PC gaming, with Open Source gaming it's easier to use more subtle tweaks to your advantage.

The simplest method to combat cheating I can think of, is also the most intensive -- recording all of the users raw inputs and locally calculated vehicle positions, uploading that, and performing a random sampling to ensure that the input matches the outputs. That'd catch a cheater who had been tweaking engine power or gravity.

Of course, the inputs for a perfect lap could be pre-recorded. So then you need to do something like request a random seed from a trusted server, and ensuring that the physics engine which uses that seed will show enough difference in its interactions for the same lap. And that level of randomness sucks in of itself.

But then a simple algorithm could still recover from the randomness and seek the racing line. Like AI cars will do if you give them an unexpected nudge.

The only way to win a Cat and Mouse game, is not to play.


So.....?
Cheating won't even be an issue until it attracts certain number of players. So rather than go the draconian route of trying to prevent cheating through technological means, I wonder what role a healthy community can play in deterring unsporting behaviour?

In other words - just chill and accept that cheating may occur, but that there's a social stigma/cost associated with that choice?

Lazyweb - has that worked for other gaming communities?
Reply
#2
This is a very interesting subject... I think it all comes down to: don't prevent modifications, but try to catch cheating/vandalism which will affect other players (or us). And preferably be as polite as possible?

And yes, proprietary software makes it possible to prevent some level of local modifications (similar to drm in that it tries to prevent tampering, but usually quite easy to bypass), while open source makes it easy to bypassing and perfect the cheating quickly.

I do not know of any lazyweb gaming out there... But I guess the internet itself is a rather rule-less gaming network: pick the pieces you want, and just ignore the rest (the cheaters). ?

(The following relates to recagedSmile

The thing is: since recaged is free software (not just open source) not only is it possible to modify it, but it's also allowed (as well as redistributing the modifications)... In fact, with lua scripting, you could modify the car by attaching sensors to it and modify the remote control (the lua block which reads the keyboard and writes data on screen) to have an "autopilot button" (perhaps some self-learning AI code which observes the player and then tries to improve?Smile).

So, lets split this into three categories:

1) local modifications:
I see no problem here. This should be allowed and encouraged.

---
For 2 and 3 below I should clarify: I plan to some day make it possible to have an online recaged identity (on a server), which will be used to find friends online (registered as being offline/online, hosting a race, or participating in a race). It will not be required, as one can also connect to a server/host using a normal ip address, but by creating an account it will all be easier: you can host a race and it will be added to the list (if public), you can find your "friends" (and see if they are online, chat with them, invite, etc...), and connect to other people hosting games. Plus, you don't have to worry about dynamic IPs. Hopefully it will also be possible to store a copy of the local "save" (unlocked stuff, achievements, etc). So you will never loose your precious data and can sync it between systems.

Hosts (race servers) can choose to only allow people with identities if wanted. Perhaps the default... Also there should be some registration delay, so people wont be bothered to just abandon one account and get a new one for some reason.

Moving on:
---

2) multiplayer cheating:

The only reliable solution I've come up with is to stick to the host-client approach: one person will host the race. This player (the host/server) runs the simulation thread(s), while all clients only run the interface thread. All cars are provided by the host, while the clients are simply holding remote controls without being able to touch the simulation (only send/receive messages with the car they are paired with). At most, the clients could upload custom skins, but no 3D models or anything which might interfer (definitely not lua scripts!).

This way, if the host is honest, the race will be safe (assuming no security hole is found).

What if the host isn't? This is bound to happen (I even plan on messing with people on non-serious friend racesWink), so I suggest some kind of karma system for the online account (initially "0"): if people get pissed of they can (through some kind of voting system) punish a bad host. This will result in a decrease of karma.

The thing is, I don't want this to be a permanent stamp on people, so the karma will move one step back to a neutral position, 0, withing some days/weeks.

Also, a good host will have a karma of "1" (given by hosting many races, a long time and with no complaints. Note: never goes above 1. So this status is easy to loose on any annoying action or being inactive for a long time).

So when browsing the list of hosts, you can check the karma of them:
Mac (karma=0: neutral or new player)
Slinger (karma=-2: misbehaved twice last 30 days)
Frillis (karma=1: been around for some time and considered to be a good host)

All of these karmas will move back to the neutral position with time (so even a good host will return to 0 after some time of inactivity).

3) online status:
If people cheat locally, unlocks all achievements and progress and upload that to their online account. That's ok! I don't plan on any benefits for people through achievements or similar (might not even be public data, more like an online backup. But I think it'd be fun if friends can follow each others progress).

But it would be worse if someone were to upload faked lap times to some score board...

I agree on the idea of:
Quote:recording all of the users raw inputs and locally calculated vehicle positions, uploading that, and performing a random sampling to ensure that the input matches the outputs.
This is an idea I've been playing with too!

Given that ode got some randomness in the simulation, finding the error margin might be tricky (perhaps each track will have its own). Keep in mind that while this will (hopefully) ensure people are using "official" cars and tracks as well as stepsize and contact points ,they will still be able to modify other portions: slowdown the simulation, record button pressing (record during a good lap and then step-by-step replay and refine until it breaks the record).

Perhaps it'd be best to stay low with score boards initially?



Finally, I haven't mentioned vandalism, but I think it's quite obvious this must be punished "Swiftly and with style"...
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#3
I can't really complain, apart from this one thing that I wish to bring up:

Quote:The only reliable solution I've come up with is to stick to the host-client approach: one person will host the race. This player (the host/server) runs the simulation thread(s), while all clients only run the interface thread. All cars are provided by the host, while the clients are simply holding remote controls without being able to touch the simulation (only send/receive messages with the car they are paired with). At most, the clients could upload custom skins, but no 3D models or anything which might interfer (definitely not lua scripts!).

I disagree with this. However, whilst this is (provided the host is clean) probably the best way to deter cheating, the side-effect is of the problem of latency. Have any of you ever played any synchronous online games? What I mean by this is generally best described as being present in every online-enabled fighting game (Streetfighter, Tekken, Smash Bros, you name it).

Though those games aren't host-client like you suggest, they do however deliberately sync the inputs, to prevent 'desync' which could cause a lot of problems. The drawback to this, is that both players need a very good internet connection to one another (under 30ms) because otherwise what is known as 'input lag' becomes apparent. My experience with Smash Bros, for example, is that it sometimes took a whole second for button presses/combinations to show up as actual movement in-game. In a situation where you must suddenly react (for example something very suddenly gets thrown at you) you won't be able to do anything about it.

This same pretense, unfortunately, would go for ReCaged if the host controlled all simulation. The cars would be horrible to drive as their input would be 'laggy', and something like a sudden rocket-shot hitting your car or a bump upsetting it in a way you didn't expect, are going to be things you won't be able to correct.

=/

I obviously can't think of any perfect ways to prevent cheating. Trying to hash-check files/applications would work to an extent, provided there isn't any client-side way to get around it (like in GTA4, where hashchecking is managed by a text file's contents and is quite easy to circumvent). Similarly some way of checking RAM to ensure that loaded/operational game files are non-modified would be needed (as much as I fucking HATE PunkBuster, I have to agree that it does work.) A server could possibly request a hash-check of the application being used along with any relevant files (cars that would be loaded, etc) but I don't know if there are ways to fake the results sent back.


I just realised this has dragged on.

But I will reiterate my point: If ReCaged is only playable online via a host-client simulation system, I won't play it. My internet is pretty decent but even so my ping to other countries is horrendous (average 200ms to america in games, don't get me started with Australians). That would equate to almost 0.5s of input lag if the host was American. It would create unnecessary advantage/disadvantage for people with better connection to the hoster.

=/
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#4
What about this:
  • All Clients run local simulation
  • Clients send player inputs + local car position to Host at set intervals (e.g. 100ms).
  • The Host could verify (in real-time, or after the race), that the inputs match the car positions the Client reported.
  • Clients perform "best guess" collisions at set intervals, based upon latest data they've received about other cars. Cheating at this stage would be detectable by statistical anomaly.

So you'd lose a bit of accuracy, but avoid all input lag.
Reply
#5
Quote:Have any of you ever played any synchronous online games? What I mean by this is generally best described as being present in every online-enabled fighting game (Streetfighter, Tekken, Smash Bros, you name it).
... Team Fortress 2, Portal 2...Wink

They're performing some level of local simulations, but it syncs with the host/server so the input latency causes problems (I'll go into more detail below). So yes I know the problem of latency. P2 doesn't matter so much (although it's annoying with buttons being out of sync, boxes suddenly warps or the floor suddenly becomes deadly goo). The solution in tf2 is that you can grab a list of all public servers, the client will ping _all_ of them (which used to overload my router when I played it) and allow sorting by lowest ping.


And I know the original games featured a p2p multiplayer mode. But that's really only possible with simple racing games (that doesn't perform any actual simulations: rigid body dynamics, wheel slip, dynamic environment, etc).


The rest of this post will just look at the problems with the solution both of you suggest... Sorry.

First of all: each player got its own simulation, and they all sync each others and try to combine them into a single state... How should the sims be synced?

Alternative 1: one of the simulations is deemed (by all) to be the most ok verrsion, and is copied to each one.
Problem: imagine one player in the last second manage to break and steer to avoid hitting a corner of a house. After the adrenaline-filled moment, the player is happy to conclude that he/she just avoided the crash. Then the simulations of the same step is sent from the other players, and they are deemed to be better for some reason. Suddenly history gets rewritten and instead of driving the car victoriously, the player is suddenly spinning around in circles watching the other overtake. On the other hand, if this player's simulation (despite the odds) is deemed to be most ok, then some other player is bound to be crashing despite not "actually crashing". Not acceptable.

Alternative 2: only the cars are synced.
Problem: the environment is not fixed, so the simulation might look different for different people. For instance: imagine two cars running through a doorway being opened by a sensor on the ground. One of the players manage to run over the sensor with a quick maneuver and opens the door, while the other drives on the side, and they both go through the door. Simple, right? No... Because in the simulation of the other player the car which should have driven on the sensor did not run over it (because that player input wasn't received in time, because of latency). The result? For one player the door never opened, both cars slams into the door, and in the next sync suddenly the other car disappears (as if it just tunnel straight through the door). For the other player it'll seem like both cars went through the door, but in the next sync the other car will be gone (as if it slammed into the door which clearly is opened)... "Huh? Oh well, no problem... I win!".

Plus if two cars are colliding, the outcome could be different on the two players' simulations, leading to very odd results when synced (the cars might tunnel and get stuck into each other, fly away of different directions or something).

Also not acceptable.


This is similar to a classic problem in tf2: automated doors. All players got a local simulated characters to make latencies less obvious. Basically the character will seem to move directly on input, but the movements will still have to be processed by the server - once they are and the sim result is sent back, the positions of local simulated characters gets warped. This is similar to alternative 2 above. The problem gets obvious with automated doors (which are only simulated on the server): with high latency you can walk against the door and it will NOT open. A second later the door you're starring at suddenly becomes a wall on the other side of the door, or an enemy blowing you to pieces before you can even react. Basically: On the local simulation you walked up to the door, which did not open, and kept walking against it. On the server you walked towards the door, which did open, and kept walking out through it.

Let me know if I've overlooked something, but I believe there's no perfect escape from latencies. Other than, you know, avoid them in the first place.

Personally, I'd be more interested in making sure "what you see is Always what you get" and also not in any way limit the simulation (by making it more complex just to solve one problem in one situation, resulting in tracks having less flexibility). I'm fairly sure we'll all want to make some kind of Rube Golberg machine(s)....Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#6
Complex, Accurate, Responsive - Pick two.

That's the classic challenge of the artist though - dress up your limitations as design choices ;-)
Reply
#7
Yup: it's like the fact that ODE can't work with bodies with mass not being centered to the body:
ODE User Guide Wrote:But in fact this limitation has been in ODE from the start, so we can now regard it as a ``feature'' :)

But I should point out (I seem to write this about most stuff lately): networking/multiplayer will be defined in lua scripting (in rc.lua, to be precise. Using only a thin set of C functions for enabling network communication and sanitize the data). So it should technically be possible to implement a p2p solution for anyone who accepts the challenge. This is also true for "dummy simulate" each cars on each local machine, to try to hide the latency from the player (like tf2/p2).
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#8
Well generally the best way forwards for a racing game is probably the so-called "prediction" technique.

I'm not sure if I even mentioned this before or not but I'll say it anyway. Basically it uses the player's 'ping' to the server/host/whatever is controlling the actual game, and with that projects the player's car -ahead- of where the player's last known location was. It accomplishes this with the ping time (to move the car ahead a sufficient distance from its last-known position sent through data so it appears to everyone else to be in the same location that the player himself is -actually- in at that given time, and moves the car according to the last known direction of travel.

The main problem with this is of course 'teleporting' (when people have very high/erratic pings, their cars will usually wobble backwards and forwards, or suddenly 'jump' from one location to another sporadically) and that when the player turns, the 'projected' location of their car won't update for maybe 0.2-0.5 seconds which means their car will suddenly (and often impossibly) swerve round the corner to end up back where the game is 'predicting' them to be.

Like I said it's the best method and is used in practically every game (to varying degrees of success). I genuinely don't know how Rollcage and Stage II dealt with multiplayer, having never played it online. I think for the sake of maintaining a balance between playability and 'accuracy' this is the best option.

Things like buildings and movable objects are best dealt with in a combination of local and 'host' simulation. Weapons in Blur generally deal with this method; a Mine (a big orange glowing mine) placed on the track will explode immediately if the local player hits it, but if someone has a terribly high ping, to that player, this 'laggy' player might appear to initially drive round or through the mine, with it being 'updated' (in this case, collided with) when the laggy player's data is sent to the host telling it they hit the Mine. There are obviously problems with this as there always will be but again, it's probably the best idea:

Local Player drives into building support.
Building support is destroyed.
Data of building support being destroyed is sent through host in next ping data packet.
On everyone else's games, that building pillar will then be destroyed, once the relevant data is transferred to them.

This combination will likely mean that laggy players may appear to 'ghost' through pillars before they then get destroyed and the player will probably suddenly jolt back in an improbable fashion when their predicted speed/location is transferred, but it's better than having input lag. Wink


If there is another term for this particular sort of host/client simulation/transferral, please say. I'm trying to think of what's going to make the game most playable as well as keep as little load on the server/host as possible.


edit

I forgot to mention. This method always gives the other cars client-side collision against the local player, themselves and the world. This tends to mean that opponent cars online appear to have more 'weight' as if Local Player collides with Online Player 1, the data latency usually means it takes half a second or more for the location prediction to catch up. It's a trade-off. Smile
96.5%
MORE
WUB WUB.
[Image: 54f5c31d9f2ce.gif]
Reply
#9
After finally trying some online multiplaying with rollcage again (thanks Mac), I now realize the importance of making the clients slightly less connected to the host.

Obviously the clients can't just rely on updated coordinates being sent from the host unless on a LAN (what was I thinking?), so my idea right now is to just let each client have its own simulation, which gets updated by the host simulation as often as possible, but otherwise they all run their own race. For obvious reasons I'm not going to support destruction of buildings and similar lua scripted events on the client simulations (because it must all be overwritten by the host anyway to be approved as a real event). So basically:

I got some notes somewhere on the technical details (but can't find it atm), but basically:

host: full simulation
clients: minimal simulation (cars+static non-lua-driven environment for just collision detection/smooth display of demolition)

The data sent to the host from clients (their car positions) gets accepted if it doesn't seem to break what the host simulated, otherwise it's discarded. The data sent the other way (which contains updated state for the bodies, geoms, joints, etc for the environment plus car datas (notice they are dealed with as something not part of the simulation?) MUST always be accepted by the client. There's also going to be flags for how important the new car positions are, so if the host insists that This Player must be hitting a road, it will set that data (position, rotation, etc of all car parts) MANDATORY and the unfortunate player will be warped to the wall in case that wasn't already the case in that player's local simulation.

On the other hand, cars just driving on the ground will have their data flagged as NON-ESSENTIAL when sent to clients (and will probably be overwritten by the data sent from the clients). This will be ignored by clients for their own cars (but still be used to update the positions of the other cars), so they wont have to bother with teleporting all the time.


The obvious annoyance would be when you think you've rammed another car which wasn't there (or get rammed by one that you couldn't see), or run into a pillar/wall only to then suddenly have passed right through it (or the other way around).

Pros: players get zero input latency and smooth display, host retains the ability to dictate the car positions, host is the only one running lua scripts at the simulation (so no complicated disagreements can occur), plus other stuff I forgot. Probably easy to extend to other things, like players in an FPS game.
Cons: the usual problems with networked games. plus if you take down a building, expect it to remain for $PING seconds locally before actually starting to collapse (so the car can be spinning out of controll by hitting a pillar which didn't break and the next second it's suddenly back on track and the pillar is long gone).

btw: yes I know this is a late post. Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#10
On asking us to “do my essay for me online”, you’re not only placing an order for an essay solution, but you are actually investing in the best essay writing company in the United Kingdom that can help you come up with technically accurate answers for questions like “can you Do my essay?”.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)