В истории амбициозной SpatialOS пока нет поражающих воображение достижений, зато появился уже второй пример отказа от этой технологии. Впрочем, не спешите делать скоропалительных выводов. Если в случае ION от Дина Холла мы не получили никакой конкретики, из-за чего совершенно непонятно, что стало камнем преткновения в использовании этой технологии, идеолог Chronicles of Elyria — Джероми Уолш — рассказал в годовом отчете о проблемах во всех подробностях.

SpatialOS довольно серьезно может упростить обсчет многих событий в игровом мире, предлагая не только собственную платформу, но и серверные мощности на основе облачной технологии. При этом SpatialOS выставляет счет авторам игры за использование серверных мощностей, обещая значительное снижение расходов на эту технологию, благодаря стратегическому соглашению с Google Cloud. Собственно, Google Cloud и без того предлагает более выгодные условия, чем их прямой конкурент Amazon. Так авторы Camelot Unchained в декабре 2017 года объявили о переходе на Google Cloud, что, по заверениям авторов этого проекта, не только сделает сервис более доступным для жителей, находящихся за пределами США, но и значительно снизит расходы компании.

В любом случае, прелесть облачной серверной технологии заключается в том, что вы платите только за те мощности, которые используете в данный момент. Вам нет необходимости вкладывать деньги в обеспечение собственной избыточной серверной инфраструктуры, которая, возможно, будет простаивать большую часть суток при неравномерном онлайне. Вот только Chronicles of Elyria изначально планировали внедрить технологию Offline Player Characters, которая позволяет вашему персонажу действовать самостоятельно, когда вы выходите из игры. Получается, что большую часть времени в сутках, когда среднестатистический игрок находится вне игры, его персонаж продолжает осуществлять не меньшую, а иногда, из-за необходимости принимать решения вместо игрока, возможно, и большую нагрузку на сервер.

MMO-индустрия: Почему авторы Chronicles of Elyria отказываются от SpatialOS
Авторы Chronicles of Elyria, посчитав все, поняли, что реальные затраты на каждого персонажа при постоянных отчислениях SpatialOS будут слишком большие. А монетизация Chronicles of Elyria попросту не предполагает прямого запроса денег за доступ к игровому процессу. Плюс ко всему, некоторые технические сложности выбранных именно авторами технологий — переход с C# на JavaScript в качестве основного языка для backend-технологии при отказе поддержки JavaScript со стороны SpatialOS и исполнение части серверных технологий за пределами SpatialOS — стали дополнительными факторами. Сколько из перечисленных проблем можно было увидеть до объявления об использовании этой технологии, сказать сложно. Но все же кажется, что некоторые из них можно было предвидеть. Нет, правда, о том, что в Chronicles of Elyria персонажей игроков планируют обсчитывать 24/7, было известно еще с анонса проекта. И то, что это вылетит в копеечку в случае аренды серверных мощностей можно было легко предсказать. Авторы Seed, к примеру, это понимают изначально.

Основная интрига во взаимоотношениях авторов CoE и авторов технологии SpatialOS осталась за вежливыми благодарностями в адрес друг друга — насколько ценной для Chronicles of Elyria была предложенная SpatialOS технология. Ответ на этот вопрос читается в окончательном решении об отказе использовать SpatialOS. А вот что могут реализовать разработчики самостоятельно — пока вопрос без ответа. Очевидно, что это замедлит процесс разработки, но, возможно, основная проблема Хроник Элирии совсем не в технологиях, а в весьма странной для MMO концепции, которой Джероми Уолш поделился в том же обращении к игрокам:

В январе 2017 года мы начали долгий процесс превращения того, что было в сущности оффлайновой однопользовательской игрой, призванной оценить пользовательский опыт и геймплей, в Мультиплеерный Развивающийся Онлайновый Мир.

Для некоторых игроков именно SpatialOS была важным фактором в решении финансово поддержать Chronicles of Elyria, потому что использование серверной технологии для многопользовательских игр, над которой работает более трехсот человек и в которую вложено полмиллиарда долларов инвестиций, кажется действительно реалистичным сценарием разработки настоящих MMO для небольших команд. Отказ от SpatialOS уже негативно повлиял на отношение к Chronicles of Elyria. Но и для SpatialOS это удар по репутации.

Главный вызов, который остается для SpatialOS — это гибкость и широта возможностей, на основе которых авторы MMO могут реализовать интересные и, что очень важно, самобытные MMO-концепции. Амбициозной технологии нужны не просто примеры успеха — для компании важно показать действительно революционные возможности, которые дает их технология настоящим онлайновым мирам. На этом пути, конечно же, будут неудачи. Тем важнее противопоставлять им явные и очевидные успехи. Которых пока нет.

40 комментариев

avatar
Хм. Мне казалось что SpatialOS может использовать любую облачную платформу. А тут оказывается эксклюзивные права замешаны. Нехорошо это. Для тех кто хочет площадку что бы создать свою ММО не беспокоясь об инфраструктуре, приходится слишком много думать об инфраструктуре, в том числе о юридической и финансовой стороне.
  • 0
avatar
Для меня вообще странным выглядит выбор JS для бэкенда.
Более матёрые меня могут поправить, но JS вроде как не очень подходит под серьёзный бэк с необходимостью параноидальной защиты данных.
  • +2
avatar
Ну да, это явно странно. Правда, там TypeScript, а не чистый JS. Не вижу, в чём разница по защите данных — дырявое приложение можно на любом языке написать. А если паковать серверную базу в клиент — то уже мало что поможет.
  • 0
avatar
Может, это из-за особенностей работы, я как вебдиз воспринимаю JS как фронтэндовый язык, который по безопасности бэкапится серверными языками. Для дырявых-то приложений понятно, что достаточно кривой связки Hands+Head.) Но для ММО, которой просто требуется серьёзная защита…
Комментарий отредактирован 2018-01-15 22:47:39 пользователем Dalairen
  • +1
avatar
Это в принципе возможно, написать backend на JS? Подозреваю таки, что просто Java
  • 0
avatar
Ссылка на оригинал в тексте есть. Джероми технический специалист, так что напутать не мог.
  • 0
avatar
Возможно, опечатка? Java makes more sense here. Или мир очень странный.)
  • +1
avatar
Гугл говорит, что это действительно возможно. И всё же… Век живи — век учись.
  • 0
avatar


Слишком много для опечатки. :)
  • 0
avatar
Что ж, мир неистов.)
  • +1
avatar
Посмотрите на NodeJs, например.
  • +3
avatar
Разработчиков под JS/TS найти проще, чем под C#, только и всего.
  • 0
avatar
Tobie и Spectrum не согласны с этим.
Судя по рейтингам, JS лишь недавно поднялся на текущую (седьмую) позицию.
Иное дело — это стоимость Java/C#-программиста и Js-программиста.

Причиной выбора JS в качестве языка бекенда могут быть недавние изменения в языке, наличие хороших инструментов для асинхронной работы и возможность построить бекенд поверх NodeJs.
На самом деле разработчики могли перейти на связку C++/Js, где на C++, в рамках Ноды, реализуется системный уровень бекенда, а Js используется как скриптовой язык для задач бизнеса.
Такая схема является производительной вне зависимости от выбранного скриптового языка.
  • +1
avatar
На самом деле разработчики могли перейти на связку C++/Js, где на C++, в рамках Ноды, реализуется системный уровень бекенда, а Js используется как скриптовой язык для задач бизнеса.
Такая схема является производительной вне зависимости от выбранного скриптового языка.
К сожалению, буквально до недавнего времени не было попыток стандартизировать ABI, и при миграции на новую версию node или v8 все ломалось в неожиданных местах. Недавно, в качестве экспериментальной возможности, добавили N-API, но до широкого распространения этой штуке надо хотя бы из экспериментального статуса выйти. О наличии тяжелых проблем из-за отсутствия стандарта для native calls говорит, например, отсутствие хоть сколько-то живых аналогов numpy/scipy, хотя, казалось бы, богатая ниша: слишком уж тяжело это поддерживать (было до недавнего времени).
Можно, конечно, пойти другим путем и встроить тот же v8 как embeddable interpreter в программу на C++, но вы, кажется, про вариант с native calls из node.
Комментарий отредактирован 2018-01-16 12:43:16 пользователем Sirius
  • +1
avatar
Можно, конечно, пойти другим путем и встроить тот же v8 как embeddable interpreter в программу на C++, но вы, кажется, про вариант с native calls из node.
Я именно про вариант эмбеддинга. :)
Конкретно для задач разработки игр вариант расширения функционала высокого уровня через низкий выглядит как рубашка наизнанку — приносит много неудобства и выглядит некрасиво.
  • +1
avatar
Сейчас написание бэкенда на node.js это популярная штука. Не могу этого одобрить, но такая уж вот ситуация.
  • 0
avatar
Тю, nodejs для бекенду можно использовать.
  • +3
avatar
Возможно, да. NodeJS. Упс, не дочитал, уже ответили )
Комментарий отредактирован 2018-01-16 21:24:35 пользователем Shauni
  • 0
avatar
Node.js — программная платформа, основанная на движке V8 (транслирующем JavaScript в машинный код), превращающая JavaScript из узкоспециализированного языка в язык общего назначения.

На js писать быстро и дешевле чем на том же C#, но все равно странно, Node.js довольно много ресурсов ест у сервера, а для высоконагруженных проектов это влетит в копеечку.
Комментарий отредактирован 2018-01-18 20:35:55 пользователем Swarog
  • 0
avatar
На js писать быстро и дешевле чем на том же C#
зависит от размера и сложности проекта.
  • 0
avatar
Вот у авторов Элирии получается в 3 раза быстрее. А это очень хорошее ускорение.
  • 0
avatar
А потом это чудо будет нещадно тормозить и не выдерживать даже человек 50 рядом ) Зато быстро написали, да.
  • 0
avatar
Вот и посмотрим :) Может, и не будет. Оптимизацией можно заняться и потом, когда всё работает.
  • 0
avatar
А я не знал, что ты разбираешься в программировании.
  • 0
avatar
Совершенно без разницы на чем писать бэкенд. Хоть на List, хоть на Cobol, хоть на JavaScript.
Если цели достигаются, языкового инструментария хватает и команда умеет — ради Бога.

И в историй этой JavaScript совсем не основная причина, я уверен.

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

А если эта надстройка не эффективна по CPU, то все вообще печально может быть и ценник «за использование серверных мощностей» может быть огромной засадой (но тут я могу только гадать)
  • +2
avatar
Потому что публичные облака и так-то дороги, а тут еще и за надстройку над ними платить надо.

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

Ну, и по одной из ссылок, которую я приводил в тексте, написано вот что:

Reduce or remove your cloud costs

Thanks to our partnership with Google Cloud, any games that are built upon the SpatialOS platform by members of the SpatialOS Games Innovation Program will receive subsidies that will substantially or completely cover the costs of cloud-based online development. Up to 100 participating studios will each be provided with up to $500,000 in SpatialOS credits that will cover SpatialOS and Google Cloud usage costs, including underlying server fees, during development. This is the largest development subsidy of its kind.
  • +3
avatar
Это немного совсем в сторону от темы, но мне хочется пояснить.

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

Если попытаться понять что вы за этот хостинг реально будете платить в месяц, то это будет не просто. Потому, что цена размазана по множеству «подсистем», и нужно очень детально понимать какие нагрузки на все эти «подсистемы» генерирует ваш проект. И уже тот факт, что достаточно точный ответ на вопрос «сколько это будет стоить» фактически не реально получить до, собственно, запуска системы в облаке, должен настораживать адекватных разумных.
И реальная, на данный момент, данность такова: публичные облака примерно в 3 раза дороже традиционных альтернатив. В 3 раза, Карл. Об этом профи прекрасно знают, и на тематических конференциях (HighLoad++, например) этот фактик всплывает не редко в контексте различных проектов. И тут я не голословен: я лично столкнулся этим болезненным фактом в 2016 году. (И в итоге идею переезда в публичное облако, фирма, в которой я работаю, похоронила полностью.)

Очень точно по этому поводу высказались ребята из MemSQL ещё в конце 2013 года: «The public cloud is phenomenal if you really need its elasticity. But if you don't – if you do a consistent amount of workload – it's far, far better to go in-house.» www.wired.com/2013/08/memsql-and-amazon/

Короче говоря, с финансовой точки зрения использование публичных облаков оправдано очень далеко не всегда. Есть мнение, что только примерно 5% проектов запущенных в публичных облаках, реально нуждается в этой самой «elasticity». Т.е. сценарии когда публичные облака это очень круто и плевать на цену — они есть. И я даже реальные примеры могу привести. Но правда и в том, что многим просто напросто деньги некуда девать.

И вот после этого жирного введения я хочу вернутся к MMO.

Понятно что хостинг чуть ли не основная статья расходов у MMO после запуска.
И если проект должен работать многие годы(MMO же!) и при этом дикого роста нагрузки каждый месяц на протяжении всех этих лет не будет — то публичное облако, это очень спорный выбор. Очень очень. В особенности спорный, для не AAA проектов, на которые деньги с неба не падают.

И поэтому, основываться на технологии, которая жестоко завязана на экосистему публичных облаков — это IMHO очень большой риск. Для таких проектов.

опять IMHO :)
  • +2
avatar
Очень точно по этому поводу высказались ребята из MemSQL ещё в конце 2013 года: «The public cloud is phenomenal if you really need its elasticity. But if you don't – if you do a consistent amount of workload – it's far, far better to go in-house.» www.wired.com/2013/08/memsql-and-amazon/
Все верно. И в случае с региональными шардами мы получаем именно противоположность состоянию «consistent amount of workload». У нас есть всплески будничного прайма и еще более крутые нагрузки на выходных. То есть наши серверы должны быть рассчитаны на максимальные нагрузки в выходные в условиях достижения максимальной вместимости, хотя реально 95% времени это не так. Мне так кажется. У меня нет реальных данных. Но это мои субъективные наблюдения за онлайном.
Комментарий отредактирован 2018-01-18 13:36:14 пользователем Atron
  • 0
avatar
И если проект должен работать многие годы(MMO же!) и при этом дикого роста нагрузки каждый месяц на протяжении всех этих лет не будет
У ММО дикий рост нагрузки на старте благодаря хайпу. Предсказать его сложно, приходится или покупать серверов с запасом, или терять доходы, временно прекращая продажи игры. Через 3 месяца после запуска 75% игроков уходят. Смысл покупать 20 серверов, чтобы скоро закрыть 15 из них? Тут как раз облака выглядят выигрышно.

Если делать инди-игру с онлайном до 5-10 тысяч человек, тогда конечно, облака и даром не сдались.
  • 0
avatar
Моя проблема в том что очень трудно донести эти особенности не скатываясь в технические и техническо-организационные детали :)

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

Речь даже не идет собственно о физических серверах. Можешь арендовать себе хост-сервер и построить виртуализацию. Т.е. ради Бога — вот вам облачные технологии те самые. Часто, действительно, удобно.

Речь именно о использовании публичных облачных сервисов (Google Cloud, AWS, Azure, Oracle Cloud и т.п.) это, на данный момент, тупо очень дорого. За те же самые ресурсы вы платите в разы больше получая взамен теоретически неограниченную горизонтальную масштабируемость и «как бы» очень высокий SLA. Нo, как я писал выше, действительно оправдано это гораздо реже чем кажется.

Вы подумайте вот о чем — крупные игроки бешено стоят и пропагандируют эти облачные сервизы не в последнюю очередь потому, что это очень прибыльное дело :) А прибыльное оно потому что ценник :))

В контексте P2P MMO, IMHO, единственное заметное достоинство это возможность развернуть свой игровой сервис в любой точке мира где есть дата-центр нужного облачного сервиса на примерно одной и той же архитектуре. (Примерно, потому что дата-центры облачных сервисов имеют гораздо больше отличий чем хотелось бы.)
  • 0
avatar
Облака для почти любого бизнеса, кроме стартапа в период построения прототипа (или условного сайта с котиками) выгоднее. Если мы говорим об обороте и нагрузке, превыщающим требования малого бизнеса, облако становится выгоднее существенно. Чтобы было совсем хорошо, считать желательно с учетом знаний особенностей платформы, позволяющих оптимизировать стоимость (preemptible инстансы у одного провайдера, reserved и spot инстансы у другого, плюс пачка трюков, которые известны людям, этим занимающимся). А набрать on-demand инстансов на все деньги для стартапа, конечно, не выгодно. Считать, конечно, надо правильно:
— учитывать, что на пиковые нагрузки в случае своего датацентра нужно держать запасные мощности, причем это может быть, скажем x1.5 от номинальной нагрузки. Про эластичность облака вы уже упомняули выше.
— железяки в облаке поддерживаются не вами. Это не особенно проблема, если у вашего бизнеса один условный «сервер в подвале» и админ, который его ребутает. Это становится проблемой, когда машин много, у них отказывают рейды, черти что еще случается, нужен персонал, который всей этой чепухой занимается. В случае с облаком вы об этом не то, чтобы не задумываетесь, а так, краем глаза посматриваете на оповещения о maintenance, которые у вас вызвали наблюдаемую задержку в пол-секунды.
— Повышенная доступность. Для обеспечения гарантий доступности, необходимых, например, согласно SLA, предоставляемым вашим бизнесом вам нужен, по сути, еще один датацентр где-нибудь не сильно далеко, но и не очень близко. Чтобы, например, при региональной аварии сервис все еще оставался доступен. Затраты на инфраструктуру вырастают значительно. Это не только еще один датацентр и персонал, но и накладные расходы на синхронизацию между ними. В случае с облаком эти штуки гораздо дешевле.
— Мультирегиональная доступность, доступ к, например, гугловой CDN. Контент отдается с points of presence гугла поблизости от пользователя. Ну и просто сеть у гугла хорошая. Лучшая в мире, пожалуй.
— Доступ к managed-сервисам, которые, опять же, обслуживаются не вами. Звучит как мелочь, а интеграция без усилий с тем же S3, или даже просто с fully-managed RDBMS, относительно которых вам не надо заморачиваться, а можно вместо этого делать то, что ваш бизнес делает — это хорошо. Казалось бы, что такого в петабайтном распределенном хранилище с минимальной latency и гарантиями доступности 99.9995 (тот же google cloud store).
… я тут понял, что написал простыню не по теме ресурса, так что прекращаю безобразия
  • +4
