TNet: Network Level Loading

[MCoburn]

What level of cheat-prevention are you aiming for in your project? Because with the strategy you outlined, I'd imagine it'd be fairly easy for clients to misreport their location to peers, and cause some major issues. Doing hit / collision checking on one host should avoid major score / state synchronization issues, but wouldn't a client misreporting it's position cause problems? Client A could report it's position falsely and make it to be nearly impossible for clients B, C, and D to hit client A between the update on their screens and the roundtrip back to the "host".

I ask because I feel like your end-goal is the same as my own, and am at the point where I have to make smart architecture decisions. It's pretty desirable to have the server doing as little as possible, but having no cheating is important too.

Honestly, I'm not quite sure what implementation I should go with. I just don't have the finances to afford game servers that have big capacities of CPU grunt and RAM which is annoying, but as a 2-man start-up you have to do what you have to do. Even if I did have the finances, I would be spending it on team development hardware and software licensing, plus business costs.

What I can see is the "host" is the one that dictates what's going on, as for the match type, scoreboard, timer, etc. When a weapon requests to fire, it (the host) does the estimation and all the related things. I could view this as a "Thin Client Network" in the IT sector. However, as Aren stated, it's better to let the clients do all the other work, rather than just be a "puppet". Then another factor is client correction - the server needs to be able to tell a client "hey, you goofed, get back to Vector3(x,y,z)".

I really don't know. I think it's best if I can get together with someone who has worked on network systems before and discuss it with them, otherwise I'm going to run around in circles and goof something up. Cheating may happen, but hopefully kits like Anti-Cheat Toolkit will help protect the core, but not eliminate all the vectors. I'll possibly rely on community reporting, and have a function assigned to a snap key that will take a picture of whatever's on screen and relay it to the team with a message for review. I will, however say that if the players are found to be cheating with enough evidence (Aimbot, etc) they will be banned for oblivion (however I implement this will be a discussion topic down the track).

I don't mind having another brain () to help assist with game coding areas that I am not fluent in.

I see two extremes: one end of the spectrum is having clients do everything, but that is the worst-case scenario for cheat prevention and best for resource utilization. The opposite is having a server do everything, which is the best case scenario for cheat prevention, but terrible on resource utilization. I realize it's really dependent on the game, but is semi-authoritative generally the balanced option?

I'd love to see what Aren weighs in with.

[ArenMook]

@Nick: Naw I left Unity almost a year ago. I've focused on NGUI for the first couple of months after that, and now I'm back to game dev full time. Windward is going to be out on Steam shortly.

@MCoburn and @Nick: As I always say make a game worth hacking first, and then worry about hackers. Preventing hacking is like preventing piracy. You can try, but you will fail. You can make it less convenient for them, sure -- but you won't prevent them from getting the results they want in the end. Also keep in mind that some games actually benefit from a lack of such features. Anything you want moddable is better left without server-side checks for example.

[MCoburn]

@MCoburn and @Nick: As I always say make a game worth hacking first, and then worry about hackers. Preventing hacking is like preventing piracy. You can try, but you will fail. You can make it less convenient for them, sure -- but you won't prevent them from getting the results they want in the end. Also keep in mind that some games actually benefit from a lack of such features. Anything you want moddable is better left without server-side checks for example.

That rings true. I guess hackers won't want to hack a game that isn't deemed worthy of hacking. I spoke to my teammate and we agreed that there's always going to be a minority of the public who want to flex their hacking skills, either for fun against there hacker friends, or just script kiddies.

At the very least, Unity's runtime has some sort of protection. I'm not sure how well that protection works, but it's not using a engine, like say IDTech where it's rather easy to hook up an aimbot. Whatever the case, I think for now I focus on making the game happen, then if the hacks occur, see what vectors they are attacking and then revise that chunk of the code. Like I said, we can't have the "perfect" app that is 100% hacker proof, somewhere there's bound to be a guy/girl poking memory and looking through the code to see what is going on.

I will protect the vitals though, such as health and such.