Войти
Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ

Где хранить армию роботов?

#0
22:38, 9 дек. 2021

В классике всё просто:
1. Пишем класс робота с полями игровой логики + методы.
2. В этом же классе и указатель на графический объект.
3. Всех роботов помещаем в массив.
4. В главном игровом апдейте в цикле проходиться по этим юнитам и что-там двигать.

А как православно верно с точки зрения Урхи?


#1
(Правка: 12:07) 9:21, 10 дек. 2021

xlat-code
> А как православно верно с точки зрения Урхи?
Всё что может быть и не может, хранится в Node
православно только два подхода.

УРхо это ECS, то бишь Entity Component System. А значит к любой ноде можно получить доступ как по имени, так и по Id, так и по ссылке. И всё работает само по себе в своих собственных окружениях. И если нужно, есть тот кто их связывает или использует на своё усмотрение
1) scene.Get...

2) ну а традиционный вариант, как ты и написал. Не знаю что такое графический объект (StaticModel? если да, то это опять же достаётся из Node.GetComponent<StaticModel>). Хранишь ссылки на ноды дополнительно, если в этом есть удобства конкретно для тебя.

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

#2
20:05, 10 дек. 2021

В классике всё просто:
1. Пишем класс робота с полями игровой логики + методы.
2. В этом же классе и указатель на графический объект.
3. Всех роботов помещаем в массив.
4. В главном игровом апдейте в цикле проходиться по этим юнитам и что-там двигать.

Это в г каком-то а не классике. В классике данные, логика и рендер лежат отдельно в разных тредах.

#3
21:16, 10 дек. 2021

ёж
Всё зависит от нужд, тут их никто не отменял. Я хотел лишь сказать что методы Get так же эффективны и не напрягают систему.

#4
21:37, 10 дек. 2021

ёж
Обычно армия делится на сквады по 4-8 юнитов. и у тебя есть вектор сквадов. Вот у тебя уже меньше итераций в 4-8 раз. Да и закешировать можно всё на старте, а не гетать в апдейте. Кароч обновлять много юнитов можно легко. Посмотри 2018Academy - ECS-DoD.pdf

#5
22:41, 10 дек. 2021

ёж
+, совершенно верно

#6
(Правка: 21:55) 11:29, 11 дек. 2021

Salamandr
> 2) ну а традиционный вариант, как ты и написал. Не знаю что такое графический
> объект (StaticModel? если да, то это опять же достаётся из
> Node.GetComponent<StaticModel>). Хранишь ссылки на ноды дополнительно, если в
> этом есть удобства конкретно для тебя.
да щас я делаю так.

Salamandr
> 1) scene.Get...
да я вижу, что ноды в движке имеют атрибуты и теги,
но пока я не разобрался что в них можно хранить.

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


lookid
> Это в г каком-то а не классике. В классике данные, логика и рендер лежат
> отдельно в разных тредах.
хм, нода это из логики или рендера?
можно повесить скрипт на ноду и забыть и нода будет фунциклировать,
но иногда данные этого фунциклирования нужно получать для логики.

робот связан с нодой и собсно положение ноды это и есть часть может дажа самая важная логики.

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

Предлагаете сделать его глобальным?
ах, мда, шаблон у мя не получится - я на ангелскриптах.

StepEver
> Про самую главную фичу
да.
я вижу много разных вкусностей в том как лучше организовать код,
но опыта мало,
и щас задача сделать что-работающее, а потом заняться рефактом.

на самом деле я должен был задать вопрос так:
Если избегать навешивания(реги) на каждого робота скрипта,
то будет ли это хорошая практика?

короче щас я делаю по колхозному, см в первопост:
Итого:
Колхозный способ, проголосовали:
За:
StepEver
> У меня так же.

Salamandr
> создаю свои классы

Против:
lookid
> Это в г каком-то а не классике

- - -

целый час убил, назвав метод get_***,
теперь называю из gt_***  и всё ок,
некогда мне со шарпосвойствами возиться
:лол , но случай реальный и сегодняшний ...

#7
(Правка: 18:34) 16:11, 12 дек. 2021

xlat-code
> да я вижу, что ноды в движке имеют атрибуты и теги,
> но пока я не разобрался что в них можно хранить.
>
> ваще я вижу что методы сериализации напиханы почти во всех классах урхи,
> но мысль хранить в строках числовые значения меня убивает,
> ну, т.е. есть хранить то можно, чтобы иметь возможность использовать урховскую
> сериализацию.

Итак, атрибуты есть и у нод, и у компонентов (в том числе, пользовательских). Храниться там могут не только строки, а любые типы, которые поддерживает тип Variant (а поддерживает он почти всё). У нод, и встроенных компонентов, атрибуты уже определены, а вот для самописных компонентов можно задать любые нужные атрибуты. Вообще, эти самые атрибуты нужны только для сохранения состояния объекта в файл, и загрузки из него, больше ни для чего, и если ты не собираешься куда-то сохранять состояние объектов, то можешь туда даже не лезть.

