Эта проблема вызывается физическими повреждениями железа, как я нагуглил
Детали так сходу не скажу, но SFile.cpp - кусок storm.dll, вроде как обработчик строк
На мой взгляд, самый классный герой получился у Toadcop (что неудивительно), остальные участники фантазию при разработке практически не применяли.
Самым качественным в плане фактической реализации считаю громовержца от Diaboliko, но преимущественно не из-за механик способностей, а из-за весьма грамотного применения мемхака в них.
Самый (и единственный) достойный подход к визуализации споосбностей показал quq_CCCP, здесь даже говорить нечего.
По балансу судить не берусь. По-хорошему, чтобы давать здесь хоть какую-нибудь оценку, нужно иметь груши для биться с личными и суммарными счётчиками DPS.
Также лично мне казалось, что "концепция" и "актуальность в доте" должны были быть разными пунктами. Разумеется, Баланар будет актуален в доте, ведь он уже в ней есть, но сама по себе концепция "а давайте переделаем то, что есть" не может представлять заметной ценности.
К окончанию конкурса не успел запилить визуал абилам, не успел => забил. Постараюсь на этой или следующей неделе допилить и выложить, но хз как получится, очень уж дофига дел запланировано. Могу описание залить :D
тому, что было в памяти на момент её выделения под переменную. Выделение памяти и её очистка - разные процессы, именно поэтому считается хорошим тоном задавать значения перед тем, как планируешь их использовать.
По-идее, она подчёркивает механику работы абилы, а реальная механика обычно всё-таки по сектору круга фигачит, не в чистом треугольнике, отсюда и когнитивный диссонанс, и по сути практически обман игроков (если эффект где-нибудь уже применяется).
Господа, без обсуждений личных дел на публике, пожалуйста. Если эффект в базе - значит, он туда попал не просто так.
На гифке вспышка будто пролагивает в начале.
Волну лавы я бы сделал так, чтобы не строго на одной линии умирали источники частиц, а полукругом. Или как-нибудь бы избавился от вспышки по этой линии в конце, чтобы частицы просто затухали, долетая туда. Предлагаю сделать 2 вида частиц - первые со вспышкой, умирают в рандомные периоды, вторые - без вспышки, умирают строго через затухание на определённой дистанции.
В нём писывается логика движения, однако свой .update() он самостоятельно никаким образом не вызывает.
Кстати, технически вектор "impulse" выражает m*v, поскольку в карте-примере из поста масса фактически не имеет значения (видимо, просто забыл удалить её из кода) и её хранение отдельным используемым скаляром приведёт только к увеличению числа рассчётов; при увеличении функционала, например, при добавлении взаимных столкновений, массу нужно будет вынести из вектора в отдельный скаляр, а вектор назвать "velocity". Показанная карта-пример, конечно, не лучшая из возможных, но, на мой взгляд, вполне адекватна (если оставить за скобками утверждение о полноценности модели в ней).
Попробую популярно пояснить лежащий в основе архитектуры подход.
Физический объект является описанием поведения игрового объекта (behavior; VisObj и DmgObj - тоже behavior по сути), он содержит в себе только те данные, которые касаются непосредственно связанного с физикой поведения игрового объекта (определение и движение объекта в пространстве), и никаких более. Этими данными являются: радиус-вектор, вектор импульса, радиус столкновений и логика движения. Последнюю в теории можно вынести из объекта, но тогда система несколько потеряет в модульности. Кроме того, хранить логику движения внутри метода полезно тем, что в случае её отсутствия/отключения у какого-либо объекта код движения даже читаться не будет.
Как абсолютно верно заметил Doc, результаты движения должны обрабатываться не в движимом теле или его компоненте, а в движущей системе, так как в результате перемещения игрового объекта он может вступить в те или иные взаимодействия с другими сущностями, обладающими физическим компонентом. Их сам по себе объект обработать не способен и не должен быть способен, он не "божественный".
Сам игровой объект - оболочка, через которую связаны все его компоненты. Система обработки ("стак" в GameField) обращается к нему с командой на апдейт, все взаимодействия между компонентами производятся в нём и нигде более.
Замечание про именование как причину ошибки было хорошим, однако в целом советую более вдумчиво анализировать архитектуру перед тем, как высказаться о её несостоятельности или неверном распределении функциональной нагрузки по её элементам.
Оптимизация это вообще дело последнее, которое выполняется уже после реализации всего, что хотели реализовать, поскольку добавлять что-нибудь еще к оптимизированному коду - это чистое мучение.
В карте-примере отсутствует преждевременная оптимизация. Ощущение её наличия могло возникнуть из-за того, что данные, которые никак не задействованы в логике примера, были удалены из неё целиком. Массу вот только пропустил.
Да, и еще: 9,8 - это для метров. В варике 1 единица расстояния это вовсе не метр, а гораздо меньшая величина.
Это вполне очевидно. Выставил 9.8, визуально результат меня устроил, с чего бы менять?
В бонусе - тебе не придется перерасчитывать величину gravity каждый раз, когда ты меняешь tickrate.
Такой себе по ценности, одно дополнительное деление и одно дополнительное умножение раз в практически никогда процессор сможет выдержать.
обязательно должен везде делится на tickrate
Точно! Каждое деление вектора на число - это три операции деления, каждый объект описывается двумя векторами, то есть всего шесть операций деления. Достаточно согласиться с твоим предложением, и их количество вырастает до девяти, что не то, чтобы критично, но в 1.5 раза тяжелее без каких-либо профитов вообще.
Кроме того, в самом коде физического компонента объекта логика описывается пусть с уже обмусоленной ошибкой, но всё-таки универсально: при обновлении объекта он смещается в направлении суммирующей на её величину, а скейлинг этой величины под тикрейт - работа контроллера, который обрабатывает этот объект и устанавливает сам тикрейт.
» WarCraft 3 / Отлов уровня воды
» WarCraft 3 / Вставка символов в текст
» WarCraft 3 / Отлов уровня воды
» WarCraft 3 / Отлов уровня воды
» WarCraft 3 / Неизвестная ошибка при выборе кампании
Детали так сходу не скажу, но SFile.cpp - кусок storm.dll, вроде как обработчик строк
» WarCraft 3 / Отлов уровня воды
» WarCraft 3 / Отлов уровня воды
» WarCraft 3 / создание нового героя если уровень героя больше 50
ApoloZ2:
» WarCraft 3 / создание нового героя если уровень героя больше 50
Ред. Clamp
» Dota 2 / Результаты конкурса героев Dota 2
Самым качественным в плане фактической реализации считаю громовержца от Diaboliko, но преимущественно не из-за механик способностей, а из-за весьма грамотного применения мемхака в них.
Самый (и единственный) достойный подход к визуализации споосбностей показал quq_CCCP, здесь даже говорить нечего.
По балансу судить не берусь. По-хорошему, чтобы давать здесь хоть какую-нибудь оценку, нужно иметь груши для биться с личными и суммарными счётчиками DPS.
» Dota 2 / Результаты конкурса героев Dota 2
» Dota 2 / Результаты конкурса героев Dota 2
У героя Toadcop'а даже ульт не показали.
Ред. Clamp
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
» WarCraft 3 / Случайная точка в области, утечка ли?
» WarCraft: Armies Of Azeroth / WarCraft: Armies Of Azeroth
» WarCraft 3 / Проблема с работой библиотеки
Ред. Clamp
» WarCraft 3 / Магма
Ред. Clamp
» WarCraft 3 / Магма
Волну лавы я бы сделал так, чтобы не строго на одной линии умирали источники частиц, а полукругом. Или как-нибудь бы избавился от вспышки по этой линии в конце, чтобы частицы просто затухали, долетая туда. Предлагаю сделать 2 вида частиц - первые со вспышкой, умирают в рандомные периоды, вторые - без вспышки, умирают строго через затухание на определённой дистанции.
Ред. Clamp
» WarCraft 3 / Конфликт имён, библиотеки, области
Ред. Clamp
» WarCraft 3 / Не работает триггерный спелл.
Ред. Clamp
» Clamp'ова кухня / Clamp's Physics
» Монстрофилию в массы / Гаргульечка
Ред. Clamp
» Clamp'ова кухня / Clamp's Physics
Кроме того, в самом коде физического компонента объекта логика описывается пусть с уже обмусоленной ошибкой, но всё-таки универсально: при обновлении объекта он смещается в направлении суммирующей на её величину, а скейлинг этой величины под тикрейт - работа контроллера, который обрабатывает этот объект и устанавливает сам тикрейт.
» WarCraft 3 / Юниты самовольно убегают