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

> Он же будет работать в одном потоке? Совсем не айс для современных процов.

Ну так запустите интерпретатор в отдельном.

aml
> Всё равно какие-то data-driven части в игре есть. Карты, расстановку неписей и
> прочие вещи программист всё равно не будет иплантировать прямо в код. Это будут
> отдельные ресурсы. Всё равно механику загрузки надо реализовывать. В этом месте
> можно передать управление скрипту, чтобы он вернул карту или список неписей.
> Скрипт считает те же самые ресурсы без значимых потерь в производительности,
> откуда надо - хоть из файла fopen, хоть по сети urlopen. Если завтра

Эти задачи прекрасно решает редактор, непонятно нафига тут скрипт. Ну разве что если лень писать редактор, то заменить его скриптом, но это имхо экстремальный метод.

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

Не знаю, у нас вроде как-то справляются с ИИ без подборов и тюнинга на лету, логами и предварительными расчетами и симуляциями, но мне встречалась и обратная ситуация.
Насчет внутриигровых редакторов, не совсем понятно зачем им скрипт.

Z
> Я вот писал редактор дорог - перезагружал его 2-3 дня сотни раз. Если мне надо
> бъло перезапускать проект - ето идти стрелятся.

Насчет перезапуска проекта не совсем понятно в чем сложность?

> Та же история с AI для
> случайнъх разговоров, юзание всяких обьектов и симуляция жизни - ее надо
> смотреть, тюнить, смотреть. Научно, сесть и в 2-3 раза написать - ето я незнаю
> как...
>

Пишется простая модель с кубиками, отлаживается поведение. Дальше сложнее - запускается симуляция когда синие кубики под управлением ИИ бьются с красными кубиками под управлением ИИ, это дело запускается на ночь, в логи пишутся результаты и потенциально глючные/критические моменты (+пишется трек для того чтобы можно было перемотать/повторить с любого места). Потом все повторяется уже в игровой обстановке.

Понятно, это разговор не про ИИ который делается по остаточному принципу непонятно кем за неделю до отправки на бета-тест, там действительно проще со скриптами методом подбора, получаются очень веселые непонятные баги :).

> > При наличии скрипт системы и дизайнеров педалящих скрипты
> Поражаюсь, как трудно осознать мъсль, что дизайнерам тот скрипт незачем давать.

Эта мысль неискоренима, т.к. такие "дизайнеры" - обычно студенты - самые низкооплачиваемые работники, а поручить им что-то толковое опасно. Менеджмент постоянно ведется на это - вручает писание скриптов :).

> Им нужен удобнъй тул.

Да, но тул пишется какое-то время (иногда очень долгое), а работники простаивают, это ведет к разного рода идеям, например, быстро сделать скрипт систему и начать писать скрипты еще до готовности редактора. Все еще усугубляется планами, в которых после обрезания бюджета таски переползают совершенно непредсказуемым образом, и, например, игровая логика вполне может быть раньше чем готов редактор :)

В идеальном проекте конечно такое не должно встречаться, но таких проектов мне не попадалось.

> Скрипт - тем же програмистам. Я сам, являясь в основном
> графичнъм програмистом провел в том скрипте немало времени, подгружая
> постпроцессинги, всякие редакторъ и прочее.

Большинство программистов, которых я встречал, предпочитают не писать на скриптах, так что это дело такое :).

>
> > олее простая поддержка всякого рода модостроителей
> В топку, такое уже почти никому не интересно.

Это зависит от проектов, у нас на одном который уже несколько лет как помер, модостроители еще во всю делают новый контент и моды. Т.е. для формирования комьюнити (особенно если планируется продолжение) не помешает.

> Эти задачи прекрасно решает редактор, непонятно нафига тут скрипт. Ну разве что если лень писать редактор, то заменить его скриптом, но это имхо экстремальный метод.

Скрипты - не замена редактору. В том же редакторе вам надо привязывать какие-то действия к событиям. Как это делать, вариантов множество. Самый гибкий и простой в реализации - скриптование.

aml
> Скрипты - не замена редактору.
Вполне могут быть заменой.

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

> В том же редакторе вам надо привязывать какие-то
> действия к событиям. Как это делать, вариантов множество. Самый гибкий и
> простой в реализации - скриптование.

Какие-то аргументы "за"  будут? :)

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

Проще и быстрее закодить нужную логику непосредственно на том языке на котором пишется редактор.

Логику вашу не улавливаю:

> Эти задачи прекрасно решает редактор, непонятно нафига тут скрипт.
и
> Вполне могут быть заменой.

Сначала вы спрашивали зачем скрипты, когда есть редактор. А теперь зачем редактор, когда есть скрипты.

> Какие-то аргументы "за" будут? :)

1. вырастет скорость разработки (разумеется, изначально надо подключить интерпретатор к вашему коду - это тоже работа. Но потом доработка игровой логики пойдёт на порядок быстрее)
2. уменьшится количество ошибок (в силу того, что скрипт занимает в разы меньший объём, чем аналогичный код на низкоуровневом языке)  => надёжность, простота эксплуатации и т.д.

Если что-то из этого кажется вам спорным, разверну мысль.

