Разумна ли такая архитектура? (2 стр)

Z
> Знаю я ету фичу, она вообще не помогает, когда нужно въполнять код в режиме дебага примерно. И многое другое.
извини, у меня, должно быть, проблемы с русским языком. это предложение следует читать как "примерный режим дебага"? или "примерное выполенение кода в режиме дебага"? в любом случае я ни о том, ни о том ещё не слышал. век живи - век учись.

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

> Скажи ето 90% програмистов, которъе работают именно в среде с GC. Потом подумай, почему так сложилось.
- наука нужна
- скажи это 90% людей, работа которых не имеет ничего общего с их специализацией.

из того, что 90% людей используют gc вовсе не следует, что профессиональные программисты, работающие на неуправляемых(unmanaged) языках не нужны. просто ниша применения unmanaged языков не слишком пересекается с нишей managed. и да, я считаю, что unmanaged языки отлично подходят под сценарий разработки игр одним-двумя программистами.

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

> При чем сдесь механизмъ синхронизации? Сдесь о менежменте тредов. Примерно штук
> 100-200-300 одновременно. При том, охота чтобъ они гарантированно засъпали и
> просъпались в нужную милисекунду и работали в нашем каком-то времени (game
> time).
> Достаточно специфично и невъполнимо для OS-а.
да уж, нативно это менеджить не очень-то удобно. один вопрос - нафига было наживать себе такой геморрой? почему бы не реализовать в том или ином роде scheduler, который бы этим всем управлял?

Suslik
>извини, у меня, должно быть, проблемы с русским языком.
Я незнаю, возможно.
Я говорю о том, что остановив программу, можно в ето же время паралельно въполнять код. Въполнить опять възов, через которъй только что прошли. Сменить стейт обьекта, в которъй вот вот зайдем дебагерром. Доступно все, ибо функции такие же обьектъ как все остальное, а интерпретатор можно запускать паралельно над одним и тем же стейтом - один ждет в режиме дебага, в breakpoint-е, а другой въполняет твой код.

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

> что профессиональные программисты, работающие на неуправляемых(unmanaged)
> языках не нужны
Кто тебе в голову заталкивает такие утверждения? Кто и где в етом треде такое говорил? Или тебе просто охота по душам поговорить, раз и так начали...?

> умышленно урезается с целью защиты от кривых рук. или с этим мы тоже поспорим?
Ето возможно. Я не о том. Я о другом. Или тъ опять таки не понимаеш? Ну, сорри...

> почему бы не реализовать в том или ином роде scheduler, который бы этим всем
> управлял?
Ето и есть scheduler. Ничего удобнее нет в коде прямо написать

Z
> Я говорю о том, что остановив программу, можно в ето же время паралельно
> въполнять код. Въполнить опять възов, через которъй только что прошли. Сменить
> стейт обьекта, в которъй вот вот зайдем дебагерром. Доступно все, ибо функции
> такие же обьектъ как все остальное, а интерпретатор можно запускать паралельно
> над одним и тем же стейтом - один ждет в режиме дебага, в breakpoint-е, а
> другой въполняет твой код.
я обычно это решаю, используя сериализацию. из состояния, когда воспроизвёлся баг, делаю дамп всех стейтов и всего, что нужно. потом во время сеанса отладки состояние загружаю и иду по какой угодно ветке выполнения, фигачу дебажный код, перезапускаю и вообще делаю, что вздумается. чувствую себя хорошо.

> Чем больше итераций - тем качество въше. Итерировать гейм-код перезапуском -
> автоматически значит что итераций будет меньше и особенно в конце проекта ето
> очень сильно будет действовать на нервъ.
я сказала, что отлаживать нужно компоненты по отдельности. ты утверждаешь, что компоненты по отдельности отлаживать долго, так как даже по отдельности они слишком громозки. вывод - разбиение на компоненты выполнено неграмотно?

> Кто тебе в голову заталкивает такие утверждения? Кто и где в етом треде такое говорил? Или тебе просто охота по душам поговорить, раз и так начали...?
восстанавливаю ветку спора:
я: ресурс менеджер лучше знает, как управлять своими ресурсами, чем абстрактный garbage collector
ты: скажи это 90% unmanaged программистов
я: если 90% программистов используют unmanaged языки, managed языки не нужны?
ты: <не увидел логики>

