Unity, C#, Steamworks.NET и Facepunch.Steamworks

Введение

Как и большинству разработчиков игр, мне очень хочется выложить мою игру в Steam.

Как и большинству инди-разработчиков игр, мне не хватает доступа к ресурсам/знаниям, которые дали бы мне чётко понять, что же действительно значит «быть в Steam».

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

Поэтому я решил написать высокоуровневый обзор для людей, которые только начинают разбираться в том, как заставить Steam работать с их играми. В частности, я подробно рассмотрю Steamworks SDK, программную библиотеку Valve, предоставляющую доступ к таким аспектам, как мастерская (Workshop), таблицы лидеров (Leaderboards), достижения (Achievements) и так далее.

Steamworks хорошо задокументирована компанией Valve, но документация написана с точки зрения человека, использующего нативную библиотеку C++ и уже имеющего представление о том, как все эти функции пересекаются. Если это не ваш случай, то так даже лучше! Ниже представлено объяснение для другого человека, который пишет игру на языке более высокого уровня и просто хочет обеспечить простую интеграцию со Steamworks (а это возможно, я гарантирую!). Конкретнее, этот пост предназначен для людей, использующих в той или иной форме C#, а в идеале — работающих в игровом движке Unity.

Когда вышел .Net Core, старая версии OData ASP.NET Web API оказалась несовместимой с новой платформой. Этот фатальный недостаток позволил мне создать свою реализацию OData на платформе .Net Core. В результате творческого переосмысления предыдущей реализации пришло понимание, что она страдала от переусложненного дизайна с большим количеством ненужных абстракций. Возникла идея создать простую в использовании, требующую минимального кодирования библиотеку. Представляю вашему вниманию OdataToEntity, библиотеку создания OData сервисов без написания кода, нужен только контекст доступа к данным.

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

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

• 1 Необходимо обеспечить отрисовку большого числа анимированных объектов на сцене. Ведь мы хотим, чтобы игрок отстреливался от полчищ монстров.
• 2 Прогресс анимации должен быть различен для каждого из объектов. Ведь мы не хотим, чтобы мобы ходили строем.

Решение «из коробки»

Безусловно, первое решение было простым: все сделать с помощью уже встроенного в UnityEngine компонента Animator. Посмотрим, что из этого получается.

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

Hotel – приют для localhost.

Запуск и управление всех ваших веб-проектов с одного адреса.

Больше, разных портов костылей.

Можно держать зоопарк портов для каждого проекта: 9000, 8000, 8080, 3000, 3001…
Или настраивать веб-сервер, править /etc/hosts файл или DNS для каждого проекта.
А еще помнить, как запускать девелоперский веб-сервер для каждого проекта:

• gulp
• gulp serve
• gulp watch
• ionic serve
• browser-sync start --server --no-open --directory --files
• http-server -p 9000
• python -m http.server 8000
• php -S localhost:8000
• и так далее...

Сделать жизнь проще поможет hotel.

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

Я участвую в проекте одного очень талантливого художника, где помогаю в разработке игры-квеста в ретро пиксель-арт стиле. Мы используем Unity, так как оба имеем длительный опыт разработки в этой среде. Практически сразу возникла необходимость создания поставленных событий, кат-сцен и головоломок, во время которых череда действий строго определена. Сначала я попытался отделаться как можно меньшей кровью и предложил использовать стандартный Animator Controller и класс StateMachineBehaviour из Unity 5 для кастомизации событий, но как оказалось этот подход не работает: конечный автомат аниматора хоть и универсален, но потребовал бы чрезмерного количества лишних действий для абсолютно линейных вещей, а нам было необходимо похожее визуальное решение, но позволяющее легко и просто выстраивать события как в таймлайне видео-редакторов.


^{Картинка из документации Unity, вдохновившая на создание собственного редактора}

Таким образом написание своего собственного полноценного редактора оказалось неминуемым.

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

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

Вместо равномерно распределённых случайных чисел (какие выдаёт генератор Math.random в большинстве языков), я использую нормальное распределение Парка-Миллера. В результате вероятность появления маленьких комнат превышает вероятность появления больших. Зачем это надо, объясню позже.

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

9. Чтобы превратить его в коридоры, для каждого ребра строится серия прямых линий (в форме Г), идущих по рёбрам графа, соединяющим комнаты. Тут нам пригождаются те клетки, которые остались неиспользованными (те, что не превратились в комнаты). Все клетки, накладывающиеся на Г-образные линии, становятся коридорами. А из-за разнообразия размеров клеток стены коридоров будут неровными, что как раз хорошо для подземелья.

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

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

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

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

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

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

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



Среди новых блестящих возможностей Unity 5.3 я обнаружил одну небольшую вещь, которая оказалась мне полезной, и, думаю, может пригодиться и вам. Это кастомные корутины, представленные классом CustomYieldInstruction. Благодаря ему, вы сможете очень просто создать свои собственные корутинные yield-операторы. Давайте рассмотрим это на живом примере.

Эта статья — перевод выступления Джона Нески (John Nesky) с GDC14.

Вторая часть тут

Джон — один из разработчиков в компании TGC, известной своей игрой Journey. Он начал работать там в роли гейм-дизайнера, но впоследствии увлёкся настройкой работы камеры в Journey, поэтому теперь его должность звучит как Feel Engineer.

Вряд ли вы найдёте какое-нибудь сообщество разработчиков, специализирующихся на игровых камерах. И есть, пожалуй, всего одна книга на эту тему — Real Time Cameras за авторством Марка Хэйг-Хатчинсона (Mark Haigh-Hutchinson). Но хотелось бы глубже изучить эту тему и узнать, как люди решают те или иные трудности.

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

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

В Windows 10 универсальные Windows-приложения на управляемых языках (C#, VB) проходят в магазине процедуру компиляции в машинный код с использованием .NET Native. В данной статье мы предлагаем вам познакомиться подробнее с тем, как это работает и как это влияет на процесс разработки приложений. Ниже вы найдете видео-интервью с представителем команды разработки .NET Native и перевод соответствующей статьи.

Что такое .NET Native?

.NET Native – это технология предварительной компиляции, используемая при создании универсальных Windows-приложений в Visual Studio 2015. Инструменты .NET Native компилируются ваши IL-библиотеки с управляемым кодом в нативные библиотеки. Каждое управляемое (C# или VB) универсальное Windows-приложение использует данную технологию. Приложения автоматически компилируются в нативный код прежде, чем они попадут на конечное устройство. Если вы хотите погрузиться глубже в то, как это работает, рекомендуем статью “Компиляция приложений с помощью машинного кода .NET”.

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

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

Эффективность сайта в немалой степени зависит от его репутации. Избавить пользователя от спама – одна из важнейших задач в сети для добросовестного бизнеса. Для борьбы со спамом формируются списки хостов-спамеров, которые помещаются в блеклисты, формируя DNSBL. ХостТрекер предлагает функционал, который, помимо обычной проверки доступности сайта, проверяет домен на попадание в DNSBL.

Наверное, многие слышали про тулбар от Билайн. С их стороны этот сервис вежливо назван "Мини-кабинет".

«Мини-кабинет» – это сервис самообслуживания в браузере, с помощью которого можно узнавать баланс, остаток интернет трафика, управлять услугами связи и менять тарифные планы, а также получать ссылки на полезные сервисы от «Билайн»

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

Однако, Билайн решил пойти еще дальше и начал добавлять на сайты тулбар с поиском mail.ru.

Сегодня мы предлагаем вашему вниманию очередную публикацию в рамках постоянной рубрики «Лекции Техносферы». В этот раз вы можете изучить материалы по курсу «Методы использования СУБД в интернет-приложениях». Цель курса — изучение топологии, многообразия и основных принципов функционирования систем хранения данных, а также алгоритмов, заложенных в основу как централизованных, так и распределённых систем, демонстрация фундаментальных компромиссов присущих тем или иным решениям. Преподаватели курса: Константин Осипов kostja, Евгений Блих bigbes, Роман Цисык.

Виртуальная реальность на Windows Phone с помощью Unity3d

На последней Game Developer Conference было много новостей связанных с виртуальной реальностью. Это и новые устройства, такие как Microsoft HoloLens, борьба за признание между Oculus Rift и Project Morfeus, анонс SteamVR. Все это говорит о том, что тема очень интересная и горячая. Хотя понятие виртуальной реальности включает в себя очень много всего, технологически это в первую очередь очки или шлем которые показывают стереоскопическое изображение и реагируют на движение. Многие из нас хотели бы поэкспериментировать в этой области, но без устройства, например, Oculus Rift это затруднительно. К счастью существуют технологии, которые могут превратить ваш телефон Windows Phone в шлем виртуальной реальности.

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

Всем снова здравствуйте! Дошли руки написать крутую статью на весьма важную тему для разработчиков игр. Итак, поговорим о защите ваших драгоценных игр и приложений, которые вы пилите на Unity в надежде заработать на буханку хлеба, от взлома злобными школьниками. Почему школьниками? Потому что надежной на 100% защиты априори быть не может. И кто захочет, все равно взломает. Вопрос лишь в том, сколько времени и сил он на это потратит. И как любят шутить безопасники — терморектальный криптоанализ никто не отменял.

Итак, в статье я постараюсь максимально доступно рассказать о 3 аспектах (и конечно, предложу реализацию):

• защита данных приложения (сейвов)
• защита памяти приложения
• защита внутриигровых покупок (Google Play)

Предисловие

Постоянно сталкивался с высказываниями ИТ специалистов «сеть нагружена на 20%… процессоры на 50%… очередей к дискам мало… Значит сеть и сервера справляются… смотрите код в 1С проблемы исключительно там».

На самом деле происходило следующее ( сервер 1С и SQL разнесены на разные компьютеры): сеть практически использовалась по максимуму(эти "20% загрузки сетевого интерфейса" = «20% полезные данные» + «80% потеря на служебной обработке»). И соответственно из-за малой ширины канала обмена «полезными» данными — SQL сервер с «Сервером 1С» постоянно ожидали друг друга, что вело к малой утилизации ресурсов CPU и дисковой системы.

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



На мототреке Thunderhill в Северной Калифорнии впервые в мире прошёл заезд на скорость между беспилотным автомобилем и профессиональным гонщиком. К сожалению для поклонников искусственного интеллекта, в гонке на три мили (4,83 км) всё-таки победил человек, обогнав соперника на несколько секунд.