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.

Привет, Хабр!

Свой первый пост я решил посвятить квантовой информатике и ее приложению к теории игр. Эта идея абсолютна не нова и своими корнями уходит в статью Жиля Брассарда 1999 года [1]. Квантовая механика сама по себе удивительная вещь, а возможность ее использования в играх вдвойне удивляет!

«Если квантовая механика вас не потрясла до глубины души, значит, вы ее еще не поняли.» (Нильс Бор)

Все крупные магазины игр (Steam, GOG, Origin, Uplay, itch и т.д.) обслуживают различные группы людей одновременно. Многие из этих групп имеют противоположные интересы. Говоря упрощённо, их можно разделить на:

1. Покупателей
2. Разработчиков
3. Издателей
4. Сами платформы магазинов

Часто слышны жалобы на разные магазины (обычно на Steam). Но не всегда очевидно, кто жалуется, каковы его интересы, и как они влияют на интересы других групп. Если вы читаете эту статью, то, скорее всего, вам ближе интересы разработчиков, покупателей или обеих этих групп. Однако у всех групп есть собственные интересы, и они часто конфликтуют.

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

До недавнего времени такой взгляд на вещи действительно был недалек от истины: говорим ФП, подразумеваем Хаскель и теорию категорий. В последнее время ситуация изменилась и функциональная парадигма набирает обороты в web-разработке, не без помощи F#, Scala и React. Попробуем взглянуть на «паттерны» функционального программирования, полезные для решения повседневных задач с точки зрения ООП – парадигмы.

ООП широко распространено в разработке прикладного ПО не одно десятилетие. Все мы знакомы с SOLID и GOF. Что будет их функциональным эквивалентом?.. Функции! Функциональное программирование просто «другое» и предлагает другие решения.

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


До...


… и после.

Художники нарисовали яркую графику, программисты встроили ее в игру, аниматоры добавили движения — казалось бы, все, готово. Но нет, менеджерам не нравится:

«Надо убрать серые пятна и белые линии. Тут пульсирующая кнопка дергается, там прогресс-бар лесенкой идет».

Смотришь игровые ресурсы — нет в них ничего такого, все спрайты обрезаны. Читаешь код — формулы правильные, точности шейдера хватает. Но результат все равно получился неважный. Где ошибка?



Небольшой опрос для тех, кто уже знает откуда берутся артефакты. Что делать в такой ситуации?

1. Нужна мощная видеокарта и свежие драйверы;
2. Стоит сделать скачиваемые наборы графики для всех возможных разрешений экрана;
3. У квадратных текстур с размерами степени двойки нет таких проблем;
4. Это все из-за сжатия графики (PVRTC/DXT5/ETC1/...);
5. В графическом редакторе придется слегка размазать края;
6. Так и должно было получиться, ведь мы не подготовили графические данные;
7. Поможет только антиалиасинг;
8. Нужны текстуры и таргеты в режиме premultiplied alpha.

Какой вариант ответа правильный, почему именно он и как побороть артефакты графики читайте под катом.

Вступление

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

Во многом статья посвящена тому, как написать все алгоритмы и протестировать их. Если говорить о самом программировании, то иногда могут возникнуть совершенно неожиданные трудности (во многом благодаря оптимизатору C++). Однако не менее трудно решить, какие именно тесты и в каких количествах нужно сделать. Коды всех алгоритмов, которые выложены в данной статье, написаны мной. Доступны и результаты запусков на всех тестах. Единственное, что я не могу показать — это сами тесты, поскольку они весят почти 140 ГБ. При малейшем подозрении я проверял и код, соответствующий тесту, и сам тест. Надеюсь, что статья Вам понравится.

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

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

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

Или как легко превратить Ragdoll в AnimationClip.



Всем привет, мы маленькая инди-студия Drunken Monday. На днях выпустили игру, где нужно бегать по арене и крутить вокруг себя здоровенным топором, стараясь попасть по другим игрокам. Хорошо попал — убил.

Чтобы смерть от топора была эффектной, мы использовали обычную ragdoll анимацию, построенную на физике. И всё было хорошо. Поначалу.

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

Можно было озадачить аниматоров. Мы даже почти отдали эту задачу в работу, как пришла мысль: почему бы не записать несколько ragdoll смертей прямо в Unity, и потом просто показывать нужную анимацию?

Смерти получатся разнообразными, аниматоров подключать не нужно, а главное — все будет быстро и красиво.

Сеть обучалась последние 12 часов. Всё выглядело хорошо: градиенты стабильные, функция потерь уменьшалась. Но потом пришёл результат: все нули, один фон, ничего не распознано. «Что я сделал не так?», — спросил я у компьютера, который промолчал в ответ.

