Почему Lua выбирают для встраивания и игрового скриптинга

Почему играм и приложениям нужен встраиваемый язык

Встраиваемый язык — это «второй слой» логики внутри программы. Основной код (обычно на C/C++/C#) отвечает за производительность, движок и системные вещи, а скрипты подключаются как данные и выполняются на встроенной виртуальной машине.

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

Какие задачи удобнее отдавать скриптам

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

Типичные примеры:

• логика геймплея (эффекты, способности, правила)
• UI и меню (реакции на события, показ подсказок)
• квесты и диалоги (ветвления, триггеры, условия)
• AI на уровне «поведения» (переходы состояний, приоритеты)
• моды и аддоны, пользовательские сценарии
• конфиги и таблицы параметров, которые удобно версионировать

Почему не хочется пересобирать проект из‑за мелочей

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

Скрипты в цикле разработки: от прототипа к продакшну

Обычно скриптовый слой сначала ускоряет прототипирование: дизайнеры и геймдизайнеры пробуют идеи, пока программисты занимаются базовыми системами. Затем те же скрипты «дозревают» до продакшна: часть решений фиксируется, часть остаётся настраиваемой.

Если вы параллельно делаете внутренние инструменты (редактор, панель сценариев, пайплайн сборки контента), их тоже выгодно проектировать вместе со скриптовым слоем: так вы быстрее закрываете путь «идея → проверка в игре».

Ключевые свойства Lua, которые делают её удобной для встраивания

Lua часто выбирают как «внутренний» язык для приложений и игровых движков, потому что она почти не навязывает инфраструктуру и хорошо уживается с уже существующим кодом. Её сильные стороны — практичные: небольшой рантайм, переносимость, предсказуемость поведения и простота для тех, кто пишет сценарии, а не ядро.

Компактный интерпретатор и простая сборка

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

Обычно Lua легко подключается как исходниками или небольшой библиотекой: без «зоопарка» модулей, без длинных цепочек сборки и без сюрпризов в рантайме. Для команд, которые хотят быстро начать и постепенно расширять скриптинг, это заметный плюс.

Минимум зависимостей и переносимость

Lua проектировалась так, чтобы быть переносимой: она одинаково уместна на ПК, консолях, мобильных устройствах и в embedded‑сценариях. Минимум внешних зависимостей снижает риск конфликтов версий и упрощает жизнь при интеграции в движок, где уже есть свои требования к библиотекам.

Побочный эффект — проще поддерживать одинаковое поведение на разных платформах, что особенно важно для контента и скриптов: меньше «работает на Windows, ломается на Switch».

Предсказуемая модель выполнения и управление памятью

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

Это помогает избегать резких просадок и держать скрипты в рамках бюджета кадра — важно для реального времени и интерактивных приложений.

Низкий порог входа для дизайнеров и контент-команд

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

В итоге Lua удобна как «клей» между системами: ядро остаётся на C/C++ (или другом основном языке), а гибкость и скорость итераций переезжают в скрипты.

Простой и практичный C API: как работает интеграция

C API Lua часто называют «низкоуровневым», но на практике он довольно прямолинеен: вы поднимаете интерпретатор внутри приложения и общаетесь с ним через стек и набор функций.

Состояние Lua: lua_State и стек

Встраивание начинается с создания состояния:

lua_State* L = luaL_newstate();
luaL_openlibs(L);

lua_State* — это контекст интерпретатора (память, таблицы, сборщик мусора, загруженные скрипты). Взаимодействие идёт через стек: вы «кладёте» значения (аргументы), вызываете функцию, затем «снимаете» результаты. Такой подход позволяет API оставаться компактным и одинаковым для всех типов.

Регистрация функций хоста и вызовы Lua из C/C++

Чтобы Lua могла вызывать ваш движок/приложение, вы регистрируете C-функции (обычно тонкие обёртки над системами: аудио, сцена, инвентарь):

lua_register(L, "play_sound", l_play_sound);

Обратная сторона — вызов Lua из хоста: вы загружаете файл/строку, находите функцию по имени, кладёте аргументы на стек и делаете lua_pcall. Важно вызывать именно lua_pcall, а не lua_call, чтобы ошибки из скрипта не «роняли» приложение.

Время жизни объектов и сборка мусора

Типичная схема: вы храните «тяжёлые» объекты в C/C++, а в Lua отдаёте безопасные хэндлы/юзердата. Когда объект уничтожается в хосте, скрипт должен перестать на него ссылаться: либо через слабые таблицы, либо через проверку валидности хэндла.

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

Типичные ошибки интеграции (и как их избегать)

Чаще всего проблемы возникают из-за стека: забыли снять значения, перепутали порядок аргументов, не проверили типы. Дисциплина простая: после каждого вызова фиксируйте ожидаемую высоту стека и валидируйте вход через luaL_check*.

Вторая частая ошибка — «протекание» доступов: открыли лишние библиотеки или дали скриптам прямой доступ к файловой системе. Лучше явно экспортировать только нужные функции и данные, а остальное скрыть за API хоста.

Производительность и размер: почему Lua подходит реальному времени

Одна из причин, почему Lua так часто выбирают для игровых движков и приложений реального времени, — сочетание компактного рантайма и предсказуемой скорости. Язык задумывался как встраиваемый: его легко «принести с собой» в продукт без тяжёлых зависимостей.

LuaJIT: когда ускоряет, а когда мешает

LuaJIT может заметно ускорить горячие участки логики (например, расчёты, фильтрацию, простые симуляции), если код хорошо «ложится» на JIT-компиляцию.

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

Где появляются узкие места: граница C↔Lua

Частая проблема — не «медленная Lua», а слишком частые вызовы через границу C↔Lua: мелкие функции, дергаемые тысячи раз за кадр, упаковка/распаковка данных, создание временных таблиц.

Как оптимизировать без магии

• Профилирование: сначала измеряйте (время кадра, горячие скрипты, количество переходов C↔Lua), потом оптимизируйте.
• Батчинг вызовов: лучше один вызов «обработай список объектов», чем тысяча вызовов «обработай один объект».
• Структуры данных: уменьшайте аллокации, переиспользуйте таблицы, храните данные в более плотном виде (массивы вместо вложенных словарей там, где это уместно).

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

Безопасность: песочницы и контроль доступов

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

Ограничиваем файловую систему, сеть и ОС

Самый безопасный подход — не открывать опасные стандартные библиотеки (или открывать частично). Например, для модов обычно не нужны io, os и произвольная загрузка модулей через package. Если скрипту нужно читать данные, лучше дать ему контролируемые функции вроде ReadAsset("path"), которые работают только внутри каталога ресурсов и не умеют выходить наружу.

«Белый список» API вместо «чёрного»

Не пытайтесь запрещать всё плохое поштучно — проще выдать небольшой набор разрешённых функций: спавн объектов, доступ к параметрам игрока, события UI, воспроизведение звуков. Такой API проще документировать, тестировать и поддерживать, а главное — он существенно сужает пространство для злоупотреблений.

Изоляция окружений и разные права

Практично разделять права по типам скриптов:

• Сюжетные/геймплейные (встроенные) — больше возможностей, но всё равно без прямого доступа к ОС.
• Пользовательские моды — минимум функций и строгая песочница.
• Серверные (если есть) — отдельное окружение и отдельные лимиты.

Это реализуется разными окружениями (отдельные таблицы _ENV) и разными наборами зарегистрированных функций.

Логирование, таймауты и защита от бесконечных циклов

Безопасность — это ещё и управляемость. Добавьте:

• логирование вызовов «опасных» точек API (загрузка ресурсов, создание сущностей, сетевые события);
• лимиты по времени/инструкциям (например, через hook), чтобы обрывать зависшие скрипты;
• понятные сообщения об ошибках и автодеактивацию мода, если он постоянно падает.

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

Удобное API для геймплея и контента

Хорошее встраивание Lua в игру — это не «просто дать доступ к функциям движка», а спроектировать понятный слой, на котором удобно писать геймплей и собирать контент. Чем аккуратнее этот слой, тем меньше скрипты зависят от внутренностей движка, а значит — реже ломаются.

Как выглядит API игры для скриптов

Обычно скриптам дают несколько ясных «точек входа»:

• События: on_spawn, on_damage, on_interact, on_tick — скрипт подписывается и реагирует.
• Команды/сервисы: SpawnEnemy(), PlaySound(), GiveItem() — ограниченный набор действий, которые разрешено делать.
• Компоненты (если игра на ECS или близко к нему): entity:Get("Health"), entity:Set("AI", {...}) — работа через данные, а не через прямые ссылки на объекты движка.

Такой API читается как «язык игры», а не как обёртка над C/C++.

Паттерны: callbacks, события, корутины, таблицы как конфиги

Lua особенно удобна, когда сочетаете код и данные. Таблица легко становится конфигом, а функция — обработчиком:

return {
  id = "goblin",
  hp = 35,
  on_spawn = function(self) self:Play("spawn") end,
  loot = { gold = {min=1, max=3}, item="dagger" }
}

Для сценариев «подождать/переходить по шагам» вместо сложных машин состояний часто используют корутины: они выглядят линейно и понятны геймдизайнеру.

Удобство для контентщиков

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

Версионирование API и совместимость

Скрипты живут долго, поэтому API стоит версионировать: добавляйте новые функции, но не меняйте поведение старых без переходного периода. Помогают префиксы/неймспейсы (game.v1, game.v2) и мелкие адаптеры, чтобы старые моды и уровни продолжали работать после обновления.

Корутины Lua: естественная модель для игровых сценариев

Корутины в Lua позволяют писать «временные» сценарии так, будто код выполняется последовательно, но при этом не блокирует игру. Для квестов, катсцен и поведения NPC это часто удобнее, чем раздувать логику в коллбэках или строить сложные машины состояний.

Сценарии как последовательности, а не графы

Вместо схемы «событие → обработчик → ещё событие» можно описать сцену простым линейным кодом:

• показать реплику
• подождать 2 секунды
• переместить NPC
• дождаться, пока игрок подойдёт
• запустить следующий шаг

В Lua это читается как сценарий, а не как набор разрозненных хендлеров.

Интеграция с игровым циклом: ожидания и события

Типичный подход: вы запускаете корутину на старте квеста, а затем каждый кадр «продвигаете» её, когда выполнено условие ожидания.

• Ожидание времени: wait(2.0) возвращает управление движку, пока не пройдёт нужная дельта.
• Ожидание события: wait_event("door_opened") возобновляет корутину, когда ваш движок доставит сигнал.
• Ожидание условий: wait_until(player_in_zone("market")) удобно для триггеров.

Важно: корутина не запускается «сама по себе» параллельно. Её возобновляет ваш код (обычно из update()), поэтому модель остаётся детерминированной и дружелюбной к отладке.

Подводные камни

Главные проблемы обычно не в корутинах, а в связях с движком:

• Утечки ссылок: если корутина хранит ссылки на объекты сцены, которые уже уничтожены, можно получить «висячие» сущности. Помогают слабые ссылки, проверки валидности и явная отмена корутин при выгрузке уровня.
• Конкуренция за ресурсы: две корутины могут одновременно пытаться управлять одним NPC или камерой. Решение — простые «замки»/владение ресурсом, очереди команд или единый контроллер.

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

Инструменты и рабочий процесс: отладка, hot-reload, тесты

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

Загрузка скриптов, hot-reload и отладка

Базовый подход — централизованный «ScriptManager», который отвечает за:

• поиск файлов (пакеты, локальная папка, /mods и т. п.);
• кеширование чанков и зависимостей;
• безопасную перезагрузку (с откатом при ошибке).

Для hot-reload обычно отслеживают изменения файлов и перезагружают только затронутые модули. Важно отделить код от состояния: храните состояние в таблицах/объектах, которые можно аккуратно пересоздать или мигрировать при перезагрузке. Практика: перезагружать модуль, затем вызывать его on_reload(old_state).

Отладка становится проще, если вы сразу подключили debug.traceback и умеете ставить «брейкпоинты» через внешние инструменты (например, протоколы отладчика) или хотя бы через встроенный логгер. Даже без полноценного дебаггера наличие единых команд вроде /reload и /lua <expr> сильно ускоряет работу.

Отдельный полезный приём на ранних этапах — быстро собрать «внутреннюю демку» API (как должны выглядеть события, сервисы, ограничения песочницы) ещё до того, как весь движок готов. Для такого прототипирования иногда используют TakProsto.AI: в формате чата можно накидать каркас сервисов, структуру модулей и примеры скриптов, а затем перенести удачные решения в основной проект. Это не заменяет ручную интеграцию Lua, но ускоряет подготовку черновиков и документации по API для команды.

Ошибки времени выполнения: понятные сообщения

Не запускайте пользовательский код «в лоб». Оборачивайте вызовы в xpcall, чтобы всегда получать трассировку:

local function run(f, ...)
  return xpcall(function() return f(...) end, debug.traceback)
end

Дальше задача движка — привязать ошибку к контексту: имя скрипта/мода, сущность в сцене, текущая миссия, кадр/тик. В UI или в консоли показывайте короткое сообщение и кнопку «раскрыть стек».

Профилирование и метрики на реальных сценах

Самое полезное профилирование — на «живых» уровнях. Снимайте метрики: время на тик Lua, топ медленных функций, количество аллокаций (по возможности), число вызовов C↔Lua. Добавьте маркеры «зон» (AI, UI, квесты), чтобы понимать, что именно просело.

Тестирование: юнит-тесты и контрактные тесты API

Юнит-тесты удобно писать для чистых Lua-модулей (логика квестов, формулы, генерация). Отдельно нужны контрактные тесты для вашего API: проверяйте, что движок предоставляет ожидаемые функции, типы и ошибки (например, что spawn_enemy падает с понятным текстом при неверных параметрах).

Такой набор быстро ловит регрессии при изменениях в C/C++ стороне и помогает поддерживать моды совместимыми.

Моды и расширяемость: почему Lua удобна для сообщества

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

Моды без доступа к исходникам

Если вы заранее выделяете стабильный слой API (например, Game.spawn_enemy(), UI.add_panel(), Events.on("damage")), моды становятся безопасным расширением поверх ядра. Lua-скрипты работают как «клей»: они комбинируют существующие возможности, не ломая нативную часть.

Как упаковывать моды: папки, манифест, зависимости

Практичный подход — стандартизировать структуру:

• mod.json (или manifest.lua): имя, версия, автор, описание
• scripts/: входная точка (например, init.lua) и модули
• assets/: текстуры, звуки, локализация
• data/: таблицы настроек, пресеты

В манифесте полезно поддержать зависимости и минимальную версию игры: так моды могут явно требовать библиотеку, другой мод или конкретную версию API.

Совместимость: конфликты, приоритеты, миграции

Главная боль моддинга — пересечения. Помогают: порядок загрузки (приоритет/«load after»), неймспейсы (префиксы в именах событий и таблиц), а также стратегия сохранений: версия схемы данных + миграции. Тогда при обновлении мода можно аккуратно преобразовать старые сохранения, а не «убить» прогресс.

Поддержка сообщества

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

Lua vs Python/JavaScript: короткое сравнение для выбора

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

Сравнение по ключевым критериям

Размер и зависимости. Lua обычно заметно компактнее и проще как библиотека для поставки вместе с игрой/приложением. Python почти всегда тянет за собой более тяжёлую рантайм-среду. JavaScript зависит от движка: современный JS-движок может быть крупным, хотя в некоторых продуктах это оправдано.

Скорость и предсказуемость. Lua часто выбирают там, где важна стабильная задержка кадра и понятная стоимость вызовов скрипта из C/C++. Python удобен, но в tight-loop сценариях может быть сложнее удерживать предсказуемость. JS может быть очень быстрым на «чистом» коде, но интеграция с нативным слоем и управление паузами сборщика мусора требуют внимания.

Простота встраивания. У Lua прямолинейный C API и понятная модель «движок ↔ скрипт». У Python отличная документация, но embedding обычно выходит сложнее по упаковке, инициализации и версии окружения. У JS многое определяется конкретным движком и его API.

Экосистема. Python лидирует по библиотекам для пайплайна (инструменты, анализ данных, контент-пайплайн). JS силён для UI, веб-интеграций и команд с фронтенд-экспертизой. Lua выигрывает там, где важны лёгкость встраивания, контроль API и сценарии геймплея.

Как принять решение под проект

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

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

Если проект тяготеет к UI/веб-слою или у команды сильная JS-экспертиза — JavaScript способен сократить время разработки, но заранее оцените стоимость встраивания выбранного движка и профилирование пауз.

Ограничения Lua и как их компенсировать

Lua ценят за простоту и встраиваемость, но у неё есть и слабые места. Хорошая новость: большинство из них закрываются практиками и инструментами — без усложнения движка.

Динамическая типизация и большие проекты

В маленьких скриптах свобода типов — плюс, а в крупных системах легко получить ошибки «на позднем этапе»: неверное поле, неожиданный nil, несовпадение форматов данных.

Компенсации обычно такие:

• договориться о стиле API: какие поля обязательны, какие могут быть nil, что возвращают функции;
• добавить лёгкие проверки на границах (валидировать входные таблицы, проверять диапазоны значений);
• включить статический анализ: Lua Language Server (проверка типов по аннотациям), luacheck (линтинг), а где нужно — использовать диалекты/надстройки вроде Teal.

Это даёт «почти типизацию» там, где она важна, не ломая привычный Lua.

Модули, стиль и контроль качества

Если не договориться заранее, проект быстро превращается в набор «глобальных» скриптов.

Рабочий минимум:

• чёткая структура модулей: один модуль — одна ответственность, явный return таблицы с публичным API;
• запрет на новые глобальные переменные (или хотя бы их аудит): это резко снижает число скрытых зависимостей;
• единые соглашения по именованию и форматированию; проверка в CI теми же luacheck и тестами.

Интеграционные риски: ABI, сборки и платформы

Главные проблемы возникают не в Lua-коде, а на стыке со «внешним миром»: разные компиляторы, сборки, версии рантайма, особенности консолей/мобайла.

Что помогает:

• держать границу интеграции узкой: меньше «магии» в биндингах, больше явных функций;
• фиксировать версии Lua и зависимостей, избегать несовместимых модулей, особенно бинарных;
• для C/C++-части — единый пайплайн сборки и тесты, которые гоняются на целевых платформах.

Безопасность и JIT (особенно на консолях)

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

Практика: давать скриптам только безопасный API, отключать опасные библиотеки (os, io), ограничивать ресурсы (память/время выполнения через хуки), аккуратно обращаться с debug.

LuaJIT часто ускоряет игру, но на консолях и некоторых мобильных платформах JIT может быть запрещён или нестабилен. Компенсация — иметь режим без JIT (обычная Lua), избегать зависимости от JIT-специфичных расширений и проверять производительность заранее.

Практический чек-лист: как внедрить Lua в игру или приложение

Эта мини-памятка помогает пройти путь от «просто подключили Lua» до управляемого, безопасного и поддерживаемого скриптинга, который не ломается на релизе.

1) Минимальный прототип скриптинга (за 1–2 дня)

