Эссе о разработке игр, мышлении и книгах

Julia — это Python++?

Логотип Julia

Давно хотел посмотреть на Julia, так как встречал его (её?) упоминание в очень разных и не всегда относящихся напрямую к программированию местах. Пока изучил только документацию и ничего серьёзного на нём не писал (это будет следующим шагом), но уже хочется сказать пару слов. В соответствии с собственными заветами :-D

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

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

Во-вторых, такие таблицы уже есть.

Поэтому я ограничусь личными впечатлениями и пересказом его идеологии, как я её вижу.

Далее

Процедурная генерация и прочая математика

Открыл для себя доклады, которые Squirrel Eiserloh делал для математической секции GDC. Очень наглядно и доступно рассказывает о процедурной генерации, случайности и прочей математике.

Доклады:

Доклады о процедурной генерации особенно интересны.

Следующий фронтир геймдизайна

Геймдизайнеры в поисках новых механик. Изображение с конкурса Каменный пояс, проекта СССР 2061.

Геймдизайнеры в поисках новых механик. Изображение с конкурса Каменный пояс, проекта СССР 2061.

Геймдизайнеры в поисках новых механик. Изображение с конкурса Каменный пояс, проекта СССР 2061.

Каждый разработчик игр, особенно ММО, со временем начинает рефлексировать и задумываться о таких вещах как «честная игра», «справедливое вознаграждение», «серые и чёрные активности» игроков.

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

Ладно, по первому пункту далеко не все переживают.

Я такой рефлексией тоже занимаюсь довольно давно и наконец смог свести вместе накопившиеся мысли. Причём они на удивление хорошо состыковались друг с другом. Спасибо обсуждению на ММОзговед, в результате которого я перешёл там в read-only режим :-D

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

Далее

О книге «Геймдизайн»

обложка книги «Геймдизайн» Джесси Шелла

«Если вы хотите сделать игру, которая завоюет сердца миллионов и принесёт вам доход, эта книга для вас» — надпись на обложке. Нет. Всё-таки нет. Если вы хотите вот всё это и вообще не понимаете что вокруг происходит, то начать с этой книги будет хорошей идеей, но никаких прорывных идей вы в ней не найдёте.

Джесси Шелл проделал хорошую работу по сбору и переработке информации из множества источников, собрав хорошее «введение в профессию геймдизайнера» и, одновременно, справочник по этой профессии.

Для новичков книга полезна освещением геймдизайна с разных сторон. Но далеко не со всех, например, практике расчёта баланса она не учит.

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

Далее

Уникальные идентификаторы для связи исходников. Как?

Хочу странного, может подскажете способ сделать.

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

Фичей не в смысле больших user-story, а в смысле конкретных пунктов, реализацию которых надо контролировать. Например «имя гильдии должно быть уникально», «Это поле должно отображаться только залогиненому пользователю».

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

Вопрос вот в чём: как делать идентификаторы, которые будут связывать фичи с кодом?

Варианты, которые вижу:

  1. Писать руками. Проблемы: геморрой и простор для ошибок/опечаток.
  2. Плагин для emacs (любого другого редактора), который в файле с фичами генерирует уникальные идентификаторы, после чего копировать их куда надо. Проблемы: его надо сделать, нужно поддерживать уникальность между файлами, хочу фичи не только в отдельном файле, но и в коде, если это будет удобно.
  3. Литературное программирование: писать фичу сразу там, где реализуется. Проблемы: фича реализуется в нескольких местах (код, тесты, вёрстка, документация), поэтому идентификаторы всё равно нужны.
  4. Идентификатором делать сам текст фичи. Проблемы: занимает много места, текст может меняться и будет геморойно менять его везде.