aml
> Логику вашу не улавливаю:
>
> > Эти задачи прекрасно решает редактор, непонятно нафига тут скрипт.
> и
> > Вполне могут быть заменой.
>
> Сначала вы спрашивали зачем скрипты, когда есть редактор. А теперь зачем
> редактор, когда есть скрипты.

Я ничего не спрашивал, тем более таких странных вещей.
Еще раз повторю: скрипты могут быть заменой редактору (или части редактора). Но _при наличии нормального редактора_, их ценность сомнительна. Так понятнее?

>
> > Какие-то аргументы "за" будут? :)
>
> 1. вырастет скорость разработки (разумеется, изначально надо подключить
> интерпретатор к вашему коду - это тоже работа. Но потом доработка игровой
> логики пойдёт на порядок быстрее)

Мы еще про редактор или уже про игру?
Напомню, изначальное ваше утверждение было - что скрипты нужны _в редакторе_. Хотелось бы узнать зачем?

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

Это как минимум спорное утверждение - и про ошибки и про размер кода.
Размер кода на универсальном скрипт языке (Lua, Python и т.д.) не сильно меньше чем на С++, C#. А если учесть поддержку и то что большая часть функционала сосредоточена в функциях на "низкоуровневом языке", то разница не существенная.

Хотя может вы под "низкоуровневом языком" подразумевали что-то особенно низкоуровневое? :)

На практике писание скриптов поручают самым бестолковым, которые более ни на что неспособны. Так что количество ошибок в скриптах гораздо больше чем в коде на нативном языке, понятно что ошибки там не критические, но тем не менее.

Может это конечно мне не везло, но я ниразу не встречал чтобы изначально скрипты писал более-менее толковый программист, или вообще программист :)

Теоретики кайфа делающие АИ и геймплей в одну итерацию на кубиках, это конечно мощно, так и представил страну эльфов и драконов, бороздящих просторы безвоздушного пространства (сферического вакуума). То что писать говнокод в разы проще на скриптах, и так думаю нормальным людям очевидно.

crazy_miner
> Теоретики кайфа делающие АИ и геймплей в одну итерацию на кубиках, это конечно
> мощно, так и представил страну эльфов и драконов, бороздящих просторы
> безвоздушного пространства (сферического вакуума).

Да, дрочить подбирать коэффициенты и бороть баги методом тыка, кочнено же более преспективный путь :)

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

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

outcast
>Да, дрочить подбирать коэффициенты и бороть баги методом тыка, кочнено же более преспективный путь :)
По другому, к сожалению, работает лишь в очень простых случаях, либо у теоретиков кайфа. И то что ты на первой итерации предположим сделал кубики "правильно работающими", не значит что спецификация еще не поменяется 10 раз во время процесса, и остальные 10 итераций, на кубиках в сферическом вакууме сделать просто не возможно.

outcast
> Нормальным людям так же понятно, что чем больше говнокода в проекте, тем больше
> кому-то придется махать лопатой во время его тестирования и сдачи.
Нормальным людям понятно, что говнокод это неотделимая часть процесса сильно ограниченного как по срокам так и по времени, и лучше если этот неизбежный говнокод будет написан относительно просто и быстро. А махать лопатой это у Q&A задача такая, им за это деньги платят.

crazy_miner
> По другому, к сожалению, работает лишь в очень простых случаях, либо у
> теоретиков кайфа. И то что ты на первой итерации предположим сделал кубики
> "правильно работающими", не значит что спецификация еще не поменяется 10 раз во
> время процесса, и остальные 10 итераций, на кубиках в сферическом вакууме
> сделать просто не возможно.

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

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

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

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

> А махать лопатой это у Q&A
> задача такая, им за это деньги платят.

У вас тестеры сами правят баги?

outcast
> Насчет перезапуска проекта не совсем понятно в чем сложность?
Во времени итерации - оно становится дольше в разъ.

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

Z
> > Насчет перезапуска проекта не совсем понятно в чем сложность?
> Во времени итерации - оно становится дольше в разъ.
>

Что занчит "во времени итерации"? Отладочная версия + неподготовленные ресурсы = дольше грузится, так?

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

Всмысле брезгующему? Языков программирования много, по такой логике если кто-то отказывается пользовать VB, он не профессионал? :)

Непонятно какой смысл более-менее нормальному программисту, переквалифицироваться в скриптовика. Т.е. если такое желание есть, проще в биздев идти, там зарплаты за такое в разы выше, гемороя в разы меньше. Логику не понимаю.

outcast
Не назовете проекты разработанные вами в которых, все было "статистически точно проверено" и смоделировано?

>У вас тестеры сами правят баги?
Баги очевидно правит, тот кто их сделал.

outcast
> по такой логике если кто-то отказывается пользовать VB, он не профессионал?
Тоесть, появилась необходимость сделать что-то на VB и програмист по идеологическим причинам отказъвается?
Ну, я надеюсь с такими програмистами не повстречатся в професиональном плане, ето ахтунг.

> Непонятно какой смысл более-менее нормальному программисту,
> переквалифицироваться в скриптовика.
Никто не заставляет переквалифицироватся, но если надо сделать работу, то хорошо ето делать в самой удобной для етого среде. Если ето не родной C++, тогда что - отказъватся работать?!
Решения с чем работать, они кстати не индивидуальнъе. Т.е. не индивидуальнъе, если охота остатся в рамках канторъ конечно...