Любой матчмейкинг приводит к образованию в среде игроков культа пятидесяти процентов.
Не знаю про культ, но техническое описание любой системы матчмейкинга действительно можно свести к тому, что система стремится держать винрейт игрока на 50%. Если игрок имеет его выше, значит, он сильнее, чем считала система, и она его поднимает, и наоборот.
Мне понравилось всё, что во внятном виде показано было, то есть всё кроме ARPG и Project L. С этими двумя ничего не понятно, кроме того, что они есть и в каком жанре.
Постебались над знаменитым "do you guys not have phones?" от метелицы, выдав фразу "it turns out that you guys do have phones!"
В описании трансляции было "putting the 's' in games"
Вообще я в полном ахере, очень круто.
И очень вовремя, надо сказать, все крупные игроки, которые могли занять инфополе как раз отмываются от своих ошибок и не делают никаких громких заявлений.
и по возможности на каждый вид события один триггер
Пишешь ты такой систему движения на WASD (то бишь на касте абилок) и какие-нибудь абилки, и для всех нужно одно событие. Красиво будет выглядеть такая "оптимизация"? Легко ли поддерживать такой код?
Тут у тебя ещё замечание про 1000 потоков было, ты его удалил, но я замечу, что вар вообще однопоточный.
иначе при дальнейших модификациях карты будет получаться всё более жесткое месиво из кода
Карта с одной из самых сильных модификаций игрового процесса, которые я знаю (tcx aside), называвшаяся Combat Zone, имела в своём коде меньше тысячи строк просто потому что писал её скиловый программист. Месиво из кода всегда характеризует не столько платформу, сколько её пользователя (/разработчика на ней).
Ну и даже если у тебя 10к+ строк кода, этот код же можно нормально структурировать, а не тупо приписывать в Map Custom Script каждый раз внизу.
Ок, тогда я начинаю с нуля писать карту...чтоб эта моя абилка в одном триггере уместилась
Постепенно улучшать почти всегда лучше, чем снести и построить заново. Да и в чём проблема, что требуется больше одного триггера для чего-то? Триггер — почти самый лёгкий не-нативный объект в игре (второе место после таймера), нет смысла их экономить.
хотя, конечно, существуют особые извращённые техники, позволяющие делать на одном триггере всю карту, но на практике это всегда неоправданно
Не в разы, просто приходится осмотрительнее/аккуратнее обращаться с хранимыми данными, чтобы они не терялись и не путались.
Я думаю, может просто много оперативки жрать карта, где на каждую абилку куча проверок кучи юнитов. Но я не имею представления, как сильно это влияет, сколько обычно операций в секунду на карте и каких именно, сколько это памяти.
Не знаю как рефорджед будет себя вести, но сейчас варкрафт физически не может потреблять больше 2 Gb RAM. Можешь посмотреть вот эту карту, чтобы понять, вещи какого уровня возможно нормально реализовывать в редакторе.
Без глобальных сложнее, конечно))) Но по-моему, только тем, что можно запутаться, ибо слишком много проверок, но логика-то та же, а это главное)
Да, плюс-минус так и есть.
может, на луа перейду
Настоятельно советовал бы так и сделать при первой же возможности. LUA, в отличии от JASS2, используется далеко не только в проприетарном редакторе одной-единственной игры.
Главный вопрос, кстати тогда: это всё можно засунуть в один триггер? Удобнее, когда на одну абилку 1 триггер. В конструкторе триггеров не получилось. А на джассе? Если к тому же можно несколько событий в один триггер пихать.
Триггер в редакторе триггеров и реальный объект "триггер" в движке не имеют между собой ничего общего.
Можно написать вот так
integer i = 0
loop
CreateTrigger()
i = i + 1
exitwhen (i > 8000)
endloop
и создать 8000 триггеров в пять строк.
В редакторе "триггер" это компонент UI, отдельное поле для ввода текста в списке триггеров. В движке "триггер" это объект, связывающий между собой события, условия и действия, причём всего этого у него может быть неограничено много (или ограничено, но всё равно много; не проверял).
Если есть анимация у скилла, то можно пикать всех юнитов в атакованной зоне не сразу, как юнит нажал, а через время анимации, к примеру. И обмен от этого будет работать так же: типо я жму обмен и дальше включается триггер: если я пикнут такой-то абилкой,(всем пикнутым задаётся какое-то значение прямо перед нанесением урона), то работает обмен и я типо исчезаю и доджу абилку.
Пока это неактуально, как я понимаю, а когда станет актуально — ты и сам поймёшь, что не всё так просто =)
Так таймер должен запуститься, именно когда я нажал кнопку, а не когда я её могу нажать.
Это второй описанный таймер. Первый таймер это эдакий "надзиратель", всё что он делает — это говорит, кто может применить способность, а кто не может. Кстати, нужно чтобы этот таймер был только один на юнита или иметь дополнительную логику проверки таймингов, чтобы не получилось подобной ситуации:
Юнита атакуют, на секунду ему разрешается применить уклонение
Через пол-секунды его ещё раз атакуют, ещё секунда на применение
Ещё через пол-секунды истекает таймер с первой атаки и юниту запрещают применять уклонение, хотя из-за второй атаки у него должно быть ещё 0.5 секунды
Если юнит начал быть атакованным, то через 10 секунд после того, как его начали атаковать, всё ещё будет проверяться условие, что у атакованного есть абилка обмена?
"Юнит атакован" в контексте игры означает exactly то, что я написал в скобочках выше. Учитывая, что это событие, оно будет срабатывать периодически, каждый раз, когда какой-нибудь юнит начинает замахиваться для атаки другого юнита (спам приказа "отставить", например, приводит к тому, что получающий эти приказы юнит будет замахиваться условно неограниченное количество раз в секунду). Причём атаки каких-то из нейтралов не будут учитываться из-за того, что у них нет инициирующего игрока-владельца. Там нормально так подводных камней =(
Прямо с ходу в голову не пришло изящных решений насчёт триггера уклонения от абилок. Тебе придётся каждый раз чекать зону нанесения урона несколько раньше, чем фактически наносить в ней урон, чтобы для всех противников в ней переключить разрешающие применение флаги и дать игрокам время на отреагировать.
И да, здесь что, надо расписывать, что именно значит "юнит атакован"?
Игра знает о том, что значит "юнит атакован" получше нас, не переживай, это я просто воткнул пояснение зачем-то.
Я вообще буду потом сложнее делать, чтоб автоатаки не было, а был скилл у всех с кулдауном, который наносит урон ближайшему юниту в области перед применившим(это видимо через угол поворота юнита и косинус для Y и синус для X этого угла надо будет использовать).
DopaMine, ну да, это поведение и будет иметь место при описанной мной реализации. Нет флага "сейчас можно применить Каварими но Дзюцу"? Никто никуда не перемещается и ниоткуда не скрывается, триггер просто не сработает, так как условие заблокирует срабатывание.
если юнита бьют, он может нажать кнопку и заменит себя на бревно, исчезнет(hide), появится бревно, эффекты и звук, и через 1.5 секунды появится(unhide) в точке, которая указана, как цель заклинания. А если не бьют, то ничего не произоидёт. Так же эффект работает всего 1 секунду(то есть применять типо надо прям перед ударом)
Если это то, о чём идёт речь, то я бы делал так:
Создаётся триггер событие — юнит атакован (то есть был отдан приказ атаки с этим юнитом в качестве цели и он находится в пределах дальности атаки атакующего) условие — атакованный юнит имеет эту абилку действия — сохранить на юнита-цель флаг "сейчас можно применить Каварими но Дзюцу" (как я понимаю, это ты и делаешь в коде в посте), затем создать таймер и запустить его на функцию, в которой этот флаг поменяется на обратное значение/удалится (больше ничего).
Создаётся ещё один триггер событие — юнит применяет способность Каварими но Дзюцу условие — для применяющего юнита сохранён флаг "сейчас можно применить Каварими но Дзюцу" действия — скрыть кастера, создать таймер, сохранить на этот таймер кастера и целевые координаты применённой способности, затем запустить его с задержкой 1.5 секунды на функцию, в которой из таймера будут выгружены координаты с юнитом, юнит будет в них перемещён (кстати, перемещать ничто не мешает сразу, разницы в игре не будет, а данных меньше таскать/хранить) и раскрыть кастера.
local boolean check = true
...
call SaveBoolean(udg_hash,h,StringHash("check"),check) // variable value
В верхнем методе
local boolean check = LoadBoolean(udg_hash,h,StringHash("check")) // never used
...
call SaveBoolean(udg_hash,h,StringHash("check"), false) // exact value
В верхнем методе у тебя caster всегда null будет, если он вызывается только таймером, потому что GetSpellAbilityUnit() возвращает реакцию на событие, а оно к моменту вызова уже целую секунду как прошло.
DopaMine, вообще лично мне кажется хорошей практикой сначала описывать решаемую проблему безотносительно кода, и только потом приводить свои попытки и соображения.
Иными словами, опиши что должно происходить при применении юнитом абилки с целью-точкой? В чём механика способности заключается-то?
» WarCraft 3 / Бета версия Warcraft III Reforged 1.32
» Прочее / Отключаем обновления в Windows 10
» WarCraft 3 / Бета версия Warcraft III Reforged 1.32
» WarCraft 3 / Бета версия Warcraft III Reforged 1.32
» Clamp'ова кухня / Riot Games за один день рассказали о целой куче своих новых игр
» Clamp'ова кухня / Riot Games за один день рассказали о целой куче своих новых игр
В описании трансляции было "putting the 's' in games"
Вообще я в полном ахере, очень круто.
И очень вовремя, надо сказать, все крупные игроки, которые могли занять инфополе как раз отмываются от своих ошибок и не делают никаких громких заявлений.
» Лучший блог / Снова КМС по жиму лежа
» WarCraft 3 / Бета версия Warcraft III Reforged 1.32
» WarCraft 3 / Бета версия Warcraft III Reforged 1.32
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
Ред. Clamp
» WarCraft 3 / CreateTimer
Можно написать вот так
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
Ред. Clamp
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer
Ред. Clamp
» WarCraft 3 / CreateTimer
событие — юнит атакован (то есть был отдан приказ атаки с этим юнитом в качестве цели и он находится в пределах дальности атаки атакующего)
условие — атакованный юнит имеет эту абилку
действия — сохранить на юнита-цель флаг "сейчас можно применить Каварими но Дзюцу" (как я понимаю, это ты и делаешь в коде в посте), затем создать таймер и запустить его на функцию, в которой этот флаг поменяется на обратное значение/удалится (больше ничего).
событие — юнит применяет способность Каварими но Дзюцу
условие — для применяющего юнита сохранён флаг "сейчас можно применить Каварими но Дзюцу"
действия — скрыть кастера, создать таймер, сохранить на этот таймер кастера и целевые координаты применённой способности, затем запустить его с задержкой 1.5 секунды на функцию, в которой из таймера будут выгружены координаты с юнитом, юнит будет в них перемещён (кстати, перемещать ничто не мешает сразу, разницы в игре не будет, а данных меньше таскать/хранить) и раскрыть кастера.
Ред. Clamp
» WarCraft 3 / CreateTimer
» WarCraft 3 / CreateTimer