Вступление
Данная тема - субъективное мнение автора, основанное на личном опыте и обсуждениях с людьми, которых я считаю компетентными в сфере. Я не претендую на абсолютную истину, тема открыта к обсуждению, но без оффтопа.
Моё BIO (важно прочитать)
Даю своё краткое BIO, чтобы было понятно, откуда у меня берутся дальнейшие тезисы и почему я вообще считаю возможным рассуждать о проблемах этой сферы.
До Rage Multiplayer я занимался разработкой desktop-приложений на C++, позже писал pet-проекты на C#, NodeJS. В начале 2021 года пришёл в Rage-сферу, где начал уже целенаправленно и агрессивно развивать свои hard-скиллы. Первые проекты писал на C#, затем полностью пересел на NodeJS / JS / TS, на этом стеке и работаю до сих пор.
Начало 2021 - середина 2022
Работал в проектах средней руки. Думаю, многие из вас прекрасно понимают, о каких проектах идёт речь: низкий бюджет, высокие требования, полное отсутствие менеджмента - либо, что ещё хуже, менеджмент со стороны овнера.
За этот период я:
Очевидно, никакого релизного опыта я тогда не получил. Зато получил опыт тимлида и менеджера: постановка задач, распределение обязанностей, найм людей. Делать это приходилось не потому что хотелось, а потому что больше этим заниматься было некому. Этот этап дал мне чёткое понимание, почему большинство таких проектов либо не живут, либо живут в перманентной агонии.
Середина 2022 - середина 2023
В какой-то момент стало ясно, что дальше расти в таком формате невозможно. Мне нужен был более серьёзный опыт - живой проект, реальный онлайн, реальные проблемы.
Поэтому я просто написал всем топовым проектам, до которых смог дотянуться: Majestic, FiveLive, Atom Community и ещё нескольким.
Сначала меня пригласили на собеседование в FiveLive, получил тестовое задание, с которым справился, но по итогу мы не сошлись по условиям.
После этого я прошёл собеседование и написал тестовое в Atom Community, куда меня и взяли работать. Это был очень сильный и важный этап:
Отдельно отмечу наставника - MiLT
Это был действительно крутой опыт менторства. При этом у меня была свобода в проектировании систем, но в рамках адекватного менеджмента, что встречается в этой сфере крайне редко.
Единственный минус - необходимость трекать рабочие часы, которые я, честно говоря, ебал в рот.
Середина 2023
К сожалению, Atom Community потерпел ряд серьёзных поражений. Найм Subo, запуск немецкого сервера и прочие внутренние проблемы привели к закрытию проекта, который в своё время был очень успешным, в том числе коммерчески.
Встал вопрос о новом месте работы, но в этот раз я был уже не один. Почти вся команда Atom Community также искала, куда двигаться дальше: гейм-дизайнер, дизайнер, фронтенд-разработчик и, собственно, я.
Мы приняли решение искать инвестиции под команду, а не идти по одиночке. Идея была простой: найти инвестора под собственную задумку, не претендуя на процент от прибыли. В таком случае все остаются в плюсе: команда получает работу, инвестор - полностью сформированную команду с релизным опытом и пониманием, как делать конкурентоспособный продукт.
Los Santos Journey
Мы нашли англоговорящего инвестора - "Jhony from Canada". Поработали около полутора месяцев, после чего он просто кинул всю команду, не выплатив ни цента.
Без угрызений совести мы выложили ресурс с исходниками на этот форум, а самого Jhony закинули в чёрный список Rage MP.
Skyrim Role Play (ныне Skyrim Online)
После LSJ той же командой Atom Community мы решили попробовать силы в ещё не занятой нише. Нашли исходники мультиплеер-платформы, наняли C++-разработчика под неё, нашли инвестиции и начали разработку.
На старте всё шло очень хорошо. Но позже произошёл внутренний конфликт, и один "нехороший человек" просто подъебал нас с гейм-дизайнером и кикнул из проекта.
Проект в итоге релизнулся и, насколько мне известно, сейчас имеет неплохой онлайн и коммерческий успех.
Последний опыт
После истории со Skyrim RP мы с тем же гейм-дизайнером нашли на этом же форуме людей, которые хотели с нуля сделать полностью конкурентоспособный проект - и технически, и по онлайну.
Над этим проектом мы работали последние два года. Это был самый яркий и тяжёлый опыт за всё время:
К команде подключились UI/UX-дизайнер, level-дизайнер (он же маппер), фронтенд-разработчики, позже мы расширялись и добирали ещё backend и frontend специалистов.
Впервые для себя я стал ментором для backend-разработчика. Считаю это важным моментом - сейчас это очень крепкий middle, и, думаю, он это менторство оценил.
На данный момент проект заморожен и находится в поиске дополнительных инвестиций для маркетинга и выхода в релиз. Если кому-то интересно - пишите в личку, мы открыты к предложениям, есть подробный бизнес-план.
Из этого опыта у меня сформировалось несколько базовых принципов, через которые я смотрю на сферу:
До Rage Multiplayer я занимался разработкой desktop-приложений на C++, позже писал pet-проекты на C#, NodeJS. В начале 2021 года пришёл в Rage-сферу, где начал уже целенаправленно и агрессивно развивать свои hard-скиллы. Первые проекты писал на C#, затем полностью пересел на NodeJS / JS / TS, на этом стеке и работаю до сих пор.
Начало 2021 - середина 2022
Работал в проектах средней руки. Думаю, многие из вас прекрасно понимают, о каких проектах идёт речь: низкий бюджет, высокие требования, полное отсутствие менеджмента - либо, что ещё хуже, менеджмент со стороны овнера.
За этот период я:
- заработал первые деньги в сфере
- прощупал почву
- начал активно набивать руку и развивать hard-скиллы
Очевидно, никакого релизного опыта я тогда не получил. Зато получил опыт тимлида и менеджера: постановка задач, распределение обязанностей, найм людей. Делать это приходилось не потому что хотелось, а потому что больше этим заниматься было некому. Этот этап дал мне чёткое понимание, почему большинство таких проектов либо не живут, либо живут в перманентной агонии.
Середина 2022 - середина 2023
В какой-то момент стало ясно, что дальше расти в таком формате невозможно. Мне нужен был более серьёзный опыт - живой проект, реальный онлайн, реальные проблемы.
Поэтому я просто написал всем топовым проектам, до которых смог дотянуться: Majestic, FiveLive, Atom Community и ещё нескольким.
Сначала меня пригласили на собеседование в FiveLive, получил тестовое задание, с которым справился, но по итогу мы не сошлись по условиям.
После этого я прошёл собеседование и написал тестовое в Atom Community, куда меня и взяли работать. Это был очень сильный и важный этап:
- реальный релизный проект
- реальный онлайн
- реальная нагрузка
- необходимость думать о производительности и архитектуре, а не просто "чтобы работало"
Отдельно отмечу наставника - MiLT
Это был действительно крутой опыт менторства. При этом у меня была свобода в проектировании систем, но в рамках адекватного менеджмента, что встречается в этой сфере крайне редко.
Единственный минус - необходимость трекать рабочие часы, которые я, честно говоря, ебал в рот.
Середина 2023
К сожалению, Atom Community потерпел ряд серьёзных поражений. Найм Subo, запуск немецкого сервера и прочие внутренние проблемы привели к закрытию проекта, который в своё время был очень успешным, в том числе коммерчески.
Встал вопрос о новом месте работы, но в этот раз я был уже не один. Почти вся команда Atom Community также искала, куда двигаться дальше: гейм-дизайнер, дизайнер, фронтенд-разработчик и, собственно, я.
Мы приняли решение искать инвестиции под команду, а не идти по одиночке. Идея была простой: найти инвестора под собственную задумку, не претендуя на процент от прибыли. В таком случае все остаются в плюсе: команда получает работу, инвестор - полностью сформированную команду с релизным опытом и пониманием, как делать конкурентоспособный продукт.
Los Santos Journey
Мы нашли англоговорящего инвестора - "Jhony from Canada". Поработали около полутора месяцев, после чего он просто кинул всю команду, не выплатив ни цента.
Без угрызений совести мы выложили ресурс с исходниками на этот форум, а самого Jhony закинули в чёрный список Rage MP.
Skyrim Role Play (ныне Skyrim Online)
После LSJ той же командой Atom Community мы решили попробовать силы в ещё не занятой нише. Нашли исходники мультиплеер-платформы, наняли C++-разработчика под неё, нашли инвестиции и начали разработку.
На старте всё шло очень хорошо. Но позже произошёл внутренний конфликт, и один "нехороший человек" просто подъебал нас с гейм-дизайнером и кикнул из проекта.
Проект в итоге релизнулся и, насколько мне известно, сейчас имеет неплохой онлайн и коммерческий успех.
Последний опыт
После истории со Skyrim RP мы с тем же гейм-дизайнером нашли на этом же форуме людей, которые хотели с нуля сделать полностью конкурентоспособный проект - и технически, и по онлайну.
Над этим проектом мы работали последние два года. Это был самый яркий и тяжёлый опыт за всё время:
- проектирование high-load продукта с нуля
- формирование команды
- проведение технических собеседований
- code review
- определение архитектурного вектора
- постановка технических задач
К команде подключились UI/UX-дизайнер, level-дизайнер (он же маппер), фронтенд-разработчики, позже мы расширялись и добирали ещё backend и frontend специалистов.
Впервые для себя я стал ментором для backend-разработчика. Считаю это важным моментом - сейчас это очень крепкий middle, и, думаю, он это менторство оценил.
На данный момент проект заморожен и находится в поиске дополнительных инвестиций для маркетинга и выхода в релиз. Если кому-то интересно - пишите в личку, мы открыты к предложениям, есть подробный бизнес-план.
Из этого опыта у меня сформировалось несколько базовых принципов, через которые я смотрю на сферу:
- ответственность за результат, а не за "отработанное время'
- честность перед заказчиком даже тогда, когда это невыгодно
- понимание, что Rage-проект - это полноценный IT продукт, а не "хуйня где можно подзаработать"
Всё, о чём будет дальше - написано именно из этой позиции.
Другие участники
Vermilion - разработчик с большим опытом в моддинге и в нашей сфере: прошёл путь от “переписывания готовых решений” до построения архитектуры и разработки собственного независимого мультиплеера.
MiLT - Мой ментор со времён Atom Community, опытный разработчик который здесь ещё со времён динозавров, участвовал в разработке RedAge, GTA GO, Atom Community.
NKondr - Думаю в представлении особо не нуждается, фронтенд разработчик с многолетним опытом в этой сфере и хорошей репутацией на форуме и среди комьюнити. Работа с такими проектами как: RedAge, DedNet, Babylon, Diamond.
JustKuali - Мой хороший друг, геймдизайнер с многолетним опытом в этой сфере и вне её, в прошлом комьюнити менеджер Atom Community, сейчас соучередитель и гейм-дизайн лид Skyrim Online.
Тема 1. Низкая квалификация
Прежде чем говорить о низкой квалификации, важно зафиксировать простую вещь: все выводы ниже сделаны не из воздуха. За несколько лет работы в этой сфере я провёл десятки собеседований на самые разные роли. Это легко проверить, просто открыв мой форумный профиль - там годами регулярно появлялись темы о поиске кандидатов в команды. Я искал людей не месяц и не два, а годами и не в один проект.
Поэтому когда я говорю, что в сфере есть системная проблема с квалификацией, я говорю это не как наблюдатель со стороны, а как человек, который постоянно сталкивался с наймом, отбором и последствиями этих решений.
Картина почти всегда одна и та же. Из десяти человек, которые откликаются на вакансию, до реального разговора доходят в лучшем случае двое. Остальные отсеиваются ещё на этапе первичного общения. Кто-то объективно не дотягивает по опыту, кто-то вообще не знаком со стеком, указанным в вакансии, а кто-то, что особенно показательно, банально не удосужился его прочитать.
На собеседовании всё становится ещё нагляднее. Я давно перестал удивляться тому, что люди приукрашивают резюме - в этой сфере это абсолютная норма. Проблема в другом. Очень часто за красивыми формулировками не стоит даже базовое понимание вещей. Человек может заявлять уверенный middle грейд, но при этом не быть в состоянии объяснить элементарные вещи. Например, чем map отличается от forEach, или ещё чаще, не могут объяснить свой же код. Это не какой-то глубокий теоретический вопрос, это базис, без которого невозможно писать осмысленный код.
В такие моменты становится очевидно, что человек просто воспроизводит знакомые конструкции, не понимая, что он делает и зачем. До тестовых заданий доходили единицы. А тестовые почти всегда окончательно расставляли всё по местам. В большинстве случаев там не было никакого системного мышления. Решения выглядели так, будто задача решалась один раз и навсегда, без мысли о том, что код придётся развивать, поддерживать и масштабировать. Работает сейчас - значит достаточно
В этом месте обычно звучит любимая фраза многих форумчан:
И здесь важно остановиться. Я никогда не говорил про идеальный код и не считаю его целью. Речь вообще не об этом. Для меня всегда было важно другое - чтобы код был устойчив к нагрузке и чтобы его можно было расширять без переписывания половины проекта.
Когда я говорю про расширяемость, это не абстрактные рассуждения. Простой и показательный пример из моей практики - система инвентаря. Очень часто инвентарь реализуют как жёстко прибитую структуру под текущие предметы и текущие сценарии использования. Пока предметов мало и логика простая, это работает. Как только появляются разные типы переносов, ограничения, временные предметы, бизнес-логика или интеграции с другими системами, такая реализация начинает трещать по швам.
В случае о котором я говорю ( код писал один не мало известный разработчик MiLT ), инвентарь изначально проектировался через абстрактный слой. Базовое ядро отвечало только за хранение и состояние, а вся логика взаимодействия выносилась наружу. Переносы предметов между контейнерами реализовывались через стратегии - в зависимости от типа переноса применялась конкретная стратегия со своими правилами, валидацией и побочными эффектами. Это позволяло добавлять новые сценарии перемещения без переписывания существующего кода и без превращения одной функции в монолитный if-else. Нужно добавить особые правила использования, ограничения, реакции на события или интеграцию с другой системой - добавляется новое расширение, а не переписывается ядро инвентаря. В результате система спокойно переживала рост требований и усложнение логики.
Это не "идеальный код". Это код, который изначально писался с мыслью о том, что проект будет жить, меняться и усложняться. И именно этого уровня архитектурного мышления в сфере чаще всего не хватает. Я не призываю к перфекционизму. Я говорю о жизнеспособности. О том минимальном уровне ответственности, без которого любой технический продукт начинает рассыпаться.
Отдельно стоит сказать про желание развиваться. С этим всё плохо, и во многом это проблема самих разработчиков. Да, внешней мотивации здесь действительно мало. Большинство не работает с реальным онлайном и не сталкивается с настоящей нагрузкой. Но это не снимает ответственности с человека. Если ты годами варишься в одном и том же уровне, не читаешь, не смотришь, как решают задачи за пределами Rage, не пытаешься расти - это твой осознанный выбор.
Ситуацию усугубляет почти полное отсутствие нормальных материалов для новичков. Я сам пытался писать статьи и гайды, и они получали неплохой отклик. Но этого очевидно недостаточно. При этом внутри комьюнити сформировалась токсичная и парадоксальная позиция. Более опытные разработчики часто считают, что учить тут просто некого, что "все дауны", "все пишут хуйню" и "тут некому что-то объяснять". Люди, которые объективно могли бы поднять общий уровень сферы, заранее относятся к любому новичку с предвзятостью, автоматически записывая его в мусор. В итоге никто никого не учит, знания не передаются, и среда сама консервирует свою деградацию.
Менторство не ценится ни внутри проектов, ни внутри комьюнити. Передача знаний не считается чем-то важным или уважаемым. Считается нормой просто отстраниться и сказать "разберутся сами", а потом удивляться, почему через несколько лет в сфере всё те же проблемы.
Если говорить о возможных решениях, то они на поверхности, хотя реализовать их сложно. Сфере нужна более здоровая конкуренция и приток новых разработчиков, но здесь мы упираемся в серую зону и отсутствие правовой стороны, из-за чего для внешних специалистов эта среда выглядит сомнительно.
Сфере нужны менторы на практике, а не на словах. Опытных разработчиков нужно мотивировать брать новичков, закреплять за ними ответственность, ценить это внутри проектов и комьюнити. Сейчас же реальность проще - никто никого не учит вообще.
И, наконец, контроль качества. Его в проектах практически нет. Причина проста - слабый менеджмент и почти полное отсутствие технического бэкграунда у тех, кто управляет разработкой. В проектах просто нет людей, которые системно отвечают за качество.
Отсюда мы закономерно приходим к следующей проблеме - низкой квалификации менеджмента и безответственности овнеров. Очень часто овнер, заходя в сферу, передаёт управление продуктом близкому человеку. У этого человека нет технического понимания, нет опыта работы с IT-продуктами, и в итоге всё держится на вере и интуиции.
Казалось бы, решение очевидное - нанять сильного техлида и контролировать процесс через него. Но даже когда до этого доходят, овнеры сталкиваются с другой стороной проблемы - людьми, которые искренне считают себя сильными специалистами, а по факту разрушают продукт. И здесь мы уже выходим на тему неосознанного и осознанного скама, о которой я буду говорить дальше.
Тема 2. Неосознанный руин и осознанный обман
Говоря о проблемах нашей с вами сферы, невозможно обойти стороной тему руина проектов и осознанного обмана. Но важно сразу расставить акценты. Тут нужно объяснить, неосознанный руин - следствие низкой квалификации, осознанный обман - намеренное введение в заблуждение работодателей.
Начнём с неосознанного руина. Почти всегда является следствием сразу нескольких факторов. Во-первых, это низкая квалификация менеджмента без технического бэкграунда. Во-вторых, отсутствие какого-либо контроля качества. И в-третьих, низкая квалификация самого разработчика.
Сценарий обычно выглядит одинаково. Разработчик приходит в проект, проходит отбор, показывая минимальный набор навыков, достаточный, чтобы его взяли. После этого он начинает делать то, что умеет. А умеет он, как правило, писать код, который работает здесь и сейчас, но плохо масштабируется и не рассчитан на рост проекта.
На старте это почти незаметно. Первые системы появляются быстро, задачи закрываются, менеджмент доволен. Но чем дольше разработчик пишет такой код, тем сложнее ему становится продолжать. Любое новое требование начинает цеплять старые решения, правки становятся болезненными, а скорость разработки постепенно падает.
В какой-то момент начинают происходить характерные вещи. Таски делаются всё медленнее. Вместо разработки новых систем всё чаще приходится переписывать старые. Количество багов растёт.
Узнали себя?
Если менеджер не понимает, почему это происходит, он не видит корень проблемы. Он видит только результат - падение продуктивности. В итоге проект либо застревает в бесконечных переделках, либо просто заканчивается бюджет.
Очень часто финал выглядит ещё проще. Разработчик сам в какой-то момент понимает, что дальше он это поддерживать не может. И просто уходит. Как правило, молча. Без передачи дел, без объяснений, без ответственности. Формально он может даже не считать себя виноватым, потому что делал всё, что умел.
Я не раз сталкивался с этим лично. Думаю, большинство разработчиков с опытом тоже.
Ты приходишь в проект после того, как предыдущий разработчик ушёл, смотришь на код и понимаешь, что поддерживать это безумно дорого.
И приходится объяснять менеджменту или овнеру неприятную вещь - то, что у них есть, нужно либо полностью переписывать под нормальную архитектуру, либо смириться с тем, что проект будет медленно умирать.
Это всегда болезненный разговор, потому что за этим кодом уже стоят потраченные деньги и время.
Но на этом история не заканчивается. Помимо неосознанного руина существует и осознанный обман.
Из-за всё тех же проблем - низкой квалификации менеджмента и отсутствия контроля качества - молодые проекты крайне уязвимы. Этим пользуются люди, которые хорошо понимают специфику сферы. Они приходят в проект, обещают сделать весь продукт в одиночку за полгода и за относительно небольшой бюджет. Для неопытного менеджера или овнера это звучит как удача
Дальше начинается имитация бурной деятельности. Полгода создаётся видимость работы. Что-то коммитится, что-то показывается, постоянно находятся оправдания. В какой-то момент бюджет заканчивается, разработчик исчезает, а проект остаётся с кучей несвязного кода, который невозможно развивать. Это осознанный расчёт на безнаказанность.
Да, на форуме существует чёрный список. Но важно понимать, что это не решение проблемы, а борьба с последствиями. В чёрный список приходят уже тогда, когда проект разрушен и деньги потеряны. Он не предотвращает скам, он лишь фиксирует его постфактум.
Важно чётко понимать одну вещь. Вторая тема полностью вытекает из первой. Неосознанный руин и осознанный обман не возникает на пустом месте. Он становится возможным именно в среде с низкой квалификацией, отсутствием технического контроля и слабым менеджментом.
Если проекты хотят реально снижать риски, единственный путь очевиден. Повышать квалификацию менеджеров, перестать делегировать управление продуктом людям без технического понимания и не экономить на действительно опытных технических лидах. Это дорого, это сложно, но это единственный способ не наступать на одни и те же грабли из года в год.
Иначе всё продолжит работать ровно так, как работает сейчас.
Тема 3. Деньги, ожидания и реальность рынка
В заключении хочется поговорить ещё об одной проблеме, которая напрямую вытекает из всего, о чём было сказано выше. Она тоже связана с низкой квалификацией и отсутствием реального релизного опыта, но здесь фокус в первую очередь на овнерах. Закрепляется эта проблема разработчиками, которые готовы работать за любые деньги и в любом проекте.
Да, речь пойдёт про цифры и вы готовы к этому разговору.
Ожидания овнеров по срокам и бюджету разработки в этой сфере почти всегда занижены. Причём занижены системно. Формируются они обычно из двух источников. Первый - поверхностный анализ рынка. Овнер видит, что разработчики готовы работать за копейки, особенно на старте, и делает вывод, что "значит так и стоит". Это прямое следствие тем 1 и 2. Второй источник - ложное ощущение, что можно либо взять open source проект вроде RedAge, либо написать мод с нуля за минимальный бюджет и год времени, а дальше как-то само поедет ( поедет
Реальность совсем другая. Невозможно составить конкуренцию проектам в релизе, не имея технически конкурентного продукта, достаточного бюджета на маркетинг и полного понимания, как устроены внутренние процессы и рынок труда. Идея сама по себе ничего не стоит, если за ней нет команды, опыта и денег. Это неприятно признавать, но это факт.
Здесь важно зафиксировать позицию максимально жёстко. Реалии рынка таковы, что в текущем состоянии сферы невозможно выехать чисто на идее. Нельзя взять open source мод, открыть сервер и рассчитывать на стабильный онлайн. Десятки "мертворожденных" проектов - лучшее тому подтверждение. Нельзя разработать конкурентный продукт с нуля за низкий бюджет. Сотни тысяч долларов, потраченных овнерами впустую, это уже доказали.
Сейчас не 2018 год. Тогда действительно можно было залететь с написанным на коленке проектом, получить стабильный онлайн и даже доход. Рынок был пустой, аудитория не избалована, конкуренция слабая. Сейчас рынок занят. Игроки распределены. Игроки выбирают крупные проекты, которые могут дать им качественный и стабильный игросервис, уникальные механики и ощущение живого продукта, над которым работает большая команда. Иллюзий здесь быть не должно.
Если говорить про цифры, то понятно, что точные значения называть я не могу, хоть мне и известны несколько кейсов. Но порядок цифр нужно понимать. Разработка с нуля конкурентного мода при наличии реально сильной и уникальной идеи, которая способна привлечь и удержать аудиторию, в самом оптимистичном сценарии занимает около 1.5-2 лет. Это команда из 7-9 человек на разные позиции. Вложения в таком случае легко доходят до примерно 200 тысяч долларов. Это сценарий, где идея действительно свежая и интересная рынку, а не попытка повторить уже существующие проекты.
Если же цель - сделать то же самое, что уже есть у крупных проектов, и попытаться забрать их аудиторию, всё становится хуже. Такой путь обходится минимум в два раза дороже и занимает в два раза больше времени. Можно масштабировать команду и сократить сроки, но тогда кратно растёт бюджет. Магии здесь нет.
Отдельно нужно сказать про маркетинг, потому что это ахиллесова пята даже технически и идейно сильных проектов. Реалии рынка таковы, что большинство медийных лиц сидят на контрактах у крупных проектов. Это самая дорогая статья расходов за весь путь проекта, от разработки до реального онлайна и поддержки. Даже мелкие стримеры с низкой конверсией давно перестали стесняться и просят огромные деньги за интеграции и амбассадорство.
Таргетированная реклама даёт минимальный приток. Аудитория больше не лояльна к обещаниям "самого лучшего проекта, где всё будет лучше, чем у других". Кредит доверия полностью исчерпан. Привлекать новых людей в сферу дорого. Очень дорого.
Единственный сценарий, где привлечение новой аудитории может сработать, это создание продукта, который изначально ориентирован не на RP в классическом виде. Более казуальный подход, RPG или MMO-механики, фактически полный отказ от RP как основы. Только в таком случае при грамотном маркетинге можно говорить о росте за счёт новой аудитории, а не о попытке откусить кусок у уже сформировавшихся гигантов.
И всё это снова возвращает нас к началу. Деньги, сроки и ожидания напрямую зависят от квалификации. От понимания, как делаются продукты, как они живут после релиза и сколько это на самом деле стоит.
Пока в сфере будут доминировать иллюзии, а не расчёт, мы будем видеть одни и те же истории снова и снова.
Заключение
Все проблемы в этой сфере упираются не в платформу, не в комьюнити и не в "плохое время". Они упираются в квалификацию и ответственность. Низкий уровень разработчиков рождает слабые продукты. Слабый менеджмент не способен это вовремя заметить. Овнеры, не понимая реальной стоимости разработки и рынка, принимают решения на ощущениях, а не на расчётах.
В итоге сфера годами крутится в одном и том же цикле: иллюзии, обещания, слив бюджета, закрытие проекта. И так по кругу.
Пока Rage-проекты будут восприниматься как "это рейдж тут так можно/нужно", а не как полноценные IT-продукты, ничего принципиально не изменится. Конкурентный продукт требует опыта, сильной команды, денег и времени. Всё остальное - самообман, за который рынок уже не раз выставлял счёт.
P.S. Спасибо всем кто прочитал эту статью за внимание к проблеме, я потратил очень много времени на подготовку материала и буду благодарен за её развитие, любое мнение приветствуется, комментируйте, распространяйте, развивайтесь. Не будьте равнодушными к сфере, которая подарила каждому из нас нас возможности.
Последнее редактирование: