Войти
ПрограммированиеФорумОбщее

Компонентная система игровых сущностей. (комментарии) (28 стр)

Страницы: 124 25 26 27 28 29 Следующая »
#405
3:01, 24 июня 2013

x
> соблазн не является характеристикой какого-либо архитектурного решения
ещо как является, плохое архитектурное решение можно ухудшать и дальше, раз ынтерфейс у нас и так жырный, от чего предупреждал ещо дед Страуструп, то хуже не станет, если мы туда добавим ещо жыра : )

> Число жизней, текущее оружие, позиция и скорость, это всё где лежит?
позиция и скорость в пешке, остальное очевидно в тех подсистемах которые ещо не были упомянуты

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

хотя отцы геймдева могут иметь другую точку зрениия : )
http://t.co/sadgq6MSTz


#406
7:00, 24 июня 2013

Без примера все равно не понятно. :( На русском про компонентное программирование игр всего 2 статьи нашел, и обе написаны так, что создают больше вопросов чем ответов. И ни в одном нет элементарного примерчика.

#407
10:56, 24 июня 2013

Proha
Автор статьи как-то забыл упомянуть, что он пишет движок, а не игру и проблемы индейцев как потом на этом будет построена игра оставлено за кадром повествования. Это раз.

Термин "аспект", вообще употребляется в каком-то произвольном контексте. Это два.
Собственно говоря аспекты не заменяют бизнес-логику, а только очищают её от присутствия посторонних систем.
Т.е. внешние системы сами указывают в какие места текущего кода они хотят влезть. Вот тут вполне понятный пример приведен: http://en.wikipedia.org/wiki/Aspect-oriented_programming

Проще говоря, автор предлагает и так очевидную идею: делаем независимые "технические" подсистемы, а потом приходят скрипты и пользуются этим как хотят.
Конечно же в такой постановке подсистемам нафиг не нужен никакой общий объект. Он будет существовать в логике, т.е. выше уровнем.

Зачем сюда приписан весь этот гемор с двойными именами, наследованием и подпиской я не знаю. Точнее знаю, но промолчу.

#408
14:45, 24 июня 2013

x
> Только если составные части лежат в отдельных массивах где-то снаружи "жирного
> объекта".
тогда объект уже перестанет быть жЫрным.

#409
20:27, 15 авг. 2013

Вопрос по теме, кто обрабатывает менеджеры компонентов? Ведь им нужно вызвать - update.
А в скриптах менеджер обрабатывает update, линейно перебором из списка?

#410
20:51, 15 авг. 2013

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

#411
17:02, 16 авг. 2013

Pushkoff, а если потом прибавился еще менеджер из плагина, то как быть с ним? Править код ядра движка? Или для плагинов делать отдельную процедуру работы именно их манагеров?

#412
18:07, 16 авг. 2013

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

#413
12:39, 26 авг. 2013

Proha
> И ни в одном нет элементарного примерчика.
я сегодня решил пошуршать интернет, и нашел вот это
http://code.google.com/p/cistron/
то есть почти готовую систему компонентов для игр

x
> как потом на этом будет построена игра оставлено за кадром повествования. Это
> раз
А вот эта статья http://www.matthewklingensmith.com/Components.html
на примере объясняет чем компонентая лучше в играх... Ну и не забываем - в юнити тоже компонентая система

#414
14:50, 26 авг. 2013

war_zes
>А вот эта статья http://www.matthewklingensmith.com/Components.html
Автор смешной конечно, годами ел кактус потом вдруг узнал, что его можно не есть. Ну ок.

Тот второй тоже жжот со своим "new programming paradigm" в презентации.
Уже даже в вики статья есть про избитое высказывание http://en.wikipedia.org/wiki/Composition_over_inheritance
Не говоря уже про http://en.wikipedia.org/wiki/Duck_typing

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

>Ну и не забываем - в юнити тоже компонентая система
Хз к чему это вообще.

#415
15:59, 26 авг. 2013

x
> Хз к чему это вообще.
к вопросу нужности компонентной системы

x
> Автор смешной конечно, годами ел кактус потом вдруг узнал, что его можно не
> есть. Ну ок.
Я тоже сначала думал о ентити и ее наследниках.

x
> Уже даже в вики статья есть про избитое высказывание
Про Data-driven architectures тоже лет сто назад уже все сказали, а серьезно применять только недавно начали

#416
20:05, 24 сен. 2013

Можете поделиться логикой реализации обмена сообщениями? У меня менеджеры общаются между собой, тек которые в потоках и сам движок с ними - состоянием их, по средствам ивентов...
Ивент, грубо говоря, пакет с командой и указателями - откуда, зачем, данные. Так вот, в менеджеры он отдается на стек в метод... Пробовал умными указателями, ну что то ничего хорошего из этого не вышло...

#417
1:12, 25 сен. 2013

neio
> Пробовал умными указателями
std::function отличный event на самом деле, можно написать маленькую обёртку чтобы юзать weak_ptr, но обычно менеджеры ставятся один раз в начале приложения и стоят до конца

>которые в потоках
потокобезопасный контейнер для событий по схеме много-производителей-один-потребитель решает практически все проблемы

#418
2:15, 25 сен. 2013

Sh.Tac.
> по схеме много-производителей-один-потребитель
Можно пример?

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

#419
13:04, 25 сен. 2013

neio
расскажи как это работает у вас сейчас

Страницы: 124 25 26 27 28 29 Следующая »
ПрограммированиеФорумОбщее