Что такое extended backtracking

Что такое бэктрекинг в играх?

Многие начинающие геймеры (возраст значения не имеет), не слишком знакомые с англоязычными терминами в индустрии, задаются вопросом: что такое бэктрекинг в играх? Это слово встречается во многих обзорах, причём обязательно в негативном ключе.

И действительно, сам термин носит отрицательный эмоциональный окрас. Речь о возвращении на предыдущие локации с целью выполнения обновлённых заданий, когда ключевые персонажи и объекты располагаются в старых местах.

Яркий пример, ставший каноничным – Dragon Age 2. В ней мы получали обширные городские локации, где герою и его компании приходилось выполнять бесконечные квесты. Увы, ничего кроме города здесь нет, приходилось многократно возвращаться в старые места, выполняя там новые миссии.

Аналогичным образом были реализованы и местные лабиринты-подземелья. Ситуация доходила до абсурда, поскольку в уже изученных казематах внезапно появлялись комнаты и двери, прежде отсутствовавшие.

Бэктрекинг в играх – это злободневная проблема

Выучив окружение впервые, геймер вряд ли испытает желание изучать закоулки второй, третий, десятый раз, не получая при этом каких-то уникальных ощущений. Проблема характерна не только для низкобюджетных AAA-поделок, но и для разработок от крупных корпораций, которые стремятся сократить временные затраты до минимума. Каждое архитектурное сооружение – плод кропотливого труда, порой растягивающегося на недели и месяцы…

Иногда искусственно растягивается общая продолжительность. В Persona 5 ближе к финалу, когда к главной битве достаточно протянуть руку, открываются побочные задания, не несущие смысловой нагрузки. А потом – ещё немного, и ещё… И так на добрые 10-15 часов, что изрядно раздражает людей, желающих побыстрее узнать, чем же закончится основная история.

В школьные годы, когда времени уйма и стремишься продлить удовольствие от процесса как можно дольше, вопросов у игрока обычно не возникает. Позднее краткость становится родной сестрой таланта авторов, ведь время – единственный ресурс, который не возобновляется никогда.

Как вы воспринимаете бэктрекинг в видеоиграх? Напишите в комментариях.

Источник

Русские Блоги

Введение в алгоритмы Backtracking

1. Концепция

Алгоритм обратного отслеживания на самом деле представляет собой процесс попытки поиска, аналогичный перечислению, который в основном предназначен для поиска решения проблемы во время попытки поиска. Когда обнаруживается, что условие решения не выполняется, он «возвращается» и возвращается, чтобы попробовать другой путь.

Многие сложные и масштабные проблемы могут использовать ретроспективный метод, который известен как «общий метод решения проблем».

2. Основные идеи

В дереве решений пространство, содержащее все решения задачи, согласноСтратегия поиска в глубинуНачиная с корневого узла, детально исследуйте дерево пространства решений. Когда исследуется определенный узел, необходимо сначала определить, содержит ли узел решение проблемы. Если это так, продолжить исследование с этого узла. Если узел не содержит решения проблемы, то шаг за шагом к его предкам Узел возврата. (Фактически, метод обратного отслеживания является алгоритмом поиска в глубину для неявных графов).

Если вы используете метод обратного отслеживания, чтобы найти все решения проблемы, вам необходимо вернуться к корню, и все возможные поддеревья корневого узла должны быть найдены до конца.

Если вы используете метод обратного отслеживания, чтобы найти какое-либо решение, вы можете закончить, если найдете одно решение проблемы.

3. Общие шаги по решению проблем с методом обратного отслеживания:

(1) Для данной задачи определите пространство решения задачи:

Прежде всего, пространство решения задачи должно быть четко определено, пространство решения задачи должно содержать хотя бы одно (оптимальное) решение задачи.

(2) Определить расширенные правила поиска для узлов

(3) Поиск в пространстве решений в глубину и использование функции сокращения, чтобы избежать неправильных поисков во время поиска.

