Войти
ПрограммированиеФорумОбщее

Создание MMORPG сервера для клиента написаного на Unity3d (4 стр)

Страницы: 1 2 3 4
#45
1:50, 2 ноя 2012

Физику для MMO ещё не делают - слишком сложно для вычислительных систем, даже GPU ускоренная физика, не потянет огромных миров.
Простая физика - да можно, но она элементарная и не влияющая на сам геймплай.

Тебе нужно почитать азы и проанализировать разные реализации в разных проектах - тогда будет яснее.

#46
9:04, 2 ноя 2012

Ну физика не влияющая на геймплей может быть реализована и на клиенте и можно очень детальной ее сделать (какие нибудь там развевающиеся одежды на ветру, взаимодействующие с террейном и другими моделями персонажей). Это меня не интересует. Меня больше интересует что-то вроде MMO Beat'en Up'а или MMO Carmaggedon'а

#47
11:13, 2 ноя 2012

San4es
> Меня больше интересует что-то вроде MMO Beat'en Up'а или MMO Carmaggedon'а
Подписался

#48
14:26, 2 ноя 2012

San4es
> взаимодействующие с террейном и другими моделями персонажей
Это уже физика для сервера..

#49
17:41, 2 ноя 2012

ну почему же для сервера? на сервер, например, взаимодействие капсулей, представляющих персонажей друг с другом и с другими Bouding shape'ами, сервер пересылает клиенту местоположение его капсуля и др. капсулей, которые надо отрендерить. Клиент, разумеется рендерит не капсули, а персонажей, меши, террейн, и т.п. но bouding шейпы тоже может учитывать( это нативная способность большинства игровых движков) Например, для своего персонажа можно не создавать капсуль, создавать капсули и боудинг шейпы для чужих персов и для своей ткани (например мантия на персе). Задача - проверить столкновение боудинг шейпа ткани, с боудинг шейпами того мира, который сервер прислал

#50
20:32, 2 ноя 2012

Ты не совсем о том.
Чтобы предотвратить что-бы кто-то переходил сквозь стены, отредактировав меш коллизий на стороне клиента, сервер не доверяет вычисление коллизии клиенту для принятия решений.
Сервер сам вычисляет коллизию для персонажей, она весьма простая и примитивная, проще чем капсулы. В том же WoW там вообще лишь вертикальная точка на ландшафте / геометрии, тупой RayCast.
Клиент же получает данные от сервера уже вычисленых позиций, и далее клиент сам тоже симулирует физику таким же образом как сервер в областях физики которая влияет на игровые данные.
А та физика которая не влияет, серверу вообще на неё пофиг, хоть персонаж будет сделать гелиевым софт-боди, пока он находиться там где сервер ему указал - всё ок. Поэтому ткани и т.п. да это чисто сторона клиента.

В гонках также не всё так просто, т.к. если мы говорим о сложной системе мартёров и т.п. то тут нужна нормальная симуляция физики (например для багги), и это дело должно быть на сервере, и на клиенте. При этом клиент будет учитывать ТОЛЬКО позицию самого тела багги, а уже мартёры и т.п. симулировать сам.
Почему на сервере должна быть полная симуляция? Потому что элемент мартёров, трений и т.п. прямым образом влияет на игровой процесс и позицию багги. Поэтому в гонках обычно 4-8 игроков максимум, т.к. там идёт perr-to-perr система, либо если есть хост, ему приходиться полноценно считать всю физику, что слишком много.

Поэтому MMO Carmageddon - это не простая задачка..

#51
12:04, 29 ноя 2012

Поэксперементировал с Юнити в направлении реализации физики на сервере.

Есть на сцене машинка которая ездит, состоит из: 1) скрипт CarMechanic - отвечает за механику машины, езду, оперирует с четырьмя wheelCollider'ами и с четырьмя мешами колес; 2) скрипт CarControlByKeyboard - получает от клавы сигналы от клавиш и передает в CarMechanic нужные управляющие импульсы accelerate, steer 3) 5 мешей с boudingBox'ами 4) 4 wheelCollider'ов 5) 1 rigidBody 6) 4 меша колеса

