Перейти к содержанию

Методология разработки игр


Рекомендуемые сообщения

Этот урок посвящен теме производственного процесса разработки игры. Как часто вы ощущаете себя в ситуации, когда в вашей голове десятки идей, но вы не знаете, с чего лучше всего начать и что делать в первую очередь. Начать с самого сложного? Или с самого лёгкого? Сделать сразу уникальную механику или оставить её на потом?

Вы делаете то одно, то другое, результат часто оказывается не таким, каким вы его себе представляли, вас это расстраивает и вы забрасываете разработку игры. Знакомое ощущение? Если да, то этот урок для вас!

КОНЦЕПЦИЯ ЗАВИСИМОСТЕЙ

Ключ к решению проблемы заключается в понимании концепции зависимостей.

Цитата

ЗАВИСИМОСТЬ – это такое отношение между двумя частями проекта, когда изменения в одной части вызывают изменения в другой.

Представьте что вы композитор и вас попросили написать 10 музыкальных тем для разных уровней. В этой задаче нет зависимостей. Нет разницы, в каком порядке вы будете писать музыку, потому что в каждом случае это никак не влияет на то, как вы будете писать музыку для других уровней.

В геймдизайне всё иначе. Игровые механики часто взаимосвязаны между собой. Например, вы потратили 2 часа своего времени на создание механики стрельбы из лука для платформера. Вы добавили лук в анимацию героя, сделали спаун стрелы, кровь при попадании стрелы во врага, отнимание здоровья у врага, отлетающие цифры урона и т.д.

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

Так что же делать?! Изменять уже готовые уровни (что, в свою очередь, несёт риск испортить хорошую работу, гарантирует вам геморой, но не гарантирует что игра станет от этих изменений лучше) или выбросить в мусор несколько часов работы над механикой стрельбы? Если бы мы лучше понимали зависимости, мы могли бы сначала проверить механику стрельбы в «сером ящике», а потом уже делать анимацию (и всё остальное).

КОНЦЕПЦИЯ «СЕРОГО ЯЩИКА»

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

Редко когда механики работают именно так, как задумано. Самый сильный враг может скатываться в простую, дегенеративную стратегию. Игрок может пропустить душещипательный диалог, потому что хочет поскорее закончить уровень. Он не понимает простейшей механики, но легко осваивает самую сложную. Он использует только два типа оружия из десяти возможных. Примеры можно продолжать до бесконечности.

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

Глупо добавлять в игру графику, сложные эффекты и анимации только для того, чтобы во время тестирования выяснилось, что механика скучная и не увлекательная. Чтобы избежать этого, вы можете протестировать игру методом «серого ящика».

Цитата

«СЕРЫЙ ЯЩИК» – это черновой прототип игровой механики, системы или уровня.

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

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

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

КОНЦЕПЦИЯ ИТЕРАЦИЙ

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

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

Цитата

ИТЕРАЦИЯ – это практика составления краткосрочных планов, их реализации, тестирования и повторения.

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

Итерация осуществляется не только для всей игры сразу. Мы можем применять её для отдельного уровня, механики или интерфейса.

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

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

Одним из наиболее эффективных методов разработки игр является "наращивание" путём пошаговой разработки. Сначала игру нужно просто заставить работать, даже если в ней нет ничего особенного. Затем игра понемногу обрастает мясом. В первую очередь делаем базовые механики и с каждой последующей итеррацией опускаемся всё ниже и ниже в паутине зависимостей (изменения в одном месте почти всегда подразумевают много изменений в другом месте).

***

На этом пока всё. Если урок оказался вам полезным — пишите свои мысли, идеи и вопросы. Тема интересная и большая, здесь есть много чего обсудить.

Ссылка на комментарий
Поделиться на другие сайты

в сети

Ну как-то много воды, а о самих моделях как-то мало информации, плюс названия не соответствуют. Демонстрации, а также и иллюстрации отличий нет. Уже все придумано по методологии разработки ПО, нужно только обертку в виде применения в РИ сделать.

https://habr.com/ru/company/edison/blog/269789/
вот хорошая статья. очень хорошо проиллюстрирована разница между итерационной и инкрементной моделью

Сейчас очень популярна Agile модель и должность SCRUM мастера за рубежом и иногда появляется вакансия в РФ (мск, спб)

