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

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

На практике же мы имеем совсем другую ситуацию.

Алгоритмы поиска пути разобраны досконально.

Нужен поиск пути с весами? A*. Нужен поиск для большого количества юнитов? Flow Field или кластеризация.

По большому счету по поиску пути не осталось не разобранных вопросов.

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

Эти проблемы и будем сегодня решать.

В этой заметке я хочу рассказать об идее и Proof-Of-Concept добавления объектов реального мира в Виртуальную Реальность.

На мой взгляд, описанная идея в ближайшее время будет реализована всеми игроками VR-рынка. ИМХО, единственная причина, по которой это до сих пор не сделано — желание выкатить идеальное решение, а это не так-то просто.

Долгие годы основным инструментом аниматора в Unreal Engine был инструмент Matinee. UE развивается и почти год назад старичок Matinee был объявлен уходящим на покой. Вместо него нам был представлен инструмент Sequencer. Этот инструмент интуитивно понятен, но, к сожалению, в попытках поискать документацию или уроки по анимации в UE4 — вы неизменно будете натыкаться на Matinee. Уроков мало. Спешу принять участие в борьбе с этим недостатком.

В этой статье проведу краткий экскурс в основы (в том числе исторические) Sequencer. А также расскажу о паре моментов, которые почему-то отсутствуют в документации.

Я не буду повторять официальные туторы от Epic Games. С ними вы можете ознакомиться на youtube.

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

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

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

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

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

Однако, было поставлено условие — работа только в офисе. Никакой удалёнки.

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

Я постараюсь рассказать, почему удалённая работа — это особенный статус, от которого очень сложно отказаться.

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

Итак, что же такое дождь или снег в реальном мире?

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

Эти размышления натолкнули меня на занятный эксперимент: в ноябре на gamedev.ru стартовал «конкурс леталок». Конкурс предполагал разработку в течении двух месяцев. Однако мне показалось, что это многовато. Поэтому я записался в участники… И забыл о конкурсе на полтора месяца.

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

Давно хочется рассказать о проекте ZSlice.

Редактор разрабатывается уже около 5 лет, пережил два прототипа и полное переписывание…
И всё ещё находится в стадии активной разработки.

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

Сегодня игра вышла в переизданном виде на Steam под покровительством KranX Productions.
Сбылась мечта западного журналиста, который в конце 90-х сожалел о том, что игра опубликована только в России и недоступна западному игроку.
Многие не знают о её существовании, но эта игра стала одной из тех первых российских игр, после которых западные игроки и издатели обратили внимание на наш геймдев.
Сейчас Калининград — один из центров российского геймдева. И это стало возможным не только благодаря особенной экономической зоне, но и благодаря примеру и кадрам KD-Lab.
Для меня огромная честь быть лично знакомым с некоторыми членами команды KD-Lab.
Поздравляю КранКа и весь состав KD-Lab с этим событием!
Ну и, конечно, игроков, которые помнят и любят Вангеров!
Вперед за Нюхой, товарищи!

Возникла необходимость сделать Drag'n'Drop с элемента ScrollView.
Причем решить эту задачу без использования посторонних библиотек и для всех устройств, начиная с Froyo.
Сам процесс перетаскивания элемента проблемой не является.
Проблема — отключить скроллирование списка после того, как мы уже с ним не работаем.

Началось всё с желания делать свои игры вместо того, чтобы делать чужие.
Полгода назад я (программист) и мой товарищ (художник) уволились с работы и решили начать делать проект мечты — раллийный симулятор.
Этот проект мы задумывали очень давно, но не хватало опыта и знаний, чтобы начать и закончить.
За несколько последних лет мы оба набрались опыта и созрели для того, чтобы наконец сделать этот проект.
Но за те 10 лет, что мы пробовали свои силы, наши наработки полностью устарели. Кодовая база оказалась сложно портируемой на мобильные устройства. Контент не соответствовал современным требованиям.
Пару месяцев мы ковыряли то, что у нас уже было в надежде понять, что же делать…
И пришли к выводу:
Надо прощупать почву

Нам надо было понять, каким образом ведётся разработка кроссплатформенного движка, способного адекватно работать как на ПК, так и на мобильных ОС. Как публикуется игра? Как ведут себя отдельные площадки и на каких условиях работают?
Нам нельзя на проекте мечты совершать детские ошибки. Проект должен разрабатываться и публиковаться с чётким пониманием: как, что и для чего делается.
И для этого мы взялись реализовать тестовый проект. Небольшую казуальную игру.
Эта статья о том, как мы публиковались на Google Play, как провалили публикацию на Greenlight и какие сюрпризы нас ждали в AppStore.

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

• Какой из подходов лучше?
• Какой подход стоит реализовать в своем приложении?

В середине девяностых, когда я переходил с программирования под DOS на Windows, мой наставник познакомил меня с механизмом исключений.
С тех пор в моём сознании укоренилось мнение: программа, падающая с исключением — плохая программа. Все исключения надо обрабатывать и завершать работу приложения в случае нештатной ситуации самостоятельно.
И это вполне актуально для обычного приложения под Windows. Ведь в случае падения приложения пользователь получает невнятное сообщение об ошибке и, как результат, негативное восприятие нестабильно работающего приложения.
Моё мнение начало меняться после знакомства с инструментами автоматической обработки исключений (таких как EurekaLog и аналогов).
И окончательно поменялось после знакомства с системой отчетов Google Play.
Этот пост — крик души против тех тысяч примеров, которые учат нас пихать в свой код необдуманные проверки.

В некоторых случаях Eclipse добавляет в apk исходные коды из каталога jni.

В интернете есть множество заметок о том, как собирать freetype под iOS.
Все эти заметки объединены общей характеристикой — они не работают.
Дело в том, что все инструкции оперируют gcc для сборки библиотеки, но начиная с XCode 5 gcc не входит в поставку и для сборки под iOS надо использовать clang.
Нет ни одной заметки о том, как компилировать правильно.
Исправляем эту несправедливость.