?

Log in

No account? Create an account

Дзэн-3, скрипт - Не кинокритик. Не палеонтолог.

июл. 7, 2009

09:03 pm - Дзэн-3, скрипт

Previous Entry Поделиться Next Entry

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

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

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

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

Группа фанатов, искренне считающих, что С++ не хватает yield return (ну допустим), модификации кода без перекомпиляции (мне и самому не хватает), и лямбд (угу), и это нужно срочно лечить приделыванием навесного мотора, может смело отправляться ваять Fallout MMO, если еще не. Подобные идеи я обсуждать как-то слегка запарился.

По опыту, единственный приличный аргумент в пользу существования скриптов - все-таки кадровый. Программисты - дорогой ресурс, и, что хуже, еще и редкий. Если логику каждого уровня и каждого интерфейсного экранчика будут писать программисты, проект сильно затянется. Кроме того, как уверен каждый дизайнер, программисты не понимают тонкой души геймера, и не сумеют нафигачить контент (имеется в виду логический) миссий таким образом, чтобы игра продала стотыщмиллионов копий. Имитируя с недавних пор принятый на дэтээфе стиль, Я ПОВТОРЯЮ: не понимают не сумеют ок.

Багов насажать более чем просто и в скрипте. Особенно в том случае, когда написатели - не программисты, и плохие практики программирования N-тым чувством распознавать не научились. Типичные имена переменных - a, b, c, aa, sdf и pidarasy_Unit, типичная длина функции - 500 строк, типичное число функций в скрипте - одна, классов - ноль, и тд и тп. Тестирование производится методом "запустил и поиграл, вроде работает - а дальше тестеры найдут". Очень также, кхм, помогает выразительность Lua/Python, позволяющая умельцу двумя лаконичными строчками записать алгоритм, имеющий сложность О(n4), и отсутствие compile-time проверок типизации (за отсутствием самого compile-time), позволяющие получать сообщения вида "IsAlive is not a callable type" в уже вышедшей игре (см., а равно см. многие путевые заметки orvind'а).

Возникает вопрос: оно нам вообще надо? В древней игре Starcraft уже был изобретен отличный "язык" для скриптов, именно, система триггеров (ага, не Тьюринг-полная). По сути это представление состояния игрового уровня в виде набора конечных автоматов. Условия и действия на переходах при этом game-specific. Некоторые условия или действия исчерпывающе описываются своим названием (например: "Всегда" или "Закончить миссию победой игрока"), другие могут иметь параметры. Типичный триггер выглядит как-то так: "если в зоне 0 есть хотя бы один герой Игрока Один, выдай Игроку Один 100 единиц минералов, отключи этот триггер и включи триггер БомбаНачало".

По мне, с точки зрения типичных целей игрового скрипта у системы Starcraft'а был всего один крупный недостаток: для создания сколько-то сложной логики нужно было ну просто укликаться мышкой. Года два назад, еще работая в геймдеве, я решил проверить, насколько вообще это плохо, и сделал похожую скриптовую систему для нашей RTS Robocalypse, используя вогстеровских дизайнеров в качестве подопытных кроликов (за что они меня, надеюсь, уже простили). У меня, впрочем было смягчающее обстоятельство, заключавшееся в том, что виртуальная машина даже для Lua в контексте Nintendo DS была ну совершенно ни к селу ни к городу. С учетом памяти под графику и код у нас оставалось что-то около 700K оперативной памяти на весь геймплей вообще, включая игровое поле, pathfinding, и, гм, собственно скрипты. Альтернатив самопальной машине из шестеренок как-то не просматривалось.

В общем, выяснилось, что много кликов - это, конечно, плохо. Ну, по крайней мере в принципе. Уровни это делать не помешало, скорость разработки не снизило, игре выйти не помешало, и 89% Editor's choise на IGN получить тоже. Может быть, зря я поленился, и все-таки стоило бы сделать для удобства DSL и писать "скрипты" в текстовом виде. Но по факту оказалось, что это не настолько важно.

Вот без чего, думаю, "не взлетело бы":



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


Некоторые вещи, естественные для текстового скрипта, были утеряны:


Ну и просто в качестве информации: в игре "скомпилированный" скрипт представлял собой бинарный блоб размером ориентировочно 200-1000 байт (в зависимости от миссии), в runtime скриптовая система дополнительно пожирала еще пару килобайт (если точнее, фиксированное количество бит идущей подряд памяти, известное в compile-time, но точную цифру я уже не помню).

Такие дела.

Tags: , ,

Comments:

[User Picture]
From:sim0nsays
Date:Июль 7, 2009 07:06 pm
(Link)
Хм, а если такой триггерной системе добавить еще и возможность описывать ее текстом - решит ли это проблему с укликиванием?

Какое-то форматирование, навигацию простенькую итд?
(Ответить) (Thread)
From:todace
Date:Июль 7, 2009 10:44 pm
(Link)
да хватит только возможности описывать текстом, считаю.
с подсветкой того, что под курсором на уровне и а)подстановкой б)проверкой (что юнит1 не присутствует на карте) больше ниче не надо, считаю.
(Ответить) (Parent) (Thread)
[User Picture]
From:vanxant
Date:Июль 7, 2009 07:21 pm
(Link)
А как бы нечто похожее на пролог реализовать, нэ? Очень похоже получается, и реализация простейшая
(Ответить) (Thread)
From:(Anonymous)
Date:Июль 7, 2009 07:45 pm
(Link)
Интересно, спасибо. Как раз сейчас примерно этим и занимаюсь - пытаюсь впихнуть сквирл на пс3. Тормозит (особенно в местах стыка с нативом). Жрет память (лечить, лазия по внутреннему рефкаунту, тоже не самое приятное занятие). Код ужасен местами.

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

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

