[Перевод] Объяснение нейронных машин Тьюринга

Восстановление файлов после трояна-шифровальщика

Что нас ждет в версии ReactOS 0.4.5?

Экстрасенсорная способность в дизайне, которую я утратил

[Перевод] Как три школьника взломали исходный код Final Fantasy V, чтобы локализовать её

Быстрое вычисление факториала — PrimeSwing

Security Week 17: DoublePulsar вырвался на волю, в сотне тысяч Linksys нашли дыры, SMSVova изгнан из Google Play

Пока безопасники охали и ахали над архивом хакерских инструментов АНБ, который слили в Сеть ShadowBrokers, серьезные дяди с темной стороны запустили новые госэксплойты в дело. И, как выяснилось, не только эксплойты – поверхностное сканирование Интернета выявило большое число машин, зараженных свежеслитым бэкдором DoublePulsar.

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

Для заражения используются эксплойты для уязвимостей в Windows SMB Server. Microsoft еще в марте запатчила эти дыры в обновлении MS17-010. Но давайте-ка вспомним похожую историю девятилетней давности, когда обновление MS08-067 прикрыло дыру, через которую шастал червь Conflicker. И знаете что? Прошло почти десять лет, а до сих пор можно найти уязвимые для него Windows-серверы. Потому, что «работает – не трогай». Вот и не трогают, и трогать не будут.

Дэн Тентлер, основатель Phobos Group, решил просканировать Интернет на предмет уязвимостей из утечки. Конечно, он нашел миллионы дырявых серверов – патч всего-то полтора месяца назад вышел, админы суетиться не любят. А потом «опросил» найденные системы, стукнувшись в порт 445. Изнутри 65 тысяч машин (около 3,1% из уязвимых) откликнулся живой DoublePulsar. ¯\_(ツ)_/¯

Вряд ли АНБ так широко раскинуло свои щупальца. Скорее, это результат бенефиса ShadowBrokers. Они выложили готовый киберарсенал, простой для использования и очень опасный, и результат не заставил себя долго ждать. И даже то, что на новых версиях Windows DoublePulsar не работает, не особо вдохновляет. Ящик Пандоры открыт, число скомпрометированных серверов в Интернете будет множиться. Накатывайте патчи, господа админы!

20 моделей роутеров Linksys содержат уязвимости
Помните Linksys? В стародавние времена так звались сетевые устройства, которые Cisco делала для простых SOHO-пользователей. Четыре года назад их купили Belkin, известные своими USB-кабелями и сетевыми фильтрами. Впрочем, это ничего особо не изменило, под маркой Linksys продолжают выходить вполне приличные домашние свитчи и роутеры. К чему это я? А, IOActive нашли в них кучу дыр.

Новость. Исследование. Уязвимости в сетевых устройствах этого класса находят часто. В этот раз IOActive прошлась по свежим моделям Linksys, в которых обнаружила десяток уязвимостей. Дыры позволяют удаленно «вешать» и перезагружать устройство, сливать с него прошивку (да кому она нужна?), и красть WPS PIN-код, что уже более интересно. И еще более интересна возможность организовать бэкдор в роутере, чтобы выполнять любые команды с root-правами. Правда, для этого надо сначала аутентифицироваться на устройстве.

IOActive назвала уязвимые модели – это новые девайсы серий EA и WRT, общим числом 20 штук. Просканировав Интернет с помощью любимого безопасниками Shodun, они нашли 7000 уязвимых роутеров. Столь скромная цифра их не устроила, поэтому аналитики IOActive умозрительно посчитали количество устройств, спрятанных за файрволами – и насчитали СТО ТЫЩ! 70% из них работают в США, 10% в Канаде, а вот у нас их почти нет – меньше 1%. Даже Чили обогнала нас по использованию уязвимых Linksys, как теперь жить?

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

Троянец-шпион SMSVova удален из Google Play
Новость. В Google Play еще недавно было отличное приложение System Update для поддержания операционки в обновленном состоянии. Вроде как бы ставишь, и оно твой Android патчит, патчит, патчит без устали. Это же решение всех проблем с мобильными уязвимостями. Не будем ждать милостей от вендора, возьмем их сами из Google Play! И таки вы будете смеяться, но несколько миллионов пользователей на это купились.

При запуске System Update показывало грустное сообщение, что сервис остановлен, и якобы закрывалось. На самом деле спрятанный в его недрах троянец-шпион SMSVova (снова эти русские!) продолжал работать и слал куда-то SMS-ками все данные о местоположении пользователя. Кроме того, SMSVova умеет получать команды извне, тоже по SMS.

Полезная утилитка гужевалась в Google Play с 2014 года, VirusTotal не детектилась, а все усиливающиеся проверки со стороны Google обходила просто – ее не обновляли, и повода проверять не было. Теперь-то, конечно, из магазина System Update убран. Хватит ему за нами следить!

Древности

«GoodBye-839»

Резидентный неопасный вирус, стандартно поражает загружаемые в память COM-, EXE- и OVL-файлы. В воскресенье исполняет мелодию «Goodbye America» рок-группы «Наутилус Помпилиус». Перехватывает int 1Ch, 21h.

Цитата по книге «Компьютерные вирусы в MS-DOS» Евгения Касперского. 1992 год. Страницa 68.

Disclaimer: Данная колонка отражает лишь частное мнение ее автора. Оно может совпадать с позицией компании «Лаборатория Касперского», а может и не совпадать. Тут уж как повезет.

Let's block ads! (Why?)

Как мы на FPGA AES ускоряли: разработка драйвера

Что Mobius 2017 рассказал о мобильной разработке

Слушая доклады на IT-конференции, можно не только узнать много конкретной информации из каждого, но и увидеть более общую картину: вместе доклады говорят о том, чем в данный момент живёт и интересуется индустрия.

В Петербурге на прошлой неделе состоялся Mobius 2017 — как прошло мероприятие, и какие общие выводы о мобильной разработке в 2017-м можно сделать по рассказанному там?

У конференции было сразу несколько отличий от прошлогодней. Во-первых, она впервые проходила в течение двух дней, а не одного. Цель «ровно вдвое больше докладов» мы при этом не ставили: предпочли этому длинные перерывы, помогавшие как следует попытать вопросами спикеров после их выступлений, и зрители активно пользовались этой возможностью.

Во-вторых, в этот раз оказался неожиданно большим географический разброс аудитории. Если немного упростить, то только треть зрителей на конференции была непосредственно из Петербурга, ещё треть — из Москвы, а оставшаяся треть — из регионов. И неожиданной деталью стало присутствие нескольких человек из Японии, решивших совместить посещение России с посещением конференции (поскольку из трёх параллельно идущих докладов почти всегда один был англоязычным, даже без знания русского они не скучали).

DIライブラリのToothpick作者のセッションにきた。 #mobiusconfhttp://pic.twitter.com/Bd32GzGaRY

— zaki50 (@zaki50) April 22, 2017

В-третьих, изменилась онлайн-трансляция: длинные перерывы дают присутствующим на конференции возможность как следует пообщаться, а что делать зрителям трансляции? Для них в перерывах делали включения из фойе и интервью со спикерами. Напомним, во второй день конференции трансляция одного зала (и перерывов) велась открыто на YouTube — можете сами увидеть, как всё происходило.

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

После кейноута все разошлись по трём залам — и мы не станем пытаться пересказать вообще всё, что в них можно было услышать за два дня, а вместо этого перечислим главные тренды, которые можно было отметить:

React Native

Первым об этом говорил как раз Михаил Самарин. Он заметил, что React Native показал взрывной рост, и игнорировать технологию теперь невозможно, но при этом она остаётся очень спорной. По его словам, специалисты традиционной нативной разработки признают «такой скорости прототипирования мы достичь в принципе не можем» — но некоторые другие аспекты приводят их в бешенство. То, что это проект Facebook, можно назвать одновременно и благословением, и проклятием (например, Facebook может отозвать лицензию на React Native у любой компании, которая перейдёт ему дорогу). JavaScript можно назвать одновременно и благословением, и проклятием («он сейчас как Visual Basic когда-то: используется в областях, для которых не был предназначен»). Множество зависимостей… вот их, пожалуй, благословением не называют. Резюмировал тему Михаил так: «Надо обязательно пробовать, через “не хочу”».

Следом Владимир Иванов (EPAM) погружал в тему уже глубоко, с кодом и решением конкретных проблем. Возможно, в каком-то смысле даже слишком глубоко: его доклад был рассчитан в первую очередь на пробовавших технологию лично, а по вопросам после доклада можно было понять, что очень многие пока что интересуются ей теоретически. Таким зрителям мог в какой-то степени помочь последовавший доклад Дмитрия Евстратова и Даниила Калинцева, рассказывавших о своём опыте использования React Native в «Сбербанк-Технологиях».

Архитектура

На Mobius был целый ряд архитектурных докладов, у одного из которых ещё и необычная история появления. Android-разработчик Евгений Мацюк (Лаборатория Касперского), задумав доклад «Чистая архитектура», ещё в январе опубликовал на Хабре «Манифест архитектурной боли», призвав делиться своей болью в специально созданном для этого Telegram-чате. За несколько месяцев чат разросся до 700 участников, чего никто не ожидал, и породил столько дискуссий, что в получившийся совместный доклад Евгений и Александр Блинов (REDMADROBOT) смогли уместить лишь небольшую часть желаемого. Тем не менее, успели сказать многое и о «чистой архитектуре» самой по себе («многие спрашивают, можно ли убрать слой из фичи, обычно хотят убрать interactor там, где от него не видно большой пользы, но я лично за трейд-офф в пользу консистентности»), и о том, как инкрементально менять в её сторону уже существующий проект.

И дискуссии не завершились после выступления с докладом. Чат продолжает активно жить, а в холле Mobius на второй день можно было увидеть, как Мацюк и Блинов активно обсуждают архитектуру с другим спикером Фернандо Сехасом, на блог которого Мацюк в самом начале ссылался в своём «Манифесте». Круг замкнулся!

Другой «архитектурный» докладчик, Денис Неклюдов (90Seconds), тоже заведует Telegram-чатом на сотни человек — это чат подкаста «Android Dev». Причём прямо на Mobius группой спикеров совместно записывала выпуск этого подкаста. К сожалению, насладиться выпуском зрителям мешали проблемы со звуком — но хотя бы все причастные получали много удовольствия:

Мы спросили Дениса о том, почему сейчас все горят желанием обсуждать архитектуру, и его версия оказалась такой: «Пару лет назад на мобильных конференциях много говорили о каких-то конкретных вопросах вроде отображения картинок, а сейчас подобные вещи уже считаются решёнными проблемами. Поэтому и произошёл переход к архитектурным темам».

А у спикера Антона Кекса нашлась другая версия:

#Mobiusconf has a lot more architectural talks than #JPoint, seems that mobile devs have finally reached big enough codebases :-)

— Anton Keks (@antonkeks) April 22, 2017

Kotlin

На прошлогоднем Mobius о Kotlin был один доклад с «вступительной» темой «Android-приложения на Kotlin: почему это хорошо», и спикер тогда был из JetBrains. В этот раз компания присутствовала на конференции как спонсор, и представители команды Kotlin охотно отвечали на вопросы о нём, но в Android-докладах уже без участия JetBrains о языке охотно говорили все подряд — причём теперь не в ознакомительном формате «есть такой язык», а разбирая конкретику.

Дэнни Пройслер рассказывал об использовании Kotlin в тестах, братья Антон и Филипп Кексы представляли Kotlin-паззлеры, у Дениса Неклюдова и Степана Гончарова в их архитектурном докладе Kotlin фигурировал как важная составляющая — и это только те случаи, где язык был вынесен прямо в название доклада, а не упоминался мимоходом.

А когда на таких докладах спрашивали «кто использует Kotlin в продакшене», поднятых рук оказывалось много, так что зрители собирались не из академического интереса. В общем, было очевидно, что за прошедший год Kotlin в Android-среде совершил громадный скачок в популярности.

Любопытно вот что. Совсем недавно был представлен проект Kotlin/Native, одной из платформ для которого является iOS. В перспективе JetBrains целятся в кроссплатформенную мобильную разработку, позволяющую писать для обеих главных платформ на одном языке и переиспользовать код (в некотором смысле конкурируя с тем же React Native). И теперь, когда в Android-мире уже очевидно получилось многого добиться, возникает новый челлендж для компании: удастся ли ей сделать так, чтобы на будущих Mobius о языке говорили применительно не только к одной платформе?

Swift

Хотя аналогия «Kotlin для Android — это как Swift для iOS» не вполне корректная, избежать их сравнений сложно. Пока в Android всё чаще используют первый язык, в iOS-мире по-настоящему размахнулся второй, и конференция наглядно это отражала. Как и в случае с Kotlin, если на предыдущем Mobius о языке был один доклад («Advanced Swift Generics — перейдем на T»), то в этот раз — целых три: о перформансе, тестируемости и использовании Swift для скриптов.

Когда год назад перед предыдущим Mobius мы спрашивали нескольких спикеров, как обстоят дела с переходом на Swift в их компаниях и что они посоветуют другим, в ответах было много осторожности: «есть как преимущества, так и недостатки», «если новый проект очень крупный и долгоиграющий — лично я все еще склоняюсь к Objective-C». Теперь же её как не бывало: когда в онлайн-трансляции мы спрашивали iOS-спикеров «есть ли смысл в 2017-м начинать новый проект на Objective-C», им в голову приходили только специфические случаи (например, когда всё завязано на интероп с C++).

Правда, Игорь Кашкута (Badoo), год назад сказавший нам «версия 3.0 будет по-настоящему нормальной версией 1.0», скорректировал свой прогноз: поскольку в Apple с тех пор изменили планы и отложили ABI stability до 4.0, теперь Игорь считает, что «версия 4.0 будет по-настоящему нормальной версией 1.0». Надо будет не забыть уточнить его позицию через год на Mobius 2018!

А в докладе Николая Лихогруда из «Яндекса», рассказывавшего об оптимизации времени загрузки iOS-приложений, было отмечено: пока Swift не стабилизировался полностью и не стал частью iOS, он несколько увеличивает время загрузки по сравнению с Objective-C. Вряд ли разница станет для многих критичной, но момент любопытный и неочевидный.

Помимо трендов

Были и выступления, которые не встраивались в какую-то большую тенденцию, но оказывались интересными из-за того, что смотрели на мобильную разработку через призму своей специфики. Например, Филипп Кекс (Creative Mobile), занимающийся играми, рассказывал, почему рекламные заявления о «производительности новых смартфонов на уровне приставок» не соответствуют действительности. Измерив стандартную продолжительность игровой сессии, оценив вероятность перегрева и определив, насколько можно нагружать устройство, в Creative Mobile пришли к неожиданному выводу: если бы в новые смартфоны вроде Galaxy S8 поставили менее мощные компоненты, то на практике выжать из них можно было бы дальше больше. Перегрев актуален не только для игр: Александр Коршак рассказывал на Mobius о 360-градусном видео и VR, и ранее он говорил нам в интервью, что там этот вопрос тоже очень болезненный.

И завершало конференцию выступление, в котором на мобильную разработку смотрели тоже с другого ракурса. Йонатан Левин (KolGene) — и разработчик, и стартапер, поэтому видит ситуацию с двух перспектив: и технологической, и продуктовой. И если первый его доклад на Mobius 2017 был о происходящем внутри Android-платформы, то закрывающий кейноут «Как сделать из вашего приложения продукт» — о происходящем снаружи. Много смеха в зале вызвала фраза Йонатана, саркастично показывающая отрыв первого от второго:

«Вы долго и старательно делаете приложение, наконец выкладываете в магазин, а его никто не устанавливает. И вы думаете: как же так, почему не хотят, там же RxJava!»

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

Let's block ads! (Why?)

Gixy — open source от Яндекса, который сделает конфигурирование Nginx безопасным

Дерзкий telegram бот

DevTools в браузере Vivaldi 1.10.289.3

Отчет с Go meetup 14 апреля

Поиск неисправностей с помощью WinDbg, Sos и Sosex

[Перевод] Учимся у мастеров: дизайн уровней Legend Of Zelda

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

Мне кажется, что в них отсутствуют многие элементы современного дизайна игр: никакого обучения, резкие изменения сложности, непродуманный дизайн уровней, и так далее. До написания этой статьи у меня было впечатление, что многие освоенные мной «правила хорошего дизайна» изобретены и начали использоваться в эру SNES.

Я думал, что NES была Диким Западом разработки игр, не принимавшим никаких законов. Поэтому когда на 25-летнюю годовщину Линка я решил поиграть в первую Zelda и, возможно, написать о ней статью, то немного опасался последствий.

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

В одном из интервью создатель игры Сигэру Миямото рассказал, что в The Legend of Zelda он хотел вызвать в игроке ощущения, появляющиеся при исследовании:

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

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

Я до сих пор слышу эту музыку в своих снах...

Чем мы здесь займёмся?

Проходя The Legend of Zelda, я играл в каждый из уровней, а затем выполнял подробный анализ уровня на бумаге. Такой анализ — довольно стандартный подход, я постоянно делаю его в дизайне уровней своих коллег. Вот что я всегда стараюсь выделить:

• Прохождение уровня. Хорошо ли сочетаются друг с другом пространства уровня? Куда должен идти игрок, и поймёт ли он, как туда добраться?
• Изменение интенсивности. Повышается ли интенсивность игры правильным образом? Становятся ли монстры сложнее по ходу уровня? Имеет ли игрок возможность освоить поведение врагов и позже показать своё мастерство?
• Вариативность. Достаточно ли вариативен геймплей? Часто ли повторяются встречи с одинаковыми врагами? Интересно ли варьируются пространства?
• Обучение. Если дизайн требует от игрока новых навыков, учит ли игра этим навыкам и проверяет ли их правильно?

В этой статье я применю ту же методику к первому уровню оригинальной Legend of Zelda. К счастью, это легко сделать, ведь карты уровней с видом сверху широко распространены и доступны. Я рассмотрю в статье только первое подземелье, но те же принципы относятся ко всем уровням.

Если вы хотите проверить их, то можно воспользоваться картами, которые нашёл я: Mike's RPG Center. (Кстати, Майк любезно дал мне разрешение на использование его карт в этой статье. Спасибо, Майк.)

Прохождение уровня

Разбивка

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

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

Я начал с анализа критического пути. Критический путь — это кратчайший путь через уровень без использования секретов, сокращений и читов. В сущности, это путь, который должен пройти игрок по замыслу дизайнера, если не окажется очень умным.

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

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

Игрок начинает с комнаты 1 и может выбрать переход в комнату 2 или 3. Комнаты, не находящиеся на критическом пути, на карте обозначены как более бледные (нажмите на изображение, чтобы посмотреть его в полном размере).

Дополнительные комнаты (а иногда и целые пути) ответвляются от критического пути и награждают игрока бонусами. На уровнях также полно сокращений, разрезающих критические пути. Например, если у игрока есть бомбы, он может перескочить из комнаты 5 в комнату 8 на схеме выше.

Если Миямото действительно хотел передать ощущения исследователя, то этот дизайн является мастерской реализацией его намерений.

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

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

1. Как я уже упомянул, критический путь почти полностью линеен. Это значит, что игроку гораздо проще найти путь сквозь подземелье, не потерявшись в нём.
2. Благодаря комнатам, ответвляющимся от критического пути, уровень ощущается менее линейным.
3. Повторно посещаемые комнаты в начале уровня тоже усиливают ощущение нелинейности, а из-за малого количества таких комнат игрок скорее всего не сможет заблудиться.
4. Маленькие скрытые сокращения пути на уровне позволяют игроку ощущать себя умным, а дизайнер может таким образом замаскировать линейность уровня.

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

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

Изменение интенсивности

Разбивка

При изучении изменения интенсивности я обычно обращаю внимание на два аспекта:

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

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

Комната 2: 3 Bats
Комната 3: 5 Stalfos (с двумя большими блоками)
Комната 4: 3 Stalfos (с одним большим блоком)
Комната 5: 5 Stalfos (с четырьмя отдельными блоками)
Комната 6: 6 Bats
Комната 7: 3 gels
Комната 8: 5 gels
Комната 9: 3 Moblins
Комната 10: 2 wall masters
Комната 11: босс

Анализ

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

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

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

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

Вариативность

Разбивка

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

Анализ

Однако тут можно добавить одно критическое замечание — вариативность монстров может быть слишком большой. В десяти комнатах с монстрами разработчики использовали шесть типов монстров и босса. В большинстве современных игр было бы меньше типов врагов, а сложность комнат повышалась сочетанием типов монстров. Например, если бы в подземелье были только Stalfos, Bats и Moblins (и босс, конечно же) в части дальних комнат сочетались бы все три типа, и их прохождение было бы сложнее из-за таких комбинаций.

На более поздних уровнях игра использует такие сочетания чаще, поэтому непонятно, почему разработчики не применили такой принцип здесь. Возможно, из-за технических ограничений?

Обучение

Разбивка

Обучение — очевидная примета большинства современных игр. Однако во времена The Legend of Zelda приходилось читать руководство, чтобы понять, как играть в игру. Когда настала эра SNES, в дизайн многих AAA-игр было встроено обучение, но на NES оно встречалось редко.

Интересно, что в оригинальной Legend of Zelda есть элементы обучения, однако они отличаются от обучения в современных играх. Обучение The Legend of Zelda в основном выполняется в «чёрных комнатах», где NPC даёт игроку подсказки.

Не самая полезная подсказка, если вы играете не в японскую версию.

Например, на первом уровне подсказка выглядит как «Eastmost peninsula has the secret» («На восточном полуострове есть секрет») и даёт понять, что нужно добраться до конца подземелья. Довольно бесполезная подсказка.

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

Анализ

Эта находка удивила меня больше остальных. Я помнил чёрные комнаты, но никогда не воспринимал их как часть обучения, потому что они были довольно бесполезными.

Когда я узнал об этой проблеме с переводом, всё изменилось. Стало ясно, что Миямото и его коллектив пытались направить игрока и обучить его важным аспектам игры.

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

Открытый вопрос

С учётом всего вышеперечисленного только одно дизайнерское решение оставило меня в недоумении.

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

Они успешно решили эту проблему на уровне 4 (который показан в приложении ниже), поэтому я не понимаю, почему они не сделали то же самое на многих других уровнях.

К моменту, когда мы добрались до A Link to the Past на Super Nintendo (шесть лет спустя), они устранили эту проблему, поэтому очевидно, что она им тоже не нравилась. Но я по прежнему не понимаю, в чём заключался замысел.

Чему мы научились?

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

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

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

Приложение: уровень 4, уровень 9

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

Уровень 4: Змея (нажмите, чтобы просмотреть в полном размере).

Комната 2: 3 Vires (с четырьмя отдельными блоками)
Комната 3: 8 Bats (с четырьмя отдельными блоками)
Комната 4: 5 Vires (с диагональными блоками)
Комната 5: 5 Zols (с участками воды)
Комната 6: 3 Vires, 2 Bubbles (с участком воды)
Примечание — в этой комнате нужна лестница
Комната 7: 5 Vires (с узкой дорожкой)
Примечание — эта комната гораздо проще проходится во второй раз, когда у игрока есть лестница
Комната 8: 2 Zols, 2 Like Likes, 2 Bubbles
Комната 9: 5 Vires (с участками воды из комнаты 5)
Комната 10: Минибосс (Manhandla)
Комната 12: 6 Bats (с участками воды)
Комната 13: 6 Blade Traps
Комната 14: 5 Vires (с двумя отдельными блоками)
Комната 15: босс

Пояснения

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

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

Однако это не очень большая проблема, потому что они заблокировали движение вперёд в комнате 6. Благодаря этому игрок не сможет слишком сильно заблудиться.

Уровень 9: Череп (нажмите, чтобы просмотреть в полном размере). Красными стрелками показан путь к серебряной стреле. Она нужна для победы над боссом Гэноном, но не требуется, чтобы попасть к нему. Вокруг комнаты 4 создан круг, позволяющий игроку зайти в неё с любой стороны. Я выбрал вход из комнаты 3, потому что так короче.

Пояснения

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

Сюрприз заключался в том, что серебряная стрела технически находилась не на критическом пути, несмотря на то, что без неё невозможно победить последнего босса (Гэнона). В современной игре Zelda разработчики разместили бы прямо перед дверью Гэнона (и по уровню тоже) ворота, которые можно открыть только серебряной стрелой. Таким образом можно гарантировать, что игрок получил её, прежде чем зайти к Гэнону.

Я выделил путь к серебряной стреле красными линиями, чтобы вы видели, куда нужно идти. При этом нужно повторно пересечь 5 комнат, что сильно отклоняется от нормы.

Let's block ads! (Why?)

[Перевод] Функциональное программирование в JavaScript с практическими примерами

[Перевод] Сравнение структур разделов GPT и MBR

Всё не так просто с ctrl+z: об undo в быстром совместном редактировании ONLYOFFICE

Случайно накосячили в документе, который вам только что пошарили? Драг-н-дропнули куда-то кусок чужого текста и не знаете, как жить дальше? Угодили курсором в ячейку вашего коллеги и уничтожили его данные? Ctrl+Z не раз спасало наши жизни и репутации добропорядочных коллег, не портящих чужие (и свои) документы.

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

Undo в быстром режиме совместного редактирования появилось у нас вместе со сносками в версии 4.3. Больше о релизе вы можете узнать из нашей прошлой статьи (из этой статьи вы узнаете только об undo).

Быстрый, строгий, злой

Короткая справка о том, чем вообще отличаются режимы коэдитинга:

• Быстрый. Вы видите, что печатает ваш соавтор. («Что за чепуху ты печатаешь, Николай?!»)
• Строгий. Вы спокойно работаете над своим куском текста, а правки соавтора видите только после сохранения. («Что за чепуху ты напечатал, Геннадий?!»)

Быстрый режим совместного редактирования включен в редакторах ONLYOFFICE по умолчанию. Раньше в нём не было undo.

Почему раньше в быстром режиме не было undo

Мы думали, что это опасно для документа. Допустим, Николай вставляет автофигуру, а Геннадий перетаскивает в нее часть текста из документа. Затем Николай отменяет действие, в результате чего удаляется автофигура. А с ней и часть текста, которую уже никак не вернуть. Геннадий и Николай грустно идут пить чай, обсуждая, как восстановить утраченный текст.

Тем не менее, мы пришли к выводу, что даже в быстром режиме возможность отменить последнее действие нужна. Это просто удобно. Например, в ситуации, описанной в начале этого текста, когда вы, выделяя текст для более внимательного чтения, случайно перетащили его мышкой, а в это время документ редактировал кто-то еще. Или даже не редактировал, а просто забыл закрыть его. Или это вы сами забыли закрыть этот же документ в соседней вкладке. В общем, нужна возможно автоматически откатить последнее действие.

К undo, конечно же, нужно относиться осторожно (но на самом деле, вы рискуете уже просто когда шарите на кого-то документ с возможностью редактирования). Но мы расскажем вам, как всё устроено, чтобы минимизировать риски.

Google и мы

Нас постоянно спрашивают (на самом деле, спрашивают): Вы сделали это как у Google Docs? Нет.

Да, у них есть совместное редактирование и возможность сделать undo, и у нас эти вещи тоже есть. Но это не значит, что у нас внутри всё одинаково.

Как у Google. Документ находится на сервере, туда же отправляются все правки, там же собирается финальная версия документа. Например: Николай выделил какое-то слово жирненьким, а Геннадий курсивом. Оба два отправляют свои изменения на сервер, который уже разруливает этот конфуз: в частности, сообщает Николаю добавить курсив, а Геннадию сделать свой курсивжирным. В такой схеме ситуация, в которой один и тот же документ выглядит на разных клиентах по-разному, возможна (на очень короткий промежуток времени, конечно же).

Как у ONLYOFFICE. Если у Google ядро документа редактируется на сервере, то у нас всё это происходит на каждом клиенте. Сервер используется как база данных, в которой хранятся изменения. Как в такой схеме должны лечь изменения в ситуации, когда Николай выделил какое-то слово жирненьким, а Геннадий курсивом? Изменения лягут последовательно, при чем последовательность будет одна и та же на каждом клиенте. Ситуация, в которых у Николая и Геннадия документы выглядят по-разному в какой-то момент времени, невозможна.

Как это вообще связано с undo, спросите вы (на самом деле, мы понятия не имеем, спросите вы или нет, но представим как будто вы спросили). Из следующего пункта нашей истории вы поймете как.

Что происходит, когда вы нажимаете Ctrl+Z

Как мы уже сказали, в ONLYOFFICE все самые важные вещи происходят непосредственно на клиенте. Там же хранится список действий — не только своих, но и чужих. Свои собственные действия помечаются, чтобы потом была возможность их откатить.

И вот тут-то мы переходим к тому, как на самом деле происходит undo. Когда человек редактирует документ в одиночестве всё, в принципе, понятно. В блоке изменений хранятся действия одного человека и в случае необходимости мы просто берем последнее действие и производим антидействие. Блок действий при этом сокращается на единицу.

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

Рассмотрим простой пример. В документе содержится такой текст:

абв

Николай добавил в конце букву д и получил текст:

абвд

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

авд

Николай нажимает undo. Удаление и добавление текста происходит по позициям. Своим первым действием Николай добавил букву в позицию 3. В обычном редактировании undo сработало бы просто как удаление буквы из третьей позиции. Но ведь Геннадий уже постарался и удалил букву б из позиции 2 и буква д переместилась на её место. Таким образом в третьей позиции теперь просто пусто и удалять оттуда ну совсем нечего.

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

Если перенести действие Николая по добавлению буквы д в самый конец блока, то есть после того, как Геннадий злодейски удалил букву букву б из второй позиции, то получится, что Николай добавил букву Д в позицию 2. Делаем обратное действие — удаление из позиции 2. Undo проходит.

Таким образом основной принцип таков: мы берем пачку действий клиента, который хочет сделать undo, коммутируем их (перестанавливаем через чужие действия по определенным правилам) и формируем новый блок обратных действий, как в обычном undo.

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

Ещё с undo, конечно, разные интересные проблемы, например

Неоткатываемые действия

Еще один простой пример:

1. Николай добавляет текст 12.
2. Геннадий удаляет 2.
3. Николай делает undo 2 раза.
4. Геннадий делает undo.

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

Исчезающие элементы

Рассмотрим ещё раз случай произошедший с Геннадием и Никлаем в начале статьи:

1. Николай добавляет автофигуру.
2. Геннадий набирает текст в автофигуре.
3. Нестабильный Николай делает undo автофигуры.
4. Вместе с автофигурой пропадает и текст, набранный Геннадием внутри неё. Окончательно.

Любая проблема с undo в быстром совместном редактировании объясняется тем, что последовательность реальных действий в документе и последовательность, в которой нажимается undo, не совпадают.

Это не недостатки нашей реализации undo. Оно работает правильно. Оно будет идеальным, если вы с коллегами будете одновременно работать над разными объектами. И вот вам наше вам напутственное слово: будьте, как это сейчас модно говорить, mindful, работая с документами. Переключайтесь между режимами совместного редактирования и используйте undo с умом.

Let's block ads! (Why?)

[Перевод] Bash-скрипты, часть 7: sed и обработка текстов

Восстание машин: Как роботы захватили бухгалтерию

UE4 для Unity-разработчиков

Привет, Хабр! Меня зовут Александр, и сегодня мы сравним Unity и Unreal Engine 4.

Думаю, многие разработчики пробовали движок Unity и видели сделанные на нём игры, проекты, какие-то демки. Его главный конкурент — движок Unreal Engine. Он берёт своё начало в проектах компании Epic Games, таких как шутер Unreal Tournament. Давайте рассмотрим, как начать работу с движком Unreal после Unity и какие препятствия могут подстерегать нас на пути.

Бывает, что 3D-движки сравнивают весьма поверхностно, либо акцентируют внимание только на одной из фич, например, на графике. Мы же холиварить не будем и рассмотрим оба движка в качестве равноправных инструментов. Наша цель — сопоставить две технологии и помочь вам разобраться в движке Unreal Engine 4. Сравним базовые системы движков на конкретных примерах кода демо-проекта UShooter (Unreal + Unity Shooter), специально сделанного для этих целей. Проект использует версию Unity 5.5.0 и Unreal Engine 4.14.3.

Система компонентов (Unity)

Когда мы запускаем проект на Unreal, то видим, что персонаж в сцене — лишь один объект. В окне World Outliner нет привычных нодов модели (вложенных объектов, мешей), костей скелета и т. д. Это следствие различий систем компонентов Unity и Unreal.

В Unity сцена состоит из объектов типа Game Object. Это пустой универсальный объект, к которому добавляются компоненты, реализованные скриптами поведения (MonoBehaviour) и встроенными компонентами движка. Иногда их оставляют пустыми, в качестве объекта-маркера, на месте которого будет создан, например, игровой персонаж или эффект.

Все эти объекты мы видим в окне Hierarchy в редакторе движка. Они имеют встроенный компонент Transform, с помощью которого мы можем управлять положением объекта в пространстве 3D-сцены. Например, скрипт движения объекта меняет координаты в функции Update, и объект двигается. Для добавления подобного скрипта на Game Object достаточно двух кликов. Создав объект — персонажа или предмет, — мы его настраиваем, добавляем скрипты и сохраняем в prefab (файл, хранящий Game Object и его дочерние объекты). Впоследствии мы можем менять сам prefab, и эти изменения отразятся на всех подобных объектах.

Вот как выглядит класс RocketProjectile, представляющий собой ракету в проекте UShooter.

Фрагмент RocketProjectile.cs

public class RocketProjectile: MonoBehaviour
{
    public float Damage = 10.0f;
    public float FlySpeed = 10.0f;

    void Update()
    {
        gameObject.transform.position += gameObject.transform.forward * FlySpeed * Time.deltaTime;
    }

    void OnCollisionEnter(Collision collision)
    {
        // Обработка столкновения
    }
}

Мы задаём параметры снаряда в редакторе, при желании меняем скорость перемещения (свойство FlySpeed) и урон (Damage). Обработка столкновений происходит в функции OnCollisionEnter. Unity сам её вызывает, так как на объекте есть компонент Rigid Body.

Система компонентов (UE4)

В Unreal Engine 4 игровые объекты представляются Actor’ами и их компонентами. AActor («актер») — это основной класс объекта, который помещается в сцене. Мы можем его создать в игровой сцене (как из редактора, так и кодом), менять его свойства и т. д. Также есть класс, от которого унаследованы все сущности движка: UObject.

Компоненты добавляются к Actor’у, игровому объекту. Это может быть оружие, персонаж, что угодно. Но эти компоненты условно скрыты от нас в аналоге Prefab’а — Blueprint Class.

В объекте Actor, в отличие от Unity, существует понятие Root Component. Это корневой компонент объекта, к которому крепятся остальные компоненты. В Unity достаточно мышкой перетащить объект, чтобы поменять у него иерархию вложенности. В Unreal это делается через привязку компонентов друг к другу ("attachment").

В Unity существуют функции Start, Update и LateUpdate для обновления или начала работы скриптов MonoBehaviour. Их аналоги в Unreal — функции BeginPlay и Tick у Actor'а. У компонентов Actor’а (UActorComponent) для этого существуют функции InitializeComponent и ComponentTick, поэтому нельзя «в один клик» сделать из компонента Actor, и наоборот. Также, в отличие от Unity, Transform есть не у всех компонентов, а только у USceneComponent и унаследованных от него.

В Unity мы можем практически в любом месте кода написать GameObject.Instantiate и получим созданный из Prefab’а объект. В Unreal же мы «просим» объект мира (UWorld) создать экземпляр объекта. Создание объекта называется в анриале спауном, от слова spawn. Для этого используется функция World->SpawnActor.

Персонажи и их Controller’ы

В Unreal для персонажей существуют специальные классы APawn и ACharacter, они унаследованы от класса AActor.

APawn — класс персонажа, которым может управлять игрок или AI. В Unreal для управления персонажами есть система контроллеров. Мы создаём Player Controller или AI Controller. Они получают команду управления от игрока или внутреннюю логику, если это AI, и передают команды движения самому классу персонажа, APawn или ACharacter.

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

Описание игрового класса (Actor’а)

Теперь, немного узнав о компонентах Unreal, мы можем взглянуть на класс ракеты в Unreal-версии UShooter.

Фрагмент RocketProjectile.h

UCLASS()
class USHOOTER_API ARocketProjectile : public AActor
{
    GENERATED_BODY()

public: 
    // Sets default values for this actor's properties
    ARocketProjectile();

    // Called when the game starts or when spawned
    virtual void BeginPlay() override;

    // Called every frame
    virtual void Tick( float DeltaSeconds ) override;

    // Rocket fly speed
    UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Rocket")
    float FlySpeed;

    // Rocket damage
    UPROPERTY(EditDefaultsOnly, BlueprintReadOnly, Category = "Rocket")
    float Damage;

    // Impact (collsion) handling
    UFUNCTION()
    void OnImpact(UPrimitiveComponent* HitComponent, AActor* OtherActor, UPrimitiveComponent* OtherComp, FVector NormalImpulse, const FHitResult& Hit);

private:

    /** Collision sphere */
    UPROPERTY(VisibleDefaultsOnly, Category = "Projectile")
    USphereComponent* CollisionComp;
};

Взаимодействие редактора и скриптов, которое в Unity не требует специального кода, работает в Unreal через генерацию кода. Этот специальный код Unreal генерирует при сборке. Чтобы редактор мог показать свойства нашего объекта, мы делаем специальные обёртки: UCLASS, GENERATED_BODY и UPROPERTY. Также мы декорируем свойства и описываем, как редактор должен с ними работать. Например, EditDefaultsOnly означает, что мы можем изменить свойства только дефолтного объекта, blueprint class’а (prefab’а, если провести аналогию с Unity). Свойства могут быть сгруппированы в разные категории. Это позволяет быстрее найти интересующие нас свойства объекта.

