В последнее время мы как-то особенно углубились в тему стартапов (это и понятно, ведь новые проекты занимают все наши мысли и свободное время), поэтому активно читаем все, что пишут по этой теме у нас и в англоязычных источниках.
И вот наткнулись на забавную статью. Автор написал ее, размышляя о турнире StartupCraft (турнир по Starcraft для IT-компаний), пытаясь понять, является ли выигрыш в этом турнире свидетельством успеха компании в работе или инвесторы должны дать денег в первую очередь тем, кто проиграл (ведь они еще что-то кроме Starcraftа умеют). Без сомнения, автор склоняется к первому варианту:)



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

[В туториале около 50 МБ изображений, в том числе анимированных GIF]

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

В этом туториале вы познакомитесь с Timeline и узнаете, как создавать катсцены с анимациями и сменами камер.

Приступаем к работе

Скачайте проект-заготовку и готовый проект отсюда.

Откройте файл Starter Project и загрузите сцену Main. Она будет нашим фундаментом. В ней есть герой, стоящий на башне и глядящий на мир:


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

Matthew Fisher из Стэнфордского Университета написал интересную статью о реализации бота на основе перехвата потока API библиотеки D3D9 (Microsoft Direct 3D, являющуюся частью библиотеки DirectX).

Как пишет сам автор, бот играет в Starcraft 2 (SC2) перехватывая, понимая и реагируя на поток сообщений D3D9, посылая нажатия клавиш и движения мыши обратно игре. Он не похож на других ботов, сделанных на основе редактора SC2 и использующих скриптовый язык, или проектов наподобии BWAPI (работает только с оригинальным StarCraft), который внедряется в адресное пространство игры. Боты, основанные на этих методах зачастую имеют возможность обойти ограничения, с которыми сталкивется человек при игре; например, они могут одновременно отдавать разные приказы разным юнитам, они могут видеть происходящее вне экрана в любое время, им не составляет труда добраться до наземного юнита, закрытого летающим.

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

Введение

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

Я начинал карьеру как 3D-художник ещё в эпоху первой PlayStation, а позже стал программистом графики. Хотел бы я прочитать эту статью перед тем, как впервые начал создавать 3D-модели для игр. Рассмотренные в ней фундаментальные основы пригодятся многим художникам. Хотя бОльшая часть информации из этой статьи не повлияет значительно на продуктивность вашей ежедневной работы, она даст вам базовое понимание того, как графическая карта (graphics processing unit, GPU) отрисовывает создаваемые вами меши.

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

В мае этого года, спустя два года в состоянии Early Access и три с половиной года разработки, мы выпустили полную версию Judgment: Apocalypse Survival Simulation. Я решил уделить время анализу наших финансовых данных, чтобы он помог другим инди-разработчикам, не представляющим, какая дорога им предстоит.

Примечание: все данные о продажах, представленные в посте, являются суммой значений по всем магазинам. На данный момент Judgment продаётся в Steam, в Humble Store, на нашем сайте (с помощью Humble Widget), Green Man Gaming и Fanatical. Никаких бандлов, только прямые продажи.

Цена, которую мы платим, чтобы быть инди

Создание игр — недешёвый процесс. В нём задействовано множество разных областей. Очень редко можно найти человека, одинаково успешного во всех них, поэтому в разработке игр обычно участвует команда или разработчик платит за услуги подрядчикам. В показанные ниже значения включены общие затраты на разработку Judgment в течение 40 месяцев, которые мы пока потратили, в том числе 15 месяцев ушло на предрелиз, а другие 25 — на Early Access. Очевидно, что после полного релиза появятся дополнительные расходы, потому что мы продолжим совершенствовать и рекламировать игру.

Только через смех можно рассказывать, как плоды долгой и упорной работы распространяются по всем компьютерам страны, но не приносят ни капли дохода. Только улыбка поможет принять хорошее, честное предложение распределения прибыли 1 к 12, где 1 — разработчику, а остальное агрегатору. И трудно слегка не загрустить, слушая о том удивительном времени абсолютно пустого рынка мобильных игр и почти азартном энтузиазме разработчиков. И, наверное, только у Вадима Башурова (PapaBubaDiop) такой длинный путь и невероятный опыт, чтобы иметь в запасе множество невыдуманных смешных и грустных историй.

Так уж повезло, что по случаю тридцатилетнего юбилея своей первой игры, Вадим пришел на Apps Conf. Да, когда вышла самая популярная игра того времени, многие из нас еще не родились, а ныне уважаемые Head of mobile пешком под стол ходили. Но каждый, кто в начале 90-х видел компьютер, видел и игру «Поле Чудес» и думал, что же такое Арзамас.

“Эка невидаль”, — скажете вы, — “В топ-100 вашей игры нет, так что нещитово”. Тоже правда. Зато за год разработки Protolife мы поднакопили какой-никакой опыт, которым можем поделиться с потенциальными будущими игроделами. Ветераны индустрии, боюсь, ничего интересного для себя не найдут. Но, может быть, хоть повеселитесь от души.

Что за игра-то? И кто “мы”?

Мы — это команда из трех человек (GRaAL, A333, icxon), волею судеб названная Volcanic Giraffe без какого либо умысла. Работали долгое время вместе, несколько раз втроем участвовали в Ludum Dare (соревнования по написанию игр за выходные), и однажды решившие довести до релиза одну из наших поделок под названием Protolife.

Если коротко: это необычная tower defense, где надо бегать героем-курсором и выстраивать оборону из блоков против постоянно растущей красной биомассы.

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

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

Вступление

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

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

Всем привет! Целых 4 года я не писал на Хабр. Последняя моя серия постов была о различных инструментах и приемах, которые мы применяли на нашей прошлой игре (разрабатывая ее на Unity). С тех пор игру ту мы благополучно выпустили, а также выпустили и новую. Так что теперь можно немного выдохнуть и написать несколько новых статей, которые могут быть кому-то полезны.


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

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

Для начала, кратко перечислю из чего собирается картинка в нашей игре:

В этой статье я расскажу как анимировать персонажа с помощью MoCap данных, полученных с использованием ipi mocap studio и 2х сенсоров Kinect.
Для этого понадобятся:
1-2 сенсора Kinect
iPi Studio, iPi Recorder
Autodesk Motionbuilder 2013 лучше, но я использую 2012, т.к. 2013 у меня не работает

Часть 1. Получение MoCap данных

Калибрация

Устанавливаем iPi Studio и iPi Recorder, подключаем Kinect. Более подробно об этом можно прочитать на wiki ipisoft инструкция для старой версии программы, в последней версии настройка происходит немного иначе.

Для того чтобы получать MoCap данные с 2х сенсоров, необходимо записать видео для калибрации.

Сенсоры могут быть расположены в 2х конфигурациях:

Предыстория

Совсем недавно вышел Unity 5, в котором куча всего нового и непонятного, а документацию сотворить пока еще не успели.

В силу своей работы технических художником мастером на все руки, мне пришлось бросить все и срочно сделать UP проекта на Unity 5. Не так давно Apple обязала разработчиков создавать 64-битные приложения.

Открыв проект в новой версии, вы увидите… ничего, ну или почти ничего. Unity 5 не понимает старые шейдеры с альфой и просто заливает их черным или белым, кто как писал.

Старый Beast ушел в историю и свет придется перепекать.

Ниже вся собранная информация по вопросу: перевод мануала и туториала с офф.сайта Unity3D, и кое-какие заметки (по настройкам) от меня.

Посвящается всем перешедшим на Unity 5.

В предыдущей статье мы рассказали о «Планоплане», нашем онлайн-планировщике и дизайнере квартир. С небольшим отрывом в опросе победила тема о школьной геометрии в «Планоплане» и Unity3D, о чём с удовольствием и рассказываем.

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

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

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

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

Лопаты в руки.

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)линк)

Первая статья данного цикла была воспринята тепло, вследствие чего затягивать с продолжением не имело никакого смысла, но, увы – это произошло. Зимнее наступление захлебнулось и плавно переросло в летнюю кампанию. В конце статьи я объясню почему, не хотелось бы вас огорчать с самых первых строк. Итак. Публика выразила желание ознакомиться с предметом глубже, чем предполагалось изначально. Большое количество писем пришло на почту, наряду с регулярными тычками в социальных сетях. В этом месте мне вспоминается одна фраза – «будьте осторожны в своих желаниях».

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)
«Галоп пикселя», часть VI — Анимация персонажей. Бег (линк)

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

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

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

«Галоп пикселя», часть I — базовые понятия, этапы взросления, прикладные упражнения (линк)
«Галоп пикселя», часть II — перспектива, цвет, анатомия и прикладные упражнения (линк)
«Галоп пикселя», часть III — Анимация (линк)
«Галоп пикселя», часть IV — Анимация света и тени (линк)
«Галоп пикселя», часть V — Анимация персонажей. Ходьба (линк)

Доброго времени суток Хабру и ценителям пиксель-арта, поклонникам квадратных точек, адептам лимитированных разрешений и цветов. Рад представить на ваш суд очередную статью из цикла «Галоп Пикселя». Не буду тратить время на оправдания моего долгого отсутствия и в виду явного присутствия перейду к сути дела. Сегодня мы продолжим изучать анимацию. На этот раз это будет анимация света и тени. Большей частью на статических объектах. Всё помнят – сначала база. Сначала фундамент. Сначала простое. Ну а сложное ввалится в ваши двери само, вслед за детишками.

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

Цель этой статьи показать насколько силён дуэт брата и сестры, Света и Тени в движении. Мы уже видели, как они преображают сцены в статике. Но динамика нам ещё не знакома. Давайте исправим это упущение.

Лопаты в руки.

Показ приватных переменных в инспекторе

Примечание переводчика: этой статье уже 17 лет, и интересна она только с исторической точки зрения. Любопытно узнать, как удавалось разработчикам добиться плавной сетевой игры в эпоху 28,8k-модемов и первых «Пентиумов».

В этой статье рассказывается об архитектуре и реализации, а также о некоторых уроках, полученных при создании многопользовательского (сетевого) кода игр Age of Empires 1 и 2. Также в ней излагаются современные и будущие подходы с созданию сетевой архитектуры, используемые Ensemble Studios в своих игровых движках.

Мультиплеер Age of Empires: требования к структуре

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

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

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

• Создавать систему прицеливания.
• Использовать рендер линии и distance joint для создания верёвки.
• Научим верёвку оборачиваться вокруг игровых объектов.
• Вычислять угол качания на верёвке и добавлять силу в этом направлении.

Примечание: этот туториал предназначен для продвинутых и опытных пользователей, и в нём не рассматриваются такие темы, как добавление компонентов, создание новых скриптов GameObject и синтаксис C#. Если вам нужно повысить навыки владения Unity, то изучите наши туториалы Getting Started with Unity и Introduction to Unity Scripting. Так как в этом туториале используется DistanceJoint2D, то стоит также просмотреть Physics Joints in Unity 2D, и уже потом вернуться к этому туториалу.