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



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

КДПВ: текущее распределение проектов в геймдеве, одна Белоснежка и семь гномов.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

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

Не хотите читать? Посмотрите демо.

Символы нулевой ширины — это непечатаемые управляющие символы, которые не отображаются большинством приложений. Н​апример, в э​то пред​ложение я вст​авил де​сять про​​белов н​улевой ширины, вы эт​о замет​или? (Подсказка: вставьте предложение в Diff Checker, чтобы увидеть местоположение символов!). Эти символы можно использовать как уникальные «отпечатки» текста для идентификации пользователей.


Безусловно, он может здесь быть. И вы никогда не догадаетесь

Зачем?

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

Привет, Хабр. Рад представить свою первую статью: описание прототипа игрового мультиплеерного сервера.

→ Исходный код (под лицензией Apache 2.0)

Содержание:

• Архитектура обработки входящих запросов
• Краткое описание прочих моментов
  
  • Модули и взаимодействия основных классов
  • Разные виды тестов
  • Кэширование при работе с БД

Архитектура обработки входящих действий от пользователя

Входной точкой является websocket-контроллер, принимающий всевозможные реквесты от пользователей: начиная от логина и заявок на игру до игровых ходов и написания сообщений в чат. Этот контроллер обслуживает thread-pool (около 20 потоков).

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

Поэтому архитектуру я постарался спроектировать также и в соответствии с этим требованием (см. картинку):

Крис Ноддер, автор книги «Evil by Design», сразу вызывает доверие. Не столько своим послужным списком достижений в психологии UX дизайне и консалтинге, сколько явным умением цеплять и продавать. По сути, под стильной обложкой с демоненком — собрание техник манипулирования потребителем, многие из которых известны уже давно. Но, согласитесь, «руководство для дизайнера, который служит Злу, пробуждая в людях темные инстинкты» звучит гораздо увлекательнее. Давайте толкать потребителя на смертные грехи!



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

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

В Высшей школе бизнес-информатики НИУ ВШЭ мы запустили новую дистанционную образовательную программу повышения квалификации «Основы создания игр». Это короткий интенсивный курс на полтора месяца, целью которого является формирование у слушателей базового понимания игровой индустрии и процессов разработки и продвижения игр. Детали про программу под катом, а записаться на нее можно здесь>>.

Мне нравится делать игры, это мое хобби. В общей сложности около года в свободное время я делал игру на javascript для ВКонтакте. В настоящее время игра доделана, запущена, прошла модерацию ВКонтакте и доступна в каталоге игр. Это не статья вида “как я сделал игру”, а рассказ о тех проблемах, с которыми я столкнулся, пока ее создавал. Надеюсь, кому-то данная информация поможет избежать сложных ситуаций в своих проектах. Знай я о некоторых багах заранее, было бы гораздо проще, и, возможно, я бы принимал другие решения относительно кода. Добро пожаловать под кат за подробностями.

Помните, Льюис Кэрролл писал: «Здесь приходится бежать со всех ног, чтобы только остаться на том же месте, а чтобы попасть в другое место, нужно бежать вдвое быстрее»? Это фраза прекрасно подходит для IT-мира: технологии быстро развиваются, и каждый день нужно осваивать что-то новое, чтобы оставаться востребованным специалистом. У каждого программиста наверняка есть 5-6 бумажных книг, ставших классикой. О некоторых таких книгах мы уже писали. Но чтобы оставаться востребованным кодером, надо постоянно обновлять библиотеку. В прошлом году портал DevMountain сделал подборку из семи не слишком популярных книг для начинающих программистов. Учитывалась не только оценка портала, но и отзывы на Amazon, а также рекомендации популярных блогов. Автор GeekBrains Илья Бубнов внимательно изучил этот список, а также дополнил подборку парой свежайших экземпляров.

Есть такая вероятность, что в этом году вы наконец-то решили сделать собственную игру. Отличная цель! И она определённо того стоит!

Вы уже наверно много раз слышали один и тот же совет от сотен других людей: делайте игру простой. В своей замечательной статье Эдмунд Макмиллен писал «если вы новичок, то начинайте с малого, а потом сделайте игру ещё меньше». В столь же хорошем посте ему вторит Томми Рефенес: «Просто сделайте свою игру так, как можете, начинайте с малого, а об остальном думайте потом».

На канале Extra credits есть хорошее видео о том, что же значит «маленькая игра».

Но «простой» — это не стандартная единица изменения. Если вы никогда до этого не делали игр, то откуда вам знать, насколько проста или легка игра? Означает ли «простая» MMO ВСЕГО с тремя играбельными классами? Лёгкая игра — это открытый мир всего с двумя типами биомов и тремя деревьями технологий?

Я понимаю вашу растерянность.

В целом я выпустил пять игр и перед началом разработки трёх из них я думал, что они будут «простыми». Во всех трёх случаях я ошибался. На завершение первой готовой игры мне понадобилось больше полутора лет. Это было не «просто».

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

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

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

Чем больше узнаёшь в своей области знания, тем чётче понимаешь, что никто не может знать всего.