Функция OnImpact — аналог OnCollisionEnter в Unity. Но для работы с ней требуется подписаться на события компонента USphereComponent в конструкторе или даже во время игры. Это не работает автоматически, как в Unity, зато здесь есть возможность оптимизации. Если нам больше не нужно реагировать на столкновения, мы можем отписаться от события.

Блупринты (Blueprint)

Типичное действие после создания C++ класса в Unreal — создание на его основе Blueprint Class’а. Это расширение объекта, которое нам предоставляет Unreal. Система Blueprint’ов в Unreal используется для визуального программирования. Мы можем создавать визуальные схемы, соединять события с какими-то реакциями на них. Через блупринты движок упрощает взаимодействие программистов и дизайнеров. Мы можем написать на С++ часть игровой логики и предоставить доступ к ней дизайнерам.

При этом Unreal позволяет отделить, если требуется, C++ исходники проекта от его бинарников и контента. Дизайнеры или аутсорсеры могут работать с собранными dll-библиотеками и никогда не узнают, что происходит внутри C++ части проекта. Это дополнительная степень свободы, предоставляемая движком.

Unreal хорош тем, что в нём практически всё связано с Blueprint’ами. Мы можем расширять ими С++ классы, создавать из них Blueprint-наследников и т. д. Эта система тесно связана со всеми компонентами движка, от его внутренней логики до визуальных компонентов, collision, анимации и т. д.

В Unity есть схожие системы визуального программирования, например Antares Universe. Они не входят в состав движка и созданы поверх него, поэтому в любой момент что-то может сломаться (например, при обновлении версии движка). Система визуального скриптования в Unity не предусмотрена. На мой взгляд, это серьёзный недостаток по сравнению с Unreal. Ведь благодаря таким системам даже далекие от программирования люди могут составить схему взаимодействия объектов или связать какую-то последовательность действий. К слову, в Unreal все шаблоны проектов имеют две версии: как на основе C++ кода, так и целиком на Blueprint’ах. Таким образом, создать простой проект без использования кода, целиком на блупринтах — вполне реально.

Демка шутера (UShooter)

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

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

Система ввода (Unity)

Управлять персонажем будем с помощью системы ввода. В Unity мы обычно настраиваем ввод через Input Manager, создаём виртуальные именованные оси. Например, «идти вперёд» или «стрелять». Даём им имена и потом получаем значение какой-либо оси или состояние виртуальной кнопки. Обычно скрипты, которые занимаются управлением объектами, получают состояние осей в функции Update. В каждом кадре опрашивается состояние оси и целого ряда кнопок управления.

Система ввода (UE4)

В Unreal тоже есть виртуальные оси, но там есть разделение на собственно оси (значения, полученные от джойстика, и т.п.) и кнопки действия. В отличие от Unity, мы привязываем оси и кнопки к функциям класса, который реализует управление персонажем. Связь создаётся через компонент UInputComponent. Такой компонент ввода есть у класса персонажа ACharacter.

Вызовом BindAxis("MoveRight", this, &AUShooterCharacter::MoveRight) в Input Component мы привязываем нажатие кнопки MoveRight к вызову одноимённой функции движения. Не требуется каждый кадр заниматься опросом кнопки.

Также в Unreal не ограничено количество альтернативных кнопок. В Unity в Input Manager есть только основная кнопка и альтернативная. Чем больше устройств ввода в вашей игре, тем острее может быть эта проблема.

Работа с 3D-моделями

Как уже говорилось, в Unreal мы не видим в сцене структуру скелета персонажа. Дело в том, что компоненты скелета не являются Actor’ами или чем-то подобным. Это внутренние свойства скелета и анимации. Как тогда привязать к персонажу оружие или скрыть одну из его частей? Может, мы хотим надеть на него модную кепку или привязать оружие к руке.

В Unity мы выделим модель оружия в редакторе, перетащим в нужную кость, можем даже повесить на него отдельный скрипт управления. В Unreal мы будем пользоваться сокетами (Socket) — точками крепления на игровых объектах. Сокеты — это часть скелета в моделях со скелетной анимацией (в Unity такие модели называются Skinned Mesh, в Unreal’е — Skeletal Mesh). Также сокеты можно добавлять в статические меши (Static Mesh).

Выбираем кость, к которой крепится сокет, и задаём имя сокета, например S_Weapon, если к точке крепится оружие. После создания сокета можно создать («заспаунить») объект в позиции этого сокета или привязать его к сокету через механизм привязки (функции AttachTo). Система немного запутанная, в отличие от Unity, зато более универсальная. Мы можем один раз настроить названия точек, тем самым отделив игровую логику от настроек моделей. Причём если у нас имеется несколько моделей с одним скелетом, то сокеты надо будет добавить только в скелет. В демке шутера сокеты используются при создании снарядов и эффектов выстрела.

Система анимации (Unity)

У нас есть персонаж, мы знаем, как работать с вводом, теперь нужно проигрывать анимацию. В Unity для этого есть Animation Controller, в нём мы описываем определённые состояния персонажа. Например, бежать, прыгать или умереть. Каждому блоку соответствует свой анимационный клип, и мы настраиваем такой граф переходов:

Хотя эта схема называется Animation Controller, внутренней логики у неё нет. Это просто схема переключения анимации в зависимости от состояния. Чтобы она работала, мы заранее объявляем в этом контроллере названия переменных, соответствующих состоянию персонажа. Скрипт, управляющий анимацией, зачастую сам передаёт эти состояния контроллеру каждый кадр.

В переходах между состояниями (на схеме показаны стрелочками) мы настраиваем условия переходов. Можно настроить смешивание (crossfade) анимации, т. e. время, в течение которого одна анимация затухнет, а другая продолжится, для их плавного совмещения.

Система анимации (UE4)

В Unreal всё сделано Blueprint’ами, анимация не исключение. Создаём Animation Blueprint, который будет управлять анимацией. Он тоже представляет собой граф состояний. Так выглядит машина состояний, она управляет финальной анимацией персонажа в зависимости от движения или состояния смерти.

Тут мы видим уже знакомые нам состояния Idle/Run, Jump, Dead. Но один узел совмещает в себе Idle и Run. Внутри него находится так называемый Blend Space 1D, он используется для плавного перехода анимации в зависимости от значения одной или нескольких переменных. С помощью Blend Space можно привязать скорость персонажа к переходу между анимацией Idle и Run. Кроме того, получится настроить несколько точек перехода. Например, от нуля до метра в секунду персонаж идёт медленно — это будет движение, интерполированное между анимацией Idle и Walk. А после некоторого порогового значения включается бег (Run). И всё это будет в одном узле Animation Blueprint’а, который обращается к Blend State.

Стрелочками показаны переходы между состояниями, но, в отличие от Unity, мы можем создать Blueprint, реализующий внутреннюю логику работы этих переходов. В Animation Blueprint есть доступ к персонажу, на котором он используется, поэтому Blueprint сам обращается к его параметрам (скорость движения и т. п.). Это можно рассматривать как дополнительную оптимизацию, так как позволяет не рассчитывать параметры, которые не используются для текущего состояния персонажа.

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

Тут представлено совмещение машины состояний движения с анимацией атаки, которую мы проигрываем через инструмент Montage.

В нижней части рисунка — фрагмент схемы Animation Blueprint, который отвечает за реакцию на выстрел из оружия. Команда Montage Play включает анимацию выстрела, затем Delay ждёт, пока она закончится, и анимация выключается командой Montage Stop. Так сделано, потому что в машине состояний анимации мы не можем задать однократное проигрывание анимационного клипа. Если анимация зациклена и соответствует какому-то состоянию персонажа, мы можем управлять анимацией через машину состояний. А если требуется проиграть один клип анимации по событию, то можем сделать через Montage.

Проблема вложенных Prefab’ов

Большая проблема в Unity — вложенные prefab’ы. На случай, если проблема вам не знакома, рассмотрим пример.

Предположим, объект «стол с ноутбуком» сохранили в prefab table1, а затем понадобился второй подобный объект, но уже с зелёным цветом экрана ноутбука. Создаём новый prefab — table2, перетаскиваем в него старый ноутбук, меняем цвет экрана на зелёный, сохраняем. В результате table2, второй prefab, становится совершенно новым объектом, у него нет никаких ссылок на оригинал. Если мы поменяем исходный префаб, это никак не отразится на втором префабе. Простейший случай, но даже он не поддерживается движком.

В Unreal, благодаря наследованию Blueprint’ов, такой проблемы нет: изменение исходного объекта отразится на всех дочерних объектах. Это пригодится не только для игровых объектов, персонажей, какой-то логики или даже статических объектов на сцене, но и для системы интерфейсов.

С другой стороны, можно попытаться победить эту проблему в Unity, используя ассеты в Asset Store. В Unity есть плагины, расширения движка, которые так и называются — Nested Prefabs. Существует несколько подобных систем, но они немного костыльные, сделаны поверх движка, поддержки нет. Они пытаются сохранить в себе внутреннее состояние объекта. Когда запускается игровая сцена, они пробуют восстановить внутренние структуры, их поля, свойства и т. д., удаляют устаревшие объекты в сцене и заменяют их экземплярами из префабов. В результате мы получаем не только удобство вложенных префабов, но и ненужные тормоза, лишнее копирование данных и создание объектов. А если что-то в движке поменяется, то эти системы могут и вовсе отвалиться по неизвестным причинам.

Системы UI

В Unity нельзя сохранить в prefab элементы окон или какие-то виджеты. Можем попытаться, но возникнет та же самая проблема префабов: движок забудет о старых объектах. Поэтому зачастую в Unity мы создаём элементы управления, добавляем скрипты и потом их копируем, не создавая prefab. Если приходится добавлять в такие «виджеты» что-то новое, требуемые изменения нужно повторять вручную.

