Как-это-всё-работает?.md

+# Как это всё работает?
+
+**Объекты, Ресурсы, Модификации ресурсов, Состояния модификаций, Владельцы объектов, Шаблоны объектов их связь между собой и теория нанесение урона**
+
+1\. В бэкенде есть приложение `objektoj` (объекты), в нём есть модель `Objekto` (Объект), у неё есть поле `integreco` (целостность). Это так в Django-бэкенде называется, когда ты к этому обращаешься через API, там названия могут быть немного другие, ну или точно такие же, просто в файлах которые создают функционал API определяется как эти поля будут называться снаружи при доступе по API, обычно они называются точно также ну или почти также.
+
+2\. Когда происходит стрельба, например, по астероиду то выстрел отнимает у него значение целостности, то есть уменьшается значение в поле integreco, это просто цифра от нуля до очень большого значения. Обращаю твоё внимание, что это не проценты от 0 до 100%, это именно цифровой показатель в единицах целостности, тут число может быть и миллионное, и больше.
+
+Такой подход нужен для того, чтобы у различных объектов, которые логически обладают разным уровнем "крепкости" в реальном мире, чтобы у них в виртуальном мире была аналогичная ситуация. Ну то есть возьмём какой-то небольшой контейнер из обычного материала и стрельнем в него из лазерной пушки и возьмём целый астероид и стрельнем в него той же лазерной пушки, эффект будет разный. Контейнер просто в мелкие куски разлетится, а у астероида только часть поверхности "обскоблится".
+
+Получается тут баланс мощности воздействия и целостности объекта. Например у пушки сила урона будет 10 единиц, а у контейнера целостность 5 единиц, значит одним выстрелом контейнер полностью уничтожается. А у небольшого астероида, предположим, целостность 1000 единиц. Это значит, чтобы его уничтожить в него нужно стрельнуть 100 раз.
+
+Тут мы говорим пока о том, что для начала реализуется упрощённая механика урона, в которой не добавляются различные модификаторы — факторы влияющие на урон и защиту от урона, типа: расстояние выстрела, скорость движения объектов, случайные факторы, перегрев оружия, угол попадания средства поражения на объект и так далее. Это всё будет наращиваться в будущем.
+
+3\. Как я уже сказал, кроме целостности объекта, есть и мощность. Эта мощность пока записана в модификациях ресурсов. То есть кроме приложения `objektoj` (объекты), в котором есть модель `Objekto` (Объект), ещё есть приложение resursoj, у которого есть модель `Resurso` (Ресурс) и её дочерняя модель `ResursoModifo`, в которой есть поле `potenco` (мощность).
+
+Ресурсы — это типа номенклатурные позиции / чертежи с описанием характеристик того какие объекты будут на основании их созданы.
+
+Модификации ресурсов — для упрощения можно понимать как подресурс, модификации нужны для разных производственных заморочек в реальном мире и игровых механик, не будем на этом сейчас сосредотачиваться, пока нужно понять, что у каждого Ресурса есть как минимум одна базовая Модификация ресурса и у многих ресурсов так всегда и будет, что у них только одна модификация.
+
+Рассказываю я о Модификациях ресурсов, чтобы было понятно, что часть полей описывающих характеристики ресурса находятся в моделе `Resurso` (Ресурс), а часть полей находятся в дочерней моделе `ResursoModifo`, например, уже упомянутое нужное нам сейчас поле поле potenco (мощность).
+
+4\. У Модификации ресурсов есть своя дочерняя модель `ResursoModifoStato` (Состояние модификации ресурса).
+
+Состояние модификации — это заранее запланированные вариации ресурсов (модификаций ресурсов), на текущий момент в первую очередь используются, чтобы запланировать какие состояния у модификаций ресурсов будут при разной степени разрушения Объектов связанных с этими ресурсами.
+
+Состояний у каждой Модификации ресурса на текущий момент реализуется по четыре (хотя в некоторых случаях начали делать и 5 уровней), не путать с четырьмя уровнями детализации моделей Объектов.
+
+Состояния — это целый объект, частично повреждённый, сильно повреждённый и полностью разрушенный. Для астероидов там делали ещё что-то типа средне-повреждённого, таким образом у него и получалось 5 состояний, но для начала запланировали для всех объектов реализовать по 4 состояния, а значит и по четыре 3D-модели. Но потом для крутости и красоты можно делать больше промежуточных Состояний.
+
+Уровни детализации (LOD) — это разные варианты 3D-моделей каждого Состояния модификации ресурса, которые показываются в зависимости от того, как близко они к камере обзора пользователя (к экрану пользователя).
+
+Нужны они для оптимизации нагрузки, чтобы когда не нужно (когда показываются вдали и мелкие детали всё равно не различимы для человеческого глаза) не загружать компьютер пользователя обсчётом сложных моделей с большим количеством деталей, потому что человеческий глаз эти мелкие детали не видит, разрешение монитора эти детали на таком расстоянии не способно показать, но компьютер их всё равно прорисовывает и тратит на это большие ресурсы.
+
+Получается, что например, у Состояния модификации частично повреждённого объекта (например, частично повреждённого Астероид, тип 1) по всей видимости нужен будет свой отдельный вид 3D-моделей для 1 и 2 уровня детализации, потому что на 3 и 4 уровне детализации эти повреждения не будут видны и для 3 и 4 уровня можно будет использовать общие 3D-модели этих уровней. Но это всё просто общая информация о логике связи Состояний модификаций ресурсов с Уровнями детализации, и то как это реализовать с меньшими затратами, сейчас речь пока про другое.
+
+5\. Модель `Objekto` (Объект) имеет поле resurso, которое связывает каждый Объект с моделью `Resurso` (Ресурс), имеет поле `modifo`, которое связывает каждый Объект с моделью `ResursoModifo` (Модификация ресурса) и имеет поле `stato`, которое связывает каждый Объект с моделью `ResursoModifoStato` (Состояние модификации ресурса).
+
+Всё же понятно и просто? :grin: Уточню, что когда я речь про "модели" — это Django-модели, то есть специальные Питоновские классы, которые наследуются от классов фреймворка Django, на основе структуры которых через Django ORM создаётся структура базы данных. А когда речь про 3D-модели — это те модели, которые мы в Блендере рисуем, которые пользователь видит. Теперь, я думаю, точно всё понятно и просто :joy:
+
+6\. Когда происходит стрельба по объекту, то у Объекта снижается уровень его целостности, то есть в моделе `Objekto` (Объект), у конкретной записи в этой моделе, ну точнее уже в таблице в базе данных, ну то есть у конкретного объекта который пользователь видит на своём экране (или не видит, но может увидеть), в поле `integreco` (целостность) цифра становится меньше на уровень нанесённого урона.
+
+7\. У модели `ResursoModifoStato` (Состояние модификации ресурса) тоже есть поля `integreco` (целостность) и `potenco` (мощность).
+
+Напомню, что ещё:
+
+- У модели у `Objekto` (Объект) есть своё поле `integreco` (целостность).
+- У модели у `ResursoModifo` (Модификация ресурса) есть своё поле integreco (целостность) и есть своё поле `potenco` (мощность).
+
+Всё чётко и ясно 🤬
+
+8\. Но если вдруг немного не ясно, то вот подробности про поля целостности:
+
+- `Objekto` (Объект) в поле `integreco` (целостность) хранится число текущей целостности объекта, например, значение целостности астероида в который мы сейчас стреляем, по мере стрельбы у него это значение уменьшается, когда доходит до нуля, тогда этот астероид становится полностью разрушенным.
+- `ResursoModifo` (Модификация ресурса) в поле integreco (целостность) указывается изначальная запроектированная целостность Объекта. Ну, конечно, когда речь о космическом корабле это звучит более понятно, ну типа мы провели изначальные расчёты проекта, испытали его и зафиксировали что вот такой максимальный урон этот корабль выдерживает. Для астероида такое звучит не очень привычно, но в этом суть виртуального мира, мы тут как боги создаём номенклатуру всего и указываем в том числе какое запроектированное значение целостности вот у такого астероида.
+- `ResursoModifoStato` (Состояние модификации ресурса) в поле `integreco` (целостность) указывается значение при котором начинает быть активным именно вот это состояние ... в конечном итоге у Объекта - это если говорить упрощёно, а если не упрощенно, то Состояние модификации ресурса с которым связан Объект.
+
+Например, у астероида есть 4 состояния, мы стреляем в астероид, значение целостности астероида снизилось, скажем, до 150, а у его Состояния "Целый объект" было значение 200, что подразумевает, что целым он отображается от 200 и ниже пока не дойдёт до ступени указанной в следующем Состоянии.
+
+А у следующего Состояния "Частично повреждённый" как раз было указано значение 150, значит для системы у этого астероида теперь другое состояние, что запускает ту логику, которую мы для этого другого состояния запрограммировали, в первую очередь будет показана 3D-модель не целого астероида, а 3D-модель с небольшими трещинами. Но а также дальше тут будет навешана логика, что от астероида с этим Состоянием при добыче начнёт меньше поступать ресурсов при каждом действии по добыче.
+
+9\. И вот подробности про поля мощности:
+
+- `ResursoModifo` (Модификация ресурса) в поле potenco (мощность) указывается мощность, вообще сейчас это универсальное поле, которое в дальнейшем нужно будет разделить на разные поля. Потому что эта "мощность" как тип переменной в языке программирования без жёсткой типизации, ну то есть мы тут значение указываем, а там дальше по логике уже это используется там где нужно. Получается если это мощность указана у оружия, значит это мощность нанесения урона, а если это мощность указана у двигателя, то это мощность двигателя.
+
+Поскольку у нас пока не реализован функционал мощности двигателей, пока `potenco` (мощность) используется только для оружия, точнее для одного типа пушки что у нас есть.
+
+Изначально potenco (мощность) была только тут как универсальное значение для всех Состояний, но стало понятно, что нужно будет реализовывать у разных Состояний разное значение, потому что если пушка повреждена то её мощность должна снижаться, ну и аналогично потом с двигателями и т.д. Поэтому основные данные для Объектов нужно брать у Состояний, а в Модификации ресурса это значение остаётся как значение для чертежа и равно Состоянию "Целый объект".
+
+- `ResursoModifoStato` (Состояние модификации ресурса) как уже было сказано выше, вот тут и есть `potenco` (мощность), значение от куда нужно брать для объектов. Ну то есть смотреть какое сейчас Состояние у Объекта и у этого состояния брать значение.
+
+10\. У модели `Objekto` (Объект) есть дочерняя модель `ObjektoPosedanto` (Владелец объекта), в которой какой-то конкретный Объект связывается с Пользователем или Организацией. Там есть всякие типы владения, статус владения, доля владения и всё-такое, в это пока погружаться не будем.
+
+Суть в том, что вот есть космический корабль и он связан с моей учётной записью, значит бэкенд даёт моей учётной записи пользователя вносить какие-то изменения в поля этого объекта. А вот у астероида моя учётная запись не является владельцем, я сейчас не говорю про будущий функционал возможности покупки своего астероида, я пока про системные вопросы говорю, про то, что есть астероид, который болтается в космосе и у него не указано что моя учётная запись является владельцем.
+
+Получается, что просто так, я ничего не могу сделать с этим астероидом, на уровне бэкенда моя учётная запись простого пользователя не может в поле integreco (целостность) этого астероида внести изменения и уменьшить это значение. Для системы у меня нет прав доступа к этому объекту.
+
+Конечно, если я авторизовался в системе под учётной записью админа системы, то я могу тогда влиять вообще на любой объект, хоть на астероид, хоть на корабли других пользователей. Но это так называемый "режим бога", а основная часть пользователей имеет обычные права и не сможет использовать такой режим.... когда случается такое, что у массы пользователей появляется режим бога, в таких системах и играх это считается жёстким багом, разработчики в панике бегают и исправляют это, а пользователи резвятся разнося всё вокруг.
+
+Вот для этого и нужен Godot-сервер, у который будет авторизовываться на бэкенде с админскими правами, ну точнее не с правами суперюзера, не в режиме бога, а просто у той системной учётной записи с которой Godot-сервер будет авторизовываться на Django-бэкенде будут даны админские права к модели Объектов и другим моделям, на которые ему нужно воздействовать.
+
+11\. Ну и кратко про Шаблоны объектов. Вот выше я написал, что есть Объекты с их дочерними моделями и есть Ресурсы с их дочерними моделями и Объекты как бы созданы на основе Ресурсов, которые как бы чертежи для Объектов. Это так и есть ... но это не так :dizzy_face:
+
+Это так в том смысле, что вот есть Объект и он связан с Ресурсом, с Модификацией ресурсов, с Состоянием модификации ресурсов и через эти связи с другими дочерними моделями ресурсов. Со всех этих моделей Объект берёт разные значения и использует их.
+
+А не так, в том смысле, что когда создаётся новый Объект в таблице в базе данных, он не создаётся на основе Ресурсов. Например, когда регистрируется новый пользователь ему нужно создать разные Объекты, владельцем которых он будет являться, которые ему полагаются по сюжеты игры. Корабль, обвесы этого корабля и всё такое. Это всё создаётся на основе уже заготовленных шаблонов в `ObjektoSxablono` (Шаблон объекта) которые связаны с другими шаблонами, ну точнее так должно быть, пока это не совсем до конца реализовано.
+
+Да, можно было бы обойтись и без модели `ObjektoSxablono` (Шаблон объекта), можно было бы просто в коде прописать, что при создании нового пользователя создай ему вот такой объект с кучей связей в других моделях и с кучей значений в разных полях. Но это не очень удобно, из этого потом будет очень сложно формировать отчёт по таблице баланса, анализировать эту таблицу баланса и так далее.
+
+Вообще почти у всех сущностей в бэкенде, которые наследуются от базовых абстрактных классов есть системные поля для обозначения этой сущности как часть шаблона. А модель `ObjektoSxablono` (Шаблон объекта) является локальной вершиной, в которую собираются связи с другими сущностями, которые помещены как шаблоны. Там есть ещё более высокая вершина, Django-приложение `sxablonoj` (шаблоны), в котором есть модель `Sxablono` (Шаблон), в которые и должны будут связаться все другие шаблоны, но это отдельный разговор.
+
+**Уточнение 1**
+
+Модель ObjektoSxablono теперь не используется. Она создавалась вначале, но потом был пересмотрен маршрут создания по шаблонам и от данной модели отказались, но решили оставить на всякий случай. Локальной вершиной является модель Sxablono (Шаблон). По ней создаются нужные объекты.
+
+И правильно будет:
+
+Всё создаётся на основе уже заготовленных шаблонов в Sxablono (Шаблон) которые связаны с другими шаблонами. И это всё реализовано и создаётся.
+
+**Уточнение 2**
+
+Ещё нужно описать как работают проекты и задачи с использованием `taskoj`, в котором создаётся проект движение или проект стрельбы и внутри него задачи по этапам.
\ Нет новой строки в конце файла