Привет Хабровчане!

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

Хотелось бы поделиться разработкой, которую мы успешно внедрили у себя в Heyworks и используем на проекте Pocket Troops (Неудержимые). Проблема, с которой сталкивались и сталкиваются все разработчики, при чем не только работающие с NGUI и Unity3d, но и с другими движками и пакетами, это поиск золотой середины между качеством и весом игровых интерфейсов (впрочем, это не только интерфейсов касается). В этой статье я постараюсь помочь убить двух зайцев одной пулей.

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

Итак, что же такое дождь или снег в реальном мире?

Совсем недавно на работе стало необходимым контролировать рост размера базы данных Oracle. Связано это было с тем, что места осталось не так много, что -то около 100 Гб, а в двух компаниях (компании крупные, страховые) базы стремительно растут.

Для начала мы создадим таблицу DB_TABLESPACE_SIZE, в которой будем хранить данные о каждом дне.

• Игровой backend: из каких модулей он должен состоять?
• Расчет параметров персонажа: виртуальные методы или сложение массивов?
• Логика поведения: на каком уровне она должна находится?
• Перемещение персонажей: кто этим должен управлять?

        Сегодня мы продолжим знакомиться с разработкой и проектированием он-лайн игры на примере космической ММО RPG «Звездные Призраки». В этой статье речь пойдет о backend'е на С++ и она будет насквозь техническая.

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

        В статье мы сосредоточимся именно на архитектурных решениях применительно к backend'у MMO RPG в реальном времени. Исходного кода будет не много и он точно не будет содержать таких специфических для С++ вещей как множественное наследование или шаблоны. Задача данной статьи помочь в проектировании игрового сервера и ознакомить всех желающих со спецификой игрового backend'а.

        Описываемые решения достаточно универсальны и вполне подойдут для многих RPG. В качестве иллюстрации в конце статьи я приведу пример использования описанной архитектуры в игре «про эльфов».

Современную мобильную игру трудно представить без социальной интеграции, общих таблиц рекордов (leaderboards) и достижений (achievements). Дабы не отставать от тенденций, решил интегрировать Game Center и Play Services для iOS и Android версий моей игры.

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

Добрый день.
Меня зовут Головач Иван, я руковожу небольшой образовательной компанией и преподаю сам:

1. Java Core
2. Junior Java Developer: Servlet API, JDBC, Maven, JUnit, Mockito, Log4J, основы Spring/SpringMVC, основы JPA/Hibernate, шаблоны/архитектуры MVC/IoC/DAO.
3. Multicore programming in Java.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

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

(GolovachCourses.com)

Здесь собраны несколько вариантов записи моего курса Java Core.
Модуль #1 (Procedural Java):
Набор июль 2013: #1, #2, #3, #4
Набор апрель 2013: #1, #2, #3, #4
Набор февраль 2013: #1, #2, #3, #4
Набор январь 2013: #1, #2, #3, #4
Набор октябрь 2012: #1, #2, #3, #4.

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

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

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



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

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

Любой нормальный сайт\приложение нынче позволяет зарегистрироваться, используя аккаунты третьих служб. И если по англоязычным\русскоязычным информации более чем достаточно, то по китайским (в русском сегменте Интернета) — кот наплакал. Между тем, помимо того, что это около 700 млн пользователей интернета, это еще и более 5 млн китайцев, посетивших Россию в 2014 году и около 500 тысяч китайцев, оставшихся в России на временное\постоянное проживание — в первую очередь студентов. Так как интеграция китайцев в местное общество всегда проходит со скрипом, они предпочитают пользоваться программным обеспечением, знакомым с детства — таким, как интернет-мессенджер QQ.

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

Не секрет, что в России c 01.09.2012 года были введены возрастные ограничения на ТВ, поэтому совсем неудивительно, что ограничения по возрасту распространяются и на игры в Windows Store. Учитывая, что вы можете предоставить вашу игру для рынков различных стран, желательно знать и особенности иноземного лицензирования.

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

В некоторых случаях необходимо работать над снижением размера сборки для Андроид. Например, установка тяжеловесных APK для пользователей мобильного интернета может влететь в копеечку. Превышение размера APK в 50 Мб в Google Play выливается в дополнительные трудности при аплоаде.



