Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

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

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

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

А что же в играх?

Допустим, появилась необходимость использовать Color Dodge смешивание для системы частиц или UI-художник сделал красивую графику для игрового интерфейса, но некоторые его элементы используют какой-нибудь Soft Light. А может, вам понадобилось подвергнуть трёхмерный объект Divide-смешиванию, чтобы получить эффект прямиком из кинокартин Линча?



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

Добрый день, хабра.

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

Больше видимости.

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



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

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

Я хотел бы рассказать об игровом движке Game Maker и разместить несколько публикаций, в которых мы напишем клон не сложной игры, например, Plants vs Zombies. Возможно, добавим поддержку геймпада и сделаем, например, Android-версию.

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

Предыстория

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

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

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

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

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

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

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

Привет, коллеги!

Совсем недавно мы анонсировали конференцию, посвященную Desktop UI & Business Application. В поддержку, чтобы посмотреть на настроения публики, была опубликована статья «WPF живее всех живых», которая оказалась дискуссионной и заставила нас в несколько другом свете взглянуть, на то, что и как мы хотим донести до широкой публики.

Как показали комментарии, не WPF единым живет десктоп разработка. Есть порты Qt для .NET, есть WinRT, если в эпсилон окрестности от дефолт-сити есть спецы по этим технологиям, которые хотят высказаться – у нас есть трибуна! Для этого все и задумано, чтобы показать различные варианты для ваших проектов.



Буквально вчера закончилась онлайн конференция dotNetConf 2015, которую, исходя из сообщений, Microsoft скорее возродила, нежели придумала заново. Конференция, судя по содержанию старается покрыть все основные области использования языка, это мультиплатформенность, веб, десктоп, доставка приложений, интеграция с Xamarin, будущее .NET, .NET Core, Roslyn Analyzer и другие темы. На мой взгляд, это генеральная репетиция перед конференцией //build, которая состоится в конце апреля-начале мая.

Про золотые молотки

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

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



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

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

Наш стартап Olery был основан почти 5 лет назад. Мы начали с единственного продукта, Olery Reputation, который был создан агентством, занимавшимся разработкой на Ruby. Всё это выросло в набор различных продуктов. Сегодня у нас есть ещё Olery Feedback, API для Hotel Review Data, виджеты для вставки на сайты и многое другое.

Всего у нас работает 25 приложений (все на Ruby) – некоторые из них в вебе (Rails или Sinatra), но в основном это фоновые приложения для обработки данных.

Хотя нам есть, чем гордиться, есть у нас одна проблема, которая всё время висела где-то в фоне – база данных. Изначально мы использовали MySQL для важных данных (пользователи, контракты, и т.д.) и MongoDB для хранения обзоров и других данных, которые легко можно было бы восстановить в случае утери. Сначала всё работало неплохо, но по мере роста мы начали испытывать проблемы, в особенности с MongoDB. Некоторые из них возникали в сфере взаимодействия БД с приложениями, некоторые – непосредственно у самой БД.

К примеру, в какой-то момент нам надо было удалить миллион документов из MongoDB, а позже вставить. В результате работа базы застопорилась на несколько часов. Потом нам пришлось запускать repairDatabase. И сама починка тоже заняла несколько часов.

Продолжая тему JIT-компиляции .NET'a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

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

Чем больше я пишу на C# 6, тем больше убеждаюсь в том, насколько оператор ?. (null coalescing operator) помогает писать чистый простой и понятный код. Сегодня я покажу 4 ситуации, в которых он может быть очень полезен.

Большая вложенность

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

var location = default(string);
if (vendor != null)
{
    if (vendor.ContactPerson != null)
    {
        if (vendor.ContactPerson.HomeAddress != null)
        {
            location = vendor.ContactPerson.HomeAddress.LineOne;
        }
    }
}

Но теперь у нас есть C# 6, с ним код можно привести на намного более читаемому виду:

var location = vendor?.ContactPerson?.HomeAddress?.LineOne;

Оператор ?. сделает так, что как только в одном из свойств цепочки окажется null, дальнейшее вычисление выражения производится не будет. Посмотрим ещё несколько примеров.

