Handling the physics/collisions on the server-side is a very good strategy so I would definitely recommend this approach to solve the problem of player objects going where they shouldn't. This means that you can build your server-side directly within unity, even in the same project that you build your client-side (even more useful!), and very efficiently run that on a dedicated server. As Whippet mentioned, unity games/applications can be built to linux (which is the OS of choice for server computers) and can be run in headless/batchmode mode (no audio/rendering, massively lowering the cpu/ram usage). To answer your question though, yeah that is exactly how you would do it. Both are viable, depending on your situation. I would recommend either going balls-deep, or just doing the cheap-and-nasty. There's no point in only partially implementing cheat prevention, unless it's just to try and confuse potential cheaters. In which case it may not be worth spending the time implementing cheat prevention.ĭefinitely don't go half way though. You however might value your time more, and you may be unsure about how well your game is going to do. I don't see my time as that valuable, so I'm happy to "waste" a lot of it, if I believe in what it is that I'm doing. Ultimately it comes down to how much time you want to spend on the game, and really whether you think the time will be worth it. Don't however confuse cheat prevention over malicious activity (such as DDOS attacks on your server) because these are things that cannot be 100% prevented. Many will tell you otherwise but I would be happy to prove them wrong. Although that can be a viable strategy, it is definitely the cheap-and-nasty route. The whole "it can be too much work" comes from the scenario where you do little-to-no planning, and optimize/prevent cheating later on. This means that I actually spend very little time implementing cheat prevention, because I've prepared for it. And I will stay in that planning stage for as long as I need to, before I know everything that I need to know. I am fairly methodological when it comes to building games/apps, I prefer to plan for things like optimization and cheat prevention right from the beginning.However, I definitely sit on the side of the fence that says to always prevent cheating, simply because: The reason for this, as Whippets mentioned, is sometimes the work and cost involved to solve problems with cheating is too high. The old "there's only a few people that cheat, so why bother" concept is sometimes valid. Response is definitely a good one, but to add to what has been said already.
0 kommentar(er)
