prog:

это еще почему?

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

alexprey, для таких придумали транслятор блоков в тот же самый код, гспди. А не парсер блоков и целую завязанную на нем систему билеберды и огромную архитектуру.

Doc, это такой вечный холивар между теми кто умеет программировать и теми кто привык мышкой блоки таскать

Очень влияет на гибкость, она там прекрасная. Эта гибкость и есть минус.
Послушайте, когда-то я выдумывал как бы мне сделать систему способностей для пошаговой игры и где их хранить. Вот я тоже придумывал типа различные компоненты, которые значится где-то вместе связываются в цепочку, и хранятся в базе/в файлах, а потом достаются оттуда, парсятся и каждой компоненте присваивается действие, я подумал о разных вариантах абилок, понадобятся условия, циклы, модули, что-то еще... Да это целый скриптовый язык для абилок получается... НО У МЕНЯ УЖЕ И ТАК ЕСТЬ СКРИПТОВЫЙ ЯЗЫК, ЗАЧЕМ ИЗОБРЕТАТЬ ВЕЛОСИПЕД? Точно так же и в ск2 есть скриптовый язык, на котором можно написать все что угодно, нахрена вообще редактор объектов, на котором запиливание спелла может занять больше времени? Ого, я написал этот спелл без кода, я такой крутой! Правда тут пара хаков, там пара хаков, тут мелкий баг, ну никто все равно не заметит, а потратил то я всего два дня. Вы серьезно? Кому это нужно? А потом кода поднакопилось и в итоге половина логики, а половина там.

Всё уже сделано за вас, блин. Берете любой скриптовый язык и прикручиваете, ограничиваете сендбоксом область действия, пишете внятные интерфейсы/врапперы для объектов используемых в коде - вуаля, делаете ВСЁ, ЧТО УГОДНО. Гибче кода блин, ничего не будет. Что верно заметили, данные в нем хранить не нужно.

DarkDes:

я так и сделал у себя в одной ммошке, свой скриптовый язык, который спелы реализовывал на стороне сервера

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

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

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

prog, вот сделали так в ск2 и что остановило большинство людей от его модмейкинга? Преслувотое разбиение и охрененно сложный редактор объектов

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