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

Давайте представим, что вас перевели на новый проект. Или вы сменили работу и о проекте максимум только слышали. Вот вы садитесь за рабочее место, к вам приходит менеджер, жмёт руку и… прямо сходу открывает страницу проекта, тыкает пальцем в монитор и просит вставить «информер о предстоящем событии Х». На этом вы расстаётесь… Что делать? С чего начать? Как создать «информер»? Где найти нужный шаблон? И море других вопросов.

Под катом будет рассказ, как мы стараемся организовать эти процессы, какие инструменты создаём для препарирования SPA. Кроме этого, мы поговорим о технических подробностях реализации Live Coding / Hot Reload и чуток о VirtualDom и React с Angular.

Как всем известно, 71% поверхности Земли занимает вода. К сожалению или к счастью, корректно изобразить океан умеют единицы. Иван Айвазовский вошел в учебники живописи благодаря одним только морским пейзажам. В компьютерных играх все еще сложнее. Когда-то море в них обозначали скоплением синих пикселей, раскрашенных белыми квадратами пены. Со временем виртуальные моря стали больше похожи на снимки из отпуска, научились качать волну и покрываться рябью, в которой иногда даже отражались очертания парусников. Но они оставались самостоятельной стихией: натолкнувшись на берег, волна превращалась в незамысловатые угловатые полигоны. Настоящий прибой логично взаимодействует с пляжем, увлажняет песок и с шуршанием откатывается назад. Такого правдоподобия удалось добиться только в современных играх. В том числе в нашем Skyforge. И хоть в основные события будут разворачиваться на суше, игроки попадут и на тропические острова, и в шумные порты. Вода будет постоянно рядом. Ее «правильный» облик будет играть большую роль. И воссоздание морской стихии – серьезная математическая задача. Расскажу об этапах ее реализации.

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

Настоящее время и воспринимаемое время

В данной статье хочу рассказать вам об опыте разработки одной простенькой игры под Android, которая многократно окупилась еще на стадии разработки!

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

Содержание

1. Памятка для начинающих
2. Основные принципы
3. Процесс
4. Инструменты
5. Словарь
6. Платформы
7. Другие ресурсы

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

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

От переводчика: этот пост — перевод одной из частей масштабного обзора физики (Sonic Physics Guide) в играх серии Sonic the Hedgehog для Sega Genesis/Mega Drive и Sonic CD. В следующих частях рассматриваются такие темы: бег, прыжки, вращение, потеря колец, поведение под водой, суперскорость, специальные возможности, камера, анимации и некоторые другие. Так как частей много (14 штук), в конце поста я добавил опрос. Стоит ли продолжать — решать вам.

Here comes.

Это будет длинный пост.

Запаситесь попкорном — я поведаю вам интересную историю… В общем, это будет одно из тысячи сочинений на тему «Как я написал свою игру». Сначала я планировал осветить как можно больше технических деталей, но потом понял, что их слишком много для одной статьи и она получится огромной. Поэтому «первая серия» будет, скорее, обзорной. Если будет интересно, то продолжу. Итак.

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

В качестве вступления

Ранее, в течение последних 2-х лет, были попытки запуска некоторых браузерных игр малого масштаба, которые собирали менее 1000 игроков, но в этой статье мы их затрагивать не будем. Рассказ пойдет о первом опыте создания браузерной онлайн-игры, которая в будущем будет стремиться выйти в массы.

Идея создания космической игры родилась довольно давно. Почему космической? Отчасти потому, что космическая тема всегда вызывала мой личный интерес, а отчасти, по причине ностальгических воспоминаний от приятного времяпрепровождения за «Космическими рейнджерами», когда-то в далеком прошлом…

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

Вычеркиваем

После непродолжительного подбора различных способов реализации, сразу были исключены варианты:

• с gif-анимацией (из-за низкого качества изображения);
• с Flash (по договоренности, Flash-технологии решили в проекте не использовать);
• с анимацией с помощью JQuery посредством функции $().animate (по причине ее прожорливости).

CANVAS в помощь!

Итак, остановились мы на использовании Canvas и JavaScript, посчитав этот вариант оптимальным для реализации нашей задачи.

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

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

Важные замечания:

• Пункты с неуказанным источником написаны мной самостоятельно. Поправьте меня, если вы заметите какие-то неточности. Предложите лучшую аналогию, если это возможно.
• Заголовки ссылаются на соответствующие им статьи в Wikipedia. Пожалуйста, читайте эти статьи для более серьезных и детальных объяснений.
• Аналогии — отличный способ объяснить материал, но они не идеальны. Если вы хотите по-настоящему понять перечисленные концепции, вам следует начать с фундаментальных азов и рассуждать, исходя из них.

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Кроссплатформенные инструменты разработки вроде PhoneGap и Xamarin сейчас популярнее, чем когда-либо. Это хорошо. Правда, причины такой популярности кроются отнюдь не в желании девелопера создать качественное приложение, которое понравилось бы пользователю. На самом деле причины несколько иные.

Согласно новому исследованию компании Visionmobile, базирующемуся на результатах опроса 8000 разработчиков, 30 % всех девелоперов, которые занимаются созданием мобильных приложений, используют кросс-платформенные инструменты. Но это вызвано желанием разработчика сэкономить свое время и деньги, а не улучшением взаимодействия с пользователями.

Привет!

Отгремели фанфары, прошел звон в ушах от истязаний «евангелистов», модников в сфере фронтенд разработки. Кто-то ушел на sprockets, кто-то пустился во все тяжкие и стал писать свои велосипеды или расширять функционал gulp или grunt. Но статей по поводу популярных инструментов автоматизации процесса сборки – стало существенно меньше и это факт! Пора бы заполнить освободившееся пространство чем-то существенно иным.

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

В своей статье я бы хотел поделиться технической частью игры, которую сделали два человека. Будут рассмотрены основные архитектурные шаблоны (design patterns) и приёмы, дополнительные библиотеки, особенности портирования при работе с движком cocos2dx. Исходный код здесь.

Здравствуй, Хабр! Ух! Давно же я не писал здесь. Итак, начну пожалуй с небольшой предыстории и заодно приведу скриншот получившейся игры.


Скриншот игрового процесса

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

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

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

Прочтите внимательно эту статью, если вы применяете упрощенную систему налогообложения с объектом налогообложения «доход» по ставке 6 процентов и продаете игры или приложения в Google Play, Apple App Store, а также прочий цифровой контент — например, 3D-модели — в Steam, Unity Asset Store или на других площадках, в условиях договоров с которыми фигурируют комиссии, агентские вознаграждения и прочие формы разделения выручки между сторонами.

Из материала вы узнаете:

• Почему разработчику желательно обладать хотя бы базовой юридической грамотностью
• Чем с точки зрения Гражданского кодекса являются игры и приложения и какие права на них есть у разработчиков помимо авторского права
• Что такое агентский договор и почему все это важно при работе по договору с Apple или Google
• Кто такой налоговый суслик и почему он может превратиться в пушного зверя
• Какой «подвох» существует для применяющих «упрощенку» в части определения налоговой базы
• Почему налог на добавленную стоимость (НДС) продолжает преследовать нас, даже когда мы не являемся его плательщиками
• Как, с точки зрения Федеральной налоговой службы, облагаются НДС внутриигровые покупки (InApp Purchases)