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



Мы много будем говорить о Steam, самой крупной открытой платформе для игр, потом посмотрим на 3rd-party дистрибуцию и альтернативные варианты продаж. До того, как вы найдете свои собственные ответы — давайте трезво посмотрим на то, как маховик издания игр работает сейчас.

Простите, ребята, но это будет очень меркантильная статья с цифрами и процентами — я считаю, что если создание игр ваша страсть и ремесло, без них сложно уверенно идти вперёд. Начнём с цен, скидок и того, как работает список желаемого в Steam.

Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение

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

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

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
2. Разработать некоторое исходное видение – концепцию проекта.
3. Провести анализ востребованности будущего продукта.
4. Провести предварительную оценку рисков будущего проекта.
5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
6. Выбрать методологию разработки и подготовить предварительный план работ.
7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
8. Провести анализ реализуемости продукта.
9. Провести независимое рецензирование технического решения.
10. Принять решение о том, стоит ли продолжать работы.

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

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

Последнее время ко мне часто обращаются начинающие тимлиды и руководители продуктов с вопросами: а что почитать на тему управления? что почитать на тему планирования? что почитать про управление рисками?

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

ДИСКЛЕЙМЕР

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

Здесь приводится опыт, который выдернул меня из состояния «читаю со словарем».



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

Возьмем такой предмет, как английский язык. Там куча понятий: 12 времен глагола, страдательный залог, причастия и т.п. Кто их ввел? Видимо, некие ученые мужи, для которых английский язык был РОДНЫМ. Они жили себе в каком-нибудь Oxford’e или в Cambridg’e и вряд ли знали русский язык.

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

Вспомните, как вы в школе изучали русский язык. Подлежащее, сказуемое, дополнение, определение… и штук 200 правил, из которых куча исключений, которые все благополучно забывают, кроме собственно учителей русского. И которые потом нужны – максимум – при разборках с бюрократическими документами («казнить нельзя помиловать»).

Английская грамматика – туда же – что-то академическое и малополезное при изучении языка с нуля. Для человека, который более-менее свободно умеет стыковать из английских слов фразу, нужно просто учить новые слова.

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

Статья ориентирована именно на таких.

Несколько лет назад мне казалось, что Олег Чумаков (тогда еще из Nival) был самым известным программистом геймдева. Постоянно выступал, проводил Gamesjam, был частым гостем подкаста Как делают игры.

С появлением на рынке VR, Олег возглавил в компании новое подразделение — NivalVR. Но вы все знаете, с виртуальной реальностью что-то пошло не так, как хотелось.

Я на долгое время отвлекся от геймдева, а взглянув снова, увидел — у команды Олега дела стали только интереснее. Теперь она называется Luden.io и их симулятор специалиста по машинному обучению while True: learn() стал хитом в своей нише, вокруг него творится куча крутых историй.

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

Почему именно больница?

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

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

Программный код внутри (но этого никто не видит)

При чем тут больница, если мы разрабатываем ПО?

А вот и нет, дорогие разработчики, руководители, аналитики, тестировщики.

Не программное обеспечение вы разрабатываете… Возьмем Android, — это ПО. А если, например, перед вами бухгалтерская система, то вы уже имеете дело не просто с ПО, а с ИНФОРМАЦИОННОЙ СИСТЕМОЙ.

Привет, уважаемые хабровчане!

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

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

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

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

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

В этой статье хочу рассказать о подходе к сборке Unity-проектов на android и ios через Gitlab на собственных сборщиках с macOS.

Я работаю в небольшой gamedev компании, и задача автоматизации сборки появилась из-за следующих проблем:

• 5 распределенных команд должны собирать проекты из любой точки мира
• должны поддерживаться разные версии юнити
• сборщик должен обеспечивать как минимум 5 сборок в неделю от каждой команды
• сертификаты должны храниться централизованно, а не у разработчиков
• собранные билды должны быть доступны по ссылке в любой точке мира
• проекты должны проверяться на наличие обязательных библиотек (рекламные sdk и коды, локализация, сохранения)
• конфигурирование сборки для команд должно производиться в одном месте

Недавно в разговоре с коллегами обсуждали различные игры жанра RTS, и я задумался, почему же релиз третьих «Казаков» прошёл мимо меня. Пару минут и один поисковый запрос спустя я вспомнил — помимо крайне сырого раннего релиза, реинкарнация этой классической стратегии отличилась невозможностью многопользовательской игры без постоянного соединения с официальным сервером. Многочисленные просьбы игроков «добавить LAN» на форумах разной степени свежести намекают, что изменений ждать не стоит.

Что ж, если гора не идёт к Магомету…

Привет, меня зовут Билл «LtRandolph» Кларк. Я работаю техническим руководителем команды создания чемпионов LoL. За последние несколько лет я успел поработать в разных отделах разработки League, но единственное, чем я был постоянно одержим — это технический долг. Мне нужно найти его, понять его и, при возможности, устранить его.

Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».

Метрики

Чтобы принимать правильные решения о том, какие проблемы необходимо устранить сейчас, а какие можно ставить на потом (или, будем реалистичными, совершенно забыть о них), нам нужен какой-то способ измерения каждого конкретного элемента технического кода. Я выбрал для оценки три основные оси измерения: влияние, затраты на устранение и инфицирование.

Для начала об авторе – я более 20 лет проработал в ИТ в трех компаниях: EMC, IBM, Sun (в алфавитном порядке). Начинал как системный инженер сразу после университета, потом был старшим инженером, техническим консультантом, руководителем технических консультантов и, наконец, техническим директором, руководившим командой пресейлов и архитекторов всего более 70-ти человек. Кроме того, год я был лидером продавцов через партнеров (Channel Sales Leader), распределенных по Центральной и Восточной Европе. Ниже я попытаюсь поделиться своим опытом именно, как руководителя и, дабы не возникало не правильных или не нужных ассоциаций, я буду приводить примеры из практики во время работы на компанию ABC (тоже три буквы). Возможно, изложение несколько однобоко, поскольку все мои работодатели – крупные международные компании, и я работал в их региональных офисах. Ну, тогда с этой спецификой я не могу ничего поделать и то, что читатель сочтет не приемлемым и не правильным пусть и останется таковым персонально для него.

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

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

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

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

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

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

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

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

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

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

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

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

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

Поехали?

Привет, харб! Примерно год назад я выкладывал статью о том, как я в прямом эфире создал выживалку за 150 часов. На этот раз хочу представить вам сетевой шутер, который я создал за 25 заходов по 3 — 4 часа. Всего вышло около 90 часов и в итоге мы создали онлайн шутер, в который сыграли вместе со зрителями.



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

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

Это вторая часть статьи о том, как правильно общаться и избежать ошибок в процессе код-ревью. Здесь мы поговорим о том, как довести ревью до конца и избежать неприятных конфликтов.

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

Моё худшее код-ревью

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

История первая

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


Игровая компания немца разрабатывала 3 вида игр:

1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

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

«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».

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

В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.