Quote:
I'm a little stuck in Moe at the point where I need to add command handling for player orders. In the previous iteration, each player got their own handler. That was nice because then setting that it was someone's turn was as easy as enabling the 'in turn' commands. It sucked, because almost all of the commands needed to know whose turn it was, which lead to a lot of binding for the particular commands. I'd like to make something a little more elegant than my current options.

1. Do binding like before. Effective, easy, but tedious.

2. Extend the handler to pass the player giving the orders as a parameter. Easy, but kind of limits the command methods, and will undoubtably yield methods that take a player param only to ignore it.

3. Have a common 'current turn' member of a game object. Hackish, and makes the handling functions need to know what game they're in, which isn't much benefit.

There's a few others floating around, but they're either too off the wall or too risky for me to use for something as important as command handling. I think there's an elegant solution I am merely overlooking either due to ignorance, sleep deprivation, or sheer skillessness; let's hope for sleep deprivation and if not that will at least help make a good design if not nice and elegant.

Amazingly, I found it pretty easy to get coding again after the slight layoff and the SQL debacle this morning. While doing bills, keeping the dog from going nuts and various similar distractions I knocked up a little infrastructure for server side message handling in a mere 2 hours.

I went with option #3, sort of. A little attribute, a little reflection, and bingo! code to automagically collect handlers into a parser (optionally binding the game context). I like that I can now ignore this code and just focus on adding handlers/content. Less room for error.