Что такое «Инверсная кинематика»?

Задачей инверсной кинематики является поиск такого набора конфигураций сочленений, который обеспечил бы максимально мягкое, быстрое и точное движение к заданным точкам. Однако, множество существующих ныне методов страдают от таких недостатков как высокая вычислительная сложность и неестественность результирующих поз. В этой статье описан новый (вероятно, на момент написания статьи — 2010 г.) эвристический метод под названием «Метод прямого и обратного следования» ( Forward and Backward Reaching Inverse Kinematics, далее просто FABRIK),
FABRIK избегает использования вращений и матриц в пользу непосредственного получения точки на прямой. Благораря этому, дело обходится всего несколькими итерациями, имеет низкую стоимость вычислений и визуально естественную позу в результате. FABRIK так-же без проблем справляется с наложением ограничений а так-же использованием нескольких цепей и/или конечных точек. Именно об этом методе этот пост.

В данном посте я хочу рассказать о простом алгоритме предложения на основании сделанных ранее выборов. Для этого, прежде всего, поставим две задачи:

1. Выбрать случайное значение из массива
2. Выбрать случайное значение из массива на основании веса значений

Наверняка многие заметят, что для решения первой задачи существуют готовые функции во многих ЯП. Однако, я буду придумывать велосипед решать её иначе, для постепенного подхода к решению второй задачи.

Для решения я буду использовать псевдокод, чем-то похожий на Javascript. Потому, мой метод random() будет возвращать значение от 0 до 1.

Боб Найстром, программист, проработавший восемь лет в компании Electronic Arts, закончил работу над книгой «Game Programming Patterns». Она доступна бесплатно на сайте gameprogrammingpatterns.com. Писать книгу Боб Найстром начал четыре года назад. Большинство книг, посвящённых программированию игр, говорит он во введении, либо подробно раскрывают какой-то из аспектов создания игры — физический движок, графику, искусственный интеллект, либо описывают процесс создания игры в определённом жанре от начала до конца. Ему очень не хватало книги, рассказывающей о решении типовых задач, возникающих перед программистом, книги достаточно универсальной, не привязанной к жанрам или конкретным подсистемам игр. И поэтому он решил написать такую книгу сам.

В этом посте я расскажу, как создать в мобильном приложении управление c помощью рисования траектории. Такое управление используется в Harbor Master и FlightControl: игрок пальцем рисует линию, по которой движутся корабли и самолеты. Для моей игры St.Val потребовалась аналогичная механика. Как я её делал и с чем пришлось столкнуться — читайте ниже.



Пара слов об игре. В St.Val основная цель соединять сердца по цвету с помощью стрел. Задача игрока: построить траекторию полета стрелы так, чтобы она соединяла сердца в полете. Игра создавалась на базе Cocos2D 2.1 под iOS, ниже видео игровой механики.

Основные задачи

Для создания управления нужно решить три задачи:

1. Считать координаты
2. Сгладить и аппроксимировать их
3. Запустить по ним стрелу

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

Под катом решение этих задач и ссылка на демонстрационный проект.

Продолжаем разговор от 07.04.2014 (Particles System в моделировании толпы).

В этой части добавляю:

1. медленные персонажи (это будут крупные стрЕлки)
2. огибание в пути медленных стрелок быстрыми
3. взрывы (с разбрасыванием тел)

Недавно я вырос из лютого эникея в очень большой компании, до скромного сисадмина надзирающего за сетью в 10 ПК. И, как очень ленивый сисадмин, столкнулся с задачами по автоматизации своей деятельности. Полгода назад я еще не знал, что в командной строке Windows есть конвейеры. Это стало первым шокирующим открытием. И я пошел дальше, и выяснилось, что там, где я раньше писал утилитки на C#, Delphi или громоздкие скрипты с вложенными циклами, можно было обойтись парой команд forfiles или robocopy.
Не буду рассказывать о банальностях, типа о перечислении файлов и папок клавишей Tab. Под хабракатом расскажу о том, что может быть полезно начинающим админам и эникеям.

Видео про 8 способов противостояния формуле нужды оказалось неожиданно популярным, набрав 8,000 просмотров за два дня. Мы решили продолжить тему.

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

Мы отобрали 10 самых любопытных, на наш взгляд, вопросов в этой теме и снова заперли в студии Дмитрия Коткина, руководителя Санкт-Петербургской школы переговорщиков ШиП и нашего хорошего друга, чтобы он рассказал, что конкретно делать:



