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

Считаем бизнес-план для игры в Steam

Заработать миллионы проще простого, сейчас расскажу как :-D

Заработать миллионы проще простого, сейчас расскажу как :-D

Когда выкладывал отчётную презентацию (слайды) по World Builders 2023 (мои посты, сайт), обещал рассказать как делал roadmap и финансовую модель для игры. Выполняю обещание.

К концу поста у нас на руках будут:

  • Краткая стратегия нашей компании: что мы делаем, как, зачем и почему.
  • Табличка наших маяков — успешных игр, которые примерно похожи на то, что мы хотим сделать. Похожи как по геймплею, так и по размеру команды, бюджету, etc.
  • Состав команды, которую нам надо собрать.
  • Roadmap — план разработки нашей игры.
  • Зачатки маркетинговой стратегии.
  • Финансовая модель — сколько мы будем тратить, сколько зарабатывать.
  • Огромное количество моих оговорок по всему посту.
  • Шутки и прибаутки.

Все итоговые документы вы можете найти тут.

Далее

Предпочтения игроков в стратегии

Смотрим на данные опроса и пытаемся найти что-нибудь полезное.

Смотрим на данные опроса и пытаемся найти что-нибудь полезное.

Недавно я делал опрос о предпочтениях игроков в стратегии.

В предыдущем посте мы очищали данные, в этом попробуем чего-нибудь в них найти.

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

Но будьте аккуратны с выводами. Данных мало, а в некоторых случаях совсем мало. Например, разница между размерами выборок мужчин и женщин примерно десятикратная => интерпретировать отличия между ними следует очень осторожно.

В целом, не воспринимайте этот пост как полноценное исследование. Уверен, многие аналитики мне бы руки за такое оторвали. Пришили и снова оторвали. Пользуйтесь постом как интерфейсом к данным, а выводы делайте свои.

Далее

Автоматический генератор квестов

Изначально статья была опубликована на Хабре в 2013 году, но я решил вернуть её в блог. Изменений не делал, поэтому подача может немного отличаться от традиционной.

Несмотря на то, что вопрос автоматической генерации заданий в RPG достаточно древний, общедоступных работающих версий таких генераторов почти нет (скорее совсем нет), если не считать совсем примитивных вариантов. Работ по этой теме тоже не много, хотя, если активно гуглить, кое-что можно откопать. Поэтому надеюсь, что этот текст (и сам генератор, ссылка на репозиторий есть в конце статьи) будет полезен.

Для торопливых: визуализация одного из полученных заданий.

Далее

Feature Programming

Эссе по итогам нырка в Deep Learning, но не о DL и даже не совсем о Machine Learning, а о новой парадигме программирования, которая рождается из него.

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

В следствие выбранной темы, эссе получилось футурологическим и абстрактным. Например, я не буду перечислять области применения DL и достигнутые в них результаты — этим итак всё инфопространство забито.

Оговорка раз: я определённо не эксперт в машинном обучении. Эссе в большей степени отражает мой опыт и картину мира, нежели знания и понимание ML и DL.

Оговорка два: термины «признак», «feature» будут использоваться достаточно вольно.

Далее

Бесконечность схем данных

Программист думает о путях, которыми ходят байты. [Демон сидящий](https://ru.wikipedia.org/wiki/Демон_сидящий) (с) [Врубель](https://ru.wikipedia.org/wiki/Врубель,_Михаил_Александрович)

Программист думает о путях, которыми ходят байты. Демон сидящий (с) Врубель

Расскажу об одной боли при разработке и проектировании ПО — преобразованиях данных между их схемами. Буду говорить о серверах, как наиболее наглядном и знакомом мне примере, но соображения можно распространить на весь софт.

Для демонстрационных целей местами может случиться некоторое преувеличение.

Рассмотрим простейший проект, этакий минимальный набор:

  • один тип клиентов;
  • один сервис;
  • одно хранилище.

Данные, соответственно, ходят в обе стороны:

  • между клиентом и сервисом;
  • между сервисом и хранилищем.

Сколько схем данных вы тут видите?

Далее