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

Еще несколько месяцев назад, открывая социальную сеть или сайт, вы неизбежно сталкивались с упоминаниями о «Flappy Bird». То, что начиналось, как очередной независимый проект одного-единственного разработчика из Вьетнама, стало глобальной сенсацией, вызвавшей невероятное количество слухов, дискуссий и загадок, а также суматоху, отчужденность и безмерный гнев.

Хотел ли создатель игры Донг Нгуен (Dong Nguyen) намеренно вызвать что-то из вышеперечисленного? Ни в малейшей степени. После того, как буря улеглась, он впервые нарушил свое молчание с тех пор, как удалил игру из магазинов приложений для iOS и Android, сказав, что он сделал это ради блага самих же игроков, т.к. боялся, что игра вызывает слишком сильную зависимость. Гипотетически, это совсем даже неплохо для разработчика игр.

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

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

Сразу – вводная, которую я сама себе нарисовала, еще планируя выход на рынок. Во-первых, на раскрутку приложения я не буду тратить ни копейки денег. Не потому что их нет (хотя…), а пока из принципа – чтобы собрать максимальный урожай с бесплатных вариантов. Во-вторых, ограничиться только установками через Гуглоплей. И сразу же спойлер – первое пока удается (потрачено 0 р. 00 коп.), второе – уже нет.

И еще один спойлер — под катом анализ конверсии до и после привлечения аудитории торрентофилов…

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

1. Никто ничего не знает

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

Примерно 30 процентов вашего времени будет потрачено собственно на создание игры. Остальное время вам потребуется тратить на другие дела. Вообще-то вам повезет, если вы будете тратить 4 месяца в году на, собственно, саму игру. Вы, наверное, не знаете многого о том как вести бизнес, о маркетинге и тому подобном, но вам придется этим заниматься. И, конечно, вы ничего не знаете о будущем, например, о том, какие платформы будут через 5 лет, как будут меняться технологии или аудитория.

Что же делать?

Здравствуйте, дорогие разработчики!
Сегодня я хочу рассказать вам о том, как погрузиться непосредственно в создание игры так, чтобы можно было забыть об платформах, sdk, компиляторах, сборках, деплоях и прочих ide. Есть способ просто писать код на современном высокоуровневом языке и быстро его тестировать на всех платформах, поддерживаемых вашей хост осью.

Традиционно к новогодним праздникам Plarium выпускает масштабные обновления своих проектов. В этом году для стратегии «Войны престолов» мы создавали нового юнита – Ледяного Стража.

Запасайтесь горячим чаем – под катом история о том, как был сотворен самый хладнокровный воин за всю историю Даркшайна (и много скриншотов рабочего процесса).

Так уж случилось, что игры я писал лишь для себя, и профессионально этим никогда не занимался.
А вот опыт писать DSL (Domain Specific language) для уменьшения рутины написания совершенно разного кода хоть какой-то есть.
Именно этим и хочется поделится: как упорядочить необъятное.



Наш хороший хабр-юзер GlukKazan пишет много статей о том какие есть замечательные продукты для создания различных досочных игр. Такие как Zillions of Games и Axiom Development Kit.
Однако эти программы не универсальны. И всегда хочется улучшить их. Но данные продукты не свободны, поэтому приходится писать программный продукт заново.
GlukKazan работает над открытым проектом Dagaz, о чём делится отличными статьями (например тут: Dagaz: Новое начало).

Итак, предположим, мы хотим создать универсальный игровой движок для настольных игр, и его основой мы хотим видеть скриптовый язык, который помогает растолковать движку правила игры.
Каким мы хотим его видеть?
1) Язык должен быть универсальным, насколько можно, дабы описать почти любые правила игры.
2) Тем не менее, язык должен быть как можно проще, минимум конструкций.
3) Описание правил должны быть легки для чтения игроделу и для написания своих игр
4) Для большинства случаев игры можно писать, дополняя/изменяя уже написанные
5) Коммуникация (АПИ) со скриптом должна быть насколько простой, насколько это возможно. Так, что бы можно легко писать ботов и ИИ.
На первый взгляд кажется, что потраченные усилия вообще никому не нужны будут, поскольку рутину не уменьшить, проще писать игры сразу готовыми.
Но это не так.
Всё куда проще!

