Следующий фронтир геймдизайна
Геймдизайнеры в поисках новых механик. Изображение с конкурса Каменный пояс, проекта СССР 2061.
Геймдизайнеры в поисках новых механик. Изображение с конкурса Каменный пояс, проекта СССР 2061.
Каждый разработчик игр, особенно ММО, со временем начинает рефлексировать и задумываться о таких вещах как «честная игра», «справедливое вознаграждение», «серые и чёрные активности» игроков.
То есть о том, как не стать капиталистической гадиной, построить здоровое игровое сообщество, не умереть с голоду и дать максимально большому количеству людей возможность получать удовольствие от игры.
Ладно, по первому пункту далеко не все переживают.
Я такой рефлексией тоже занимаюсь довольно давно и наконец смог свести вместе накопившиеся мысли. Причём они на удивление хорошо состыковались друг с другом. Спасибо обсуждению на ММОзговед, в результате которого я перешёл там в read-only режим :-D
В основном я буду вести речь в контексте ММО, но считаю, что сказанное можно распространять на игры в целом.
Софт для «поддержки принятия решений»
Обновлено: исходники проекта открыты — https://github.com/Tiendil/morphologic
В марте я писал в фейсбуке про софт для «поддержки принятия решений». О том, что не могу найти ничего подходящего.
В итоге я решил, что если гора не идёт к Магомету, то Магомет пишет необходимый софт сам.
На текущий момент у меня есть рабочий прототип, который очень надо проверить на людях.
Софт может пригодиться, если вам необходимо найти решение / выбрать архитектуру / определить лучшее сочетание параметров в сложной и / или слабо формализированной области.Например, вы знаете, что решение может обладать свойствами A, B, C, D, … Z, но не знаете какое сочетание свойств будет оптимальным. При том, что A и D несовместимы, а сочетание свойств B+X+Y выглядит лучше, чем P+Q.
В этом случае вы можете ввести список свойств, ограничения, и поэкспериментировать, меняя правила подбора и оценки решений.
По сути, софт помогает делать полный перебор всех вариантов решений с ограничениями.
На странице софта есть более подробноее описание и инструкция.
Посмотрите пожалуйста. В основном на предмет полезности для вас лично и идей в какую сторону двигать разработку.
Прототип:: https://tiendil.github.io/morphologic/
Группа в телеграм для обсуждения: https://t.me/morphologic_soft
Генерация подземелий — от простого к сложному
Что у нас должно получиться.
В этом уроке рассказывается, как запрограммировать подземелье. Если вы не программист, вам будет интересно почитать как придумать подземелье.
Несколько вечеров проверял идею генерации космических баз. Космическая база в итоге не получилась, а вот на добротное подземелье результат похож. Поскольку шёл от простого к сложному и никакой суровой магии не делал, то решил переработать код в урок по генерации подземелий на Python.
В итоге у нас получится генератор подземелий со следующими свойствами:
- Комнаты будут соединены коридорами.
- Топологически подземелье будет иметь форму дерева. Добавить циклы будет элементарно, но уже в качестве домашнего задания.
- Будет настраиваться количество комнат, их размер, «уровень ветвления».
- Подземелье будет располагаться на клеточной сетке (состоять из квадратных клеток).
Весь код можно найти на github.
Кода в посте не будет — все используемые подходы легко описываются словами.
Для каждого этапа разработки в репозитории будет создан отдельный тэг, содержащий код на момент завершения этапа.
Задача этого урока не столько научить программировать генераторы подземелий, сколько показать, что кажущиеся сложными вещи на деле довольно просты, если их правильно разбить на подзадачи.
Как я делал и делал бы поддержку GDPR
Удалось столкнуться с этой штукой в момент её появления и в авральном режиме впилить в крупную мобильную игру. Поскольку делать эту функциональность мне явно придётся ещё не раз, а также потому, что иногда спрашивают про неё запишу тут свои мысли о практической реализации поддержки этого закона.
Без юридических тонкостей, так как они не моя специальность, могу насоветовать не того. В целом, с подозрением относитесь к любым не программистским утверждениям в этом тексте, их надо перепроверять!
Про GUI я тут тоже говорить не буду.
Этот текст не отражает ни конкретную реализацию, ни идеальную, а является скорее собранием накопившегося опыта и мыслей.
Уникальные идентификаторы для связи исходников. Как?
Хочу странного, может подскажете способ сделать.
Итак, хочу вести список фичей (в репозитории, рядом с исходниками) и когда пишу логику (тесты, документацию, вёрстку) иметь возможность поставить какой-то идентификатор рядом с реализацией (тестом, документацией, вёрсткой). Дескать вот тут реализуется (тестируется, документируется, отображается) именно эта фича. И потом по этим кроссылками генерировать всякую полезную аналитику.
Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».
Фактически я уже так работаю, записывая каждую мелкую фичу в туду-листе и удаляя их по факту реализации. Не хочется, чтобы знания терялись. Логичный следующий шаг — хранить историю фичей и их реализации.
Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?
Варианты, которые вижу:
- Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
- Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
- Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
- Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.