Не зашло. Все то же самое можно было уместить и в один абзац. Sailer, кстати, описывал кратко модель на том форуме (в 1 абзац). Но кто как не обзывает затронутую модель...

Изменено пользователем Aventiy
Ссылка на комментарий
Поделиться на другие сайты

1 час назад, Aventiy сказал:

Ну как-то много воды, а о самих моделях как-то мало информации, плюс названия не соответствуют. Демонстрации, а также и иллюстрации отличий нет. Уже все придумано по методологии разработки ПО, нужно только обертку в виде применения в РИ сделать.

https://habr.com/ru/company/edison/blog/269789/
вот хорошая статья. очень хорошо проиллюстрирована разница между итерационной и инкрементной моделью

Сейчас очень популярна Agile модель и должность SCRUM мастера за рубежом и иногда появляется вакансия в РФ (мск, спб)

Не зашло. Все то же самое можно было уместить и в один абзац. Sailer, кстати, описывал кратко модель на том форуме (в 1 абзац). Но кто как не обзывает затронутую модель...

У меня не было цели описывать сухую теорию из учебника по прожект менеджменту. Цель была в том, чтобы показать, как оно бывает в реальной жизни. С какими реальными проблемами столкнётся каждый разработчик и какие есть возможные пути их решения. Нужно понимать, что разработке игр нельзя научиться по учебнику — нужен опыт (свой или чужой). Этот урок просто даёт понимание, куда смотреть и на что нужно обращать внимание.

А как лично вы справляетесь с трудностями в разработке? Или у вас их не бывает?! Какие практики лично вам помогают доводить ваши игры до релиза?

Ссылка на комментарий
Поделиться на другие сайты

У меня абсолютно нубский вопрос. Вот на форуме (как минимум на старом) есть народ с играми и на стиме и с не слабым количеством установок на ГП и фрилансеры на заказах крупных игровых вебпорталов. Кто из вас уделяет внимание всем этим концепциям итерациям итд?

Я конечно понимаю что в геймдев студиях где есть бюджет, менеджеры и стаф работников это все мега важно, а может и важно одиноким инди разрабам я хз 😳

Изменено пользователем Nagval333
Ссылка на комментарий
Поделиться на другие сайты

1 час назад, Nagval333 сказал:

Кто из вас уделяет внимание всем этим концепциям итерациям итд?

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

з.ы.  пролил кофе на клаву,       теперь пробел залипает)))

Зри в корень

Ссылка на комментарий
Поделиться на другие сайты

в сети

@Nagval333 смотря какая задача стоит и какие условия работы

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

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

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

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

это уже если в команде человек 5 и выше постоянно работающих над проектом (не аутсорс) и тем более если роли одинаковые есть (2 прогера, 2 худа, 1 разнораб, например). и соотвественно тут уже надо распределять задачи так, чтобы процесс разработки не увеличился из-за объема штата.

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

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

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

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

Изменено пользователем Aventiy
Ссылка на комментарий
Поделиться на другие сайты

Ок, спасибо за ответы. Я это приблизительно понимаю.

Просто хотелось знать кто из форумчан (нового и старого форума) использует данные фишки. Особенно те у кого уже есть успешные проекты. Но кажется мне народ здесь пилит игры как попало, ну максимум строит диздок с набросками...

 

Я сам в свободное время пилю свои маленькие игрульки как попало иногда вобще без общей картины или понимания конечной цели, начинаю что-то потом откладываю начинаю новое и так по сто раз и не какие статьи процесса разработки игр мне так и не помогли  😅

Изменено пользователем Nagval333
Ссылка на комментарий
Поделиться на другие сайты

42 минуты назад, Nagval333 сказал:

начинаю что-то потом откладываю начинаю новое и так по сто раз и не какие статьи процесса разработки игр мне так и не помогли

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

Ссылка на комментарий
Поделиться на другие сайты

в сети

четыре стадии усвоения новых знаний
img5.jpg
далеко не каждый из нас (РИ) может их в полной мере освоить, так как нужна полноценная управленческая деятельность

Изменено пользователем Aventiy
Ссылка на комментарий
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   0 пользователей онлайн

    • Ни одного зарегистрированного пользователя не просматривает данную страницу
×
×
  • Создать...