I’m part of a team planning on making an MMO FPS and one technology we’re looking at is Unity plus Badumna. The peer to peer architecture is something to look at as it alleviates processing from the server especially on bandwidth heavy games like an online FPS.
But the security is also a big question. So here I want to create a discussion about working around the security holes inherent in a peer to peer architecture.
My idea is, you can’t prevent it, since what arrives in the server is not “may I do this” but “hey I did this”, but you can do something about it after its done.
What I’m thinking is to make the server do game logic checks to see if what the client has done was within acceptable parameters, if not, he is banned.
The game logic checks would be things such as:
were you allowed to jump that high?
were you allowed to run that fast?
did you actually still have health to move?
did you actually still have health to attack?
should you really have been able to attack that fast?
did you really have a clear line of sight to the enemy you shot?
did you still have enough ammo to make that shot?
with the weapon you used to attack, did you actually have that kind of weapon in your inventory?
Not only this but clients also actively make game logic checks against updates sent by other clients, if other clients were found to be cheating, the client votes that other client to banned by the server.
Another issue is wallhacking, where players can see through walls to see where their enemies are hiding. My idea to prevent that is: we only send object updates to clients what their character can “see”. If an object is obstructed by a wall, data about that object is not sent to the client. I don’t know though if this is possible with Unity + Badumna.
Cheats that I don’t have an idea how to fix are aimbots (automatically aim perfectly at targets) and triggerbots (automatically fire if a target is within the crosshair). If you have any suggestions, feel free to discuss them here.
I appreciate that this is an old thread, but I was thinking about these issues recently and might as well write my (long-winded) thoughts in here.
What Badunma offers is basically a reversion to ye olde style of game networking, as used in early RTS games and Doom. Clients send their data to each other, not a central server, and it is not possible to prevent cheating. Badumna offers a hybrid approach, where some data can be sent to an authoritative peer to be validated before it’s passed on to clients, just like a dedicated server. The issue is that ALL data in a multiplayer game MUST be sent through an authoritative peer if you want to prevent cheating. I don’t understand what traffic is suitable for sending in a peer-to-peer manner, so you’re getting no advantage from the features Badunma offers and the entire thing just confuses the hell out of me.
When Quake was released it used the dedicated server approach, so that cheating could be dealt with by having the server be responsible for everything, and the client was reduced to a simple terminal that sends nothing but input commands to the server. This was great, but latency was a pain in the ass. There was an obvious delay after every key press or mouse click before you saw the action take place on your client.
When Quakeworld was released, it introduced client-side prediction to give the illusion of a latency-free game. This also meant that clients were no longer “dumb terminals” and now had to worry about things like collision for their prediction, even though the server also had to calculate this stuff before updating the client with their “real” position. Your player would movedaround immediately when you hit movement keys, but the server would nudge you back into your real position every second or so to keep everything in synch (basically).
This is pretty much all you can do to try and stop people cheating if you’re going to allow peer-to-peer (non-authoritative) transfer of things like player position. You have a lot of things to worry about, not just “is the player moving at a realistic rate” but “has the player just teleported through a wall?”. I don’t think you’ll catch things like that easily, if at all, without doing something crazy like pathfinding from their last known position to their current position every time you check their position updates and seeing if it was possible to move there in the timeframe. If packets are lost or the player’s connection suddenly gains a load of latency for a few seconds, you might end up accusing them of cheating because you missed the packets and just saw a huge leap in their position. In other words, you can’t rely on this at all.
Health and other stat updates must be dealt with server-side, and not peer-to-peer. If the player has no health (as stored on the server, not their client) then they are killed server-side. Pretty much everything in your bullet point list should NOT be done through peer-to-peer, but via an authoritative server.
This is a big one. You can’t allow this type of thing to be client-side/peer-to-peer as line of sight isn’t really the issue. Maybe they can see 10 other players out in the open and have their modified client (which is stupidly easy to do with a .NET decompiler) send 10 “I shot this player” messages to other players through the peer-to-peer system. They have line of sight, so all the other players die instantly?
I suppose you’d have to send the “I am firing mah lasers!” message to the server, and it would do the raycast to see what you hit. You’d also want to roll back player positions to where they were when the shot was fired and calculate it from that, not their current positions. This can lead to people being shot 100ms after they’ve ducked into cover (see pretty much any recent FPS for examples of this), but as far as the firing player was concerned they hit you when you were visible and you should be dead. It’s a compromise.
You cannot do this. Again, it’s so easy to decompile a Unity game and modify the client that you’re just asking for abuse. You could connect with a modified client that sends out “You’re a cheat!” messages left and right for no reason. You should never, ever, trust the client or anything it sends to you or other players. You would not do this in any game, no matter what language it was written in.
You cannot prevent this (or aimbots) from happening. Big companies like Valve and Blizzard try to combat this by installing client-side anti-cheat software on your computer to look for wallhacks and stuff in memory. There is no other way to combat this, and I don’t think your idea of only sending network updates about visible objects is realistic. That would mean that a huge fight could be taking place on the other side of a door and none of it would be transmitted to the player’s client until the door was opened or they rounded a corner or something. Not only that, but you’d essentially need to render every single player’s view on the server every network frame to calculate line of sight. You’d need to take semi-transparent objects like glass into account as well, and the whole thing would just become a horrible nightmare.
Yes, loads. You can’t deal with any of them unless all your traffic is going through a dedicated, authoritative server. You also cannot trust anything that a client sends to the server, especially when it’s so trivial to decompile a Unity (or any .NET) application and modify all of the scripts, then rebuild the client. The client must be as dumb as possible, ideally just sending key presses to the server and having it work out what the result of those presses is. That works for a slow-paced game, but for an FPS you also need to have client-side prediction happening so that the player moves or shoots immediately when you press the keys, but the actual result of those actions is calculated on the server before anything actually happens. The client must be nothing more than a keyboard hooked up to the internet, with some graphics on the screen to make it look like the player has immediate control of their avatar.
As for Badumna, the idea is nice but the reality is that you can’t really take advantage of what it’s offering unless I’m missing something.
edit: Good luck making an MMO FPS. There’s a reason why very few exist, apart from heavily instanced games.
Xomg gave you a pretty comprehensive reply, but I just thought I’d weigh in on this as well - peer to peer for an MMO will only work with authoritative peers, essentially client-server, and then the servers are peer to peer. I haven’t used baduma as we have our own bespoke MMO server - btw writing your own server is always advantageous, though only if you have the time, and the engineers who know how.
For an FPS I’d recommend a gaming protocol written on top of UDP, an MMOFPS is a tall order, so good luck!
For the benefit of everyone, I thought I should clarify Badumna’s hybrid architecture and how it manages cheat prevention.
Firstly, Badumna provides complete control to the developer in deciding what is critical (and must be verified) and what is not critical (and can be sent via Badumna’s decentralized network). If an MMO requires that every single bit of information has to be verified then Badumna will function as a client-server solution. However, I believe that there are different categories of MMO applications with varying requirements. For example, quite often an MMO will have combat zones where players are likely to cheat and hence every bit of information has to be verified. However, there are also zones where players can only walk/run/dance/chat. Such zones do not require complete verification and can utilize Badumna’s decentralized network and benefit from the scalability that it can offer. In fact, Badumna 1.4 has an example that shows how to switch between a combat zone (that is arbitrated) to a non-combat zone (that utilizes the end user network).
Secondly, Badumna provides additional security features that developers can access such as identity protection (so that users cannot pretend to be someone else), complaint proxy (allowing clients to be configured to report malicious/cheating players to a trusted source), and black listing (banning malicious players from the games).
Hope this helps in understanding Badumna’s hybrid architecture and how it handle cheat prevention.
Cheers,
Unfortunately wont do much for a open world ffa pvp game =(
Someone earlier in a diff thread suggested having clients check each other to see if there calculations match… if 1 doesnt match then have it flagged… But, of course you would need clients around the player…
However for unpopulated areas you can put up “cheat detectors” which would be basically a headless client running on a box to match there code with other clients? I wonder could this work then for this type of MMO?
I have quite forgotten about this thread and only just recently checked it. I appreciate the replies.
@xomg: I am quite aware of the rule that clients cannot be trusted. No need to mention it multiple times.
I agree latency can make the server mistake you for a cheater regarding movement hacks. That one alone, I think, makes my idea of having the server check for cheaters not a good idea in that servers can mistake you for a cheater if you’re lagging.
What I meant is that the server would then ban you after you did this cheat. I will really have to let the other players die. The server can only act on your behavior after the cheat has been done. Of course, adding to that is the issue of lag. Lag is a problem. Then again, even in a traditional client/server architecture, lag is still a problem.
That is what Torque does, meaning all the games that use Torque does this, including the MMORTS, Dreamlords. My point is that this idea has been used in a production setting already.
Yes that is the idea. What exactly is wrong with that? You’re not seeing it, so you shouldn’t receive data about it. That will even alleviate your bandwidth consumption since you’re not getting network updates that much. This is similar to the simpler idea of proximity network updates wherein you only receive network updates of the players that are near you, regardless if your camera can see them or not.
Yup, that’s more or less true. Its not really rendering, but doing a sort of occlusion culling. Again, that’s what Torque does. When I used Torque, at first I was confused why the server needs data on the client’s camera settings.
Then make your server consider the transparency of objects then. Your servers will need data on the levels in the first place so that data is already present. I don’t see how that becomes a horrible nightmare. The only way I think this is a nightmare is if the person required to implement this feature does not know how to do it properly.
And yet you don’t seem to want to mention what those loads exactly are. Please, if you think there are more, discuss them.
That is a good idea, even for populated areas. Clients that do not participate in the game but actively check for cheaters. You now have clients that you can trust because you’re the one running them, or distribute them to people you can trust, provided you have people that you can trust. I guess you could even give higher priority to the decisions of those clients over normal players.
The way I understand it, Badumna’s arbitration servers behave in a traditional client/server architecture wherein the server simulates the client’s actions in his copy of the world, so that he can check if the action that the client wants to do is valid. If not, the server prevents it from happening.
What I was thinking, which now I think, is not a good idea, is for the server to check if what the client did was valid. If not, then it bans him. Or rather, have the clients do the checks and vote if a certain client is cheating. If the server receives enough votes, the server bans that client.
Still, I think it would be nice to set up such a thing in a trial run, and see if clients can find a way to cheat without getting banned.
The problem with P2P MMOs is that they’re so prone to cheating, they nearly never get past the concept phase.
If you have a central anti-cheat server enforcing anticheating rules like packet checking, bans, and blacklists, you may as well have everything centered out of a single server for tech purposes - less to keep track of, and a central authority for all game rules. I don’t doubt the P2P MMO technology is compelling, but unless you find a way to get around the issue of cheating, main server MMOing is where it’s at.
well my plan is to run thee most critical information thru arbitration/dei such as character info, exp, hit poitns, things of that nature… and then develop a method to have clients check each other…
for a open world pvp mmorpg all information is critical i understand im just saying THE MOST CRITICAL…
then i want to develop and run “trusted headless” clients as “cheat spheres” and strategically place them in my world… Not only would they help with latency issues as they would act as a trusted seed peer but, also check for cheating when people walk into the sphere it checks the client data against its own…
Also up for other methods and ideas, If anyone would like to help develop a solution with Badumna to help protect against cheating contact me via skype @ bruinp8n or email bruinp8n@yahoo.com or pm…
That’s the problem. With an MMO everything is critical. If you offload chat to the clients, folks would soon be running scams pretending to be GM’s. Look what happened when WOW decided to let clients have authority over movement. Hello Warden!
So exactly what ‘not most critical’ data are you talking about here?
Once you have an arbitration server, and multiple headless clients running as cheat spheres, you might as well just go with a standard architecture, for you have saved neither infrastructure or bandwidth. In fact you’ve made it all worse.
A peer->peer MMO might look good on paper, but once it’s in the real world one of two things will occur. You will quickly move everything to the arbitration server, or your game will be pilloried at the worst MMO ever. Omg more haxors than diablo and gunz online combined!
Position syncing between users for example isn’t critical until a critical action is performed (attack, interaction, periodical position verifications to work against speed hacks, new area found) so you can hold off doing such verifications until such actions happen for example.
Already getting rid of permanent backend force checking of the position changes means major differences as movement makes the vast majority of all packets.
Also stuff like no drop living environment NPC simulation is not critical either, even the simulation of basic grind npcs that only provide base resources, near worthless items or skill resourcables could be offloadeded.
I don’t see any problem there at least from the level of detail at which I have been trying to find the shortcoming, cause the only case it would become important that the server did it all was when you interact with the npc ie attack it and when you do that, you can do the required verifications you need to do anyway (distance, reachability, ammo, mana, …)
I might be missing something in the lightweight way I think about it though.
What concerns me more than “whats critical - what not” is the problem of the unpredictability of the user bandwidth available, their latency, the cpu power, if they allow computation offloading and alike, things that make it very unpredictable on how much power we need on the backend to keep up with the needs to fullfill the user desires.
I’ve played MMO’s where positions were handled in a similar manner to save bandwidth. The movement simulation performed on the client until there was interaction. They were very annoying.
You had difficulty finding the ‘true’ position of the mobile. You would be standing in front of it and wouldn’t be in range to attack. When you did get within range by trial and error, there was a discernible pop or mega fast lerp to it’s true position.
They also sometimes do the same thing with corpses in games, making looting a pain. Kill the mobile and the corpse teleports about once you try and open it, at times inside a tree or other object making it inaccessible. ie, where you appeared to fight the mobile wasn’t where it truly was.
That’s certainly a factor, I think I remember when reading the docs, that things fall back to to the arbitration server if a set of peers gets saturated. Might be different in Europe, but in the USA most internet connections have a great deal of downstream but incredibly limited upstream bandwidth.
Walk into a city, an instance with 40 other characters, it will certainly need to fall back to the arbitration server. I got the impression that the peer network would only come into play in situations such as 2 people wandering in the middle of nowhere. If so, you’re adding a lot of complexity for no reason if you’re going to end up on the arbitration server anyhow.
Myself, I would also think that interest management is really the big question when offloading so much to the clients.
The technology is unproven. There’s not a single production game using it that you can log into and see how it handles itself in real world situation. They have a few things on their showcase, but none of them have anybody logged into them. Show me a game with a thousand players logged in, then we’ll see how the peer network handles itself.
The problem you describe there though sounds like it basically never verifies and syncs up at all so it runs all local till you do something or alike, that or a massive multi second latency.
Haveo nly seen very few games do that and they were often using HTTP fallbacks and crap like that.
unsure if badumna for example works at all on mobile.
but a verification at a very low frequency for example would still be enough. it would not be 100% accurate, but accurate enough to not allow any real benefit.
Bandwidth: Same here in europe too. its normally a factor of 10 - 20 between up and downstream.
I see alot of speculation, Have any of you guys ever set up badumna network server? and tested how it works? It’s actually a pretty solid peace of software. I certainly can say iv tested just the default seed peers on the previous version of badumna with a hand full of people (i cant say for more then 20 people in a area what happends) but, the connection seemed to improve the more we added. Peoples locations didnt jump let alone movement was very smooth.
They also have a option to add a overload server to the mix if someones connection is lacking or if things get to much i believe that is what Quietus is reffering too.
Now, With What Dreamora is saying about only having it check movement based on interactions threw the arbitration server you still have the peer to peer handling the movement… so the issue Quietus described is non existant aslong as no one is maliciously tampering with the movement.
My plan would be to have the clients check the data against each other … So if two people match and 1 person is cheating then they get flagged… That brings up other issues tho but, if we can get a solution like this working we can work thru them and probably have a viable answer to the cheating.
In low population areas i would add the cheat spheres… wich are basicly clients that would help check data with the other clients in the area against each other to single out a cheater… So it wouldnt be taking the whole load. I still think this system would benefit greatly from peer to peer if it worked. Only one way to find out… i will be working on such a system…
Also the upstream required for badumna is scalable… In reality it may be a bit costly on some clients but, for a standard broadband connection in the states it should be more then feasible… what at most it uses probably 50k? give or take
Someone made a good point the other day tho if your running the game threw a web player people cant de-compile which would drastically help slow down a lot of the cheating… However v1.4 of the network isn’t working for p2p atm so hopefully they will have fixed that soon…
This day in age especially with unity web player it doesn’t seem like a bad idea to run/stream a MMO threw a website player… If this is the case you can offload most the information onto the web player and then use arbitration for saving character information and statistics and things of that nature.
Ideally if this gets fixed with the web player you would have full use of the peer to peer and not have to worry about the information on the clients side. Altho couldn’t you still edit what goes into your memory?
Don’t count on the web player build to be undecompilable. I never heard UT say the web player build is encrypted. If there is a determined enough person, they will find a way.
Are your anti-cheat spheres checking after a client does something or before he does something?
The OP really needs to get started on his project and understand the software before trying to figure out it if it will work or not how he thinks it will. Making matters worse, the topic cheating is so broad that some people even disagree on what is actually considered to be cheating. My advice, which is closely related to Ensane’s, is to just get started on something using the preview version of the tool and see how it goes.
The project I stated is for the future and right now I’m busy with small-time projects on the iPhone. I do want to find some time to make a prototype in the future though.
I recently Licensed Badumna, There are a few other teams with these same security concerns. So what I plan on doing is putting together a collaboration project were we can all work on a Badumna server solution together and share ideas, code, security plans. The idea is so we can come up with a viable solution together and make this work as its a great piece of software.
This way we can continue our own projects individually but, work on a server end with a bigger group.
Please pm me if interested in getting into the collaboration!
Scalify has stated they also will be working on making there peer to peer solution more secure.