Тёмная тема
RPGman
> Нужно в любом случае аккуратно резать скриптовую часть от натива. Не пытаться
> делать идентичные структуры, или выставлять в скрипт полный рефлекшн нативного
> объекта.
> Не размазывать функционал равномерно по всем слоям, и не делать частых мелких
> функций на противоположной стороне. Вместо одного мелкого действия над объектом
> в натив нужно выносить пакетную обработку целой коллекции примитивов. И это
> рулит в любой связке языков, даже в жабе
Спорно, тогда это потребует почти всегда дополнительной прослойки для этого самого пакетного выполения.
3eR0.1ive
> Спорно
Аргументы - при аккуратном разрезе не появляется сотен классов, которые надо прибиндить, и количество переходов скрипт<->натив минимально.
> потребует почти всегда дополнительной прослойки для этого самого пакетного выполения.
Зачем прослойка? Вот написал ты нативную функцию, считающую умножение двух матриц. А зачем делать сто вызовов между скриптом и нативом, когда все те матрицы и так часть некоторой коллекции, и их всех можно считать одним вызовом. Просто другая реализация нативной функции, никаких прослоек.
Или, например, не спрашивать из скрипта события от клавы/мыши поштучно, а наоборот - при вызове функции скрипта передать ей все накопленные события одной табличкой.
RPGman
> Просто другая реализация нативной функции
RPGman
> при вызове функции скрипта передать ей все накопленные события
Другая реализация, и функция которая копит события, если этого УЖЕ нет в основном коде, и есть прослойка. Довольно разумно просто забиндить что есть, и не писать еще чего-то-там только для того чтобы скрипты не захлебывались. И анджелскрипт с этим прекрасно справляется.
3eR0.1ive
> Довольно разумно просто забиндить что есть
Ты не прав. Нет здесь ничего разумного.
Скрипт не должен перебирать меши чтобы найти пересечение луча с геометрией.
Скрипт не должен вычислять путь для ИИ, он должен вызвать функцию этот путь считающий.
Скрипт не должен поэлементно сохранять информацию об объекте, он должен вызвать функцию сохранения и все.
Скрипт не должен решать низкоуровневые задачи.
Скрипт работает на более высоком уровне, а значит прослойка делающая все низкоуровневые задачи все равно нужна.
У меня на работе народ очень не любит, когда какие-то задачи низкоуровневые прихоходится решать на уровне скриптов. И они безусловно правы.
Скрипты должны быть максимально простыми. Доходит до того, что часто скриптование вообще делают через визуальное представление без кода. Если бы у меня хватало навыков сделать такое скриптование - мы бы тоже давно отказались от редактирования кода.
А вы тут предлагает объекты из ядра напрямую биндить. :)))
3eR0.1ive
> Другая реализация, и функция которая копит события, если этого УЖЕ нет в основном коде, и есть прослойка.
Эта другая функция в основном коде. И она не оборачивает старую функцию, а заменяет ее. Старая просто выбрасывается на помойку, как негодная.
> Довольно разумно просто забиндить что есть,
Вот это способствует частым переходам между вм и нативом. Зачем тщательно что-то организовывать, когда можно позвать то, что есть?
И неважно, что оно было рассчитано на нативное использование, где цена вызова совсем не та.
А доведи ситуацию до абсурда, запусти вм на удаленном хосте - и такой подход сразу похоронит производительность.
> И анджелскрипт с этим прекрасно справляется.
Располагать к проблемному коду, чтобы потом прекрасно решать созданную проблему? :)
Легкий биндинг это замечательно, до тех пор, пока этим не начинают злоупотреблять. Тогда он просто маскирует спагетти из натива со скриптом.
@!!ex
> Если бы у меня хватало навыков сделать такое скриптование - мы бы тоже давно
> отказались от редактирования кода.
у нас были скрипты в виде графсхем - неудобно это
хотя кое где в этом есть смысл, допустим: стейты игры ну или места где нужны состояния и стейт машина, в графсхеме это выглядит нагляднее
@!!ex
> А вы тут предлагает объекты из ядра напрямую биндить. :)))
Нет, не предлагаю. Не до обсурда конечно, просто я встречал в коде нескольких проектов целые простыни функций созданных только для того чтобы забиндить их в луа скрипты.
RPGman
> Эта другая функция в основном коде. И она не оборачивает старую функцию, а
> заменяет ее. Старая просто выбрасывается на помойку, как негодная.
Это совсем другое дело, это вопрос организации кода таким обаразом чтобы он был юзабелен отовсюду.
RPGman
> Располагать к проблемному коду, чтобы потом прекрасно решать созданную
> проблему? :)
> Легкий биндинг это замечательно, до тех пор, пока этим не начинают
> злоупотреблять. Тогда он просто маскирует спагетти из натива со скриптом.
Проблемный код - это проблемный код, он не имеет отношения к скриптам в общем-то. Правильная организация кода должна присутствовать в любом случае.
И само собой злоупотреблять и пихать каждый чих в скрипты это конечно абсурд. Но легкость биндинга и скорость вызова позволяют не создавать таких простыней отдельных функций для биндинга про которые я писал чуть выше.
Pushkoff
> у нас были скрипты в виде графсхем - неудобно это
> хотя кое где в этом есть смысл, допустим: стейты игры ну или места где нужны
> состояния и стейт машина, в графсхеме это выглядит нагляднее
во, +1
такие схемы удобнее только для скриптования однотипных сущностей, типа стейта, плюшки, и т.п.
А всякая логика описанная таким способом быстро перерастает в монстроподобные схемы, где и создатель-то ногу сломит =)
3eR0.1ive
> Нет, не предлагаю. Не до обсурда конечно, просто я встречал в коде нескольких
> проектов целые простыни функций созданных только для того чтобы забиндить их в
> луа скрипты.
Какая разница куда я буду биндить функцию в Lua скрипт или в AS?
Будет таже самая простыня из прослоечных функций.
Причина - выше обозначена:
скрипт работает на более высоком уровне, а значит реализацию этих функций все равно делать.
@!!ex
> Будет таже самая простыня из прослоечных функций.
> Причина - выше обозначена:
> скрипт работает на более высоком уровне, а значит реализацию этих функций все
> равно делать.
Если требуется делать вот такие функции, то с кодом однозначно что-то не так.
3eR0.1ive
> Если требуется делать вот такие функции, то с кодом однозначно что-то не так.
Давай разберем конкретный пример:
Есть объект. Представляющий из себя NPC в виде человека с автоматом. У него есть параметры: номер текущей анимации, положение его в пространстве, принадлежность к одной из сторон конфликта и т.п.
Скрипт должен реализовать его ИИ.
Например ИИ может управлять его движением.
Вот у меня есть нативная функция MoveTo. Естественно в самом ядре она никогда не вызывается, эта функция прослойки, чтобы в скрипте не задавать анимации напрямую, не следить за перемещением, не делать поиск пути.
По твоему это плохое решение и у меня однозначно что-то не так с кодом. Ок, приводи свое.
@!!ex
> @!!ex
Вот геймдев, лишь бы поспорить да померятся =)
В данном случае эта функция MoveTo должна быть ни какой не прослойкой, а просто методом NPC, весь NPC должен быть заскриптован, если это не так, то это проблема организации кода. При чем сдесь ядро - не понятно.
3eR0.1ive
> Вот геймдев, лишь бы поспорить да померятся =)
Чем мы меряемся сейчас? Не понимаю тебя.
3eR0.1ive
Что значит методом NPC?
Это метод внутри NPC на уровне ядра игра. На уровне нативного кода.
При этом в нативном коде этот метод никогда не вызывается. Нативный код просто не умеет пользоваться этой функцией, все управление NPC осуществляется из скриптов.
[native]
NPC:MoveTo(); //Функция прослойка. Управляет движением. Считает путь. и т.п. Никогда не вызывается из нативного кода.
[script]
NCP.MoveTo(Position); //Скрипт вызывает нативную функцию, чтобы указать NPC куда идти. Скриптер не думает об анимации, поиске пути и т.п. Это не его задача.
Приводи пример, как эту же задачу решить правильно.
@!!ex
> @!!ex
Что то каша какая-то. В моем понимании ядро может быть у движка, у игры его нет, но хер с ним. Этот метод либо на уровне нативного кода и от туда может использоваться, либо полностью описан в скриптах. Как нативный код может не уметь пользоваться методами NPC которые там-же и написаны!?
Сдается что у нас разные понятия о построении логики слоев кода. Не хочу разводить воду и не буду.
Правка: Править сообщения не хорошо, но если считаешь что ради того чтобы убрать пару параметров из скрипта стоит слоить прослойки, пожалуйста.
3eR0.1ive
> Как нативный код может не уметь пользоваться методами NPC которые там-же и
> написаны!?
Сам движок игры не управляет NPC. NPC На уровне движка - это болванка без ИИ. Просто потому что на уровне движка неизвестно какого NPC захочет сделать геймдизайнер в конкретном случае. Может при встрече с врагом он будет убегать и поднимать тревогу, или атаковать, или еще 100500 действий, которые просто бессмысланно зашивать на уровне нативного кода.
3eR0.1ive
> либо полностью описан в скриптах
То есть делать на уровне скриптов управление анимацией, поиск пути, опрос графов и прочее. Зачем? Движение у всех человекоподобных NPC одинаковое. Какой смысл предоставлять интерфейс для управления этими вещами геймдизайнеру? Таким макаром можно вообще весь код вынести в скрипты, вдруг геймдиз захочет что-то совсем уникальное сделать. Из Варкрафта 3Д экшен.
Тема в архиве.