Как мы разрабатываем игры для пиксельного пола, публикуем исходники и делимся частью выручки⁠⁠

Программисты и игроделы, привет! Полгода назад я писал про наш путь к открытию первой пиксельной игровой. Сегодня хочу рассказать, как мы решили проблему разработки игр путём перехода с Go на Lua и публикации исходников, а также о планах делиться частью выручки со сторонними разработчиками.

Проблематика и поиск решения

Мой основной язык разработки – Go, соответственно он и был выбран для разработки сайд-проекта, а значит и все игры для проекта изначально тоже были написаны на нём. Но ровно в тот момент, когда сайд-проект превратился в тыкву самостоятельный бизнес, встал вопрос целесообразности использования Go для написания игровых механик. Сам по себе язык отличный и прекрасно справляется со своей задачей, но хотелось упростить процесс найма людей для разработки игр, и в воздухе маячила идея открытия свободного доступа сторонним разработчикам.

Нужна была удобная платформа для разработки, а т.к Go – язык компилируемый, то было сложно сделать стенд для тестирования кода, не предоставляя доступ к исходникам игрового контроллера. Поиск решения привёл меня к идее использовать скриптовый язык Lua.

Как оказалось, язык Lua – очень простотой в изучении и использовании, но в то же время один из самых быстрых и производительных скриптовых языков программирования! Де-факто он является стандартом в игровой индустрии и используется, например, в таких играх, как World of Warcraft, Roblox, Minecraft и Angry Birds.

Для интерпретации Lua скриптов на Go есть неплохая виртуальная машина GopherLua. По производительности она сравнима с Python версией, но, конечно, уступает нативной реализации на C. Но нам не космолёт строить, логика игр часто весьма простая, и в крайнем случае сложные вычисления можно будет вынести обратно на сторону Go.

Интегрировать машину в существующий Go код оказалось весьма просто и заняло буквально пару дней. Она позволяет как выполнять Lua код из Go, так и вызывать Go код из Lua. Я был приятно поражён гибкостью такого решения и очень пожалел, что откладывал момент интеграции так долго.

Структура игры

Для управления игрой я выделил 11 обязательных методов (я ни разу не игродел, соответственно буду рад обсудить ваши варианты):

• StartGame(gameJson, configJson) – старт игры. Тут декодируем игровой и конфиг json для инициализации игры и её стартового состояния;

• NextTick() – тик игрового мира, здесь обычно описана вся основная логика. В текущих реалиях вызывается ПРИМЕРНО каждые ~35мс (28 кадров в секунду), но ориентироваться на время периода нельзя, вместо этого нужно использовать абсолютное время. Не вызывается, когда игра на паузе или завершена;

• RangeFloor(setPixel, setButton) – опрос снапшота пола, вызывается в тот же игровой тик следом за NextTick(), чтобы забрать состояние пола для отрисовки;

• GetStats() – забор статистики игры, вызывается сразу за RangeFloor() для получения информации для отрисовки игрового табло;

• PauseGame() – событие паузы игры;

• ResumeGame() – событие снятия игры с паузы;

• SwitchStage() – дополнительный рычаг админу для переключения этапа, может быть полезен в некоторых играх;

• PixelClick(click) – событие клика/отпускания пикселя;

• ButtonClick(click) – событие клика/отпускания кнопки;

• DefectPixel(defect) – событие дефектовки/раздефектовки пикселя;

• DefectButton(defect) – событие дефектовки/радефектовки кнопки;

Нас тут коллеги из Испании спрашивали: а как вы делаете так, чтобы не отправлять людей домой в случаях, когда что-то сломалось?

Отвечаем: у нас есть механизм дефектовки – это когда пиксель/кнопка, не реагирующие на нажатие, выводятся из игры и не блокируют игровой процесс. Чаще всего цвета они отображать могут, а нажиматься – уже нет. Таким образом, ни в одной игре на такие пиксели или кнопки больше не будет назначено задание и игроки в большинстве своём даже не замечают, что с полом что-то не так.
Иногда картина выглядит, прямо скажем, очень печально, особенно после нагруженных выходных дней, когда времени на ремонт/замены совсем нет:

Но мы работаем над качеством: в новой версии весовые датчики будут вдвое мощнее, а кнопки станут емкостными без физического нажатия.

После определения основных методов управления игрой мы переписали несколько наших ранее реализованных простых игр с Go на Lua. Исходный код можно посмотреть в репозитории github.com/pixel-quest/pixel-games, там же есть идеи некоторых игр в очереди на разработку + скромная Wiki с документацией.

Жизнеспособность идеи была подтверждена, игры работали как надо. И даже управление аудиоплеером удалось прокинуть в Lua без особых проблем. Оставалось дело за малым – удобной платформой для тестирования скриптов.

Платформа для разработки

Хотелось иметь онлайн платформу, в которой можно писать код игры и тут же запускать его на виртуальном пиксельном полу для тестирования. За основу был взят наш существующий админ-интерфейс, написанный на Vue. Я его сильно урезал в части функционала управления электроникой, оставил только виртуальный пол и прикрутил навороченный текстовый редактор в виде VS Code.

Для обеспечения прозрачного механизма отладки я сделал на вебсокетах проброс ошибок в виде всплывающих нотификаций и добавил возможность вывода в Lua коде дебаг сообщений log.print() прямо в консоль разработчика в браузере. Также есть валидация json при сохранении конфигов.

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

Так как я опасаюсь лавинной нагрузки, с которой может не справиться мой говнокод дешевый VPS, я пока что не готов выкладывать прямую ссылку на ресурс, но я готов буду выдать доступ всем заинтересованным при личном обращении в специальном телеграм чате: @pixel_quest_games

План развития

Эта статья является своего рода проверкой интереса сторонних разработчиков к нашей платформе. Сейчас мы напрямую платим фрилансерам за разработку, но в перспективе мы готовы выделять процент от выручки (в том числе всех будущих франчайзи) на выплаты авторам новых игр. Также рассматриваем идею создания портала, где каждый сможет выгружать свои игры и в реальном времени видеть статистику запусков и сумму вознаграждения. Можно даже онлайн камеры подключить, как у ДоДо. Но даже сейчас, если написанная вами игра окажется популярной, то мы в частном порядке придумаем, как платить вам роялти с каждого запуска! Огромных доходов здесь и сейчас не обещаю, но в перспективе пары-тройки лет это может оказаться весьма выгодной инвестицией вашего сегодняшнего времени: у нас весьма амбициозные планы на рост партнерской сети, и вы сможете получать вознаграждение с каждой из будущих локаций сети, где будет запущена ваша игра. Уже сейчас мы готовим к открытию 5 новых городов, в т.ч один за пределами РФ…

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

Заключение

Буду рад конструктивной критике в комментариях, а также вашим идеям для новых игр!

Кому интересно следить за развитием проекта Pixel Quest, подписывайтесь на наш телеграм канал @pixel_quest. Я пишу там исключительно сам и не чаще одного раза в 4-7 дней, маркетологов выгнал, больше планирую рассказывать про техническую составляющую проекта с постепенным уклоном в IT, плюс ежемесячно публикую финансовые отчёты.