Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Сегодня JavaScript лежит в основе большинства современных веб-приложений. При этом за последние годы появилось большое количество JavaScript-библиотек и фреймворков для разработчиков Single Page Application (SPA), графики, анимации и даже серверных платформ. Для веб-разработки JavaScript используется повсеместно, и поэтому качество кода обретает всё большее значение.

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

Прошло уже больше года после публикации статей, посвященных нагрузочному тестированию Skyforge — новой MMORPG от студии Allods Team. С тех пор изменилось многое: дизайн Хабра, Ubuntu обновилась до 14.04.1 LTS, вышла Java 8, а главное — изменилась стадия развития проекта. Состоялось первое закрытое тестирование на внешних пользователях, а скоро будет и стресс-тест – приглашение максимально возможного числа «живых пользователей» на сервера в рамках ЗБТ или ОБТ. Но не буду отнимать работу у нашей команды маркетинга, расскажу лучше о том, что у нас нового в нагрузочном тестировании, что мы переосмыслили, и что из этого может быть полезно широкой общественности.

Художник по эффектам — это алхимик. Его задача: за неимением золота это золото добыть. В любом случае это будет фейк, но от опыта художника зависит, насколько он будет правдоподобным. Художник по эффектам — универсал. Если задача не укладывается в стандартный пайплайн художников, значит эта задача для художника по спецэффектам. Нужно уметь как можно больше и не бояться нестандартных решений, но только если они дадут выгоду. В этой статье я постараюсь подробно рассказать, чем руководствуются художники по эффектам на нашем проекте. Расскажу о некоторых хитростях. Затрону сторону оптимизации арта и расскажу о взаимоотношениях в команде.

Всем привет! Меня зовут Дмитрий Бородин, я работаю гейм-дизайнером в команде боя на проекте Skyforge. В Allods Team я уже более четырех лет, и это время не прошло даром — я узнал много нового и интересного из самых разных областей геймдева. В основном же моя работа была связана с реализацией боя в игре, и сейчас я расскажу о том, как мы делали его в Skyforge.



Бой, или комбат, как мы его чаще всего называем, в целом можно описать как активное взаимодействие игрока с враждебным ему окружением. В современных MMO комбат занимает до 90% игрового времени, и задача сделать его увлекательным и не надоедающим — одна из самых главных и одновременно одна из самых сложных. Поэтому для Skyforge была сформирована специальная большая команда, которая занимается исключительно этой проблемой.

Основной вклад в комбат ММО вносят 3 составляющие:

1. Классы — связанные наборы умений, которые игрок будет использовать в бою.
2. Мобы — враждебные игроку монстры.
3. Интерфейс и камера.

Про каждый из этих пунктов надо рассказывать основательно в отдельных статьях, и я расскажу про первый — про классы.

Всем привет! Меня зовут Сергей Макеев, и я технический директор в проекте Skyforge в команде Allods Team, игровой студии Mail.Ru Group. Мне хотелось бы рассказать про технологии рендеринга, которые мы используем для создания графики в Skyforge. Расскажу немного о задачах, которые стояли перед нами при разработке Skyforge с точки зрения программиста. У нас свой собственный движок. Разрабатывать свою технологию дорого и сложно, но дело в том, что на момент запуска игры (три года назад) не было технологии, которая могла бы удовлетворить всем нашим запросам. И нам пришлось самим создать движок с нуля.

Сегодня я хочу рассказать о первой части закрытого бета-тестирования (ЗБТ) Skyforge. Это уже не первое ЗБТ, но зато оно стало самым массовым. Большинство игроков составляют не сотрудники компании и их друзья, а поклонники игры, выбранные случайно из числа зарегистрировавшихся для участия в тесте, а так же купившие или выигравшие наборы раннего доступа. С вечера пятницы, 6 февраля, и до конца выходных будет организован специальный бета-уикенд, во время которого доступ на ЗБТ будет открыт всем пользователям, имеющим аккаунт в почте Mail.Ru. Этот пост носит повествовательный характер и передаёт мою личную точку зрения на происходившие до и во время ЗБТ события.

Как многие из вас знают, 26-го марта Allods Team (студия Mail.Ru Group) запустила открытый бета-тест (ОБТ) нового MMORPG-проекта Skyforge. Меня зовут Сергей Загурский, я работаю в команде сервера и хочу рассказать о том, как проходил запуск, с какими инцидентами мы столкнулись и как вышли из ситуации победителями.

8 лет назад маленькая команда разработчиков, почти что бывшие студенты, решили сделать свою первую большую, как им тогда казалось, игру. Они выполняли все функции вперемешку. И гейм-дизайн, и программирование, и арт. Кто что умел. Получившаяся игра называлась «Возмездие». Это была браузерка. Она показала неплохие результаты: доходы с игры выросли от нескольких десятков до сотен тысяч рублей за первые месяцы. Для группы в несколько человек это уже какие-то деньги. В таком режиме игра просуществовала порядка года. А потом аудитория стала уменьшаться, доход начал падать. Разработчики подумали: «Наверное, мало контента». Игра была контентнозависимой, т.е. постоянно жила на обновлениях. Они поднажали, стали производить больше локаций, предметов, уровней, ремесленнических рецептов — всё, что делали раньше. Но пользователи все равно продолжали уходить. И было непонятно, почему это происходит. В итоге проект, просуществовав три года, закрылся — рано или поздно такой конец ждет все онлайн-игры.


