Начало Нового года и неотредактированное архитектурное планирование Адам начинает с необработанной и неотредактированной сессии, посвященной планированию архитектуры для клона Slay the Spire, чтобы начать новый год с чистого листа. Он открыто делится своим творческим процессом, включая спонтанные идеи и неизбежные ошибки. Сессия задумана как ознакомительное путешествие, направленное на то, чтобы попутно получить представление о принципах геймдизайна.
Определение модульной и гибкой кодовой базы Основное внимание уделяется созданию модульной и гибкой кодовой базы. Идея заключается в том, чтобы разбить архитектуру на короткие, управляемые скрипты, которые взаимодействуют через слабо связанные системы. Это гарантирует, что каждый компонент может быть независимо протестирован и обновлен без ущерба для общего дизайна.
Обеспечение масштабируемости и простоты расширения контента Масштабируемая кодовая база имеет решающее значение для простого внедрения новых функций и игрового контента, не вызывая сбоев в работе. В число приоритетов при разработке входит возможность добавления карт, реликвий, врагов и многого другого, сохраняя при этом надежность структуры. Поддержание масштабируемости обеспечивает плавную адаптацию архитектуры к меняющимся требованиям игры.
Пересматриваем правила первого сезона для второго При планировании учитывается, что существующий код первого сезона может не полностью соответствовать новым системным требованиям. Рефакторинг считается необходимым для приведения текущей функциональности в соответствие с будущими игровыми возможностями. Понимание и переработка предыдущей реализации становятся критически важными перед внедрением дополнительных сложностей.
Разработка функционального плана для игры-клона Составлен полный список функций, включая реликвии, магазины, статусные эффекты, создание карт, награды за сражения и многое другое. Эта дорожная карта представляет собой структурированную схему, которая определяет, какие компоненты необходимо разработать. Определение приоритетов этих элементов закладывает основу для последовательной и логичной разработки.
Реализация функций упорядочивания и управление зависимостями Определение порядка реализации функций связано с распознаванием логических зависимостей между системами. Например, статусные эффекты должны предшествовать функциональности relic для обеспечения надлежащего взаимодействия. Такой упорядоченный подход также облегчает независимое тестирование каждой функции перед интеграцией.
Создание главного меню в качестве игрового шлюза Разработка дизайна начинается с создания главного меню, которое служит отправной точкой для запуска новых игр. Это меню не только запускает игру, но и содержит ссылки на основные системы, такие как настройки запуска и сцены сражений. Оно обеспечивает центральный узел, с помощью которого игроки могут управлять игровым процессом.
Разработка многоразового представления стопки карт для управления колодой Режим просмотра колоды карт предназначен для управления и отображения колоды игрока, сбора колоды и сброса колоды. Использование прокручиваемой и адаптивной сетки позволяет использовать неограниченное количество карт. Система создана таким образом, чтобы ее можно было повторно использовать в различных игровых контекстах, обеспечивая согласованность действий пользователей.
Разработка концепции системы запуска для новых сеансов Предполагается, что новая система запуска запустит игровую сессию, дублируя характеристики и ресурсы персонажа. Эта система действует как организатор, объединяя первоначальную настройку с текущим ходом игры. Она обеспечивает плавный переход между различными игровыми контекстами в течение одной сессии.
Интеграция сражений, карт, магазинов и походных костров Архитектурный план предусматривает плавные переходы между сражениями, исследованиями карты, магазинами и мероприятиями у костра. Каждый сегмент спроектирован как отдельный вид, который взаимодействует с общей системой прохождения. Эффективное переключение между этими контекстами жизненно важно для поддержания плавного хода игры.
Разработка стратегии обработки данных для ключевых показателей игры На сессии планирования рассматриваются такие важные данные, как статистика персонажа, количество золота и прогресс в игре. Принимаются решения о том, следует ли хранить эти данные в файлах ресурсов или в узловых структурах для упрощения доступа. Эта стратегия обработки данных является основополагающей для поддержания согласованности состояний в течение длительных игровых сессий.
Внедрение четкой иерархии коммуникаций Создание надежных линий связи между различными системами является главной задачей. Дизайн требует, чтобы управляющая система действовала как посредник, передавая необходимую информацию о сражениях, картах и других компонентах. Четкая иерархия гарантирует, что события и зависимости будут управляться без путаницы.
Баланс между высоким уровнем и детализированными перспективами Такой подход требует переключения между высокоуровневым представлением о взаимодействии систем и расширенным рассмотрением отдельных компонентов. На высоком уровне основное внимание уделяется тому, как различные системы взаимодействуют и влияют на ход игры. Между тем, детальная перспектива оттачивается на таких особенностях, как поведение отдельных реликвий или функциональность элементов пользовательского интерфейса.
Внедрение четырехэтапного процесса проектирования системы Представлен структурированный четырехэтапный процесс: перечисление ключевых функций, анализ потребностей в данных, определение линий связи и потенциальных проблемных точек. Эта методология применяется к каждой системе для обеспечения тщательного планирования и упреждающего решения проблем. Процесс поощряет активное мышление как о функциональности, так и о будущих проблемах.
Разделение пользовательского интерфейса и данных в режиме просмотра стопки карточек Дизайн представления картотеки подчеркивает отделение визуального интерфейса от управления данными. Оно представляет собой автономную сцену пользовательского интерфейса, в которой отображается информация о карточке, полученная из выделенного ресурса. Взаимодействие с другими системами осуществляется с помощью внедрения зависимостей и простой сигнализации для обеспечения плавного взаимодействия с пользователем.
Организация зависимостей в рамках запущенной системы Система запуска предназначена для дублирования характеристик персонажей и управления переходом между несколькими игровыми контекстами. Она выступает в качестве центральной точки коммуникации, внедряя зависимости в батальные сцены, магазины и виды карт. Подход, основанный на узлах, обеспечивает гибкость и гарантирует, что каждая система получит правильные данные в нужное время.
Разбираемся в сложностях интеграции реликвий Реликвии представляют собой серьезную проблему из-за их разнообразных и стойких эффектов на протяжении всего пробега. Они должны быть постоянно видны и поддерживать различное время активации, например, в начале или конце поворотов и во время определенных событий. Эта сложность считается главной архитектурной проблемой, требующей тщательного проектирования.
Устранение ошибок шины событий при системной коммуникации В обсуждении освещаются проблемы, связанные с использованием глобальной шины событий для управления одновременными реликтовыми эффектами и боевыми действиями. Риск непредсказуемого упорядочения сигналов может привести к одновременному выполнению, что может привести к потенциальным конфликтам. Обеспечение надежной последовательности событий становится критической задачей, которую необходимо решить.
Реализация очереди задач для упорядоченного выполнения по очереди Чтобы восстановить контроль над последовательностью событий в битвах, предлагается ввести очередь заданий. Эта система собирает такие задачи, как розыгрыши карт и эффекты реликвий, а затем последовательно обрабатывает их в конце кадра. Очередь заданий позволяет избежать дублирования действий и поддерживать предсказуемый порядок хода.
Размышления об архитектуре, рефакторинге и будущих шагах Сессия завершается размышлениями о балансе между детальным планированием и своевременным продвижением. Признано, что, хотя постоянный рефакторинг позволяет улучшать системы, бесконечная доработка может затормозить разработку игры. В конечном счете, основное внимание по-прежнему уделяется сохранению основных архитектурных принципов, в то же время оставаясь открытым для итеративных улучшений и адаптации.