4. Алгоритм каркаса

(1) Структура проблемы

(2) нерекурсивный каркас возврата

(3) Рекурсивный алгоритм

Источник

Бэктрекинг в играх – что это?

Если Вы смотрите обзоры новых компьютерных игр, то могли столкнуться с термином «бэктрекинг». Но что это такое, говоря простыми словами?

Бэктрекинг (поиск с возвратом) – это общий метод нахождения решений задачи, в которой требуется полный перебор всех возможных вариантов в некотором множестве. Данный термин был введёт в 1950 году, но уже значительно позже он стал употребляться и в отношении игр.

Бэктрекинг в играх, говоря простыми словами – это возврат в предыдущие локации с целью выполнения новых заданий. Получается, что игрок вынужден идти в локации, которые он уже прошёл, чтобы выполнить какое-то новое задание. Если разработчик злоупотребляет бэктрекингом, то это вызывает у игроков неприятные ощущения – вместо чего-то действительно нового им приходится бегать по уже знакомым местам, сражаться с противниками, которых они уже убивали.

Реализация бэктрекинга может быть разная. Вот несколько примеров:

Одна из последних игр, в которой имеется бэктрекинг – «ЗВЁЗДНЫЕ ВОЙНЫ Джедаи — Павший Орден™». Вы проходите часть планеты, летите на другую, затем – опять на первую, потом – на третью, четвертую, опять на вторую, затем – третью и так далее. Сама по себе игра довольно хороша, но бэктрекинг в ней действительно очень сильно раздражает.

Зачем так делают разработчики? Дело в том, что многие люди не любят короткие игры, прохождение которых занимает 4-5 часов. Заплатив несколько тысяч рублей, игру можно легко пройти за один вечер или выходной день. Куда выше ценятся игры с прохождением более 20 часов, например, 30-50. Это если мы говорим об одиночных играх (Singleplayer). Многие разработчики, желая сделать длинную игру, но не желая делать новые локации, прибегают к бэктрекингу, чтобы искусственно растянуть игру.

Источник

Еще раз о регекспах, бэктрекинге и том, как можно положить на лопатки JVM двумя строками «безобидного» кода

Раннее утро, десятая чашка кофе, безуспешные попытки понять почему ваше клиентское (или еще хуже – серверное) java-приложение намертво зависло при вычислении простого регекспа на небольшой строке… Если подобная ситуация уже возникала в вашей жизни, вы уже наверняка знаете про бэктрекинг и темную сторону регулярных выражений. Остальным – добро пожаловать под кат!

Бэктрекинг, или вечное ожидание результата

Проблема бэктрекинга при матчинге регулярных выражений уже неоднократно поднималась в различных статьях на хабре (раз, два, три), поэтому опишем ее суть без погружения в детали. Рассмотрим простой синтетический пример – типичный экземпляр из так называемых «evil regexes» (аналог изначально представлен тут):

Если запустить код на JDK8 (почему на более актуальных версиях воспроизводиться не будет – опишем далее), то JVM будет очень долго вычислять результат работы метода matches(). Едва ли вам удастся его дождаться, не состарившись на несколько месяцев или даже лет.

Что же пошло не так? Стандартная реализация Pattern/Matcher из пакета java.util.regex будет искать решение из теста следующим образом:

Произведем откат (backtrack) к начальному состоянию. Мы попытались захватить максимальную группу из нулей и нас ждал провал; давайте теперь возьмём на один нолик меньше. Тогда группа (0) захватит все нули без одного, снаружи группы укажет на наличие единственной группы, а оставшийся ноль не равен единице. Снова провал.

Снова откатываемся к начальному состоянию и забираем группой (0) все нули без двух последних. Но ведь оставшиеся два нуля тоже могут заматчиться группой (0)! И теперь эта группа тоже попытается сначала захватить два нуля, после чего попытается взять один ноль, и после этого произойдет откат и попытка матчинга строки уже без трех нулей.

