- aml
- Постоялец
> Именно так на С++ не сделать, но есть масса других вариантов. А здесь преимущество только при ожидании асинхронных операций.
Асинхронные операции встречаются сплошь и рядом - запросы к базе, подгрузка ресурсов по сети, ожидание ответа от других серверов. Я тов. outcast'у о том и писал, что пока он пишет движок для игры, реальную пользу от скриптов не оценит. А когда дойдёт собственно до игровой логики, увидит, сколько эти операций там напичкано. Я не знаю, какими играми он занимается, но в MMO их просто немерено.
Другие варианты, конечно, есть. Но они сложнее в реализации.
> Проблема в том, что не во всех проектах логика поведения такая простая. И стейты или события все-равно будут. А грамотно написанный С++ код более скалируемый, чем скрипт.
В любом проекте есть места, где логика будет не такая простая - это 100%. Но практика показывает, что большая часть кода не требует ничего большего.
Ataman
> Именно так на С++ не сделать, но есть масса других вариантов.
Слушаю с интересом какие, если можно ограничится только годнъми. Чтобъ код бъл нормально читаем и чтобъ можно бъло без труда възъвать асинхроннъе операции.
> Проблема в том, что не во всех проектах логика поведения такая простая.
Я думаю имелось ввиду та простота, которая исходит из линейно написанного кода перемешанного с асинхроннъми операциями vs автомат. Тогда незнаю, что сложное имеется ввиду, что нельзя заимплементить первъм методом...?
Z
> > Насчет локальных функций не совсем понял в чем смысл?
> x = function() .... end
замыкание можно прикрутить - будет неплохо смотреться :)
Z
> Слушаю с интересом какие, если можно ограничится только годнъми
Сила натива в универсальности и масштабируемости - для каждой проблемы можно найти свое решение.
Если говорить про гуи - ивенты, листенеры, наследование. Для модальных диалогов - рекурсивный основной цикл апдейта, но это уже ограничения. Если про сеть, загрузку ресурсов и прочие хардварные вещи - перевод асинхронного процесса в синхронный, либо вообще скрытый с помощью соответствующих систем. Тоже самое надо по большей части и для скрипта делать - если не использовать многопоточный интерпретатор или vm.
Тики логики в зависимости от проекта могут требовать достаточно жесткой синхронизации, если ето не так - очередь на апдейт и все.
А вас послушать, так без луа или питона игру не сделать =)
Да нет, сделать то можно, глупо с етим спорить. Скорее акцент, что создание гейм-кода будет сложнее и въглядеть он будет не так читаемо, как мог бъ.
Как оно бъло в проектах где работал? Пример, если можно, чтобъ представить...
aml
> Я не знаю, какими играми он занимается, но в MMO их просто немерено.
Мой поинт в том, что выбор инструмента для проекта должен быть взвешенным. Если для вашей ММО и вашей команды удобны скрипты - значит надо использовать. Но не надо забывать и об альтернативных вариантах.
aml
> Но практика показывает, что большая часть кода не требует ничего большего.
У всех разная практика и разная специфика проекта. Например, я хочу (гипотетически) сделать мультиплеерную РТС для 2 разных платформ - ПС и Мак. Очевидно, использую свои мат. библиотеки для детерминированности игры. Скрипт не подходит. Пишем на спп с оглядкой на разные компиляторы. Второй пример, использование для ИИ (логики) ФПС дата-дривен бихейвиор-три. Тут в пору свой специфический велик прикручивать, а не надеяться на луа. А если GOAP - о каком скрипте вообще можно говорить, тут бы на нативе взлетело =)
Ataman
> Сила натива в универсальности и масштабируемости - для каждой проблемы можно
> найти свое решение
сила натива в унификации всего чего можно обработать единообразно : )
всякий кастомный код (ad hoc под задачу), который встречается в проекте ровно один раз, вызывает желание оторвать голову геймдизу
потому как при этом запускается целая бодяга:
1. написать прототип решения
2. написать тесты
3. убедится что все тесты ОК
4. интегрировать решение в систему
5. переписать тесты
6. убедится что все тесты ОК
но такова к сожалению игровая логика
скрипт позволяет вон те пункты свернуть очень быстро в короткие итерации "накодал - проверил"
а скорость разработки это критически важный параметр всего проекта
Ataman
Согласен на 100%. Каждому инструменту своё место. Надо их знать и уметь ими пользоваться.
Sh.Tac.
Голову геймдизам отрывать бесполезно - у них три новые отрастают. Вообще да, неплохо бы. А то что ни идея - обязательно дохрена кода нового хотят.
Z
> Как оно бъло в проектах где работал? Пример, если можно, чтобъ представить...
Да по разному. Но луа или питон не использовались. Зато была ява ну и специфические велосипеды для ИИ и миссий. Но это теперь легаси, от которого нет возможности избавиться =). Про UE и так все понятно.
Z
> Ну, назъвать отсуствие фич - каким то плюсом язъка я бъ не стал. Его нет -
> точка. Делать локальнъе функции нельзя и все тут. А они удобнъе, код нагляднее
> (сразу видно scope) и т.д.
Ну ладно - убедил
> Да какие блин дизайнеръ, не видел в жизни дизайнеров, которъе бъ писали на
> скрипте... У нас один из лидов пересел на скрипт уже как год - просто бъстрее
> игровой код там писать, логику всякую и прочее.
Да, я понял что у вас не так как у нас в этом смысле.
aml
> Вот тут как раз синтаксисом разница не обойдётся. Если мы хотим, чтобы на C++ у
> нас такой же код работал, надо его запускать в отдельном потоке операционной
> системы. Пока поток один, два или даже 10 - проблем нет. Если же вы захотите
> описать логику каждого бота таким простеньким скриптом, у вас будет на каждого
> бота по потоку. 100 ботов - и система будет захлёбываться. Вам придётся
> отказаться от такой простой записи поведения и перейти к явному заданию
> конечного автомата - к какому-нибудь событийному механизму. Код будет расти и
> усложняться.
Ок убедил, для параллельного выполнения, если нехочется заморачиватся сильно с написанием менеджера задач, наверное скриптовые "потоки" будут уместнее.
aml
> Я тов. outcast'у о том и писал, что пока он пишет движок для игры, реальную
> пользу от скриптов не оценит. А когда дойдёт собственно до игровой логики,
> увидит, сколько эти операций там напичкано.
Товарищ outcast к счастью движок для игры написал и даже не для одной и не планирует заниматься написанием нового в обозримом будущем, так что преимущества скриптописания над нативом постигает из этого топика :Р
> Я не знаю, какими играми он
> занимается, но в MMO их просто немерено.
ММО не занимался, возможно там все по другому.
Z
> Как оно бъло в проектах где работал? Пример, если можно, чтобъ представить...
В первом проекте был самописный велик для описания сценариев миссий, но собственно напрямую его никто не использовал, т.к. все это дело генерилось из редактора, в котором писалось визуально (написанием сценариев занимались нелюбимые тобой дизайнеры :) ), потом для продолжения пытались прикрутить Lua но я незнаю чем все это закончилось и был ли от этого толк.
Во следующем проекте и его продолжениях тоже самопальный велик, но уже более продвинутый с нормальной многопоточностью синхронизациями и т.д. (но в рамках предметной области), на нем писалась так же обучалка и всякое по мелочам. Скрипт собственно так же редактором генерился, но некоторые специфические вещи иногда вручную.
В крайнем проекте и аддоне к нему скрипты не используются, т.к. ИИ без них справляется в миссиях, а для целей отличных от сценариев целесообразность их использования пока не видна.
Спасибо за ответъ, но как-то не стало понятно как перемешиваются асинхроннъе операции с кодом, или может бъть их просто нет?
Т.е. bla-bla, FindPath(), bla-bla, trace rays, bla-bla
Как ето в вашем коде въглядит?
И как AI тикает - все сделано автоматом с тучей стейтами?
Z
> Спасибо за ответъ, но как-то не стало понятно как перемешиваются асинхроннъе
> операции с кодом, или может бъть их просто нет?
У нас по сути как таковых небыло. Т.е. в определенный момент тика игровой логики зовется интерпретатор скрипта, который в цикле делает шаг (или несколько) по активным скриптам.
> Т.е. bla-bla, FindPath(), bla-bla, trace rays, bla-bla
> Как ето в вашем коде въглядит?
> И как AI тикает - все сделано автоматом с тучей стейтами?
FindPath в отдельных потоках асинхронно. trace rays - по разному, часть синхронно когда позвали, часть "асинхронно".
Остальное bla-bla синхронно с заранее заданной частотой дискретизации. Т.е. некоторая логика ИИ может и раз в 10-30 секунд тикать, а для физики дробится тик, так чтобы время константное всегда было.
На данный момент у меня получилось нечто вроде:
[application layer]<-window, resource, memory pools,... etc
entities, components, factories<-[gamelogic layer ]<-input, gui, audio, physics, ai, graphics, scripts... etc
Есть некая плоская иерархия entity, вроде:
[avatar], [creep], [building], [misc]...
Все entity по сути представляют сборище компонент. Любой entity может наследоваться через lua и как-нибудь расширяться, т.е. [building]->[tower], [misc]->[item]
У каждой компоненты есть идентификатор, на данный момент генерируется он хитрым препроцессингом/темплейтом, т.е. unique_id<ComponentMapLocatable>::value будет уникальным идентификатором компоненты. Компоненты общаются через сигналы или через ссылки если их привязать вручную на нейтив коде.
Каждому entity посылается от [gamelogic layer] набор ссылок на factory, типа, xxxRenderableComponentFactor, xxxAIComponentFactory, entity сам определяет использовать их или нет. Не уверен, что это лучшая идея, пока над этим думаю.
Отдельно от всего этого счастья существует редактор, в нём частично методом тыка, частично методом скриптования можно что-нибудь расширить. Приблизительно это выглядит так:
additem - [name: "spoon"][damage: 0][icon: (picture)][model: (model)]
.... addscript. Скрипт должен выглядить условно так: (псевдокод)
exec_this_when_attacking(target) -- something end pc= get(unitcomponent) -- lookup очень быстрый и не занимает много памяти, бинарное дерево из натуральных чисел pc.on_attack(exec_this_when_attacking) -- регистрируется callback
Реально же получается так (псевдокод):
class 'extended_spoon_item' (item)
function extended_spoon_item:__init(item)
item.__init(item)
end
function extended_spoon_item:OnAttack(target)
-- something
item.OnAttack(target)
endВ общем какой-то фейл получился :) Не пойму как нормально связать нейтив и скрипт. Если писать чисто на скрипте, то можно соответственно использовать скриптовые callback'и и прочие плюшки, если все писать на нейтиве, то можно выстроить скалируемую систему и легко все расширять. А хочется связать нейтив и скрипт...
outcast
> Остальное bla-bla синхронно с заранее заданной частотой дискретизации.
Не ну, а в коде то как ето въглядит? Могучий switch по состоянию?
Stultus
> Не пойму как нормально связать нейтив и скрипт.
Тоесть? В нейтив скрипт пишет или запросъ на патфайдинг или колижн, или всякие read-only состояния, важнъе для рендера/аудио. Все остальное в скрипте.
OnDamage и собътия - немного коряво. И вообще етот data driven можно убить и просто создать фабрику обьектов по имени. Создал обьект, възвал ему метод скажем Init и пусть он дальше живет как ему угодно - хоть дамаг раздает, хоть получает, етц.
Тема в архиве.