Прежде чем начать, хотелось бы сделать две ремарки:

1. Мне хорошо известна целевая аудитория Хабра и, возможно, поэтому для неё данный материал будет не просто понятен, но и прост. Но с другой стороны, именно вы, жители одного из самого большого it-сообщества в СНГ, сможете всегда дать своим знакомым или просто встретившимся в Сети людям этот материал, чтобы наконец-то избежать очередного, искусственного пузыря.
   
   
2. Второй аспект заключается в том, что понимание и систематизированное знание — две качественно разные категории, поэтому мне, в рамках развития единой репутационной системы (о ней — как-нибудь в следующий раз), хотелось бы начать структурировать то, что известно.
   

Scam — это обман

Чтобы понять, что scam явление не новое, нужно лишь добавить к нему точку и com — http://scam.com — выдаст сотни результатов по теме. И это неудивительно: людям свойственно ошибаться, а значит всегда найдутся те, кто превратят их ошибки в бизнес.

И вот об этом поподробней.

Всем привет! В нескольких статьях я хотел бы поделиться опытом создания подобия ММО игры используя Unreal Engine и Netty. Возможно архитектура и мой опыт кому-то пригодится и поможет начать создавать свой игровой сервер в противовес unreal dedicated server, который слегка прожорлив или заменить собой фреймворки для разработки многопользовательских игр такие как Photon.

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

Часть 1. Общая картина, сборка библиотек, подготовка клиента и сервера к обмену сообщениями
Часть 2. Наращивание игрового функционала + алгоритм Diamond Square

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

Введение

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



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

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

Метод Уэлфорда — простой и эффективный способ для вычисления средних, дисперсий, ковариаций и других статистик. Этот метод обладает целым рядом прекрасных свойств:

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

Оригинальная статья Уэлфорда была опубликована в 1962 году. Тем не менее, нельзя сказать, что алгоритм сколь-нибудь широко известен в настоящее время. А уж найти математическое доказательство его корректности или экспериментальные сравнения с другими методами и вовсе нетривиально.

Настоящая статья пытается заполнить эти пробелы.

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Посуда в нашем доме всегда была чистая. Потому что после трапезы мы играли в японского дурака. Папа, мама, братья, дети садились за стол (вернее не вставали от него) и играли, пока не была вымыта последняя сковородка.

Игра очень простая, быстрая и азартная. Один на один. Колода 36 карт. Разыгрывалось 18 взяток. Кто брал меньшее число взяток — тот мыл тарелки. Например, я выиграл 11 взяток, соперник — 7. Неудачник отправлялся мыть 11 — 7 = 4 посудины. Было выгодно проигрывать первые раздачи, при наличии слегка запачканных вилок, чайных ложек и стаканов. Под конец бедолагам оставались лишь жирные сковородки и неподъемные кастрюли.

К сожалению, прошло время, и я стал жить вдали от родного дома. Скучал по родителям, игре и чистой посуде.
Да-да, однажды мне надоело скучать, и я написал Японского Дурака для iPhone и Японского Дурака для iPad.

Что было интересного при создании карточных игр, читайте в моем скромном опусе.

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

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

Продолжение:
Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер).
Пишем свой упрощенный OpenGL на Rust — часть 3 (растеризатор)

Наверное, мало кто на хабре не в курсе, что такое Rust — новый язык программирования от Mozilla. Уже сейчас он привлекает много интереса, а недавно наконец вышла первая стабильная версия Rust 1.0, что знаменует собой стабилизацию языковых возможностей. Мне всегда импонировали системные ЯП, а уж идея системного языка, предлагающего безопасность превосходящую языки высокого уровня, заинтересовала еще больше. Захотелось новый язык попробовать в деле и, заодно, интересно провести время, программируя что-нибудь увлекательное. Пока думал, что бы такого на расте написать, вспомнился недавний цикл статей про компьютерную графику, который я лишь бегло просмотрел. А очень интересно было бы попробовать все-таки написать все эти красивости самостоятельно. Вот так и родилась идея этого хобби-проекта, а также данной статьи.

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

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


Here is the Rust, which i hope to get at the end. (игра слов, Rust по-английски «ржавчина»)

В прошлом, обрабатывать фатальные ошибки было практически невозможно. Обработчик, установленный set_error_handler вызван не будет, скрипт просто будет завершен.
В PHP 7 при возникновении фатальных ошибок (E_ERROR) и фатальных ошибок с возможностью обработки (E_RECOVERABLE_ERROR) будет выброшен exception, а не произойдет завершение скрипта. Но определенные ошибки, например «out of memory», по прежнему приведут к остановке. Не перехваченные ошибки в PHP 7, будут «фатальны», так же как и в php 5.*.

Обратите внимание, что другие виды ошибок, такие как warinng и notice остаются без изменения в php 7.

Исключения выброшенные из E_ERROR и E_RECOVERABLE_ERROR не наследуются от Exception. Это разделение было сделано, чтобы предотвратить обработку этих ошибок кодом, написанным под 5.*. Исключения для фатальных ошибок теперь являются экземпляром нового класса: Error. Как и любые другие исключения, Error может отловлен, обработан и выполнен finally блок.

Лето – пора больших свершений. Потратьте время отпусков с пользой: читайте наш новый дайджест и создавайте потрясающие игры на Unity.

Среди задач мобильного разработчика, помимо самой частой (написания, собственно, приложений) периодически появляется и такая, как создание sdk.

Примерами такой задачи может быть создание sdk, использующего REST API какого-либо сервиса (реклама, аналитика, погода), библиотека реализаций алгоритмов, обработка изображений… Список практически неограничен.

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

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

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

Пожалуй, для многих новость о выходе новой системы Unity UI (далее просто UI) не показалась чем-то значимым. Как минимум — по причине её сырости, как максимум — из-за существования NGUI. Я поначалу не стал исключением, но открытие исходного кода UI системы (1) под либеральной лицензией MIT/X11, а так же энтузиазм разработчиков Unity Technologies заставили меня изменить мнение.

На мой взгляд, новый UI принесет нам довольно много плюсов:

• Вполне достойный инструмент из коробки;
• Возможность более глубоко понимать работу UI благодаря наличию исходников;
• Общепринятый механизм внесения изменений в исходный код UI — fork/pull request;
• Здоровая конкуренция между разными системами UI в конечном итоге принесет свои плоды в виде более качественных и удобных инструментов для Unity, а возможно и демпинг цен;
• Тесное взаимодействие команды разработки UI и ядра Unity уже сейчас приносят плоды в виде оптимизаций производительности, да и в будущем надеюсь они будут идти нога в ногу.

Всем привет,

Недавно мне попалась на глаза статья о том, что в IT компаниях готовятся к небольшим кадровым проблемам из-за того, что заработная плата в РФ немного упала в долларовом эквиваленте. Несмотря на это, доход компаний, работающих на экспорт, не сильно менялся (опять-таки, если смотреть в долларах), а таких около 80% компаний. То есть, цена на одного разработчика в РФ стала меньше раза в два, чем была где-то год назад. Логично, что в этом случае вероятен рост спроса на разработку в РФ (а также в соседних странах), что может повлиять на кадровый рынок IT.
Очень похожая ситуация с валютой случилась год назад на Украине, где в итоге заработная плата в IT сфере выросла, по сравнению со среднерыночной по стране. Опять-таки, логично предположить, что заработная плата в IT отрасли в РФ сделает похожий финт (то есть вырастет на величину, пропорциональную роста доллара по отношению к рублю).

Следовательно, у меня вопрос к читателям: а как обстоят дела в Ваших компаниях? Собираются ли они индексировать зарплаты? Увеличилась ли текучка кадров? Стали ли набирать они новых сотрудников?

Графические дизайнеры, мультипликаторы, архитекторы и разработчики игр очень часто используют различные библиотеки текстур. Есть платные сервисы, есть бесплатные, созданные энтузиастами. Тем не менее, любого количества текстур и материалов, которые сейчас можно найти, все равно недостаточно. Компания Quixel, которая давно уже заявила о намерении запустить сервис Megascans, с тысячами моделей и онлайн-текстур, таки выполнила свое обещание.

По словам разработчиков, теперь любой человек или компания смогут воспользоваться онлайн-библиотекой Megascans, «выводя CG на качественно новый уровень). Библиотека пополняется каждый день.

Содержание:



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

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

Под катом вас также ждет конкурс с призами от компании JetBrains!

Несмотря на то, что в Objective-C 2.0 присутствуют замыкания (известные как блоки), ранее эппловский API использовал их неохотно. Возможно, отчасти поэтому многие программисты под iOS с удовольствием эксплуатировали сторонние библиотеки, вроде AFNetworking, где блоки применяются повсеместно. С выходом Swift, а также добавлением новой функциональности в API, работать с замыканиями стало чрезвычайно удобно. Давайте рассмотрим, какими особенностями обладает их синтаксис в Swift, и какие трюки можно с ними «вытворять».



Продвигаться будем от простого к сложному, от скучного к веселому. Заранее приношу извинения за обильное использование мантр «функция», «параметр» и «Double», но из песни слов не выкинешь.

В конце октября в Москве прошла наша первая конференция мобильных разработчиков #MBLTDev. 17 докладчиков из Англии, Германии, Голландии, Дании, России и США пришло послушать более 300 человек.

Мы будем постепенно выкладывать записи докладов с презентациями и начнем с доклада канадского блоггера Эша Фюрроу «Реактивное программирование на Swift». Помимо ведения блога, Эш является iOS-разработчиком онлайн галереи Artsy и автором нескольких книг про iOS-разработку.


Презентация

В своем докладе Эш познакомил аудиторию с основами фреймворка ReactiveCocoa, проиллюстрировав их примерами на Swift. Также, он рассказал о приложении, над которым он в данное время работает в Artsy с использованием этих инструментов. Приложение, что примечательно, с открытым исходным кодом и доступно на GitHub.

Хочу поделиться еще одним вариантом реализации стейт машины (конечного автомата) для Unity. Статьи про конечные автоматы в привязке к Unity и/или C# на Хабре уже были, например, вот и вот, но я хочу продемонстрировать несколько иной подход, основанный на использовании компонентов Unity.