Теги — это просто этакие пометки, которыми можно пометить тот, или иной объект, например, для какой-нибудь проверки или выборки.

Для хранения чисел, и прочего, существуют переменные (опять Variant, опять почти все типы).

Что же касается твоего случая — пиши свой класс робота, унаследовав его от ScriptObject (AS) или LogicComponent (c++), делай внутри него что душе угодно, а потом вешай на ноду через CreateComponent(). Там уже определены виртуальные обработчики всех основных событий (обновление, обновление физики, и т.п.), и остаётся только переопределить нужные, поэтому

В главном игровом апдейте в цикле проходиться по этим юнитам и что-там двигать

не нужно — движок это сделает сам, тебе остаётся только делать что-то в соответствующих обработчиках. Именно под такой принцип работы заточен движок, и именно он является самым правильным.
Сам список роботов (массив указателей на ноды или компоненты), что бы в случае чего не перебирать все объекты в сцене, никто не запрещает хранить отдельно.

#8
(Правка: 20:49) 20:46, 12 дек. 2021

Dozorniy
> Итак, атрибуты есть и у нод, и у компонентов (в том числе, пользовательских).
> Храниться там могут не только строки, а любые типы, которые поддерживает тип
> Variant (а поддерживает он почти всё). У нод, и встроенных компонентов,
> атрибуты уже определены,
>
> https://urho3d.io/documentation/HEAD/class_urho3_d_1_1_variant.html
> https://urho3d.io/documentation/HEAD/_attribute_list.html
>
> а вот для самописных компонентов можно задать любые
> нужные атрибуты. Вообще, эти самые атрибуты нужны только для сохранения
> состояния объекта в файл, и загрузки из него, больше ни для чего, и если ты не
> собираешься куда-то сохранять состояние объектов, то можешь туда даже не лезть.
>
> Теги — это просто этакие пометки, которыми можно пометить тот, или иной объект,
> например, для какой-нибудь проверки или выборки.
>
> Для хранения чисел, и прочего, существуют переменные (опять Variant, опять
> почти все типы).
>
> Что же касается твоего случая — пиши свой класс робота, унаследовав его от
> ScriptObject (AS) или LogicComponent (c++), делай внутри него что душе угодно,
> а потом вешай на ноду через CreateComponent(). Там уже определены виртуальные
> обработчики всех основных событий (обновление, обновление физики, и т.п.), и
> остаётся только переопределить нужные, поэтому
>
> В главном игровом апдейте в цикле проходиться по этим юнитам и что-там двигать
>
> не нужно — движок это сделает сам, тебе остаётся только делать что-то в
> соответствующих обработчиках. Именно под такой принцип работы заточен движок, и
> именно он является самым правильным.
> Сам список роботов (массив указателей на ноды или компоненты), что бы в случае
> чего не перебирать все объекты в сцене, никто не запрещает хранить отдельно

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

#9
(Правка: 2:42) 2:39, 13 дек. 2021

xlat-code
> вашим сообщением буду обмазывать мою практику и буду поглядеть, что получится.
Пользуйся на здоровье) Только небольшое дополнение: как оказалось, атрибуты используются ещё и при сетевой репликации, так что если ты и сетевую игру пока не пишешь, то атрибуты всё так же можешь пока не трогать.

#10
15:58, 13 дек. 2021

Salamandr
> УРхо это ECS
Позвольте не согласится. Хотя "системы" и присутсвуют в урхе она всё же ближе к Entity-Component. Под ECS сейчас обычно понимают другой подход, вроде DOTS в Unity.

Salamandr
> +, совершенно верно
Забавно конечно читать ответы на удалённые сообщения.

xlat-code
> А как православно верно с точки зрения Урхи?
Я делаю логику которая работает относительно какой то сущности в виде компонента + в приложении коллекции объектов игровых по которым удобно бегать и делать что то глобально.

#11
19:31, 15 дек. 2021

GLoom
> Я делаю логику которая работает относительно какой то сущности в виде
> компонента

если расшифровать, то это так void Сущность(соnst Логика&); ?

#12
13:43, 17 дек. 2021

xlat-code
Перечитал, да хреново написал :)

Логика - это код который что то делает. Например переключает персонажа на регдол в случае смерти. Такой код может существовать в контексте сущности (entity, в терминах урхи - Node). По этому его засовываем в компонент (Component) который вешается на ноду.

А есть код который работает вне рамок одной сущности. И его удобнее делать глобальным, например в классе приложения.

Иногда удобнее для решения какой то задачи сочетать оба подхода.

#13
16:13, 17 дек. 2021

GLoom
> Перечитал, да хреново написал :)
Настолько, что даже я не понял)

Urho3DФорумЗАДАВАЙТЕ ВОПРОСЫ