Легко догадаться, что по мере уменьшения «начальной» жадной группы будет появляться множество вариаций соседних групп (0), которые также придется откатывать и проверять все большее количество комбинаций. Сложность будет расти экспоненциально; при наличии достаточного количества нулей в строке – прямо как в нашем примере – возникнет так называемый катастрофический бэктрекинг, который и приведет к печальным последствиям.

Представленная тестовая строка имеет длину 80 символов и сгенерирована случайным образом. Она не заставит JVM на JDK8+ работать вечно – всего лишь около 30 минут – но этого уже достаточно, чтобы нанести вашему приложению существенный вред. В случае разработки серверных приложений риск многократно увеличивается из-за возможности проведения ReDoS-атак. Причиной же подобного поведения, как и в первом примере, является бэктрекинг, а именно – сочетание квантификаторов «+» внутри группы и «<1,10>« – снаружи.

Война с бэктрекингом или с разработчиками Java SDK?

Чем запутаннее паттерн, тем сложнее для неопытного человека увидеть проблемы в регулярном выражении. Причем речь сейчас идет вовсе не о внешних пользователях, использующих ваше ПО, а о разработчиках. Так, с конца нулевых было создано значительное количество тикетов с жалобой на бесконечно работающий матчинг. Несколько примеров: JDK-5026912, JDK-7006761, JDK-8139263. Реже можно встретить жалобы на StackOverflowError, который тоже типичен при проведении матчинга (JDK-5050507). Все подобные баги закрывались с одними и теми же формулировками: «неэффективный регексп», «катастрофический бектрекинг», «не является багом».

Доработки алгоритма действительно происходили. Так, в JDK9 реализовано следующее улучшение: каждый раз, когда применяется жадный квантификатор, не соответствующий данным для проверки, выставляется курсор, указывающий на позицию в проверяемом выражении. При повторной проверке после отката достаточно убедиться, что если для текущей позиции проверка уже была провалена, продолжение текущего подхода лишено смысла и проводиться не будет (JDK-6328855, пояснение). Это позволило исключить бесконечный матчинг в тесте testRegexJDK8Only() начиная с версии jdk9-b119, однако второй тест вызывает задержки вне зависимости от версии JDK. Более того, при наличии обратных ссылок в регулярных выражениях оптимизация не используется.

Опасный враг: внешнее управление

Публикации, упомянутые в самом начале статьи, отлично раскрывают варианты оптимизации регулярных выражений, в результате чего катастрофический бектрекинг перестает быть опасным врагом; для сложных случаев потребуется дополнительная экспертиза, но в целом регулярное выражение можно почти всегда записать «безопасным» образом. Да и проверить себя тоже можно, например, на npmjs.com. Проблема остается при составлении очень сложных регулярок, а также в тех сценариях, когда регулярное выражение задается не программистом, а аналитиком, заказчиком после передачи решения, или же пользователем. В последнем случае управление сложностью регулярного выражения оказывается снаружи – и вам придется позаботиться о том, чтобы при любых условиях приложение продолжало корректную работу.

В конце января 2021 года был опубликован драфт JEP-а, в котором предлагается создать движок для регулярных выражений с матчингом за линейное время, и одним из основных подходов в реализации является именно RE2.

Может показаться, что переход на RE2/J – отличный выбор практически для каждого проекта. Какова цена линейного времени выполнения?

У RE2/J отсутствует ряд методов API у Matcher;

Синтаксис регулярных выражений совпадает не полностью (у RE2/J отсутствует часть конструкций, в том числе – обратные ссылки, backreferences). Вполне вероятно, после замены импорта ваша регулярка перестанет корректно распознаваться;

Несмотря на то, что формально код принадлежит Google, библиотека не является официальной, а основным ее мейнтейнером является единственный разработчик – Джеймс Ринг.

