From: brett l. <wak...@gm...> - 2007-10-25 03:29:24
|
On 10/24/07, Chris Shaffer <chr...@gm...> wrote: > > Hmm... either I don't understand your description, or I have a > > completely different design goal, but that sounds way more complex > > than it really needs to be to implement a playable game. Having > > multiple tiles that are the same ID but different rotations doesn't > > make sense to me. Why wouldn't you have one tile, know the starting > > rotation, then calculate the other rotations? > > Because the orientation/location of the printed number on the tile is > what is used by players in play-by-email to describe the position of > the tile. You have to account for all the possibilities in playing > the game. > > I'm currently in a play-by-email game with someone who can charitably > be described as computer-illiterate. Over the course of the game, > we've had to reset his turn and rebuild the spreadsheet several times. > If we didn't have a consistent way to describe tile orientations > (within that particular game, compared to the actual physical copy of > the game that he owns and has set up in his basement), we wouldn't be > able to play. Despite the challenges of playing with this fellow, I'm > really enjoying the game, and he's a good player. He just has no clue > how the computer really works. > > Thus, it's important to mimic the printed games as closely as > possible, as John Tamplin described. > Hmm... I think there's the exact disconnect. You see, with an implementation like Rails, that eliminates the causes for much of those problems. Rather than trying to figure out what version of the printed game each player has, you all centralize on the same computer version, which handles all of those details for you. This allows you to just focus on the printed image rather than trying to get verbal descriptions correct. ---Brett. |