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

Перед вами здание- склад, сгенерированное процедурно:

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

Небольшое лирическое отступление. LibGDX в значительной части представляет из себя простую обертку над OpenGL. Просто работа с текстурами. Все что мы делаем — это указываем порядок и способ отрисовки текстур. Базовый инструмент для рисования текстур — Drawable.

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

Атлас текстур

Одним из важнейших параметров «комфортности» приложения является время загрузки. Узким звеном в этом плане является считывание с накопителя. Если мы используем везде вот такие конструкции

Image(Texture("backgrounds/main-screen-background.png"))

то мы создаем избыточную задержки. В данном случае текстура «backgrounds/main-screen-background.png» будет считана с накопителя в синхронном режиме. Это не всегда является злом. Как правило загрузка одной фоновой картинки не портит впечатления от работы с программой. Но если мы будет каждый элемент нашей сцены считывать таким образом, скорость и плавность приложения могут серьезно просесть.

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

Первый commit для этой игры случился 4 июня сего года, то есть до открытой беты я дошёл примерно за 3 с половиной 4 недели. Нельзя сказать что это первая игра или программа под Android которую я разрабатываю, но и опытным разработчикам под Андроид я также не являюсь. Мой предыдущий опыт в основном составляла Enterprise разработка.

Я хочу обозначить несколько тем в этой статье и пробежаться по ним коротенечко. Тему Kotlin’a постараюсь раскрыть подробно, по остальным возможны дополнительные статьи если будет такой запрос от вас (ну и плюс уточняющие вопросы в комментариях помогут улучшить подачу материала). Итак к списку: это сравнение стоимости разработка на Kotlin vs Java, где брать графику для вашей игры. Немного про деньги (пока про затраты, т.к. статистики по доходам пока нет). Также я считаю очень важно коснуться мотивировочной части. Начнем пожалуй с конца.

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

Графика, это первое что бросается в глаза пользователю, запустившему ваше приложение. И хотя в Google Play есть несколько игр чисто текстовых, это исключение из правил. И в разработке подобных игр без сомнения полно своих подводных камней. Что же следует сделать инди-разработчику, чтобы не провалить то самое первое впечатление? В первую очередь следует на первых этапах разработки определиться с основным интерфейсом. Есть несколько практик как сделать это быстро и дешево:

И снова всем привет! Спешу поделиться, у меня были отличные выходные! Полтора дня я обдумывал вариант подачи материала, пилил макет и вообще всячески старался сделать хорошо. Что такое хорошо в контексте обучающего материала? На мой взгляд это «интересность», краткость, корректность и наглядность. Для меня лично написать такую статью — это подвиг. А вот серию статей — просто емкая и ответственная задача. Изучать Scene2d мы будем в процессе написания игры с нуля! Процесс нашего творчества растянется на долгие десять-двенадцать дней. Мне хочется верить что периодичность материалов будет примерно раз в день. Для меня лично это очень амбициозная задача, ведь требуется не столько запрограммировать, но и описать в статьях с детальным разбором. Я не сторонник бросаться в бушующий океан, в надежде научиться плавать. Мы прыгнем у лужу и будем последовательно ее углублять и расширять. Итак начинаем.

Эта статья является продолжением моего введения в алгоритм A*. В ней я показал, как реализуются поиск в ширину, алгоритм Дейкстры, жадный поиск по наилучшему первому совпадению и A*. Я стремился как можно больше упростить объяснение.

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

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

Всем привет! Решил я поделиться с Вами опытом «бесплатного пиара» в Google Play, а именно способами для достижения 2K установок в день без денежных вложений. Вся статистика прилагается +информация о доходах

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

Статистика, указанная в статье, собрана с нового приложения, которое живет с 24 мая 2017

Размеры объектов в Java уже обсуждались на Хабре, например, здесь или здесь. Мне бы хотелось подробнее остановиться на размерах многомерных массивов — простая вещь, которая для меня стала неожиданной.

Оптимизируя вычислительный алгоритм по памяти, я наткнулся на то, что при определённых (вполне разумных) входных параметрах создаётся массив float[500][14761][2]. Сколько он может занимать в памяти (на HotSpot 1.6.0_26 32bit, если кому интересно)? Я примерно прикинул, что 500*14 761*2*sizeof(float) = 500*14 761*2*4 = 59 044 000 байт плюс какой-то оверхед. Решив проверить, как на самом деле, я воспользовался Eclipse Memory Analyzer (невероятно волшебная вещь, рекомендую!) и обнаружил, что «Retained Heap» для этого массива составляет 206 662 016 байт! Неплохой оверхед — 350%. Посмотрим, почему так получилось.

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

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

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

Я ясно помню тот день в далеком 2014 году, когда я решил заняться программирование под Android. Это оказалось лучшим решением, которое я принял в моей жизни. Уже прошло почти два с половиной года, и за это время у меня возможность кое-чему научиться.

Когда я только начал, я не знал никого, кто мог бы научить меня, показать, как правильно нужно делать. И я совершил МНОЖЕСТВО ошибок, в так же потратил кучу времени на то, чтобы потом их исправить.

Полтора года спустя, мне выпал шанс поработать с очень талантливыми и опытными Android-разработчиками, которые направляли меня и помогли мне привести все в порядок. Эти две составляющие научили меня многому. Я понял, что надо ДЕЛАТЬ, а самое главное, что НЕ НАДО.

И уже какое-то время я, как могу, стараюсь помогать другим разработчикам — прямо или косвенно. Вот мои профили: StackOverflow и Github.

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

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

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

Начну с оговорки: эта статья относится не только к играм, сделанным в Unity, или к инди-играм, но в ней есть разделы, посвящённые только Unity, так что можно пропустить их, если вам нужны общие советы по локализации. Я написал эту статью, чтобы описать ВСЕ затраты, связанные с локализацией, и дать советы по снижению этих затрат.

Большинство игроков не пройдёт вашу игру до конца. Это не трагедия, а просто особенность дизайна видеоигр. Креативный директор Ubisoft Джейсон Ванденберге рассказывает, почему это так.

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

Продолжаем публикацию наших свежих образовательных курсов. За 14 лекций Технотрека вы получите необходимые навыки и опыт в области разработки на Java, узнаете синтаксис и основные библиотеки языка, начнете понимать объектно-ориентированный подход, сможете декомпозировать сложные задачи.

Курс ведут Рустам Кильдиев, Java/Scala-разработчик мобильного ПО, и Дмитрий Архангельский, инженер-разработчик в Одноклассниках.

Лекция 1. «Знакомство с платформой Java»

Вводное занятие, на котором кратко дается описание всего курса. Основная задача курса — не просто научить синтаксису, а дать практические навыки и понимание основ. Курс выстроен так, чтобы, выполняя небольшие задачи, написать проект «Бэкенд к мессенджеру».

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

Под катом смотрите расписание интервью с нашими коллегами. Встречи будут проходить в прямом эфире на YouTube, поэтому, если вы пока не решались расспросить наших коллег об играх, вы можете сделать это онлайн. Первая трансляция будет уже сегодня! Время начала — 19:00.

College by DamaiMikaz

Привет, Хабр! Меня зовут Ольга Шуберт, я занимаюсь UX-проектированием игровых проектов Mail.ru Group. В последнее время все чаще замечаю живой интерес к юзабилити игр со стороны и крупных разработчиков, и начинающих стартапов. Где найти специалистов? Как и где обучиться азам? Может ли вчерашний геймдизайнер стать UX-проектировщиком? Собрав в кучу самые распространенные вопросы начинающих юзабилистов, я сформировала короткий список советов, которые помогут преодолеть непростой карьерный путь.