Твой вариант (т.е. "старкрафт-стайл дсл") как раз для дизайнеров самое то.

Вообще, конечно, задумался, а, действительно, если не для дизайнеров, то нафига?
(Ответить) (Thread)
From:(Anonymous)
Date:Июль 8, 2009 10:27 am
(Link)
все таки от задач зависит сильно. В ртс ск стайл куда лучше подходит чем в синг.плеер экшене. И вообще в мултьплеер ориентированной игре.
Но таки да, достаточно часто лучше подходит такие скрипты.
ПС кроме дизайнеров и программистов бывают еще опытные программист логики и неопытные, также и дизайнеры. Это влияет.
(Ответить) (Parent) (Thread)
From:daradiboga
Date:Июль 7, 2009 09:32 pm
(Link)
Если интересно, то у нас вот раньше (4?) года назад была такая же система (Starcraft-подобная, как раз, честно скоммунизидили).
Отказались в пользу скриптов по следующим причинам:
* кадры (используем Squirrel, синтаксис более знаком в России чем Lua).
* емкость текста
* отладка херни. Типично - отлаживает задницу в игре (не в скриптах, нет. но они ее вызвали) вовсе не скриптер. А программист. Сквиррел ему понятнее.
* более сложная логика, описывающая поведения (behaviour) объектов, требовала нативного кода все равно.

Расставлять по уровню скриптовые точки итд - оставили.
(Ответить) (Thread)
From:todace
Date:Июль 7, 2009 10:42 pm
(Link)
На самом деле это не вся история.
Изначально собирались сделать как раз как пишет Андрей "в идеале":
текстовые псевдо"скрипты", с подсветкой, т.е. без автоподстановка, и тд, такие же конструкции, но настоящий текст + точки на уровнях и области.
Потому как это идеально, чаще всего.
А сквирелл был временным решением - для половины проектов и более подходящим для другой половины (по емкости текста и задачам).

А самое главное, без чего плохо на триггерах типа SC - это find, и возможность "почитать" весь скрипт подряд.
(Ответить) (Parent) (Thread) (Развернуть)
(без темы) - (Анонимно) (Развернуть)
[User Picture]
From:malaya_zemlya
Date:Июль 8, 2009 03:39 am
(Link)
>Без поддержки в редакторе триггеров привычных ctrl+Z, ctrl+C и ctrl+V, как это ни банально

Мудры слова твои.

По опыту, профи-дизайнеры могут работать с самым отвратительым редактором, но производительность их от этого страдает сильно.
(Ответить) (Thread)
[User Picture]
From:plakhov
Date:Июль 8, 2009 08:09 am
(Link)
Да вообще по-моему RTS надо делать в такой последовательности:
- mission editor с UI вида "для end user-ов"
- мультиплеер
- сингл
Какого хрена все, кроме Близзарда, делают это почти в точности наоборот, не понимаю.
(Ответить) (Parent) (Thread)
[User Picture]
From:golergka
Date:Июль 8, 2009 08:16 am
(Link)
В том случае, когда речь идёт о забивании контента, подтвержу: работать в системе с табличками и выпадающими списками приятнее, чем с LUA-кодом. Но кроме этого есть игровая механика (хит-пойнты, спеллы и так далее), которую тоже неплохо вынести в скрипты: гейм-дизайнеры всегда норовят сунуть туда свой нос, чтобы выяснить, как оно работает _на_самом_деле_ и немного модифицировать.
(Ответить) (Thread)
[User Picture]
From:dtjurev
Date:Июль 8, 2009 10:13 am
(Link)
У меня вопрос. Как насчёт отладки? Расставить логи, поставить break-point и пройтись по шагам, посмотреть историю смены состояний? Как отлаживать? Не получится ли так, что запустился какой-то триггер не в своё время, а почему это произошло - фиг поймёшь?

Потом есть мнение, что описанная система скриптования подходит в основном для RTS, где геймплей строится из достаточно небольшого набора ясных логических элементов. Причём, они известны до начала скриптования игровой логики. По ходу работы над проектом могут немного поменяться/расшириться, но косметически.

А вот если взять ММО, то здесь уже всё не так. Игровая логика не ложится на простой набор триггеров. В игре множество фич, и дизайнеры постоянно придумывают новые. Всё это требует настоящего ЯП. Если попытаться делать это на триггерах, то процесс разработки будет выглядеть, как постоянное написание новых и новых триггеров, чтобы потом составить из этих триггеров логику. А если логику пишут не те, кто пишет триггеры, то взаимодействие/непонимание/нестыковки планов усугубляют проблему многократно. Довольно быстро число триггеров превысит всякий разумный предел, чтобы ими было удобно пользоваться. Не найдя нужный триггер дизайнеры будут заказывать программистам новый с почти таким же функционалом. Из-за сложности логики триггеров будет возникать непонимания тонкостей их работы и так далее.

В итоге пользоваться этой системой будет менее удобно, чем просто кодировать игровую логику в обычном ОО-стиле. Напомню, я сейчас про ММО. Насчёт RTS вопросов нет - там это идеальный вариант.
(Ответить) (Thread)
[User Picture]
From:strangeraven
Date:Июль 8, 2009 11:34 am
(Link)
Я же тебе рассказывал про нашу систему :) Её идея, кстати, тоже родилась, когда я делал карту в близзардовском редакторе для war3.

Я бы сказал, что в ММО все получилось очень даже ништяк, хотя игровая логика требовалась очень сложная (иногда не просто скрипты, а целые миниигры) и очень большая по объему (несколько отделов херачит).

Imho, это вообще от жанра не зависит, можно налепить все что угодно.

К тексту, кстати, все сводится очень просто: хранить данные -в xml-based типизированных структурах.
(Ответить) (Parent) (Thread) (Развернуть)
From:captain_tylor
Date:Июль 8, 2009 08:54 pm
(Link)
Вроде бы, VM Lua меньше 30к занимает. Если без либ и парсера, просто интерпретатор байткода.
(Ответить) (Thread)
[User Picture]
From:plakhov
Date:Июль 9, 2009 12:02 pm
(Link)
1) невозможно предсказать верхнюю границу потребляемой памяти (разве что экспериментально, но придется достаточно сильно перезакладываться)
2) скрипт после "компиляции" в байткод весит не меньше, а даже больше (из-за того, что все названия переменных и функций остаются в рантайме)
3) как два пальца случайно организовать бесконечно растущее потребление памяти в скрипте (например, какую-нибудь бесконечно растущую "очередь событий")
4) реально на тестовых скриптах получалось не 30, а все 200
5) даже 30 в сравнении с 3 мне было несколько жаль

самым критичным для нас был п.1 - он полностью противоречил всей центральной идеологии контроля
(Ответить) (Parent) (Thread)
[User Picture]
From:musasy
Date:Июль 10, 2009 07:47 am
(Link)
Я только теперь осознал, насколько это была удобная и дружественная юзеру система. Это был мой первый проект, поэтому мне казалось, что так и должно быть.
(Ответить) (Thread)
[User Picture]
From:loyso_b
Date:Июль 10, 2009 08:58 am
(Link)
Старая байда - visual DSL vs. textual.
А что насчет истины посередине? Мне например кажется, что композиция обьектов в пространстве плюс навешенные на них микро-програмки (на scheme например) как-то правильнее. Подразумевается причем, что многое из микропрограммок можно смастерить композицией обьектов аля схемотехника. А можно просто программкой. Ну и люди выбирают, что им удобнее прямо для каждого уровня+обьекта+сотрудника.
(Ответить) (Thread)
From:captain_tylor
Date:Июль 10, 2009 11:31 pm
(Link)
Кстати, когда я думал о подобной схеме, мне одним из основных преимуществ казалась возможность значительной автоматической оптимизации.

Скажем, зная структуру триггеров, можно многие повторяющиеся проверки делать реже. Например, если 100 триггеров требуют срабатывания одного и того же флага, то можно этот флаг проверять сразу, и если он не взведен - то все эти сто триггеров даже не проверять.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]
From:cd_riper
Date:Июль 11, 2009 11:18 am
(Link)
Есть еще путь Кармака. Уже в первой кваке был свой язык, которым, собственно говоря, практически вся игра и описывалась.

Очень часто скрипты это просто более удобный и высокоуровневый инструментарий программиста.

Дизайн уровней немного другое.
Кроме всего прочего есть еще RPG, где нужно мощное, простое и удобное средство для наполнения игры.
(Ответить) (Thread)
From:deadepilogue
Date:Август 15, 2009 12:04 am
(Link)
"Далекие от геймдева люди часто искренне считают, что скрипт нужен для того, чтобы фанаты позже могли как угодно видоизменить проект. На самом деле, это так максимум для двух с половиной игр-брэндов, которые перечислит даже марокканский пастух, если его разбудить среди ночи."
=========
"Operation Flashpoint" (BIS), из, примерно, 400 команд (в языке нет ключевых слов, и прочего -- все "команды", в терминологии самих разрабов) в официальной кампании использовалось что-то около 4, для передачи статуса персонажа из миссии в миссию. Язык явно был добавлен "абы было", в результате его использовало только коммюнити. Да, еще катсцены на нем писались, но для этого был и альтернативный способ, который также использовался.
Это наверно не единственный пример, так что, кажется, марсианский петух может и соврать.
PS. Я извиняюсь за коммент, и заодно говорю спасибо (Спасибо!) за интересные статьи ))
(Ответить) (Thread)
[User Picture]
From:golergka
Date:Март 12, 2010 09:58 am
(Link)
Я тут кстати недавно начала с редактором warcraft3 возиться - истинный рай для дизайнера. Мышкой да, укликаться, но это особо не мешает, на самом деле. Единственное, чем отличается от редактора starcraft - функционал раз в 4 больше.
Так я это про что; вот он в эти 700k влез бы? Просто интересно.
(Ответить) (Thread)
From:artem3kg09
Date:Май 30, 2018 05:49 pm
(Link)
Дааа, половину слов не понял, а потом где и смысл потеря, но почитать, полистать было интересно. Как-то давным давно я открывал в редакторе карт (starcraft)старкрафта 1-го триггеры, но так с ними не разобрался, ни одного не сделал.
_ А Lua как я понял, в частности, использовался в LockOn , авиасимуляторе от EagleDynamics, но там я тоже только пара цифр менял в файлах конфигурации и всё, больше ничего не делал.
(Ответить) (Thread)