В мае 2010 года появилась игра Transformice, которую создали всего лишь два разработчика ради собственного удовольствия и в свое свободное время. Эта игра принадлежит к классу многопользовательских платформеров. Своим же успехом Transformice обязана публикациям на таких платформах, как 4chan и Something Awful.



После 4 лет и множества обновлений в игре зарегистрировано уже 60 миллионов учетных записей.

Нельзя сказать, что разработка игры Transformice уже завершена. Наоборот, эта игра находится в стадии активного развития. И сегодня я бы хотела рассказать о том, что мы делали эти четыре года как для развития игры, так и для ее монетизации, ведь сделать игру – непросто, но еще сложнее – заработать на этом деньги. Итак, цифры!

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

1. Power Bank на 30000mah, которая заряжается солнцем 12.70$ (3491 человек лайкнули)

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

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!

Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.

От переводчика: данная статья написана Дядюшкой Бобом в августе 2012 года, но, на мой взгляд, вполне актуальна до сих пор.



За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.

Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Практически всем, кто обучался программированию, известна книга Стива Макконнелла «Совершенный код». Она всегда производит впечатление, прежде всего, внушительной толщиной (около 900 страниц). К сожалению, реальность такова, что иногда впечатления этим и ограничиваются. А зря. В дальнейшей профессиональной деятельности программисты сталкиваются практически со всеми ситуациями, описанными в книге, и приходят опытным путём к тем же самым выводам. В то время как более тесное знакомство могло бы сэкономить время и силы. Мы в GeekBrains придерживаемся комплексного подхода в обучении, поэтому провели для слушателей вебинар по правилам создания хорошего кода.

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

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки

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

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

Что побудило меня написать это статью?

Первое. Зачем художнику рассказывать о тяготах жизни и о трудном пути, если у него вроде как все хорошо? Во-первых не так уж и хорошо (потому что всегда может быть лучше), а во вторых, для того чтобы идущие следом – не повторяли ошибок, стало быть не тратили свое драгоценное время. Сколько бы нам не было отпущено – все равно на все не хватит. Стоит постараться выделить важные вещи, и опустить незначительные.

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

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

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

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

Введение в проблему

Здравствуйте, дорогие читатели!

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

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

Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.

По мнению нидерландского сайта TRNDlabs коптер SKEYE Pico Drone с габаритами 22 мм* 22 мм * 19 мм и весом 7 грамм является наименьшим из существующих коптеров на данный момент.

Перед тем как начать писать этот доклад я прочел больше 115 постмортемов и историй инди разработчиков. Что я понял? Во-первых, что мой английский отстой. Во-вторых что инди очень разные. Очень. И чтобы каталогизировать их понадобилась куча времени.

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

Нитсух Абеб из New York Magazine выяснил, почему на краудфандинговой платформе Kickstarer так популярны проекты кошельков. Madrobots.ru представляет перевод этого любопытного исследования, а также рассказывает о собственных кошельках Zavtra, сбор средств на которые идет прямо сейчас на Boomstarter.



Если у вас когда-нибудь найдется время и желание подробно изучить содержание разделов «Дизайн» и «Технологии» на популярной платформе Кикстартер, то вы обязательно заметите странную «кошельковую активность», царящую на этом ресурсе. Нет, о технологической пандемии пока говорить не приходится: кошелькам посвящено где-то 0,3% от общего числа. Однако на фоне миллиона различных вещей, никак не представленных на Кикстертере или представленных в единственном экземпляре, десятки кошельков – это весьма немало.

Введение

Django — широко известный и один из наиболее развитых фреймворков для веб-разработки. Django написан на Python и, следовательно, для работы с ним потребуется установленный интерпретатор Python. Это не представляет никаких проблем, если мы работаем в среде Linux. Однако события принимают совсем другой оборот, если приходится заниматься разработкой на Python под Windows.

Для Windows есть готовые сборки Python, среди которых стоит отметить Enthought Python, Anaconda Python, PythonXY.
Есть и более простые пути.
Основной их недостаток по сравнению со «стандартным» Python в Linux — ограниченность набора библиотек, доступных для установки. В частности, в них не Django, и для его установки приходится совершать некие не совсем очевидные действия.

Один из возможных вариантов решения проблемы — установка виртуальной машины с Linux на борту. Работа с виртуальной машиной, несмотря на простоту ее установки и настройки, привносит ряд неудобств.
Так, виртуальная машина может оказаться довольно требовательной к ресурсам компьютера и временами работать медленно, создавая дискомфорт разработчику. Особенно сильно это раздражает, если торможение начинается в самый напряженный момент работы (а именно тогда это чаще всего и происходит!). Кроме того, даже на очень хорошем железе такое IDE, как PyCharm, работает в режиме далеком от того, который принято считать комфортным.

Повысить быстродействие можно за счет установки только необходимых пакетов, отсутствия оконного менеджера и тому подобных проблем. Т. е., необходимо правильно сконфигурировать виртуальную машину. И в этом деле на помощь приходит Vagrant — утилита для создания полностью готовых рабочих окружений на основе виртуальных машин (VirtualBox, VmWare Player/Workstation). Vagrant не только устанавливает виртуальную машину, но и позволяет с легкостью создавать новые, используя текущую конфигурацию пользователя.

В следующем разделе рассматривается установка и настройка рабочего окружения Vagrant для использования его в качестве удаленного Python интерпретатора для проектов PyCharm.

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

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

Предыстория

Так вышло, что я всегда хотел делать игры, но долго не мог выбрать идею и приступить к созданию. И после получения определенного опыта использования движка Unity, я решил, что настало время заняться своей игрой. Мне хотелось чего-то простого в плане разработки, но интересного с точки зрения геймплея. И уже тогда в моей голове начала зарождаться идея Layer Switch.

Хочу поделиться небольшим опытом, который я приобрел при создании своей первой игры для Andriod. Скажу сразу, на момент начала разработки мой опыт программирования был средним (1С и немного C#), а опыт в гейм-деве — нулевым. В качестве инструмента разработки был выбран Unity3D 4.6, привлекла мультиплатформенность и наличие большого количества видео-уроков. Т.к. я вырос на играх 80-х, то было решено попробовать сделать ремейк культовой игры Prehistorik 2, в итоге получилась 2D-аркада под названием Prehistoric Story. Начиналось всё это как хобби, а потом переросло в большой проект, благодаря которому много людей получили ценный опыт и практические навыки. Далее будет 5 ценных советов, основанных на моем личном опыте.

Какое-то время назад на сайте Юлмарта разрешили привязывать юридических контрагентов (организаций) к аккаунтам физ. лиц, если они ранее совершали покупки по телефону или добавить новую. Для идентификации организации выбрали ИНН и КПП, для аутентификации не выбрали ничего.

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

Вы неплохо владеете языком C# и платформой .NET в целом? Вам надоело стоять в стороне и смотреть, как кто-то другой пишет крутые мобильные приложения вместо вас? У меня есть для вас кое-что интересное! То, что поможет вам изменить сложившуюся ситуацию и позволит писать отличные мобильные приложения, не требуя отдельного изучения Objective-C и Java. Я расскажу вам о продукте Xamarin. Подробно и правдиво.

Что это?

Xamarin — это фреймворк для кроссплатформенной разработки мобильных приложений (iOS, Android, Windows Phone) с использованием языка C#. Идея очень простая. Вы пишете код на своем любимом языке, с применением всех привычных для вас языковых фич типо LINQ, лямбда-выражений, Generic`ов и async`ов. При этом вы имеете полный доступ ко всем возможностям SDK платформы и родному механизму создания UI, получая на выходе приложение, которое, строго говоря, ничем не отличается от нативных и (по крайней мере по заверениям) не уступает им в производительности.

Фреймворк состоит из нескольких основных частей: