Лучше всего общаться между двумя досками скремблеров на отдельных компьютерах, создавая облако с таблицей SQL, имитируя доску. И каждый раз, когда я двигаюсь, вы связываетесь с сервером и обновляете локальную плату?Scrabble board to board
Звучит неплохо для меня. Scrabble не требует точности в миллисекундах в реальном времени, поэтому использование транзакций базы данных для достижения контроля платы звучит как хороший подход.
Хранение состояния платы в центральной БД прекрасно - и хороший дизайн. Пока неясно, каким образом вы планируете иметь каждый клиент ручку связи, у вас есть несколько вариантов:
Или
Таким образом, вы должны рассмотреть вопрос, хотите ли вы 2-полосную клиент-сервер связи (клиент вызывает сервер, сервер вызывает клиент) или хотите ли вы 1-полосной коммуникация клиентского сервера (клиенты звонят на сервер, включая опрос, чтобы определить, когда состояние изменилось).
В ваших ботинках, я попытался бы формализовать свои состояния немного больше. Если вы думаете об этом, игра Эрудит состоит из:
Многое из этого можно хранить в базе данных SQL - например, имя игрока и счет. Но SQL DB может быть слишком тяжелой для таких вещей, как координаты платы и как различные бонусы отображаются в разных координатах. Если вы думаете об этом, это статические, доступные только для чтения атрибуты, которые никогда не будут меняться от игры к игре. Было бы разумно представить их как сериализованный двухмерный массив или что-то подобное. То же самое касается словаря допустимых слов. В ваших ботинках у меня возникнет соблазн прочитать словарь из текстового файла при запуске сервера, сохранить строки в неперемещаемый массив и ручной код сверхбыстрого бинарного поиска, а не пострадать из-за накладных расходов на базу данных вызывает индексированную таблицу.
Подобным образом захват-мешок букв: вам действительно нужна база данных? Может, и так. Возможно, вы это решите, поскольку сумка-захват представляет собой изменяемое состояние, которое будет использоваться всеми подключенными клиентами, вы хотите воспользоваться механизмами блокировки вашего БД. Или, может быть, скорость становится проблемой, поэтому вы обнаружите, что массив или список вам лучше, и вам удобно управлять самим потоком.
Дело в том, что вы не будете знать, что выбрать, пока не сообщите, что вы делаете с некоторой степенью точности. Тогда вы можете начать рассматривать компромиссы.
Конечно, требуется больше планирования, и я сделаю это. Спасибо вам за ваши предложения. –
Здесь есть несколько хороших ответов, но я бы сказал, что все зависит от того, что у вас есть. Если вы можете предположить, что имеется центральный сервер, то использование его для отслеживания состояния игры было бы хорошей идеей, поскольку оно не блокировало бы клиентов на какой-либо конкретной машине - они могут переходить от одного к другому во время игры если они пожелают. Здесь также будет какая-то дополнительная защита, так как вы можете обнаружить клиентов, которые пытаются совершить незаконные действия. И я уверен, что есть и другие преимущества. Самым очевидным недостатком будет то, что для этого требуется сервер (т. Е. Третья часть аппаратного обеспечения, а также веб-адрес и хостинг и т. Д.).
Если вы не можете сделать это предположение, нет ничего плохого в том, чтобы сделать одного клиента «сервером». У него просто разные плюсы и минусы.
Что касается таблицы SQL, то rtperson сделал очень хорошие наблюдения.
Сервер не является проблемой, поэтому я уверен, что так я поеду. –
Могу ли я рекомендовать вставлять новые строки для каждого изменения на плату, а не обновлять существующие строки? Таким образом, у вас есть возможность вернуться в случае необходимости. –
Я думаю, что это немного усложнится. Я всегда могу сделать дубликат и повторить этот процесс в цикле. –
Я думаю, что идея Норлы действительно хороша. Вы можете использовать его, чтобы показать игровой повтор или показать последние пару шагов, чтобы игроки могли подумать о своих ходах. В зависимости от времени, которое вы ожидаете от игры (например, минут против дней), это может быть очень полезно. – Chris