Делаю игровой портал, где есть игры по заявкам и столы. 
Столы - фиксированные правила, пользователи присоединяются за стол и в любой момент могут уйти 
Заявки - пользователи создают игры по желаемым правилам (например играть в дурака переводного, колодой из 52 карт, на ход отводить 2 минуты).

Столкнулся с проблемами проектирования для правил игры по заявкам. 

GameProposalRulesInterface - интерфейс для реализации правил



Итак в любой заявке есть правило для выбора игроков (2, 3, 4, на пару), игра на интерес или на рейтинг и тп, время хода и дополнительные правила. 

Например:
Дурак: 2, 3, 4 или на пару, на интерес или на рейтинг, 60 секунд на ход, дурак переводной, колода из 52 карт
Шашки: 2 игрока, на интерес или на рейтинг, 60 секунд на ход, дамка ходит только на 1 клетку, бить назад нельзя

Правила описываются в конфигурационном файла примерно так:




Следующий этап это виджет который генерирует из общего массива правил игры (общий массив правил собирает спец. хелпер) форму для пользователя:



Вопрос 1:
Как организовать дочерние правила ? Тоесть к примеру если пользователь выбирает играть на рейтинг, должно открыться окошко для ввода суммы.
Я генерировал эти правили и скрывал через display:block, но это не лучший вариант, так как данные летят на сервер.

Вопрос 2:
Поделитесь пожалуйста советом, возможно есть косяки при структуре и можно сделать лучше ?

nepster, Вопрос непонятен.

Насчет формы и ее автоматического перестроения я бы делал так. По каждому критическому выбору пользователя (все чек-радио-батоны, полностью введенные текстовые поля и т.д.), ajax'ом форма отсылается на сервер с признаком "validate", без реального создания игры. Введенная информация хранится в сессии и используется для формирования новой формы. По введенным данным инициируется игра в тестовом режиме и сообщения об ошибках создания игры выводятся клиенту. Дополнительно заново формируется форма ввода параметров. Если форма ввода изменилась от выбранных правил - она отсылается клиенту и клиент подменяет ее у себя.

Таким образом, логика валидации параметров игры оказывается собрана в одном месте - в конструкторе класса игры. Дополнительно в классе есть метод-генератор формы ввода параметров игры. Его, вероятно, удобно разместить в классе-родителе всех таких игр.

Вы не так поняли. 

Чуть подробнее:
Вы зашли на сайт, хотите поиграть к примеру в дурака. Вы заходите на страницу игры дурак, где есть список предложенных заявок, если вас не устраивает вы создаете свою заявку и ждете других игроков. 

Вопрос в том, что у меня не выходит красиво с точки зрения проектирования оформить заявку. 

Тоесть мы делим игры на типы (столы, заявки, лоттереи и тп.). Берем к примеру тип заявки, к которому относятся: шашки, шахматы, нарды, дурак, деберц, морской бой и тп. 

Теперь я хочу сделать так, что бы у каждой игры был свой конфигурационный файл,  который бы описывал правила для каждой игры. 
Вначале у нас идет список основных правил, которые есть везде:
- игроки 
- время на ход
- игра на 

эти все правила есть в любой игре текущего типа. Дальше есть дополнительные правила, которые в каждой игре разные. 

Меня интересует как лучше всего хранить эти правила в конфигурационном файле, чтобы максимиально просто было сгенерировать форму для создания заяки ? 

и 2 вопрос

Как организовать вложенные правила ? 

воспользуйтесь форматом JSON или XML

Этот ответ добавлен с нового Винграда - http://vingrad.com

xml - умер =) 

а какая разница между массивом и json в данной ситуации ? 

Мне кажется не верно разные игры подпихивать под один интерфейс. Скорее всего их должно быть несколько.

А что бы скрытые данные не посылались на сервер - им нужно назначать атрибут disabled

ПС: ksnk, что-то мне не кажется такое решение хорошим =(

Почему? Логика в одном месте - это всегда хорошо. Нет? Другое дело, что валидация делается через реакцию сервера, это немного замедляет реактивность.

Добавлено через 2 минуты и 51 секунду
nepster, Как хранить - какая разница? Чем не устраивает php-array? Если хочется чего-то более красивого - можно смотреть на yaml, но принципиальной разницы не очень много.

мне не понравилась сама идея "выполнить фейковую операцию и посмотреть что вернется в ответ". наверное, единственный раз, где это было оправдано в моем опыте - это создание объявлений через ВК АПИ (что логично - валидация находится на другом сервере, и может быть изменена - поэтому тестовое создание - единственное универсальное в том случае решение). А в собственном же проекте лучше обойтись без этого. Что мешает продублировать основные правила на клиент, как это обычно делается? Или я не правильно чего-то понял?

Aliance, Если форма ввода зафиксирована и нечасто меняется, то лучше продублировать валидацию в клиенте, для реактивности и разгрузки трафика, тут особых возражений нет. 
Но тут случай, когда сами правила валидации могут оказаться сложнее, чем формальное наличие-отсутствие значений. Насколько я понимаю, тут список игр будет пополняться-изменяться на лету и гарантировать корректную валидацию на клиенте может и не получится. Так что все равно придется по окончании ввода параметров делать попытку стартовать игру и выводить сообщения об ошибке в случае неудачи. Почему бы не пользоваться этим механизмом почаще, вместо дублирования логики проверки на клиенте? 

 

Фактически форма вообще не должна меняться. Ну может только в том случае, если в какой-то игре будет добавленно новое правило. 
Я даже не знаю, например пользователи попросили включить джокеров в игру дурака. 

Мне очень интересно как максимально просто хранить список правил, в каком вормате и максимально легко сгенерировать форму. 
Тоесть чтобы при добавлении новой игры, нужно было только внести ее в базу и добавить список правил. 

Так форма должна меняться?

В принципе, чтобы скрытые поля не передавали данные на сервер, их можно дополнительно disable' ить. Хотя и не понятно чему мешают лишние поля в post'е?

В Yaml есть алиасы и еще какие то навороты, что позволяет единые опции для разных игр определять в конфигурации в одном месте.