Подробности про командную строку
#код
Запилил на днях по работе командную строку с проверкой синтаксиса и автодополнением и похвастался этим в чатике. Народ проявил интерес и поэтому рассказываю подробнее.
Нужна эта штука для двух вещей. Во-первых, сценаристы, собирающие диалоги в редакторе, должны иметь возможность проверять доступность вариантов ответа (например, реплика возможна только при заданном уровне интеллекта или после выполнения квеста), а также вызывать скрипты при ответах. Во-вторых, для разработки нужна классическая игровая консоль для ввода читов и отладки. Чтобы разом покрыть оба этих юзкейса нужно написать нехитрый интерпретатор строки. Разумеется, он не будет поддерживать все фишки C#, а только некоторый базовый сабсет, вроде функций, операторов и скобочек.
Теперь о реализации. Несмотря на кажущуюся сложность задачи, имплементация у меня до боли простая и занимает чуть более тысячи строк. Первый элемент системы — это, конечно, лексический анализатор. Который у меня в коде какого-то фига называется Parser (надо не забыть переименовать в Lexer, а то чё я, как наркоман). Лексер представляет собой одну единственную функцию-генератор, которая в цикле читает символы строки и возвращает по одной токены лексем, которыми могут быть:
Между лексемами могут быть пробелы, они игнорируются. Помимо типа, токен также хранит начало и длину фрагмента внутри входной строки (чтобы подсветить красным место, в котором произошла ошибка) и поле типа object для дополнительной информации: для value это считанное значение, для оператора — информация о том, какой конкретно оператор и т.п. Единственный нюанс, при чтении знака минус, нужно взглянуть на то, какой токен был перед этим: если значение, идентификатор или закрывающая скобка, то это оператор минус, в противном случае начало отрицательного числа.
Едем дальше. Непосредственно сам интерпретатор совмещённый с валидатором. Он у меня однопроходный, то есть я читаю очередь лексем слева направо и сразу же выполняю. Командная строка может выполнять только выражения. Выражение — это один или несколько операндов, разделённых операторами. Например,
или просто
Когда мы дошли до конца выражения (конец строки, запятая или закрывающая скобка), мы выполняем операторы в порядке их приоритета («схлопываем» по два операнда, пока не останется только один).
Операндом может выступать как значение, так и другое выражение в скобках. Поэтому если наткнёмся на открывающуюся скобку, то просто запускаем процесс парсинга вложенного выражения рекурсивно. И также операндом может выступать цепочка идентификаторов, типа такой:
В данном случае мы тоже выполняем всё последовательно. Сначала ищем объект среди глобальных. У меня разрешены только классы скриптов (считай, синглтоны) и enum’ы. Затем на каждый доступ через точку достаём через рефлекшн соответствующий member класса, а при вызове функции запускаем сперва вложенный парсинг выражений-аргументов через запятую.
Собственно, всё. Ну ещё есть оператор присваивания, который умеет вызывать сеттер для поля или свойства, но теперь точно всё.
Валидация происходит точно также, как и выполнение, только в «холостом» режиме: вместо честных вызовов функций и операторов, мы возвращаем объект-заглушку, которая знает какого типа должен быть результат. Этой информации достаточно, чтобы проверить весь синтаксис.
Автодополнение же сделано запуском валидации строки, в которую в определённом месте вставлен символ многоточие. При разборе
лексер вернёт не идентификатор «Pl», а специальную лексему типа Autocomplete «Pl...». Ну а синтаксический анализатор, если наткнётся на эту лексему там, где предполагается идентификатор, посмотрит, какие вообще есть варианты, и если что-то подходит, то бросит AutoCompleteException, содержащий остаток строки. Заменой выделенного текста на автодополненный вариант занимается уже гуишный контрол наверху.
#код
Запилил на днях по работе командную строку с проверкой синтаксиса и автодополнением и похвастался этим в чатике. Народ проявил интерес и поэтому рассказываю подробнее.
Нужна эта штука для двух вещей. Во-первых, сценаристы, собирающие диалоги в редакторе, должны иметь возможность проверять доступность вариантов ответа (например, реплика возможна только при заданном уровне интеллекта или после выполнения квеста), а также вызывать скрипты при ответах. Во-вторых, для разработки нужна классическая игровая консоль для ввода читов и отладки. Чтобы разом покрыть оба этих юзкейса нужно написать нехитрый интерпретатор строки. Разумеется, он не будет поддерживать все фишки C#, а только некоторый базовый сабсет, вроде функций, операторов и скобочек.
Теперь о реализации. Несмотря на кажущуюся сложность задачи, имплементация у меня до боли простая и занимает чуть более тысячи строк. Первый элемент системы — это, конечно, лексический анализатор. Который у меня в коде какого-то фига называется Parser (надо не забыть переименовать в Lexer, а то чё я, как наркоман). Лексер представляет собой одну единственную функцию-генератор, которая в цикле читает символы строки и возвращает по одной токены лексем, которыми могут быть:
Value (строки, числа, true и false),
Identifier,
Dot,
Comma,
OpenBracket,
ClosedBracket,
Operator,
AssignmentOperator,
EndOfLine
Между лексемами могут быть пробелы, они игнорируются. Помимо типа, токен также хранит начало и длину фрагмента внутри входной строки (чтобы подсветить красным место, в котором произошла ошибка) и поле типа object для дополнительной информации: для value это считанное значение, для оператора — информация о том, какой конкретно оператор и т.п. Единственный нюанс, при чтении знака минус, нужно взглянуть на то, какой токен был перед этим: если значение, идентификатор или закрывающая скобка, то это оператор минус, в противном случае начало отрицательного числа.
Едем дальше. Непосредственно сам интерпретатор совмещённый с валидатором. Он у меня однопроходный, то есть я читаю очередь лексем слева направо и сразу же выполняю. Командная строка может выполнять только выражения. Выражение — это один или несколько операндов, разделённых операторами. Например,
a + b * c + d
или просто
a
Когда мы дошли до конца выражения (конец строки, запятая или закрывающая скобка), мы выполняем операторы в порядке их приоритета («схлопываем» по два операнда, пока не останется только один).
Операндом может выступать как значение, так и другое выражение в скобках. Поэтому если наткнёмся на открывающуюся скобку, то просто запускаем процесс парсинга вложенного выражения рекурсивно. И также операндом может выступать цепочка идентификаторов, типа такой:
Foo.bar.foo(a + b, c).foo.bar
В данном случае мы тоже выполняем всё последовательно. Сначала ищем объект среди глобальных. У меня разрешены только классы скриптов (считай, синглтоны) и enum’ы. Затем на каждый доступ через точку достаём через рефлекшн соответствующий member класса, а при вызове функции запускаем сперва вложенный парсинг выражений-аргументов через запятую.
Собственно, всё. Ну ещё есть оператор присваивания, который умеет вызывать сеттер для поля или свойства, но теперь точно всё.
Валидация происходит точно также, как и выполнение, только в «холостом» режиме: вместо честных вызовов функций и операторов, мы возвращаем объект-заглушку, которая знает какого типа должен быть результат. Этой информации достаточно, чтобы проверить весь синтаксис.
Автодополнение же сделано запуском валидации строки, в которую в определённом месте вставлен символ многоточие. При разборе
GlobalVars.Pl…
лексер вернёт не идентификатор «Pl», а специальную лексему типа Autocomplete «Pl...». Ну а синтаксический анализатор, если наткнётся на эту лексему там, где предполагается идентификатор, посмотрит, какие вообще есть варианты, и если что-то подходит, то бросит AutoCompleteException, содержащий остаток строки. Заменой выделенного текста на автодополненный вариант занимается уже гуишный контрол наверху.
SOLIDные рассуждения
#код
Месяц назад я твитнул, что, дескать, как только слышу от соискателя или работодателя в геймдеве что-нибудь про SOLID, так сразу автоматически помечаю их в своей голове как нубов, либо поехавших. С тех пор мне пришлось пару раз подискутировать на эту тему в разных уголках интернета, и я решил, что стоит уже это оформить в отдельный пост.
Понятно, что это своего рода упрощение и навешивание ярлыков, которое отражает ситуацию лишь до определённой точности, но оно взято не из воздуха, а основывается на наблюдениях за реальным положением дел. И главный мой тезис в том, что в геймдеве на реальных проектах принципами SOLID никто никогда не руководствуется. Соответственно, если человек декларирует их своими ценностями, то он либо новичок в области, начитавшийся умных слов и книжек, но ещё не нюхавший пороху как следует на практике; либо же, мягко говоря, довольно неординарный геймдевелопер. То есть наглухо поехавший с моей точки зрения.
Поехавшие, в свою очередь, делятся, на две основные категории. Первые — это люди, пришедшие из энтерпрайза. Я никогда в энтерпрайзе не работал, но похоже, что там написание абстрактного кода эволюционно более привлекательная стратегия. Я ничего против этого не имею, но когда эти люди приходят в геймдев, с ними бывает тяжело сработаться, так как это зачастую сплошное ООП головного мозга. Там, где типичный программист из кровавого энтерпрайза в рубашке с длинными рукавами заведёт десять интерфейсов и фабрику фабрик; типичный геймдевелопер в перепачканной пиццой футболке вооружится принципами KISS и YAGNI и удалит это всё нахрен, написав взамен простой и понятный класс, решающий конкретную задачу. Пусть и наплевав при этом на принцип открытости/закрытости, разделения интерфейсов и другие святая святых ООП. То есть, конечно, наверняка где-то в природе существуют игры, написанные полностью по канонам SOLID. Но, во-первых, я такого не встречал, а во-вторых, боюсь представить, что там за монструозная кодобаза, и не считаю это нормальным.
Вторая важная категория «поехавших», которую хотелось бы разобрать — это люди, утверждающие, что применяют принципы SOLID, но на самом деле этого не делающие. Их аргументация обычно сводится к тому, что солид следует применять не по всему проекту, а лишь в тех местах, где он подходит. Но тут налицо непонимание разницы между паттерном и принципом. Солид это не паттерн, а принцип. Ты либо стараешься следовать ему везде, либо это уже не солид.
Поясню. Вот есть DRY. Очень простой принцип о том, что надо стараться избегать копипаста. Конечно, где-то в коде могут быть отступления от этого правила, но если человек исповедует dry, то в какой-то момент он может посмотреть на некий участок кода, решить, что он недостаточно dry, и переписать его менее влажно. Не потому, что этот участок кода работал плохо, а только лишь потому, что он не соответствует принципам, по которым мы решили писать код. И это действительно происходит в реальных проектах. То же касается KISS и YAGNI. Но не SOLID. Не бывает такого, что чувак в геймдеве смотрит на код, и решает, что дай-ка я его перепишу, потому что он какой-то недостаточно солидный. Ну не бывает такого на практике. А если ты так не делаешь, значит, ты и не следуешь этому принципу. У тебя просто в случайных местах код написан в соответствии с его правилами, но ты ими на самом деле не руководствовался.
Вот так и получается, что если кто-то в геймдеве на полном серьёзе топит за SOLID, то для меня это или нуб или поехавший.
Обсудить
#код
Месяц назад я твитнул, что, дескать, как только слышу от соискателя или работодателя в геймдеве что-нибудь про SOLID, так сразу автоматически помечаю их в своей голове как нубов, либо поехавших. С тех пор мне пришлось пару раз подискутировать на эту тему в разных уголках интернета, и я решил, что стоит уже это оформить в отдельный пост.
Понятно, что это своего рода упрощение и навешивание ярлыков, которое отражает ситуацию лишь до определённой точности, но оно взято не из воздуха, а основывается на наблюдениях за реальным положением дел. И главный мой тезис в том, что в геймдеве на реальных проектах принципами SOLID никто никогда не руководствуется. Соответственно, если человек декларирует их своими ценностями, то он либо новичок в области, начитавшийся умных слов и книжек, но ещё не нюхавший пороху как следует на практике; либо же, мягко говоря, довольно неординарный геймдевелопер. То есть наглухо поехавший с моей точки зрения.
Поехавшие, в свою очередь, делятся, на две основные категории. Первые — это люди, пришедшие из энтерпрайза. Я никогда в энтерпрайзе не работал, но похоже, что там написание абстрактного кода эволюционно более привлекательная стратегия. Я ничего против этого не имею, но когда эти люди приходят в геймдев, с ними бывает тяжело сработаться, так как это зачастую сплошное ООП головного мозга. Там, где типичный программист из кровавого энтерпрайза в рубашке с длинными рукавами заведёт десять интерфейсов и фабрику фабрик; типичный геймдевелопер в перепачканной пиццой футболке вооружится принципами KISS и YAGNI и удалит это всё нахрен, написав взамен простой и понятный класс, решающий конкретную задачу. Пусть и наплевав при этом на принцип открытости/закрытости, разделения интерфейсов и другие святая святых ООП. То есть, конечно, наверняка где-то в природе существуют игры, написанные полностью по канонам SOLID. Но, во-первых, я такого не встречал, а во-вторых, боюсь представить, что там за монструозная кодобаза, и не считаю это нормальным.
Вторая важная категория «поехавших», которую хотелось бы разобрать — это люди, утверждающие, что применяют принципы SOLID, но на самом деле этого не делающие. Их аргументация обычно сводится к тому, что солид следует применять не по всему проекту, а лишь в тех местах, где он подходит. Но тут налицо непонимание разницы между паттерном и принципом. Солид это не паттерн, а принцип. Ты либо стараешься следовать ему везде, либо это уже не солид.
Поясню. Вот есть DRY. Очень простой принцип о том, что надо стараться избегать копипаста. Конечно, где-то в коде могут быть отступления от этого правила, но если человек исповедует dry, то в какой-то момент он может посмотреть на некий участок кода, решить, что он недостаточно dry, и переписать его менее влажно. Не потому, что этот участок кода работал плохо, а только лишь потому, что он не соответствует принципам, по которым мы решили писать код. И это действительно происходит в реальных проектах. То же касается KISS и YAGNI. Но не SOLID. Не бывает такого, что чувак в геймдеве смотрит на код, и решает, что дай-ка я его перепишу, потому что он какой-то недостаточно солидный. Ну не бывает такого на практике. А если ты так не делаешь, значит, ты и не следуешь этому принципу. У тебя просто в случайных местах код написан в соответствии с его правилами, но ты ими на самом деле не руководствовался.
Вот так и получается, что если кто-то в геймдеве на полном серьёзе топит за SOLID, то для меня это или нуб или поехавший.
Обсудить
Исходники командной строки
#код
Удивительное дело, но моего недавнего поста про командную строку в нашем проекте оказалось недостаточно, чтобы утолить к ней интерес. Народ продолжил требовать запилить ассет. С ассет стором я, конечно же, возиться не стал, но код, так уж и быть, заопенсорсил.
Код не идеальный. Например, он много мелочи аллочит, чего по идее можно было бы избежать (впрочем, задачи такой не стояло, так как командная строка не каждый кадр выполняется). Тем не менее, это вполне боевой код. В нашем проекте он почти в таком виде и существует. Я вычистил кое-какие зависимости от Encased, чутка причесал и накатал минимальный пример использования. Если очень захотеть, то вполне можно заюзать это в своём проекте.
Обсудить
#код
Удивительное дело, но моего недавнего поста про командную строку в нашем проекте оказалось недостаточно, чтобы утолить к ней интерес. Народ продолжил требовать запилить ассет. С ассет стором я, конечно же, возиться не стал, но код, так уж и быть, заопенсорсил.
Код не идеальный. Например, он много мелочи аллочит, чего по идее можно было бы избежать (впрочем, задачи такой не стояло, так как командная строка не каждый кадр выполняется). Тем не менее, это вполне боевой код. В нашем проекте он почти в таком виде и существует. Я вычистил кое-какие зависимости от Encased, чутка причесал и накатал минимальный пример использования. Если очень захотеть, то вполне можно заюзать это в своём проекте.
Обсудить
GoTo the Dark Side
#код
Сегодня чатик что-то беснуется по поводу использования goto. Орден джедаев не позволяет использовать этот оператор в личных целях, а я же призываю вас перейти на Тёмную сторону Силы.
Но обо всём по порядку. Мой преподаватель программирования на первом курсе университета говорила, что goto в рамках учебного курса применять нельзя, и что она не будет принимать лабораторные работы с ним. И это очень правильно: личинкам кодера нельзя давать в руки такой инструмент, иначе они обмажут им все стены. Чтобы стать хорошим программистом всё-таки нужно сперва научиться писать код без goto.
Проблема начинается в тот момент, когда забывают добавить волшебную фразу «в рамках учебного курса». Людям преподносят goto как абсолютное зло, которое нельзя допускать ни в коем случае. Это превращается в примитивную пропаганду и, судя по количеству приверженцев идеи, так происходит достаточно часто. Да простят меня читатели за то, что я сейчас сворую блок мыслей у Андрея Коняева, но всё дело в том, что пропаганда, какие хорошие практики она бы не пыталась прививать, всё равно остаётся пропагандой. И ничего путного из этого не получится. Пропаганда даёт человеку позицию, но не объясняет её; и на выходе мы получаем кучу людей, которые не способны ответить на вопрос, почему они делают то, что делают. Максимум, что мы услышим, это лозунги вида «goto — это зло», «goto ухудшает читабельность!». Любая попытка разобраться, а действительно ли пострадала, например, читабельность исходников lua из-за того, что там обработка ошибок происходит через goto, будет встречена лишь непониманием и хейтом: «А разве не очевидно? Тут же стоит goto. А это худшая практика из всех. Или ты чё, защитник goto?»
Вам может сейчас показаться, что я утрирую, а на самом деле ненависть к goto обоснована и никакого фанатизма нет, но давайте проанализируем. Вы без труда можете представить человека (а может сами им являетесь), который ненавидит всей душой goto, но при этом любит и обильно использует макросы. Но если вдуматься, негативные эффекты от злоупотребления этими вещами крайне схожи. В обоих случаях от одного использования не случится никакой катастрофы, и даже более того, этим можно сильно облегчить себе жизнь и повысить читабельность в конкретном месте. В обоих случаях, если не локализовать применение, можно нарваться на опасные сайд-эффекты. И в обоих случаях, если пихать повсеместно, проект очень быстро превращается в неуправляемую кашу. Но в первом случае человек борется до последнего против появления в проекте «вредного сорняка», а в другом смотрит сквозь пальцы: не, ну а чё такого? Макросы же не включены в расстрельный список — значит, можно обмазываться.
Переходите на Тёмную сторону Силы и начинайте использовать не хорошие или плохоие практики, а здравый смысл.
Обсудить
#код
Сегодня чатик что-то беснуется по поводу использования goto. Орден джедаев не позволяет использовать этот оператор в личных целях, а я же призываю вас перейти на Тёмную сторону Силы.
Но обо всём по порядку. Мой преподаватель программирования на первом курсе университета говорила, что goto в рамках учебного курса применять нельзя, и что она не будет принимать лабораторные работы с ним. И это очень правильно: личинкам кодера нельзя давать в руки такой инструмент, иначе они обмажут им все стены. Чтобы стать хорошим программистом всё-таки нужно сперва научиться писать код без goto.
Проблема начинается в тот момент, когда забывают добавить волшебную фразу «в рамках учебного курса». Людям преподносят goto как абсолютное зло, которое нельзя допускать ни в коем случае. Это превращается в примитивную пропаганду и, судя по количеству приверженцев идеи, так происходит достаточно часто. Да простят меня читатели за то, что я сейчас сворую блок мыслей у Андрея Коняева, но всё дело в том, что пропаганда, какие хорошие практики она бы не пыталась прививать, всё равно остаётся пропагандой. И ничего путного из этого не получится. Пропаганда даёт человеку позицию, но не объясняет её; и на выходе мы получаем кучу людей, которые не способны ответить на вопрос, почему они делают то, что делают. Максимум, что мы услышим, это лозунги вида «goto — это зло», «goto ухудшает читабельность!». Любая попытка разобраться, а действительно ли пострадала, например, читабельность исходников lua из-за того, что там обработка ошибок происходит через goto, будет встречена лишь непониманием и хейтом: «А разве не очевидно? Тут же стоит goto. А это худшая практика из всех. Или ты чё, защитник goto?»
Вам может сейчас показаться, что я утрирую, а на самом деле ненависть к goto обоснована и никакого фанатизма нет, но давайте проанализируем. Вы без труда можете представить человека (а может сами им являетесь), который ненавидит всей душой goto, но при этом любит и обильно использует макросы. Но если вдуматься, негативные эффекты от злоупотребления этими вещами крайне схожи. В обоих случаях от одного использования не случится никакой катастрофы, и даже более того, этим можно сильно облегчить себе жизнь и повысить читабельность в конкретном месте. В обоих случаях, если не локализовать применение, можно нарваться на опасные сайд-эффекты. И в обоих случаях, если пихать повсеместно, проект очень быстро превращается в неуправляемую кашу. Но в первом случае человек борется до последнего против появления в проекте «вредного сорняка», а в другом смотрит сквозь пальцы: не, ну а чё такого? Макросы же не включены в расстрельный список — значит, можно обмазываться.
Переходите на Тёмную сторону Силы и начинайте использовать не хорошие или плохоие практики, а здравый смысл.
Обсудить
Про бег и уравнения
#код
По моим наблюдениям практически единственное, что у людей остаётся в памяти из школьной программы по математике — это как находить дискриминант квадратного уравнения. Забавно, но при разработке игр это как раз надо крайне редко. Я вот, например, без гугла и не скажу, где там минус и из кого. А вот тригонометрию всякую помню наизусть, потому что нужно каждый день. Но иногда всё-таки дискриминант тоже нужен. Сейчас приведу пример. Собственно, весь дальнейший пост будет просто иллюстрацией типичного случая, когда нужно немножко математики (серьёзно, ничего другого не будет).
Вот потребовалось мне сделать, чтобы человек на бегу останавливался синхронно с анимацией. У нас в аниматоре есть параметр скорости движения. Один метр в секунду — лёгкий шаг, два быстрый, три и более — бег. И так настроено, что ноги двигаются аккурат с этой скоростью. Резко этот параметр дёргать нельзя (будет скачок), надо плавненько. Но и когда моделька на месте стоит, долго крутить ползунки тоже нельзя — будет ногами в воздухе болтать. В идеале надо чтобы всегда скорость движения персонажа совпадала с анимацией. То есть для этого надо начать тормозить чуть заранее фактической остановки.
А двигается персонаж у нас по точкам. От точки к точке по прямым линиям. Если точка последняя в маршруте или там очень резкий поворот, то, очевидно, в этом месте персонаж должен полностью остановиться (и развернуться). Если же поворот не сильный, то можно лишь слегка притормозить, а то и вообще пройти поворот на максимальной скорости.
Вот и получается, что в каждый момент времени у нас есть текущая скорость, расстояние до ближайшей поворотной точки и скорость, которая должна быть на финише. Если персонаж разгоняется до максимальной скорости, скажем, за один метр пути, а тормозит за два, и при этом у нас 100 метров до финиша, то вопросов не возникает. Но как быть, если расстояние до следующей маршрутной точки всего метр? Сколько времени мы можем позволить себе разгоняться на этом пятачке, прежде, чем начать тормозить, чтобы остановиться точно в конце? А может у нас уже ненулевая скорость и вообще нет времени сопли жевать и пора экстренно тормозить? Может быть даже резче обычного (если дверь закрылась прямо перед носом). Ну и, конечно же, надо, чтобы всё эта байда от FPS никак не зависела.
Как быть в этой ситуации? Известно как: составлять систему уравнений и решать, как в школе. Сперва я, правда, вычитаю дистанцию, которую персонажу в любом случае надо пройти, чтобы компенсировать разницу между начальной и конечной скоростями. Так что в начале и в конце манёвра мы имеем одинаковую известную скорость v1. А в конце ускорения (и перед началом торможения) неизвестную скорость v2. Ещё нам известна общая длина пути s, а также a1 и a2, то есть ускорения разгона и торможения соответственно, но неизвестны их длительности t1 и t2.
Записываем это в виде формул равноускоренного движения и понеслась. Я имею привычку набрасывать решения в paint.net, так что весь процесс вы можете наблюдать в шапке поста. В конце остаётся посчитать коэффициенты и найти корни квадратного уравнения.
Вот примерно так у нас теперь персонажи ходят. Всё, правда, несколько сложнее, потому что надо ещё погемороиться с поворотами, но это уже другая история.
Обсудить
#код
По моим наблюдениям практически единственное, что у людей остаётся в памяти из школьной программы по математике — это как находить дискриминант квадратного уравнения. Забавно, но при разработке игр это как раз надо крайне редко. Я вот, например, без гугла и не скажу, где там минус и из кого. А вот тригонометрию всякую помню наизусть, потому что нужно каждый день. Но иногда всё-таки дискриминант тоже нужен. Сейчас приведу пример. Собственно, весь дальнейший пост будет просто иллюстрацией типичного случая, когда нужно немножко математики (серьёзно, ничего другого не будет).
Вот потребовалось мне сделать, чтобы человек на бегу останавливался синхронно с анимацией. У нас в аниматоре есть параметр скорости движения. Один метр в секунду — лёгкий шаг, два быстрый, три и более — бег. И так настроено, что ноги двигаются аккурат с этой скоростью. Резко этот параметр дёргать нельзя (будет скачок), надо плавненько. Но и когда моделька на месте стоит, долго крутить ползунки тоже нельзя — будет ногами в воздухе болтать. В идеале надо чтобы всегда скорость движения персонажа совпадала с анимацией. То есть для этого надо начать тормозить чуть заранее фактической остановки.
А двигается персонаж у нас по точкам. От точки к точке по прямым линиям. Если точка последняя в маршруте или там очень резкий поворот, то, очевидно, в этом месте персонаж должен полностью остановиться (и развернуться). Если же поворот не сильный, то можно лишь слегка притормозить, а то и вообще пройти поворот на максимальной скорости.
Вот и получается, что в каждый момент времени у нас есть текущая скорость, расстояние до ближайшей поворотной точки и скорость, которая должна быть на финише. Если персонаж разгоняется до максимальной скорости, скажем, за один метр пути, а тормозит за два, и при этом у нас 100 метров до финиша, то вопросов не возникает. Но как быть, если расстояние до следующей маршрутной точки всего метр? Сколько времени мы можем позволить себе разгоняться на этом пятачке, прежде, чем начать тормозить, чтобы остановиться точно в конце? А может у нас уже ненулевая скорость и вообще нет времени сопли жевать и пора экстренно тормозить? Может быть даже резче обычного (если дверь закрылась прямо перед носом). Ну и, конечно же, надо, чтобы всё эта байда от FPS никак не зависела.
Как быть в этой ситуации? Известно как: составлять систему уравнений и решать, как в школе. Сперва я, правда, вычитаю дистанцию, которую персонажу в любом случае надо пройти, чтобы компенсировать разницу между начальной и конечной скоростями. Так что в начале и в конце манёвра мы имеем одинаковую известную скорость v1. А в конце ускорения (и перед началом торможения) неизвестную скорость v2. Ещё нам известна общая длина пути s, а также a1 и a2, то есть ускорения разгона и торможения соответственно, но неизвестны их длительности t1 и t2.
Записываем это в виде формул равноускоренного движения и понеслась. Я имею привычку набрасывать решения в paint.net, так что весь процесс вы можете наблюдать в шапке поста. В конце остаётся посчитать коэффициенты и найти корни квадратного уравнения.
Вот примерно так у нас теперь персонажи ходят. Всё, правда, несколько сложнее, потому что надо ещё погемороиться с поворотами, но это уже другая история.
Обсудить
Две истории моей юности про вирусы
#код
Чатик ожил и пристыдил меня за молчание на канале. Что ж, давайте я вам расскажу две истории про вирусы. В первой я буду выступать злостным создателем вредоносного ПО, а в другой, напротив, окажусь доблестным антихакером (блин, количество баек, которые я могу рассказывать в барчиках стремительно сокращается из-за бложека).
Когда мне было лет 14, я уже два года писал примитивные игры на бейсике, делал карты для Half-Life (иногда даже на заказ), и тому подобные вещи. Словом, файлы моего производства распространялись среди знакомых довольно широко и запускались несмотря на угрозы антивируса без подозрений. А ещё мы тогда играли в StarCraft через HyperTerminal (некоторые подписчики, наверняка, таких слов даже не слышали, но это была такая штука, позволяющая соединяться в локальную сеть через телефонные модемы). Само собой, я тоже захотел сделать сетевую игру. После успешного релиза и плейтеста моих крестиков-ноликов на WinSockets, у меня появился мой первый (и последний) коварный план по написанию вирусов. Идея была поистине хитроумной для моих лет. Я собирался написать клиент шахмат, который бы также позволял лазить по файловой системе другого игрока, пока ты якобы размышляешь над ходами. Му-ха-ха! Оценили масштаб вероломства?
От злодеяния меня тогда остановила только внутренняя тяга к свету и уважение личных границ… Сейчас, глядя на код тех крестиков-ноликов, можно подумать, что меня также остановила техническая неспособность написать что-то столь сложное, как шахматы. Но пару лет спустя, уже в университетские годы, когда я написал сетевые «точки» (родственник игры «го»), я всё-таки встроил в клиента возможность лазить по чужой файловой системе. Встроил, сыграл с жертвой, но не воспользовался. Потому что я кайфанул от самого факта «взлома», а шпионить за людьми всё же нехорошо.
Первая история была для разминки, но вторая будет более захватывающей. Родители никогда не воспринимали всерьёз моё увлечение разработкой игр, поскольку не особенно отличали это занятие от собственно игр, долго отговаривали поступать на программиста, но в какой-то момент всё же смирились и даже в середине первого курса подарили мне личный ноутбук. Даже у старшего брата не было отдельного компа, а у меня был. И я с гордостью таскался с этой почти 5-килограммовой махиной в универ. Опять же, некоторые подписчики могут офигеть, но тогда это был нормальный вес для ноутбука и в них, представьте себе, пихали даже CD-ROM.
Так вот. Родители на тот момент хотя и расщедрились, но всё же не особо видели во мне программиста. Всё изменилось, когда однажды родители подхватили вирус. Стандартное по тем временам дерьмо про то, что комп заблокирован, и вы должны куда-то там перевести деньги. Курсор не реагирует, диспетчер задач не вызывается, безопасный режим не помогает. Переустанавливать винду не хочется.
В определённый момент я запихиваю в привод диск какой-то игрушки и слышу, что играет музыка автоплея, хотя самого окна на экране нет. В это мгновение я понимаю, как вирус работает. Я тогда как раз читал книгу форума VBStreets — сборник различных нетривиальных ухищрений с Visual Basic. Среди всего прочего там был пример по созданию дополнительных рабочих столов в Windows. Если кто не знал, такая возможность программно была встроена даже в XP, просто не была протянута в интерфейс. И вот то, как вёл себя вирус, было чертовски похоже на запуск примеров кода по рабочим столам (если тебя переключили на другой стол, ты никак не можешь повлиять на другие).
Что же делаю я? Я сообщаю родителям, что могу написать антивирус, сажусь за ноутбук, пишу за час-другой программу, которая создаёт новый десктоп и открывает там окно-переключалку между столами; создаю файл autoplay и записываю его на болванку. Затем вставляю свежезапечённый диск в заражённую машину и — о чудо — на экране появляется окошко с кнопкой, возвращающей управление компьютером. После чего уже руками нахожу и убиваю остатки вируса. Стоит ли говорить, как после этого выросло уважение ко мне со стороны родителей?
Обсудить
#код
Чатик ожил и пристыдил меня за молчание на канале. Что ж, давайте я вам расскажу две истории про вирусы. В первой я буду выступать злостным создателем вредоносного ПО, а в другой, напротив, окажусь доблестным антихакером (блин, количество баек, которые я могу рассказывать в барчиках стремительно сокращается из-за бложека).
Когда мне было лет 14, я уже два года писал примитивные игры на бейсике, делал карты для Half-Life (иногда даже на заказ), и тому подобные вещи. Словом, файлы моего производства распространялись среди знакомых довольно широко и запускались несмотря на угрозы антивируса без подозрений. А ещё мы тогда играли в StarCraft через HyperTerminal (некоторые подписчики, наверняка, таких слов даже не слышали, но это была такая штука, позволяющая соединяться в локальную сеть через телефонные модемы). Само собой, я тоже захотел сделать сетевую игру. После успешного релиза и плейтеста моих крестиков-ноликов на WinSockets, у меня появился мой первый (и последний) коварный план по написанию вирусов. Идея была поистине хитроумной для моих лет. Я собирался написать клиент шахмат, который бы также позволял лазить по файловой системе другого игрока, пока ты якобы размышляешь над ходами. Му-ха-ха! Оценили масштаб вероломства?
От злодеяния меня тогда остановила только внутренняя тяга к свету и уважение личных границ… Сейчас, глядя на код тех крестиков-ноликов, можно подумать, что меня также остановила техническая неспособность написать что-то столь сложное, как шахматы. Но пару лет спустя, уже в университетские годы, когда я написал сетевые «точки» (родственник игры «го»), я всё-таки встроил в клиента возможность лазить по чужой файловой системе. Встроил, сыграл с жертвой, но не воспользовался. Потому что я кайфанул от самого факта «взлома», а шпионить за людьми всё же нехорошо.
Первая история была для разминки, но вторая будет более захватывающей. Родители никогда не воспринимали всерьёз моё увлечение разработкой игр, поскольку не особенно отличали это занятие от собственно игр, долго отговаривали поступать на программиста, но в какой-то момент всё же смирились и даже в середине первого курса подарили мне личный ноутбук. Даже у старшего брата не было отдельного компа, а у меня был. И я с гордостью таскался с этой почти 5-килограммовой махиной в универ. Опять же, некоторые подписчики могут офигеть, но тогда это был нормальный вес для ноутбука и в них, представьте себе, пихали даже CD-ROM.
Так вот. Родители на тот момент хотя и расщедрились, но всё же не особо видели во мне программиста. Всё изменилось, когда однажды родители подхватили вирус. Стандартное по тем временам дерьмо про то, что комп заблокирован, и вы должны куда-то там перевести деньги. Курсор не реагирует, диспетчер задач не вызывается, безопасный режим не помогает. Переустанавливать винду не хочется.
В определённый момент я запихиваю в привод диск какой-то игрушки и слышу, что играет музыка автоплея, хотя самого окна на экране нет. В это мгновение я понимаю, как вирус работает. Я тогда как раз читал книгу форума VBStreets — сборник различных нетривиальных ухищрений с Visual Basic. Среди всего прочего там был пример по созданию дополнительных рабочих столов в Windows. Если кто не знал, такая возможность программно была встроена даже в XP, просто не была протянута в интерфейс. И вот то, как вёл себя вирус, было чертовски похоже на запуск примеров кода по рабочим столам (если тебя переключили на другой стол, ты никак не можешь повлиять на другие).
Что же делаю я? Я сообщаю родителям, что могу написать антивирус, сажусь за ноутбук, пишу за час-другой программу, которая создаёт новый десктоп и открывает там окно-переключалку между столами; создаю файл autoplay и записываю его на болванку. Затем вставляю свежезапечённый диск в заражённую машину и — о чудо — на экране появляется окошко с кнопкой, возвращающей управление компьютером. После чего уже руками нахожу и убиваю остатки вируса. Стоит ли говорить, как после этого выросло уважение ко мне со стороны родителей?
Обсудить
Переобувания Блаба
#код
Что-то нашло настроение поразмышлять о том, как часто я менял мнение на программерском поприще. Такое на самом деле случается нечасто, потому что мы все живём в пузырях из собственного опыта. Первый инструмент или подход, который хорошо себя зарекомендовал, формирует в нас эффект утёнка. Затем мы этим самым утёнком какое-то время восторженно забиваем все гвозди в округе. И вот спустя десятки птичьих, натянутых на разнообразные модели Земли, когда по-хорошему стоило бы задуматься об этичности происходящего, у нас уже достаточно травматичного опыта, чтобы спутать стокгольмский синдром с любовью.
Когда твоя позиция сформулирована и озвучена коллегам возле кулера, когда по теме написаны посты и твиты, бывает уже очень трудно выйти на следующий виток спирали понимания и начать декларировать противоположное своим же вчерашним взглядам. Самая главная моя ошибка прошлого — это конечно то, как упорно я в юности не признавал, что Visual Basic плохой язык (если вам резануло ухо слово «плохой», то переформулирую: неподходящий для моих задач). Осознание этого было длительным и болезненным. Я топал ножкой и капризничал, лишь бы не учить С++. Но сегодня я фанат крестов. Я добрался сюда через пару витков .Net, но что-то мне подсказывает, что на этом моя личная спираль обрывается. Конечно, сейчас я привязан к С++ во многом стокгольмским синдромом, но как мне кажется, у меня есть и рациональные аргументы, почему оглядываясь назад через 10 лет я не сочту это ошибкой.
Другие примеры изменения моего мнения не столь драматичны, но тоже случались. Например, я помню, как 10 лет назад вкручивал локализацию в игру для Wii. И я тогда на полном серьёзе втирал, что для геймдева строки лучше хранить в 8-битных кодировках с переключением кодовых страниц (Windows-1251, 1252 — вот это вот всё). Мне тогда представлялось важным иметь доступ к нужному символу по смещению в строке, а необходимость помнить кодировку совсем не смущала и не казалась геморройной. Я проникся силой юникода уже буквально через год, но стыдно до сих пор.
А вот если говорить о вечном, то помнится в известном холиваре порядка байт я раньше был на стороне тупоконечников. Превалировало во мне что-то такое дикое, что-то из мира человеческого письма. А теперь я как будто больше проникся машинной красотой остроконечности. Следуя этой же логике я, по идее, должен был стать и фанатом column-мажоров из OpenGL, ведь это так математично. Но здесь я почему-то пропутешествовал на один виток дальше и всё-таки остановился на том, что они (вместе со всей математикой) наркоманы и курильщики, а нормальные люди матрицы перемножают слева направо.
Это далеко не самый интересный для чтения мой пост получился: всем, в общем-то, плевать, какие конкретно метаморфозы проходило чужое мнение. Но как мне кажется, это довольно занятная тема, чтобы порассуждать и проанализировать свои взгляды. А вы помните, как кардинально меняли своё мнение по холиварным темам?
#код
Что-то нашло настроение поразмышлять о том, как часто я менял мнение на программерском поприще. Такое на самом деле случается нечасто, потому что мы все живём в пузырях из собственного опыта. Первый инструмент или подход, который хорошо себя зарекомендовал, формирует в нас эффект утёнка. Затем мы этим самым утёнком какое-то время восторженно забиваем все гвозди в округе. И вот спустя десятки птичьих, натянутых на разнообразные модели Земли, когда по-хорошему стоило бы задуматься об этичности происходящего, у нас уже достаточно травматичного опыта, чтобы спутать стокгольмский синдром с любовью.
Когда твоя позиция сформулирована и озвучена коллегам возле кулера, когда по теме написаны посты и твиты, бывает уже очень трудно выйти на следующий виток спирали понимания и начать декларировать противоположное своим же вчерашним взглядам. Самая главная моя ошибка прошлого — это конечно то, как упорно я в юности не признавал, что Visual Basic плохой язык (если вам резануло ухо слово «плохой», то переформулирую: неподходящий для моих задач). Осознание этого было длительным и болезненным. Я топал ножкой и капризничал, лишь бы не учить С++. Но сегодня я фанат крестов. Я добрался сюда через пару витков .Net, но что-то мне подсказывает, что на этом моя личная спираль обрывается. Конечно, сейчас я привязан к С++ во многом стокгольмским синдромом, но как мне кажется, у меня есть и рациональные аргументы, почему оглядываясь назад через 10 лет я не сочту это ошибкой.
Другие примеры изменения моего мнения не столь драматичны, но тоже случались. Например, я помню, как 10 лет назад вкручивал локализацию в игру для Wii. И я тогда на полном серьёзе втирал, что для геймдева строки лучше хранить в 8-битных кодировках с переключением кодовых страниц (Windows-1251, 1252 — вот это вот всё). Мне тогда представлялось важным иметь доступ к нужному символу по смещению в строке, а необходимость помнить кодировку совсем не смущала и не казалась геморройной. Я проникся силой юникода уже буквально через год, но стыдно до сих пор.
А вот если говорить о вечном, то помнится в известном холиваре порядка байт я раньше был на стороне тупоконечников. Превалировало во мне что-то такое дикое, что-то из мира человеческого письма. А теперь я как будто больше проникся машинной красотой остроконечности. Следуя этой же логике я, по идее, должен был стать и фанатом column-мажоров из OpenGL, ведь это так математично. Но здесь я почему-то пропутешествовал на один виток дальше и всё-таки остановился на том, что они (вместе со всей математикой) наркоманы и курильщики, а нормальные люди матрицы перемножают слева направо.
Это далеко не самый интересный для чтения мой пост получился: всем, в общем-то, плевать, какие конкретно метаморфозы проходило чужое мнение. Но как мне кажется, это довольно занятная тема, чтобы порассуждать и проанализировать свои взгляды. А вы помните, как кардинально меняли своё мнение по холиварным темам?
Логарифм и резинки
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.
Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.
Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.
Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?
На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь
Можно думать об этом числе, как о степени агрессивности нашего In в нашем FPS-независимом сглаживании (аналог InCubic, InQuad и т.д.). Формула продолжит работать.
Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:
По-моему, симпатично получилось. А вы что думаете?
#код
Как-то в одном из чатов обронили фразу: «а когда вам последний раз был нужен логарифм?». Забавно, но мне он потребовался буквально на следующий день. Это ещё один маленький пост о том, какого рода математика нужна геймплейному программисту в повседневной жизни.
Часто нам нужно сглаживать какие-то процессы, у которых нет чёткого конца или он меняется во времени. Ну, например, у нас один объект — пусть это будет ручной дракончик — движется на воображаемой резинке за другим объектом, который тоже постоянно в движении: скажем, это будет персонаж игрока. Если игрок оказался далеко от дракончика (например, телепортировался), то дракончик сперва летит к нему очень быстро, но при приближении постепенно замедляется, чтобы это смотрелось хорошо.
Новички обычно просто домножают скорость дракончика на расстояние до игрока. Это простое решение, но ужасно плохое, поскольку время, за которое дракончик долетит до игрока, будет напрямую зависеть от FPS. При низком фпс он будет добираться до цели быстро, а при большом топтаться на месте неожиданно долго. А если FPS скачет, то и вовсе придётся лицезреть нечто рывкообразное.
Юнитологи классом повыше обычно используют небезызвестную функцию SmoothDamp. Внутри там скрывается мудрённое решение из книги Game Programming Gems 4. Вот только нам приходится где-то хранить текущую скорость для каждого процесса сглаживания, да и в целом довольно страшно выглядит. Нельзя ли как-то попроще сделать и без лишних переменных в местах вызова?
На самом деле если мы задумаемся, как будет выглядеть FPS-независимый способ приближения со сглаживанием, то быстро поймём, что нам надо проходить одинаковую долю расстояния за одинаковое время. Например, за первую секунду проходим половину пути, за вторую секунду половину от половины, то есть остаётся четверть, затем 1/8, 1/16 и так далее. И никогда мы по настоящему не достигаем цели, но нам это и не надо. При таком движении неважно в какой точке этого процесса мы оказались (на первой секунде, второй и т.п.), мы всегда знаем, как рассчитать движение дальше. От пути всегда остаётся лишь
1 / 2^tА значит пройденное расстояние от времени вычисляется по формуле:
1 - 1 / 2^tДвойка здесь всего лишь указатель на то, что в качестве одинаковых промежутков мы выбрали половину расстояния. Мы можем подставить туда 3, чтобы получить треть, или любое другое число больше 1.
Но для полного счастья нам не хватает настройки времени, за которое дракончик будет визуально догонять персонажа из любой точки. Конечно, полностью он догнать не может, но нам хватит преодоления, скажем, 98% пути:
1 - 1 / base^t = 0,98Ну вот и всё. Теперь мы можем инициализировать этими параметрами нашу бесконечную резинку-пружинку, после чего ей можно будет скармливать deltaTime, а в ответ получать LerpK. Таким образом получилось простое FPS-независимое сглаживание для всего, что можно лерпать. Финальный класс можно видеть на скриншоте.
base^t = 1 / (1 - 0,98)
t = log(1 / (1 - 0,98), base)
По-моему, симпатично получилось. А вы что думаете?
Поправочка!
#код
Ох, что-то я написал этот пост и тут же понял, что лишнего наворотил. Движение, при котором мы за равные промежутки проходим половину, затем половину от остатка и так далее — это фактически тоже самое движение, когда мы за равные промежутки проходим треть, затем треть от остатка и так далее. Это просто свойство перевёрнутой экспоненты самой по себе. И неважно какое основание. А чтобы управлять агрессивностью In-прыжка, достаточно слегка менять threshold-порог. Чем выше выставить процент порога, тем агрессивнее будет прыжок в начале.
Правду говорят, что если хочешь в чём-то разобраться сам, то расскажи это другому. Вот и здесь так получилось.
#код
Ох, что-то я написал этот пост и тут же понял, что лишнего наворотил. Движение, при котором мы за равные промежутки проходим половину, затем половину от остатка и так далее — это фактически тоже самое движение, когда мы за равные промежутки проходим треть, затем треть от остатка и так далее. Это просто свойство перевёрнутой экспоненты самой по себе. И неважно какое основание. А чтобы управлять агрессивностью In-прыжка, достаточно слегка менять threshold-порог. Чем выше выставить процент порога, тем агрессивнее будет прыжок в начале.
Правду говорят, что если хочешь в чём-то разобраться сам, то расскажи это другому. Вот и здесь так получилось.
public struct EndlessSpring
{
private float TimeScale;
// time is amount of time that needeed to pass
// threshold-share of the distance (never pass 100%)
public EndlessSpring(float time, float threashold = 0.98f)
{
var expectedValue = 1 / (1 - threashold);
this.TimeScale = Mathf.Log(expectedValue, 2) / time;
}
public float GetLerpK(float deltaTime)
{
return 1 - 1 / Mathf.Pow(2, deltaTime * TimeScale);
}
}
Вы точно понимаете корутины?
#код
Много-много лет назад, когда я первый раз пришёл на настоящую работу программировать за настоящие деньги, меня научили корутинам. Ну, не то, чтобы прям научили. Просто там был проект с корутинами, и мне волей-неволей пришлось вникнуть, что это за yield такой непонятный. Новый мир, зазиявший передо мной, в корне перевернул моё тогдашнее представление о том, как можно писать геймплейный код. Я и до сих пор это воспринимаю, как одну из важнейших ментальных ступенек для программиста.
Речь сейчас идёт о тех диких временах, когда воевали с луками и стрелами против боевых машин самописными движками на плюсах. Я тогда успел немного походить из конторы в контору, но везде обнаруживал несчастных грустных людей, не вкусивших плодов корутин. Многие и слов таких не знали. И я нёс знания в простой народ. И жизнь людская преображалась на этих проектах.
Но эти времена давно прошли. Теперь каждый знает, что такое StartCoroutine() в Unity. Все к ним привыкли, и никого ими не удивишь; но я заметил, что самое крутое назначение корутин все ещё ускользает от многих в наше время.
Новички считают, что это просто удобный способ делать задержки. Каждый второй, делающий тестовое про самолётик в DarkCrystalGames, делал таймаут выстрелам через запуск корутины и WaitForSeconds(). Мой внутренний эстет при чтении такого кода всегда бьёт себя по лицу, но это вкусовщина. А проблема в том, что эти люди, как правило, только таким использованием и ограничиваются. Ничего более интересного, чем задержки, на корутинах и не пишут. Какое неуважение.
Но этого поста не было бы, если бы проблемы с пониманием возникали только у новичков. Опытные сеньористые ветераны порой думают о корутинах, как о неком легковесном способе организации мультипоточки.
Нет, нет и ещё раз нет! Мультипоточка тут вообще ни при чём!
Недопонимание происходит из-за того, что к одной и той же вещи можно прийти с двух сторон. Можно с одной стороны постепенно облегчать мультизадачность и повышать безопасность и прийти от потоков к так называемым Green Threads. А можно вообще идти с другой стороны, пытаясь в однопоточном приложении улучшить читабельность колбеков и стейт-машин, и прийти внезапно к тому же самому. В этом случае результат скорее назовут корутинами. Разница между получившимися вещами с точки зрения функционала будет весьма условна, но отличается мотивация и назначение. Если вы познакомились с корутинами не с той стороны, то эта статья для вас.
#код
Много-много лет назад, когда я первый раз пришёл на настоящую работу программировать за настоящие деньги, меня научили корутинам. Ну, не то, чтобы прям научили. Просто там был проект с корутинами, и мне волей-неволей пришлось вникнуть, что это за yield такой непонятный. Новый мир, зазиявший передо мной, в корне перевернул моё тогдашнее представление о том, как можно писать геймплейный код. Я и до сих пор это воспринимаю, как одну из важнейших ментальных ступенек для программиста.
Речь сейчас идёт о тех диких временах, когда воевали с луками и стрелами против боевых машин самописными движками на плюсах. Я тогда успел немного походить из конторы в контору, но везде обнаруживал несчастных грустных людей, не вкусивших плодов корутин. Многие и слов таких не знали. И я нёс знания в простой народ. И жизнь людская преображалась на этих проектах.
Но эти времена давно прошли. Теперь каждый знает, что такое StartCoroutine() в Unity. Все к ним привыкли, и никого ими не удивишь; но я заметил, что самое крутое назначение корутин все ещё ускользает от многих в наше время.
Новички считают, что это просто удобный способ делать задержки. Каждый второй, делающий тестовое про самолётик в DarkCrystalGames, делал таймаут выстрелам через запуск корутины и WaitForSeconds(). Мой внутренний эстет при чтении такого кода всегда бьёт себя по лицу, но это вкусовщина. А проблема в том, что эти люди, как правило, только таким использованием и ограничиваются. Ничего более интересного, чем задержки, на корутинах и не пишут. Какое неуважение.
Но этого поста не было бы, если бы проблемы с пониманием возникали только у новичков. Опытные сеньористые ветераны порой думают о корутинах, как о неком легковесном способе организации мультипоточки.
Нет, нет и ещё раз нет! Мультипоточка тут вообще ни при чём!
Недопонимание происходит из-за того, что к одной и той же вещи можно прийти с двух сторон. Можно с одной стороны постепенно облегчать мультизадачность и повышать безопасность и прийти от потоков к так называемым Green Threads. А можно вообще идти с другой стороны, пытаясь в однопоточном приложении улучшить читабельность колбеков и стейт-машин, и прийти внезапно к тому же самому. В этом случае результат скорее назовут корутинами. Разница между получившимися вещами с точки зрения функционала будет весьма условна, но отличается мотивация и назначение. Если вы познакомились с корутинами не с той стороны, то эта статья для вас.