Мы разрабатывали под Андроид на Unity 2D-игру, которая изобилует картинками (большинство с областями прозрачности) и разнообразными звуками, и столкнулись с проблемой размера APK. Забегая вперед скажу, что решив ее и снизив вес в 1,5 раза, мы получили в 1,5 раза больше скачиваний. Заставляет задуматься, не правда ли?

Рассмотрим, в качестве примера, следующую ситуацию. У нас имеется класс User с полями, описывающими пользователя. Имеется класс Phone, который является родительским для классов CellPhone и SatellitePhone. В классе User есть поле содержащее список телефонов пользователя. В целях уменьшения нагрузки на БД мы сделали этот список «ленивым». Он будет загружаться только по требованию.


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

В данной статье я расскажу, как быстро добавить в ваше приложение для Android боковое меню (aka Navigation Drawer) в стиле Material Design. Для этого мы воспользуемся библиотекой, любезно предоставленной Mike Penz.

У вас получится Navigation Drawer, который:

• Соответствует последним рекомендациям по дизайну (Google Material Design Guidelines);
• Поддерживает использование нескольких Drawer (можно выдвигать второй справа);
• Поддерживает использование бейджей;
• Имеет простой и понятный интерфейс (API);
• Может выползать как под, так и поверх Status Bar;
• Позволяет менять иконки, цвета, бейджи во время выполнения;
• Использует AppCompat support library;
• Работает, начиная с API 14.

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

У меня было локализованное приложение для Windows Store. В нем была возможность переключить язык на английский, но даже с английским интерфейсом приложение продолжало удивлять англоязычных пользователей русскими кириллическими «иероглифами» на заставке и логотипах. А русскоязычные пользователи в свою очередь удивлялись тому, что приложение называлось не по-русски. О том, как получилось такое безобразие и как сделать хорошо эта статья.

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

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

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

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

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

Команда подобралась настолько компактной, насколько возможно: серверщик, клиентщик, дизайнер, художник-аниматор. Раздувать штат инвестор не хотел, потому как сам не был уверен в целесообразности данного предприятия. При этом каждый (кроме, пожалуй, меня) хорошо знал своё дело и был в нём действительно хорош. Казалось бы, всё должно получиться!

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

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

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

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

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

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

Дисклеймер
Этот пост является некоторым развитием идей поста «Простая система событий в Unity». Я не претендую на единственный верный подход к вопросу и вообще являюсь посредственным программистом, относительно мастодонтов, которые обитают на хабре. Так же я очень поверхностно знаком с C#, так как в основном работе использую Java. Тем ни менее судьба занесла меня в Unity и я понял что у меня есть некоторый инструмент, которым можно отплатить сообществу за то, что я у него взял. Проще говоря внести свой, пусть и маленький, вклад в открытый и, хочется верить, хороший код.

Кому лень читать проблематику, выводы и прочее могут сразу посмотреть код с примерами на гитхабе — github.com/erlioniel/unity-smessage
Там даже можно .unitypackage скачать :)

На сегодняшний день существует немалое количество обзорных статей о PhoneGap, но к сожалению, написаны они или front-end разработчиками, которые решили заняться мобильными платформами, или нативными программистами, которые решили попробовать себя в кроссплатформенной разработке. И именно с этих позиций рассматриваются достоинства и недостатки PhoneGap'а, возникают статьи о том, «насколько крута кроссплатформа», или об «ущербности кроссплатформенных решений».

В качестве затравки — видео демо-приложения, написанного за 6 часов; готовым был взят UI-бутстрап, наверстанный за 3,5 часа; использовались библиотеки iScroll, backbone, underscore, Jquery, и небольшая обертка на backbone (RAD.js — rapid application development, архитектурный фреймворк, берущий на себя часть оптимизации, связанной с мобильной средой выполнения).


Еще 2 часа было потрачено на фикс движка. Но сегодня речь не о том, что что-то тормозит, дергается, или самописный свайп не всегда вовремя отрабатывает на 14000 объектах данных; речь о том, что на PhoneGap можно и нужно писать.

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

Привет, друг! В этот раз я опять подниму вопрос о графике в ААА-играх. Я уже разобрал методику HDRR (не путать с HDRI) тут и чуть-чуть поговорил о коррекции цвета. Сегодня я расскажу, что такое SSLR (так же известная как SSPR, SSR): Screen Space Local Reflections. Кому интересно — под кат.