Однажды мне попалась на глаза статья про сотрудника, который реализовал в Excel книге полноценную игру с интерфейсом, противниками и другими механиками. Продолжив изучать эту тему, я увидел целый мир, в котором люди, используя не предназначенные для этого продукты, реализуют различные игровые механики. Эта мысль попала мне в голову, и после этого мне всегда хотелось самому реализовать нечто подобное.

Не так давно на работе ко мне пришли с предложением подготовиться и сдать на сертификат разработчика по продукту «Форсайт. Аналитическая платформа». Простое чтение документации дало первоначальное понимание о возможностях платформы, и нужно было применить полученные знания на практике. Особенно меня зацепил конструктор собственных форм на языке Fore, который напомнил о студенчестве и Visual C#.

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

Осталось только выбрать игру.

Выбор игры

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

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

Ход проекта

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

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

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

Ниже в статье будет ссылка на мой репозиторий с кодом – буду ждать ваших пул-реквестов по оптимизации.

Описание логики

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

Немного скриншотов самой игры - как у лучших издателей
Немного скриншотов самой игры - как у лучших издателей


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

Логика построения игры такова:

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

  • Каждый тайл знает, является ли он миной или нет. Также знает, в каком ряду и колонке он находится.

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

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

  1. Срабатывает событие OnClick на выбранном тайле.

  2. Если тайл - бомба, то посылается команда главной форме окончания игры.

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

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

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

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

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

А теперь в процессе создания игры «Сапер» можно познакомиться и с основным синтаксисом встроенного языка Fore, набить руку в написании кода и узнать, как работают более сложные концепции - ООП, динамическое создание элементов, научиться работать с утечками памяти.

Результаты

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

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

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

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

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

Максим Бритвин

Старший консультант-разработчик департамента ЕРМ в «КОРУС Консалтинг»

Комментарии (5)


  1. niktor_mpt
    13.04.2024 15:50
    +1

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

    Конечно.

    Вопрос тип игры: соревнование, конкуренция или противостояние?

    Если первое, то банально у каждого своё поле, одинаковые условия, каждому виден прогресс каждого. Оценка кто кого обогнал и насколько может быть самая разная.

    Конкурентная - общее поле, гарантия равномерного распределения, дальше кто больше флажков поставил. Можно делать подлянки, ставить флажок там, где мины нет :). Система баллов усложняется, но вполне очевидна.

    Противостояние - каждый снимает мины и ставит уже для противника мины. Быстрее снимаешь - больше мин можешь поставить. Поставил мину - часть область вокруг неё закрывается. Тут уже вообще вынос мозга, потому что надо переключаться с одной тактики на другую. :)

    В общем, ничего сложного, на мой взгляд. Разбираю такого рода задачи со студентами как приёмы мышления. Для разминки :)


    1. DarkwingDuck48 Автор
      13.04.2024 15:50

      Спасибо за комментарий! Но вопрос был не столько о типе игры, сколько о реализации взаимодействия между пользователями так, как это сделано в многопользовательских играх. . Возможно ли создать в EPM системах такой же способ взаимодействия между пользователями, как в многопользовательских играх? То есть, сделать так, чтобы несколько игроков могли бы в реальном времени видеть одно и то же поле и взаимодействовать с ним так, чтобы это было видно другим игрокам.


  1. shuraknows
    13.04.2024 15:50

    Спасибо что поделились опытом, но хочу отметить что сам термин геймификация означает немного другое, например внедрение игровых механизмов в какой-нибудь не игровой процесс. Например: "создал 10 отчетов - получил медаль `мастер отчетов`" и т.д. Сама по себе игра сапер не способствует повышению вовлеченности в работу.


    1. DarkwingDuck48 Автор
      13.04.2024 15:50
      +1

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

      Как например у меня - моей задачей было подготовиться к сертификации на разработчика. Получить какую то медальку или стать первым, кто сдаст на сертификат мотивация была не слишком прочная. А вот в рабочее время написать собственную игру, пусть маленькую - вот это меня мотивировало и к прочтению документации и к поиску дополнительных источников информации, когда документации не хватало.


  1. sashabort
    13.04.2024 15:50

    Осталось тоже самое проделать на Web-форме в 10 версии:)