| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > PHP: Общие вопросы > Как правильно реализовать общую структуру правил д |
| Автор: nepster 14.8.2014, 16:32 | ||||
| Делаю игровой портал, где есть игры по заявкам и столы. Столы - фиксированные правила, пользователи присоединяются за стол и в любой момент могут уйти Заявки - пользователи создают игры по желаемым правилам (например играть в дурака переводного, колодой из 52 карт, на ход отводить 2 минуты). Столкнулся с проблемами проектирования для правил игры по заявкам. GameProposalRulesInterface - интерфейс для реализации правил
Итак в любой заявке есть правило для выбора игроков (2, 3, 4, на пару), игра на интерес или на рейтинг и тп, время хода и дополнительные правила. Например: Дурак: 2, 3, 4 или на пару, на интерес или на рейтинг, 60 секунд на ход, дурак переводной, колода из 52 карт Шашки: 2 игрока, на интерес или на рейтинг, 60 секунд на ход, дамка ходит только на 1 клетку, бить назад нельзя Правила описываются в конфигурационном файла примерно так:
Следующий этап это виджет который генерирует из общего массива правил игры (общий массив правил собирает спец. хелпер) форму для пользователя: ![]() Вопрос 1: Как организовать дочерние правила ? Тоесть к примеру если пользователь выбирает играть на рейтинг, должно открыться окошко для ввода суммы. Я генерировал эти правили и скрывал через display:block, но это не лучший вариант, так как данные летят на сервер. Вопрос 2: Поделитесь пожалуйста советом, возможно есть косяки при структуре и можно сделать лучше ? |
| Автор: ksnk 14.8.2014, 17:15 |
| nepster, Вопрос непонятен. Насчет формы и ее автоматического перестроения я бы делал так. По каждому критическому выбору пользователя (все чек-радио-батоны, полностью введенные текстовые поля и т.д.), ajax'ом форма отсылается на сервер с признаком "validate", без реального создания игры. Введенная информация хранится в сессии и используется для формирования новой формы. По введенным данным инициируется игра в тестовом режиме и сообщения об ошибках создания игры выводятся клиенту. Дополнительно заново формируется форма ввода параметров. Если форма ввода изменилась от выбранных правил - она отсылается клиенту и клиент подменяет ее у себя. Таким образом, логика валидации параметров игры оказывается собрана в одном месте - в конструкторе класса игры. Дополнительно в классе есть метод-генератор формы ввода параметров игры. Его, вероятно, удобно разместить в классе-родителе всех таких игр. |
| Автор: nepster 14.8.2014, 17:37 |
| Вы не так поняли. Чуть подробнее: Вы зашли на сайт, хотите поиграть к примеру в дурака. Вы заходите на страницу игры дурак, где есть список предложенных заявок, если вас не устраивает вы создаете свою заявку и ждете других игроков. Вопрос в том, что у меня не выходит красиво с точки зрения проектирования оформить заявку. Тоесть мы делим игры на типы (столы, заявки, лоттереи и тп.). Берем к примеру тип заявки, к которому относятся: шашки, шахматы, нарды, дурак, деберц, морской бой и тп. Теперь я хочу сделать так, что бы у каждой игры был свой конфигурационный файл, который бы описывал правила для каждой игры. Вначале у нас идет список основных правил, которые есть везде: - игроки - время на ход - игра на эти все правила есть в любой игре текущего типа. Дальше есть дополнительные правила, которые в каждой игре разные. Меня интересует как лучше всего хранить эти правила в конфигурационном файле, чтобы максимиально просто было сгенерировать форму для создания заяки ? и 2 вопрос Как организовать вложенные правила ? |
| Автор: Game-lot 14.8.2014, 19:07 |
| воспользуйтесь форматом JSON или XML Этот ответ добавлен с нового Винграда - http://ru.vingrad.com/Kak-pravilno-realizovat-obshchuyu-strukturu-pravil-d-id53ecba8fae2015ab658b4567#findElement_E7045_53ecdec3ae2015d676b418a3_0 |
| Автор: nepster 14.8.2014, 20:44 |
| xml - умер =) а какая разница между массивом и json в данной ситуации ? |
| Автор: Aliance 15.8.2014, 07:55 |
| Мне кажется не верно разные игры подпихивать под один интерфейс. Скорее всего их должно быть несколько. А что бы скрытые данные не посылались на сервер - им нужно назначать атрибут disabled ПС: ksnk, что-то мне не кажется такое решение хорошим =( |
| Автор: ksnk 15.8.2014, 09:58 |
Почему? Логика в одном месте - это всегда хорошо. Нет? Другое дело, что валидация делается через реакцию сервера, это немного замедляет реактивность. Добавлено через 2 минуты и 51 секунду nepster, Как хранить - какая разница? Чем не устраивает php-array? Если хочется чего-то более красивого - можно смотреть на yaml, но принципиальной разницы не очень много. |
| Автор: ksnk 15.8.2014, 11:28 |
| Aliance, Если форма ввода зафиксирована и нечасто меняется, то лучше продублировать валидацию в клиенте, для реактивности и разгрузки трафика, тут особых возражений нет. Но тут случай, когда сами правила валидации могут оказаться сложнее, чем формальное наличие-отсутствие значений. Насколько я понимаю, тут список игр будет пополняться-изменяться на лету и гарантировать корректную валидацию на клиенте может и не получится. Так что все равно придется по окончании ввода параметров делать попытку стартовать игру и выводить сообщения об ошибке в случае неудачи. Почему бы не пользоваться этим механизмом почаще, вместо дублирования логики проверки на клиенте? |
| Автор: nepster 15.8.2014, 13:46 |
| Фактически форма вообще не должна меняться. Ну может только в том случае, если в какой-то игре будет добавленно новое правило. Я даже не знаю, например пользователи попросили включить джокеров в игру дурака. Мне очень интересно как максимально просто хранить список правил, в каком вормате и максимально легко сгенерировать форму. Тоесть чтобы при добавлении новой игры, нужно было только внести ее в базу и добавить список правил. |
| Автор: ksnk 15.8.2014, 14:28 | ||
Так форма должна меняться? В принципе, чтобы скрытые поля не передавали данные на сервер, их можно дополнительно disable' ить. Хотя и не понятно чему мешают лишние поля в post'е? В Yaml есть алиасы и еще какие то навороты, что позволяет единые опции для разных игр определять в конфигурации в одном месте. |