Геймификация в EPM системах: фан или крутая фича? Разбираем на примере Форсайт

Лет 20 назад я впервые сел за компьютер. Там стояла Windows 98 и мне, как и любому ребенку, сразу хотелось поиграть на нем. И была одна игра, которая мне не давалась, от слова совсем, - «Сапер».

Позже, когда я разобрался в механике игры, она уже не казалась такой сложной, но тогда это был вызов. И память об этом настолько долго хранилась в моей голове, что вариантов, какую игру реализовать, просто не было - я хотел написать свой «Сапер». Тем более что сейчас в стандартных версия Windows уже даже игр нет, а иногда хочется и отдохнуть немного ностальгически.

Изобретать велосипед не хотелось, поэтому первым делом я начал искать реализацию игры на других языках, которые мне были бы ближе всего. Недолгий поиск привел меня на курс видео по созданию «Сапера» на языке Python, так что референс был найден и можно было приступать к адаптации логики на Fore.

Сразу уточню, что код игры скорее всего далек от оптимального, и сейчас многие вещи можно было бы сделать по-другому, возможно, даже проще. Но главной целью этого проекта было обучение разработке форм, взаимодействию между различными объектами на форме и прощупывание границ возможностей кастомизации.

Например, сейчас каждая клетка в игре – это отдельный класс, унаследованный от базового класса кнопки, в котором я переопределил и добавил свои методы (это, кстати, тоже было сделано ради тестирования возможностей). Далее, когда уже начал тестировать игру, оказалось, что при наличии 100 кнопок на одной форме есть замедление при обновлении поля. Тут, возможно, сказываются какие-то мои неоптимальные решения при проектировании.

В этой статье я не буду подробно останавливаться на механиках «Сапер». Весь код, который позволит добавить игру в Форсайт, доступен в репозитории GitHub.  

Я не стал усложнять пример использованием Python или Java (хотя мы можем использовать модули на этих языках в расчетах), все полностью написано на языке платформы - Fore.

1. Есть главная форма, которую пользователь видит на экране. Когда форма запускается, то на форме расставляются мины, и создается поле из тайлов. Каждый тайл — это одна кнопка, на которую игрок может нажать.
2. Каждый тайл знает, является ли он миной или нет. Также знает, в каком ряду и колонке он находится.

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

Поэтому при нажатии на тайл происходит следующее:

1. Срабатывает событие OnClick на выбранном тайле.
2. Если тайл - бомба, то посылается команда главной форме окончания игры.
3. Если тайл не бомба - то посылается команда главной форме, чтобы посчитать количество бомб на соседних клетках и показать пользователю их количество.

Зачем вообще реализовывать игры в продуктах, которые для этого не предназначены

Но зачем это делать? Есть программные продукты, которые предназначены для разработки игр, а есть серьезные аналитические платформы, которые не предназначены. Ответов тут несколько.

1. Пытаясь решить нестандартную для платформы задачу, мы тестируем ее на гибкость к требованиям заказчика и на пределы наших возможностей. Сколько времени у нас займет решение нестандартной задачи? Сможем ли мы найти ответы на нестандартные вопросы в документации, в справке, на форумах? В итоге, мы, как интеграторы и разработчики, можем предлагать нашим клиентам оптимальные решения задач, и понимаем насколько та или иная боль клиента может быть решена с помощью платформы.
2. Обучение. В игровой форме учиться гораздо легче, и игры появились не просто так. На примере Windows, все стандартные игры, которые шли вместе с операционной системой, обучали пользователей базовым вещам - работе с мышью, которая в то время была новинкой. Наш «Сапер» изначально нужен был для обучения пользователей работе с правой и левой кнопками на мыши (Пруф).

Лично мне данный проект позволил подготовится к сдаче сертификата разработчика без скучного чтения документации, а с практической пользой. Кроме того, стало понятно, что многие базовые вещи в языке можно будет изменить и настроить так, как нужно под конкретную задачу.

Одной из самых ключевых штук для понимания стал механизм взаимодействия между двумя объектами на форме, как вызвать тот или иной метод, как между ними можно передавать данные.

И теперь мы знаем, что, если нашему клиенту нужно будет реализовать особенный бизнес-процесс, то мы сможем корректно оценить и возможности платформы, и время, которое будет затрачено на реализацию.

По доработке этого проекта осталась масса нереализованных идей, как с дополнительными механиками по установке флажков на «подозрительные» тайлы, так и с доской почета с лучшим игроками или достижениями.

После этого проекта у меня в голове остался только один вопрос: если можно сделать игру одиночную – можно ли сделать многопользовательскую?