Сама проверка механики необязательно должна выливаться в написание кода. Мы можем проверить ее, например, в виде настольной игры. Особенно если нашей задачей является проверка того, насколько механика интересна, а не какова возможность ее реализации. Такая настольная игра может быть сделана буквально «на коленке»: можно взять бумагу из тетради или принтера, нарисовать карту, вырезать карточки действий и персонажей. Генератор случайных чисел в виде игрального кубика можно взять из другой настольной игры или найти в интернете.
Например, мы работаем над игрой о мусороперерабатывающей фабрике. Мы можем создать карту с рабочими местами, на которых расставим персонажей. Одни персонажи лучше сортируют, другие лучше управляются с техникой. Каждый цикл мусор, находящийся на фабрике, перемещается от одного персонажа к другому, и на фабрику прибывают новые грузовики с мусором. Если игрок правильно расставил персонажей, то мусор будет перерабатываться эффективно и не будет накапливаться. Если к концу раунда на фабрике останется не отсортированный мусор, можем считать это проигрышем, хотя это совершенно не важно. Ведь на этом этапе мы проверяем интересность самого игрового процесса, а не придуманные на скорую руку правила и баланс.
Итак, нам нужно немножко поработать руками.
• Так как фабрика, по сути, разделена на отдельные зоны, в которых работают отдельные персонажи, эти зоны у нас будут изображать листы бумаги с названиями зон. Пока зон у нас будет две: зона разгрузки и зона сортировки.
• У нас будет набор карточек с персонажами с разными случайными характеристиками. Карточки мы вырежем из той же бумаги, напишем на них имена персонажей, нарисуем портреты и распишем характеристики. Кому-то достанется +2 на сортировку стекла, кому-то +5 на управление погрузчиком и т. п. Мы можем сделать с десяток таких карточек и ограничим игрока правилом, что из персонажей он может взять только троих случайных. Двух можно поставить в зону сортировки, а одного на разгрузку.
• Мусор у нас будет в виде фишек – клочков бумаги с разными обозначениями: С – стекло, Б – бумага и т. п. Таких фишек нам нужно штук 50.
Дальше идет сам игровой процесс.
• Вначале игрок кидает игральный шестигранный кубик, чтобы узнать, сколько мусора придет ему на фабрику в начале хода. Соответствующее выпавшему числу количество мусора нужно взять из мешка с мусором случайным образом. Мусор попадает в зону разгрузки, при этом он должен оставаться скрытым для игрока, а значит, лежать «рубашкой» вверх.
– Скрытость мусора – это довольно важное уточнение, о котором мы могли не подумать с первого раза. Если мы случайно нарисуем обозначение мусора на обеих сторонах фишки, то нам придется их переделывать. Это маленький урок итеративности.
• Отвечающий за разгрузку персонаж должен переправить мусор из зоны разгрузки в зону сортировки. Перевезти персонаж может столько мусора, сколько очков управления погрузчиком у него есть. Пока мусор скрыт, игрок может взять любые фишки мусора и переложить их в зону сортировки.
– Уже здесь можно немного задуматься над балансом игры. Игроку в начале хода может прийти и одна единица мусора, и шесть. Иногда игроку будет приходить меньше мусора, чем он может перевезти, а иногда больше. Тогда мусор начнет накапливаться в зоне разгрузки. В среднем d6 будет давать значение 3,5. Соответственно ставить на разгрузку персонажа с навыком меньше 4 довольно рискованно.
• В зоне сортировки мусор можно раскрыть и перевернуть. Сортировщики работают примерно по тому же принципу, что и погрузчик: игрок может переместить столько мусора, сколько очков есть у персонажей, находящихся в зоне сортировки. Если у нас есть два персонажа: на 2 очка стекла и 3 очка стекла – значит, суммарно за ход игрок может отсортировать 5 единиц стекла.
На этом этапе еще нет никакой объективной оценки интересности. Эту настольную игру мы можем показать в лучшем случае коллегам. Но мы уже можем начать работать с отзывами. Немного поправить правила, изменить количество типов мусора, количество персонажей. Исправить ошибку с забытым правилом, что на разгрузку мусор должен попадать скрытым от игрока. Этап разработки прототипа даже отдельной механики так же итеративен, как и весь процесс разработки игры как программного продукта:
• создаем новую версию;
• тестируем;
• получаем отклик;