Fakov, расскажи подробней о "распределении" и "требованиях поведения" и как это решает проблему сложности использования аналогичных механизмов в юнити и анриле.
Fakov, мне кажется ты опять упускаешь из вида важную деталь - кто и как должен определять какая анимация должна воспроизводиться в каждый конкретный момент времени? В варе все просто - у юнита есть стандартный набор состояний, согласно которым движок дергает анимации, но этот набор состояний у вара специфичен для RTS и весьма ограничен, даже с учетом возможности влиять на анимации тегами.
Fakov, я немного о другом - не важно с моделью в комплекте идут анимации или к скелету подходят анимации взятые из базовой комплектации движка, сложность в другом - научить объект правильно воспроизводить эти анимации в зависимости от своего состояния. Даже если запилить пресет который будет уметь переключать анимации стандартных состояний на подобии того как это делает вар, ему всеравно нужно будет где-то указывать какие анимации соответствуют какому состоянию, как минимум для каждой модели, а лучше с возможностью переопределения для каждого типа юнитов. Поскольку анимация не является неотъемлемой частью модели, а лежит где-то отдельно, то по стандартному имени как в варе её достать уже не получится. И уже на этом этапе простота использования начинает сыпаться - пользователь должен будет понимать где и почему он должен перечислить все используемые моделью анимации и еще и разместить эти анимации в правильные слоты - birth в birth, stand в stand. Для поставляемых вместе с анимациями моделей эту проблему можно частично решить, но тут зарыта новая собака - рано или поздно понадобится поддержка более чем одного стандартного пресета (анимационный пресет от RTS не очень подходит для какого-нибудь шутера от первого лица) и опять пользователю нужно будет понимать происходящее чтобы делать осмысленный выбор там где невозможна автоматизация. И таких собак, одна за другой, огромное количество, в какую часть движка ни ткни. Всем нужно будет найти какое-то решение или безжалостно резать функциональность и настраиваемость.
Я же не с потолка это все пишу - я давно всерьез рассматриваю возможность реализации подобного проекта на основе UnrealEngine4 с релизом либо в стиме либо в анриловском маркете, либо и там и там с разным функционалом. Но во-первых я еще не нашел даже теоретического решения всем проблемам которые успел обнаружить, а во-вторых сейчас в разработке более интересные мне проекты, а этот ведется только в форме документации.
А теперь представь, что у тебя есть движок где ты можешь сделать вот это описанное без специальных навыков в программировании?
Что в UnrealEngine 4 что в старкрафте 2 это делается без навыков программирования, в визуальных редакторах, проблема в том, что нужно понимать что ты делаеш чтобы ими пользоваться, недостаточно обеспечить наличие модели с правильно именоваными анимациями.
Представь что модель является коммерческим ассетом без исходников, редактировать который ты не можеш согласно лицензии, а тебе нужен другой набор анимаций или материалов - при монолитной структуре модели для этого нужно обращаться к автору модели или нарушать лицензию, а при модульной структуре никто не мешает использовать эту модель с другими анимациями и материалами.
Максимальная доступность к изменениям и простота освоения и использования вещи практически не совместимые. Тот же WC3 очень сильно ограничивает пользователей в возможностях, за счет чего и становится возможной та самая ламповость и простота. Например, сетевой код полностью скрыт от пользователя и оптимизирован под RTS с фиксированным кол-вом игроков, без малейшего шанса как-то на это повлиять, в то время как под разные задачи должны применяться разные алгоритмы сетевого взаимодействия. Или вот более наглядный пример: модели в варе это монолитные сущности, с вшитыми анимациями, текстурами и свойствами материала, в то время как в современных движках модель отделена от анимаций и при совместимости скелетов одну анимацию можно использовать на любой модели без редактирования модели, также от модели отделены и материалы с текстурами - к любой модели при желании можно применить любой материал. Не менее показательно использование анимаций в WC3 - определенные действия всегда вызывают определенные анимации, без вменяемой возможности на это повлиять, в то время как движок позволяет определить любому объекту любой набор анимаций, условий их воспроизведения и генерируемых при этом событий, но ценой необходимости разбираться как вся эта система анимаций работает и необходимости настраивать анимации каждому объекту по отдельности.
Kirill78, а смысл? кто эту правленую версию вара будет качать из сомнительных источников ради неизвестно кем запиленых фиксов? Кроме того, копаться в чужом коде такой древности и объема - то еще удовольствие.
во вторых бот не может писать в кэш без fakeplayer'a
Вот что получается если вклиниваться в чужой диалог пытаясь то ли компенсировать недостаток общения, то ли в наглую набивая опыт... Где я писал про кеш и хостботов кроме цитаты? Зачем ты пишешь это обращаясь ко мне, будто это был мой тезис?
Есть более-менее надежный, но сложный в реализации способ - часть ключевой игровой логики выносится в подгружаемую мемхаком dll - тогда простое выпиливание защиты уже ничего не даст т.к. карта перестанет правильно работать, а восстановить потеряный кусок уже не так просто, а дальше тем-же мемхаком делаем любую дичь, хоть связываемся с хостботом напрямую и спрашиваем он ли хостит эту карту, хоть проверяем гандикапы (принципиально важно чтобы это было не в jass коде и при попытке удалить удалялось только вместе с упомянутым выше куском игровой логики).
Минусы:
долго и сложно в реализации
требует мемхак и, соответственно, не работает в версиях вара под которые мемхака не существует
всеравно можно обойти если заморочиться декомпиляцией dll
UrsaBoss, во-первых я обращался к nvc123. Во-вторых предложеный им способ я недавно предлагал при другой постановке задачи, там он решал поставленую задачу, тут не решает. В-третьих, если затолкать проверку HCL или информации передаваемой в карту любым другим способом, то это конечно остановит хомячков, не способных вскрыть карту и выпилить защиту, но автора вроде как что-то по серьезней интересовало, чем защита от хомячков.
сделай чтобы бот писал в кэш карты пароль
в карте хранишь хэш этого пароля
после старта карты высчитываешь хэш полученного пароля и сверяешь с тем что записан в карте
если совпали то значит карта на твоём боте
если пароля нету или не совпали то значит карта не на твоём боте
увы, никто не помешает просто отодрать от карты любую защиту и захостить результат, в отличии от ситуации когда нужно защитить пароль от сторонних глаз и помешать его вводу в официальной версии своей карты
Раз близы утруждаются возней с каском, значит планируют что-то где он им понадобится - скорее всего это будет ремастер, но чем черт не шутит, вдруг и дополнение выкатят. Просто так такие масштабные изменения в архитектуре не делаются.
современный движок = ядро, которое и есть собственно движок + среда для кодинга, часто сторонняя (эклипс, студия, да хоть блокнот) + визуальный редактор в котором ведется работа с ассетами, картами и прочими не связаными напрямую с кодом аспектами разработки, там-же всякие дизайнерские инструменты + набор внешних утилит, для компиляции, для работы с ассетами вне редактора, для конвертации и импорта и так далее, в зависимости от движка + различные фреймворки построеные вокруг движка но не входящие в состав ядра, предназначеные для ускорения разработки и решения типовых задач + опционально, инструменты для скриптинга в рамках API движка, с доступом к низкоуровневым системам
предположим, что конструктор построен на движке, а не написан с нуля, тогда:
конструктор = исполняемый файл "игры", умеющий загружать результаты работы редактора + визуальный редактор с отсутствием доступа к низкоуровневой части движка и значительной части инструментов, но с добавлением инструментов для работы с игровыми системами, как правило без инструментов для компиляции, но с возможностью сохранения результата работы в специальный формат + встроеные в редактор инструменты для скриптинга в рамках ограниченого API не имеющего доступ к низкоуровневым системам и непосредственно движку + ядро движка под капотом, о существовании которого пользователь конструктора может даже не знать и это не повлияет на его продуктивность + готовые игровые механики и сущности, не в виде фреймворка, а в состоянии в котором их при желании можно было бы релизить как есть после заполнения контентом + опционально, готовый контент и ассеты (пункты про отсутствие компиляции и работу исключительно через готовый исполняемый файл опциональны - возможны различные варианты, включая генерацию лаунчера и даже компиляцию).
quq_CCCP, если бы ты читал внимательно о чем речь, а не только самое начало дискуссии, то понял бы, что идея и цель вовсе не в том чтобы затолкать именно близовский вар на мобилки.
PrincePhoenix, в WE я могу запилить варкрафто-подобную RTS не написав ни строки кода, просто измываясь над редактором данных. И уйти достаточно далеко от варкрафтоподобной ртс на одном гуи, которое кодом ну никак не является в виду своей простоты и ограниченности. Кроме того, есть огромная разница между низкоуровневым кодингом глубоко в недрах движка и скриптингом в рамках ограниченного высокоуровневого API поверх уже существующей низкоуровневой реализации.
Да и в конце концов, чем юнити и уе не конструкторы? Если откинуть всю эту нудятину, типа кода, то это как раз таки те самые конструкторы, только более углубленные в кастомизации, а за счёт этого и сложные в понимании
Бред же. Конструктор подразумевает наличие уже готовой низкоуровневой реализации - сетевой код, базовые игровые механики и сущности, управление, причем все это должно быть в готовом к релизу виде сразу из коробки, без необходимости писать код если не нужны нестандартные механики. Движки же таким не занимаются т.к. рассчитаны не на хомячков, а на разработчиков, которые в состоянии разобраться в движке и запилить то что им надо так как им надо.
Fakov, такого редактора нет и под пк, насколько мне известно - движки оперируют более низкоуровневыми понятиями (имхо, по объективным причинам), а тут нужен конструктор в котором вся низкоуровневая реализация уже готова и требует только небольшой настройки со стороны пользователя, но достаточно гибкая чтобы в рамках "настройки" можно было получить большое разнообразие конечного продукта. При этом настройка не должна требовать понимания низкоуровневых сущностей (неудача отличного редактора ск2 тому пример) и позволять свободное добавление сторонних ассетов. В идеале там должно быть еще и с несколько пресетов, чтобы не нужно было делать костылями шутер из ртс и наоборот.
Валв попытался добиться такого результата со своей дотой2 и кастомками на её основе, но там аналогичный ск2 факап - слишком высокий порог вхождения ради большей гибкости.
Fakov, вар, мобайл, юнити - полностью не мой профиль, так что мвп не будет. А платформа эксплуатирующая удачные решения и аудиторию вара у меня в планах есть, но под стим, на анриле и после того как примерно три других более интересных мне проекта будут доведены до логического завершения.
Naadir, не уверен в том что именно я не должен вплетать, но представь ситуацию, в которой Джайна находится рядом с Артесом, не дает ему сломаться и наделать слишком много глупостей, ну а поскольку шоу маст го он, то события все-же доходят до слияния с Нерзулом, но вмешательство Джайны позволяет Артесу сохранить свое собственное сознание. Вот только в ходе развития сюжета оба всеравно измажутся достаточно чтобы люди не горели желанием кинуться к ним с распростертыми объятиями. Да и Плеть, пусть и более слабая и малочисленная, никуда не денется и по прежнему будет требовать контроля. Да и Легион не спишет долги Нерзула и наверняка попытается спросить их с Артеса.
Fakov, редактор на пеке, офк, девелопмент прямо на телефоне это рак, я пробовал. Но редактор ни в коем случае не родной варовский - с родным больше гемороя будет, чем написать все с нуля сразу под новые реалии платформы.
Юз контента из вара - проблема - авторские права не дадут выкладывать близовские ассеты, а далеко не каждый пойдет качать мпку из вара и заталкивать их себе в телефон/планшет. Теоретически, поддержка загрузки моделей из оригинальных мпку в рантайме это круто, но это не может претендовать на роль ключевой фичи иначе сильно сужает целевую аудиторию и потенциально ограничивает функционал.
Fakov, я прошарил, но смысл? Я еще понимаю запилить платформу с похожим "ламповым" редактором, слизав с вара удачные решения и улучшив неудачные, с встроенными импортерами-конвертерами текстур и моделей, может даже с конвертером целых карт в новый формат (с неизбежной последующей ручной доводкой) и попытаться переманить туда часть варкрафто-дрочеров, такое может даже взлететь, правда не очень понятно как монетизировать. А вот извраты с попытками сохранить полную совместимость с варовскими форматами... Зачем и ради чего?
Naadir, и я не согласен с утверждением что ничего бы не изменилось - это, как минимум, могло бы повлиять на психологический профиль Артаса и некоторые его решения, а как максимум - Джайна вполне могла бы занять место рядом с троном Короля Лича, в той или иной роли.
Naadir, это была отсылка к одной из неофициальных версий, согласно которой у Артаса крыша начала ехать после того как Джайна ему не дала и предложила подождать, а уже на это наложились последствия остальных событий.
Ред. prog
» Fa_losophy / Движок 3D игор
» Fa_losophy / Движок 3D игор
» Fa_losophy / Движок 3D игор
Ред. prog
» Fa_losophy / Движок 3D игор
Ред. prog
» Fa_losophy / Движок 3D игор
» Fa_losophy / Движок 3D игор
Ред. prog
» WarCraft 3 / Защита карты от редактирования
» WarCraft 3 / Защита карты от редактирования
» WarCraft 3 / Защита карты от редактирования
Минусы:
Ред. prog
» WarCraft 3 / Защита карты от редактирования
Ред. prog
» WarCraft 3 / Защита карты от редактирования
» WarCraft 3 / Простой способ подключения собственных MPQ-архивов
» Fa_losophy / Wc3 Mobile?
конструктор = исполняемый файл "игры", умеющий загружать результаты работы редактора + визуальный редактор с отсутствием доступа к низкоуровневой части движка и значительной части инструментов, но с добавлением инструментов для работы с игровыми системами, как правило без инструментов для компиляции, но с возможностью сохранения результата работы в специальный формат + встроеные в редактор инструменты для скриптинга в рамках ограниченого API не имеющего доступ к низкоуровневым системам и непосредственно движку + ядро движка под капотом, о существовании которого пользователь конструктора может даже не знать и это не повлияет на его продуктивность + готовые игровые механики и сущности, не в виде фреймворка, а в состоянии в котором их при желании можно было бы релизить как есть после заполнения контентом + опционально, готовый контент и ассеты (пункты про отсутствие компиляции и работу исключительно через готовый исполняемый файл опциональны - возможны различные варианты, включая генерацию лаунчера и даже компиляцию).
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Fa_losophy / Wc3 Mobile?
» Naadir / Первый интерактив
Ред. prog
» Fa_losophy / Wc3 Mobile?
Юз контента из вара - проблема - авторские права не дадут выкладывать близовские ассеты, а далеко не каждый пойдет качать мпку из вара и заталкивать их себе в телефон/планшет. Теоретически, поддержка загрузки моделей из оригинальных мпку в рантайме это круто, но это не может претендовать на роль ключевой фичи иначе сильно сужает целевую аудиторию и потенциально ограничивает функционал.
Ред. prog
» Fa_losophy / Wc3 Mobile?
» Naadir / Первый интерактив
» Naadir / Первый интерактив