Ну Atlantis и Galaxy — это тема отдельной статьи. Здесь я прежде всего делюсь радостью от того. что запущен новый мир Атлантиса. На моей памяти второй мир за 8 лет. И судя по нику, запустил его наш русский эмигрант.
Если народ откликнется и посчитает тему интересной, то можно будет и общие рассуждения запостить.
Судя по списку сделанных на движке проектов — никто толком не использует его преимущества. Да, точность высокая, но кто бы ей воспользовался? =D
Для симуляторов — да, очень важно. Особенно точность при высоких скоростях перемещения — моделирование снарядов оружия и высокоскоростных маневренных целей. Самолётов-перехватчиков, ракет…
Когда-нибудь доживём и до двойной точности на массовых платформах.
Мне кажется, вы берёте слишком высокий уровень ошибок. Проблемы были не на уровне «как бы нам побороть джиттер на дистанции» (Это уровень KSP, и да, это иерархические КС. Изящное решение, ИМХО), да и точность там вряд ли была особо высокой.
Проблемы там были на уровне пониже. Если у них неписевые сущности жрали до 80% нагрузки на сервер (trigger-based behaviour tree? Ага, щаз...), то что говорить про прочие аспекты нагрузки…
А что касается больших карт и расстояний — то я считаю, что помешал им прежде всего плохо продуманный дизайн игры в целом.
Они хотели сделать кооперативные приключения. Но при этом сильно обделили игроков инструментами, необходимыми, чтобы это было именно приключение, а не интерактивная переэкранизация «Ёжика в тумане». В игре новички зачастую падали со своих кораблей, не имея возможности ориентироваться в пространстве — и это при наличии гроздей островов поблизости!
А теперь попробуйте представить: вот вы висите посреди бескрайнего неба. Слева вдали — стена шторма. Снизу молочная пелена. Справа туман. Прямо туман. Сзади туман. Наверное сзади. Компаса один хрен нет. И горизонта. Можно грабить корованы лететь вперёд. А можно не лететь.
Вопрос: зачем? Какая мотивация куда-либо двигаться?
Видимые острова хотя бы давали такую мотивацию: вон там что-то виднеется, а давайте посмотрим поближе. Если бы между ними были расстояния больше видимости — было бы абсолютно непонятно, зачем куда-то лететь. А даже если и понятно — тратить полчаса, просто жужжа двигателями ("- Are we there yet?.. — No. — Are we there yet?.. — No. — Are we there yet?.. — F**k..."), убивает мотивацию исследования очень быстро.
Нужны «маяки», Points of Interest. Но Боссы не смогли их сделать, увлекшись визуалкой и лором. Вот и вся история эксперимента.
О. Atlantis и Galaxy. Жаль, что автор не сказал, как закончился оригинальный Atlantis и во что выродились поздние игры в Galaxy. Но это проблема всех современных игр.
Да брось :)
Я им с 2012 года занимаюсь и все только переписываю да меняю архитектуру, вместо того чтобы уже закончить и начать развивать на нем свои проекты. У него цели иные — отработка решений, а не экономическая эффективность.
Я себя сегодня утром вообще «дном почувствовал»(нет) потому что развиваю его уже приличное время без видимого выхлопа.
Не спорю, играют и 15. Но суть в том, что между заходами здесь проходит никак не менее суток. Представьте себе ММО, в которой вы убили пачку монстров, а затем мир замирает на сутки и в нем ничего не происходит.
Даже не так. Вы ударили монстра десять раз, а потом сутки сидите и ждете, попали ваши удары или нет. И ничего в это время сделать не можете. Правда в PbEM у вас не один персонаж, а несколько армий, как в HoMM, например. И каждый из этих отрядов, начав делать что-то, ждет сутки результатов своего действия.
Согласитесь, такое долго выдержит далеко не каждый.
В текущей модели данных Unity ситуация складывается не в пользу больших расстояний. Все современные игровые движки, и мой тоже, вообще не очень дружат с большими расстояниями, если дружить с ними «в лоб».
Стандартное вещественное число (float), лежащее в основе данных для всей математики Unity, имеет одинарную точность.
Хорошее позиционирование и верная передача динамики мира требуют от данных определенной разрешающей способности. Грубо говоря, нужно что-то принять за единицу измерения пространства. Может быть — принять метр за единицу измерений пространства. Может быть — миллиметр. От этого будет зависеть качество визуализации игры.
Так вот. В большом 3D мире, где требуется большое внимание к событиям вблизи персонажа, за единицу пространства принято считать миллиметр. При этом, одинарная точность типа float (который может содержать не больше 6 разрядов без обретения накопительной ошибки) позволяет описать не больше 10км пространства вдоль оси. 10км — это, хоть и большое, обозримое пространство.
Когда у тебя игра про свободные полеты и разрозненные острова, даже при наличии навигации, высока вероятность получить накопительную разницу между проложенным курсом и вектором фактического движения объекта. Поэтому, зачастую, чтобы в принципе не допускать возможности накопительной ошибки координат, разработчики итого сильнее сжимают пространство координатной системы мира.
Проблема с накоплением ошибки в координатах всегда мешала игровым движкам стать «чем-то большим». Многие разработчики систем симуляции управления и обучающих тренажеров (а я на эту тему разговаривал и с военными, и с их подрядчиками) упираются именно в нехватку точности позиционирования и физических расчетов. Поэтому, однажды в Томске был разработан очень полезный инструмент — Unigine.
Этот инструмент отличается прежде всего использованием типа вещественных чисел с двойной точностью (double) в качестве основы для всей математики пространства и физики. Его используют в симуляторах обучения пилотов самой различной техники, для создания VR-окружения и многих прочих проектов.
Однако для игр этот движок мало подходит потому что с двойной точностью современные процессоры работают чуть более чем в вдвое медленнее. Что GPU, что CPU.
Игры — это высокая динамика в ущерб точности модели представления. Мы ведь не хотим, ради боле точного позиционирования себя в микрометрах пространства, получить ~0,4 от текущего великолепия графики, динамично разрушаемого пространства, количества объектов и деталей вокруг нас, количества в принципе нас самих в рамках одной совместной сессии?
Это и не нужно :) Игровые движки имеют свои решения задач позиционирования и симуляции. Мое самое любимое решение — это иерархические координатные системы. В такие координатные оси можно записать всю нашу вселенную с точностью хоть в пикометр. Коротко: наша координатная система с разрешением в 10км может быть просто одним делением в другой координатной системе.
Другой прием довольно часто применяется на практике, особенно в космическом пространстве — это логарифмические интервалы осей. Коротко: все точки интереса на самом деле находятся на расстоянии вытянутой руки, но между ними находится подпространство, по которому ты будешь очень долго пилить на умопомрачительной для тебя скорости, но на черепашьей скорости для стороннего наблюдателя.
Судя по описанию лага при переходе проблема так называемого world origin shifting там была решена, тот же PhysX, на котором работает Unity, использовавшийся для клиентской части игры. Да и SpatialOS сама по себе предполагала соединение именно таких вот локальных симулируемых физ. пространств, так что это изначально решалось и в серверной части, без этого никак в openworld, от слова совсем.
А вот насчет double (64 БИТНЫЕ переменные, если я правильно понимаю о чем речь) вместо float это дело такое… Сначала смотришь и думаешь: «Ну что такого!? Каких-то 4 байта за х2 увеличение точности и еще большее увеличение расстояний и т.д.»
А потом понимаешь, что вектор это структура из 3х таких переменных, так еще и направление и скорость тоже определяются не одной точкой в 3х мерном пространстве. Вот и получается, что 4 байта на, скажем, 6 это 24 байта, которые на практике относятся далеко не только к векторам игроков, но и к NPC, их скелеты с 80 и блее костями, и еще есть сама физика, а если она продвинутая ( то есть не только коллизии, но и еще инерция честная, вращение и т.д.)…
Если кратко, то введение двойной точности это резкое увеличение потребляемой памяти и снижение частоты обработки данных, т.к. CPU тоже страдают от, скажем так, забитого кеша. Индустрия, на мой взгляд, пока не готова, да и, если честно world origin shifting неплохо справляется, там больше проблем с сетью ( передача данных клиента от сервера к серверу должна быть максимально плавной ), чем с флотами. ^_^
Для обычных игр дальности корректно просчитываемых координат вполне хватает, а для действительно огромных расстояний требуется переход на 64-разрядную версию. Но, повторюсь, я не спец, может там в чем-то другом проблемы были.
резкое увеличение расстояний без наращивания объектов — просто создание пустого пространства — было бы вполне логичным решением.
Я не специалист, но скорее всего это не получалось сделать из-за технических ограничений движка (например, проблемы с точностью определения координат объектов на больших расстояниях), а преодолеть их не было возможности. Хотя там и других технических проблем хватало. Красивую задумку подкосила слабая техническая реализация. А значительные ошибки в геймдизайне и финансовые трудности еще больше усугубили и без того сложную ситуацию.
Вы можете называть это любыми словами, суть от этого не поменяется: из того, что оно «развивалось» эти 20 лет (на самом деле развивались необходимые технологии, а сама VR не развивалась — после пруф оф концепт было ясно, что ещё не пришло время) не следует, что понадобится ещё 20 лет, чтобы оно развилось.
Если народ откликнется и посчитает тему интересной, то можно будет и общие рассуждения запостить.
Для симуляторов — да, очень важно. Особенно точность при высоких скоростях перемещения — моделирование снарядов оружия и высокоскоростных маневренных целей. Самолётов-перехватчиков, ракет…
Когда-нибудь доживём и до двойной точности на массовых платформах.
Проблемы там были на уровне пониже. Если у них неписевые сущности жрали до 80% нагрузки на сервер (trigger-based behaviour tree? Ага, щаз...), то что говорить про прочие аспекты нагрузки…
А что касается больших карт и расстояний — то я считаю, что помешал им прежде всего плохо продуманный дизайн игры в целом.
Они хотели сделать кооперативные приключения. Но при этом сильно обделили игроков инструментами, необходимыми, чтобы это было именно приключение, а не интерактивная переэкранизация «Ёжика в тумане». В игре новички зачастую падали со своих кораблей, не имея возможности ориентироваться в пространстве — и это при наличии гроздей островов поблизости!
А теперь попробуйте представить: вот вы висите посреди бескрайнего неба. Слева вдали — стена шторма. Снизу молочная пелена. Справа туман. Прямо туман. Сзади туман. Наверное сзади. Компаса один хрен нет. И горизонта. Можно
грабить корованылететь вперёд. А можно не лететь.Вопрос: зачем? Какая мотивация куда-либо двигаться?
Видимые острова хотя бы давали такую мотивацию: вон там что-то виднеется, а давайте посмотрим поближе. Если бы между ними были расстояния больше видимости — было бы абсолютно непонятно, зачем куда-то лететь. А даже если и понятно — тратить полчаса, просто жужжа двигателями ("- Are we there yet?.. — No. — Are we there yet?.. — No. — Are we there yet?.. — F**k..."), убивает мотивацию исследования очень быстро.
Нужны «маяки», Points of Interest. Но Боссы не смогли их сделать, увлекшись визуалкой и лором. Вот и вся история эксперимента.
Ок, ну ты хоть там в опенсорс выкинь лет через 5, ато посчупать-то интересное всегда хоца))
Я им с 2012 года занимаюсь и все только переписываю да меняю архитектуру, вместо того чтобы уже закончить и начать развивать на нем свои проекты. У него цели иные — отработка решений, а не экономическая эффективность.
Я себя сегодня утром вообще «дном почувствовал»(нет) потому что развиваю его уже приличное время без видимого выхлопа.
Так, так, а лицензирование предусмотрено?)))
Только вот в отличие от Эко — игроки в Еву не могут выпустить закон, отменяющий налог или переизбрать правительство…
Даже не так. Вы ударили монстра десять раз, а потом сутки сидите и ждете, попали ваши удары или нет. И ничего в это время сделать не можете. Правда в PbEM у вас не один персонаж, а несколько армий, как в HoMM, например. И каждый из этих отрядов, начав делать что-то, ждет сутки результатов своего действия.
Согласитесь, такое долго выдержит далеко не каждый.
Стандартное вещественное число (float), лежащее в основе данных для всей математики Unity, имеет одинарную точность.
Хорошее позиционирование и верная передача динамики мира требуют от данных определенной разрешающей способности. Грубо говоря, нужно что-то принять за единицу измерения пространства. Может быть — принять метр за единицу измерений пространства. Может быть — миллиметр. От этого будет зависеть качество визуализации игры.
Так вот. В большом 3D мире, где требуется большое внимание к событиям вблизи персонажа, за единицу пространства принято считать миллиметр. При этом, одинарная точность типа float (который может содержать не больше 6 разрядов без обретения накопительной ошибки) позволяет описать не больше 10км пространства вдоль оси. 10км — это, хоть и большое, обозримое пространство.
Когда у тебя игра про свободные полеты и разрозненные острова, даже при наличии навигации, высока вероятность получить накопительную разницу между проложенным курсом и вектором фактического движения объекта. Поэтому, зачастую, чтобы в принципе не допускать возможности накопительной ошибки координат, разработчики итого сильнее сжимают пространство координатной системы мира.
Проблема с накоплением ошибки в координатах всегда мешала игровым движкам стать «чем-то большим». Многие разработчики систем симуляции управления и обучающих тренажеров (а я на эту тему разговаривал и с военными, и с их подрядчиками) упираются именно в нехватку точности позиционирования и физических расчетов. Поэтому, однажды в Томске был разработан очень полезный инструмент — Unigine.
Этот инструмент отличается прежде всего использованием типа вещественных чисел с двойной точностью (double) в качестве основы для всей математики пространства и физики. Его используют в симуляторах обучения пилотов самой различной техники, для создания VR-окружения и многих прочих проектов.
Однако для игр этот движок мало подходит потому что с двойной точностью современные процессоры работают чуть более чем в вдвое медленнее. Что GPU, что CPU.
Игры — это высокая динамика в ущерб точности модели представления. Мы ведь не хотим, ради боле точного позиционирования себя в микрометрах пространства, получить ~0,4 от текущего великолепия графики, динамично разрушаемого пространства, количества объектов и деталей вокруг нас, количества в принципе нас самих в рамках одной совместной сессии?
Это и не нужно :) Игровые движки имеют свои решения задач позиционирования и симуляции. Мое самое любимое решение — это иерархические координатные системы. В такие координатные оси можно записать всю нашу вселенную с точностью хоть в пикометр. Коротко: наша координатная система с разрешением в 10км может быть просто одним делением в другой координатной системе.
Другой прием довольно часто применяется на практике, особенно в космическом пространстве — это логарифмические интервалы осей. Коротко: все точки интереса на самом деле находятся на расстоянии вытянутой руки, но между ними находится подпространство, по которому ты будешь очень долго пилить на умопомрачительной для тебя скорости, но на черепашьей скорости для стороннего наблюдателя.
А вот насчет double (64 БИТНЫЕ переменные, если я правильно понимаю о чем речь) вместо float это дело такое… Сначала смотришь и думаешь: «Ну что такого!? Каких-то 4 байта за х2 увеличение точности и еще большее увеличение расстояний и т.д.»
А потом понимаешь, что вектор это структура из 3х таких переменных, так еще и направление и скорость тоже определяются не одной точкой в 3х мерном пространстве. Вот и получается, что 4 байта на, скажем, 6 это 24 байта, которые на практике относятся далеко не только к векторам игроков, но и к NPC, их скелеты с 80 и блее костями, и еще есть сама физика, а если она продвинутая ( то есть не только коллизии, но и еще инерция честная, вращение и т.д.)…
Если кратко, то введение двойной точности это резкое увеличение потребляемой памяти и снижение частоты обработки данных, т.к. CPU тоже страдают от, скажем так, забитого кеша. Индустрия, на мой взгляд, пока не готова, да и, если честно world origin shifting неплохо справляется, там больше проблем с сетью ( передача данных клиента от сервера к серверу должна быть максимально плавной ), чем с флотами. ^_^