<pclass="rvps10"><spanclass="rvts22">Суть ТАСинга – в стремлении к абсолютному идеалу. Применив научный подход к прохождению видеоигр, можно увидеть в них не просто мимолётное развлечение, а сложную и интересную оптимизационную задачу.</span></p>
<pclass="rvps10"><spanclass="rvts22">Для решения комплексных задач требуется проявлять не только изобретательность, но и методичность.</span></p>
<pclass="rvps10"><spanclass="rvts22">Чтобы создать идеальное (или близкое к идеалу) прохождение игры, нужно сначала записать неидеальное прохождение, а затем заняться последовательным улучшением его отдельно взятых частей. Когда каждый фрагмент мувика является идеальным, можно говорить об идеальности всего ТАСа.</span></p>
<pclass="rvps10"><spanclass="rvts22">Концентрация усилий на небольших участках мувика – это ключ к успеху. Каждый рабочий участок должен быть достаточно большим, чтобы представлять из себя полноценную подзадачу, и при этом достаточно маленьким, чтобы эту задачу было легко решать.</span></p>
<pclass="rvps10"><spanclass="rvts22">Без такой структуризации эффективный и комфортный ТАСинг невозможен. Слишком много факторов влияют на конечный результат, и какие-то из этих факторов дополняются или противоречат друг другу. Памяти человека не хватает, чтобы удержать в голове и просчитать все взаимосвязи игровых факторов на большом отрезке прохождения, а также найти оптимальную комбинацию этих факторов. Так что во время длительных игровых сессий уТАСера, как и у обычного игрока, возникает естественный соблазн взять первые попавшиеся наблюдения в качестве основы для формирования решений. Обычному игроку такая беспечность сходит с рук, но ТАСер в итоге получит далёкое от идеала прохождение.</span></p>
<pclass="rvps10"><spanclass="rvts22">Поэтому в реальном ТАСинге участки должны быть маленькими. Весь процесс ТАСинга можно представить таким образом: сидит человек, смотрит своё тестовое прохождение, намечает в нём небольшой кусочек и бросает все силы на его улучшение, затем намечает следующий, и так до конца игры.</span></p>
<pclass="rvps10"><spanclass="rvts22">Конечно, это утрированная картина, ведь помимо непосредственно обработки мувика ТАСер ещё занимается предварительными исследованиями и экспериментами с игрой (для выявления скрытых факторов). Но это уже не имеет отношения к Тасэдитору.</span></p>
<pclass="rvps10"><spanclass="rvts22">Умение интуитивно выбирать участки отличает опытного ТАСера от новичка. Многие ТАСеры даже не задумываются, чем они руководствуются, когда спонтанно акцентируют своё внимание на некоем участке </span><spanclass="rvts22">Ввод</span><spanclass="rvts22">а, подсознательно ограничивая начало и конец текущего этапа работ. Некоторые даже полагают, что просто записывают мувик кадр за кадром подряд, не замечая, что в основном работают в рамках "окна" размером в 20-200 кадров, и это окно передвигается вперёд по мувику не плавно, а прыжками (конец предыдущего участка зачастую становится началом следующего).</span></p>
<pclass="rvps10"><spanclass="rvts22">Сейчас мы попробуем проанализировать этот навык, чтобы научиться осмысленнно определять границы текущего участка в каждом конкретном случае. А потом уже практика ТАСинга научит вас определять их машинально.</span></p>
<pclass="rvps10"><spanclass="rvts22">Правильно выбранный участок (подзадача) должен давать ТАСеру чёткую непротиворечивую </span><spanclass="rvts26">цель</span><spanclass="rvts22"> и простые однозначные </span><spanclass="rvts26">средства</span><spanclass="rvts22"> для её достижения.</span></p>
<pclass="rvps10"><spanclass="rvts26">Цель</span><spanclass="rvts22"> прохождения любого участка игры – это достижение определённого события. Например, целью прохождения всей игры является появление на экране надписи THE END. Целью прохождения одного уровня может быть событие "изменился счётчик уровней в оперативной памяти приставки" или "потемнел экран в конце текущего уровня". А целью небольшого участка может быть даже просто событие типа "персонаж приземлился по ту сторону ямы". Эти промежуточные цели определяются ситуацией в игре на данном участке мувика.</span></p>
<pclass="rvps10"><spanclass="rvts22">Исходя из цели ТАСер формулирует в уме </span><spanclass="rvts26">критерий оптимальности</span><spanclass="rvts22">– правило, по которому он сможет сравнивать любые два способа прохождения участка игры. При ТАСинге недостаточно просто достигнуть цели, нужно перепробовать множество разных вариантов её достижения и выбрать из них самый лучший, используя некий критерий. Например, в спидране обычно лучшим вариантом прохождения участка считается тот вариант, в котором целевое событие наступает раньше. То есть, если в первом варианте прохождения участка целевое событие начинается на кадре 350, а во втором – на кадре 340, то второй вариант лучше первого, и в финальном мувике должен остаться именно он.</span></p>
<pclass="rvps10"><spanclass="rvts26">Средств</span><spanclass="rvts22"> достижения целевого события у игрока очень много. Теоретически, любой аспект геймплея (в том числе не учтённый разработчиками) может помочь или помешать ТАСеру. Чтобы не запутаться в этом многообразии, надо рассматривать все игровые возможности в виде </span><spanclass="rvts26">факторов оптимальности</span><spanclass="rvts22">. Фактор оптимальности – это любой игровой аспект, который напрямую влияет на оптимальность прохождения участка.</span></p>
<pclass="rvps10"><spanclass="rvts22">При такой постановке вопроса сразу отпадает множество неактуальных на данном участке возможностей. Например, обычный игрок может переждать врага в укрытии, но в спидране такая возможность даже не рассматривается. В результате уТАСера остаётся ограниченный набор полезных действий и игровых индикаторов, за которыми требуется следить. И чем меньше участок, тем более ограничен и понятен этот набор, а значит, тем легче перебрать сочетания факторов и найти идеальную комбинацию действий.</span></p>
<pclass="rvps10"><spanclass="rvts22">С другой стороны, чем меньше участок, тем менее его цель пересекается с финальной целью ТАСа. Финальная цель уТАСера одна – сделать идеальное прохождение, например, самое быстрое в мире (то есть счётчик кадров в момент окончания мувика должен иметь минимально возможное значение). Но в рамках каждого конкретного участка цель может быть другой, иногда даже противоположной по звучанию (например, продержаться как можно дольше в бонус-уровне, за счёт чего потом будет сэкономлено время в другом месте). Поэтому для совсем мелких участков критерий оптимальности обычно не применяется, и эти микро-участки оцениваются только в составе более крупного участка.</span></p>
<pclass="rvps10"><spanclass="rvts22">Например, если во время перепрыгивания ямы вам необходимо отстреливаться от врагов, в принципе, можно рассматривать каждую выпущенную пулю в виде подучастка (чтобы изолировать и обдумать такие факторы как "таймер перезарядки", "максимум 3 пули на экране" и т.д.). Но сравнивать потом нужно будет именно варианты перепрыгивания через яму, в составе которых находятся подучастки с выстрелами. Даже если в первом варианте перепрыгивания (который заканчивается на кадре 350) вы подстрелили двух врагов, а во втором (заканчивается на 340) застрелили только одного, выбирать следует второй участок, так как его критерий оптимальности более соответствует финальной цели спидрана.</span></p>
<pclass="rvps10"><spanclass="rvts22">Возьмём пример со слишком большим участком. В спидране Super Mario Bros требуется максимально быстро добраться от начала до конца World 1-1, то есть нужно максимизировать координату X персонажа, который перемещается слева направо. В начале уровня координата Марио равна нулю, а в конце уровня, допустим, равна тысяче. С помощью кнопок джойстика можно по-разному влиять на эту координату.</span></p>
<pclass="rvps10"><spanclass="rvts22">Если в качестве оптимизируемого участка выбрать весь уровень от момента с</span><spanclass="rvts37">X = 0</span><spanclass="rvts22"> до события </span><spanclass="rvts37">X = 1000</span><spanclass="rvts22">, то у нас появляется однозначный критерий оптимальности при записи и оценке вариантов прохождения участка – самым лучшим вариантом будет мувик с минимальным значением счётчика кадров на момент </span><spanclass="rvts37">X = 1000</span><spanclass="rvts22">. Итак, у нас есть критерий, но нет факторов. Как именно нужно нажимать кнопки, чтобы получить </span><spanclass="rvts37">X = 1000</span><spanclass="rvts22"> за наименьшее количество кадров? Здесь человек подключает логику и интуицию. При нажатии кнопки </span><spanclass="rvts32">R</span><spanclass="rvts22"> координата X обычно возрастает, а при нажатии </span><spanclass="rvts32">L</span><spanclass="rvts22"> убывает. И вот, самое очевидное решение – зажать кнопку </span><spanclass="rvts32">R</span><spanclass="rvts22"> и узнать, через сколько кадров значение X дорастёт до тысячи. Однако при просмотре такого варианта в эмуляторе оказывается, что Марио упирается в препятствия, и координата X не растёт, хотя кнопка </span><spanclass="rvts32">R</span><spanclass="rvts22"> зажата. Тем самым обнаруживается новый фактор – необходимость перепрыгивать препятствия и ямы. В результате применения кнопки </span><spanclass="rvts32">A</span><spanclass="rvts22"> персонаж вскоре достигает момента с</span><spanclass="rvts37">X = 1000</span><spanclass="rvts22">, и при этом по критерию оптимальности сразу отсеялись все варианты прохождения, где нажатия кнопки </span><spanclass="rvts32">A</span><spanclass="rvts22"> были менее своевременными (например, там, где Марио спотыкался о края труб, счётчик кадров в конце участка был больше).</span></p>
<pclass="rvps10"><spanclass="rvts22">Тут игрок может посчитать, что учёл все факторы оптимальности, и что участок пройден идеально. Однако это не так. В Super Mario Bros довольно сложный физический движок. На координату X влияет текущее значение скорости, а на значение скорости влияет ускорение. На ускорение влияет кнопка </span><spanclass="rvts32">B</span><spanclass="rvts22"> и положение Марио в воздухе или на земле. Также существуют трубы-телепорты и полезные баги игры, вроде "flagpole glitch" и т.д. А в рабочей памяти человека может одновременно храниться лишь </span><aclass="rvts28"href="http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D1%87%D0%B8%D1%81%D0%BB%D0%BE_%D1%81%D0%B5%D0%BC%D1%8C_%D0%BF%D0%BB%D1%8E%D1%81-%D0%BC%D0%B8%D0%BD%D1%83%D1%81_%D0%B4%D0%B2%D0%B0"target="_blank">около 7 объектов</a><spanclass="rvts22">, поэтому часть факторов обязательно ускользнёт от вас во время редактирования </span><spanclass="rvts22">Ввод</span><spanclass="rvts22">а. Необходимо уменьшить участок до масштаба, при котором факторы проявляются по отдельности, или хотя бы небольшой группой.</span></p>
<pclass="rvps10"><spanclass="rvts22">Сосредоточимся на участке от </span><spanclass="rvts37">X = 0</span><spanclass="rvts22"> до </span><spanclass="rvts37">X = 50</span><spanclass="rvts22">, критерий оптимальности тот же.</span><spanclass="rvts22"> Здесь уже становится заметно, что в первой половине участка Марио почему-то бежит медленнее, чем во второй, причём во второй половине он бежит всё время с одинаковой скоростью, которую можно принять за максимально возможную. Таким образом проявляется фактор ускорения, и ТАСер начинает думать, как бы на него повлиять. Благодаря экспериментам с прыжками он может обнаружить различие значений ускорения в воздухе и на земле. Таким образом проявляется ещё один фактор.</span></p>
<pclass="rvps10"><spanclass="rvts22">В результате по текущему критерию оптимальности к моменту с</span><spanclass="rvts37">X = 50</span><spanclass="rvts22"> быстрее приходит тот вариант мувика, где ТАСер в начале уровня создал сложную комбинацию из нажатий и отпусканий кнопок </span><spanclass="rvts32">R</span><spanclass="rvts22">, </span><spanclass="rvts32">B</span><spanclass="rvts22"> и </span><spanclass="rvts32">A</span><spanclass="rvts22">, а не просто зажал </span><spanclass="rvts32">R</span><spanclass="rvts22"> и </span><spanclass="rvts32">B</span><spanclass="rvts22">. И это прохождение уже гораздо ближе к идеалу, после этого можно на какое-то время успокоиться и взяться за следующий участок (от </span><spanclass="rvts37">X = 50</span><spanclass="rvts22"> до </span><spanclass="rvts37">первого препятствия)</span><spanclass="rvts22">.</span></p>
<pclass="rvps10"><spanclass="rvts22">Теперь рассмотрим другую крайность –ТАСер выбирает очень маленький участок и ограничивается оптимизацией только заданного набора кадров. На таком масштабе хорошо видны цели и средства, весь участок целиком умещается в окне Piano Roll, работать одно удовольствие. Однако здесь возможна ситуация, когда мы получаем неверный критерий оптимальности, который противоречит финальной цели ТАСа.</span></p>
<pclass="rvps10"><spanclass="rvts22">Например, если в SMB увлечься максимизацией скорости и ускорения в промежутках между каждой следующей сотней пикселей, можно забыть про трубу, которая сокращает путь к концу уровня. Ведь остановка и ныряние в трубу сбрасывают значение скорости в ноль, что противоречит плану по максимизации фактора "скорость". В данном случае участок был выбран неверно, и, как следствие, появился неверный критерий оптимальности ("на момент </span><spanclass="rvts37">X = 200</span><spanclass="rvts22"> счётчик кадров должен быть минимален"). Нужно было определить концом участка момент ныряния в трубу. Такие ошибки порой замечаются при повторном просмотре готового мувика на свежую голову, но иногда ошибка менее очевидна и обнаруживается только после опубликования.</span></p>
<pclass="rvps10"><spanclass="rvts22">Например, в том же SMB после ныряния в трубу (мир 1-1) нужно добраться до выхода, находящегося справа. Казалось бы, требуется с первых мгновений начинать максимизацию скорости. Однако тесты показали, что в течение первой дюжины кадров правильнее всего будет зажать кнопку </span><spanclass="rvts32">L</span><spanclass="rvts22">, а не </span><spanclass="rvts32">R</span><spanclass="rvts22">, чтобы сначала приземлиться немного левее от стенки, через которую требуется перепрыгнуть. Если сразу зажать </span><spanclass="rvts32">R</span><spanclass="rvts22">, то Марио приземлится вплотную перед стенкой, и ему придётся прыгать вертикально вверх, обнулив всю набранную скорость.</span></p>
<pclass="rvps10"><spanclass="rvts22">Таким образом, если вы выберете в качестве оптимизируемого участка промежуток из дюжины первых кадров (от </span><spanclass="rvts37">появления Марио</span><spanclass="rvts22"> до </span><spanclass="rvts37">приземления</span><spanclass="rvts22">) , критерий оптимальности подскажет вам неверную последовательность кнопок (по результатам тестов выиграет вариант с зажатием </span><spanclass="rvts32">R</span><spanclass="rvts22"> вместо </span><spanclass="rvts32">L</span><spanclass="rvts22">). Здесь нужно выбирать участок от первого кадра появления Марио до момента перепрыгивания угла стенки.</span></p>
<pclass="rvps10"><spanclass="rvts22">Конкретные размеры участка сильно различаются не только от игры к игре, но и от этапа к этапу в одной и той же игре. Опытные ТАСеры используют индивидуальный подход к каждому следующему участку (хоть и не задумываются об этом слишком долго). Выбирать следующий участок по тому же принципу, что и предыдущий – плохая идея, это срабатывает только в очень однообразных играх.</span></p>
<pclass="rvps10"><spanclass="rvts22">В принципе, можно измерять участок в кадрах (например, ставить цель максимизировать координату X на момент истечения первой сотни кадров мувика), но логичнее ассоциировать конец участка с каким-нибудь мелким рубежом в игре (например, удачное преодоление ловушки или убийство очередного врага) – тогда сама цель будет подсказывать вам средства для её достижения. Задача типа "взять цветок максимально быстро" звучит гораздо понятнее, чем задача "на кадр 300 быть максимально близко к цветку".</span></p>
<pclass="rvps10"><spanclass="rvts22">В подавляющем большинстве видеоигр игровой процесс делится на "комнаты", "волны врагов" и "последовательности ловушек", между которыми обязательно присутствуют краткие моменты расслабления. Даже в играх со скроллингом и свободным исследованием мира дизайн уровней всегда таков, что можно выделить насыщенные участки и промежутки отдыха между ними. Дело в том, что </span><spanclass="rvts26">дизайнеры тоже структурируют задачу игрока на подзадачи</span><spanclass="rvts22">, так что в ряде случаев ТАСер может воспользоваться заготовленным разбиением. Главное, не забывать его критически оценивать и при необходимости доразбивать на более мелкие подучастки (впрочем, это дробление произойдёт само собой в процессе редактирования Ввода большого участка).</span></p>
<pclass="rvps10"><spanclass="rvts22">Это можно сравнить с тем, как писатели разбивают книгу на главы (уровни игры), а главы – на абзацы и предложения (участки). Простой читатель (игрок) довольствуется авторским разбиением для удобства чтения и впитывания авторского замысла. Но литературному критику (ТАСеру) необходимо уметь читать между строк, разбивая предложения по своему разумению.</span></p>
<pclass="rvps10"><spanclass="rvts22">Например, в Super Mario Bros между каждой группой врагов есть относительно спокойный промежуток уровня, на котором не требуется особое мастерство управления, его можно бездумно пробежать или пропрыгать, зажав </span><spanclass="rvts32">Вправо </span><spanclass="rvts22">(подразумевается, что Марио уже давно разогнался до максимальной скорости). Идеальный ТАС в такие моменты почти не будет отличаться от неидеального прохождения. Эти моменты очень хорошо подходят в качестве промежуточных целей – если обозначить здесь конец участка, то критерий его оптимальности не будет противоречить финальной цели ТАСа. И обычно эти моменты чередуются достаточно часто, чтобы полученный между ними участок был небольшим (одна-две сотни кадров), ну или потребуется разбиение его на два-три рабочих участка.</span></p>
<pclass="rvps10"><spanclass="rvts22">Разделение ТАСа на участки существовало всегда, но Тасэдитор делает этот процесс более осмысленным и понятным для новичка. В Тасэдиторе вы можете визуально отметить начало и конец любого участка с помощью Маркеров или Закладок.</span></p>
<pclass="rvps10"><spanclass="rvts22">При просмотре тестового прохождения можно легко выбрать кадр начала участка – момент в игре, когда все предшествующие факторы можно игнорировать. Так, например, в начале каждого уровня начинается очередной участок, потому что все факторы, действовашие на последнем участке предыдущего уровня (такие как счётчик жизней босса), утратили свою актуальность, уступив место новым факторам. Поэтому в начале каждого уровня имеет смысл ставить Маркер или Закладку, обозначив не только начало уровня, но и начало текущего рабочего участка. Благодаря визуальной отметке вы не будете отвлекаться на соседний Ввод при шлифовке участка и не потратите время на анализ устаревших факторов и тестирование бесполезных вариантов.</span></p>
<pclass="rvps10"><aname="EndOfSegment"></a>
<spanclass="rvts22">С концом участка дело обстоит немного иначе. Определившись с целью (например, довести координату X до значения 50) можно зафиксировать конец участка, установив второй Маркер/Закладку на кадре, где текущее неидеальное прохождение достигает этой цели. При шлифовке </span><spanclass="rvts22">Ввод</span><spanclass="rvts22">а мы постараемся достичь той же цели (</span><spanclass="rvts37">X = 50</span><spanclass="rvts22">) на более ранний кадр, или хотя бы на тот же. И если в ходе редактирования и тестов </span><spanclass="rvts22">Ввод</span><spanclass="rvts22">а обнаружится, что цель действительно можно достигнуть раньше, необходимо будет передвинуть замыкающий Маркер/Закладку выше (отметив улучшенный конец участка), а затем продолжить тестирование других вариантов в поисках ещё лучшего. В традиционном методе ТАСинга именно так постепенно передвигается вверх главная Закладка, хранящая лучшее на данный момент прохождение участка.</span></p>
<pclass="rvps10"><spanclass="rvts22">В принципе, в Тасэдиторе вы можете дать волю своей лени и не отмечать конец участка ни Закладкой, ни Маркером, а просто держать цель в уме и примерно помнить, на каком кадре проявляется конечное событие в лучшем варианте. Эта мелочная экономия времени имеет смысл, когда участок очень прост, и его не потребуется многократно переделывать. Также, вместо замыкающего Маркера во многих случаях можно ориентироваться по зелёной стрелке, автоматически остающейся на кадре прошлого конца участка.</span></p>
<pclass="rvps10"><spanclass="rvts22">Однако в сложных ТАСах, где голова заполнена обдумыванием множества факторов оптимальности, лучше не торопиться, а методично отмечать текущий конец участка Закладкой, перестанавливая эту Закладку в случае улучшения Ввода на участке. Ведь в сложных ТАСах улучшение участка – это большое достижение, так что слишком часто изменять отметку конца участка вам не придётся.</span></p>
<pclass="rvps10"><spanclass="rvts22">Когда появляется уверенность, что найдено наилучшее решение из всех возможных, надо переходить к следующему участку. Не нужно просто так удалять старые Маркеры, они могут пригодиться в будущем, когда вы усомнитесь в идеальности тех или иных решений (например, найдя новый трюк) и захотите отредактировать Ввод в ранее пройденных уровнях. Скорее всего, логика разбиения останется той же даже после появлении нового фактора (нового трюка), и готовое разбиение сэкономит вам время.</span></p>
<pclass="rvps10"><spanclass="rvts22">Если в процессе тестирования вариантов Ввода на участке у вас появляется уверенность, что найдена наилучшая последовательность Ввода для первой половины (или трети) участка, имеет смысл разбить участок надвое и заняться только оставшимся вторым. Часто такие ситуации возникают, когда изначально взят слишком большой участок, и только при редактировании проявились логические подучастки в его составе. Это обычная практика.</span></p>
<pclass="rvps10"><spanclass="rvts22">Итак, если ваш характер не приемлет порядка, вы можете вовсе не ставить Маркеры и Закладки во время работы, представляя участки умозрительно. Но учтите, что эта информация тоже занимает часть рабочей памяти человека, так что в результате может не хватить места для каких-то факторов оптимальности, и вы этого даже не заметите.</span></p>
<pclass="rvps10"><spanclass="rvts22">Если же вы, наоборот, любите порядок, рекомендуется после завершения шлифовки участка (а можно и до или во время шлифовки) добавлять к Маркерам текстовые Заметки! Желательно оставлять комментарий хотя бы к Маркеру в начале участка, например, название участка или тег. Таким образом вы одновременно с ТАСингом документируете его разработку, оформляете появляющийся Ввод и придаёте ему объективный смысл. Это особенно полезно при работе в соавторстве, но и при ТАСинге в одиночку вы можете заметить, что "документация" из прошлых уровней мотивирует продолжать ТАСинг следующих. Отнимая секунды на печать текста, Маркеры дают силы не забросить проект на годы.</span></p>
<pclass="rvps10"><spanclass="rvts22">Также Заметки помогают полнее раскрыть потенциал хитроумных трюков и багов игры. Дело в том, что во время написания текста Заметки, вы формализуете собственные знания об описываемом явлении. Когда суть трюка хранится в голове, вам будет казаться, что вы знаете о нём всё, и что в текущем ТАСе он уже и так используется максимально эффективно. Но когда появляется объективная модель в виде словесного описания трюка, нередко раскрываются новые грани вещей, казавшихся очевидными. На сайте TASVideos.org часто были случаи, когда один ТАСер прочитал описание какого-то трюка в сабмишене другого ТАСера и обнаружил способ использовать этот трюк лучше автора. Также были случаи, когда сам автор, перечитав свой свежий сабмишен, хлопал себя по лбу и срочно записывал улучшение.</span></p>
<pclass="rvps10"><spanclass="rvts22">Несмотря на всю полезность Маркеров и организации рабочего процесса, основной целью ТАСинга является создание Ввода. На поиск идеальной последовательности нажатий на каждом участке уходит намного больше времени, чем на всё остальное.</span></p>
<pclass="rvps10"><spanclass="rvts22">Зачастую почти сразу кажется, что текущий Ввод – самый лучший из всех возможных (особенно при сравнении с первоначальным вариантом). Но обычно это не так, особенно если вы делаете вывод об оптимальности, ориентируясь только на экран FCEUX, а не на состояние памяти (Memory Watch). Поэтому всегда есть смысл предполагать текущий результат неидеальным. Если вы в данный момент не видите в нём никаких ошибок и потенциальных улучшений, то надо переходить к следующему участку, но не отвергать последующие попытки улучшить предыдущие участки.</span></p>
<pclass="rvps10"><spanclass="rvts22">Чаще просматривайте готовую часть мувика –с начала игры или начала уровня до последнего записанного участка – и пытайтесь заметить несовершенства. Тасэдитор позволяет редактировать </span><spanclass="rvts22">Ввод</span><spanclass="rvts22"> прямо во время просмотра, поэтому любую спонтанную идею можно ввести посреди готовых участков сразу же, как только идея пришла в голову. Если она окажется неудачной, просто откатите последние изменения Истории или вернитесь во времени на Закладку с последним актуальным состоянием мувика. А если идея действительно улучшит ваш ТАС, после радостных известий необходимо будет ещё добиться синхронизации последующих участков </span><spanclass="rvts22">Ввод</span><spanclass="rvts22">а (так как из-за реализации этой идеи последующее состояние игры изменится). Причём переписывать весь последующий </span><spanclass="rvts22">Ввод </span><spanclass="rvts22">в большинстве случаев не требуется. Обычно достаточно лишь удалить или вставить пару кадров (сдвинув все участки вверх), или подправить несколько участков между местом реализации идеи и ближайшим чекпоинтом (конец уровня или т.п.). В Тасэдиторе всё это делается довольно быстро, а в ходе вынужденных исправлений вы можете обнаружить ещё какую-нибудь ошибку или нереализованную идею.</span></p>
<pclass="rvps10"><spanclass="rvts22">Многие обгоны спидранов появлялись из-за обнаружения маленького улучшения в середине мувика, из-за чего приходилось потом переписывать (пересинхронизировать) всю вторую половину мувика и даже наталкиваться на новые улучшения. А потом эти новые трюки оказалось возможным применить в первом уровне игры. Движок у игры один, и если трюк сработал в одном уровне, он вполне может сработать в другом, где возникают подобные условия. И даже если условия не возникают, порой можно их создать за счёт потери чего-то менее ценного. В итоге весь мувик неоднократно переписывается почти с самого начала. Так из маленького улучшения вырастает серьёзный обгон.</span></p>
<pclass="rvps10"><spanclass="rvts22">Главное – не жалеть выбрасывать уже проделанную работу, когда многодневные труды по отшлифовке мувика становятся неактуальными из-за обнаружения ошибки (упущенной возможности оптимизации).</span></p>
<pclass="rvps10"><spanclass="rvts22">ТАСинг традиционным методом очень быстро приучает ТАСера к мысли о неизбежности потерь. Сам принцип многократной перезаписи одного и того же участка предлагает ТАСеру оценивать свой прогресс количеством затраченных попыток, ушедших впустую. Ведь при ТАСинге без Тасэдитора выбрасывать проделанную работу приходится на каждом шагу, как в мелочах, так и по-крупному.</span></p>
<pclass="rvps10"><spanclass="rvts22">Тасэдитор позволяет предотвратить некоторые мелкие потери, но он не спасает от необходимости крупных переделок в случае обнаружения новых факторов оптимизации. Например, проходя третий уровень, вы можете обнаружить новый трюк, который также срабатывает на первом уровне, – теперь вам необходимо заново переделывать не только первый и третий уровни, но, скорее всего, и второй, к которому новый трюк не имеет никакого отношения. Конечно, во второй раз те же самые уровни ТАСить гораздо проще, но сам факт выброшенного времени иногда удручает, и поначалу даже кажется, что исправление старой ошибки не стоит того, чтобы тратить на него время. В этом случае следует, не долго думая, либо заставить себя сделать это, либо отложить исправление на следующий раз, оставив рядом с ошибкой Маркер с памяткой, детально описывающей суть проблемы. Если к моменту окончания ТАСа таких отложенных планов накапливается немало, придётся назвать почти готовый мувик "тестовым пробегом" и после продолжительного отдыха взяться за его переписывание. Впрочем, ревизия готового ТАСа имеет смысл всегда, даже когда на уме нет запланированных улучшений.</span></p>
<pclass="rvps10"><spanclass="rvts22">Просмотрите в Тасэдиторе неидеальное прохождение 1 уровня, записанное в прошлом практическом занятии, и с помощью Маркеров разделите его на участки по собственному принципу. Если мувик длинный, не нужно структурировать его полностью, требуется только прочувствовать принципы разбиения.</span></p>
<pclass="rvps10"><spanclass="rvts26">Примерное время выполнения: </span><spanclass="rvts22">5-10 минут.</span></p>
<pclass="rvps8"><spanclass="rvts18">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts19"href="http://www.helpndoc.com/help-authoring-tool">Free help authoring environment</a></p>
