@normen said: Quite the contrary actually. Definitely not slower. I agree obfuscating is silly though, you don't stop the people you want to stop.
In fact, it encourages them because now it’s a challenge.
1 Like
Challenge Accepted. lol
Anyways i feel like this has been answered, but i didnt notice it being specifically called out,
that is with authoritative server setup rather than predicting the future, you run your simulation as it were, and just take “snapshots” of it every pass through the network update loop, and then check the state of the player in the past, (because of the round trip time every client is in the past, just all of them are in different parts of it). The problem you called out in your original question is if the player moves in an unexpected fashion or something happens that the physics didnt predict, and the straight forward answer is you invalidate your users message and send them what would have actually happened at that point in the game, then take the input of what the player wants to do next, and plug that input into the “current” stage of the simulation. Then do the step, and calculate whether that action was valid or not and reply to the user.
Given those two restrictions its now clear that the user has to “predict” whats going to happen before the server has the chance to reply thus reducing the RTT essentially to none, unfortunately player action is NOT deterministic, therefore the response from the server is important, and when its different(never if, because of the user interaction statement 
), interpolate between the extrapolation from earlier, and what we just recieved, meaning while the game is running in the “now” state its not the actual position of the player, and you are constantly in the “approximate” vacinity of where you actually are, and there fore…
you dont exist and the cake is a LIE. Also networked physics is a lie since even valve only does real physics networking on actual player characters, and not the stupid cans lying around, cause thats just waste of bandwidth.
I hope this helps, and the proguard thing is debatable, because for every obfuscator / packer, there is a reverse that comes out like a week after, so mostly those are only usefull to package your viruses cuase they fudge the signature 
1 Like
@normen said: Quite the contrary actually. Definitely not slower. I agree obfuscating is silly though, you don't stop the people you want to stop.
Sorry, that was ambiguous. All it will do is slow down wannabe hackers - not stop them. It shouldn’t effect runtime performance unless its doing something stupid.
@zarch said: Sorry, that was ambiguous. All it will do is slow down wannabe hackers - not stop them. It shouldn't effect runtime performance unless its doing something stupid.Ah, right.
Thx for the answers :).
I never had obfuscated anything and the only obfuscated code I’ve ever seen was from minecraft so I believed I could learn some lessons from doing it. For example, you better make as much possible stuff non-public if you want the obfuscation to be somewhat effective. Ofc, you should always do that to end up with better code, but I have some values holder classes whose all fields are public which harms obfuscation.
You did convince me that obfuscating wouldn’t stop people really wanting to hack it, but it may stop people that would be discouraged by some additional work… though some may be more tempted XD.
Notch seems to have taken a road where constant updates with different obfuscations makes it more a pain in the butt for the hackers because their lil tricks only work for a lil while.
Anyway, I was already opting for the exe road and it’s nice" to be comforted in that way :).
I really have neither the resources nor the knowledge to protect against die hard hackers but I believe I shouldn’t make their work too easy :D.
I’m kind of mostly aiming for solo and friend/private networks, where people would be less tempted of cheating. I would love to have an authoritative server, but there is at least one main brick I have no idea how to do and valve documents don’t help me there so until I get how to do that, I’ll keep going with a barely-authoritative server.
The server would make sure you go “gate” by “gate” and didn’t go too quickly from one to the other. Would also check that shooting would occur on someone nearby… that kind of stuff.
Thx for the authoritative description. I think Valve adds a twist, through lerp (I think), where everything is played 1/10th of a second in the past, server-side, so as to be able to interpolate between known positions. Probably solves some contradicting situations too. Anyway, until I program one authoritative server, I’m way over my head here :D.
Anyway, my problems are code quality and logic related which is a very good sign for the monkey engine.
And that monkey is definitively Scottish… very small spender of cpu and mem.
Got some refactoring to do still to organize advanced logic and network message issuing and then I can get back to immediately rewarding stuff.
@loopies said: Notch seems to have taken a road where constant updates with different obfuscations makes it more a pain in the butt for the hackers because their lil tricks only work for a lil while.of stuff.
And yet still I understand you could decompile the whole thing and write plugins, override bits, etc… so I’m not sure what he was obfuscating for. Interesting that it still had a thriving plugin community.
@loopies said: Thx for the authoritative description. I think Valve adds a twist, through lerp (I think), where everything is played 1/10th of a second in the past, server-side, so as to be able to interpolate between known positions. Probably solves some contradicting situations too. Anyway, until I program one authoritative server, I'm way over my head here :D.
Since you brought it up, these links are obligatory:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
lerp - http://en.wikipedia.org/wiki/Linear_interpolation
turns out is linear interpolation and in source engine controls the choppiness of the animation, by controlling the “snapping” effect, meaning the amount of time thats spent adjusting between the calculated and the real value. Generally though @pspeed listed the two articles that describe how to implement what i talked about in my other post.
MonkeyZone uses bullet for determinism, a bit more advanced than linear interpolation but still relatively easy to handle / implement. Its basically the inverse of what valve does / suggests.
The lerp in this case is a form of synching two separate sets of frame rates. You have two values provided by some source that are at specific times but your rendering is going potentially at different times so you lerp between the two values.
JME Bullet gets around this by lockstepping the physics and render frames so that you know both frames are ready at the same time. But in a networking situation where you are getting states externally, you wait for the next known good state, set your time from that, and interpolate at regular render-frame-dependent intervals within these retained states. It makes for smoother movement and you can miss some state without it being obvious. The Valve articles go into way greater depth on that subject.
With the right threaded data structures it can also be used in the same process to smooth the differences between the physics thread and the render thread… say physics is operating at 50 FPS but your rendering speed will vary. The state rendered will vary widely as frames come in and out of sync unless you lerp.
The snapping issue is similar but separate. That’s when you’ve predicted incorrectly and now must catch up to a real position without it looking sucky.
Well MonkeyZone does that, it simply steps the physics slower or quicker to locally move to the target time which is determined from the current networking latency, as said very similar to what valve suggests.
@normen said: Well MonkeyZone does that, it simply steps the physics slower or quicker to locally move to the target time which is determined from the current networking latency, as said very similar to what valve suggests.
Yes, very similar to what they talk about on the server side for rolling back time, etc. to undo prediction.
The client side is a little different.
Forgive my crappy drawing (and I know you already know this Normen but for the rest of the thread):
Without interpolation, the client would only see movement where I’ve drawn blue dots down below. With lerp, everything is always smoothly interpolated and the two frame rates can be completely unhooked. When you have no control over either one, that’s useful.
Sooo, I’m back thinking about protecting my code. Not aiming for invulnerability, since that can’t be done.
I want it for 2 reasons:
- protection of my work… obfuscation could be enough here, since no feats are to be found in my lil start of a game
- barrier to cheating… really important since the server will barely be authoritative unless I suddenly gain 50 in IQ.
But .class files are kind of open books. Obfuscation doesn’t seem to be extremely useful and peeps here didn’t seem to trust it.
So, I thought, heck, I’ll simply turn my code into an exe… but, seems launch4j (which is used by jme) doesn’t build a “real” exe… right click such an exe and you get it’s content as class files.
So, I thought I’d go native (:D)… but seems the only software available for that would be excelsior jet… which is awfully expensive for a crappy game like mine (although it seems they have somewhat cheaper options if you contact them and fill a couple conditions)… and no certitude it would be able to compile.
So now, I’m back thinking about obfuscation… which I was told was quite useless, here.
Does anybody know of a good solution?
Business software are quite well protected by laws + lawyers, but that doesn’t work with games and doesn’t help me against cheating.
Also, I want to distribute the server with the game, so can’t hide anything there.
I read somewhere that imaginative business approach are the best way, but that is only somewhat possible for my kind of game and doesn’t help against cheating.
Why would Oracle not provide an aot?
Any thoughts? I’m kind of lost here. Is obfuscation the only tool?
Should I just do some obfuscation and forget about it?
No good solution.
And people even cheat if the game is distributed as .exe.
You have two options:
- Try to control the user’s machine and what runs and what doesn’t. Doesn’t sit well with those people who like to own their machine by themselves, thank you very much. Also, it’s horribly expensive to harden such a system.
- Give up on the topic and keep the server authoritative.
Okay, in theory, there is also
3) Let multiple clients do the same calculations and exclude cheaters.
I haven’t seen anybody do that, and it’s horribly complicated. It also tends to leak data to machines (and their users) that shouldn’t be able to see it. (It’s an avenue that I’d like to explore some day, but only after I have made enough money that I can afford to never work again. IOW: probably never.)
1 Like
You can’t control the machine anyway. In the extreme case they could run the game inside a complete clean VM and then modify/monitor it from outside the VM.
You really only have two choices for cheating:
- allow it
- have the server authoritative.
It’s trivially provable that there are no other options.
re: obfuscation, in my experience, most people who think they need this have an overestimated opinion of how clever their code is. And the truly clever parts would be apparent with or without obfuscation.
Edit: I should point out that there really is a third option where you distribute authoritativeness over a large group of players. I read an article on it once for a peer-to-peer MMO that was doing this. It’s incredibly complicated and requires that some clients from one game session are also running the game simulation for a group of clients in a completely different session. ie: regardless of your multiplayer game model you would still have to have a single authoritative server to at least coordinate the state voting. So I don’t really consider this a viable option for indie development.
1 Like
@zarch said: @pspeed heh, I've been mulling that idea over for a few years. Has someone actually implemented it?
I don’t remember who… but it was in a game developer magazine article a few months back. Also, I understand that Roblox (sp?) does a distributed physics engine but they may be less concerned about being authoritative.
I think for authoritativeness distributed over player machines, you need to dig deeply into distributed hashtables and how they establish truth. You might still want to have a central authoritative server to inject scripted events and such into the network.
Also, you’d have to pick your evil among the choices that the CAP theorem offers. (I just found a very enlightening article about that by Eric Brewer, explaining the actual as opposed to the obvious design choices imposed by CAP.)
Lag compensation could be a huge issue. Having to wait for multiple peers to confirm an outcome could slow down the game (and it would also multiply network traffic for each player); on the other hand, lag-wise near machines could react faster, and it would load a huge workload off the server, so you don’t need a server farm and can do indie MMOs.
It would be very, very nice to have this, and it would require very, very deep insight about P2P networking, establishing trust, and other interesting engineering puzzles.
For now, it’s far outside the reach of any indie game developer, I’d say, so it’s back to the two options: allow cheating, or have an authoritative server (or server farm).
UPDATE: Roblox was the right search term, I found this: http://blog.roblox.com/tag/distributed-physics/
Well, the way I was thinking it was that you have a shared state situation - and you are also connected to multiple verifiers. They don’t need to run the full game but just work to validate that you have what you say you have - essentially a 3rd party uses a public private key setup to record what you did and when.
For example in an RTS when you build things, move units, etc then verifiers would need to know and give you a signed key saying yes you did that. Then when you reveal the units/building/whatever you also reveal the signed key showing that you verified you did that. You would need something in place to stop people setting up multiple verifiers and sending them all different info but that can be done by having a 3 way handshake on setting up verifiers and then making the verifiers occasionally confirm with each other.
The big problem with this sort of approach though is that you have no guarantee that any server is going to be live or give you a certain level of service at any time. They could crash, turn off, start downloading porn, lose internet, whatever… Messy.
1 Like
Thx for your inputs, peeps, very enlightening as usual.
2 links I found quite complete on the subject: