Ключевые роли в инди-разработке текстовых игр

В нашей жизни очень многое зависит от отношения к деятельности. Если автор относится к разработке как этакий художник, мол “я создал произведение искусства”, “у меня такое видение”, то ничего не поможет стать лучше. Человек закрыт для критики. Он может меняться, только с черепашьей скоростью, после выпуска игры и множества отзывов. Похожий случай, когда кто-то работает “для себя” или “в стол”. Для меня одна из форм самообмана. Никто из создателей игр не создает их для себя, это всегда продукт для определённой аудитории. Если у вас отношение к игре, как к продукту, то шансы на успех заметно повышаются. Начнём хотя бы с того, что появляется цель, появляются требования к игре, какие-то границы. Как только вы решили серьёзно заняться разработкой, то надо осознать, что в одиночку проект хорошего качества за ограниченное время создать не удастся. Я считаю, что помогать автору должны хотя бы два человека — внешний тестировщик и внутренний. Внутренний тестировщик работает в команде с автором на ранних этапах, проверяет идеи и первые версии игры. Внешний проверяет уже предрелизную версию.
Задача у внутреннего тестировщика более трудная. Он не только проверяет сырые варианты, он ещё должен поддерживать огонь творчества, а не гасить его. Внешних тестеров можно взять побольше, хватит и 3-4. Часто они проверяют версию один раз и их глаз не замылен изначальной концепцией игры. Для своих игр я периодически пользуюсь услугами бета-ридеров для улучшения текста. Ну нет у меня врождённой грамотности.
Ещё один подход, возможно более продвинутый — парная разработка, когда два автора параллельно делают игры и являются внутренними тестерами друг для друга. Товарищи, что вы думаете про парное созидание? Кстати, если хотите, чтобы я протестировал вашу текстовую игру, то пишите, не стесняйтесь!

2 comments on “Ключевые роли в инди-разработке текстовых игр

  1. -

    Главная проблема не в том, чтоб набрать тестеров (заходи на форум или чат — там всегда много желающих), а что с ними делать. Сколько контекста давать («а вот эта часть будет переделываться, сюда не смотрим»), как расшифровывать отчёты и транскрипты, что делать если тестировщик где-то застрял или бросил игру на первом экране (для некоторых это «объявить что он не умеет играть и вообще это не его жанр»). Вот бы что-то такое обсудить, а не ловлю опечаток.

  2. - Post author

    Ну, не знаю. У меня как-то таких проблем не было. Со «своим» тестером можно детально обсудить что тестировать, а что нет. При этом он является практически соавтором, ну или первопроходцем. Надо его только найти 🙂 Другим тестировщикам можно давать релизы с четкими целями: попробуй дойти до конца или прочитай главное историю, вот тебе чит-коды. К ним не попадает сырой продукт.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *