Hacker News Reader

Comment by reedlaw | Hacker News Reader

You're right, but for me another challenge was to try to circumvent cheating. If I see players that try to win by pure Ruby hackery I'd like to see if there's a Ruby way to make sure that hackery doesn't work (inside Game, Player, or PlayerProxy). Is there a way in Ruby to prevent a module from overriding a method of the class in which its included?

View on HN

Short answer: No. Nothing in Ruby is truly private, and even if you did manage to hide references to something, you could always find it in ObjectSpace. I could even undefine your Game class and replace it with my own (I reject your reality, and substitute my own!)

To get true cheating prevention, you'd have to do something like spawn off another Ruby process and use some kind of IPC to pass events to your "client" process and receive actions back to your "server" process. All canonical state would be held by the "server" process.

This is really the classic "don't trust the client" problem that all games run into. :)

if you force move to be an arithmetic function with inputs the stats of the game, then you can parse that the syntax of the move functions only involve arithmetic operators and some math functions (max, min, ...). This way one can't cheat in the game.

My #move method was perfectly innocuous; I cheated by making my player never take damage, and by giving him infinite stats.

Parsing source code for "bad" stuff is generally an arms race you can't win. For actual sandboxing you need a clean environment (hence, the reference to Lua's setfenv).

I haven't used it, but if you're running this on MRI, you might try https://github.com/tario/shikashi

Reply on news.ycombinator.com