Всем привет, с вами снова Delfuego FM, и я наконец-таки созрел, чтобы выложить вторую часть статьи! Вследствие неоднозначной реакции на первую часть, была предпринята попытка выложить вторую на geek times, и… она успешно провалилась. Поэтому придётся совершить небольшой хабрасуицид и выложить её прямо тут! Итак, поехали!..

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

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

После прочтения одной из статей на Хабре решил заняться разработкой игр для мобильных платформ. Решено было сделать игру для андроида, так как Window Store мне не нравится, a регистрация в Appstore стоит 100$.

Через 10 минут я придумал механику, которую ни у одной игры ещё не видел. По задумке, камера располагалась сверху (Top-down), на персонажа с разных сторон шли враги он автоматически по ним стрелял. От игрока только требовалось перемещать персонажа по экрану, чтобы враги его не задели. Суть игры в том, чтобы набрать как можно больше очков.

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

Речь пойдет о деле А40-91072/14-90-176 (ООО «Мэйл.Ру Геймз» против ИФНС №14), окончательное решение по которому было принято 24.11.2014 года Арбитражным судом города Москвы

Так уж получилось, что приложение для чтения комиксов и манги, которое я использую на своем android-смартфоне, после обновления стало показывать рекламу в конце каждой главы комикса. Данное приложение пару лет назад было доступно на Google Play (платная версия которого и была мной куплена), но было удалено в силу «нарушения авторских прав», после чего ушло в подполье и стало распространятся через сайт разработчика. Увы, достойных альтернатив этому приложению на android и iOS я не нашел, но и смотреть рекламу особо не было желания, тем более я уже покупал версию без рекламы. Сам разработчик почему-то не сделал возможности отключить ее, а на просьбы добавить такую возможность не отозвался. Поэтому пришлось искать альтернативные методы ее отключения. Первое, что пришло в голову, это то, что android-приложения пишутся на java, а значит есть вероятность, что автор не обфусцировал свое приложение и его можно попытаться декомпилировать. Немного подумав, я приступил к работе.

Недавно был озадачен проблемой мониторинга нескольких десятков серверов (ну наверно редко кто не сталкивался с такой задачей). Проблему можно описать несколькими правилами:

1. Нужно периодически пинговать сервер
2. Иногда выполнять какое-либо действие с сервером (например, исполнение команды через ssh), которое засабмитил пользователь
3. Действия с серверами могут нескольких типов, у каждого действия свой приоритет
4. Таски (из п.1-3) нельзя выполнять одновременно для каждого сервера
5. Таски могут завершаться с неудачей, например по причине отсутствия связи с сервером, нужно ждать пока связь восстановится и пытатся выполнить запланированную задачу

Для одного из своих Android-приложений Book Tracker я реализовал кастомный AutoCompleteTextView с подсказками для названий книг, которые динамически подгружаются с Google Books по мере ввода названия книги.

Задача перед компонентом стояла следующая:

• Загрузка данных должна осуществляться в отдельном потоке, чтобы не блокировать UI-поток;
• Загрузка подсказок должна начинаться только, если пользователь приостанавливает набор (чтобы предотвратить отправку множества запросов к серверу после каждого введенного символа);
• Подсказки должны загружаться, если пользователь ввел строку некоторой минимальной длины (нет смысла начинать загрузку данных для строки из двух или трех символов);
• При запросе к серверу в правой части поля должен быть показан анимированный прогресс, чтобы информировать пользователя о загрузке.

Финальный результат:

