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

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

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

Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.

Ребята из Yii Software готовят бомбу. Пока я лишь наблюдаю за новой версией фреймворка из-за угла, но уже вижу улучшения во всём — от использования новых возможностей языка до удобного создания собственных структур для крупных проектов.

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



Yiinitializr — библиотека, помогающая упростить и ускорить цикл разработки приложения на основе фреймворка Yii. Из коробки доступны 3 варианта структурных шаблонов:

• Basic — создан для проектов небольших масштабов;
• Intermediate — подойдёт для большинства проектов средней сложности;
• Advanced — будет хорошим выбором для более сложных проектов с необходимостью предоставления собственного API.

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

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

В статье я расскажу реальные истории изменений интернет магазинов и о том, какой эффект они дали. Все истории 2012-2013 годов.

На протяжении многих лет я специализируюсь на анализе текущего положения дел интернет магазина и последующем увеличении его конверсии. За это время у меня набрались некоторые хинты, внедрение которых всегда позволяло на значительную величину увеличить продажи. (Значительное – это конечно, не 500%, а 1%-5%). Другими словами — отсутствие этих вещей, снижает эффективность магазина. Накопилось их значительно больше 6, но я постарался написать о тех, внедрение которых не требует много времени или ресурсов.

Знакомимся с RabbitMQ

Переводы на хабре:
RabbitMQ tutorial 1 — Hello World
RabbitMQ tutorial 2 — Очередь задач
RabbitMQ tutorial 3 — Публикация/Подписка

Сразу дополню некоторые недочеты. И кратко повторю основные термины.

Принцип работы архитектуры использующей rabbitMq

При разработке нам понадобился простой конечный автомат, желательно уже реализованный. Из списка реализаций, который предложил гугл, выбрали этот, за простоту и компактность. Используем у себя, в целом FSM неплох. Далее под катом перевод оригинальной статьи автора из Греции Tasos Giannakopoulos. Я не переводчик, поэтому я старался передать смысл, иногда объясняя суть своими словами, за что извиняюсь перед перфекционистами.

В этом посте вы найдете пошаговые инструкции, как создать прототип мобильной 3D-игры за невероятно короткое время с помощью игрового движка Project Anarchy. Для работы нам понадобятся:

• ПК с установленным Project Anarchy SDK, Android SDK и драйверами для подключения по adb;
• Подключенное по USB Android устройство;
• Установленное приложение vSceneViewer.apk;
• Набор объектов LiveCodeparisDemo.zip;
• Работающее Wi-Fi соединение у ПК и устройства Android.

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.

Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов

Что нужно знать?

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

Почему писать диалоги игры в .cpp файле было большой ошибкой

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

Но есть способ, на голову выше — использование скриптов.

Я хотел бы поделиться нашим опытом использования Go в течение двух лет в продакшне Iron.io. Мы одна из первых компаний, ставших использовать Go (golang) в высоконагруженных сервисах. Когда в Iron.io было принято решение об использовании этого языка, мы не знали, чего ожидать в долгосрочной перспективе, но до сих пор все идет отлично.

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

Здравствуйте, я Антон Кругляков, руководитель команды User Interface проекта Skyforge. В этой статье я расскажу о нашем опыте проектирования дизайна интерфейса. Я старался максимально уменьшить теоретическую часть, но, глядя на финальный результат, понимаю, что не особо преуспел в этом.

Уникальные отличия

Несколько месяцев назад мы с коллегами решили сделать многопользовательскую realtime игру, которая могла бы работать в вебе. Мы решили использовать node.js для нашего сервера. Это решение привело к очень убедительному успеху — наш сервер работал несколько месяцев без единого падения или перезагрузки процесса.

Мы решили написать нашу игру на node.js, потому что мы слышали много хорошего об этой платформе и очень хотели немного с ней поиграть. И это было потрясающе — мы очень быстро вошли в тему. Для node.js существует множество любопытных библиотек, способных решать абсолютно разные задачи. Побочным преимуществом использования node для серверной части является, собственно, javascript — очень простой в обращении язык. Это позволило нам сфокусироваться на проблемах, которые встречаются во всех realtime играх, без лишней суеты, ограничений и необходимости компилировать код, как это случается при использовании менее динамических языков.

Также node.js проявил себя как очень легковесный язык, даже в моменты пиковой нагрузки. Для нашей игры, процесс node.js использовал только один поток и потреблял всего около 3-4% CPU при одновременной работе 8-10 копий игры, каждая со своим собственным движком обнаружения столкновений.

Отгадайте загадку: в четырёх измерениях сидит и комплексными числами воротит?

Подсказка: это вектор со скаляром. И вещественная матрица. И придумал его Гамильтон.

