- Suslik
- Постоялец
Pushkoff
> скрипты нужны в основном для того чтоб освободить "отцов" от рутинной работы,
> ведь для набивки 95% логики много ума не надо, поэтому с этой работой может
> справиться самый слабый гейм/левел дизайнер, который пару раз сидел на паре по
> программированию или видел паскаль в школе...
бинго! моё мнение - такое же.
я считаю, что если не предполагается, что гейм-код будут разрабатывать существенно более слабые программисты, то на мой взгляд, система скриптования может быть вовсе не обязательно оправдана. и что-то я сомневаюсь, что преимущества вроде closures и магических потоков могут окупить оверхед и существенные трудности, возникающие при разработке софта на такого рода орхетектуре.
Suslik
> существенные трудности, возникающие при разработке софта на такого рода
> орхетектуре.
Ну, оверхед - фиг с ним, понятие относительное. Что за трудности то?
Те, что связаны с native разработкой, про которые говорит Z, я понимаю. Хорошо в оффлайне отлаживать одну подсистему, две, пять. Дампы, бряки, компиляция, запуски. А когда отдельных "систем" стопицот - это кажется весьма тоскливым занятием.
Что-то совсем о разных вещах говорите. Ошибки типа "подтюнить" это, да. Lua рулит. Перезапуск скриптов это очень-очень круто. Ошибки типа "fatal error", ну в скриптах они вообще не должны появляться. И в коде, вызывающем скрипты тоже. В нативном - ASSERT и смотрим, что в стеке. Тут сериализация не нужна, мы точно знаем, что косячит. Перезапуск нужен. Если ассерт не помогает (коряво рейтресинг написан). Делаем либо интерактивное тестовое приложение (грузим меш и кликаем мышкой), либо сериализация нужного и консольный test case. Тут что проще. Зависит от имеющихся средств в самом проекте. А дампить всё, это очень дорого. Что бы быть уверенным, что ты дампишь всё (в своём модуле), надо делать 100% покрытие кода тестами, или затачивать архитектуру под это, в ущерб остальным характеристикам.
Ghost2
> Что за трудности то?
гм, трудностей при разработке script-based приложения я выделяю две:
1) чтобы начать, собственно, реализацию бизнес-кода(который у нас подразумевается скриптовым), нужно сперва реализовать совершенно не определённой трудности фреймворк, который будет скрипты загружать, их исполнять, менеджить, скедьюлеры, и вся эта платформа, которая будет управляться(drive) нашим контентом(data). если мы используем готовый data-driven движок, этой существенной проблемы нет, но мы здесь, как я понимаю, обсуждаем именно разработку готового программного продукта "от" и "до", то есть совершенно не определённую часть работы нам придётся при этом потратить на разработку, собственно, движка. в native(unmanaged, не data-driven: слово не могу подобрать) соотношение в проекте бизнес-кода с кодом технической части может быть вполне сопоставимого размера. в data-driven же "техническая часть", скорее всего, будет на порядок тяжелее, как для разработки, так и для поддержки и для расширения.
2) разрабатывая софт на нашем фреймворке, мы сами себя ставим в серьёзные рамки. если мы изначально не задумывали, например, что из нашего скриптового языка можно будет реализовать постэффект, то придётся либо лепить костыли, либо перелопачивать всю систему, тесно связывая нативный код со скриптовым, теряя все преимущества скриптования.
Извините, если моё представление о полностью data-driven системе со сложной логикой не соответствует истине. я имел дело лишь с проектами, в которых скриптовый язык используется в качестве самого высокоуровневого менеджера того, что делать десяти тоннам нативного кода. то есть скрипт сам ограничивается объёмом в килобайты, а вычислительное ядро, которым он управляет - сотни мегобайт. я могу ошибаться в поведении системы, в которой будут сотни мегабайт скриптов и мегабайты нативного кода.
Suslik
> гм, трудностей при разработке script-based приложения я выделяю две:
> ...
Согласен с данными аргументами, вряд ли я осилю сверх обобщённую скриптовую систему, придётся заранее думать о том, чего вырезать.
Suslik
скриптовую системъ объчно очень просто расширять.
Вот на примере пост-ефекта - или просто даем интерфейс к нейтиву, которъй создает пост-еффект пасс или прямо создаем табличку всего пост-процессинга и нейтив ее читает.
Ето работа на 1-2 часа, какое перелопачивание аж всей системъ... :)
Если подключить полноценный скрипт с широким доступом к движку, то для работы потребуется более-менее опытный программист и время на изучение не только скриптового языка, но и особенностей низкоуровнего функционала. Проще во всех отношениях использовать чисто дата-драйвен, декларативный подход. Единственное место, где, но-моему, текстовый скриптинг удобен - специфические скрипты миссий. Иначе получится очередной фейл, где программисты пишут и скрипты и движок.
Ataman
> Иначе получится очередной фейл, где программисты пишут и скрипты и движок.
Я именно разсуждал на тему полноценного кодинга на скрипте, програмистами, а не какими-то кодерами второго сорта. Такое я не понимаю вообще, как и зачем им давать в руки текст, а не набор комбо-боксов + редактор.
Z
> Я именно разсуждал на тему полноценного кодинга на скрипте
А какую часть игры именно программисты должны делать на скрипте, и зачем?
> зачем им давать в руки текст, а не набор комбо-боксов
Склоняюсь к мысли, что в некоторых случаях, текстом в окошке редактора удобней, чем визуал скриптинг. При наличии специфических хелперов, естественно.
Ataman
> А какую часть игры именно программисты должны делать на скрипте, и зачем?
Геймплей, AI. Я писал уже зачем.
Ataman
> текстом в окошке редактора удобней, чем визуал скриптинг.
Ничего не мешает ето окошко добавить в вижуал скрипт редактор, для особо развитъх, но пусть ето будет опция, а не требование.
Suslik
> бинго! моё мнение - такое же.
>
> я считаю, что если не предполагается, что гейм-код будут разрабатывать
> существенно более слабые программисты, то на мой взгляд, система скриптования
> может быть вовсе не обязательно оправдана. и что-то я сомневаюсь, что
> преимущества вроде closures и магических потоков могут окупить оверхед и
> существенные трудности, возникающие при разработке софта на такого рода
> орхетектуре.
+1
Довелось мне участвовать в проектах как со обилием скриптов так и с почти полным их отсутствием. Соглашусь что если народ в основном квалифицированный на проекте, то проку от скриптов немного, т.е. обычно нормальный программист не занимается поиском багов или подбором коэффициентов методом ненаучного тыка, для чего собственно и нужна возможность быстрой правки и перезапуска.
При наличии скрипт системы и дизайнеров педалящих скрипты, на выходе получаются тонны говнокода который проще выбросить чем пытаться понять что оно там делает. Хотя конечно определенные плюсы есть - например, более простая поддержка всякого рода модостроителей, но это не всегда нужно.
Коллеги, можно я тоже вмешаюсь в вашу дискуссию про script vs native? Хочу поделиться некоторыми соображениями, где уместен скриптинг, а где нет.
Когда большая часть логики какой-то подсистемы реализована на компилируемом языке, делать скриптовые биндинги - это большая работа, смысл в которой есть, только если код будут писать неопытные программисты или сами гейм-дизайнеры. Это тут уже обсудили.
Однако хочу напомнить, что игра не ограничивается одним только графическим или сетевым движком, сериализацией объектов и прочими низкоуровневыми вещами. Как только вы перейдёте от движка к наполнению игры контентом, сразу начнётся, например, GUI. Поторговать с неписем или другим игроком надо? Показать список товаров, для каждого товара отформатировать описание, положить в корзину, посмотреть корзину, совершить покупку, записать в базу данных. Конечно, это можно реализовать на native, но на скриптовом разработка будет на порядок быстрее и код будет на порядок надёжнее (в силу того, что он короче).
Не стоит гнаться за производительностью и экономией памяти там, где они не нужны. Тут считали, сколько байт занимают переменные, и насколько быстрее работает сборщик мусора. Производительность имеет решающее значение в 3D-движке. В интерфейсных же вещах, в обращениях к диску, к базам данных, при запросе чего-нибудь по сети издержками скриптовых языков можно пренебречь.
Всё равно какие-то data-driven части в игре есть. Карты, расстановку неписей и прочие вещи программист всё равно не будет иплантировать прямо в код. Это будут отдельные ресурсы. Всё равно механику загрузки надо реализовывать. В этом месте можно передать управление скрипту, чтобы он вернул карту или список неписей. Скрипт считает те же самые ресурсы без значимых потерь в производительности, откуда надо - хоть из файла fopen, хоть по сети urlopen. Если завтра потребуется процедурная генерация монстров, поменять скрипт проще, чем изменять native-ядро игры. Скрипту уже намного проще полезть в базу данных, проверить состояние каких-то других объектов и принять решение, что и как сгенерировать.
Что касается многопоточности. Её необязательно реализовывать native-потоками операционки. Вместо этого встройте интерпретатор stackless в игру и получите очень производительный движок, умеющий одновременно делать массу асинхронных операций без усложнения логики скрипта. С точки зрения скрипта будет обычный вызов urlopen, а на самом деле во время ожидания соединения с сервером, передачи запроса и приёма ответа ваш процессор будет заниматься другими делами. Ту же самую логику можно реализовать конечными автоматами и на native-языках, но тут лучше сразу застрелиться - работа чрезмерно кропотливая. stackless позволит описывать даже поведение объектов не конечными автоматами, а самой простой линейной программой. Это минимум ошибок и исключительная простота отладки без потерь производительности.
aml
> Вместо этого встройте интерпретатор stackless в игру
Он же будет работать в одном потоке? Совсем не айс для современных процов.
Z
> Геймплей, AI. Я писал уже зачем.
Это наверно сильно проджект-специфик, но логика юнитов, по идее, сильно завязана на низкоуровневые системы типа поиска путей и анимации. Поэтому, где и как, по-твоему, надо провести интерфейс между нативным кодом и скриптом? Причем так, что бы была возможность делать хот релоад.
outcast
> т.е. обычно нормальный программист не занимается поиском багов или подбором
> коэффициентов методом ненаучного тыка, для чего собственно и нужна возможность
> быстрой правки и перезапуска.
Писать всякие внутриигровъе редакторъ, сложнъе поведения AI и прочее - их научно не делают, насколько мне известно. Их делают, чтобъ красиво и удобно.
Надо тестить, тюнить, смотреть как оно себя ведет в реальной среде.
Я вот писал редактор дорог - перезагружал его 2-3 дня сотни раз. Если мне надо бъло перезапускать проект - ето идти стрелятся. Та же история с AI для случайнъх разговоров, юзание всяких обьектов и симуляция жизни - ее надо смотреть, тюнить, смотреть. Научно, сесть и в 2-3 раза написать - ето я незнаю как...
> При наличии скрипт системы и дизайнеров педалящих скрипты
Поражаюсь, как трудно осознать мъсль, что дизайнерам тот скрипт незачем давать. Им нужен удобнъй тул. Скрипт - тем же програмистам. Я сам, являясь в основном графичнъм програмистом провел в том скрипте немало времени, подгружая постпроцессинги, всякие редакторъ и прочее.
>более простая поддержка всякого рода модостроителей
В топку, такое уже почти никому не интересно.
aml
> смысл в которой есть, только если код будут писать неопытные программисты или
> сами гейм-дизайнеры. Это тут уже обсудили.
.
Ataman
> Он же будет работать в одном потоке? Совсем не айс для современных процов.
Там перформанса по идее не надо. Там надо контролированно спать нитям длинное время и иметь много ниток и все.
> Поэтому, где и как, по-твоему, надо провести интерфейс между нативным кодом и
> скриптом?
Где ето нам подсказъвает здравъй смъсл. Интерфейс на сетап анимаций в движок + интерфейс на асинхроннъй расчет пути и все. Там капля в море, а не интерфейс...
Тема в архиве.