Scrabble board to board

Is it best to communicat开发者_StackOverflow中文版e between two scrabble boards on separate computers by creating a cloud with a SQL table, simulating the board. And every time I move is made you contact the server and update the local board?

Sounds good to me. Scrabble doesn't require real-time millisecond precision, so using database transactions to consummate the board moves sounds like a good approach.

In your shoes, I'd try to formalize my states a bit more. If you think of it, a Scrabble game consists of:

• A board
• The coordinates on that board that give bonuses (x2 letter, x3 word, etal.)
• The set of available letters, and the amounts of each letter available, and the point-score for each letter
• A profile for each player
• The set of letters in each Player's possession
• The words each player has played, and where they are on the board
• The player's current score
• A dictionary of allowable words (for challenges)

A lot of this can be stored in an SQL database - for instance, a player's name and score. But an SQL DB might be too heavy for things like the board coordinates and how various bonuses map to various coordinates. If you think of it, these are static, read-only attributes that will never change from game to game. It might make sense to represent them as a serialized 2-D array, or something similar. Same goes for the dictionary of allowable words. In your shoes I'd be tempted to read the dictionary from a text file on server start-up, store the strings into a non-mutable array, and hand-code an ultra-fast binary search rather than suffer through the overhead of database calls to an indexed table.

Likewise the grab-bag of letters: do you really need a database for this? Maybe you do. Maybe you decide that, since the grab-bag represents mutable state that's going to be shared between all connected clients, you want to take advantage of your DB's locking mechanisms. Or maybe speed becomes an issue, so you find that an array or a list serves you better, and you're comfortable managing the thread-state yourself.

The point is that you won't know what to choose until you spell out what you're doing with some degree of precision. Then you can begin to consider the trade-offs.

Storing the board state in a central DB is fine - and good design. It's unclear how you are planning on having each client handle communications, you have a couple of options:

1. client 1 make a move, send details to server (persisting state in DB)
2. server pings client 2 notifying them that it is their move (use a remoting technology to ping)
3. Same as step 1 but for client 2.

Or

1. client 1 make a move, send details to server (persisting state in DB)
2. client 2 polls server until it notices that it is it's turn.
3. Same as step 1 but for client 2.

So, you have to consider whether you want 2-way client-server communication (client calls server, server calls client) or whether you want 1-way client server communication (clients calls server, including polling to determine when state has changed).

There are some good answers here but I would say it really all depends on what you have available. If you can assume that there is a central server available, then using it to keep track of game state would be a good idea, as it would not lock down the clients to any particular machine - they can go from one to another during the game if they wish. There would also be some extra security here, as you can detect clients that are trying to make illegal moves. And I'm sure there are other benefits too. The most obvious downside would be that this requires a server (i.e. a third piece of hardware, along with a web address and hosting, etc.).

If you can't make that assumption, there's really nothing wrong with making one client the 'server'. It just comes with different pros and cons.

As for using an SQL table, rtperson made some very good observations.