Темой этого лога станет рендер. Расскажу немного о том как я себе представляю виртуального художника и почему лучше реализовать интерфейс IRender и класс-реализацию CRenderOGL, наример.
DarkDes, я говорю о том, что все это можно записать в двух внешних файлах, в одном скрипт, а в другом твои данные, которые скрипту подаются уже готовые. И никогда не придется ребилдить, скрипты они еще щас очень красивые в плане синтаксиса и много что прощающие, питон вон вообще как английский выглядит. И делается то, о чем я писал все вместе очень просто.
Тот же таргетинг допустим, определяется в скрипте какой-нибудь функцией типа
def isTargetable(Unit caster, Target target, SpellData data){
if (target is GroundTarget)
return false
if (target is UnitTarget)
return target.getUnit().isEnemy(caster) && Util.distance(target.getUnit(), caster) <= data.getCastRange()
}
Такой код и дурачок с базовыми знаниями англ языка поймет. А если для дурачков сделать красивый редактор с подсветкой синтаксиса (готовых либ тысяча в сети) и базовой проверкой самого скрипта (для этого достаточно просто вызывать функции из этого скрипта, банальные юнит-тесты), и код-темплейты, чтобы не приходилось начинать с нуля, то разберется и ребенок-дурачок, пожалуй.
И так с любыми условиями и запросами. Все уже сделано за Вас, честно.
Гспди, xgm, ну кто же делает word-wrapping в коде, ну?
-------------------
Если что, у меня все спеллы и юниты на скриптах. Единственное что сделано модульно, это периодические и временные действия выделены в отдельные переиспользуемые сущности с параметрами (т.к. игра пошаговая) и честно говоря, даже эти сущности надоедает создавать при разработке.
В тему спеллов\скилов\эффектов. Визуальные редакторы таких данных - это конечно может быть удобно, но для внутренней разработки наверно будет достаточно и простых текстовых данных (кэп!). Ну вот например такая штука:
Doc, окей, ты меня сделал. можно вот всё это записать в супер-коде, а во внешнем файле хоть 2, хоть 8 юнитов чтоб было. 100хп, 200хп, всё зависит от движка жи. Doc:
бежать сломя голову в отдел прогеров движка
Не знаю как там в современном инди, труЪ-инди и прочем на коленках, но думаю, что нет у них отдела прогеров с движком )
Оки. Хочу чтобы этот спелл можно было кастовать только на юнитов у которых меньше 100хп. И только на тех, рядом с которыми есть деревья, которые тоже загораются (это специальный интеракшн только с этим спеллом, сами деревья не больше чем декорации). И кастовать можно было только тогда (т.е. проверка должна быть еще на стадии нажатии кнопки, до выбора цели), когда рядом с кастером есть хотя бы 2 союзных юнита. Как это реализовать в параметрах и эффектах? Да и так чтобы если я еще что подобное захотел сделать, но с изменениями типа того, что юниты рядом должны быть вражеские или что еще, мне не пришлось бежать сломя голову в отдел прогеров движка. Мы же не хотим постоянно ребилдить проект, правда?
Тогда расскажи ка что подразумевается под параметрами эффекта burning
например, время горения, сколько урона наносит и сколько раз в секунду (или другой промежуток) этот самый урон наносится. Вообще базовую логику различных эффектов лучше хранить в супер-коде (основном коде программы).
И да, ребилда проекта не требуется, скрипты хранятся снаружи, для большинства не потребуется даже перезапуск приложения, при ченжах во время тестирования.
Это конечно круто, но надо ли ? Ладно там значения какие-нибудь, но когда работа с указателями различными (не в самом скрипте, просто скрипт дёргает такие штуки) - это проблема, хотя всё зависит от мощности скриптового движка.
Тогда расскажи ка что подразумевается под параметрами эффекта burning, а я тебе приведу примеры, для реализации которых эти параметры превратятся практически в скрипт, только корявый и неудобный.
И да, ребилда проекта не требуется, скрипты хранятся снаружи, для большинства не потребуется даже перезапуск приложения, при ченжах во время тестирования.
Данные хранить разумеется нужно отдельно.
Doc, ну это не скриптовый же язык, а форма заполнения данных )
Или предлагаешь все значения и всё всё всё хранить в самом коде? Не надоест билдить проект после каждого незначительного изменения в балансе?) Вообще внешние скрипты с логикой - это по мне лишнее, а вот различные данные хранить, да или тот же UI - это нормально, но это имхо конечно.
AlienShooter - почти вся игровая механика на скриптах О_О сам был в шоке когда нашел
World of Warcraft - вся логика интерфейса написана на lua, а так же пиратские сервера, большая часть логики написано тоже на нем же (не уверен)
Warcraft 3 - скрипты jass2, опять же большая часть логики для карт написана на нем
Stracraft 2 - Galaxy
Ого! Не знал этого. Возможно скрипты действительно мощный инструмент - ещё не пробовал на практике. Единственное, что делал дак это некий "язык разметки" для интерфейсов .. был удивлён, когда узнал, что на движке idTech3 аналогично сделано (только круче конечно).
В тему спеллов\скилов\эффектов. Визуальные редакторы таких данных - это конечно может быть удобно, но для внутренней разработки наверно будет достаточно и простых текстовых данных (кэп!). Ну вот например такая штука:
effect "burning" // регистрируем эффект "догорание"
{
... // тут различные параметры
}
skill "uber-shock" // типа регистрируем скилл
{
target = AREA; // цель = какая-то местность
radius = 5;
addEffect "burning", target_unit; // всем юнитам попавшим под этот спелл добавить эффект.
}
Это может выглядеть убого (возможно так и есть), но я бы сделал примерно так в реальном проекте. В подобных "скриптах" указал бы героев, их способности, модели и т.д., а в коде указал бы что нужно "выдернуть" ( хотя это не обязательно )
Doc, ну так система гибкая не только в использовании, но и в разработке. Если возникает корнеркейс, то оценивается время на реализацию недостающего функционала, будь то новый тип эффекта, добавление параметров в существующий или допил модификатора в архитектурном приложении чтобы эффективнее использовать существующие эффекты. После оценки принимается решение - реализовать сейчас, отложить до следующей итерации или переубедить геймдизайнера, что нужно пойти другим путем.
Что касается UI, то он не может быть сложнее блендера - данные представляются в виде таблиц, как и в ск2, работа с геометрией отсутствует, работа со сложной анимацией в прямом смысле тоже, как и работа с материалами, рендерингом, параметрами сцены, камерами, светом - расставить примитивы, по таскать их по сцене, установить между ними связи, да вбить в таблицу данные - вот и все задачи архитектурного приложения.
Вот время разработки - да, его понадобится ощутимо больше, чем если ваять то-же самое, но на коленке. Так что эта технология скорее не для рядового инди разработчика, а для более-менее крупной студии, которая может себе позволить задержать очередной релиз ради разработки инструментария, который пригодится не только в текущем проекте.
BRODILKA
Комментарии проекта Бродилка
Выбор редакции
[Лог #7] Класс рисовальщика.
Ред. Doc
можно вот всё это записать в супер-коде, а во внешнем файле хоть 2, хоть 8 юнитов чтоб было. 100хп, 200хп, всё зависит от движка жи.
Doc:
Ред. Doc
И да, ребилда проекта не требуется, скрипты хранятся снаружи, для большинства не потребуется даже перезапуск приложения, при ченжах во время тестирования.
Данные хранить разумеется нужно отдельно.
Или предлагаешь все значения и всё всё всё хранить в самом коде? Не надоест билдить проект после каждого незначительного изменения в балансе?) Вообще внешние скрипты с логикой - это по мне лишнее, а вот различные данные хранить, да или тот же UI - это нормально, но это имхо конечно.