Мы уже много писали о возможностях, которые предоставляют современные коммутаторы с загрузочной средой ONIE и открытые ОС на базе Linux для них. Построение L3-фабрик, оверлейные виртуальные сети L2, — все это уже было. Но осталась нераскрытой одна важная тема, о которой много упоминалось — возможности по автоматизации.

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

Так что же мы получаем при использовании коммутатора c ОС на основе Linux, такой как Cumulus?

«Чтоб ты жил в интересные времена!» — якобы старинное китайское проклятие.
Да, нам с вами повезло или «повезло» жить в действительно интересные времена (вариант — «в эпоху перемен»). Возможно, это на самом деле проклятие, особенно с точки зрения мифических древних китайцев. Однако факт остается фактом: то, что еще пара десятков лет назад казалось невозможным, сейчас доступно практически каждому. Особенно это заметно в нашей отрасли — информационные технологии и цифровая электроника развиваются просто какими-то совершенно фантастическими темпами. Функциональные возможности, быстродействие, миниатюрность и (относительная) дешевизна современных цифровых решений поражает воображение.
Еще совсем недавно сетевой компьютер размером меньше кредитки и стоимостью в несколько сотен рублей, пригодный для создания на его базе интересных самостоятельных проектов энтузиастами-одиночками с относительно невысоким уровнем знаний в области электроники и программирования, казался весьма отдаленной перспективой. И вот уже мы можем смело выбирать из десятка (как минимум) альтернатив! Давайте посмотрим, что сейчас можно приобрести буквально за несколько десятков долларов, чтобы построить вокруг этого нечто впечатляющее и даже, может быть, полезное.

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

Немного лирики. Я – разработчик мобильных игр. Силами небольшой инди-команды мы разрабатываем небольшую, довольно хардкорную игру в стиле «два замка» для мобилок. Пару месяцев назад мы добрались-таки до момента, когда необходимо было определиться с выбором издателя.

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

В предыдущей статье «Транслируем звук по сети с помощью Java» я описывал способ приема и трансляции звука по сети встроенными средствами Java.

Здесь я продолжу развивать эту идею, и расскажу, как сделать с помощью Java простую систему IP-телефонии.

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

Полностью исходники можно посмотреть на github.

Всех заинтересовавшихся прошу под кат.

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

В силу разных причин были выбраны Facebook, Vkontakte и Google+. Планировала добавить Twitter, но его Fabric к тому времени еще не вышел, а использовать стороннюю библиотеку не хотелось (см. п.2 ниже). Позже добавлю.

В итоге, задача для этих трех соцсетей получилась следующей:

1. Максимально простой программный интерфейс постинга ссылок.
2. Использование только нативных SDK (из тех соображений, что эти знания пригодятся в дальнейшем).
3. Минимум кода – только самое необходимое для работы.
4. Работать все должно вне зависимости от наличия у пользователя установленного клиента соцсети. Но если он есть – использовать диалоговые окна клиента.
5. Пользователю должно выводиться сообщение об успешном или нет размещении записи.
6. Должна быть возможность программно реагировать на успешное размещение записи.

Доброго времени суток %username%. Не давно наткнулся на хороший туториал по созданию клона игры Flappy Bird используя LibGDX и этот туториал мне понравился своей простотой и детализацией.

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

Туториал разбит на 12 дней, содержит множество картинок, полотен кода и исходный код разбит по дням. Кому интересно, добро пожаловать под кат.

Привет, Хабр!



Хочу поделиться с вами опытом разработки двух игр под Андроид, их продвижением и рассказать об ошибках, которые я совершал, и как я решил их избежать в будущем. Год назад я начал делать свою первую игру на Андроид. Всё начиналось с идеи. Обычная, ничем не примечательная — запоминать фигурки на экране. Ради опыта и своего первого проекта на Google Play я начал усердно работать с моим братом.

Ошибка №1 — Нежелание прислушиваться к чужому мнению

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