Добро пожаловать в чат pro.lua, Nick! Ознакомься с правилами чата (в описании и прикрепленном сообщении), и присоединяйся к обсуждению.

подскажите, если у меня nginx+lua и очень хочется lua 5.3, то проще переписать все например на тарантул и нгинх оставить только фронтендом, или есть еще варианты?

Так просто не выйдет и скорость потеряешь. Ну, или биндить lua5.3 к nginx, мда.

оно там не очень совместимо

Тарантул с openresty - отлично совместимы, там один и тот же luajit (5.1).

а как соотносятся luajit и lua по версиям? 5.3 я хочу из-за поддержки юникода

Ммм. Ставишь либу на luajit с юникодом, ту же самую что и в 5.3.

Чего там у тебя на С++ такого на 20к строк?

а как соотносятся luajit и lua по версиям? 5.3 я хочу из-за поддержки юникода

В общем, это не повод отказываться от luajit, он слишком крут. Ещё спасибо скажешь, когда у тебя бек заработает в 30-80 раз быстрее, и ты сможешь подключать абсолютно любые с/с++-либы на лету без перекомпиляций.

подскажите, если у меня nginx+lua и очень хочется lua 5.3, то проще переписать все например на тарантул и нгинх оставить только фронтендом, или есть еще варианты?

а зачем тебе 5.3? LuaJIT же лучше соба^W!

;)

а как соотносятся luajit и lua по версиям? 5.3 я хочу из-за поддержки юникода

смотря что именно ты понимаешь под поддержкой юникода

если юникодные переменные, то они есть и в luajit

если string.utf8, то да, есть либа. Подключаешь её к JIT и не знаешь проблем.

https://github.com/dibyendumajumdar/ravi o..o

ravi - не то

Вот эта - идентична 5.3 https://github.com/starwing/luautf8

Чего там у тебя на С++ такого на 20к строк?

По большей части низкоуровневые вещи, либо те, которые легко обобщаются вне зависимости от игры. Рендеринг, ввод, коллизия, ECS, GUI, тайл мэпы и пр. Я использую SFML, который по идее уже должен сократить количество строк кода для многих вещей, но все равно как-то накопилось. А вся игровая логика на Lua. Пока что контента маловато, так что 5к строк пока что. :)

ECS \o/

...а насколько большой мир поддерживается? Какие тыйлы и взаимодействия между ними?

По большей части низкоуровневые вещи, либо те, которые легко обобщаются вне зависимости от игры. Рендеринг, ввод, коллизия, ECS, GUI, тайл мэпы и пр. Я использую SFML, который по идее уже должен сократить количество строк кода для многих вещей, но все равно как-то накопилось. А вся игровая логика на Lua. Пока что контента маловато, так что 5к строк пока что. :)

а ты юзаешь наследование\виртуальные методы?

а ты юзаешь наследование\виртуальные методы?

Нафиг, ECS же?

Я не тестировал пока что очень большие карты, но по идее поддерживаются. Карты состоят из чанков тайлов 8x8, хранятся в разреженной матрице, поэтому место не тратится впустую и в итоге можно эффективно хранить не только прямоугольные карты. С тайлами пока мало взаимодействий, коллизия, а также можно коллбеки писать в зависимости от типа тайла (например сделать тайл, который будет тайлом пропасти, в результате столкновения с которым игровые объекты будут "падать")

Нафиг, ECS же?

нууу, знаешь, лично мне такая система не нравится

Я не тестировал пока что очень большие карты, но по идее поддерживаются. Карты состоят из чанков тайлов 8x8, хранятся в разреженной матрице, поэтому место не тратится впустую и в итоге можно эффективно хранить не только прямоугольные карты. С тайлами пока мало взаимодействий, коллизия, а также можно коллбеки писать в зависимости от типа тайла (например сделать тайл, который будет тайлом пропасти, в результате столкновения с которым игровые объекты будут "падать")

А можно например сделать тайлы, которые создают, передают и потребляют некие ресурсы с соседями?

а ты юзаешь наследование\виртуальные методы?

Наследование только в таком духе. Component <- GraphicsComponent ;) А все типы игровых объектов описываются в JSON

нууу, знаешь, лично мне такая система не нравится

Чем же?

оу...

Наследование только в таком духе. Component <- GraphicsComponent ;) А все типы игровых объектов описываются в JSON

Почему json, а не луа?

Чем же?

тем что каждый компонент должен соответствовать родителю

а у меня там сооовсем все разное

...эм

ECS это когда у тебя куча мелких компонентов, которые практически не связаны друг с другом

И ты можешь легко навесить требуемые на любой объект игровой

например, класс C_Mesh, в котором находятся несколько методов по управлению буфферами, несколько буфферов и еще материал с текстурой, а в классе C_ParticleEmitter куча совсем других вещей

и наследовать все от компонентов как-то не хочется

ибо тогда в родителе придется объявлять все это

А можно например сделать тайлы, которые создают, передают и потребляют некие ресурсы с соседями?

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