В Unreal мы можем сохранить элементы интерфейса в виджеты (Widget Blueprint), быстро сделать на основе одних элементов управления новые. Cделали кнопку и надпись, пусть это будет наш status bar widget. На основе стандартных и новых виджетов получается быстро и удобно строить окна интерфейса. К слову, виджеты также расширяются за счет Blueprint’ов, можно описать логику их работы на визуальных схемах.

В Unreal система редактирования интерфейсов и всех виджетов открывается в отдельной вкладке редактора. В Unity интерфейс редактируется через специальный объект Canvas, расположенный прямо в 3D-сцене и зачастую даже мешающий её редактировать.

Преимущества и недостатки

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

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

Из плюсов Unreal стоит отметить визуальное программирование, наследование blueprint’ов, виджеты UI, систему анимации с множеством возможностей и многое другое. Кроме того, в Unreal Engine 4 существует целый набор классов и компонентов, рассчитанных на создание игр: Gameplay Framework. Gameplay Framework является частью движка, на нём созданы все шаблоны проектов. Классы Gameplay Framework открывают множество возможностей — от описания игровых режимов (Game Mode) и состояния игрока (Player State) до сохранения игры (Save Game) и управления персонажами (Player Controller). Особенная фича движка — продвинутая сетевая подсистема, выделенный (dedicated) сервер и возможность запуска сетевой игры в редакторе.

Заключение

Мы сравнили движки Unity 5 и Unreal Engine 4 на конкретных примерах и проблемах, с которыми вы можете столкнуться, начав работу с движком Unreal. Часть сложностей, присущих Unity, решена в Unreal Engine 4. Конечно, невозможно в одном докладе сделать всесторонний обзор этих технологий в полной мере. Однако мы надеемся, что данный материал поможет вам в изучении движка.

Let's block ads! (Why?)

«Нашим разработчикам важен Social Impact»: Михаил Самарин о Futurice и мобильной разработке

Возможно, вы уже знаете компанию Futurice, даже если сами об этом не подозреваете: она стоит за популярным списком «Android best practices», перевод которого пару лет назад собрал на Хабре почти 50 000 просмотров. За эту пару лет и оригинал текста был ощутимо обновлён, и с компанией произошло много интересного: она оплачивает вклад сотрудников в open source, активно работает с новыми мобильными технологиями вроде React Native (уже поделившись с миром своим starter kit для него), а к аутсорс-разработке добавила работу над стартапами.

На прошедшей в Петербурге конференции Mobius, где компания стала генеральным спонсором, её бизнес-директор Михаил Самарин рассказывал о трендах мобильной разработки за последний год: от взлёта того же React Native до дефицита нативных мобильных разработчиков. А мы отдельно расспросили Михаила для Хабра и о компании в целом, и о мобильной разработке. Поскольку он живёт в Хельсинки, в его русскоязычных ответах порой встречаются англоязычные слова — но так только интереснее.

О компании

— Вводный вопрос для тех, кто слышит о Futurice впервые: что компания собой представляет?

— Мы называем компанию «консалтинговой», но здесь есть терминологический нюанс в том, что называют консалтингом в Скандинавии. Более близким термином для России будет subcontracting или аутсорсинг. Нас уже почти 400 человек, два офиса в Финляндии, два в Германии, по одному в Швеции и Англии.

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

Сейчас есть очень много высококачественных subcontracting-агентств в Восточной Европе и в Азии, мы давно не соревнуемся с ними по многим причинам. Одна из причин — цена, нет никакой экономической возможности конкурировать в этом. Но наступает такой момент, когда заказчикам не хватает удалённых сабконтрактинговых агентств, им становится очень важно иметь специалиста у себя в офисе, с живым общением. И тогда они приходят к нам.

— Компания давно известна как аутсорсер, а недавно взяла и занялась также стартапами — со стороны это было неожиданно. Что стало причиной? Что это означает для разработчиков из Futurice?

— Сотрудники Futurice — это люди, которым важно верить в то, чем они занимаются. Нашим разработчикам важны не только технологические аспекты, но и social impact, влияние их работы на общество.

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

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

А кроме того, работа может выполняться на несколько горизонтов: то, что важно сегодня, завтра или 10-20 лет. Если мы начинаем участвовать в проектах, эффект которых будет не сегодня-завтра, а через 10-20 лет, то традиционная бизнес-модель консалтинговых агентств не подходит.

В связи с этим мы решили, что мы будем создавать startup ventures и кооперироваться с некоторыми нашими заказчиками для создания новых компаний с очень большим социальным импактом. Сотрудники Futurice, желающие попробовать себя в чём-то, отличающемся от традиционного консалтингового бизнеса, получают возможность стать частью таких инициатив — в качестве сотрудников или даже соучредителей. Первый такой наш проект, о котором мы недавно публично объявили: вместе с крупнейшей энергетической компанией Финляндии Fortum создаём joint venture по SAAS-инициативе, которая упрощает для обычных людей работы в тех местах, где есть возможность производить солнечную энергию.

— Futurice спонсирует вклад сотрудников в open source — это тоже история про social impact?

— Да, это еще одна наша инициатива со схожей идеей. Чтобы привлекать исключительных специалистов, недостаточно просто иметь обычную хорошую компанию с хорошими условиями. Нужно иметь компанию, которая делает больше, чем зарабатывает деньги для своих собственников. Особенно в ситуации, когда много молодых людей приходит с университетской скамьи: новое поколение гораздо более socially aware. И когда технические специалисты участвуют в open source-проектах — это то, что они как специалисты могут дарить в общество, развивая то или иное техническое направление.

Некоторое время назад мы решили активно спонсировать эти действия наших сотрудников и создали так называемую программу Spice. Если я правильно помню, «спайс» пошло из «Дюны» Френка Герберта, но интересным образом трансформировалось, с одной стороны, в перец чили как специю (spice), а с другой — в единорога, unicorn. Поэтому логотип, нарисованный в Microsoft Paint одним из основателей этого направления Тээму Туруненом — «chilicorn», единорог с перцем чили вместо рога.

И некоторое время назад мы решили, что вне зависимости от того, в каких опенсорс-проектах наши работники участвуют в нерабочеее время, мы в компании будем спонсировать определённое количество часов труда наших работников. У нас есть фонд и система, в которой работники сообщают, где и сколько часов они делают свои contributions, и мы считаем, что таким образом увеличиваем social impact компании. И главное: как компания, мы не претендуем ни на какие права тех open source-проектов, которые спонсированы нам через Spice. Финансирование — это просто наш социальный вклад, как говорится, no strings attached.

Наверное, не очень много компаний занимаются таким, если это не часть их основного бизнеса, и в результате мы привлекли этой программой внимание очень интересных людей. А в конце прошлого года решили продвинуть это дальше и организовали Chilicorn Fund — фонд, где мы выделяем определённое количество денег на спонсирование разных open source и non-profit проектов, которые создаются либо нашими работниками в рабочее время, либо другими компаниями, приходящими к нам за спонсированием.

Тээму не так давно написал обо всём этом книгу, рекомендую её.

— В блоге Futurice недавно был пост с громким заголовком «Почему я не нанял бы Дональда Кнута». Звучит провокационно, но если почитать аргументы, то они звучат убедительно. Тогда такой вопрос: окей, Дональда Кнута нанимать не стали бы, а каких людей хотите нанимать, кто лучше всего подходит Futurice?

— Для начала замечу вот что: в блоге компании каждый работник имеет право на свое мнение, и необязательно, что все остальные будут согласны с этим мнением — это тема для дискуссии. Мы не пытаемся цензурировать то, что работники пишут в блоге, это часть культуры компании. Так что конкретный пост не стоит автоматически считать официальной позицией компании.

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

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

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

— В Guardian недавно писали о внутреннем проекте хельсинкского офиса Futurice, который сообщает сотрудникам офиса информацию вроде «занят ли сейчас туалет» — можете об этом рассказать?

— Да, интересный проект. Мы создали систему, которая может, например, определять местонахождение в офисе тех сотрудников, которые сами хотят быть определёнными. Там много сенсоров и компонентов, вплоть до такого controversial решения, как детектор метана в определённых местах :)

Но я бы хотел использовать этот вопрос, чтобы проиллюстрировать то, чем мы занимаемся в Futurice. Мы уже говорили про наше инициативы, связанные с внешним social impact, а это внутренние инициативы, которые снаружи могут быть не очень видны.

Некоторое время назад мы задумывались, каким образом люди учатся и экспериментируют с новыми технологиями. Безусловно, идеальный вариант — в проектах с заказчиками, но как правило, это более-менее традиционные мобильные или веб-проекты. Каким образом развивать знания специалистов, когда хотим попробовать те области, по которым либо вообще нет никаких проектов, либо это недавно появившиеся технологии? Мы создали внутреннюю инициативу Futulabs, где наши сотрудники могут покупать какие угодно новые гаджеты, сенсоры, VR-headsets и так далее, с тем, чтобы иметь аппаратную базу для экспериментиров с новыми технологиями.

IoT-эксперименты — часть этой инициативы, где сотрудники могут в рабочее время пробовать разные вещи и экспериментировать. Так у нас и появляются интересные эксперименты, которые потом оказываются в Guardian. Но есть ещё более интересный аспект этого. Когда вы разговариваете с многими компаниями, даже с техническими специалистами, и упоминаете термин IoT — это, к сожалению, buzzword, который очень часто не несёт смыслового наполнения. А когда вы пытаетесь разговаривать на каких-то более конкретных уровнях, то у вас нет предмета для разговора. Всем очевидно, что можно иметь какое-то количество сенсоров, микроаппаратуры, связывать их в компьютерную сеть, каким-то образом получать и обрабатывать данные. Это стало возможным ещё с появлением микроэлектроники. А каким образом непосредственно применить это к той или иной проблеме, которую компания пытается решить — это совсем другой уровень.

Мои коллеги создали IoT Service Kit. Эта инициатива началась так: когда мы разговариваем с заказчиками, как мы можем помочь им понять, что такое IoT и как они могут применить это в каком-то конкретном бизнесе? В итоге создали то, что можно назвать настольной игрой.

Набор canvases, которые описывают разные ситуации (офисные здания, магазины, индустриальная фабрика), и набор трёхмерных фигурок, которые представляют разные объекты: там есть сенсоры, камеры, автомобили, люди, участники движения и так далее. И всякие сценарийные карточки. И с помощью такого, казалось бы, довольно примитивного набора инструментов мы получили набор методик, воркшопов и способов общения с заказчиками, когда мы можем выкристаллизовать их идеи восприятия: где, как и в каких сценариях их конкретного бизнеса это может быть применимо, нужно ли это вообще. Недавно коллеги получили награду UX Magazine за эту работу. Мы сделали весь этот проект опенсорсным, на сайте можно всё это получить и увидеть наглядное видео.

О мобильной разработке

— Для начала хочется узнать: какое место мобильная разработка занимает в Futurice, сколько вы занимаетесь ей, а сколько немобильной? Является ли для вас какая-то мобильная платформа более приоритетной?

— Я бы сказал, что мобильная и веб — 50 на 50. Есть сезонность, бывают всплески активности, например, в связи с выпуском новых ОС и новых устройств, но в целом так. В отношении платформ — мы платформо-агностичные, стараемся быть во всех бизнесах, которые сейчас активны.

— Раньше у Futurice были громкие проекты на Windows Phone: например, в вашем докладе на Mobius 2015 было много таких примеров. За последние два годы рынок WP-разработки схлопнулся. Как на вас сказалось исчезновение важного рынка?

— Хороший вопрос, иллюстрирующий разные подходы. Очень ценный совет для разработчиков — быть прагматичными. Если для вас программирование — это профессия, которой вы собираетесь заниматься долго, то стоит очень прагматично относиться к рынку с его супербыстрым изменением технологий. Гигантские корпорации появляются и исчезают, а вы хотите оставаться востребованными.

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

Поэтому мы всегда, даже во времена Symbian, очень прагматично относились к взаимоотношениям с Nokia, хотя у нас с этим была связана значительная часть бизнеса, да ещё и сказывалась специфика Финляндии с большим проникновением телефонов Nokia. В результате, когда Nokia резко отходила от Symbian, другие сабконтрактинговые компании увольняли своих работников в этой области, а у нас никогда в жизни не было даже мысли, что если мы нанимаем специалиста технологии X, то при её исчезновении мы уволим его и наймём другого. У нас политика поиска и найма хороших талантливых работников, дизайнеров, консультантов, которые достаточно гибкие и готовы переключаться на другие технологии.

Когда Symbian, можно сказать, в числе одной недели исчез как бизнес и появился Windows Phone, у нас была очень мягкая transition между одним Nokia-миром и другим. И точно так же на протяжении последних двух лет, когда Windows Phone стал исчезать как бизнес, у нас происходит мягкая миграция наших проектов из одной сферы бизнеса в другую.

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

— К вопросу о начинающих разработчиках. Вы в своём свежем кейноуте говорили про резкий взлёт React Native, также растёт интерес к мобильному вебу. В итоге у начинающих возникают сомнения «стоит ли вкладывать время в изучение нативной мобильной разработки, или теперь везде веб, JavaScript и кроссплатформенность, и с нативной я окажусь невостребованным». Что вы можете им сказать?

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

И в итоге возник такой дефицит «нативных» кадров, что в текущей ситуации как раз толковому нативному мобильному разработчику очень легко найти работу. Ему, в принципе, можно её не искать, достаточно просто заявить где-то публично «я — native мобильный разработчик», и через пять минут у него будет работа.

А также важно понимать, что при всём росте популярности кроссплатформенной разработки самый бескомпромиссный доступ ко всем возможностям платформы, всегда будет с native SDK или native tools, которые предоставляются производителем этой платформы. И если мы говорим о first day release features, если Google или Apple выпускают новую ОС или новое устройство, то их поддержка гарантирована именно их инструментами, их SDK. А если вы используете кроссплатформенные решения и через некоторое время решаете копнуть глубже, чтобы обойти какие-то компромиссы вашего кроссплатформенного решения, то native-знания всегда оказываются полезными и востребованными.

Кроссплатформенные решения вроде React Native и Xamarin обладают своими плюсами и минусами, которые не всегда очевидны, потому что скорость создания мобильных приложений или доступ к каким-либо определённым платформенным фичам — не всегда прямой показатель, нужно ли вам использовать данное какое-то решение.

— Вы упомянули Xamarin, в Futurice его используют, и хочется спросить о судьбе проекта. Видно, что в Microsoft не просто «купили Xamarin и забыли», а развивают купленное (например, сделали Visual Studio for Mac на основе Xamarin Studio) — а по тому, что вы видите, насколько их усилия приводят к результату, оказывается ли Xamarin востребован?

— Xamarin — интересная вещь в том смысле, что в зависимости от страны его популярность может быть исключительно большой или исключительно маленькой. В Финляндии интерес, пожалуй, минимальный по сравнению с другими странами. Не знаю, связано ли это с тем, что местное сообщество разработчиков устало от разных решений Microsoft от покупки Nokia до её исчезновения. Но одно знаю точно: в тех странах, где традиционно большое число разработчиков на ASP.NET и C#, для них это, естественно, самый естественный способ прийти в мобильную разработку.

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

Tools для Xamarin под Mac пока гораздо более стабильные, чем под Windows. Регулярно и с той, и с другой стороны что-нибудь ломается, но это, в общем-то, естественный процесс. В случае с React Native люди тоже зачастую испытывают проблемы не с идеологической точки зрения, а из-за того, что ломается при выходе новой версии, сколько времени тратится на переконфигурацию своей среды. Такие же проблемы есть и с Xamarin, так что тут вопрос личных предпочтений.

— Интересно следить за тем, как в iOS-мире идёт переход к Swift: кто-то уже переписал всё своё приложение, а кто-то не хочет использовать новый язык, пока его новые версии не перестанут ломать код. Что с этим переходом в Futurice?

— Практически все новые iOS-проекты начинаются на Swift. А про те, где мы поддерживаем уже существующую кодовую базу на Objective-C, я бы не сказал, что кто-то из наших заказчиков вдруг резко начал переписывать свои существующие iPhone-приложения на Swift, там медленная постепенная миграция по мере возникновения необходимости.

Этот транзиционный период может быть долгим, но, зная Apple как компанию, очевидно, что за Swift будущее, и рано или поздно выбора просто не останется. Можно проследить это по всем их переходным процессам вплоть до перехода с классической Mac OS на OS X много лет назад, когда разработали Carbon специально для транзиционного периода.

— Вопрос в связи с вашими best practices по Android, набравшими на Хабре много просмотров. Как они появились: сначала был создан документ для внутреннего пользования, а потом его решили сделать публичным? У вас ведь, кроме этого, есть ещё похожие инициативы?

— Да, эта не единственная, но самая популярная — видимо, в связи с тем, что большинство мобильных телефонов в мире на Android.

У нас никогда не было конкретной установки «так, нам нужно написать best practices документ для нашего внутреннего использования, это будет наша догма, а потом мы можем выложить её для всеобщего обозрения». Это самостоятельные инициативы наших программистов. Когда есть желание создать такой документ, и такой документ создаётся. И поскольку мы можем быть замкнуты в своём понимании доменной проблемы, а у кого-то другого будут полезные советы, наши разработчики никогда не задумывались, делать это закрытым или нет, это сразу были публичные инициативы.

Так как у нас есть энтузиасты разных платформ, то Android best practices стали изначальной inspiration, и следом возник аналог для iOS и аналог для Windows, который со временем трансформировался из Windows Phone-документа в Universal Windows Platform-документ. Теперь Microsoft вот ещё и сделала XBox таргет-платформой для UWP, получается, что Windows Phone исчез, а Xbox появился.

А также у нас возникли инициативы про кроссплатформенной разработке, там это не best practices, а starter kits, помогающие писать меньше boilerplate: по React Native это Pepperoni, а по Xamarin — Xalami.

— А внутри самой компании ваши best practices соблюдаются неукоснительно, или есть причины от них отходить?

— С этим очень по-разному, и в этом, конечно, есть плюсы и минусы консалтинговой работы: не всегда получается применять best practices, которые ты хочешь использовать, в тех проектах, в которых ты работаешь. Это связано с очень многими факторами. Например, есть ли возможность использовать ту или иную библиотеку, вдруг какие-нибудь внутренние программные конфликты и что-то невозможно использовать. Или, например, уже существует большое количество кода, который написан определённым образом, а мы подключаемся в середине проекта. Или, например, отсутствие какого-то определённого специалиста. Так что каждый из проектов может не следовать всем best practices как догме, а использовать часть из них в зависимости от конкретных обстоятельств.

— А каков фидбэк сообщества по этим инициативам? Бывает ли такое, что люди с другой спецификой работы предлагают что-то, что вы в свои документы не готовы включать, а в итоге это приводит к форкам ваших best practices?

— Да, в этом вся прелесть open source-сообщества. Если вы предлагаете какие-то изменения и мы считаем, что они в данном контексте не вполне подходят, но в вашем собственном контексте они будут весомы и значимы — делайте свой форк и работайте над ним, это очень здорово!

