Здравствуйте, ylem, Вы писали:

F>>а если "в природе" самого объекта есть возможность изменять "здоровье", то ф-ция takeDamage(entity) будет делать entity.decreaseHp(n), а ф-ция heal(entity) будет делать entity.increaseHp(n)
Y>И опять же, я бы предпочел не менять здоровье снаружи так явно, потому что, например, у каких-нибудь десептиконов вообще нет здоровья в обычном понимании или кого-нибудь лечи-нелечи, все бестолку.

это уже зависит от подхода.
ничто не мешает сделать пустую реализацию метода. а если там ещё и entity component system с HealthComponent, то только inc/dec и останутся.

F>ничто не мешает сделать пустую реализацию метода. а если там ещё и entity component system с HealthComponent, то только inc/dec и останутся.

Все-таки пошел читать про ECS. Спасибо.

Здравствуйте, Qulac, Вы писали:

V>>>В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
V>>>Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

I>> Entity-Component-System это конкретный подход, можно сказать архитектурный паттерн и он нисколько не противоречит ООП.

I>>ООП нужно не для наследования-инкапсуляции-полиморфизма, а для управления сложностью решения. Т.е. структурирование решения.
I>>Как только ты решил задачу, её нужно перевести в код. Вот здесь и начинает работать ООП. А Entity-Component-System это уже конкретный вариант дизайна.

I>>Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

Q>Это реализация игровой бизнес-логики, а мы про отрисовку говорим.

Отрисовка это частный случай System в этой архитектуре. Вся бизнес-логика всего лишь разные System, которые между собой взаимодействуют. Коллизии, движение, урон и тд — это все System. И отрисовка здесь ничем не выделяется.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.

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

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

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

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

При фотореалистичном подходе объект не отрисовывается сам по себе, отрисовывается сцена, с конкретными источниками света и с конкретным положением зрителя этой сцены. В процессе какие-то участки оказываются затененными, а какие-то бликуют, а где-то появляются отражения. Но не потому что у нас есть объект "блик" или "тень", а потому что вся сцена рендерится в картинку и картинка получается вот такой. При этом объекты только содержат информацию о своих цветах и свойствах поверхности, а рисовать сами себя, конечно, не умеют. Рисуется сцена целиком. Например, если свет выключить, то всё должно нарисоваться черным...


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

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