Register
Events
Popular
More
Post #1I've had a few discussions with some people that are familiar with this game engine, and they stated, "This engine has always been compromised with these types of hacks. If they continue to use this engine, this will be something that we will deal with for the foreseeable future."
Now I myself am not as familiar with this engine as the people I spoke to, so I'm just quoting their comments. But if their theories are correct, I really hope they use the millions of dollars we provided them to invest in using a much more up to date engine that will eliminate most of these known hacks.
You guys are making a real successful indie game. Do not let these hackers get to you, as they could be trying to push you out of the market by making it too much of a pain in the ass to provide a sound game in a timely matter. I think I speak for everyone, that your proof of concept it exceptional, and the players that really respect what you're doing will follow you to a final product, no matter what direction you guys decide to go. So keep on keepen on, life's a garden dig it.
-
-
Switching engines would require them to totally rebuild the game.
The reason you can get so many players on a server is the same reason its vulnerable to hackers, lots of work is done clientside to have less stress on server.
-
who said this lmao
they're wrong
-
That's a completely nonsensical theory. The Unity engine is not "more vulnerable" to hacks than, say, the Source engine or Unreal Engine 3.
Rust is vulnerable to hackers for several reasons, and the number one reason is that validation is being handled client-side for speed and efficiency in testing and debugging. This means that the server trusts what the client is saying, including if a hacker has compromised the client and is sending bad data in order to noclip and speedhack.
This will change in the future.
-
Do you have any experience developing with these engines, or are you talking out your butt? It is quite possible the other engines are built with a more server authoritative model than unity and the popular unity third party components. If that is the case, then they could very well be less vulnerable to hacks.
That might not be the case, but unless you know for sure, then saying it is a 'completely nonsensical theory' is a completely nonsensical thing to do.
"that validation is being handled client-side for speed and efficiency in testing and debugging. This means that the server trusts what the client is saying, including if a hacker has compromised the client and is sending bad data in order to noclip and speedhack."
Do you have a cite for Facepunch claiming this is intentional and deliberate?
-
Uh, no, the main function of an engine is not to lay down a single rigid inflexible server-client relationship. You can make the server as paranoid and secure against client tampering as you want on any engine, as long as you're willing to write the code needed for the server to essentially run the entire simulation so it can thwart most hacks.
There is nothing inherently unstable or vulnerable with the Unity engine. The devs currently do not do server-side validation in Rust for two main reasons:
1. Putting all that validation on the server side has a major impact on performance, and the server has bad performance enough as it is right now. Optimization will come in time, and that'll make server-side validation more practical.
2. Having the validation be on the client means it's a lot faster to track down bugs and push out updates. If everything was being handled on the server, any gameplay change on the client would need to be replicated on the server code, because now you have to keep both of them in sync and on the same page. That means every change is in fact two changes, which doubles the opportunity for bugs to screw everything up.
I don't have experience programming games in Unity, but I know shit about software development in general.
Edited:
Max was on the Rust dev team at the time of this post and would know what the programmers were saying inside the dev team:
-
"the main function of an engine is not to lay down a single rigid inflexible server-client relationship"
Not sure how you go from 'authoritative server' model to 'single rigid inflexible server-client relationship'. That's quite a leap.
You folks seem to think I am still making this crap up. Try this: http://developer.muchdifferent.com/u...ritativeServer (From the library documentation used by Facepunch)
Questions: based on your experience in software development, do you think it is easier or harder to make a game use an authoritative model later rather than earlier? Are those bugs ones you'd rather squish earlier or later?
Perhaps, if there were only hundreds of servers instead of thousands, the resources could be consolidated to run the game better.
With properly library development, you don't have to run into a situation where "any gameplay change on the client would need to be replicated on the server code, because now you have to keep both of them in sync and on the same page." I never would have thought I'd give Notch a shout out, but they do a pretty fine job of managing common execution re: client and server. It doesn't have to be two completely sets of independent code. Algorithms by their very nature tend to be very reusable components.
Also, not all server-side authoritative code has to be a duplicate of the client code, in fact, for some concepts, that would be a pretty poor design strategy anyway.
Still waiting on your cite for what you are claiming about Facepunch doing this intentional and deliberate.
Edit: Ninja edit on your part. I think I remember seeing that. I would love more than an IIRC from a non-programmer.
If it truly is the case, then I don't envy them when they have to go put that stuff back in to the server.
-
If you can edit your posts after I've started replying, so can I.
-
Yes, you may. Did you really flag my post as 'late'?
Elix, you are a piece of work my man.
-
Hackers are an important factor for Facepunch's cash flow. Without hackers, the number of private servers rented by players will be significantly less. You didn't really think you could play a cool game forever for just $20 did you?
-
I don't think this calculation ever happened the way you're thinking. The number of private servers exploded before there even were pervasive hackers running around constantly. Everyone wants to be the admin.
The devs aren't particularly relying on hackers for their cash flow. If anything, hackers are hurting their cash flow by making the game inhospitable to legit users if the server they're on isn't closely moderated. The money coming in from new copies of Rust being bought after bans is very likely not a replacement for the negative effects the hackers have on Rust's reputation.
As for wanting a response from a coder, go ahead and ask garry why validation is all client-side. Go nuts.
-
Ha, while I wonder about some of his approach to timing, priorities, and such, I don't doubt his integrity, so I doubt it is an intentional strategy. Having said that, I've seen enough profiles of people I suspected of hacking that have only had Rust a few days and its only their game to think that it definitely isn't hurting their cash flow to have hackers continually rebuying the game.
So much more helpful to engage in meaningful conversation than to just flag posts as dumb, donchathink?
-
Crying over ratings on Facepunch generally just attracts more dumb ratings, FYI.
-
Do you think DICE/EA should ditch Frostbite because it's been compromised by numerous hacks? A different engine won't prevent cheating in an online game.
-
99victor has no idea about Game Dev. yet is complaining about how real world game devs work.
Move along nothing new here...
-
It's not all client-side right now. They moved placement of construction items to require server side authorization, for example.
Most of my response on this topic has been in response to people claiming that 'there isn't anything you can do' to prevent the hacking, when in fact there is, and being so fatalistic isn't fruitful.
I jumped in this thread because I didn't like that you jumped on the OP's post as if it the theory as crazy, which it isn't. I find it crazy to think that an engine that has likely had millions of dollars more put into it wouldn't have more authoritative mechanisms built into the server than one that is a relatively inexpensive choice that is (justifiably) a common choice of Indie developers. I would be incredibly surprised to learn that every game built on those engines had to build their own 'don't let the player fly around the map' logic built into it, for example.
Again, I don't know with certainty, but the theory certainly isn't crazy. Price and features are what drive companies to choose an engine.
Edited:
I wasn't crying. I find them quite humorous and fairly telling about the people that use them.
-
There are things they can do, and anyone who says otherwise is a fool. However, those things will take time and are not easy, and anyone who expects the changes to occur rapidly and on demand (in bitchy forum threads) is also a fool.
My point is, Rust is vulnerable to hackers right now, it's going to stay that way for the near future, bandaid solutions are inappropriate wastes of the devs' time most of the time, and people need to stop whining about it so much and learn some patience.
Every day the Rust forum sees at least five new threads complaining about hackers. Often with no proof but a Steam profile, and they expect bans to be handed out on that no-evidence. People need to get over the fact that Rust is in alpha, and it's a real alpha, not a fancy word for "you pay less than full price because you heard about it early".
Dumb x 2
Optimistic x 1
Agree x 1
Artistic x 1
Late x 1
Funny x 1