10 реальных ситуаций, которые удалось осветить — под катом:

многие идеи, которые приходят ко мне, уже кто-то реализовал или скоро реализует (цитата с просторов интернета)

В далеком 2001 году меня, любителя стратегий реального времени, поразила игра “Казаки”. Поразила ГИГАНТСКИМИ толпами, бродящими по карте. Поразило то, что эти толпы довольно резво бегали на тогдашних маломощных компьютерах. Но в то время я работал на скорой помощи, был далек от программирования, потому восхищением дело это тогда и ограничилось.

Уже в наше время захотелось сделать игрушку с примерно подобным количеством подвижных юнитов — чтоб “эпик” просто зашкаливал(!). И чтоб эти юниты не просто двигались, а двигались внешне(!) осмысленно. И чтоб (главное), все это великолепие работало на слабеньких мобильных платформах.

Встал вопрос — как? С графикой вопросов нет — на любой современной платформе есть разные по-произодительности графические библиотеки, которые займутся выводом толпы на экраны. Главный вопрос — как программно реализовать осмысленное (ну или бессмысленное) нечто, что игроком воспринималось бы однозначно — это подчиняющаяся каким-то стимулам толпа, а не просто набор мельтешащих фигурок.

Уверен, существует куча рекомендаций, литературы, и даже реализаций. Но меня интересовало что-то “простенькое”, что можно применить в незатейливой игрушке для “мобилы” и собрать “на коленке”. Т.е. дешево и сердито, а главное — понятно для меня(!).

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

Однако я верю в то, что их можно избежать, если знать в какие ловушки можно попасть и как из них выбираться. Возможно эта вера — очередная ловушка.

Речь сегодня пойдёт о генерации изображений с картой расстояний (Signed Distance Field). Данный вид изображений примечателен тем, что фактически позволяет получить «векторную» графику на видеоускорителе, причём даром. Одной из первых данный метод растеризации предложила компания Valve в игре Team Fortress 2 для масштабируемых декалей в 2007 году, но до сих пор он не пользуется особой популярностью, хотя позволяет рендерить прекрасного качества шрифты, используя текстуру всего 256х256 точек. Данный метод прекрасно подходит для современных экранов высокой чёткости и позволяет серьёзно сэкономить на текстурах в играх, он не требователен к железу и прекрасно работает на смартфонах.



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

Как же создавать такие изображения? Очень просто, ImageMagick позволяет сделать это одной командой:

convert in.png -filter Jinc -resize 400% -threshold 30% \( +clone -negate -morphology Distance Euclidean -level 50%,-50% \) -morphology Distance Euclidean -compose Plus -composite -level 45%,55% -resize 25% out.png

На этом можно было бы поставить точку, но так полноценного топика не получится. Что ж, под катом — описание быстрого алгоритма расчёта SDF, пример на C++ и немного шейдеров для OpenGL.

Mozilla выпустила инструмент, который наверняка многим облегчит жизнь: это фреймворк RR под Linux для записи и последующего воспроизведения хода выполнения программы. Воспроизведение происходит абсолютно детерминированно, то есть с теми же регистрами и адресами памяти — и неизменно с тем же сбоем (если он был). Другими словами, можно бесконечно гонять тесты, а как только появится баг — не спеша его изучить в офлайне, прокрутив запись сколько угодно раз. Записываются все деревья процессов и потоков.

RR создан для точного воспроизведения багов, которые проявляют себя непредсказуемо. В таких случаях при отладке стандартными средствами нет смысла запускать программу снова: не факт, что баг опять проявится. Эта проблема постоянно портит жизнь разработчикам. Вот почему в Mozilla решили создать такой фреймворк.

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

А пока вы не заглянули под кат, задайтесь вопросом о том, как связан наш с вами календарь и настольные игры. (Чур не гуглить!)

Привет Хабр,
Я продолжаю переводить статью Рафаэля Чендлера о приемах, которые помогут проработать персонажей в ваших играх более детально.
Первая часть статьи поведала нам о методе использования карт Таро для составления прошлого и будущего персонажей, что во многом определит их судьбу.

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

Продолжение под катом:

Для написания статей на Хабр я пользуюсь текстовым редактором Sublime Text. Почему это хороший редактор на Хабре уже много раз писали (например тут). Есть, однако, при написании статьи момент, когда её нужно переносить для публикации на Хабр, ну, знаете: Хабр->Добавить пост->Название, хабы, текст (Ctrl+C/Ctrl+V), метки, предпосмотр. В этот момент оказывается, что как-то текст с картинками сверстался на Хабре некрасиво, начинаются правки. Править в браузере? Неудобно и небезопасно. Править в Sublime и постоянно копипастить? Неудобно и надоедает.

Поэтому я сделал для себя небольшой плагин к Sublime, который умеет взаимодействовать с Хромом и Хабром, перекидывая по хоткею в Sublime написанный текст в редактор на странице создания нового топика с автоматическим нажиманием кнопки «Предпросмотр». Это позволяет писать статью в Sublime и в одно нажатие видеть результат её отображения на Хабре.

Под катом мы научимся писать плагины к Sublime и разберёмся как из питоновского кода взаимодействовать с Хромом, используя его протокол удалённой отладки. Полный код плагина на GitHub прилагается.

Большинство современных веб-сайтов являются динамическими. Их страницы формируются на стороне сервера, а затем отображаются в браузере пользователя. Многие такие сайты функционируют на основе простых и удобных CMS (систем управления контентом) в состав которых, как правило, входит WYSIWYG-редактор, простой и интуитивно понятный. При всей очевидной простоте при работе с динамическими сайтами возникает целый ряд неудобств.

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

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

Первая часть статьи ознакомит вас с ассоциативным подходом с использованием карт Таро.

Когда-то я жила беззаботно и думала, что переводчику игр ничего не нужно, кроме хорошего знания языков, фантазии и любви к своему делу. Но потом я выросла, устроилась на работу и узнала, что перевод игр на консоли — это минное поле, ошибиться на котором ты не имеешь права. Чем же может быть омрачена жизнь специалиста по локализации, который работает с консольными проектами? Ему приходится знать все о том, о чем многие даже не подозревают: о требованиях first parties (или производителей консолей) Microsoft, Nintendo и Sony. Ты углубляешься в их инструкции, учишь, разбираешься в тонкостях перевода для той или иной платформы… и вот ты уже сам не замечаешь, как начинаешь поправлять своих друзей, когда они называют контроллер геймпадом, и бесишься от заголовков типа «PlayStation 4 — консоль нового поколения».

Divine Elemente

Один из самых потрясающих проектов, которые я встречал за последнее время. Плагин Divine Elemente дает возможность дизайнерам создавать WordPress темы без каких либо навыков фронт/бэк-енда. К сожалению у меня не было возможности поработать с ним. Он доступен только для Windows. Для того что бы все работало необходимо создавать макет в соответствии со встроенным blueprint — это некий Bootstrap, Boilerplate или даже набор инструкций по наименовании слоев и групп. Разработчики обещают множество всего хорошего, в том числе: SEO friendly, валидную и семантичную верстку, читаемый код. Впечатляет!

Очень часто в статьях про Хаскель сплошь и рядом встречаются функторы и особенно монады.
Так часто, что порой не реже встречаются комментарии «сколько можно про какие-то новые монады» и «пишите о чём-либо полезном».
На мой взгляд это свидетельствует о том, что люди порой не понимают зачем же нужны все эти функторы и монады.

Это статья попытка показать, что сила функциональных языков и в первую очередь Хаскеля — это в том числе и силе функторов и монад.

Не припоминаю я на Хабре статьи про атаки на банки. Никакой теории и фантазии, реальная практика и скрины

Немного введения. Не так давно я выступал на VI уральском форуме по информационной безопасности банков, где много внимания было уделено новому стандарту ЦБ РФ об обеспечении информационной безопасности банковских систем, на эту же тему был и мой доклад. В стандарте выделено 7 этапов жизни банковских систем (ПО), от написания ТЗ до снятия с эксплуатации. И схема моего доклада была следующей — рассказать некоторые реальные истории атак, проецируя их на новый стандарт от ЦБ, и показывая, как бы он (стандарт) мог «сломать» эти вектора, если бы банки его применяли. А на Хабре я опубликую пересказ своего выступления (осторожно, картинки!). Ах и да — вся информация предоставлена исключительно с целью ознакомления и ни в коем случае не является руководством к действию.