а, например, в классе для работы с частицами нахер не нужны буфферы нормалей и tangent\bitangent, а так же методы их обработки

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

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

и в C_Mesh нахер не нужны поля и методы для обработки частиц

...ты вообще про что-то другое говоришь, ибо это не ECS

ну да, я не реализовывала ECS за ненадобностью

Почему json, а не луа?

Долго использовал Lua, но потом захотелось явно отделить данные от логики. JSON для данных как-то больше нравится. Особенно тем, что не требует состояния Lua, легко парсится и сериализуется. Это нужно для визуального редактора Entity

я видела исходники движков с использованием ECS, но имхо, сложно понять что к чему относится

и что где используется

Фигово написали видимо..

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

Сейчас такие вещи могут делать только Entity. Я думаю, что тайлы можно было бы сделать похожими на них чуть больше. :) Ну или создавать для особых тайлов Entity в соответствие

ECS хорошо использовать в 2D движках, вроде как, ибо все их используют именно там. Для 3D я не видел такого

CryEngine не использует это, Banshee Engine, Serious Engine, XRay Engine

В 3d только так используют. Тот же UE4 - ECS И вообще философия пошла от 3d игр, которым понадобилась тонна производительности.

да, (а)уе4 этим страдает

Deus Ex, Neverwinter Nights, Thief, Tony Hawk's Pro Skater... Сейчас тот же Overwatch написан на ECS. Первое, что в голову пришло. :)

а у тебя есть их исходнки?

и да, thief на UE написан

Неа. Знаю об этих вещах по блог постам и презентациям на конференциях К сожалению пока что на коммерческие игры с открытым кодом на ECS не натыкался. Давно ничего крупного не раскрывали

А чем ESC отличается от всего остального? Условно, куча объектов с координатами и размерами, отнаследованные от класса сущности, и все в куче крутятся?

хз, я пишу, конечно, лютый говнокод, но люблю, когда этот говнокод понятен

Они ещё создаются из блоков, компонентов Какое-нибудь дерево имеет collision, graphics, transform А враг имеет ещё ai, health и пр.

имхо, ECS сложнее для чтения, чем система ВЛОБ

Они ещё создаются из блоков, компонентов Какое-нибудь дерево имеет collision, graphics, transform А враг имеет ещё ai, health и пр.

в игре не обязательно будет враг

в игре не обязательно будет враг

Так это же тупо пример

имхо, ECS сложнее для чтения, чем система ВЛОБ

Это что за влоб?

пишешь в лоб

А, типа сущности с повешенными на них классификаторами, а ля "drawable/collidable/updatable".

просто пишешь, как хочешь, а не по шаблону

Ещё стоит упомянуть про системы, которые потом итерируют по всем активным компонентам и что-то делают для них. Например проверяют коллизию на Collision component Да, что-то похожее на то, как раньше делали (и делают, я думаю) Как наследование от IDrawable, ICollidable и пр. Только вместо наследования композиция

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

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

эххх

Отбирать, в смысле знать какие объекты обновлять, а какие - нет?

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

Расслабься. Ты всегда писала хуйню, пишешь хуйню и будешь писать хуйню, это нормально : )

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

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

Отбирать, в смысле знать какие объекты обновлять, а какие - нет?

Ну вроде того. Я показывал пример где обрезаем сущности в spartial hash коллайдера ориентируясь по камере, и это оказалось самым рациональным. Но для этого нужно иметь этот самый spartial hash и цеплять сущности к нему, чтобы была какая-то пространственная индексация. Очень далёкие объекты не нужно обновлять, даже если они активны. А прохождение по списку из сотен миллионов сущностей - долго.

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

Кстати, в чём проблема с ООП? Медленно плодить объекты и цеплять к ним методы? Или прописывать кучу параметров для каждого?

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

ООП бывает разный Самая проблематичная система, это когда у тебя есть наследование в духе Character -> Enemy -> Troll -> SuperMegaTrollWithGuns Если много типов объектов, то такое дерево быстро разростается и его не так удобно поддерживать. Объекты часто тащат за собой много ненужных зависимостей, особенно данных. Часто любят в класс Entity/Character напихать всего подряд, в итоге у самых простых объектов есть много объектов и членов класса, что как-то не ок. Чуть лучше - это когда ты наследуешь от IDrawable, ITransformable и пр. Это почти уже ECS, где различные аспекты объектов разбиваются на разные классы, а затем Entity собираются из них. И это очень близко к ECS и можно даже так ECS написать, но проблема в том, что ты не можешь создавать без рекомпиляции новые сущности. Т.е. если я захочу сделать новый тип объекта, я пропишу один JSON и всё. Иначе нужно было бы писать код, рекомпилировать его и пр. В индустрии, где те же геймдизайнеры хотят писать скрипты и не заниматься C++ кодом, это особенно полезно. Можно изменить многие вещи для каждого типа объекта не прикасаясь к коду вообще. :)

кстати, какую либу для json ты юзаешь