Все игры Out построены вокруг сущностей (объектов в мире) и компонентов (поведение/данные, привязанные к сущностям).
Если вы раньше использовали Unity: думайте “GameObject + Components”. Если вы раньше использовали Roblox: думайте “Instance + Scripts/Components”. Основная идея та же: вы собираете геймплей, добавляя компоненты к сущностям.
Сущности
Сущности существуют двумя распространёнными способами:
Размещённые в редакторе: они уже находятся в сцене при запуске.
Созданные во время выполнения: вы создаёте их из скрипта.
Создание и уничтожение сущностей
entity:=Scene.create_entity();entity->set_local_position({10,20});entity->set_local_scale({2.5,2.5});entity->set_local_rotation(0);// Когда закончите:entity->destroy();
Уничтожение сущности уничтожает и её компоненты. Не храните ссылки на компоненты после уничтожения их сущности.
Итерация по сущностям
Компоненты
Компоненты — это единицы поведения. Компонент «живёт» на сущности и может читать/изменять эту сущность.
Получение и добавление компонентов
Итерация по компонентам
Встроенные компоненты, которые вы будете часто использовать
Sprite_Renderer
Префабы (Prefab_Asset)
Префабы нужно создавать в редакторе. В скриптах вы их инстанцируете.
Spine (Spine_Animator)
Если вы используете 2D-анимированных персонажей, вы часто будете работать с Spine_Animator. См. Spine.
Написание собственного компонента
Создавайте новые компоненты в отдельных файлах (например, orbiter.csl) и прикрепляйте их к сущностям либо:
Вручную в редакторе, или
Во время выполнения с помощью entity->add_component(...)
Компоненты могут реализовывать колбэки жизненного цикла:
ao_start()
ao_update(dt)
ao_late_update(dt) (после всех обновлений)
ao_end() (при уничтожении)
Пример:
Методы жизненного цикла для глобальных скриптов (ao_start, ao_update, ...) рассматриваются в Жизненный цикл игры/кадра.
Сериализуемые поля (@ao_serialize)
Используйте @ao_serialize чтобы отобразить поле в редакторе (и часто включить сохранение/персистентность, где это применимо).
Поиск ближайших компонентов (запросы по близости)
В CSL нет колбэков столкновений. Распространённый шаблон — «запросить ближайшие компоненты и проверить расстояние».
Полезные вспомогательные функции:
Пример:
Лучшие практики
Состояние, относящееся к конкретному игроку, должно находиться на Player. Избегайте глобальных переменных, которые сломаются при наличии нескольких игроков.
Для игровых механик отдавайте предпочтение компонентам. В итоге у вас получатся переиспользуемые блоки, которые можно прикреплять к разным сущностям.
Локализуйте косметические эффекты. UI/частицы обычно должны выполняться за is_local() проверок.