Как потоки помогают вам в кликере? Есть реальные примеры, где потоки реально принесли пользу? В чем они помогли?
Если пока не понял, то тебе пока это не нужно. Как появится проблема которую решат потоки, так сразу и узнаешь.
Ты узнаешь её из тысячи... В группе ВК есть товарищи, которые пихают потоки везде, надо это или не надо. Нам с ними не по пути.
Часть примеров есть в справке и в той статье. Если обобщить и оставить только суть, то основных причин применять потоки две:
1. Нам нужно одновременное выполнение двух веток скрипта.
2. Нам нужно иметь возможность прерывать выполнение ветки кода
в любом месте, с (или без) последующего перезапуска этого кода.
Чаще, но не всегда, эти причины ходят вместе.
Под "1" подходит пример с клавишами - из статьи. Где нужно нажимать кнопки клавиатуры каждую со своей периодичностью, а ля применение бафов/ударов со временем отката.
Можно сделать на паузах если они маленькие и не критично не точное выполнение периодов, ну будет чуть дольше, чем нужно. Если паузы большие, они будут мешать друг другу сильнее и может стать неприемлим такой подход. Здесь два варианта решения: на таймерах или на потоках. На потоках понятно как это будет выглядеть, плюс код будет меньше и менее сложный. На таймерах, каждому нажатию зададим свой таймер и все эти действия проверяем последовательно в цикле. Чей таймер вышел - то действие и выполняется. Точность меньше, чем на потоках из-за времени проверок и времени срабатываний вышедших таймеров.
Всё хорошо, если у нас действия простые, типа этих нажатий кнопок, а если более продолжительные? Допустим мы в цикле программы ожидаем какие-то признаки и в зависимости от признака выполняем довольно большой кусок кода. Но даже если один из признаков сработал и мы начали выполнять, нам требуется продолжать следить за другими признаками.
Пример - рыбалка на 2+ снасти. Нужно следить за разными поплавками - это можно делать и последовательно, даже именно лучше последовательно, но при клёве нужно выполнят действия по вылову. Вот действия лучше запускать в отдельном потоке. При этом может начаться клёв на другую снасть и нужно одновременно вылавливать и другой.
Здесь у нас к первой причине присоединяется и вторая.
Всё это сопровождается возможностью включать/отключать отдельные слежения (ветки кода) не городя кучу условий.
Другой пример: в давние времена, когда деревья были большими, а версия кликера маленькой, писал я скрипт на зомби ферму. Скрипт выполнял по кругу очень продолжительные и сложные действия. В основном всё работало нормально в пределах нескольких часов. Но если дольше, флеш сильно сжирал память уставал и начинал падать. Если сбои по причине интернета или браузера были очень редкими и на них писать код проверки было мало смысла, то с этим сбоем надо было решать. Решаем стандартно, следим за каким нибудь постоянным элементом игры который при падении пропадает или проверяем не появилось ли сообщение о падении (сбоев было несколько и каждый нужно ловить по своему). Написал подпрограмму проверки на сбой и при сбое действия по устранению и GOTO на старт скрипта с начала. Теперь вопрос когда и где вызывать эту подпрограмму проверки. Начал раскидывать её максимально по скрипту, внутри больших и средних по продолжительности циклов с действиями, после основных блоков. Мало. Внутри часто использующихся блоков... Стало легче, но полностью вопрос не решило.
Потому, что в скрипте было много циклов ожидания изменений на экране и с необязательным появлением картинки и с обязательным. С необязательным не так критично, а вот с обязательным нужно было добавлять вызов проверки ещё и внутрь всех этих циклов ожидания. Стало всё не очень хорошо и уж совсем не красиво и неудобно. Я до сих пор не уверен не пропустил ли я потенциальные места для проверки.
К тому же простой перезапуск всего скрипта с самого начала не подходил, он был не с самого начала, а после некоторой части инициализаций. К тому же пришлось перешерстить все переменные и задать им начальные значения не полагаясь на значения по умолчанию, ведь после перехода в начало переменные уже были использованы и там хранилось много разных значений которые нужно было сбросить.
Вот когда в кликере появились потоки эту задачу стало гораздо проще реализовать. И работала она намного надёжнее и перезапускала правильней без выпрыгивания по GOTO из десятка подпрограмм и нескольких вложенных циклов.
Вот такие дела.
Ещё пример на 2 причину: управление кнопками типа горячих клавиш. Разные кнопки запускают/останавливают разные части кода. Даже если не нужно их одновременное выполнение, особенно если не нужно!
И если реализовывать без потоков, просто по условиям запуск можно, то с остановкой проблема. Мы даже если вовремя поймаем нажатие кнопки управления (тоже вопрос как это сделать не раскидывая по скрипту капсулы из условий меняющих флаг или выпригивающих по GOTO), то если менять флаг нам всё равно нужно дождаться окончания действия или подпрыгнуть ближе к этому окончанию. С потоками же мы просто останавливаем или приостанавливаем нужный поток и всё.
