Когда речь идёт о программном обеспечении, термин «взлом» зачастую ассоциируют с пиратством и нарушением авторских прав. Данная статья не об этом; напротив, я решительно не одобряю любые действия, которые прямо или косвенно могут навредить другим разработчикам. Тем не менее, эта статья всё же является практическим руководством по взлому. Используя инструменты и методы о которых далее пойдёт речь, вы сможете проверить защиту собственной Unity игры и узнаете, как обезопасить её от взлома и кражи ресурсов.

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

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

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

Наверное, не ошибусь, если скажу, что более 90% жителей России знающих, что такое светодиодные ленты, на вопрос «можно ли трансформаторы от „галогенок“ использовать для питания светодиодных лент?» ответят «нет, нельзя!». Самым распространенным объяснением станет банальное «электронный трансформатор – это переменный ток, а светодиодам нужен постоянный». Именно так нам говорят в магазинах, именно такой лейтмотив имеют подавляющее большинство «профессиональных» статей на эту тему, чем, в общем-то, и приучили людей тратить заметно больше денег.

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

Сразу оговорюсь, что для обозначения «светодиод» я и далее буду применять само собой напрашивающееся и вполне естественное сокращение СД и намеренно не буду использовать для этого понятия английскую техническую аббревиатуру LED (Light Emitting Diode). В нашей нынешней стране отсутствие какой либо должной технической подготовки менеджеров и продавцов в магазинах уже привело к замусориванию и появлению таких неестественных для технического языка, юродивых для слуха и ужасных в написании буквосочетаний «леды», «led’ы», «ледовые», или как недавно увидел бегущей строкой — «LEDовые светодиоды». Мало того, что «масло – масляное», я просто вторить и плодить это «словомутие» не хочу…

Идейным источником написания исследования стало давнее желание опровергнуть необоснованные и безаппеляционные утверждения о недопустимости питания СД переменным током. В общем-то спорность этого утверждения наверняка бросается в глаза любому специалисту (а равно и «неспециалисту»), понимающему, что светодиод, хоть и излучает свет, есть прежде всего – ДИОД. А это значит, что излучать под воздействием переменного напряжения он все же будет, но только в свой полупериод.

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

Не успела улечься волна реакции на недавнюю покупку Фейсбуком компании Oculus VR, как новое событие «взорвало» новостные ленты. К команде, занимающейся созданием Oculus Rift, следом за Джоном Кармаком присоединяется еще один специалист звездного уровня — это Майкл Абраш, возглавлявший до этого команду исследований VR в компании Valve.

Новость вдвойне приятная – ведь Кармак и Абраш уже работали бок о бок в один из самых светлых периодов жизни id Software. История гласит, что Кармаку достаточно нелегко давалось создание движка Quake — бросив на него все свои силы, Джон круглосуточно занимался только им одним, но все равно решить всех проблем не получалось. Джон принялся убеждать Майкла Абраша — уже на тот момент одного из самых талантливых программистов графики, которым Кармак искренне восхищался — присоединиться к нему и переманил его из Microsoft, где тот занимался графикой и ассемблерной частью в Windows NT 3.1. Он был из тех программистов, кто любит решать самые трудные и интересные задачи, и не смог устоять перед предложением Кармака.

Вот так в середине 1990-х Абраш присоединился к id Software для работы над Quake и, как мы все знаем сегодня, помог Джону разрешить все критические вопросы создания настоящего трехмерного движка. В те времена Майкл также принял участие в разработке Doom. После того как Quake был выпущен, Абраш вернулся в Microsoft, где работал над распознаванием естественных языков, затем перешёл в команду Xbox до 2001 года.

Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.

Топик с Hacker News, под которым мог бы подписаться я и куча людей с Хабра. Сегодня я публикую перевод только вопроса, давайте попробуем посоветовать этому парню, да и всем остальным бедолагам, как найти свет в конце туннеля. Завтра опубликую интересные ответы людей с Hacker News.

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

