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

Даже пустой проект в Unity весит очень много. Пустой проект под Android с настройками по умолчанию в Unity 2017.1 весит 21637 КБ. Однако его можно очень легко уменьшить до 11952\12412 КБ, указав платформу для компиляции (ARMv7 и x86 соответственно).

По аналогии с этим, можно еще попробовать еще немного уменьшить вес, выбрав Graphic API. Если выбрать OpenGLES2 вместо Auto Graphics API, можно сэкономить еще 236 КБ (11716 вместо 11952). Выгода незначительна и возможна потеря в производительности, так что этого делать я не рекомендую.

Теперь поговорим о содержимом проекта. Рассмотрим 2D игру с большим количеством спрайтов.
Есть вероятность, что многие спрайты будут симметричными по одной или нескольким осям.

В геймдеве часто нужно что-нибудь завязать на рандоме: у Unity для этого есть свой Random, а параллельно с ним существует System.Random. Когда-то давно на одном из проектов сложилось впечатление, что оба могут работать по-разному (хотя должны иметь равномерное распределение).

Тогда в детали углубляться не стали — хватило того, что переход на System.Random исправил все проблемы. Сейчас решили разобраться подробнее и провести небольшое исследование: насколько «предвзяты» или предсказуемы ГСЧ, и какой выбрать. Тем более, я не раз слышал противоречивые мнения об их «честности» — попробуем разобраться, как реальные результаты соотносятся с заявленными.

Всем привет! Меня зовут Дядиченко Григорий, и я основатель и CTO студии Foxsys. Сегодня хочется поговорить про шейдеры. Умение писать шейдеры (и в целом работать с рендером) очень важно при разработке под мобильные платформы или AR/VR, если хочется добиться крутой графики. Многие разработчики считают, что шейдеры — это магия. Что по ним мало хорошей информации, и что чтобы их писать нужно иметь, как мимимум, звание кандидата наук. Да, разработка шейдеров по своим принципам сильно отличается от клиентской разработки. Но основное понимать базовые принципы работы шейдеров, а так же знать их суть, чтобы в этом не было ничего магического и поиск информации по этой теме был простой задачей. Данная серия статей рассчитана на новичков, так что если вы разбираетесь в программировании шейдеров, данная серия вам не будет интересна. Всем же кто хочет разобраться в этой теме — добро пожаловать под кат!

Привет Хабр.

Raspberry Pi наверное есть дома почти у каждого, и рискну предположить, что у многих она валяется без дела. А ведь Raspberry это не только ценный мех, но и вполне мощный fanless-компьютер с Linux. Сегодня мы рассмотрим полезные возможности Raspberry Pi, для использования которых код писать не придется совсем.

Для тех кому интересно, подробности под катом. Статья рассчитана для начинающих.

Вы потратили бесконечное количество времени на оптимизацию Unity UI. Но для того, чтобы вызвать торможения, достаточно небольшой модификации крошечного атрибута почти невидимого элемента UI Canvas. И когда такое случается, даже профилирование Unity UI не спасёт вас от снижения FPS. Вы готовы долгому исправлению ошибок?

Именно это и произошло в моём последнем проекте...

Я упорно работал над оптимизацией нескольких панелей UI в порте нашей игры на Oculus Quest. В основном задача сводилась к снижению уровня перерисовки (overdraw) до приемлемых величин, чтобы GPU мог справляться с самым главным — реальным 3D-рендерингом.

Так я работал над оптимизацией Unity UI не меньше месяца, и со временем добился чертовски неплохого прогресса.

На каком-то этапе UI стал настолько оптимизированным, что едва влиял на тайминги GPU. Реализованные мной техники затемнения непрозрачного UI компенсировали большую часть перерисовок, вызванных наслоением UI (элементами, отрисовываемыми поверх других элементов).

Итак, у меня получилась сверхоптимизированная гибридная система UI, которая по сути перекрывала отрисовываемые под ней 3D-элементы. Стало очень легко отбрасывать рендеринг этих перекрытых фрагментов.

Однако работа ещё была далека от завершения...

Когда я подключил Unity UI Profiler, моё внимание привлекла одна вещь.

Я увидел, что перегруженный ЦП тратит в каждом кадре более 1 мс на рендеринг UI. Это куча времени для платформы, которая даёт тебе бюджет в 13 мс на выполнение всей игры: физики, логики, 3D-рендеринга, ввода, VR и сетевого кода.

И ведь бывали случаи, когда UI «убивал» производительность ЦП ещё сильнее.

*FAANG — акроним 5 крупнейших tech компаний (Facebook, Apple, Amazon, Netflix and Google), предоставляющих одни из самых хороших возможностей для разработчиков, которые мечтают/планируют/хотят приобщиться к волне IT-эмиграции.

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

К сожалению, на практике подобный процесс поиска работы часто заканчивается неудачами. Сайты со списком вакансий — один из самых низкоэффективных способов, по крайней мере в США.

Под катом я поделюсь практическими рекомендациями, которые помогут «твикнуть» систему и существенно увеличить шансы на получение предложения от топ-компаний в сжатые сроки.

На прошлой неделе мы говорили в своём блоге об изменениях, которые позволят врагам (biters, кусакам) не наталкиваться друг на друга, но это было не единственное обновление, связанное с biter-ами. Совпало так, что в обновления этой недели вошло то, над чем мы работали предыдущие несколько недель — обновление системы поиска пути для врагов.

Поиск пути

Когда юнит хочет куда-то переместиться, ему сначала нужно понять, как туда добраться. В самом простом случае можно двигаться прямиком к цели, но на пути иногда возникают препятствия — скалы, деревья, гнёзда врагов (spawners), юниты игрока. Чтобы проложить дорогу, мы должны сообщить функции поиска пути (pathfinder) текущую и конечную позиции, а pathfinder вернёт нам (возможно, через много тактов) путь, который просто является набором промежуточных точек (waypoints), по которым должен двигаться юнит, чтобы добраться до места назначения.

Для выполнения своей работы pathfinder использует алгоритм под названием A* (произносится «A star»). Простой пример поиска пути при помощи A* показан на видео: biter хочет найти путь в обход скал. Функция поиска пути начинает исследовать карту вокруг biter-а (исследование показано белыми точками). Сначала она пытается пойти напрямик к цели, но как только достигает скал, «разливается» в обе стороны, пытаясь найти позицию из которой снова можно будет двигаться к цели.

Я занялся изучением процессов распознавания коллизий, и это привело меня к алгоритму Гилберта — Джонсона — Кирти (Gilbert-Johnson-Keerthi, GJK).

Все примеры кода в посте написаны на TypeScript. В примерах используются созданные мной структуры, которые подробно в посте не рассмотрены. Они просты и их можно посмотреть в репозитории GitHub:

• Vector
• IShape
• Collision

Весь код из поста хранится в репозитории GitHub:

https://github.com/jthomperoo/gjk-ts-implementation

Пост написан на основании этой статьи и рекомендованного в ней видео:

• http://www.dyn4j.org/2010/04/gjk-gilbert-johnson-keerthi/
• http://mollyrocket.com/849

Введение

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

Короткий мануал — как реализовать поддержку загрузочного NVMe SSD на старых материнских платах с Legacy BIOS и с использованием Clover (для любых ОС). По следам вот этого поста, где на мой взгляд, решение не так изящно и не для всех BIOS & OS.

В StackOverflow по-прежнему появляется много вопросов о валидации App Store чеков, поэтому мы решили написать статью на эту тему в формате вопросов и ответов.

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



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

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

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

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

Процедурная генерация используется для повышения вариабельности игр. Среди известных проектов можно упомянуть Minecraft, Enter the Gungeon и Descenders. В этом посте я объясню некоторые из алгоритмов, которые можно применять при работе с системой Tilemap, появившейся как 2D-функция в Unity 2017.2, и с RuleTile.

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

О чём этот пост?

Мы рассмотрим одни из самых распространённых способов создания процедурных миров, а также пару вариаций, созданных мной. Вот пример того, что вы сможете создавать после прочтения статьи. Три алгоритм работают вместе, создавая карту при помощи Tilemap и RuleTile:


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

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

Уже более 10 лет я работаю гейм-дизайнером в очень успешных компаниях (старшим гейм-дизайнером в Matific, ведущим гейм-дизайнером в TabTale, владельцем Lookandfeel Games), и всё это время обладал привилегией и возможностью использования данных, полученных от сотен миллионов пользователей со всего света. Настало время поделиться моими знаниями с миром.

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

«Жаль вас разочаровывать, но ваша идея не сработала».

Разочаровывать? С какой стати! Спасибо за то, что дали мне возможность переосмыслить свой дизайн, чтобы я не заблуждался в его правильности. Как иначе бы я мог совершенствоваться? Как иначе достигнуть мастерства? Благодаря анализу данных хорошие идеи дублируются и применяются в моих следующих проектах, а «пробные шары» в соответствии с ним улучшаются или отбрасываются. Вот «библи»я моих рекомендаций с уроками, почерпнутыми из 250 с лишним игр. Данные подтвердили, что они повышают монетизацию, удерживание игроков (retention), игровой процесс и вовлечённость (engagement).

Представляем вам перевод статьи Sm0ke, опубликованной на сайте dev.to. Автор рассказывает о своем опыте генерации веб-приложений и способе автоматизации процесса их создания.

Привет, кодеры!

Я — разработчик-фрилансер, и я сгенерировал более 100 приложений на различных языках и платформах, используя инструменты автоматизации, парсинг HTML и бойлерплейт-код.

Все мои приложения, как платные, так и бесплатные, находятся в открытом хранилище GitHub. О некоторых из них я расскажу в этой статье.

#1  Сгенерированные JAMstack-приложения

Всего я создал более 40 таких приложений. Дизайн для них разрабатывали известные веб-агентства.

Доброго Хактоберфеста, дамы и господа. Подготовил для вас подборку самых интересных находок из опенсорса за сентябрь 2019.

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

В сегодняшнем выпуске.
Технологии внутри: Python, C, Rust, Ruby, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.

Прошлый выпуск.

Nitter — это свободный фронтенд для Twitter, ориентированный на сохранение конфиденциальности пользоватей. Написан на языке Nim, и находится в стадии активной разработки (ни одного релиза пока не было). Аналогом для YouTube является Invidious, который и вдохновил автора на создание проекта.

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

За последние два месяца я создал целых 9 новых действий игрока (такие забавные вещи как блокировка щитом, уворачивание в прыжке и оружие), 17 новых носимых предметов, 3 набора брони (пластинчатый, шёлковый и кожаный) и 6 видов причёсок. Также я завершил создавать всю автоматизацию и инструменты, поэтому всё уже используется в игре. В статье я расскажу, как этого добился!


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

Краткое описание

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

Разумеется, такие функции активно используются в 3D- и 2D-играх с пререндеренными спрайтами или в 2D-играх со скелетной анимацией, но насколько я знаю, существует не так много игр, совмещающих созданную вручную анимацию и модульных персонажей (обычно потому, что процесс оказывается слишком монотонным).

Вступление

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