Каждый C#-разработчик знает, что C#-компилятор переводит исходный код программы в промежуточный язык под названием Intermediate Language (IL). А за превращение IL в последовательность машинных команд чаще всего отвечает Just-In-Time-компилятор (JIT). Да, на сегодняшний день есть NGen, Mono AOT, .NET Native, но JIT-компиляция всё ещё лидирует в мире .NET-приложений. А вот работает этот самый JIT, знают далеко не все. Если брать в расчёт только реализацию .NET от Microsoft, то стоит различать JIT-x86 и JIT-x64. А ещё за дверями стоит RyuJIT который уже совсем скоро займёт почётное место основного JIT-компилятора. А если вы любите старые версии .NET, то полезно знать, что в разных версиях CLR логика работы JIT отличалась. Исходники у нас теперь открыты, вы можете их посмотреть и осознать, насколько же это большая и сложная тема. Сегодня мы не будем пытаться охватить её, а лишь кратко посмотрим на несколько интересных особенностей отдельных версий JIT-компиляторов. Итак, сегодня в номере:

• Почему короткий метод может не быть заинлайнен и как этого избежать
• JIT-баги: опасные и беспощадные
• Кто и как разматывает циклы
• Чем отличается размотка маленьких и больших циклов

Точка встречи сотового оператора с роуминговыми и домашними абонентами

В России 6 узловых аэропортов выделяются на фоне остальных. Долгие годы эта шестёрка преобладает в рейтинге самых загруженных аэропортов нашей страны. Большая часть авиаперевозок пассажиров приходится именно на них. Они концентрируют в себе порядка 70% общего трафика пассажиропотока. Это: Домодедово (33,04 млн. пас. в год), Шереметьево (31,57 млн. пас. в год), Пулково (14,26 млн. пас. в год), Внуково (12,73 млн. пас. в год), Кольцово (4,53 млн. пас. в год) и Толмачёво (3,96 млн. пас. в год).


Географическое расположение крупнейших аэропортов России

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

Привет всем хаброюзерам. Хотел бы поделиться опытом создания нативных расширений для OS X.

AIR — просто потрясающая в своей кроссплатформенности среда. Пока дело не доходит до использования каких-то уникальных для платформы фишек. Именно с этой проблемой я столкнулся, когда передо мной была поставлена задача превратить браузерную flash-игру в десктопную для OS X. Всё это с использованием среды AIR мной было сделано за несколько часов и я не буду описывать этот процесс, так как в гугле на эту тему полно информации. Самое интересное началось тогда, когда появилась необходимость подключить к игре различные сервисы Apple, такие как GameCenter, In-App-Purchase и т.д. И здесь я столкнулся с трудностями. Дело в том, что есть куча готовых ANE, в том числе и бесплатных. Но вся беда в том, что все эти решения работают только для iOS. Для OS X же нет ни то, что готовых библиотек, но даже информацию по созданию этих библиотек приходилось собирать по крупицам с пары-тройки интернет ресурсов многолетней давности, постоянно натыкаясь на какие-то подводные камни или даже айсберги.

Сейчас же я хочу собрать все накопленные знания и опыт в одном месте и поделиться с вами, чтобы хоть немного уменьшить ту боль, через которую вам придётся пройти, если всё таки вы тоже решитесь на создание нативных библиотек для мака. Хотя после четырёх разработанных расширений для OS X они не кажутся такими уж сложными и мудрёными.

Выход смартфонов iPhone 6 и 6+ внесло некоторую дезориентированность в ряды дизайнеров и программистов, ведь раньше можно было просто нарисовать один макет под iPhone 5 и пропорционально уменьшить в 2 раза при разметке под предыдущие устройства. Но теперь ситуация несколько изменилась: первопроходцы-программисты сетуют, что макет, красиво нарисованный и сверстанный под iPhone 6, выглядит абсолютно непривлекательно, нечитаемо и нетапабельно на iPhone 5, ведь его как раньше просто пропорционально уменьшили. IOS HIG по этому поводу конкретных советов не содержит, поэтому для дизайнеров сейчас особо остро стоит вопрос о том, сколько же на самом деле дизайнов интерфейсов нужно рисовать, чтобы охватить всю текущую линейку iPhone-устройств? Давайте разбираться.

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

Как мы все с Вами знаем, MVP — это шаблон призванный отделить презентационную логику от логики приложения. В случае Unity3D, представлением может быть GameObject с набором прикрепленных к нему компонентов, необходимых для реализации презентационной логики ( в том числе и компонент самой презентационной логики — MonoBehaviour имплементирующий соответствующий интерфейс представления (View)).