Харгард, зачем? ты же и так делаешь привязку геосета одежды к скелету героя, так? После того, как модель готова делаем копию файла и удаляем из него геосет героя, оставив только геосет одежды, после чего экспортируем без анимаций, также делаем еще одну копию и там поступаем с точностью до наоборот - удаляем геосет одежды и экспоритруем без анимаций, ну и финальный штрих - экспортируем только анимации в m3a файл.
Duke911, будет время - разберу модель морпеха и посмотрю что именно там анимировано и как сделана анимация.
Duke911, хочешь сказать, что близы анимировали не видимость геосета щита, а материал в модели морпеха?
Что касается первого варианта - автору нужен не простой статичный аттач, а следование модели одежды движениям героя, насколько я понял. Такое можно провернуть за счет добавления анимации в модель предмета и синхронизации анимаций, но это реально геморрой - сам так делать пытался, в итоге пришел к методу "делаем одну модель со всеми анимациями и убираемой частью, потом экспоритруем основу и убираемую часть по отдельности с одинаковым скелетом и на закуску экспортируем m3a файл со всеми анимациями, который и используем чтобы оживить обе модели", мороки в 3д-редакторах с этим море, но работало идеально.
Duke911,
А что мешает внимательно прочитать вопрос и к чему мы пришли в обсуждении?
Вариант 1 не подходит Харгард.
Вариант 2 можно сделать намного проще, через глобальные анимации.
Вот вариант 3 для меня новость - в свое время я это так и не осилил разобраться, а никакой статьи на мапстере тогда еще не было.
Doc, ну так система гибкая не только в использовании, но и в разработке. Если возникает корнеркейс, то оценивается время на реализацию недостающего функционала, будь то новый тип эффекта, добавление параметров в существующий или допил модификатора в архитектурном приложении чтобы эффективнее использовать существующие эффекты. После оценки принимается решение - реализовать сейчас, отложить до следующей итерации или переубедить геймдизайнера, что нужно пойти другим путем.
Что касается UI, то он не может быть сложнее блендера - данные представляются в виде таблиц, как и в ск2, работа с геометрией отсутствует, работа со сложной анимацией в прямом смысле тоже, как и работа с материалами, рендерингом, параметрами сцены, камерами, светом - расставить примитивы, по таскать их по сцене, установить между ними связи, да вбить в таблицу данные - вот и все задачи архитектурного приложения.
Вот время разработки - да, его понадобится ощутимо больше, чем если ваять то-же самое, но на коленке. Так что эта технология скорее не для рядового инди разработчика, а для более-менее крупной студии, которая может себе позволить задержать очередной релиз ради разработки инструментария, который пригодится не только в текущем проекте.
Doc, важно отличать два этапа разработки - проэктирование и редактирование уже после завершения проектирования. Для каждого этапа нужен свой инструментарий и вот если рассмотреть, например, старкрафт2, то там хорошо сделан инструментарий для редактирования, но отвратнейше представлен инструментарий для проектирования, потому то мне и приходится лезть в чистый xml, как ты и говоришь - не удобно проектировать новые данные, когда есть только режим редактирования.
В идеале, инструментарий для проектирования полностью абстрагируется от системы, которая под ним работает - все нужные данные и связи между ними генерируются автоматически, а прямая работа с данными, выходящая за рамки "поменять 2 на 10" это удел особо тяжелых случаев, с которыми не справляется автоматическая генерация. И позволь тебя заверить, если случай тяжелый, то пилить его придется два дня, не зависимо от того, в данных это делается или в скриптах.
Могу даже привести пример того, как мог бы выглядеть инструментарий для проектирования.
Представьте себе что-то вроде 3д-редактора - со сценой, набором примитивов, таймлайном и кучей всякого другого добра.
Для начала архитектор разбрасывает на сцене даммиков - простые геометрические фигуры или модели или что угодно - это наши юниты. Дальше архитектор выбирает одного даммика - это будет кастер. Потом архитектор применяет к кастеру модификатор, допустим это будет запуск снаряда - на сцене появляется предполагаемая траектория полета снаряда, её можно перетянуть на другого даммика другим концом, тогда получится способность с указанием цели, или можно оставить указывать в точку - получим способность с указанием точки в качестве цели. Кроме того кривую траектории можно зафиксировать относительно угла поворота кастера - получим способность, которая не спрашивает цели, а летит в фиксированном направлении.
В этот момент на таймлайне появляется первый ключ - это стадия запуска способности. Если в том-же кадре набросать в кастера еще модификаторов, то получим способность, состоящую из множества одновременно активируемых эффектов.
Теперь архитектор переходит на второй кадр таймлайна, выбирает кривую траектории и отдает комаду "добавить ключ" - на таймлайне создается ключ, соответствующий моменту попадания снаряда в цель. Теперь во втором фрейме можно добавлять модификаторы как к кастеру, так и к траектории. Добавленные к кастеру модификаторы приведут к добавлению эффектов, срабатывающих из позиции кастера, а добавленные к траектории, соответственно, будут происходить с целью, в которую попал снаряд, при этом и те и другие будут привязыватсья к моменту попадения снаряда в цель.
После этого архитектор добавляет к кривой траектории модификатор выбора в области - вокруг точки соприкосновения траектории с землей или целью появляется окружность - это область, в которой будет производиться выборка целей. Попадающие в эту область даммики подсвечиваются и к ним можно добавить модификатор - это будет эффект, кторый будет применен к целям, попавшим в область действия.
Продолжать и детализировать этот пример можно до бесконечности, но, думаю, суть уже должна быть понятна.
В зависимости от конкретных требований, можно добавить и заполнение числовых и строковых данных на этапе проектирования, а можно и вынести это на этап редактирования. Я бы, наверно, добавил возможность редактировать данные сразу на этапе проектирования, но сделал бы это не обязательным или отключаемым элементом.
Doc, мне кажется мы сейчас дискутируем о преимуществах теплого перед мягким и наоборот, когда на самом деле оба объекта зеленые.
Рассмотрим простейший пример - нанесение урона и необходимость его учитывать.
В случае с эффектами у нас есть базовый тип эффекта "нанесение урона" и, соответственно, класс DealDamageEffect, который знает все о нанесении урона - за какое яичко надо потянуть юнита, чтобы он понял, что его ударили, куда подуть AI, чтобы тот проснулся и отреагировал на издевательства над его юнитом, в зависимости от реализации, этот же класс может и влияние брони обсчитывать и много чего еще делать, а может и не делать сам, а только раздавать пинки другим классам.
В случае со скриптами, если мы, конечно, не хотим миллион раз дублировать один и тот же код, мы будем вызывать некий метод DealDamage из библиотеки скриптов или из API или дергать его в юните, а уже юнит будет делать все остальное.
Получаем примерно те-же тапки, только граблей вокруг одних раскидано больше, чем вокруг других т.к. зафейлить в написании скрипта чуть проще. Кроме того, в случае с эффектом в момент нанесения урона мы имеем доступ ко всей иерархии эффектов, которые к этому привели, а значит и кучу данных о том, как, куда, кем и зачем был нанесен этот урон, а из скрипта все эти данные нужно передавать вручную в параметрах (да, я осознаю что объем передаваемых данных одинаков, просто в одном случае их автоматическая передача подразумевается спецификацией, а во втором - нет). Еще можно было бы заикнуться о быстродействии за счет нативной реализации эффектов и кеширования цепочек, но скриптовые языки нынче шибко шустрые пошли, так что без реальных тестов это можно только предположить.
А теперь десерт - та спецификация, которой я буду следовать, если мне когда-нибудь еще раз удастся дойти до проекта, где подобная система будет необходима, подразумевает возможность использовать скрипты и эффекты одновременно. Правда напрямую скрипту не положено работать с игровыми объектами - только через другие эффекты и сравнительно небольшой список функций API, а на скрипт ложится больше задача по выполнению арифметических и логических вычислений и дерганию за усы нужных эффектов. При этом сам скрипт помещается внутрь эффекта соответствующего типа и его свободно могут использовать другие эффекты, не задумываясь о том, скрипт это или нативный эффект. Более того, редактор данных подхватывает константы из скрипта и позволяет менять их в будущем через инструменты для работы с данными, а также создавать клоны этого эффекта с другими числовыми значениями, не дублируя скрипт (в идеале еще можно добавить ручное управление линковкой между полями таблиц данных и константами в скрипте для тонкой настройки и возможность отделить клона от родителя, превратив в самостоятельный скрипт).
Напоследок хочу уточнить три вещи
речь сейчас шла исключительно о взаимодействиях объектов, не затрагивая вопрос визуального отображения т.к. это отдельная тема
все это применимо только к проектам, переходящим определенную планку по объему данных, связанных с взаимодействием между объектами - например, писать пакмена или тетрис с подобной системой в основе это оверкил, а вот для какой-нибудь доты, где данные регулярно пополняются новыми героями, а старые правятся в угоду балансу, это самое то.
реализация визуального редактора данных в ск2 отстойна до такой степени, что голый xml часто предпочтительней, благо такую возможность разработчики предусмотрели, видимо их мапмекеры тоже от этого страдали когда кампанию делали.
Харгард, ага, через неё самую. Анимацию в смысле. Как по мне, это достаточно приятный метод в условиях, когда нет доступа к геосетам - насколько я знаю, формат m3 не гарантирует сохранения порядка и именования геосетов, а значит гарантирует обилие зубов, которые нужно сверлить через клоаку в попытках поймать нужный геосет. Тем более, что эта функциональность нужна не так уж и часто - большая часть решается через аттачи и отдельные модели - в конце концов, кто мешает смоделить одежду на персонаже, а потом экспоритровать её отдельно, с сохранением того-же скелета, а анимации прикрепив через m3a файл, общий для обоих. Рулить в итоге этим делом далеко не так сложно, как кажется.
alexprey, потому что команда, как правило, состоит не только из одних программистов и все доступные программисты, как правило, заняты не созданием контента и мыслями о балансе, а более важными вещами, вроде допиливания движка и багфикса.
Согласитесь, было бы странно, если бы, например, 3д-дизайнер вместо того, чтобы делать модели в 3д редакторе, прописывал бы их в коде или работал в редакторе, а потом экспоритровал результат не в сжатый бинарный формат, а прямо в програмный код.
Та-же судьба ждет и игровые данные, которых в крупных проектах становится все больше и больше - стать со временем независимыми от кода и получить отдельного специалиста для работы с ними.
Doc, не знаю откуда такая лютая ненависть к ск2 и самой идее, но лично я пользуюсь и редактором данных и скриптами, когда у меня есть настроение что-то там по делать и нет настроения хардкорно кодить в более серьезном проекте. Что касается скриптового языка - это довольно удобно, но при такой архитектуре совершенно нереально часть работы спихнуть на геймдизайнера - все приходится кодить лично, что хорошо при работе в одно сопло, но отвратительно вписывается в командную работу.
Посмотри как сделан щит у морпеха терранов. Если не ошибаюсь, близы даже подарили его исходник в составе Art Tools. Под щитом имею в виду улучшение, после которого на модели появляется щит, а у юнита добавляется здоровье.
Хотя, возможно, там через анимации сделано - посмотрю вечером как до машины с ск2 доберусь.
Плохая новость - да, единственный приходящий мне на ум пример с отображением/скрытием геосета реализован таки за счет анимаций.
Хорошая новость - в модели нет отдельных анимаций для состояний "со щитом" и "без щита" - есть один набор анимаций в состоянии "со щитом" и анимация на один кадр в состоянии "без щита".
Резюмируя выше сказанное - теоретически это можно реализовать, но нужно будет во-первых изрядно по ломать голову, а во-вторых без редактирования модели не обойтись.
Doc, а еще лень, привычка к варкрафту и отсутствие информации. Ну и главная проблема у новичков это не столько само разбиение, сколько система агентов/актеров, которые отвечают за отображение всей визуальной части и по которым практически нет внятной документации даже на англоязычных ресурсах.
DarkDes, я в редакторе ск2 делал систему пошаговой игры на доске, в которой кодом было реализовано по большому счету только отображение таймера хода в интерфейсе и пара хаков, позволяющих обойти мелкие, но неприятные недостатки возможностей движка - все остальное было сделано в редакторе данных. Причем таймер тоже был на данные завязан, код отвечал только за синхронизацию интерфейса и таймера. Потом, конечно, кода поднакопилось, когда я захотел еще дальше за пределы базовых возможностей движка выйти.
Что касается интерпретируемого языка - во-первых в идеале он тоже нужен, просто для хранения данных это избыточное решение, а во-вторых намного проще интегрировать тот-же Lua или даже джаваскрипт, чем писать что-то свое.
DarkDes, даже не знаю что сказать - для меня идея разбиеня сложных способностей на элементарные эффекты выглядит настолько очевидной, что меня приводят в легкий ступор утверждения будто это очень сложно. И код намного чище получается - вместо бесконечного количества классов, каждый из которых описывает отдельную способность, получаем небольшой набор классов, каждый из которых выполняет свою сугубо специализарованную задачу. А если еще и довести дело до конца и вынести из кода все данные, получаем возможность править баланс не перекомпилируя ни строчки кода, да и создавать новых героев и способости тоже вполне реально, если они вписываются в уже существующие базовые механики.
Praytic, я хоть и не имею ни малейшего отношения к проекту, отвечу т.к. немно ознакомлен с тем, как работает гринлайт. Как правило, там смотрят не на кол-во лайков, а на их динамику, плюс все это в сравнении с другими проектами гринлайта. Что касается выкладывания в шоп - там нужно разгрести горку бюрократической возни для начала - занимает от пары дней до пары месяцев в разных случаях, плюс не стоит забывать про интеграцию с API и подготовку всех файлов для заливки - это тоже само себя не сделает.
"Превращает существо в золото. (если у существа меньше 100хп)"
проверка условий это отдельный вопрос, но суть примерно та-же - есть типы проверок и параметры
превращение в золото - зависит от того, какие требуются результирующие параметры, например можно фиксированное значение выдавать, можно по набору условий выдавать из списка возможных значений, а можно использовать какую-нибудь хитрую формулу
считаю что визуальная часть слушает события от логической и сама по себе знает что ей в том или ином случае делать, но по большому счету никто кроме здравого смысла не мешает и это запихнуть в эффекты
также для этого примера буду считать, что вознаграждение фиксированное, а проверка запаса здоровья делается на этапе каста способности - применить её на кого-то, у кого больше хп просто не даст и, соответственно, эффектам это проверять не нужно
получаем следующую цепочку эффектов:
1 несколько эффектов (список эффектов - эффекты 2 и 3)
2 получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - xxx)
3 нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)
предположим, что нам надо варьировать кол-во золота в зависимости от ряда условий, проверка по прежнему на совести способности
несколько эффектов (эффекты 2, 8 )
проверка нескольких условий (список условий - 3, 5, список эффектов - 4, 6, прерывать проверку после первой удачной - да, действие по умолчанию - 7) работает путем последовательной проверки объектов-условий и активации соответствующих им объектов-эффектов, если условие вернет true, можно обрвать после первого нахождения true, можно не обрывать, можно назначить эффект, который будет вызван, если ни одно условие не вернет true
условие типа "классификация цели" (цель - цель заклинания, ожидаемая классификация - механизм)
получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 20)
условие типа "классификация цели" (цель - цель заклинания, ожидаемая классификация - растение)
получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 5)
получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - 10)
нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)
предположим, что проверять подходит ли нам цель должны эффекты, а получаемое золото фиксировано
проверка условия (условие - 2, эффект при true - 3, эффект при false - нет)
условие типа "сравнение характеристик с константой" (цель - цель заклинания, характеристика - здоровье в %, операция - меньше или равно, значение - 10)
3 несколько эффектов (эффекты - 4, 5)
получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - xxx)
нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)
по остальным распишу позже, если еще будет интересно
А на jass можно закодить новые способности? Думал вот вместо игры сделать карту-прототип одной старой идеи, если конечно редактор карт такое позволит :)
И да и нет. Данные способностей задаются только в редакторе объектов и код на них никак не повлияет, но игрока можно обмануть - создать способность, которая ничего не делает и отлавливать её применение, после чего делать то, что нужно. Есть один нюанс - применить способность триггерно из воздуха нельзя, потому если нужно использовать в качестве составляющих своей способности какие-то из родных для движка, приходится создавать невидимого юнита, который получает приказ применить способность, после чего удаляется. Короче куча мороки - быстрее игру написать имея некоторые навыки и план, чем с нуля во всех нюансах разобраться.
Для сравнения, во втором старкрафте все намного веселей - то что я привел в качестве примера там выглядело бы почти так-же - как набор данных в редакторе данных и ни строчки настоящего кода.
upd: не знаю зачем я написал условие <=10% если заказ был <100хп чистыми, но суть та-же
DarkDes, в варкрафте3 можно было только менять характеристики уже существующих способностей или их копий. Кто хотел большего - использовал внутренний язык программирования jass.
В старкрафте 2 же это дело реализовано на порядок приятней, но и одновременно сложней. Не буду это расписывать - можно несколько дней убить и ничего понятней не станет.
Что касается придумок геймдизайнера - большая часть даже самых замысловатых способностей сводится к простейшим элементам - нанесение урона, наложение бафа, выбор объектов в области, запуск снаряда, взаимодействие с физическим движком, активация нескольких эффектов подряд, выбор одного из эффектов по условию, периодические действия и так далее. Причем этот список можно расширять по мере необходимости или дополнять уже существующие типы эффектов дополнительными параметрами.
Если хочешь, можешь сыграть роль геймдизайнера и придумать способность или даже набор способностей, а я распишу один из вариантов, как это можно было бы реализовать и какие бы базовые элементы для этого понадобились бы.
DarkDes, собственно, я отталкиваюсь от двух источников - то, как это реализовано в Starcraft2 у Blizzard и то, как это было реализовано в свое время у меня в небольшом приватном проекте.
У Blizzard этот механизм вобще вынесен на уровень данных и как устроен сам движок остается только догадываться, а в моей версии похожий механизм был реализован довольно криво и с тех пор я уже успел серьезно поменять свою спецификацию такого механизма, но практической реализации новой спецификации еще не делал.
Суть в том, чтобы разобрать все сложные эффекты на простейшие составляющие и реализовать возможность собирать составные эффекты из кусочков.
Да, кстати, хочу уточнить кое что - слово "эффект" в данном контексте стоит воспринимать как "действие", может так будет понятнее о чем речь.
Бафы это отдельная тема, по которой мне не так много чего есть сказать. Разделить их можно на три основные категории - периодические, постоянные и маркеры. Маркеры - ничего не делающие бафы, позволяющие динамически сохранить какую-то дополнительную информацию об объекте, периодические - вызывают по таймеру привязанный к ним эффект. Сложнее всего с постоянными - они напрямую зависят от того, как реализованы характеристики объектов. Помимо этого еще стоит учитывать что у бафов может быть длительность действия, а может и не быть, что бафы могут иметь не только основной эффект, но и, например, эффект, который запускается только при снятии бафа с цели.
При этом наложение бафа на цель и снятие бафа в обход его жизненного цикла делаются, естественно, не напрямую, а через соответствующий тип эффектов.
Doc, но не стоит и уходить в противоположную сторону спектра, со скатыванием в макаронный код и месяцами дебага и рефакторинга после малейшего изменения. Неоднократно был свидетелем ситуации, когда небольшие и не особо критичные баги откладывали на "никогда" т.к. их фикс требовал изменения пары строк в тех частях кода, которые "трогать нельзя" т.к. это ведет к необходимости пересборки буквально всех модулей проекта и астрономических объемах работы для QA.
В идеале добавить бы в панель управления проектом раздел, в котором можно загрузить картинку, указать подписи и оттуда-же отправить заявку модератору на утверждение.
Molecyla,
Для начала нужно перейти на PTR клиент. Затем запустить игру (в PTR регионе, естественно) - залогиниться и создать персонажа. Потом можно начинать работать с редактором. В редакторе нужно установить две зависимости к карте - одна в списке стандартных и там только модели, а вторая в списке зависимостей на сервере и там только данные. Если установлена только первая зависимость - модели можно смотреть в редакторе сцен, плюс к ним можно самостоятельно создавать обмотку в редакторе данных и использовать, но для этого есть вторая зависимость.
KorvinGump, интересную информацию вы раскопали, однако. Это же прецедент включения превышающего все лимиты веса пользовательского ассет-пака в архивы игры. Да, ассеты там на 90% это чистой воды конверт, но прецедент всеравно интересен - получается при доле удачи, разумном весе и должном качестве материалов вполне реально раскрутить близов на подобный ход.
» StarCraft 2 / Скрыть/показать часть модели или геосет
» StarCraft 2 / Скрыть/показать часть модели или геосет
» StarCraft 2 / Скрыть/показать часть модели или геосет
» StarCraft 2 / Скрыть/показать часть модели или геосет
А что мешает внимательно прочитать вопрос и к чему мы пришли в обсуждении?
Вариант 1 не подходит Харгард.
Вариант 2 можно сделать намного проще, через глобальные анимации.
Вот вариант 3 для меня новость - в свое время я это так и не осилил разобраться, а никакой статьи на мапстере тогда еще не было.
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
» StarCraft 2 / Скрыть/показать часть модели или геосет
» StarCraft 2 / Скрыть/показать часть модели или геосет
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» StarCraft 2 / Скрыть/показать часть модели или геосет
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
» Beyond Despair / OWSP на Greenlight!
Ред. prog
» Бродилка / [Лог #7] Класс рисовальщика.
1 несколько эффектов (список эффектов - эффекты 2 и 3)
2 получение ресурсов (тип ресурса - золото, цель - хозяин кастера, количество - xxx)
3 нанесение урона (кол-во урона - xxx, цель - цель заклинания, фатальный урон - да)
- проверка условия (условие - 2, эффект при true - 3, эффект при false - нет)
- условие типа "сравнение характеристик с константой" (цель - цель заклинания, характеристика - здоровье в %, операция - меньше или равно, значение - 10)
3 несколько эффектов (эффекты - 4, 5)» Бродилка / [Лог #7] Класс рисовальщика.
» Бродилка / [Лог #7] Класс рисовальщика.
» Dead Eternity / Пост Негодования
» Эксперименты в Пустоте / Немного безумия
» WarCraft 3 / CASC архив, проблема для экспорта(конверт wow)
» Эксперименты в Пустоте / Немного безумия
Для начала нужно перейти на PTR клиент. Затем запустить игру (в PTR регионе, естественно) - залогиниться и создать персонажа. Потом можно начинать работать с редактором. В редакторе нужно установить две зависимости к карте - одна в списке стандартных и там только модели, а вторая в списке зависимостей на сервере и там только данные. Если установлена только первая зависимость - модели можно смотреть в редакторе сцен, плюс к ним можно самостоятельно создавать обмотку в редакторе данных и использовать, но для этого есть вторая зависимость.
» Эксперименты в Пустоте / [WIP] Minecraft, микроблоки
Ред. prog
» StarCraft 2 / Blizzard выпустят свой контент-пак на тему WC3
» StarCraft 2 / Blizzard выпустят свой контент-пак на тему WC3