Разделение рендеринга на основе Entity /Component на основе логики

Я заметил в Unity3D, что каждый объект gameObject (entity) имеет свой собственный компонент визуализации, насколько я понимаю, такую ​​логику обработки дескриптора компонента.

Интересно, является ли это обычной практикой в ​​механизмах на основе сущностей /компонентов, когда у одного объекта есть компоненты визуализатора и логические компоненты, такие как позиция, поведение вообще в одном поле?

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

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

Я бы это сделал, , что этот объект будет содержать только логические компоненты, такие как AI, transform, scripts плюс ссылка на mesh или sprite. Затем какой-то объект с компонентом Camera сохранит все ссылки на объект, который будет видимым для камеры. И для того, чтобы отобразить все эти вещи, мне пришлось бы передать ссылку Камеры на класс Renderer и отобразить все спрайты, сетки видимых объектов.

Является ли такой подход чем-то неправильным?

5 голосов | спросил Denis Narushevich 6 MarpmWed, 06 Mar 2013 16:31:46 +04002013-03-06T16:31:46+04:0004 2013, 16:31:46

4 ответа


5
  

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

В некоторых системах сущностей компоненты содержат только логику. В других случаях они содержат только данные. В других же они содержат и то, и другое. Я бы, конечно, утверждал, что включение фактических команд рендеринга (как в коде OpenGL или D3D) в компонент рендеринга не является идеальным (см.

ответил Josh 6 MarpmWed, 06 Mar 2013 20:33:56 +04002013-03-06T20:33:56+04:0008 2013, 20:33:56
3

Вы правы и неправы одновременно. Модель entity /component очень гибкая, и это одна из причин ее использования. То, что вы очень хорошо отмечаете, это то, что он путает симуляцию (логику игры) и презентацию (графический и звук).

Прежде всего следует отметить, что компонент не означает, что он действительно что-то сделает. Например, MeshRenderComponent может не отображать сетку. Он может быть реализован как содержащий все релевантные данные и передать фактический рендеринг в «систему» ​​двигателя.

Это имеет два преимущества. Во-первых, объект может быть полностью создан на сервере. Все компоненты, которые не работают на сервере, - это просто немые контейнеры данных. Во-вторых, система со всеми резидентными данными может работать более жесткими и эффективными циклами, а затем при перемещении компонентов.

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

Второе, что нужно отметить, - старый добрый вопрос: «Это имеет значение?»

Это более сложный вопрос. С точки зрения программного обеспечения решение ясно, у вас чистое симуляция и чистый уровень представления. (Model-View-Controller) Но когда дело доходит до художников и дизайнеров уровней, становится все труднее. Вы упоминаете Unit3D, и вы можете увидеть, откуда я.

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

Как выясняется, как Unity3D запутывает логику и презентацию, так это то, как большинство не инженеров действительно думают, как все должно работать. (И не пытайтесь объяснить, почему мультиплеер так сложно реализовать с такой моделью ...)

ответил rioki 6 MarpmWed, 06 Mar 2013 18:38:19 +04002013-03-06T18:38:19+04:0006 2013, 18:38:19
0

Кажется, что Renderer - это просто компонент ( http: //docs.unity3d. ком /Документация /ScriptReference /Renderer.html ).

Насколько я понимаю, Renderer предоставляет общие функции для более конкретных унаследованных компонентов:

http://docs.unity3d.com/Documentation/Components/class -MeshRenderer.html http://docs.unity3d.com/Documentation/Components/class-ParticleRenderer. HTML http://docs.unity3d.com/Documentation/Components/class-LineRenderer. HTML

Насколько я знаю, Unity поддерживает несколько базовых рендерингов для своих различных платформ, Direct3D и OpenGL среди них:

Использует ли Unity для ПК Direct3D или OpenGL?

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

Если вы уже прочитали общую информацию о архитектурах компонентов-сущностей, то вы знаете, что объекты обычно являются наборами компонентов. Компонент может вообще быть чем угодно, включая физику, анимацию, логику игры и т. Д. Зачем относиться к графике по-другому?

Некоторые архитектуры систем с компонентами-объектами имеют тенденцию вкладывать больше логики в компоненты, в то время как некоторые концентрируют все это в системах и используют компоненты как чистые данные.

Прочтите это, если вы еще этого не сделали:

https://stackoverflow.com/questions/1901251/component-based -game двигатель-дизайн /3495647 # 3495647

ответил Den 6 MarpmWed, 06 Mar 2013 18:00:53 +04002013-03-06T18:00:53+04:0006 2013, 18:00:53
-3

Все, что я могу сказать, это GUI.Button - худший вид кода, который может написать любая команда разработчиков. Это может привести к замедлению, а что нет. Рендеринг и логика в одном цикле? Почему же Unity нуждается в функции обновления? Если Unity захотела одновременно рисовать и запускать логику, то ей не нужны функции обновления ... В команде, которая работает над большими проектами, обрабатывая код в OnGUI (), логика - это катастрофа. Я бы предпочел не используйте Единство только по этой причине. Другая причина заключается в том, что концепция управления загрузкой и разгрузкой означает, что управление памятью осталось на Unity, чтобы решить, что совсем не идеально подходит для любого программиста. Программист должен знать, где и когда используется память, но Unity скрывает все это.

Насколько я понимаю, Unity позволяет вам создавать много кода и вводить полную игру в течение нескольких дней, если не через несколько месяцев. Но когда вы на самом деле пытаетесь продать эту игру через PSN или XBOX, вы раскаетесь в том, почему выбрали Unity, потому что теперь у вас есть игра, которая работает, но вы не контролируете ее управление памятью или FPS из-за того, что Rendering and Logic написана в тот же код.

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

По моему мнению, эта структура компонентов Entity не подходит для крупных команд, создающих огромные игры. Попробуйте сделать MMORPG на Unity3D ... вы узнаете, что такое PAIN! : D

ответил user1505148 25 J0000006Europe/Moscow 2013, 04:55:41

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132