Да, Скотч с ними с кусками контента в магазине, вот то, что игровым механикам дали по шарам ради ребаланса под магазин, вот, что действительно и всерьез мешает играть в такие игры(
Тут уже смешивается несколько методологий и Agile и Lean. По гибкой мы вроди бы разобрались, что разрабатывать нужно функционал который сразу же в течении итерации будет интегрирован в продукт и поставлен пользователю. В случае с Lean, то бережливое производство предусматривает что в случае обнаружения проблемы, весь процесс должен быть остановлен и проблема должна быть устранена, дабы не причинять ущерба всему что базируется на ней. Если же проблема в области на которой ничего не держится, её можно отложить. В нашем случае, разработчики эко сломали экологию и забросили её, продолжая работать над срывающимся планом работ по новым фичам, в чём я точно уверен, и понимаю как работает эта кухня, особенно когда время заканчивается (деньги) и надо взять где то ещё.
Тот процесс по которому разрабатывается эко, это демонстрация непрофессиональности Джона, который разрабатывает как романтик. Это поверхностные знания которые можно получить работая 2-4 года в области управления проектами/продуктом.
Ну, это да. Если разрабатывать игру с прицелом на магазин, то p2p-версия получится… странной. А если — с прицелом на p2p, то все приёмы монетизации ярко вылезут на свет, продемонстрировав, как из игры просто выдрали куски и засунули в магазин :)
В приведённом тобой примере с государствами это, утрируя, выглядело бы так — создаётся заглушка модуля «Государство», интегрируется со всем остальным, и потом разрабатывается первая его версия — с единоличным лидером мира.
Это в ситуации, когда ты рассматриваешь принципиальную возможность добавления конкурирующих государств в будущем. То есть, по сути, уже дошёл до этой механики и проектируешь её, просто временно используешь заглушку. Но что если изначально ты считал схему «одна планета, одна экология, одно государство» цельной и достаточной? Я об этом.
Давай попробуем поговорить о том же, но в контексте будущих механик, а потом вернёмся к этому разговору через пару лет. Что сейчас нужно сделать разработчикам в 9.0, чтобы не допустить проблем, с которыми мы столкнёмся в ближайшие пару лет? Можно ли это чётко предсказать без фазы практических результатов на протяжении этих двух лет?
Я не идеализирую SLG и не считаю, что они делают всё правильно. Я вообще не знаю ни одного человека, который делал бы всё правильно. А уж целую команду, которой постоянно приходится идти на компромиссы, и подавно. Здесь я говорю о принципиальном подходе к циклам разработки через практические эксперименты и переделки. Я хочу быть свидетелем этой эволюции. Мне она кажется вполне естественной.
Чего? Я вот искренний сторонник гибридной модели монетизации игр :)
Делайте два стула сервера с одинаковыми рейтами и моментом открытия. Один f2p, второй p2p. Кто куда хочет — тот пусть туда и идёт. Уверен, что время очень быстро расставит всё по своим местам, даже статистику населённости публиковать не придётся.
Но так, разумеется, никто никогда не сделает — иначе все красивые презентации подобных евангелистов хорошего фритуплея можно будет отправлять в Recycle Bin.
Что касается обозначенных мной сроков: я считаю, что подход «попасть с первого раза» очень трудозатратный (ведь в Eco сейчас реализуют куда более сложные механики по большинству направлений) и стимулирующий существенные перестраховки. Да, может показаться, что сделать с первого раза всё равно было бы быстрее. Так и есть, будь у разработчиков машина времени и знания о промежуточных фидбэках, благодаря которым они могли бы не допускать промежуточных ошибок или неоптимальных механик. Но машины времени нет.
Смысл гибкой разработки — вовсе не в том, чтобы «попасть с первого раза». Он скорее в том, чтобы принятие неверного решения (о котором мы в момент его принятия ещё не знаем, что оно неверное) не оказывало существенного влияния на проект в целом — поэтому и принято как можно сильнее декомпозировать компоненты, уменьшая площадь воздействия их друг на друга.
В приведённом тобой примере с государствами это, утрируя, выглядело бы так — создаётся заглушка модуля «Государство», интегрируется со всем остальным, и потом разрабатывается первая его версия — с единоличным лидером мира. В зависимости от фидбэка она либо оставляется, либо заменяется на вторую версию — с выборными должностями. Потом — на третью версию — с множественными государствами. Таким же образом с остальными механиками.
Важно, что в любой момент игра представляет собой полностью работоспособный набор элементов. А сейчас получилось, что в 0.7 были одни механики и некоторые из них не работали, в 0.8 довольно сильно всё перелопатили, но некоторые (уже другие) механики не работают. В 0.9 всё ещё раз перелопатят, добавив кучу нового — но справятся ли со всеми заглушками?
Именно это меня беспокоит, потому что я, так же, как и ты, обладаю существенным кредитом доверия к SLG. И мне грустно видеть, как они выкатывают очередную версию крутейшей игры, которую нельзя чётко назвать полностью играбельным продуктом — а значит, и начать как-то интенсивно монетизировать. Хочется, чтобы у них появились лишние деньги на расширение штата, новое оборудование, рекламу и всё такое прочее, что ускорило бы процесс разработки.
В том и дело, что «смена фундамента» — это признак того, что геймдизайн был, мягко говоря, сыроват на старте.
По-моему, далеко не всегда это так. Например, если авторы New World допускают типичные ошибки при проектировании PvP-среды, приводящие к типичным последствиям в виде ганкбокса, это выглядит явной ошибкой, потому что до этого была масса практических примеров в виде реализованных аналогичных механик с аналогичными последствиями. Но, например, если EVE Online проектирует свою MMO, а вместе с ней механику контроля территорий в 2000 году, когда никаких практических примеров контроля территорий в MMO нет, я не считаю это плохим геймдизайном из-за наличия там ошибок.
Это эксперимент в полной неизвестности, который затем корректируется путём кардинальной переделки с нуля на основе полученных косяков, как это и произошло дважды в истории EVE Online, когда сначала игроки ответили на наивную модель установки POS'ов в качестве маркеров клайма их множественным спамом по всей системе (и пришлось вводить один единственный TCU), а затем, через пятнадцать лет после изначального проектирования, авторы пришли к идее окон уязвимости.
И нет, я не готов говорить, что они плохие геймдизайнеры, потому что не ввели окна уязвимости в 2000 году. В этом вопросе я буду считать их хорошими геймдизайнерами до тех пор, пока они не опускают руки и готовы замахиваться на переделки даже в фундаментальных механиках.
Кстати, Эко — это про экосистемы в широком смысле (природные, экономические, социальные), а сверх-чувствительная экология в социальной среде, как выяснилось, слишком сильно привлекает грифферов. И вот в этом часто заключается ошибка геймдизайнера. Ты, наверняка, как и я, при взгляде на игру с чуткой экологией, моделировал ситуацию, как мы будем её защищать и доказывать другим важность этой защиты, указывая на явные последствия. Но рассматривал ли ты ту же ситуацию с точки зрения гриффера, который будет наслаждаться твоими безрезультатными уговорами и негативными эмоциями от гибели экосистемы?
Я совершенно согласен с тобой в вопросе фундаментальных просчётов бизнес-модели Eco. Во всяком случае с точки зрения игры, которая собирается развиваться многие годы. Но мы ведь говорили, как мне кажется, о другом — о принципиальных подходах к разработке, и о сравнении с другими реальными многопользовательскими проектами (желательно такими же амбициозными в плане механик), которые пытаются работать в такой же непредсказуемой среде с таким же количеством степеней свободы и рычагов влияния игроков друг на друга.
Что касается обозначенных мной сроков: я считаю, что подход «попасть с первого раза» очень трудозатратный (ведь в Eco сейчас реализуют куда более сложные механики по большинству направлений) и стимулирующий существенные перестраховки. Да, может показаться, что сделать с первого раза всё равно было бы быстрее. Так и есть, будь у разработчиков машина времени и знания о промежуточных фидбэках, благодаря которым они могли бы не допускать промежуточных ошибок или неоптимальных механик. Но машины времени нет.
Приведу простой пример — я одновременно с надеждой и страхом смотрю на механику конкурирующих государств. Ты знаешь мою позицию и мои опасения по поводу того, как это может помешать социальной среде. Если бы ты меня попросил принять решение, добавлять эту механику в Eco или нет, чтобы зря не тратить силы и время команды, я был бы в замешательстве. То есть, скорее всего, я бы сказал «не тратить», но никакого реального этапа проработки этого варианта у нас не было бы. Всё было бы решено гипотетически. И мне это не нравится. Потому что из любого практического игрового опыта можно сделать выводы, которые невозможно сделать из мысленных допущений.
Например, благодаря мысленным допущениям, я был уверен, что идея жизни «в одной лодке», «на одной планете» в качестве единого государства — концептуально правильная. В конце концов, так и живёт любое государство, пытаясь примирить внутри себя интересы очень разных людей. Куда всё пришло? В плане законов — к довольно стандартному, безопасному набору в большинстве случаев. Людям так проще. И безопаснее. Нет конкуренции — нет особых законодательных экспериментов. Вместо них принцип «не ломай то, что более-менее работает». В плане социальной среды это привело к постоянным эмоциональным человеческим стычкам, которые довольно сильно выматывают, а взамен не предлагают эмоциональных связей с теми, с кем твои взгляды совпадают. Я не мог этого просчитать. Никто из разработчиков в этом направлении ничего не делал. Чужого опыта в этом вопросе у авторов Eco не было, или мне о нём неизвестно. Но теперь, получив кучу «полевых результатов», мы кое-что знаем. И, оглядываясь назад, может критиковать.
Но сможем ли мы сделать то же самое по поводу механики пользовательских государств? Сейчас, на берегу, когда механики ещё нет. Мне кажется, что не сможем. Во всяком случае я — не могу. Мне всё ещё интересно заглянуть в реальность, где пользовательские государства есть. Но мои опасения никуда не делись. А это фундаментальные вещи для социальной многопользовательской игры, которые могут поменять главные мотивации, модель общения, базовую модель взаимодействия.
Вот почему я готов всячески поддерживать авторов Eco именно в последовательных экспериментах. В движении от простого к сложному через реальные игровые сессии. Именно за это я люблю живые, развивающиеся игровые сервисы. И мне кажется, что сама установка «сделать наверняка с первого раза» может сильно увеличить срок разработки и количество безопасных решений в дизайне.
В том и дело, что «смена фундамента» — это признак того, что геймдизайн был, мягко говоря, сыроват на старте. Вчера ты играешь в одну игру, а через год разработчики выкатывают тебе игру с полностью видоизмененными механиками. Есть не иллюзорный шанс, что ты будешь сидеть в «недоумении».
Я не в коем случае не ругаю саму игру — интересный онлайн опыт, без вопросов. Но что говорить о механиках, если базовая концепция, вынесенная в название игры, на минуту, уже давно ушла на третьи-четвертые роли. Ни грамма влияния меня на экологию или экологии на меня и мир я не увидел за наш цикл и никогда не ощущал в других мирах, где был. Достаточно формальная часть игры, будем честны.
Так что, да, соглашусь с предыдущими мнениями — сделайте рабочий продукт с готовой концепцией, а потом шлифуйте его, а не выкатывайте «новую игру» каждый год.
Ты приписываешь моему «альтернативному миру» какой-то странный набор качеств.
В моём альтернативном мире, раз уж мы решили залезть ко мне в голову — собрав 200 тысяч долларов на Кикстартере и получив не знаю уж какой грант и договорённости о поставке Эко в учебные заведения, я бы начал с того, что продумал наиболее важный для жизнеспособности любого коммерческого предприятия вопрос, а именно — что будет, когда деньги начнут заканчиваться. Не тянул бы до 2020 года с этим вопросом и не реализовывал бы его (только) в виде варианта собственного платного хостинга на своих мощностях. Впрочем, в финансовых планах я не специалист, в отличие от других аспектов разработки.
Так вот — обдумав хорошенько концепцию и архитектуру игры, в моём альтернативном мире та платформа, которую в реальном наконец-то, вроде бы, к 0.9 сделали модульной и легко расширяемой, была бы таковой изначально. А значит — не нужно было бы по несколько раз переделывать одно и то же, и тем более — одновременно, потому что изменение одного не тянуло бы за собой остальное. В ПО с монолитной архитектурой сложность внесения изменения и тестирования возрастает в соответствии со степенной функцией с увеличением числа компонентов, отсюда крайне низкая скорость разработки и количество багов — тронув одно, с высокой вероятностью ломаешь что-то другое, и не одно.
Отсутствие приколоченности гвоздями одного компонента игры к другим позволило бы:
а) Вводить и развивать их постепенно
б) Быстро вносить изменения в соответствии с фидбэком
Подробно разбирать не лезущую ни в какие ворота фразу про то, что в моём альтернативном мире мы ещё и игры бы в глаза не видели не буду — полагаю, понятно, почему всё скорее всего было бы ровно наоборот.
Как я понял, Кио совсем о другом. Он предлагает релизнуть версию 1.0 с базовыми механиками. Затем, через 2-3 месяца адд-он v.2.0 с новыми профессиями и несколькими новыми механиками плюс правки багов. И так далее — каждые N… нет, N маловато — пусть будет каждые M месяцев в таком стиле полноценный адд-он, повышающий версию релиза.
Имхо, аналог полугодовых адд-онов Евы доапокрифовских времен, но с чуть меньшим временным интервалом.
То есть в твоей версии альтернативного мира мы всё ещё не играем и в глаза не видели Eco. И ещё не увидим пару лет. При этом у разработчиков до сих пор нет обратной реакции и набора реальных игровых историй, того, что людям интересно, а что не прижилось или было дискредитировано.
То есть ты хотел бы, чтобы Eco осталась на уровне 7.0, но с рюшиками в виде водного и железнодорожного транспорта?
Нет, я хотел бы версию 1.0 — с половиной текущих профессий повара, частью промышленных, ограниченным набором правил для законов и контрактов. Потом — 2.0, где добавилось бы несколько профессий, расширились возможности законов/контрактов. Потом 3.0 — с коллективными контрактами, Конституцией и дальнейшими улучшениями. Потом — 4.0, который был бы по функциональности где-то на уровне того, что нас ждёт в 0.9.
Между этими этапами могли вы помещаться более мелкие обновления с косметическими новшествами типа новых животных и материалов + багфиксы.
Но нет — мы будет годами пилить одно огромное дополнение, а игроки за это время устанут ждать, пресытятся и разочаруются…
То есть ты хотел бы, чтобы Eco осталась на уровне 7.0, но с рюшиками в виде водного и железнодорожного транспорта?
Не, я понимаю, что ты хотел бы, чтобы они сразу выпустили хотя бы 9.0, но на практике я такого ни разу не видел. Видел, как в EVE фундаментальную систему суверенитета меняли дважды. Видел, как в ХиХе перепахивали многие фундаментальные механики. Но чтобы в живой, большой MMO, завязанной на человеческий фактор, что-то сделали идеально с первого раза, не видел. А Oxygen not included и RimWorld, всё же — строго выверенные однопользовательские концепции, которые никто не собирался принципиально менять.
Мне, к слову, наоборот нравится это развитие по живому, на основе кучи реальных игровых историй, узких мест и извращений геймплея. Ведь всё это невозможно просчитать. Слишком много степеней свободы у многопользовательских миров.
В том-то и дело, что «менять фундамент», по крайней мере не по прошествии долгих лет после релиза — это очень, ОЧЕНЬ плохая практика. Фактически она означает, что системный архитектор с главным геймдизайнером провалили свою миссию.
Это примерно как написать серверную часть многопользовательской игры под винду, а после релиза обнаружить, что она не тянет требуемого количества народа — и начать с нуля переписывать под линукс. Или (привет, Worlds Adrift) внедрить SpatialOS, а на определённом этапе понять, что всё тормозит и счета за электричество из ЦОДов астрономические.
Кио, практический пример игры, которая именно так разрабатывается, есть? :)
Практически любая игра, доступная с ранних этапов разработки. Из последних, которые я трогал лично — Oxygen not included, RimWorld. Это не какая-то экзотика, а скорее наоборот — настоящее разработки программного обеспечения. У геймдева, разумеется, есть свои нюансы — но наладить гибкую разработку вполне реально и там, особенно если это заложено с самого начала.
Тот процесс по которому разрабатывается эко, это демонстрация непрофессиональности Джона, который разрабатывает как романтик. Это поверхностные знания которые можно получить работая 2-4 года в области управления проектами/продуктом.
Но ведь согласно доводам Кристин, это невозможно. Потому что микротранзакции — это часть геймдизайна. Что доказывает старый отечественный эксперимент.
Это в ситуации, когда ты рассматриваешь принципиальную возможность добавления конкурирующих государств в будущем. То есть, по сути, уже дошёл до этой механики и проектируешь её, просто временно используешь заглушку. Но что если изначально ты считал схему «одна планета, одна экология, одно государство» цельной и достаточной? Я об этом.
Давай попробуем поговорить о том же, но в контексте будущих механик, а потом вернёмся к этому разговору через пару лет. Что сейчас нужно сделать разработчикам в 9.0, чтобы не допустить проблем, с которыми мы столкнёмся в ближайшие пару лет? Можно ли это чётко предсказать без фазы практических результатов на протяжении этих двух лет?
Я не идеализирую SLG и не считаю, что они делают всё правильно. Я вообще не знаю ни одного человека, который делал бы всё правильно. А уж целую команду, которой постоянно приходится идти на компромиссы, и подавно. Здесь я говорю о принципиальном подходе к циклам разработки через практические эксперименты и переделки. Я хочу быть свидетелем этой эволюции. Мне она кажется вполне естественной.
Делайте два
стуласервера с одинаковыми рейтами и моментом открытия. Один f2p, второй p2p. Кто куда хочет — тот пусть туда и идёт. Уверен, что время очень быстро расставит всё по своим местам, даже статистику населённости публиковать не придётся.Но так, разумеется, никто никогда не сделает — иначе все красивые презентации подобных евангелистов хорошего фритуплея можно будет отправлять в Recycle Bin.
В приведённом тобой примере с государствами это, утрируя, выглядело бы так — создаётся заглушка модуля «Государство», интегрируется со всем остальным, и потом разрабатывается первая его версия — с единоличным лидером мира. В зависимости от фидбэка она либо оставляется, либо заменяется на вторую версию — с выборными должностями. Потом — на третью версию — с множественными государствами. Таким же образом с остальными механиками.
Важно, что в любой момент игра представляет собой полностью работоспособный набор элементов. А сейчас получилось, что в 0.7 были одни механики и некоторые из них не работали, в 0.8 довольно сильно всё перелопатили, но некоторые (уже другие) механики не работают. В 0.9 всё ещё раз перелопатят, добавив кучу нового — но справятся ли со всеми заглушками?
Именно это меня беспокоит, потому что я, так же, как и ты, обладаю существенным кредитом доверия к SLG. И мне грустно видеть, как они выкатывают очередную версию крутейшей игры, которую нельзя чётко назвать полностью играбельным продуктом — а значит, и начать как-то интенсивно монетизировать. Хочется, чтобы у них появились лишние деньги на расширение штата, новое оборудование, рекламу и всё такое прочее, что ускорило бы процесс разработки.
По-моему, далеко не всегда это так. Например, если авторы New World допускают типичные ошибки при проектировании PvP-среды, приводящие к типичным последствиям в виде ганкбокса, это выглядит явной ошибкой, потому что до этого была масса практических примеров в виде реализованных аналогичных механик с аналогичными последствиями. Но, например, если EVE Online проектирует свою MMO, а вместе с ней механику контроля территорий в 2000 году, когда никаких практических примеров контроля территорий в MMO нет, я не считаю это плохим геймдизайном из-за наличия там ошибок.
Это эксперимент в полной неизвестности, который затем корректируется путём кардинальной переделки с нуля на основе полученных косяков, как это и произошло дважды в истории EVE Online, когда сначала игроки ответили на наивную модель установки POS'ов в качестве маркеров клайма их множественным спамом по всей системе (и пришлось вводить один единственный TCU), а затем, через пятнадцать лет после изначального проектирования, авторы пришли к идее окон уязвимости.
И нет, я не готов говорить, что они плохие геймдизайнеры, потому что не ввели окна уязвимости в 2000 году. В этом вопросе я буду считать их хорошими геймдизайнерами до тех пор, пока они не опускают руки и готовы замахиваться на переделки даже в фундаментальных механиках.
Кстати, Эко — это про экосистемы в широком смысле (природные, экономические, социальные), а сверх-чувствительная экология в социальной среде, как выяснилось, слишком сильно привлекает грифферов. И вот в этом часто заключается ошибка геймдизайнера. Ты, наверняка, как и я, при взгляде на игру с чуткой экологией, моделировал ситуацию, как мы будем её защищать и доказывать другим важность этой защиты, указывая на явные последствия. Но рассматривал ли ты ту же ситуацию с точки зрения гриффера, который будет наслаждаться твоими безрезультатными уговорами и негативными эмоциями от гибели экосистемы?
Что касается обозначенных мной сроков: я считаю, что подход «попасть с первого раза» очень трудозатратный (ведь в Eco сейчас реализуют куда более сложные механики по большинству направлений) и стимулирующий существенные перестраховки. Да, может показаться, что сделать с первого раза всё равно было бы быстрее. Так и есть, будь у разработчиков машина времени и знания о промежуточных фидбэках, благодаря которым они могли бы не допускать промежуточных ошибок или неоптимальных механик. Но машины времени нет.
Приведу простой пример — я одновременно с надеждой и страхом смотрю на механику конкурирующих государств. Ты знаешь мою позицию и мои опасения по поводу того, как это может помешать социальной среде. Если бы ты меня попросил принять решение, добавлять эту механику в Eco или нет, чтобы зря не тратить силы и время команды, я был бы в замешательстве. То есть, скорее всего, я бы сказал «не тратить», но никакого реального этапа проработки этого варианта у нас не было бы. Всё было бы решено гипотетически. И мне это не нравится. Потому что из любого практического игрового опыта можно сделать выводы, которые невозможно сделать из мысленных допущений.
Например, благодаря мысленным допущениям, я был уверен, что идея жизни «в одной лодке», «на одной планете» в качестве единого государства — концептуально правильная. В конце концов, так и живёт любое государство, пытаясь примирить внутри себя интересы очень разных людей. Куда всё пришло? В плане законов — к довольно стандартному, безопасному набору в большинстве случаев. Людям так проще. И безопаснее. Нет конкуренции — нет особых законодательных экспериментов. Вместо них принцип «не ломай то, что более-менее работает». В плане социальной среды это привело к постоянным эмоциональным человеческим стычкам, которые довольно сильно выматывают, а взамен не предлагают эмоциональных связей с теми, с кем твои взгляды совпадают. Я не мог этого просчитать. Никто из разработчиков в этом направлении ничего не делал. Чужого опыта в этом вопросе у авторов Eco не было, или мне о нём неизвестно. Но теперь, получив кучу «полевых результатов», мы кое-что знаем. И, оглядываясь назад, может критиковать.
Но сможем ли мы сделать то же самое по поводу механики пользовательских государств? Сейчас, на берегу, когда механики ещё нет. Мне кажется, что не сможем. Во всяком случае я — не могу. Мне всё ещё интересно заглянуть в реальность, где пользовательские государства есть. Но мои опасения никуда не делись. А это фундаментальные вещи для социальной многопользовательской игры, которые могут поменять главные мотивации, модель общения, базовую модель взаимодействия.
Вот почему я готов всячески поддерживать авторов Eco именно в последовательных экспериментах. В движении от простого к сложному через реальные игровые сессии. Именно за это я люблю живые, развивающиеся игровые сервисы. И мне кажется, что сама установка «сделать наверняка с первого раза» может сильно увеличить срок разработки и количество безопасных решений в дизайне.
Я не в коем случае не ругаю саму игру — интересный онлайн опыт, без вопросов. Но что говорить о механиках, если базовая концепция, вынесенная в название игры, на минуту, уже давно ушла на третьи-четвертые роли. Ни грамма влияния меня на экологию или экологии на меня и мир я не увидел за наш цикл и никогда не ощущал в других мирах, где был. Достаточно формальная часть игры, будем честны.
Так что, да, соглашусь с предыдущими мнениями — сделайте рабочий продукт с готовой концепцией, а потом шлифуйте его, а не выкатывайте «новую игру» каждый год.
В моём альтернативном мире, раз уж мы решили залезть ко мне в голову — собрав 200 тысяч долларов на Кикстартере и получив не знаю уж какой грант и договорённости о поставке Эко в учебные заведения, я бы начал с того, что продумал наиболее важный для жизнеспособности любого коммерческого предприятия вопрос, а именно — что будет, когда деньги начнут заканчиваться. Не тянул бы до 2020 года с этим вопросом и не реализовывал бы его (только) в виде варианта собственного платного хостинга на своих мощностях. Впрочем, в финансовых планах я не специалист, в отличие от других аспектов разработки.
Так вот — обдумав хорошенько концепцию и архитектуру игры, в моём альтернативном мире та платформа, которую в реальном наконец-то, вроде бы, к 0.9 сделали модульной и легко расширяемой, была бы таковой изначально. А значит — не нужно было бы по несколько раз переделывать одно и то же, и тем более — одновременно, потому что изменение одного не тянуло бы за собой остальное. В ПО с монолитной архитектурой сложность внесения изменения и тестирования возрастает в соответствии со степенной функцией с увеличением числа компонентов, отсюда крайне низкая скорость разработки и количество багов — тронув одно, с высокой вероятностью ломаешь что-то другое, и не одно.
Отсутствие приколоченности гвоздями одного компонента игры к другим позволило бы:
а) Вводить и развивать их постепенно
б) Быстро вносить изменения в соответствии с фидбэком
Подробно разбирать не лезущую ни в какие ворота фразу про то, что в моём альтернативном мире мы ещё и игры бы в глаза не видели не буду — полагаю, понятно, почему всё скорее всего было бы ровно наоборот.
Имхо, аналог полугодовых адд-онов Евы доапокрифовских времен, но с чуть меньшим временным интервалом.
Между этими этапами могли вы помещаться более мелкие обновления с косметическими новшествами типа новых животных и материалов + багфиксы.
Но нет — мы будет годами пилить одно огромное дополнение, а игроки за это время устанут ждать, пресытятся и разочаруются…
Не, я понимаю, что ты хотел бы, чтобы они сразу выпустили хотя бы 9.0, но на практике я такого ни разу не видел. Видел, как в EVE фундаментальную систему суверенитета меняли дважды. Видел, как в ХиХе перепахивали многие фундаментальные механики. Но чтобы в живой, большой MMO, завязанной на человеческий фактор, что-то сделали идеально с первого раза, не видел. А Oxygen not included и RimWorld, всё же — строго выверенные однопользовательские концепции, которые никто не собирался принципиально менять.
Мне, к слову, наоборот нравится это развитие по живому, на основе кучи реальных игровых историй, узких мест и извращений геймплея. Ведь всё это невозможно просчитать. Слишком много степеней свободы у многопользовательских миров.
Это примерно как написать серверную часть многопользовательской игры под винду, а после релиза обнаружить, что она не тянет требуемого количества народа — и начать с нуля переписывать под линукс. Или (привет, Worlds Adrift) внедрить SpatialOS, а на определённом этапе понять, что всё тормозит и счета за электричество из ЦОДов астрономические.