Доброго времени суток, Хабрачане!

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

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

За долгие годы написания статей про игры я рассказал о многих удивительных глитчах, неизвестных с давних пор кодах, трюках с выполнением произвольного кода и поисках глубоко сокрытого контента внутри классических игр и оборудования. Но ничто не смогло подготовить меня к этому видео с Twitch, в котором флот летающих Arwing из Star Fox 64 вторгаются в мир Ocarina of Time, чтобы напасть на Линка.

Подобную сцену ожидаешь увидеть только в созданном фанатом мультфильме или ROM-хаке, которые Nintendo так любит изымать из Интернета. Но самое удивительное в этом клипе то, что он демонстрирует немодифицированную версию оригинального японского ROM Ocarina of Time с использованием стандартной консоли и контроллеров N64.

Целое утро я разбирался с тем, как такое вообще возможно. Чтобы объяснить это, придётся совершить глубокое погружение в суть инструкций машинного языка Nintendo 64, управления памятью Ocarina of Time и самого процесса разработки игр середины 90-х. Если вам так же любопытно, как и мне, присоединяйтесь.

Новый год для игровых разработчиков начался с волны критики, обрушившейся в адрес комитета по стандартизации C++ после публикации Араса Пранкевичуса «Жалобы по поводу современного C++». Возник серьезный вопрос: действительно ли комитет стандартов потерял связь с реальностью, или все наоборот, и это игровые разработчики откололись от остального С++ сообщества?

Вашему вниманию предлагается перевод популярного поста Бена Дина, — ветерана игровой индустрии, проработавшего продолжительный срок в компаниях Blizzard, Electronic Arts и Bullfrog в качестве разработчика на C++ и тимлида, — в котором он отвечает на критику с позиции собственного опыта.

TL;DR: Комитет по стандартизации C++ не имеет скрытой цели игнорировать нужды игровых разработчиков, а «современный» C++ не собирается становиться «неотлаживаемым» языком.

На протяжении всей прошлой недели в Twitter шла активная дискуссия, в ходе которой многие программисты – особенно те из них, кто работает в сфере игровой разработки – высказались о том, что нынешний вектор развития «современного C++» не отвечает их потребностям. В частности, с позиции обычного игрового разработчика, все выглядит так, будто производительность отладки в языке игнорируется, а оптимизация кода становится ожидаемой и необходимой.

В силу того, что на 2019 год я успел проработать в игровой индустрии более 23 лет, у меня имеется собственное мнение, основанное на наблюдениях по данной теме применительно к игровой разработке, которым мне и хотелось бы поделиться. Важна ли для игровых разработчиков «отлаживаемость» и почему? В чем заключаются вопросы, связанные с ней?

Для начала — небольшой экскурс в историю.

Проблемы с ограничениями памяти давно в прошлом?

Оказывается, нет. Плохо работают с памятью не только некоторые коммерческие движки — у многих платформ достаточно агрессивные требования к ОЗУ. Кроме того, к ним добавляются ещё и ограничения по размерам дисков и картриджей.

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

Привет, Хабр. С вами Владимир Разуваев. В Softline я руковожу департаментом бизнес-консалтинга и практически все свое свободное время я посвящаю спорту. В этом посте я расскажу о своем опыте подготовки к соревнованиям Ironman. В процессе мне сильно помогли навыки проектного менеджмента. Благодаря им я разложил казавшуюся недостижимой суперцель на задачи, нашел тренера и сам стал для него заказчиком и исполнителем, полностью перенастроил свою жизнь под будущее спортивное достижение, при этом не остался без семьи, но полностью провалил ту часть подготовки, которая была связана с бюджетом. Если для вас это звучит достаточно драматично – прошу под кат.

[Когда график поджимает и проект уже пора выпускать, программисты могут прибегать к грязным трюкам, чтобы уже наконец выпихнуть игру за дверь. В этой статье собрано девять примеров таких «костылей» из реальной жизни.]

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

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

Предыстория. Так получилось, что моя юность пришлась на время появления 3д игр. Впервые увидев спектрумовский Total Eclipse я сразу стал считать 3д вершиной технологий. Вскоре появились IBM-совместимые компьютеры с известными Вольфенштейном и Думом. Я был впечатлен. Имея склонность к программированию я начал пробовать повторить их. Была середина девяностых, у меня был медленный QuickBASIC, 5х86 комп и ноль опыта. Ничего не вышло. Ну, почти ничего.

Введение

Почему псевдо-3d?

Зачем кому-то захочется создавать дороги в олдскульном стиле сегодня, когда каждый компьютер может на лету отрисовывать графику, состоящую из миллионов полигонов? Разве полигоны — не то же самое, только лучше? На самом деле нет. Полигоны действительно создают меньше искажений, но именно деформации в старых игровых движках дают такое сюрреалистическое, головокружительное чувство скорости, ощущаемое во многих дополигональных играх. Представьте, что область видимости управляется камерой. При движении по кривой в игре, использующей один из таких движков, похоже, что она заглядывает на кривую. Затем, когда дорога становится прямой, вид тоже выпрямляется. При движении в повороте с плохим обзором камера как будто заглядывает за выступ. И поскольку в таких играх не используется традиционный формат трасс с точными пространственными соотношениями, то можно без проблем создавать трассы, на которых игрок будет ездить с захватывающей дух скоростью. При этом не нужно беспокоиться о том, что объекты появляются на трассе быстрее, чем может среагировать игрок, потому что физическую реальность игры можно легко изменять в соответствии со стилем геймплея.

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

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

Я потратил две недели на чтение и реверс-инжиниринг исходного кода Another World (в Северной Америке игра вышла под названием Out Of This World). Моя работа основана на обратной разработке Грегори Монтуа (Gregory Montoir) оригинального исполняемого файла для DOS из двоичного кода в C++.

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

Всё это умещалось на гибкий диск ёмкостью 1,44 МБ и работало на 600 КБ ОЗУ. Совсем неплохо для 1991 года! Как обычно, я привёл свои заметки в порядок — это поможет кому-нибудь сэкономить несколько часов работы.

В очередной статье нашего цикла публикаций, посвященного интернет-разведке, рассмотрим, как операторы продвинутого поиска Google (advanced search operators) позволяют быстро находить необходимую информацию о конкретном человеке.

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

Хочу поделиться своим опытом работы со Spine — программой для создания скелетной анимации, специально заточенной под игры.

После просмотра официального гайда возникает много вопросов, поговорим про то, какие подводные камни ожидают нас при работе с этой программой на каждом этапе рабочего процесса (на примере Spine — Unity), как можно оптимизировать свою работу, а так же рассмотрим некоторые популярные фишки типа 3D эффекта. В статье будет много тяжелых гифок.

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

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

Разработчик Дмитрий Лукьяненко, чью лекцию мы публикуем сегодня, не только является специалистом Яндекса, но и умеет проверять на прочность решения разработчиков других компаний. Это позволяет учиться на чужих ошибках — не исключая порой своих, конечно. В докладе Дмитрий поделится примерами Android-уязвимостей, в том числе найденных им собственноручно. Каждый пример сопровождается рекомендациями — как нужно и как не нужно писать приложения под Android.



Меня зовут Дмитрий, я работаю в компании Яндекс в минском офисе, занимаюсь разработкой аккаунт-менеджера. Это библиотека, которая отвечает за авторизацию пользователей. Поэтому мы поговорим о безопасности Android-приложений.

Введение

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

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

Я предполагаю, что читатель имеет опыт в разработке под Android и знаком с классами Canvas, Drawable и Bitmap.

Код, используемый в статье, можно найти на GitHub.

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

С развитием HTML5 и мобильных платформ 2D-игры возвращаются в моду. Заниматься такими проектами, будь то браузерные игры, игры на телефон или для ПК, стало легче благодаря таким инструментам, как Unity, и онлайн-ресурсам с игровыми ассетами. Ниже представлен список из 10 лучших сайтов с 2D-ресурсами для игр – как платными, так и бесплатными.

Как построить график по n точкам? Самое простое — отметить их маркерами на координатной сетке. Однако для наглядности их хочется соединить, чтобы получить легко читаемую линию. Соединять точки проще всего отрезками прямых. Но график-ломаная читается довольно тяжело: взгляд цепляется за углы, а не скользит вдоль линии. Да и выглядят изломы не очень красиво. Получается, что кроме ломаных нужно уметь строить и кривые. Однако тут нужно быть осторожным, чтобы не получилось вот такого:

Если Вам интересно, как вызов метода ClassLoader.getResourceAsStream() в Android приложении может занимать 1432ms и насколько опасны могут быть некоторые библиотеки — прошу под кат.

Наше путешествие от стандартных Activity и AsyncTask'ов к современной MVP архитектуре с применением RxJava.

Код проекта должен быть разделён на независимые модули, работающие друг с другом как хорошо смазанный механизм — фото Честера Альвареза.

Экосистема средств разработки под Android развивается очень быстро. Каждую неделю кто-то создаёт новые инструменты, обновляет существующие библиотеки, пишет новые статьи, или выступает с докладами. Если вы уедете в отпуск на месяц, то к моменту вашего возвращения уже будет опубликована свежая версия Support Library и/или Google Play Services.

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