avatar
Ну ждешь ты наплыв на старте — арендую много серверов, через три месяца откажешься. Это никакая не проблема.
Красноречивый пример с русским ArcheAge говорит об обратном. Ну арендовало Мыло 9 серверов (или купило) — а народу набежало столько, что пришлось практически сразу останавливать продажи НРД. И запустили игру с 9 серверами, а 27 сделали через несколько недель, когда смогли арендовать и настроить ещё серверов. Было бы всё изначально в облаке — они бы за один день сделали не 9, а 30 серверов, продали бы намного больше НРД и оставили бы клиентов довольными.
  • 0
avatar
переход с C# на JavaScript в качестве основного языка для backend-технологии при отказе поддержки JavaScript со стороны SpatialOS и исполнение части серверных технологий за пределами SpatialOS
Мне кажется в это одна из основных причин, а не дополнительных. :) Интересно, а на основании чего собственники SpatialOS устанавливают свои тарифы?
  • 0
avatar
Скорее всего, исходя из целевого ROI.
  • 0
avatar
Отдельной заметкой, наверное, публиковать это не стоит, особенно учитывая тот факт, что редакция бойкотирует общий информационный поток по Chronicles of Elyria из-за выбранной авторами этой MMO системы монетизации, так что две негативные новости подряд могли бы быть восприняты как излишнее внимание исключительно к неудачам, но вот вам штрих к общей картине:

Вслед за отказом от SpatialOS в компании прошли увольнения части сотрудников в связи с тем, что переговоры с инвесторами на протяжении всего 2017 года не дали конкретных результатов.

К концу 2017 года стало понятно, что издатели не хотят брать на себя риск в продвижении настолько инновационного проекта, как Chronicles of Elyria, без существенных изменений в наших начальных взглядах. Условием некоторых издателей также был ввод микротранзакций, лутбоксов или других способов предпочесть доход игровому опыту. Ни один из этих вариантов нами не был принят.

Недостаток средств, собственно, мог стать одной из причин отказа от сотрудничества со SpatialOS, за которое, разумеется, нужно платить. Что до внезапно проснувшегося у идеолога Chronicles of Elyria предпочтения игрового опыта доходу компании, хочется напомнить важные философские установки Джероми Уолша, которые вступают в явный конфликт с красивыми лозунгами.
Комментарий отредактирован 2018-01-17 13:53:24 пользователем Atron
  • +4
avatar
издатели не хотят брать на себя риск в продвижении настолько инновационного проекта, как Chronicles of Elyria
Ахаха, это не игра «не очень», а наоборот — она слишком инновационная и гениальная, как Леонардо да Винчи. А людям вокруг не дано понять это.
  • +2
avatar
Ну, справедливости ради, в концепции много интересных задумок, а, судя по тому, как издатели самозабвенно наступали на грабли вовоклонов, им в узколобости не откажешь. Так что да, фраза, возможно, немного нескромная, но не «ахахаха». :)
  • 0
avatar
Вспомнил это интервью и сразу подумалось: а собственно почему издатели Евы не сдают нули в аренду всем желающим, в обмен давая настоящую защиту от нападений, а не тот псевдозонтик, что действует сейчас. Да и с логистикой могли бы подсобить. Это к тому, что не зря увольняют людей из компании, не додумавшихся до такой простой схемы.
ПС: надеюсь не надо доставать табличку «сарказм».
  • 0
avatar
ПС: надеюсь не надо доставать табличку «сарказм».
Спасибо, что всё же достал. =) В наше время так много людей защищают весь этот бред, что сарказмометр уже давно сломался.
  • +2
avatar
Касательно CCP, есть мнение, весьма субъективное и не мной сформированное, что наработки с ИИ бёрнеров рано или поздно выстрелят в наемный донат-флот. Что-то вроде — ты молодой и амбициозный, но еще не нашел себе друзей? Корпа НПЦ под ключ! Встяхни нули!
  • 0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.