Есть вторая "машинка" которая не очень ездит: 1) скрипт CarMechanic только вместо мешей колес передаются снова wheelCollider'ы, поэтому и не совсем ездит - скрипт надо доработать)); 2) скрипт CarControlByKeyboard; 3) один cube - это и меш и boxCollider 4) четыре wheelCollider'ов 5) один rigidBody

Вторую машинку Instantiate 150 раз - все зависит от мощности компа, на работе комп помощней можно 200 копий создать, дома - 100. Работает без тормозов. Еду на нормальной машинке, сталкиваюсь с кубами, которые дергаются, сталкиваются между собой

На сервере, значит, рендеринга не будет - это небольшой "+" в сторону производительности.
На сервере будут открываться N сетевых соединений и обмен по ним - это большой "-" в сторону производительности
На сервере будет реализована еще дополнительная игровая логика (никому ведь неинтересно просто ездить и врезаться друг в друга) - это небольшой "-" в сторону производительности

  • комп на работе - i7 Значит восьмиядерный
  •   комп дома core 2 duo - значит четырех ядерный
    да не суть

    Онлайн в 100 человек это, конечно, маловато, но уже неплохо с учетом того что полноценная игровая физика (читай PhysX) реализовывается.
    Хорошо бы для Unity3d найти решение распределенных вычислений.
    Можно виртуальную машину на сотнях компах, только не думаю, что это очень оптимально, это скорее универсальное решение.

    #52
    12:12, 29 ноя 2012

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

    #53
    12:36, 29 ноя 2012

    Получилось запустить 4 процесса проекта в background режиме, создающего каждый по 150 копий "машинок" и все работает без проблем, не тормозит вообще!)) Эврика!)

    #54
    12:40, 29 ноя 2012

    Надо только в Unity в настройках Build settings -> player settings указать Run in Background

    #55
    23:36, 29 ноя 2012

    +1 к carmageddon! а еще лучше гибрид с твистед метал.
    был в сети ммо проект auto assault вроде, но загнулся. жаль я даже поиграть не успел. сорри за офтоп.

    #56
    3:02, 1 дек 2012

    Поделюсь своим опытом. Пишем сейчас игру, реализуем третий вариант. Для нас и второй вариант не сложно реализовать, но остановились на стороне меньшей нагрузки на сервер. В этом плане проще, т.к. не использую готовый игровой движок, из готового - только Ogre3D и Bullet. Сервером просчитывается только игровая логика и тесты на идентичность игрового мира..
    Клиент отправляет серверу только команды ползуна,  запрос сервера состоянии мира или событий. Сервер регистрирует команды ползуна и время их срабатывания, так же детектирует лаги. И отправляет эти же команды всем остальным клиентам. Сервер может запросить у клиента любое состояние или дифф с предыдущим состоянием. От полной передачи состояния отказываемся, потому что на каждого перса уже сейчас насчитывается около 200 анимаций, из которых до 10 могут проигрываться одновременно - это довольно большой поток данных.

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

    Состояние клиента будет версионироваться, и в случае неудачи предсказания - откатываться и интерполироваться. В силу специфики нашей игры, лаги даже в 400 миллисекунд не сильно заметны. (Проверено опытным путём) Но рассчитываем игру на лаги не более 100 миллисекунд.

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

    Думаю, что ни что не помешает это реализовать и в юнити.

    #57
    15:48, 11 апр 2013

    Вот очень интересная наработка для начала разработки своей MMO RPG

    Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры

    Прошло более 2 лет
    #58
    6:54, 30 янв 2016

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

    кто-нибудь интересовался связкой Bullet ныне с неплохой поддержкой GPU и серверов с хорошими видеокартами? какой выигрыш можно ожидать? чуть чуть? в несколько раз? или на порядки?

    и существуют ли на постсоветском пространстве хостеры, предоставляющие в аренду выделенные сервера с приличной видеокартой вроде Nvidia Grid / Tesla?

    идея с просчетом физики на клиенте и всякими методиками вычисления честности описанная выше интересная, но такая физика не покрывает областей где нет игроков в данный момент, это очень ограничивает игровую логику на сервере

    так что хотелось бы услышать мнения по поводу Bullet + хорошая GPU. считать предполагается конечно только bounding box-ы, и изредка делать разнообразные рэйкасты.

    Страницы: 1 2 3 4
    ПрограммированиеФорумОбщее

    Тема в архиве.