CocosCreator: быстрый старт в разработке лёгких игр
Описание проекта
Данный проект основан на Cocos Creator версии 3.7.2 и представляет собой пример игры, основанной на Asset Bundle, который включает в себя лобби и мини-игры. Проект предлагает лёгкую игровую среду разработки, упрощающую процесс создания игр.
Адрес примера
Пример установочного пакета можно найти в группе.
Примечание: конфигурация сервера низкая, поэтому при входе может потребоваться некоторое время.
Обновление Cocos Creator
Плагины для исправления движка можно использовать для версий от 3.7.2 до 3.8.4. В примере проекта можно самостоятельно настроить обрезку под свой проект.
Шаги обновления:
- После обновления используйте плагин «Исправление движка» один раз.
- Перестройте проект.
Получение полного проекта
Перейдите в каталог tools и выполните команду npm install для установки зависимостей. Затем в каталоге tools выполните команду npm run main.
Подробные документы
Более подробные документы доступны в разделе doc этого проекта. Из-за личных обстоятельств документы находятся в процессе завершения. Также приглашаем присоединиться к нашему дискуссионному каналу для обмена опытом и совместной работы над улучшением Cocos Creator.
О QuickFramework
Вопросы и ответы
Q: Почему используется один сценарий?
-
Ответ: Это обеспечивает нормальное всплытие представлений при переключении между сценами. Например, если есть две сцены A и B, и в сцене A запрашиваются сетевые данные, которые должны отображаться в сцене B, то после получения ответа от сети необходимо проверить, находится ли пользователь в сцене B. Если нет, то данные помещаются в очередь отображения и отображаются, когда пользователь переходит в сцену B. Однако, если используется одна сцена, не нужно беспокоиться о том, в какой сцене находится пользователь, и данные могут быть отображены сразу после получения ответа.
-
Ответ: Это также защищает состояние интерфейса. При переключении сцен все представления в текущей сцене будут закрыты, а данные очищены. Но если некоторые представления должны быть сохранены в предыдущей сцене, это потребует дополнительной работы по сохранению состояния интерфейса перед переключением сцен и восстановлению его после переключения. Использование одной сцены позволяет избежать этой проблемы, так как переключение сцен просто скрывает и отображает представления без необходимости сохранения их состояния.
Q: Почему не рекомендуется использовать скрипты непосредственно в предустановленных объектах?
-
Ответ: Это облегчает рефакторинг. Если вы обнаружите, что структура каталогов или имена файлов выбраны неправильно, но уже много компонентов было добавлено в предустановленные объекты, некоторые проекты могут иметь разные версии SVN для разных частей игры. Во время разработки не все коды будут включены в основную версию. Если в этот момент изменить имя или переместить каталог, это может привести к изменению UUID скрипта. В этом случае Creator покажет, что скрипт находится в состоянии Mission, и не будет показывать, какой скрипт был ранее прикреплён к предустановленному объекту. Если проект достаточно большой, изменение UUID одного скрипта может потребовать повторного прикрепления многих предустановленных объектов, увеличивая затраты на обслуживание.
Q: Зачем использовать предустановленные объекты и компоненты UIView для привязки?
- Ответ: Это обеспечивает централизованное управление, фабричный подход к созданию и упрощает реализацию унифицированных анимационных эффектов. Большинство компаний имеют свои стандарты анимации, и если мы хотим реализовать унифицированные анимационные эффекты, достаточно обработать их в UIView и вызвать UIManager.open() для отображения.
- Ответ: Управление памятью и ресурсами передаётся менеджеру, снижая необходимость разработчиков заботиться о времени освобождения ресурсов и загрузки новых. Они могут сосредоточиться на бизнес-логике, не беспокоясь о управлении ресурсами.
- Ответ: Интерфейс унифицирован, что облегчает подсчёт количества открытий модулей в будущем для предоставления данных операционному персоналу и оценки популярности каждого модуля.
Q: Почему основные модули проекта расположены в менеджере Manager?
- Ответ: Повышается читаемость кода, облегчается освоение для новичков, и можно сразу понять структуру проекта, просматривая Manager. Кроме того, глобальные переменные могут быть легко добавлены в Manager, что помогает избежать загрязнения глобального пространства имён.
Q: Почему рекомендуется сохранять типы везде, где это возможно?
- Ответ: С точки зрения автора, проект использует VSCode + Creator + TypeScript для разработки, а TypeScript и VSCode являются продуктами Microsoft. Microsoft добавил тип в JavaScript, чтобы решить проблемы с отсутствием типов и плохой читаемостью.
- Вы можете чётко определить, к какому типу относится значение.
- Редактор VSCode предоставляет интеллектуальные подсказки кода и статическую проверку синтаксиса, помогая разработчикам избегать ошибок.
- Код становится более строгим, и ограничения на типы параметров могут быть установлены в VSCode.
- Рефакторинг становится проще. Если вам нужно переместить файл в другое место, VSCode автоматически исправит все ссылки на этот файл. То же самое происходит при изменении имени API или класса. VSCode автоматически обновит все места, где используется этот тип, уменьшая затраты на рефакторинг.
- Наконец, никто не знает TypeScript лучше, чем VSCode. TypeScript фокусируется на типах, и рекомендуется сохранять их везде, где это возможно.
Комментарии ( 0 )