По какой-то причине (за что, господи, за что?) моей областью стала разработка игр. Каждый, кто работает в этой сфере, скажет вам: никогда не добавляй сетевой многопользовательский режим в уже готовую игру, никогда, пьяный ты клоун.

Как бы то ни было, я именно это и сделал, и ненавижу себя за это. На удивление, вышло замечательно. Никто из нас не знает всего.

Проблема №1: ресурсы

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

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

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

Статья для тех, кто хочет переехать работать в США. На Хабре есть несколько хороших статей про поиск работы в Америке. Тут я постараюсь добавить к ним собственный опыт и поделиться несколькими приемами, которые помогли мне получить долгожданный джоб оффер.

Сперва расскажу про рабочие визы, а потом как и где искать работодателя.

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



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

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

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

Пpивeтcтвyю вcex!

Ceгoдняшняя небольшая cтaтья, впpoчeм, кaк вceгдa, кoнeчнo жe, o зaмeчaтeльнoм и пpocтoм, кaк тpи кoпeйки, фpeймвopкe для кpoccплaтфopмeннoй paзpaбoтки Kivy.

B дaннoм мaтepиaлe бyдyт paзвeяны мифы o тoм, чтo Kivy нe гoдитcя для paзpaбoтки cлoжныx пpилoжeний, бyдyт oпpoвepгнyты пpeдвзятыe мнения, кoтopыe пpeдcтaвляют paзpaбoтчикaм и зaкaзчикaм Kivy, кaк мaлo пoдxoдящий и кpивoй инcтpyмeнт для cepьeзнoй paбoты и coвceм нeгoдным для production.

Ceгoдняшняя cтaтья бoльнo yдapит пo кocтылям других фреймворков, зacтaвит их пoшaтнyтьcя, ocoзнaть, чтo oни yжe oтнюдь нe eдинcтвeнные и пoдвинyтьcя нaзaд в peйтингe кpoccплaтфopмeннoй paзpaбoтки, cпpaвeдливo ycтyпaя мecтo Kivy, как более быстрому в плане разработки, не менее надежному и более выгодному инструменту!

Всем заинтересовавшимся, милости просим под кат...

Наталия Шергина, фрилансер-редактор и студентка Нетологии, специально для блога перевела лонгрид Richard Rutter о типографике веб-таблиц.



Хорошие дизайнеры не жалеют времени на типографику. Они тщательно подбирают шрифты, перебирают множество типографических шкал и скрупулезно применяют пробелы (white space) ради удобства пользователя. Затем появляется соблазн покреативить — и вот все мысли уже не о пользователе. Однако таблицы нужны в первую очередь, чтобы их читали и использовали, а не просто любовались.

Привет, Хабр! Представляю вашему вниманию перевод статьи «What habits made me a better Software Engineer?» от Sonny Recio.

Наши привычки — это ежедневные шаблоны поведения в жизни. Они могут быть как плохими, так и хорошими. Привычки могут быть жизненно необходимыми, например, потребность в еде 3 раза в день. Есть и такие привычки, которые помогают быть здоровым — занятие в тренажерном зале 3-4 раза в неделю. Но есть также привычки, которые портят тело, такие как курение и ежедневное распитие алкогольных напитков.

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

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

Если вас заинтересовали мои слова, вот некоторые из привычек, которые я сформировал, чтобы стать успешным. Вы их можете также использовать:

Глеб Летушов, редактор-фрилансер, адаптировал для блога Нетологии чеклист с Github от David Dias. Этот чеклист уже переводили, но так как на Хабре его нет, мы решили, что он пригодится. В чеклисте собран полный список элементов, которые необходимо проверить перед запуском и публикацией сайта.



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

В декабре прошлого года в Высшей школе бизнес-информатики НИУ ВШЭ проходил лекционный день по игровой индустрии. На мероприятии своим опытом с собравшимися гостями делились американский геймдизайнер компьютерных игр Richard «Levelord» Gray, директор продуктового департамента Rocket Jump Игорь Соловьев, игровой продюсер Сергей Гимельрейх, игровой маркетолог Сергей Зыков, основатели клуба игрофикаторов «Why42» Иван Нефедьев и Мирослава Бронникова. Под катом я собрал для вас видеозаписи и краткое описание всех докладов .

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

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

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

0. Об авторе

Всем привет, меня зовут Максим Логвинов и я студент Харьковского Национального университета радиоэлектроники.

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

А давайте посмотрим, что из себя представляет звук, как он кодируется и какие инструменты используются для этого самого кодирования. Более того, поэкспериментируем с битрейтами одного из самых продвинутых на сегодняшний день кодеков — Opus и оценим, что и с какими циферками можно закодировать, чтобы и рыбку съесть, и… Собственно, просто почему бы и нет? Почему бы не попытаться описать простым языком не только то, как хранится и кодируется аудио компьютером, но и протестировать один из лучших кодеков на сегодняшний день? Особенно, если речь идёт о сверхнизких битрейтах, где практически все существующие кодеки начинают творить невероятные вещи со звуком в попытках уложиться в малый размер файла. Если хочется отвлечься от рутины и узнать, какие выводы были получены при тестировании нового кодека — добро пожаловать под кат.