Это звучит круто, но это ТЕОРЕТИКА, потому что на ПРАКТИКЕ будет тысяча корнеркейзов, где чего-то где-то не хватит и тут уж либо костылим, либо забиваем. Ах, мы же сделали супергибко? Ну получай тогда охрененно громоздкий UI уровня трех блендеров, в котором нужно еще и разбираться тысячу лет. Так на это еще и время разработки нужно потратить!

Вот меня тут вы не переубедите. Я твою идею полностью понимаю и я много где её видел и для себя прокручивал в голове тыщу раз. Но это та самая идея, которая по моему стойкому мнению НЕ БУДЕТ РАБОТАТЬ. Ну никак! Только в голове и в теории.

Doc, важно отличать два этапа разработки - проэктирование и редактирование уже после завершения проектирования. Для каждого этапа нужен свой инструментарий и вот если рассмотреть, например, старкрафт2, то там хорошо сделан инструментарий для редактирования, но отвратнейше представлен инструментарий для проектирования, потому то мне и приходится лезть в чистый xml, как ты и говоришь - не удобно проектировать новые данные, когда есть только режим редактирования.

В идеале, инструментарий для проектирования полностью абстрагируется от системы, которая под ним работает - все нужные данные и связи между ними генерируются автоматически, а прямая работа с данными, выходящая за рамки "поменять 2 на 10" это удел особо тяжелых случаев, с которыми не справляется автоматическая генерация. И позволь тебя заверить, если случай тяжелый, то пилить его придется два дня, не зависимо от того, в данных это делается или в скриптах.

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

Представьте себе что-то вроде 3д-редактора - со сценой, набором примитивов, таймлайном и кучей всякого другого добра.

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

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

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

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

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

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

Doc, я тебя прекрасно понимаю. Просто у каждого свои взгляды. Хотя сама идея prog'а мне оч даже нравится, но в реальном проекте, реально будет оч много костылей

Блин да причем тут спецификации, на этой хрени просто будет неудобно разрабатывать. НИКОМУ не будет это удобнее, чем просто файл скрипта и файл данных, например. Напишу сотню спеллов, сделаю тысячу разных сущностей, в 90% случаев сущности не переиспользуются. Офигенно гибко, офигенно ненужно, никому не будет удобно постоянно создавать новые файлы, объекты, что угодно, пусть это супер чистое апи и здоровенская убергибкая архитектура от которой ни шагнуть ни вправо ни влево и на которой при этом можно сделать все, на реальном проекте это НЕУДОБНО. Это все, о чем я пытаюсь сказать.

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

Doc, мне кажется мы сейчас дискутируем о преимуществах теплого перед мягким и наоборот, когда на самом деле оба объекта зеленые.

Рассмотрим простейший пример - нанесение урона и необходимость его учитывать.

В случае с эффектами у нас есть базовый тип эффекта "нанесение урона" и, соответственно, класс DealDamageEffect, который знает все о нанесении урона - за какое яичко надо потянуть юнита, чтобы он понял, что его ударили, куда подуть AI, чтобы тот проснулся и отреагировал на издевательства над его юнитом, в зависимости от реализации, этот же класс может и влияние брони обсчитывать и много чего еще делать, а может и не делать сам, а только раздавать пинки другим классам.

В случае со скриптами, если мы, конечно, не хотим миллион раз дублировать один и тот же код, мы будем вызывать некий метод DealDamage из библиотеки скриптов или из API или дергать его в юните, а уже юнит будет делать все остальное.

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

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

Напоследок хочу уточнить три вещи

1. речь сейчас шла исключительно о взаимодействиях объектов, не затрагивая вопрос визуального отображения т.к. это отдельная тема
2. все это применимо только к проектам, переходящим определенную планку по объему данных, связанных с взаимодействием между объектами - например, писать пакмена или тетрис с подобной системой в основе это оверкил, а вот для какой-нибудь доты, где данные регулярно пополняются новыми героями, а старые правятся в угоду балансу, это самое то.
3. реализация визуального редактора данных в ск2 отстойна до такой степени, что голый xml часто предпочтительней, благо такую возможность разработчики предусмотрели, видимо их мапмекеры тоже от этого страдали когда кампанию делали.

Нет ненависти к ск2, есть ненависть к оверинжинирингу

DarkDes, да запросто

• AlienShooter - почти вся игровая механика на скриптах О_О сам был в шоке когда нашел
• World of Warcraft - вся логика интерфейса написана на lua, а так же пиратские сервера, большая часть логики написано тоже на нем же (не уверен)
• Warcraft 3 - скрипты jass2, опять же большая часть логики для карт написана на нем
• Stracraft 2 - Galaxy

Примеров тьма на самом деле

Но скрипты не обязательно должны быть прямо в коде и опять же, я писал о трансляторе, как это работает в вк3.

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

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

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