Let's block ads! (Why?)

Как мы «Мисс Россию» на руках переносили

«Кубики» для магазинов: зачем реально нужна гиперконвергентность, и почему это не просто модное слово

Старая инфраструктура

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

В таких условиях мы внедряли Симпливити — один из первых проектов по внедрению решений такого класса в России. Запрос пришёл не в виде «подскажите решения», а в виде конкретной задачи «Есть столько мощности, нужен такой объём». Дальше получался либо набор из пяти дорогих железок, либо из двух дорогих, но на малознакомой шаманской Симпливити. Выбрали второе. Получилась единая инфраструктура с единым пространством и таким медленным обменом между площадками. Очень странная штука.

Сейчас расскажу, что шайтан-система делает. Забегая чуть вперёд — там и модная гиперконвергентность и главная фишка — глобальная дедупликация.

В каждом магазине работают 4–5 виртуальных машин. Часть из них относится к инфраструктуре: домен-контроллер, файловый сервер. Часть — специфичные приложения для торговли: управление весами, печать ценников и плакатов, сервисы аналитики. Все эти задачи уместились на маленькую систему из двух узлов SimpliVity OmniCube CN-1400.

Как видите, в данном проекте SimpliVity OmniCube — это кластеры из двух нод. На кластер ставится ВМваре, в каждом сервере — внутренние диски. Пространство дисков выдаётся на виртуальную машину. Полезное пространство объединяется в единую систему хранения — и отдаются обратно на сервера. SDS как ScaleIO или RAIDIX, только функционал рассчитан немного на другое. Основное — не надо иметь отдельную систему хранения данных, только диски серверов.

Узлы соединены между собой по сети 10 GbE напрямую, поэтому не нужны дорогие 10-гигабитные коммутаторы в магазинах. ПО виртуализации — VMware vSphere. Получился типовой комплект инфраструктуры для нового магазина «в коробке». При открытии нового магазина не нужно заново ломать голову насчёт серверного оборудования, достаточно взять пару кубиков SimpliVity. Кластеры SimpliVity в разных магазинах видят друг друга и управляются централизованно. Резервные копии ВМ делаются раз в день и хранятся две недели. Одна резервная копия хранится локально, чтобы быстро поднять данные при их случайном удалении или логическом повреждении. Вторая хранится на SimpliVity в соседнем магазине. Хранилище второго кластера не зависит от первого.

Это довольно дорого из расчёта на одно внедрение (можно сделать аналогично дешевле на других решениях), но если считать вместе со временем работы админа, охлаждением, энергией, стоимостью поддержки и её продления в будущем, и учесть, что всё это добро заменяет весь традиционный стек/инфраструктуру, то получается очень даже прилично и красиво. Дело в том, что тут «всё в одном», очень простой набор компонентов. Нужно всего поладмина со знаниями ВМвары. Решение легко масштабируется на любое количество узлов. Главное, чтобы не было мегажирной базы данных, для такого у совсем больших пацанов есть all-flash массивы. Главный кейс — филиалы и фермы терминалов пользователей. В процессе тестирования также открылось, что очень приятно эта штука работает с плохими каналами — благодаря встроенной оптимизации каналов связи и встроенной дедупликации на лету.

В итоге магазины открываются по несколько штук в год в дополнение к тем восьми, что уже есть. Это по размерам типа Метро. Офисы в них на 30 активных пользователей. Выбрали они типовое решение по ИТ-инфраструктуре для локальных приложений. Планировалось открытие новых магазинов, а в существующих нужно было менять устаревшее железо. Так как ИТ-специалисты занимаются не только инфраструктурой, решение должно быть максимально простым и управляться централизованно. В идеале заказчик искал одну готовую коробку, которую можно растиражировать по магазинам и вообще забыть о том, что в них есть ИТ-инфраструктура.

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

Тестирование

Вот отчёт с наших тестов решения (прошлогодний отчёт перед внедрением). Пациентом был двухнодовый SimpliVity CN-3400.

Каждая нода представляет собой двухюнитовый rack-сервер Dell R720 с фирменной лицевой панелью SimpliVity и особой PCIe карточкой внутри — OmniStack accelerator card (OAC). В каждом сервере установлено 2 проца E5-2680v3, 24 планки 16GB DDR3 и 24 диска (4 SSD 400GB, 20 HDD 1TB 7,2k SAS).

На передней части под лицевой панелью установлены 24 диска — 4 SSD и 20 2,5-дюймовых SAS-дисков. С обратной стороны два разъёма питания, пять сетевых портов, сервисный порт карты OAC и два системных HDD 300GB 10K SAS.

SimpliVity CN-3400, вид сзади

Omnistack Acccelerator Card с двух сторон

В типовом случае, каждый сервер подключается двумя 10 Гбит соединениями к сети данных, двумя 1 Гбит к сети управления и один интерфейс требуется для консоли управления сервером IPMI (iDRAC). Это лишь один из вариантов подключения. Можно не подключать в гигабитную сеть, а использовать 10GbE как для кластерной сети, так и для трафика ВМ. Также можно добавить сетевые карты и выделить несколько дополнительных портов. В случае двухнодовой конфигурации в организации 10-гигабитной сети вообще нет необходимости — достаточно подключить ноды напрямую друг к другу двумя DAC-кабелями.

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

В нашем случае vCenter был установлен на выделенный Windows Server. vCenter Server Appliance так же поддерживается.

Нам удалось протестировать несколько способов инициализации системы. Это связанно с тем, что предоставленный комплект мы тестировали первыми в России (напомню, тест был в прошлом году). И на нём была установлена версия системы поколения 2.x. В случае данной версии процедура была следующей. Установленный vCenter требует дополнительной подготовки: необходимо добавить нового пользователя svtuser и сконфигурировать виртуальные коммутаторы. Все настройки описаны в брошюре, приложенной к системе.
После выполнения рекомендаций по подготовке существующей инфраструктуры, следует задать IP-адреса системы, произвести подключение нод к vCenter, создать федерацию SimpliVity и инициализировать VMware cluster. Всё выполняется при помощи простого мастера, идущего в комплекте вместе с системой на обычной флешке. Во время настройки будет установлен арбитр, предназначенный для выбора главной ноды в случае сплитбрейна. Его можно установить, как на хост vCenter, так и на отдельный сервер.

После обновления системы до актуальной версии (3.5.x), мы попробовали выполнить инициализацию системы заново. В последних версиях установка делается с помощью Deployment Manager, ему нужен только доступ к vCenter, всё остальное он делает сам.
На этом предварительная настройка заканчивается и во вкладке vCenter — SimpliVity federation можно создавать необходимые датасторы, расписания резервного копирования и использовать остальной функционал.

В целом настройка системы довольно простая и при верном соблюдении приложенной инструкции трудностей не вызывает. Если нет необходимости обновлять поставленную систему (заранее подготовлены IP-адреса и настроен vCenter), то разворачивание системы, включая монтаж в стойку, коммутацию и первичную настройку, займёт около 30 минут.
В разделе SimpliVity Federation в vCenter можно мониторить производительность, физическую/логическую ёмкость, коэффициенты дедупликации и компрессии, управлять политиками резервного копирования.

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

После создания снепшота из него можно восстановить как целую ВМ, так и отдельный файл (с гранулярностью до файлов восстанавливаются только виртуальные машины с ОС Windows). При восстановлении виртуальной машины можно выбрать «заменить существующую виртуальную машину» или «создать новую». При этом, любую резервную копию можно вручную восстановить в любом удалённом ЦОД.

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

Производительность
Для замера производительности использовался VMware IO Analyzer 1.6.4 с параметрами виртуальной машины: VM version: 7, vCPU: 1. Memory: 2 ГБ, VD: 16 ГБ; OS: SUSE Linux Enterprise 11. В среднем получили результат 7 560 IOPS при нагрузке (8K, 50/50w/r, NoRandom), 20 352 IOPS для AllRandom. Это всё мимо кеша.

Все наши любимые краш-тесты с выдиранием дисков на ходу, прерыванием интерконнектов и отключением нод система тоже успешно пережила и при возвращении компонентов корректно восстанавливала своё состояние. Влияние на производительность системы при всех наших издевательствах была минимальна, не считая отключение интерконнекта. Он помог ускорить систему в 2 раза! (Но лишившись синхронной репликации между нодами).
Вывод: железка интересная, так как даёт возможность заменить практически все элементы традиционной архитектуры ЦОД набором rack-серверов и коммутаторов. Система хорошо справляется с распределёнными нагрузками, но плохо подходит для консолидированных. Никаких однопоточных приложений или больших баз.

Результат в магазине

Внедрение заняло 2 дня, по дню на площадку. Проработка решения и тестирование заняли полгода. Большую часть времени делали поставку оборудования и обкатывали тесты. Заказчик рассматривал различные продукты, которые обещают «инфраструктуру в коробке»: гиперконвергентные системы и модульную платформу. Остановились на SimpliVity, потому что не нужен отдельный софт для бекапа, все машины видно из единого центра — там вообще всё управление, а не россыпь консолей, очень хорошее отношение к отстойному каналу из-за продвинутой дедупликации. Например, при ежедневном полном бекапе ВМ с 220 ГБ использованной ёмкости по каналу связи пролетает 570 МБ. А полный бекап всей инфраструктуры завершается за 2-3 часа. Для админов это звучало как фантастика, но это работает по факту теперь.

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

Итог: в магазин ставится два сервера, за 5 минут настраивается бекап. Всё.

P.S. Спасибо «Марвел Дистрибуция» за предоставленное оборудование для тестов. Они же поставляли боевые системы для заказчика.

Let's block ads! (Why?)