^{Арт персонажа браузерной игры Возмездие}

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

1. Интро. Личное

Я готовлюсь к языковому экзамену IELTS (International English Language Testing System) — пожалуй, самому популярному
тесту на знание английского. Если хочется эмигрировать, найти работу в международной компании — диплом IELTS очень пригодится. Шкала оценок — от 0 (от испытуемого не удалось получить даже внятного мычания) до 9 (экcперт — испытуемый чертовски хорош и может устроиться даже редактором лондонской газеты).

Для учебы, например, в США, нужно не менее 6.5 баллов (бывает и 6, но не часто), для работы — 7 и выше. А для эмиграции, допустим, в Канаду — чем выше оценка, тем лучше. Мой прогнозируемый балл перед сдачей теста — 5.5. Значит, что я могу читать газеты, смотреть кино, вести беседы в знакомых ситуациях, писать ответы на письма. Но для работы в центральном офисе Гугла явно недостаточно.

Что же делать, чтобы подтянуть уровень языка? Конечно же, начать использовать его в своей жизни как можно чаще и больше. Например, читать книги на английском.

Часть 1.

Краткий анализ существующих подходов к сильному ИИ.

Когнитивные архитектуры.

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

Добрый день, уважаемые хабраюзеры.

Данный пост ставит собой целью попытаться донести до менеджера проекта/руководства необходимость приобретения SSD для разработчиков.

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

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

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса != смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

Рассмотрим популярные способы распределения сотрудником собственного рабочего времени (в порядке возрастания «уровня профессиональной ответственности»):

1. Нужно заниматься «видимым» достижением конкретных целей. Если задачу нужно сделать за неделю, а я могу за день — я потяну время, ведь я получаю зарплату и так.
2. Мне не интересно развивать чужой бизнес.
3. Да, видно, что для достижения целей необходимо еще пол помыть и выполнить кучу рутины — но я сдвинусь, только если за это дадут премию.
4. Для достижения цели нужно выстроить бизнес-процесс, понятно как, я могу описать необходимые шаги и варианты — чтобы сотрудник моей квалификации смог в принципе достичь цели аналогично. Но тогда я буду не нужен и этим воспользуются коллеги-конкуренты :-)
5. Понятно, как выстроить/оптимизировать бизнес-процесс. Также можно описать шаги и научить их выполнять менее квалифицированным сотрудникам. Но тогда я буду не нужен и, что еще страшнее — поставленной мне задачей могут заняться слабо квалифицированные, но более амбициозные/рвущиеся по карьерной лестнице (за славой и деньгами, например Вася Пупкин).

Так стоит ли стараться делать больше, чем нужно, внедрять и улучать бизнес-процессы?

Интро

Это краткий перевод основных тезисов из брошюры «Web API Design. Crafting Interfaces that Developers Love» Брайана Маллоя из компании Apigee Labs. Apigee занимается разработкой различных API-сервисов и консталтингом. Кстати, среди клиентов этой компании засветились такие гиганты, как Best Buy, Cisco, Dell и Ebay.

В тексте попадаются комментарии переводчика, они выделены курсивом.

Собираем API-интерфейсы, которые понравятся другим разработчикам

Понятные URL для вызовов API

Первый принцип хорошего REST-дизайна — делать вещи понятно и просто. Начинать стоит с основных URL адресов для ваших вызовов API.

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

/dogs для работы со списком собак
/dogs/12345 для работы с отдельной собакой

Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

Эрик Липперт — ветеран Microsoft, проработавший в компании 16 лет и стоящий за разработкой VBScript, JScript и C#.

На прошлой неделе в комментариях к одной из статей разгорелся спор о роли низкоуровневой оптимизации в программировании, и я вспомнил относящуюся к этому статью Эрика. Она была написана в конце 2003, и хотя реалии с тех пор несколько изменились — принципы остались теми же самыми. Можете мысленно заменить ASP и VBScript на PHP, JavaScript, или на другой скриптовый язык по вашему вкусу.

Эту статью я уже пытался перевести в 2005, но русский текст тогда получился неуклюжий, так что этот перевод — новый и ранее не публиковался, в соответствии с требованиями НЛО. В Переводе блога Эрика Липперта этого текста тоже нет — наверное, для них он слишком стар.

---

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

Например, за семь лет в Microsoft я получил десятки вопросов, аналогичных по своей сути этому, заданному в конце 1990-х:

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

Какой интересный вопрос! В компилируемом языке, таком как Си, объявление локальных переменных общим размером n байт всего лишь вычитает n из указателя стека при входе в функцию. Если n будет чуть больше или чуть меньше, затраты времени на вычитание никак не изменятся. Наверное, в VBScript точно так же? Оказалось, что нет! Вот что я написал автору вопроса: