Если ты доделал свою первую игру, значит с тобой что-то не так.

Именно эта фраза, прочитанная в одном из постов, впечаталась в мою память 2 или 3 года назад. И автор был прав. Начав делать свой первый прототип, большинство разработчиков бросают его на пол пути и берутся за следующий по разным причинам.

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

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

Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

Первая часть

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

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

Направление

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

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

Wonder Boy, ещё одна моя любимица, быстрый платформер, в котором можно идти только вперёд через старое доброе одностороннее окно свободного хода. В отличие то Super Mario Bros., там нет зоны разгона, плавно ускоряющей камеру, но есть другая интересная техника, которую я называю «рельсы». Камера ставится и движется так, чтобы предвосхищать будущие преграды.

Wonder Boy (Sega, 1986)

Рельсы: запрограммированный маршрут камеры Зона свободного хода (односторонняя) Статическое упреждение

Пятое поколение приставок, среди них PlayStation и Nintendo 64, открыло новые аппаратные возможности, положив начала грубому, но настоящему 3D. Приёмы трёхмерной камеры — сами по себе захватывающая и многогранная тема, но поддержка 3D повлияла и на двухмерные игры. Разработчики теперь могут приближать камеру, наклонять вид и даже сочетать 2D и 3D — то, что мы сейчас называем 2,5D, когда игра идёт на двухмерной плоскости, но в объёмном мире.

Представляю вашему вниманию перевод очень ёмкой, и в то же время достаточно краткой (для такого масштаба проблемы) статьи Карла Чео. Я решил, что очень хочу сделать её перевод практически сразу, как только начал читать, и очень рад, что в итоге сделал это.

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

Важные замечания:

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

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Меня зовут Евгений, я разрабатываю компьютерные игры. Я успел поработать в больших компаниях и маленьких студиях программистом, а также у меня есть хобби: делать небольшие мобильные игры целиком: придумывать, рисовать, программировать.
Сейчас я заканчиваю игру Out of Brakes и хочу на ее примере посчитать, сколько же стоит разработать игру своими силами для App Store?

Введение в проблему

Здравствуйте, дорогие читатели!

Мысли о создании серии простых уроков «концептуальные идеи для новичков игродева» появились у меня спонтанно, где-то в 2:00 по Московскому времени во время создания своего нынешнего проекта. Ну нет, это так мне кажется, что спонтанно, но, наверное, это мое подсознание так среагировало. Среагировало потому, что все больше юных (коим я и сам являюсь) и очень юных программистов решают заняться созданием игр. Как мне кажется, общая тенденция молодежи-программистов (и людей, интересующихся сферой программирования) плавно перешла от создания сайтов и модных блогов к созданию развлекательных продуктов. Я начинаю замечать это и среди своих знакомых, которые одно время говорили, что, мол игры — это не серьезное программирование, но теперь уже проявляют настоящий интерес к этой среде.

Я объясняю это для себя следующим, очевидным образом. Любые информационные направления приобретает массовые тенденции к изучению при выполнении двух условий: наличие простого и адекватного инструмента осуществления конкретных задач в выбранной информационной сфере и легкость получения прибыли при продаже ваших выполненных задач. В пример же опять можно привести сферу веб-технологий (когда-то сайты было создавать ультра-хардкорно, а сейчас, наверное, даже моя мама сможет поставить блог на WordPress или его аналогах. Опять же почему? Потому что WordPress открыл возможность создавать свои блоги всем мамам вокруг света, и потому что веб-сайты открыли доступ к быстрой популярности, славе, деньгам и рому).

Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.

«Возьми себя в руки, тряпка!» — сказал я себе, когда понял, что работа скоро доконает. Или она тебя, или ты её.

Дорога в тысячу ли начинается с первого шага.
Первым шагом стала книга Дэвида Аллена «Как привести дела в порядок: искусство продуктивности без стресса». Точки над i расставил курс Максима Дорофеева «Джедайская техника пустого инбокса, или Как доводить дела до конца».
 
Нельзя питать иллюзий, ступив на тропу войны. Проблемы не заставили себя долго ждать. Работа на компьютере требовала автоматизации. Дело стало за малым, поиск подходящего программного обеспечения для Getting Things Done (GTD).

Бесконечные пробы GTD-программ не принесли счастья. Комфортной работе мешало большое количество данных.
Не получалось связать задачи и данные внутри одной GTD-программы. Поток писем складировался в Outlook, документы и другие файлы на диске, часть информации на web ресурсах и так далее. Решая дела, приходилось тратить время на поиск связанных с ними данных. Возникали проблемы с синхронизацией информации на разных устройствах и многое другое.
 
Но кто ищет, тот всегда найдёт! Выходом из патовой ситуации оказался Microsoft OneNote 2013, который простыми настройками легко превратился в полноценный GTD-инструмент. Только такой подход позволил преодолеть все проблемы и ощутить комфорт от использования GTD.

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

Например, мы захотели создать незатейливую RPGMMO-шечку «убийцу WoW», и у нас уже почти все готово. Мы уже нафантазировали, какая в игре будет крутая механика боя и система умений. Дело осталось за малым – абстрактные мысли превратить в конкретные значения. Причем, каким-то образом, сочетание этих значений должно убедить игрока в том, что фраза «баланс – говно» — это не про нас.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Доброго времени суток, уважаемый читатель! На Хабре неоднократно публиковались статьи о разработке игр с использованием замечательного движка Unity3d. Большинство этих статей были посвящены вполне определенным задачам, я же хотел сделать общий экскурс в данный движок. Данная часть будет посвящена наиболее часто используемым скриптовым методам и объектам, которые используются мной в процессе разработки на данном движке. Примеры я буду приводить на JavaScript, как на наиболее близком мне языке.

В видеоиграх красивое освещение в реальном времени сильно бьёт по производительности, что особенно заметно на мобильных устройствах. Таким образом, разработчики вынуждены искать методы обхода этой проблемы. Lightmapping — технология, сохраняющая информацию об освещении в текстуру, что позволяет высвободить вычислительные ресурсы под другие нужды.
В этой статье я познакомлю читателя с теорией освещения в играх, опишу процесс создания “лайтмапа” в Unity 5 и поделюсь рядом советов.