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

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

1. Пиши на UnityScript

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

2. Не используй var

Сами Unity запрещают^* это делать, да и вообще непонятно, какого типа переменная. Когда тебе скажут про подсказки IntelliSense — закатывай глаза, майкрософт головного мозга! Твой Notepad++ этого не умеет.

3. Смешивай стили

Ну а что? Сами Unity нарушают C# Style Guide и фигачат camelCase в пропертях, чем ты хуже? Если используешь MonoDevelop, не забывай периодически менять табы на пробелы и обратно. При этом говори всем, что в MonoDevelop «настройки слетели» — про этот баг все знают!

Все началось с того, что я получил тестовое задание на вакансию Unity-разработчика: написать игру «Змейка». Чуть позже от вакансии по субъективным причинам пришлось отказаться, но к тому времени я уже начал делать проект и, чтобы не пропадать работе, решил его развить, закончить и выпустить. Так я обзавёлся своей «Змейкой», которую никогда до этого делать не собирался.

Осознавая что мои статьи похожи на восторг человека, впервые увидевшего какую-то (многим уже давно знакомую) вещь, все же решил написать очередную. Причина — заинтересовавший меня параметр drag у компонента Rigidbody. Объяснений и, тем более, формул — как он работает — руководства не дают. Поэтому разбираться придется самому.

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

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

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

Доброго времени суток! Вот и закончил я разработку своей первой игры на Unity для Android. Причиной разработки игры послужил анализ вакансий на hh. Стало интересно, отчего же разработчикам игр работодатели готовы платить серьезные суммы. Ведь по сути мы (разработчики), в идеале, можем быть самодостаточными, т.к. практически каждый серьезный программист в состоянии сам создать достойный продукт и заниматься его продажей и продвижением. Мне кажется с созданием не должно возникнуть серьезных вопросов (кроме художественной части, ибо я не встречал пока прекрасного художника с отличными навыками в программировании), а вот бесплатное продвижение продукта, это тайна — по крайней мере сейчас и для меня.



Перейдем собственно к самой игре. У меня двое маленьких детей и они часто играют в детские игрушки на телефоне, эдакие «отвлекалки». Естественно они тапают по рекламным баннерам с завидной частотой, чем не мало радуют разработчиков данных игр. Вышеперечисленные обстоятельства натолкнули меня на мысль о создании чего-то подобного, но не на отъе… сь (многие детские игры не блещут аккуратностью), а красивого и приятного глазу. При выборе темы, время года само продиктовало мне решение. Была выбрана новогодняя/рождественская тематика. Геймплей должен был получиться очень простой, но веселый и красочный. Тут начались работы головы на тему того, какие элементы реализовать в игре. В итоге на сцену было решено поместить следующие элементы: новогодние шары, ёлку, деда мороза пролетающего по таймеру и танцующего оленя со снеговиком.

В цикле статей «Особенности разработки мобильной MMO RTS» мы расскажем о работе большой команды над масштабным проектом Stormfall: Rise of Balur. Этот опыт будет полезен независимым разработчиками и студиям, которые еще не определились с выбором технологий, архитектуры и структуры команды для своей RTS.

Привет Хабр. Хочу поделиться опытом в разработке игры-викторины на Unity 5 версии. Замечу, что подобная игра уже выпускалась мной в 2014 году и набирала 7800 скачиваний. Из-за ужасной реализации игра заработала 80% удалений и проект был заброшен. Попробуем запустить игру по новой, исправив ошибки предшественника.

В статье рассмотрим такие темы как:

1. Идея игры
2. Структура проекта
3. Особенности игровой логики и способы реализации
4. Внедрение инструментов монетизации in app purchase и официального плагина AdMob
5. Продвижение

Результат: информация о цвете занимает 1/64 от исходной площади при достаточно высоком качестве результата. Тестовое изображение взято с этого сайта.

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

В этом руководстве собраны базовые ссылки и рекомендации, которые могут послужить вам точкой отсчёта в освоении VR-разработки.

1. Изучаем оборудование

Спросите себя: меня интересует разработка для десктопных устройств, наподобие HTC Vive, или меня больше привлекают мобильные устройства вроде Samsung Gear VR или Google Cardboard? Если вы пока не определились, то почитайте обзоры и подумайте о том, что лучше выбрать для вашего рынка. Если для ваших идей требуются контроллеры движения или качественная графика, то ориентируйтесь на подключаемые к компьютеру очки VR. Модели, которые сегодня поддерживаются движками Unity, Unreal и веб-реaлизациями:

Второго декабря, в пятницу мы впервые приглашаем разработчиков на Unity Moscow Meetup, который пройдет в московском офисе Mail.Ru Group. Они смогут обменяться опытом использования Unity3D, идеями и современными подходами к разработке, а также завести новые контакты.

На первой же встрече участников ждет доклад разработчика из Unity! Программу смотрите под катом.

После того как я закончил мой первый проект, пришла мысль о портировании его на мобильные устройства или хотя бы запуске на встроенном GPU. Во всех гайдах по оптимизации, в одном из первых советов вам сообщат, что не стоит переживать о производительности заранее, начинайте оптимизировать, после того как все закончите, и вы постепенно приведете все в порядок. Так и я, выпустив изначально игру на десктоп, решил, что никогда не будет поздно оптимизировать ее под мобильные устройства. К сожалению, мне не удалось в полной мере достичь поставленной цели, потому как, похоже, что мобильные игры следует с самого начала разрабатывать с прицелом на слабое железо. На данный момент, для дальнейшей оптимизации под мобильные платформы я вижу только необходимость серьезно переделать геймплей и дизайн игрового мира. Однако и в текущем варианте получен ценный опыт оптимизации под Unity3d и результирующий прирост производительности более чем в 300% на интегрированном GPU.

В рамках конференции White Nights Moscow 2016, мы пообщались с Олегом Придюком, евангелистом международной компании по разработке игр King.



До King Олег успел поработать в Unity Technologies, затем занимался разработкой игр в Game Insight. В рамках King Олег развивает идею стриминга процесса разработки игр, организовывает круглые столы по игровым движкам и занимается геймджемами.

Из интервью вы узнаете:

• Что такое Defold Game Engine?
• Как бесплатно продвигать движок для игры?
• Что круче: Unity или Defold?
• Как совершить кругосветное путешествие за 21 день за счет компании?

А под катом мы расскажем о процессах разработки игр в King: какие движки использует компания, и какие требования предъявляются к разрабатываемым играм.

Можете ли вы представить игру для Android, сделанную в Unity, которая использует больше 64K методов Java? Не удалось это и архитекторам байт-кода Dalvik. Возможно, у них получилось (я не читал спецификации), и винить следует другие элементы тулчейна. Как бы то ни было, если ваша игра превышает ограничение в 64K методов на файл DEX, вам придётся ковыряться в своих нативных плагинах и/или процессе сборки. Этот пост является попыткой показать различные способы решения проблемы.

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

Глобальное освещение, динамический свет и декали (да, есть такое слово :) ) в действии.

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

Ужасные мучения

Текстурирование и создание игровых материалов всегда были интересной… и мучительной работой одновременно. До перехода на Substance Designer я использовал для создания всех нужных карт Photoshop и xNormal. Приходилось много раз переключаться между двумя этими приложениями, и это надоедало. Теперь я избавился от этой проблемы.

Substance Designer (SD) — это программное обеспечение, позволяющее создавать материалы и текстуры «на лету». В нём используется удивительно простая система узлов. Я художник, и обычно меня очень пугала работа с узлами (и вообще всем, кроме кисти). Честно говоря, когда я впервые увидел SD, то слегка вздрогнул. К счастью, у авторов программы есть видео, демонстрирующие её возможности. Они дают такого мотивирующего «пинка», что вам приходится совершить «прыжок веры».

Помните небезызвестный мем про "корованы"? Наверное, каждый, кто разрабатывает игры (или хотел бы этим заняться) раздумывает о неком "проекте мечты", где можно будет "грабить корованы" и "набигать". А ещё, чтобы погода менялась динамически, и на грязи следы от сапог оставались, и деревья росли в реальном времени. И ещё, чтобы ...

Понятно, что в реальном игровом проекте такая погоня за хотелками — смерти подобна. А вот в техно-демке — самое то.

Я опубликовал первую статью «50 советов по работе с Unity» 4 года назад. Несмотря на то, что бóльшая её часть всё ещё актуальна, многое изменилось по следующим причинам:

• Unity стал лучше. Например, теперь я могу доверять счётчику FPS. Возможность использования Property Drawers снизила необходимость написания пользовательских редакторов (Custom Editors). Способ работы с префабами стал меньше требовать заданных встроенных префабов (nested prefabs) и их альтернатив. Скриптуемые объекты стали более дружелюбными.
  
  
• Улучшилась интеграция с Visual Studio, отладка стала намного проще и уменьшилась потребность в «обезьяньем» дебаггинге.
  
  
• Стали лучше сторонние инструменты и библиотеки. В Asset Store появилось очень много ассетов, упрощающих такие аспекты, как визуальная отладка и логирование. Большая часть кода нашего собственного (бесплатного) плагина Extensions описана в моей первой статье (и многое из него описано здесь).
  
  
• Усовершенствован контроль версий. (Но, может быть, я просто научился использовать его более эффективно). Например, теперь не нужно создавать множественные или резервные копии для префабов.
  
  
• Я стал более опытным. За последние 4 года я поработал над многими проектами в Unity, в том числе над кучей прототипов игр, завершёнными играми, такими как Father.IO, и над нашим основным ассетом Unity Grids.

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

За время обучения не раз задавался вопросом: все эти хорошие и крутые алгоритмы чем могут помочь на практике? И вот, пару дней назад столкнулся с задачей по расчету цепи электрического тока. То, как это решилось и чем — под катом.



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

Википедия: Brick Game («Игра с кирпичами»; также его называют «Тетрис») — игровое устройство, работающее на гальванических элементах, снабжённое несколькими предустановленными играми и чёрно-белым (монохромным) экраном. На таких устройствах практически всегда присутствует игра, аналогичная «Тетрису», хотя вместе с ней часто имеются и другие игры. Существуют разные виды устройств с разным количеством игр.

Я расскажу о том, как (и почему) создавал симулятор Brick Game на Unity3D для Android с тетрисом, змейкой, гонками, танчиками и прочими играми, об эксперименте с монетизацией, а также о том за что Google Play может заблокировать подобное приложение и как его потом разблокировать.