Начните с самого маленького вертикального среза: загрузить файл, выполнить функцию, вернуть результат.

• Поднимите Lua VM (lua_State) и добавьте один “host”-метод, например Log(text).
• Экспортируйте в Lua один объект/таблицу API: Game = { Log = ... }.
• Сделайте один сценарий: onStart() или onUpdate(dt) и вызывайте его из движка.

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

2) Спроектируйте границу: что в движке, что в скриптах

Правило, которое часто работает: скрипты описывают «что» (правила, параметры, события), а движок делает «как» (физика, рендер, сетевой код, файловая система).

• В движке: тяжёлые циклы, работа с памятью, конкурентность, системные вызовы.
• В Lua: квесты, AI‑поведение верхнего уровня, триггеры, UI‑логика, конфиги контента.

Сразу решите, какой стиль API нужен: событийный (OnHit, OnInteract) или data-driven (Lua возвращает таблицы настроек).

3) Документация API и примеры для контент-команды

Даже небольшой API быстрее освоить, если есть «золотые» примеры.

• один файл /scripts/examples/ на каждый тип задачи (спавн, диалог, баффы);
• короткая спецификация ошибок: какие исключения/коды возвращаются и что с ними делать;
• версионирование API: добавляйте API_VERSION и отмечайте устаревшие функции заранее.

4) Чек-лист перед релизом: производительность, безопасность, совместимость

• Производительность: измеряйте время onUpdate и аллокации; ограничьте частоту вызовов из C/C++ в Lua и обратно; кэшируйте ссылки на функции.
• Безопасность: отключите лишние стандартные библиотеки (I/O, OS), используйте песочницу и лимиты (время/инструкции, память), валидируйте входные данные.
• Совместимость: фиксируйте версию Lua, тестируйте сценарии на «старых» сохранениях/модах, добавляйте миграции для форматов данных.

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