Не помогло? Ну что вы, это же элементарно! Это кватернион! Кватернионы используют для записи вращений в робототехнике, игровых движках, ПО для моделирования и вообще везде, где не нужны проблемы с углами Эйлера или матрицами. Если вас испугала путаница выше с разными представлениями кватерниона, то можете быть спокойны. Кватернионы очень просты в использовании и их внутреннее строение может понадобиться только в очень редких случаях, где нужна тонкая оптимизация. В остальное время с помощью кватернионов можно крутить всё что угодно и как угодно, и оно будет плавно и красиво интерполироваться без шарнирных замков.

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

Разработал и запустил на домене quickpong.com онлайн версию игры Pong. В игре (by design) реализован только режим мультиплейера, то есть игра идет не против искусственного интеллекта, а против другого человека.

Игра представляет из себя клиент-серверное приложение, серверная часть написана на питоновском фреймворке Twisted, клиентская — на флэшовом фреймворке FlashPunk.

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

Собственно, изучая данную тему, было перерыто много сайтов, но нигде толком ничего не объяснялось, либо информация была по устаревшим ныне протоколам. Это и послужило своеобразным пинком для создания этого HowTo. Это будет не детальный разбор всех возможных проблем, но немного теории и описание некоторых вещей которые для кого-то являются банальщиной, а у кого-то (вроде меня) вызвали трудности и потерю времени на поиск решения. Сразу предупрежу — здесь не рассматривается как поднять сокет-сервер на PHP, подобной информации в интернете навалом. Буду исходить из того, что сокет-сервер уже существует и надо лишь научить его общаться через вебсокеты.
Итак, хватит лирики, теперь к делу!

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



Есть только два фактора, которые определяют любое текущее состояние игры: механика (правила) и игроки своими действиями.

Уровень ядра

Такт 1: определение состояния
Всегда есть некое текущее состояние системы (например, начало хода). Оно определяется на первом такте инициализирующей последовательностью, когда игроки «загружают» игру, раскладывая поле, выбирая фишки, распределяя начальные ресурсы и так далее. Затем оно меняется в зависимости от происходящего в игре.

Это топик-перевод статьи Eller's Algorithm. В ней рассказывается о способе программной генерации лабиринтов. Дальнейшее повествование идет от лица автора.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  
|__   |__       __ __|__   |   __|  |  |  |  |
|__   |__   |__|   __ __|   __ __      |     |
|        |  |  |     |  |__      |__|  |  |  |
|__|__|  |  |   __|   __|__   |   __|__|  |__|
|   __|  |     |__ __ __|  |  |__|  |     |  |
|  |  |  |  |__|  |__   |  |   __|__ __|  |  |
|  |__    __    __ __    __|  |   __   |  |  |
|  |  |  |  |      __|  |   __|  |  |__|  |  |
|  |     |     |__   |  |  |  |  |  |__    __|
|  |  |__|__|__ __|  |     |  |  |      __|  |
|__ __|  |  |  |__   |__|   __|     |   __ __|
|   __|  |   __|__      |__   |__|  |__    __|
|  |  |     |  |     |__|  |   __    __|   __|
|   __|  |__ __|__|      __|  |  |     |  |  |
|   __ __   |      __|__|  |__   |  |  |__|  |
|__ __ __|__ __|__ __ __ __ __|__|__|__ __ __|

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

Статистика для инди разработчика

Автор Emeric Thoa

Перевод мой

Intro

Когда я распрощался с работой на крупную игровую компанию и основал свою игровую студию, было интересно прикинуть, сколько денег можно было ожидать заработать как инди разработчик. Проработав в Ubisoft в разработке консольных AAA игр, у меня были некоторые соображения. Но они для моей новой инди жизни уже были неактуальны. 20-ти миллионные бюджеты в долларах, команды из 20 тысяч человек, продажи по 70 долларов за копию… Я понимал, что для инди все намного по-другому, но информации о том, насколько по-другому было очень недостаточно.

Angry Birds взлетела на Олимп, Plants vs. Zombies уже была показательным образцом успеха, Doodle Jump был хорошим примером успеха в то время, когда я стартовал, Cut the Rope продавалась по миллиону копий в неделю. Но, кроме случаев, которые я называю джекпотами, в сети было очень мало публичных данных со статистикой. Это значило, что финансовые ожидания от первого проекта SQUIDS были покрыты мраком необоснованных предположений. С тех пор, я собираю статистику и в этой статье хочу поделиться информацией с собратьями по оружию – инди разработчиками, которые находятся на той стадии, на которой я сам был полтора года назад.

Мифы App Store

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

На этой неделе Facebook представил свой Home, iTunes как-то странно провалился в поисковой выдаче Google, Corona SDK стала бесплатной, а также появилось еще два движка для кросс-платформенной разработки. Есть также две занятные истории от российских разработчиков и русская версия Developer Economics 2013.