|Keep It Simple, Stupid|
Moose class design for gameby wanna_code_perl (Pilgrim)
|on Sep 06, 2013 at 01:33 UTC||Need Help??|
wanna_code_perl has asked for the
wisdom of the Perl Monks concerning the following question:
I'm toying with some proof-of-concept code for an online game with the logic written in Perl (and Moose). The game would have a typical client/server architecture, with the closed-source server determining all critical game state and logic, and open-source client handling the player UI and game view. What I'm not sure of is how to model the game state in the client without duplication of code. Say I have the bad guys modeled like so (simplified):
The server of course needs low-level r/w access to this information. The client, however, will run on the player's computer and must therefore have limited access but enough to display the bad guys on screen and determine how the player may interact with them.
The rub is: I'm operating under the assumption that someone will start hacking at the Perl client code. Obviously the client can't just do $badguy->health(0); and expect a meaningful result; that's not the issue. The issue is exposing only select fields to the client (possibly munged) so it's non-trivial to reverse-engineer the game mechanics (see Note), and how to design the class(es) efficiently. For example:
So, then, what's the best way to go about this? Keeping in mind the client will receive some kind of serialized copy of the relevant data (and only the relevant data), here are some options I've brainstormed so far:
There are tradeoffs to each of these. But it still feels like there's a pattern I'm missing (it's been a while since I did any serious OO design, plus this is my first non-trivial effort with Moose).
Note: I believe that determined players should be able to figure out most of the game mechanics, but doing so should involve observation, math, and intuition, not just a couple of trivial method calls. In fact I'd be honored if someone cared enough to go to the effort.