как играть со скриптами
как вообще побеждать против грамотного минёра со скриптами?
27 Oct 2019 в 15:45
27 Oct 2019 в 15:45 #1
Против самого героя абсолютного ничего не имею НО если у него есть скрипты и он умеет играть то как его победить
спушить вообще невозможно потому что толкает форсом и взрывает нужное колиество мин
даже скрипты на скаймага не дают такого преимущества как читы на этого шахида
27 Oct 2019 в 15:46 #2
скрипт отменет покупку вардов и заставляет тебя на мины идти?
27 Oct 2019 в 15:50 #3
Как и не скриптованного,берешь кора силовика,собираешся в статы+пайп и ыкаешь на минера,который пытается засрать 40 бочек на 1 точке
27 Oct 2019 в 15:51 #4
Кто вам в голову вбил скрипты? Я как на питуха катаю, каждую 3-ю катку на нем мне говорят, что у меня якобы скрипты. Серьезно, нажать 4 кнопки надо иметь много навыков? Кто вам это в голову вбивает? Стримеры что-ли или ютуберы. Не сами же вы это рожаете.
27 Oct 2019 в 15:51 #5
Я даже против того морфа который в радиусе экрана кидал бревна на 500 урона с кд 1 клик мышки побеждал. Рики контрит, клоун даже не видит твоих перемещений. Контролить всю игру, убивать по кд и он изи слит
В основном они играют как фул отбросы так что выиграть не составит труда
27 Oct 2019 в 15:52 #6
скрипт отменет покупку вардов и заставляет тебя на мины идти?
у него скрипт на автоюз форсика
плюс он может загадить абсолютно любую точку на карте и даже без статик трапы будет сразу тебя на неё подрывать
Я даже против того морфа который в радиусе экрана кидал бревна на 500 урона с кд в виде 1 клика мышки побеждал. Рики контрит, клоун даже не видит твоих перемещений. Контролить всю игру и он изи слит
27 Oct 2019 в 15:53 #7
Есть только один способ: Дико засноуболить, выиграть все 3 лайна и снести за 20. Сча тебе будут затирать про Варды, гем и т.д. Просто эти люди не играли против сильного минера, который возможности скриптов на максимум использует. Против него не поможет ни тараски, ни пайп, ни бкб с рефрешем. Ничо не поможет )
27 Oct 2019 в 15:53 #8
у него скрипт на автоюз форсика
плюс он может загадить абсолютно любую точку на карте и даже без статик трапы будет сразу тебя на неё подрывать
? Бегаешь и сносишь мины, в мид гейме покупаешь гем и сносишь мины с 2 силой. В файте у вас 4.5 героя за счет тучи с 0 кд а у врагов 4 ибо мин не будет никогда
Дифуз еул и всегда 2 сентри при себе, на очевидные места расставляешь и фармишь мины
Есть только один способ: Дико засноуболить, выиграть все 3 лайна и снести за 20. Сча тебе будут затирать про Варды, гем и т.д. Просто эти люди не играли против сильного минера, который возможности скриптов на максимум использует. Против него не поможет ни тараски, ни пайп, ни бкб с рефрешем. Ничо не поможет )
Обычно хватает засноуболить только лайн с минером скриптером, эти раки не часто в игру раньше 40 минуты возвращаются
Вам интересно играть со скриптами?
15 Feb 2016 в 18:31
15 Feb 2016 в 18:31 #1
Вот особенно Инвокеры, которые всех обсирают, что мол «ты помойка, не умеешь играть» а ведь большинство из них сами то не умеют играть, а сделав скрипты и дурак сможет. это те же читы(как для меня) всё равно, что вх в кс. вам вот самим то интересно со скриптами играть?
15 Feb 2016 в 18:32 #2
15 Feb 2016 в 18:34 #3
Да очень интересно с ними играть всегда переживает дадут бан или нет эх столько адреналина
15 Feb 2016 в 18:34 #4
Ну вообще да, можешь не отвлекаясь на всякую чушь тренить отдельные части игры вроде добивания крепов
15 Feb 2016 в 18:35 #5
15 Feb 2016 в 18:35 #6
15 Feb 2016 в 18:37 #7
А на инвокера есть полезные скрипты? :hmm:
15 Feb 2016 в 18:38 #8
в чем проблема? используй тоже, если думаешь, что это нечестно по отношению к тебе. а беспричинно подгорать на форуме каждый может. сходил бы уже и попробовал.
15 Feb 2016 в 18:40 #9
ну я вот не такой человек. если увижу кого-то с читом-не буду же их сам качать. ведь кому то станет так же не приятно как и мне
15 Feb 2016 в 18:42 #10
Ответ простой. Чтобы тащить на вокере, надо сыграть игр 100.
Если юзать скрипты, то хватит и игр 10-15 чтобы наваливать.
PS на вокере не играю.
15 Feb 2016 в 18:43 #11
15 Feb 2016 в 18:44 #12
ну, сам смотри. просто, орать, что это обоссаное занятие, при этом даже ни разу не сыграв со скриптами, это как-то странно.
дело ваше, ни в коем случае не защищаю любителей облегчить себе жизнь, но и не осуждаю :vic:
15 Feb 2016 в 18:46 #13
За скрипты бын не дают, лёл
15 Feb 2016 в 18:47 #14
15 Feb 2016 в 18:53 #15
Чего плохого в скриптах?) Вместо 4 кнопок жать 1.
15 Feb 2016 в 18:55 #16
На Иннокентия каличные скрипты, лучше руками все прожимать. Интересный вроде скрипт для Черного. Но я ещё не тестил.
15 Feb 2016 в 18:57 #17
15 Feb 2016 в 19:02 #18
скрипты не чит
если немного подумать, можно понять разницу между скриптом и валлхаком
15 Feb 2016 в 19:16 #19
Только скрипты это не чит и за него не банят. Читы это когда чел настоящего среди иллюзий бьет. А естли ты не используешь разрешенную возможность игры то жто твои проблемы. Тоже самое еслибы боксер закинул одну руку за спину, а потом бы жаловался что его соперник не сделал также
15 Feb 2016 в 19:29 #20
то есть если бы твой соперник играл с читом-ты бы тоже скачал?
Screeps — игра для программистов: управляйте виртуальным миром с помощью JavaScript
В магазине игр Steam появился новый интересный представитель из жанра «песочница» — Screeps. Механика игры заключается в управлении колонией посредством программирования AI юнитов на JavaScript. Кстати, мы уже писали о программировании нейронной сети на JS.
Вот такой трейлер игры можно найти в Steam:
Поиграть в Screeps можно прямо из браузера, но в реальном (не тренировочном) игровом мире, видимо, все равно придется платить за использование вычислительных мощностей, чтобы ваши скрипты могли исполняться.
В целом Screeps — это традиционная стратегия, в которой целью игры является наращивание влияния в игровом мире.
К слову, игровой мир там общий: нет никаких отдельных серверов, колония игрока управляется написанным им кодом 24/7 в едином мире с колониями других пользователей. На момент написания материала игра опубликована со статусом «в раннем доступе», и разработчики как раз продолжают работу над возможностью играть в локальном мире или на выделенном сервере по сети с друзьями. Выпуск окончательной версии и сервера с открытым исходным кодом намечен на июль-август 2016 года.
Что касается рабочей среды: код можно писать как во встроенном редакторе, так и в любом другом — в частности, в удобной вам IDE.
Механика игры порождает интересный эффект: игроку не нужно принимать непосредственное участие в управлении своей колонией — достаточно заходить время от времени, чтобы проверить, что все идет как надо.
Базовые навыки уже должны программирования иметься у игроков. Создатели утверждают, что игра не обучает программированию, а позволяет продемонстрировать свое мастерство. Правда, возможность подключения дополнительных библиотек нигде не упомянута, так что вас может неприятно удивить тот факт, что jQuery — это не то же самое, что JavaScript.
По заверению пользователей, игра очень мотивирует писать код, вы только взгляните на активность в репозитории игрока BonzaiFerroni:
Сейчас на счету игры в Steam много отзывов, причем на момент написания материала только положительных. Хотя у автора статьи возникла проблема со входом и через GitHub, и через Steam. Если будете пробовать войти первым способом, обязательно указывайте свой e-mail, иначе на следующем шаге вам не будет прислано письмо для подтверждения регистрации и игра зависнет в ожидании.
Хинт для программистов: если зарегистрируетесь на соревнования Huawei Cup, то бесплатно получите доступ к онлайн-школе для участников. Можно прокачаться по разным навыкам и выиграть призы в самом соревновании.
Перейти к регистрации
Что такое скрипты и с чем их едят — Lua & C++
Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов
Что нужно знать?
Но есть способ, на голову выше — использование скриптов.
Решение проблемы
«Окей, для таких дел хватает обычного файла с описанием характеристиков игрока. Но что делать, если в бурно развивающемся проекте почти каждый день приходится немножко изменять логику главного игрока, и, следовательно, много раз компилировать проект?»
Хороший вопрос. В этом случае нам на помощь приходят скрипты, держащие именно логику игрока со всеми характеристиками либо какой-либо другой части игры.
Естественно, удобнее всего держать, логику игрока в виде кода какого-нибудь языка программирования.
Первая мысль — написать свой интерпретатор своего скриптового языка, выкидывается из мозга через несколько секунд. Логика игрока определенно не стоит таких жутких затрат.
К счастью, есть специальные библиотеки скриптовых языков для С++, которые принимают на вход текстовый файл и выполняют его.
Об одном таком скриптовом языке Lua пойдет речь.
Как это работает?
Прежде чем начать, важно понимать, как работает скриптовый язык. Дело в том, что в скриптовых языках есть очень мало функций, при наличии конструкций for, while, if, прочих.
В основном это функции вывода текста в консоль, математические функции и функции для работы с файлами.
Как же тогда можно управлять игроком через скрипты?
Мы в С++-программе делаем какие-либо функции, «регистрируем» их под каким-нибудь именем в скрипте и вызываем в скрипте. То есть если мы зарегистрировали функцию SetPos(x,y) для определения позиции игрока в С++-программе, то, встретив эту функцию в скрипте, «интерпретатор» из библиотеки скриптового языка вызывает эту функцию в С++-программе, естественно, с передачей всех методов.
Удивительно, да? 🙂
UPD: Внимание! Один юзер обратился мне с мейлом, что, когда я заливал код, я не полностью устранил все ошибки — habrahabr.ru/post/196272/#comment_6850016
В коде с позволения хабра проникли жучки
Замените участки кода вроде
И еще вместо lua_CFunction проскакивает lua_cfunction
Спасибо!
Я готов!
Когда вы поняли преимущества скриптовых языков программирования, самое время начать работать!
Скачайте из репозитория на гитхабе (низ топика) lib’у и includ’ы Lua, либо возмите их на официальном сайте.
Создаем консольный проект либо Win32 (это неважно) в Visual Studio (у меня стоит версия 2012)
Заходим в Проект->Свойства->Свойства конфигурации->Каталоги VC++ и в «каталоги включения» и «каталоги библиотек» добавьте папку Include и Lib из репозитория соответственно.
Теперь создаем файл main.cpp, пишем в нем:
Как вы догадались, у меня консольное приложение.
Теперь переходим к кодингу
Обещаю, что буду тщательно объяснять каждый момент
У нас за скрипты будет отвечать класс Script. Я буду объявлять и одновременно реализовывать функции в Script.h/.cpp
Создаем Script.cpp и пишем в нем
Создаем Script.h и пишем в нем
После 2 строчки и перед #endif мы определяем класс скриптов
Этот код пишется для предотвращения взаимного включения файлов. Допустим, что файл Game.h подключает Script.h, а Script.h подключает Game.h — непорядок! А с таким кодом включение выполняется только 1 раз
Теперь пишем внутри этого кода вот это
Первая строчка подключает сам lua.lib из архива.
Для чего нужен extern «C»? Дело в том, что lua написан на С и поэтому такой код необходим для подключения библиотек.
Дальше идет подключение хорошо известных многим файлов для работы с консолью
Теперь приступим к определению класса
Самый главный объект библиотеки Lua для C++ — lua_State, он необходим для выполнения скриптов
Дальше идут публичные функции
Эта функция инициализирует lua_State
Его определение в Script.cpp
Первой строчкой мы инициализируем наш lua_State.
Потом мы объявляем список «подключенных библиотек». Дело в том, что в «чистом» виде в луа есть только функция print(). Для математических и прочих функций требуется подключать специальные библиотеки и потом вызывать их как math.foo, base.foo, io.foo. Для подключения других библиотек добавьте в lualibs, например, <«math», luaopen_math>. Все названия библиотек начинаются с luaopen_. в конце lialibs должен стоять
Просто используем lua_close()
А эта функция выполняет файл. На вход она принимает название файла, например, «C:\\script.lua».
Почему она возвращает int? Просто некоторые скрипты могут содержать return, прерывая работу скрипта и возвращая какое-нибудь значение.
Как вы видите, я выполняю скрипт и возвращаю int. Но возращать функция может не только int, но еще и bool и char*, просто я всегда возвращаю числа (lua_toboolean, lua_tostring)
Теперь мы сделаем функцию, регистрирующую константы (числа, строки, функции)
Мы действуем через шаблоны. Пример вызова функции:
Ее определение
Для каждого возможного значения class T мы определяем свои действия.
*Капитан* последнее определение — регистрация функции
Функции, годные для регистрации, выглядят так:
Где n — количество возвращаемых значений. Если n = 2, то в Луа можно сделать так:
Читайте мануалы по Луа, если были удивлены тем, что одна функция возвращает несколько значений 🙂
Следующая функция создает таблицу для Луа. Если непонятно, что это значит, то тамошная таблица все равно что массив
Следующая функция регистрирует элемент в таблице.
Если вы не знаете Lua, вы, наверное, удивлены тем, что в один массив помещается столько типов? 🙂
На самом деле в элементе таблицы может содержаться еще и таблица, я так никогда не делаю.
Наконец, заполненную таблицу нужно зарегистрировать
Ничего особенного нет
Следующие функции предназначены в основном только для функций типа int foo(lua_State*), которые нужны для регистрации в Луа.
Первая из них — получает количество аргументов
Эта функция нужна, например, для функции Write(), куда можно запихать сколь угодно аргументов, а можно и ни одного
Подобную функцию мы реализуем позже
Следующая функция получает аргумент, переданный функции в скрипте
Можно получить все типы, описывавшиеся ранее, кроме таблиц и функций
index — это номер аргумента. И первый аргумент начинается с 1.
Наконец, последняя функция, которая возвращает значение в скрипт
Боевой код
Пора что-нибудь сделать!
Изменяем main.cpp
Компилируем. Теперь можно приступить к тестированию нашего класса
Помните, я обещал сделать функцию Write? 🙂
Видоизменяем main.cpp
А в папке с проектом создаем файл script.lua
Компилируем и запускаем проект.
Теперь изменяем script.lua
Теперь программа будет выводить по 2 строки («\n» — создание новой строки), ждать нажатия Enter и снова выводить строки.
Экспериментируйте со скриптами!
Вот пример main.cpp с функциями и пример script.lua
Полезные советы
Вопросы и ответы
Методы организации взаимодействия между скриптами в Unity3D
Вступление
Подход 1. Назначение через редактор Unity3D
Пусть у нас в проекте есть два скрипта. Первый скрип отвечает за начисление очков в игре, а второй за пользовательский интерфейс, который, отображает количество набранных очков на экране игры.
Назовем оба скрипта менеджерами: ScoresManager и HUDManager.
Каким же образом менеджеру, отвечающему за меню экрана можно получить текущее количество очков от менеджера, отвечающего за начисление очков?
Предполагается, что в иерархии объектов(Hierarchy) сцены существуют два объекта, на один из которых назначен скрипт ScoresManager, а на другой скрипт HUDManager.
Один из подходов, содержит следующий принцип:
В скрипте UIManager определяем переменную типа ScoresManager:
Но переменную ScoresManager необходимо еще инициализировать экземпляром класса. Для этого выберем в иерархии объектов объект, на который назначен скрипт HUDManager и в настройках объекта увидим переменную ScoresManager со значением None.
Далее, из окна иерархии перетаскиваем объект, содержащий скрипт ScoresManager в область, где написано None и назначаем его объявленной переменной:
После чего, у нас появляется возможность из кода HUDManager обращаться к скрипту ScoresManager, таким образом:
Все просто, но игра, не ограничивается одними набранными очками, HUD может отображать текущие жизни игрока, меню доступных действия игрока, информацию о уровне и многое другое. Игра может насчитывать в себе десятки и сотни различных скриптов, которым нужно получать информацию друг от друга.
Чтобы получить в одном скрипте данные из другого скрипта нам каждый раз придется описывать переменную в одном скрипте и назначать (перетаскивать вручную) ее с помощью редактора, что само по себе нудная работа, которую легко можно забыть сделать и потом долго искать какая из переменных не инициализирована.
Если мы захотим что-то отрефакторить, переименовать скрипт, то все старые инициализации в иерархии объектов, связанные с переименованным скриптом, сбросятся и придется их назначать снова.
В то же время, такой механизм не работает для префабов (prefab) — динамического создания объектов из шаблона. Если какому-либо префабу нужно обращаться к менеджеру, расположенному в иерархии объектов, то вы не сможете назначить самому префабу элемент из иерархии, а придется сначала создать объект из префаба и после этого программно присвоить экземпляр менеджера переменной только что созданного объекта. Не нужная работа, не нужный код, дополнительная связанность.
Следующий подход решает все эти проблемы.
Подход 2. «Синглтоны»
Применим упрощенную классификацию возможных скриптов, которые используются при создании игры. Первый тип скриптов: «скрипты-менеджеры», второй: «скрипты-игровые-объекты».
Основное отличие одних от других в том, что «скрипты-менеджеры» всегда имеют единственный экземпляр в игре, в то время как «скрипты-игровые-объекты» могут иметь количество экземпляров больше единицы.
Примеры
Как правило, в единственном экземпляре существуют скрипты, отвечающие за общую логику пользовательского интерфейса, за проигрывание музыки, за отслеживание условий завершения уровня, за управление системой заданий, за отображение спецэффектов и так далее.
В то же время, скрипты игровых объектов существуют в большом количестве экземпляров: каждая птичка из «Angry Birds» управляется экземпляром скрипта птички со своим уникальным состоянием; для любого юнита в стратегии создается экземпляр скрипта юнита, содержащий его текущее количество жизней, позицию на поле и личную цель; поведение пяти разных иконок обеспечивается различными экземплярами одних и тех же скриптов, отвечающих за это поведение.
В примере из предыдущего шага скрипты HUDManager и ScoresManager всегда существуют в единственном экземпляре. Для их взаимодействия друг с другом применим паттерн «синглтон» (Singleton, он же одиночка).
В классе ScoresManager опишем статическое свойство типа ScoresManager, в котором будет храниться единственный экземпляр менеджера очков:
Осталось инициализировать свойство Instance экземпляром класса, который создает среда Unity3D. Так как ScoresManager наследник MonoBehaviour, то он участвует в жизненном цикле всех активных скриптов в сцене и во время инициализации скрипта у него вызывается метод Awake. В этот метод мы и поместить код инициализации свойства Instance:
После чего, использовать ScoresManager из других скриптов можно следующим образом:
Теперь нет необходимости в HUDManager описывать поле типа ScoresManager и назначать его в редакторе Unity3D, любой «скрипт-менеджер» может предоставлять доступ к себе через статическое свойство Instance, которое будет инициализировать в функции Awake.
Плюсы
— нет необходимости описывать поле скрипта и назначать его через редактор Unity3D.
— можно смело рефакторить код, если что и отвалится, то компилятор даст знать.
— к другим «скриптам-менеджерам» теперь можно обращаться из префабов, через свойство Instance.
Минусы
— подход обеспечивает доступ только к «скриптам-менеджерам», существующим в единственном экземпляре.
— сильная связанность.
На последнем «минусе» остановимся подробнее.
Пусть мы разрабатываем игру, в которой есть персонажи (unit) и эти персонажи могут погибать (die).
Где-то находится участок кода, который проверяет не погиб ли наш персонаж:
Получается, что персонаж после совей смерти должен разослать всем компонентам, которые в ней заинтересованы этот печальный факт, он должен знать о существовании этих компонентов и должен знать, что они им интересуются. Не слишком ли много знаний, для маленького юнита?
Так как игра, по логике, очень связанная структура, то и события происходящие в других компонентах интересуют третьи, юнит тут ничем не особенный.
Примеры таких событий (далеко не все):
— Условие прохождение уровня зависит от количества набранных очков, набрали 1000 очков – прошли уровень (LevelConditionManager связан с ScoresManager).
— Когда набираем 500 очков, достигаем важную стадию прохождения уровня, нужно проиграть веселую мелодию и визуальный эффект (ScoresManager связан с EffectsManager и SoundsManager).
— Когда персонаж восстанавливает здоровье, нужно проиграть эффект лечения над картинкой персонажа в панели персонажа (UnitsPanel связан с EffectsManager).
— и так далее.
В результате таких связей мы приходим к картине похожей на следующую, где все про всех все знают:
Пример со смертью персонажа немного преувеличен, сообщать о смерти (или другом событии) шести разным компонентам не так часто приходится. Но варианты, когда при каком-то событии в игре, функция, в которой произошло событие, сообщает об этом 2-3 другим компонентам встречается сплошь и рядом по всему коду.
Следующий подход пытается решает эту проблему.
Подход 3. Мировой эфир (Event Aggregator)
Введем специальный компонент «EventAggregator», основная функция которого хранить список событий, происходящих в игре.
Событие в игре — это функционал, предоставляющий любому другому компоненту возможность как подписаться на себя, так и опубликовать факт совершения этого события. Реализация функционала события может быть любой на вкус разработчика, можно использовать стандартные решения языка или написать свою реализацию.
Пример простой реализации события из прошлого примера (о смерти юнита):
Добавляем это событие в «EventAggregator»:
Теперь, функция Die из предыдущего примера с восемью строчками преобразуется в функцию с одной строчкой кода. Нам нет необходимости сообщать о том, что юнит умер всем заинтересованным компонентам и знать о этих заинтересованных. Мы просто публикуем факт свершения события:
А любой компонент, которому интересно это событие, может отреагировать на него следующим образом (на примере менеджера отвечающего за количество набранных очков):
В функции Awake менеджер подписывается на событие и передает делегат, отвечающий за обработку этого события. Сам же обработчик события, принимает в качестве параметра экземпляр умершего юнита и добавляет количество очков в зависимости от типа этого юнита.
Таким же образом, все другие компоненты, кому интересно событие смерти юнита, могут подписаться на него и обработать, когда событие произойдет.
В результате, диаграмма связей между компонентами, когда каждая компонента знала друг о друге, превращается в диаграмму, когда компоненты знают только о событиях, которые происходят в игре (только о интересующих их событиях), но им все равно, от куда эти события пришли. Новая диаграмма будет выглядеть следующим образом:
Замечание
Говоря, что никакой другой код не меняется, я конечно немножко лукавлю. Может оказаться так, что систему достижений интересуют события, которые ранее просто не публиковались в игре, потому как ни одну другую систему до этого не интересовали. И в этом случае, нам нужно будет решить какие новые события добавить в игру и кто будет их публиковать. Но в идеальной игре уже все возможные события есть и эфир наполнен ими по полной.
Плюсы
— не связанность компонентов, мне достаточно просто опубликовать событие, а кого оно интересует не имеет значение.
— не связанность компонентов, я просто подписываюсь на нужные мне события.
— можно добавлять отдельные модули без изменения в существующем функционале.
Минусы
— нужно постоянно описывать новые события и добавлять их в мир.
— нарушение функциональной атомарности.
Последний минус рассмотрим более детально
Представим, что у нас есть объект «ObjectA», в котором вызывается метод «MethodA». Метод «MethodA», состоит из трех шагов и вызывает внутри себя три других метода, которые выполняют эти шаги последовательно («MethodA1», «MethodA2» и «MethodA3»). Во втором методе «MethodA2» происходит публикация какого-то события. И тут происходит следующее: все кто подписан на это событие начнут его обрабатывать, выполняя какую-то свою логику. В этой логике тоже может произойти публикация других событий, обработка которых также может привести к публикации новых событий и так далее. Дерево публикаций и реакции в отдельных случаях может очень сильно разрастись. Такие длинные цепочки крайне тяжело отлаживать.
Но самая страшная проблема, которая тут может произойти, это когда одна из веток цепочки приводит обратно в «ObjectA» и начинает обрабатывать событие путем вызова какого-то другого метода «MethodB». Получается, что метод «MethodA» у нас еще не выполнил все шаги, так как был прерван на втором шаге, и содержит сейчас в себе не валидное состояние (в шаге 1 и 2 мы изменили состояние объекта, но последнее изменение из шага 3 еще не сделали) и при этом начинается выполняться «MethodB» в этом же объекте, имея это не валидное состояние. Такие ситуации порождают ошибки, очень сложно отлавливаются, приводят к тому, что надо контролировать порядок вызова методов и публикации событий, когда по логике этого делать нет необходимости и вводят дополнительную сложность, которую хотелось бы избежать.
Решение
Решить описанную проблему не сложно, достаточно добавить функционал отложенной реакции на событие. В качестве простой реализации такого функционала мы можем завести хранилище, в которое будем складывать произошедшие события. Когда событие произошло, мы не выполняем его немедленно, а просто сохраняем где-то у себя. И в момент наступления очереди выполнения функционала какой-то компоненты в игре (в методе Update, например) мы проверяем на наличие произошедших событий и выполняем обработку, если есть такие события.
Таким образом, при выполнении метода «MethodA» не происходит его прерывание, а опубликованное событие все заинтересованные записывают себе в специальное хранилище. И только после того как к заинтересованным подписчикам дойдет очередь, они достанут из хранилища событие и обработают его. В этот момент весь «MethodA» будет завершен и «ObjectA» будет иметь валидное состояние.