Разработчик фреймворка подчеркивает: «Основная задача RE2/J заключается в обеспечении линейного времени выполнения матчинга при наличии регулярных выражений от внешних источников. Если все регулярные выражения находятся под контролем разработчика, вероятно, использование java.util.regex является лучшим выбором«.

Надеюсь, этих пунктов достаточно, чтобы убедиться: RE2/J – не серебряная пуля; фреймворк не является бескомпромиссным решением для проверки на соответствие регулярным выражениям. Реализация при создании кода повлечет ограниченный функционал, а прямая замена импорта в уже существующем коде может негативно сказаться на стабильности работы приложения.

Итоги

Даже простые регулярные выражения при невнимательном написании могут сделать ваш продукт уязвимым для ReDoS.

Движков регулярных выражений, которые были бы одновременно максимально функциональны, быстры и стабильны, не существует.

Если все регулярные выражения в приложении находятся под контролем разработчика – обязательно тестируйте их, чтобы убедиться в отсутствии риска падения.

Если возможность самостоятельно задавать регулярное выражение есть не только у разработчика, то стоит реализовать защиту от вечной проверки с помощью создания таймаута или использования сторонних решений, позволяющих решать задачу матчинга за линейное время – например, таких, как RE2/J.

Источник

объясните как неопытному пользователю компьютера что такое BackTrack и зачем он нужен хакерам?

BackTrack — GNU/Linux-LiveCD, возникший как результат слияния WHAX и Auditor Security Collection. Проект создали Мати Ахарони (Mati Aharoni) и Макс Мозер (Max Moser).

BackTrack был создан на базе нескольких linux-дистрибутивов.
WHAX

WHAX (название создано из White Hat и SLAX) был создан для проведения тестов на проникновения. Изначально базировался на Knoppix и назывался Whoppix. Однако после выхода версии 3, основанной на Slax был переименован в WHAX. Разрабатываемый израильским специалистом по информационной безопасности Мати Ахарони, WHAX делал основной акцент на тесты на проникновение. Дистрибутив делал возможным проверку безопасности с помощью компьютеров, расположеных в различных местах.

[править] Auditor Security Collection

Макс Мозер называл Auditor Security Collection швейцарским ножом для оценки безопасности. Одинаковые цели этого дистрибутива и WHAX в конце концов привели к объединению. Он представлял более 300 инструментов в виде удобных графических меню. Эта дружелюбность к пользователю перекочевала и в BackTrack. Auditor Security Collection представлял из себя liveCD, на базе knoppix.

[править] Текущее состояние

После того, как дистрибутив начал стабильно развиваться и была налажена работа обратной связи с пользователями, производители сделали упор на расширение стабильности и функциональности, что изменило процесс разработки. В текущих версиях BackTrack большинство программ использованы в виде отдельных модулей, что упрощает процесс создание дополнений и исправлений.

Дистрибутив создан для тестировщиков информационной безопасности. Поставляется в виде LiveUSB и liveCD, от пользователя требуется только загрузиться с носителя содержащего BackTrack. Так же есть возможность установки системы на жесткий диск (требуется примерно 2,7 GB). В настоящие время в дистрибутив включены инструменты для форензики. Так же ведется работа над поддержкой иероглифических азиатских языков.

[править] Наиболее известные программы в пакете

* Metasploit
* Kismet
* Nmap
* Ettercap
* Wireshark

Для удобства доступа к инструментам они разделены на 16 категорий

* Enumeration
* Exploit archive
* Scanners
* Password Attacks
* Fuzzers
* Spoofing
* Sniffers
* Tunneling
* Wireless Tools
* Bluetooth
* Cisco Tools
* Database Tools
* Forensic Tools
* BackTrack Services
* Reversing
* Misc

Так же в состав дистрибутива включены привычные для пользователей программы Mozilla Firefox, Pidgin, K3b, и XMMS.

Источник