Почему нейросеть выдаёт мусор (например, среднее всех результатов или у неё реально слабая точность)? С чего начать проверку?

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

Привет, Хабр! В своём первом посте я расскажу, как мы уже полгода как пишем неофициальный мультиплеер для NFS Most Wanted 2005 года выпуска. Сразу скажу — ссылок не будет, лишь скриншоты, дабы не сочли за банальную рекламу. Если будет интересно — спросите в комментариях. Поехали!

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

Типичные трудности перевода

Классический пример симбиоза знания языка и творческого начала в ходе перевода — деятельность братьев Стругацких. Кроме создания собственных произведений, они оба работали как переводчики с английского и японского под псевдонимами С. Бережков, С. Победин и С. Витин. И если вы читали советские издания Азимова «Как им было весело», Нортон «Саргассы в космосе» или Уиндема «День триффидов» — то это были переводы Стругацких.

Когда я начала думать над созданием игры Bollywood Wannabe, одной из первых проблем была музыка. Мне нужны были песни, которые в сочетании с соответствующей графикой и геймплеем воссоздавали бы ощущения от просмотра болливудских фильмов. Музыку при разработке игр часто игнорируют, но в музыкальной игре (rhythm game) плохих композиций быть не может. Большинство песен в Bollywood Wannabe лицензировано — редкий случай для инди-игры. Мне задали кучу вопросов по этой теме, поэтому я написала небольшую инструкцию по лицензированию музыки для инди-разработчиков.

Зачем лицензировать музыку?

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

Для Bollywood Wannabe мне нужна была очень специфическая музыка. После долгих поисков мне удалось найти для игры две песни с лицензией без отчислений (royalty free). Но мне нужно было десять. Я не знала ни одного композитора, способного написать остальные, и даже если бы и нашла его, это было бы слишком дорого. Оптимальнее всего оказалось найти уже выпущенные песни и убедить их авторов продать мне лицензию.

Многие начинающие художники горят желанием рисовать персонажей для игр. Но зачастую энтузиазм быстро гаснет, потому что создание персонажа — это ответственное дело, которым нельзя заниматься в отрыве от работы всей команды. Поэтому мы написали для вас руководство, как создавать игровых персонажей, на примере «Аллодов Онлайн».

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

      

Современные геоинформационные системы и сервисы (QGIS, ArcGIS, MapBox и т.д.; далее ГИС) и используемые ими форматы данных стали стандартным средством для представления карт земной поверхности и даже поверхности некоторых соседних планет. Но есть разновидность карт, где средства геоинформационных систем пока практически нигде не применяются. И это карты, которые получаются в результате процедурной генерации, например, в видеоиграх.

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

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

В этой статье описана эволюция национальной инновационной системы США с XIX века.


Стэнфордский университет

23 ноября 2011 года id Software поддержала собственную традицию и опубликовала исходный код своего предыдущего движка.

На сей раз настало время idTech4, который использовался в Prey, в Quake 4 и, разумеется, в Doom 3. Всего за несколько часов было создано больше 400 форков репозитория на GitHub, люди начали исследовать внутренние механизмы игры или портировать её на другие платформы. Я тоже решил поучаствовать и создал Intel-версию для Mac OS X, которую Джон Кармак любезно прорекламировал.

С точки зрения чистоты и комментариев это самый лучший релиз кода id Software со времени кодовой базы Doom iPhone (которая была выпущена позже, а потому откомментирована лучше). Крайне рекомендую каждому изучить этот движок, собрать его и поэкспериментировать.

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

Себастьян ван Элвердинге рассказывает о своём подходе к созданию потрясающих трёхмерных камней и скал с помощью множества фотографий. Более подробно о нём можно узнать в туториале на gumroad.com/sebvhe.

Введение

Привет, меня зовут Себастьян, я живу в Брюсселе, на родине лучшего картофеля фри, пива и шоколада! Сейчас я работаю художником по окружениям в Starbreeze Studios (Стокгольм). раньше я работал в Playground Games над игрой Forza Horizon 3, которая стала для меня отличной возможностью применения фотограмметрии в игре AAA-класса.



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

Хотя с момента написания мой рабочий процесс немного поменялся, туториал всё равно применим к тому, что собираюсь рассказать. Если вам будет что-то непонятно в этом интервью, то, скорее всего, вы найдёте подробное объяснение в туториале.

Интервью с Кейси Риасом о процедуральных искусстве и дизайне, развитии цифровых инструментов и о том, как софт стал стал новым выразительным средством для художников. Риас — один из создателей Processing, профессор UCLA, медиахудожник, автор трёх книг о программировании и визуальных медиа. Его работы выставлялись в San Francisco Museum of Modern Art, Art Institute of Chicago, Whitney Museum of American Art.

© Casey Reas, reas.com