Мне скоро 30, и я чувствую, что попал в тупик. У меня было много проблем и, к счастью, большинство из них я решил с помощью очень хорошего школьного психолога. Я никогда не ходил в колледж, несколько лет провёл прыгая с одной унылой работы на другую. Сейчас занимаюсь продажами.

Я сам научился программировать на старом Commodore Amiga. С тех пор я изучил много различных языков на нескольких платформах. За эти годы я начал бесчисленное множество проектов — больше, чем могу вспомнить. Проблема в том, что я не закончил ни одного из них. Я либо тратил несколько недель или месяцев на рефакторинг и переписывание кода или, что происходило более часто, закончив писать код, я опускал руки, вместо того, чтобы приступить к дизайну, документированию и отладке. То же самое творится и в других областях моей жизни. Самоделки, планы путешествий, образование, карьера… Всё это запускается, но ничего из этого не завершено.

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

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

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

Прочитав много литературы по истории бизнеса и наблюдая рост популярности Интернет-торговли, автору этих строк хотелось реализовать свои знания на практике. Искали подходящую тему для проекта. Необходимыми условиями были:

1) Вложение не более $10 000
2) Прибыль не менее $1 000 в месяц
3) Минимальная рутина

По первым двум пунктам все понятно. А вот по третьему пункту поясню. К тому моменту я уже работал в собственной компании (сфера финансов). Это был 2009 год. Последствия кризиса еще сильно влияли на основной бизнес и работы было непочатый край. Много времени отвлекать на сторонний бизнес автор не мог.
Подходящий случай подвернулся в октябре 2009 года.

Небольшое вступление

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

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

Большое вступление

Некоторое время назад мне захотелось прочитать цикл Дугласа Адамса «Автостопом по галактике». Я попробовал почитать несколько переводов и не один меня не устроил. Поэтому было принято решение — читать на английском! Найти эти книги в оригинале в наших книжных магазинах довольно сложно. А если и есть, то только первая часть цикла. В электронном виде найти несколько проще. Но я предпочитаю читать с бумаги (читалку на E-ink куплю обязательно — очень нравятся), поэтому книги я распечатываю.

Первые две книги выглядели так:


Я их прочитал с огромным удовольствием, но выглядели они не очень хорошо. И я решил, что «Life, the Universe, and Everything» нужно делать книжкой.

Процесс с картинками и комментариями под катом. Осторожно, действительно много картинок.

Отладка Windows Service приложений не такая тривиальная задача как кажется. Проблема в том, что при отладке этого типа приложений нельзя воспользоваться стандартными средствами Visual Studio такими как точки останова (breakpoints) и прочими полезными инструментами. Всё из-за того, что Windows Service приложение не может быть зыпущено по F5 прямо из Visual Studio. Всё же, MSDN предлагает нам несколько способов для их отладки. Скорее всего многие разработчики даже и не сталкивались с ними до тех пор, пока не стали создавать свою первую службу. Это использование записей в журнал событий и подключение к процессу. Оба этих метода хорошо описаны в MSDN, но они позволяют произовдить отладку только уже запущенной службы. Из-за этого код, который производит сам запуск службы, в методе OnStart(), нельзя протестировать.

Ниже я хочу рассказать о способе которым можно обойти это ограничение, и тестировать свой сервис как обычное консольное приложение. И, следовательно, воспользоваться всем тем, что предлагает нам для этого Visual Studio.

Предисловие

Хабралюди проявили некоторый интерес к Unity, поэтому открываю этим постом цикл туториалов, освещающих основные моменты работы с объектом (цикл неопределённой пока длительности — если кому окажется полезным продолжу).

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

На хабрахабре периодически предпринимаются попытки описания процесса игроделания с самых разных сторон — от воплощения 3D-графики до создания сетевых протоколов. Эти темы, безусловно, важны, однако довольно узкие. В данной статье я попробую использовать более широкий подход — рассмотрю принцип создания игрового движка для т.н. казуальных игр. Описываемая механика вполне подойдет для создания всяческих пакманов, арканоидов, платформеров и пр. Описание процесса будет на примере примитивного scrolldown шутера (из ностальгических чувств к Zybex и Xevious) — летаем по полю, сбиваем метеориты. Инструмент — Qt.