Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!

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

Напомню, что мы делаем стратегию/тайкун с прицелом на ПК (Steam) с премиум монетизацией (никакого фритуплея). Следовательно, в этом ключе я и буду рассказывать.

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

По поводу “когда начинать пиариться” там же есть цифра “за пару месяцев до релиза” для мобильного проекта и до полугода для ПК. Это связано с тем, что на всем протяжении вам надо поддерживать интерес потенциального покупателя к вашей игре. И продолжительность этой заинтересованности разная для разных платформ.

Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств.

Мы познакомились с Владиславом Архиповым во время питерской конференции WNCONF, где он выступал с докладом. В его выступлении особое внимание уделялось важной для нас теме трактовки gambling для social casino. В ходе разговора, в котором участвовали и другие коллеги, выяснилось, что юридическим моментам в своей работе инди-девелоперы уделяют очень мало внимания, создавая необходимые документы по остаточному принципу. Мы решили восполнить этот пробел и провести вместе с практикующим юристом небольшой “ликбез”.

Что такое коллизии?

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

• Когда столкновение начинается и заканчивается
• Точку соприкосновения фикстур
• Вектор нормали к линии контакта фикстур
• Какая энергия была приложена и результат коллизии

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

Мне постоянно приходится слышать от студентов и начинающих гейм-дизайнеров – да, честно говоря, и от бывалых программистов тоже – один и тот же вопрос, который звучит примерно так: “Какую архитектуру AI мне выбрать для своего проекта?”. Этим вопросом пестрят форумы, его можно услышать на конференции разработчиков игр GDC, и, конечно же, его не один раз вспоминают во время пре-продакшна создатели любой игры – от AAA-класса до инди. Я работаю консультантом по игровому AI, поэтому я постоянно слышу ее от своих клиентов.

Обычно, самый лучший ответ на этот вопрос – «Когда как». Вот только подобный ответ мало кого устраивает, поэтому после него мне приходится устраивать самый настоящий допрос.

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

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

Содержание

1. Обзор алгоритмов
1.1. Полный перебор
1.2. Sweep & Prune
1.3. Регулярная сеть
2. Некоторые оптимизации
2.1. Sweep & Prune
2.2. Регулярная сеть
3. Сравнение скорости выполнения
4. Приложение (программа и исходный код)
5. Заключение

Мы рады объявить о запуске новой услуги — перевода средств с карты Payoneer в систему WebMoney. Мы всегда стремимся предоставить нашим клиентам и партнерам лучшие платежные решения: предоплаченные карты, US Payment Service, международные и местные банковские переводы, чеки, трансферы в местные электронные кошельки, различные дополнительные услуги и многое другое.
Видя огромный интерес пользователей к прямым переводам с предоплаченных карт Payoneer MasterCard в систему WebMoney, компания Payoneer запустила данную услугу.

Эта статья предназначена для тех пользователей unity3d, что уже хорошо знакомы с самим движком, но ещё не обладают достаточной собственной базой знаний для того, чтобы писать без дополнительного сёрфинга по интернету, с целью поиска возникающих иногда фундаментальных вопросов. Чтобы сократить некоторым время на ресёч, расскажу несколько важных фишек, которые необходимо знать каждому unity программисту. Если у Вас возникают вопросы: как сделать чтобы у Вас не тормозило на чём-то послабее iPad 3, или Вы не знаете как удобно работать со спрайтами, как заставить музыку не прерываться при загрузке, или как обойти максимальный допустимый размер под android (50 мегабайт) и так далее, возможно Вы найдёте ответ в этой статье.

Статья затрагивает лишь проблемы мобильной разработки (IOS, Android). Все примеры только на C#.

Автор статьи не претендует на абсолютную категоричность и правильность предложенных решений.

Преамбула

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

Встал вопрос о создании новой небольшой игры. И дабы не повторить опыт предыдущей, я сел и написал список требований, которые нужно держать в голове при запуске в производство небольшого проекта для iOS. Конечно, он учитывает, что у разработчиков уже должен быть некий опыт и свои наработки. Без них некоторые пункты не имеют смысла. К тому же, список ориентирован не на все жанры, и во многом определен нашими играми. Но что-то для себя из него, думаю, может почерпнуть каждый.

Добрый день сообщество,

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

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

У вас никогда не возникало ощущения, что в языке X, на котором вы в данный момент программируете чего-то не хватает? Какой-нибудь небольшой, но приятной плюшки, которая может и не сделала бы вашу жизнь абсолютно счастливой, но определенно добавила бы немало радостных моментов. И вот вы с черной завистью посматриваете на язык Y, в котором эта штуковина есть, грустно вздыхаете и тайком льете по ночам слезы бессилия в любимую подушку. Бывало?

Все нетривиальные абстракции дырявы

Джоэл Спольски – Закон дырявых абстракций

А иногда дырявятся и довольно простые абстракции

Автор этой статьи


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

Когда-то давно, в «небольшой» мелкомягкой компании решили, а почему бы нам не «абстрагироваться» от местоположения объекта и сделать сам факт того, является ли объект локальным или удаленным, лишь «деталью реализации». Так появились технологии DCOM и ее наследник .NET Remoting, которые скрывали от разработчика, является ли объект удаленным или нет. При этом появились все эти «прозрачные прокси», которые позволяли работать с удаленным объектом, даже не зная об этом. Однако, со временем выяснилось, что эта информация архиважна для разработчика, поскольку удаленный объект может генерировать совершенно другой перечень исключений, да и стоимость работы с ним несравнимо выше, чем взаимодействие с локальным объектом.

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