The idea is to build a demo of a game in Perl/tk.
Basic premise is this: Various players request moves in a gui client, send the move request off to a server. Server then resolves all moves, stores resultant game state in db, client reconnects, gets new game state, game continues.
Assume secure sockets, crypto secure ident, and spoofing pretty much handled, as in, we'll do that in the real version if there is one.
One assumes that using perl for this would be slow, and thats okay by me, since this is to be a proof of concept, not a playable game.
I've taken a stab at mocking up a perl/tk client, and I'm satisfied that perl/tk will give us enough features.
The next obvious thing to do is start work on the server end. We're now working out game rules on paper, but I was hoping the monks could give me some ideas:

Game rules by external grammar? ie write a parser and a separate rule file? .. making it "pluggable"

Hard code game rules in a module, and expose an api so we re write the module for different rules? Also pluggable and possibly easier to write than a grammar.

Hack up some kind of xs api to the demi-OOP capabilities of the zip/infocomm game engine?

some other, much smarter idea that I'm missing? Help me perlmonks, you're my only hope!
--
Jay "Yohimbe" Thorne, alpha geek for UserFriendly

---

In reply to Rule Based Game Engines by Yohimbe

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.