что-то не так?
> ... CreateThread( function() while true do local ol=GetObjects{ class="Unit", flag = enemy } if #ol>0 then print("Enemy found!") return end Sleep(100) end end
> Гибче етого некуда.
ну здравствуйте. у нас реализовано то же самое, только распределённое(не геймдев) и unmanaged. из приведённого кода я не понял, чем он принципиально гибче нашего unmanaged.

Suslik
Z скорее имел ввиду не полновесные трэды, а coroutine - stackless, легковесные нити, с низкими затратами на переключение. Давно читал хорошую статью про реализацию игровой логики на питоне с использованием до нескольких тыщ короутинс. Впечатлило.

Добавлено. Ёмоё, да хотя бы тот же Eve оnline сервер

Pilot Stargazer
> Z скорее имел ввиду не полновесные трэды, а coroutine - stackless, легковесные
> нити, с низкими затратами на переключение. Давно читал хорошую статью про
> реализацию игровой логики на питоне с использованием до нескольких тыщ
> короутинс. Впечатлило.
их принципиально неудобно реализовывать на native? я просто с таким не сталкивался и мне трудно представить сразу все перспективы и сценарии использования и подводные камни.

Suslik
Вроде, до последнего времени в С++ не было таких либ. Надо было писать свой нетривиальный велосипед.

Suslik
> чувствую себя хорошо.
Ето тъ просто большой софт и чужой в нем код не дебагал наверное. Негибко делать дамп всего, ето как еще один юнит тест поверх даннъх игръ в памяти написать.

> вывод - разбиение на компоненты выполнено неграмотно?
Ну вот, отдебагай и оттюнь поведение юнита, когда в него стреляет игрок. Где тъ будеш етот "компонент" дебагать, в вакууме? Отруби вообще всю графику, все что можно - то что нужно для такого дебага или тюнинга оно достаточно большое, чтобъ сделать перезапуск непрактичнъм решением.
Можно так работать и иногда въбора нет. Но со скриптом сильно удобнее.

>восстанавливаю ветку спора:
Идет речь про гейм-код. Какой там ресурс менажер?

>из приведённого кода я не понял, чем он принципиально гибче нашего unmanaged.
Да, но у вас OS-thread, да? Я не уверен как OS-threads будут себя вести в больших количествах и опять таки - нет гарантий как и кто из них будут въполнятся и в каком порядке.
Примерно для сетевой игръ получится недеретминированность. А со своим шедулером такого нет.

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

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

> Ну вот, отдебагай и оттюнь поведение юнита, когда в него стреляет игрок. Где тъ будеш етот "компонент" дебагать, в вакууме?
находим способ воспроизводить ситуацию, когда код работает неправильно. вывешиваем ишью. пинаем того, кто писал код, отвечающий за коллижн с пулям. он воспроизводит баг, после чего локально, в изоляции от всего проекта дебажит свою систему коллижн детекшна с входными данными из дампа.

> Идет речь про гейм-код. Какой там ресурс менажер?
извини, в таком случае я тоже потерял ветвь. забей.

> Да, но у вас OS-thread, да? Я не уверен как OS-threads будут себя вести в
> больших количествах и опять таки - нет гарантий как и кто из них будут
> въполнятся и в каком порядке.
> Примерно для сетевой игръ получится недеретминированность. А со своим шедулером
> такого нет.
именно. скедьюлер свой - проблем нет. я только не могу понять, откуда у тебя такое ярое стремление реализовать его unmanaged, а треды - managed. почему ты предполагаешь, что роль скедьюлера выполняет OS, а не мой код?

Suslik
> я опять с глупыми вопросами. зачем луа? какую цель преследует ТС, перекладывая
> функциональную нагрузку с С++ на lua?
Честно не пойму, шутка ли это?
№1 - Добавил джетпак, перекомпилируешь код релиз, профайл, дебаг, тестишь, надо увеличить скорость джетпака на 1%, опять все заново? Нет спасибо.
Отлаживать AI без скрипта вообще не представляю возможным.
№2 - С++ мне нужен для ядры игры, для всех корневых функций, для графического ядра наконец, но я не представляю зачем мне писать сверх эффективно банальное событие вроде IfDamaged->GlowRed, когда сделаю это быстрее на lua.
> я уже сталкивался с достаточным количеством горе-программеров, которые своей
> орхетектурой убивали производительность просто за счёт оверхеда. передачка
> сообщений туда-сюда между тысячей юнитов(РТС) - вполне реалистичный сценарий
> использования с вполне реалистично светящим оверхедом.
Не знаю как горе программисты передают сообщения, но у меня передача сообщения занимает чуть больше времени, чем вызов виртуальной функции, оверхед на передачу сотни таких сообщений эквивалентен оверхеду на расчёт реальной длины одного вектора, которые производится в графической системе черт знает сколько раз в секунду.
> редакторы приведённых в примере игр не используют нативные языки прежде всего
> потому что предполагается, что редактор будут использовать совершенно другие
> люди, не знакомые с кодом проекта.
В том числе и это мне интересно реализовать, не задумывались почему игры без нормального редактора забывают через пол года, а при наличии редактора продолжают развивать и через 10? Если редактора нет, то в конце концов находятся отважные люди которые его напишут, аля самодельных редакторов для diablo, fallout и baldurs gate.

В целом, мне хочется попробовать это реализовать.

Suslik
> этот дамп занимает вполне конечное количество ресурсов и выполняется уж точно
> не с большим оверхедом, чем перезапуск треда с этой системой из-под виртуальной
> машины.
Я незнаю, если надо в память поднять ряд анимаций для юнитов, пересоздать то да се для патфайдинга и прочее... Ето целъй ряд секунд. А сдампить некоторое, ето вообще победа над разумом, особенно если ето 3rd party мидлваря или жуткий ООП код, которъй создает большие полиморфнъе йерархии. Такое сдампить - ето работа!

>я не знаю, что ты называешь большим софтом.
Много кода, где почти все от всего зависит - типичная игра. Порезать до некого уровня можно, но от етого перезапуск бъстрее особо не будет. Наш конзольнъй проект в самъе лучшие времена заводился секунд за 10-15. Для итераций даже ето неприемливо, имея ввиду что еще надо переключатся между апликейшнами.

>извини, в таком случае я тоже потерял ветвь. забей.
Ну про гейм код ведь речь-то. Никто не хочет рендер писать на Lua...

>почему ты предполагаешь, что роль скедьюлера выполняет OS, а не мой код?
Если ето твой код, то интересно как тъ обрабатъваеш yeld, т.е. когда твой код засъпает и просъпается твоим же скедулером. В точке засъпания небось уже другой кусок кода, да? Т.е. можеш скажем "засъпать" внутри тройновложенного цъкла?

Stultus
> struct Component : OpaqueComponent {virtual void OnInit(); virtual void
> OnExit(); /*и.т.д*/};
> struct UpdatableComponent : public Component {virtual void Update();};
с чего UpdatableComponent наследуется (is-a отношение) от OpaqueComponent ?

> ctor()
> { /*Вызываются например 100000 раз за кадр (i.e. 60 раз у 1500 объектов)*/
> spatialComponent.link(rendercomponent);
> rendercomponent.link(spatialComponent);
> }
тоже ерунда какая-то - зачем пересоздавать и линковать компоненты (по сути - пересоздавать entity) каждый кадр? entity создаются очень редко, компоненты соответственно тоже.

> Так никто и не ответил, Вы сами передаёте Entity/Actor'у компоненты и начальные
> данные (i.e. mesh/material) или он сам их создает в отдельном
> factory/конструкторе? Или это вообще не имеет никакого значения? о_о
всё создание entity может являться созданием компонент и их линковки. лучше создавать однотипные компоненты толпой, потом для каждого entity линковать нужные.

> Ещё один вопрос... Допустим есть тот самый healthComponent и renderComponent, и
> как советуют здесь и здесь и ещё много где
healthComponent - это слишком большая гранулярность.

> RenderComponent::LinkToHealthComponent
> RenderComponent::LinkToJetPackComponent
перечитай - там рендеркомпоненты общие, которые нифига про hp или джетпаки не знают.

> Завтра мне понадобиться связь jetPackEffectsComponent <-> RenderComponent
связь не обязательно двусторонняя, чаще не так.

> Но это же гадость... Получается та же уродливая цепь связей или иерархий, но
> только на уровне компонент... (Я наверное чего-то не понял?)
если делать иерархии, то получаться те-же иерархии - магии не бывает. объективные явные связи это хорошо - осознаешь что делаешь, проще отладка, легче устранить ненужные. система в которой дали произвольно общаться кому угодно с кем угодно превращается в спагетти с намного меньшими усилиями, и не сразу понятен масштаб спутанности всего.

> Пока буду использовать сигналы и мессаджы, а там видно будет...
оно не спасет ни чем - только отладку усложнит. а абъюз всех этих boost::any,signal,bind - * для производительности и отладки.

Suslik
скрипты нужны в основном для того чтоб освободить "отцов" от рутинной работы, ведь для набивки 95% логики много ума не надо, поэтому с этой работой может справиться самый слабый гейм/левел дизайнер, который пару раз сидел на паре по программированию или видел паскаль в школе...

Xunter
> тоже ерунда какая-то - зачем пересоздавать и линковать компоненты (по сути -
> пересоздавать entity) каждый кадр? entity создаются очень редко, компоненты
> соответственно тоже.
Имелось ввиду не то, что конструктор вызывается столько раз, имелось ввиду, что ссылки кешируются в конструкторе если необходимо вызывать компоненты столько раз.

Xunter
> связь не обязательно двусторонняя, чаще не так.
Это я уже понял, ступил.

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

Реализовал пока все ручной линковкой, думаю с опытом придёт как правильно компоненты создавать. От монолита надо отвыкать, но не переусердствовать :)

Xunter
> создавать однотипные компоненты толпой, потом для каждого entity линковать
> нужные.
Можно поподробнее? Зачем толпой создавать однотипные компоненты? Можно конкретный пример посмотреть?

Stultus
> От монолита надо отвыкать, но не переусердствовать :)
от god-object может? а монолит - это такой кусок, без дизайна вообще.

> Можно поподробнее? Зачем толпой создавать однотипные компоненты? Можно
> конкретный пример посмотреть?
компоненты по типам лежат в массивчиках. препроцесс чанка сцены например позволяет получить данные для инициализации компонент в списках-массивах по типам и получить простой код ресурс-менеджера/загрузки сцены. подробней как нибудь потом.

Xunter
> от god-object может? а монолит - это такой кусок, без дизайна вообще.
Да именно он, в это время суток ничерта не соображаю.

Xunter
> подробней как нибудь потом.
Буду ждать подробного ответа, а то почти ничерта не понял. Это нечто вроде B дерева что-ли?