UEngine.Ru

Добил таки это дело.

Для чего GameSpark (своими словами).Реализация мультиплеера без необходимости поднимать свой выделенный сервер. Очень удобно для небольших игр на мобильные и рс платформы если нужна аутентификация, таблица лидеров или какой либо кооперативный режим игры. Как показал мой пример можно использовать и в задумках типа ммо (по схеме dota wot думаю потянет без проблем(имеется виду стиль и тип игры а не глобализм). Описать всё очень сложно продукт очень серьёзный. Есть документация,примеры и демки для UE4. Признаюсь честно я долго разбирался в этом всём чтобы склепать эту демку. Сейчас обновили и плагин и SDK под новые версии так что всё намного проще.(хотя демки остались под старые версии).


Что реализовал:
Аутентификацию, обработку событий(например актёр подобрал предмет), сохранение и загрузку позиций(при входе выходе из игры), управление персонажем(немного даже оптимизировал канал использует совсем чуть чуть). Всё это обрабатывается и хранится на серверах GameSpark.



Есть желание продолжить эту тему реализовать инвентарь, кошелёк ну и конечно что либо из физики например стрельбу. Сейчас нужно бы сделать какую либо локацию, но у меня под это руки совсем не заточены да и вообще мало чего в этом понимаю.
_________________
Project SKIT

Я бы с удовольствием помог в плане моделинга, Я к примеру не очень понимаю в программировании даже в блюпринтах раставлении всего по блокам, но все же, Я очень увлечен своим проектом, буду продолжать толкать его, а за твоим проектом Я охотно послежу))

как продвигаются познания геймспаркса?) ищу человека которого можно поспрашивать как там что)

Нормально продвигаются)). Участвую в разработке space MMORTS UE4+GameSparks.
Поспрашивать можно здесь. Чем смогу помогу.
_________________
Project SKIT

вот и первый вопрос - как реплицировать физический обьект =)
для примера футбольный мяч - я пока допер только до такого варианта -
1- начинается матч
2- изначально отдаем право управления мячом любому игроку (у меня этот пир1 в массиве игроков) тот кто пир 1 говорит своему мячу начать симуляцию физики, и начать отпралять пакеты с трансформом мяча всем остальным игрокам, они позиционирует свой мяч через сет актор локейшн итд.
3- если кто то из игроков касается мяча - то он высылает всем пакет что теперь он "хозяин" мяча и включает у себя симуляцию физики мяча и отправку пакетов с трансформом всем остальным, (тот кто до этого был хозяином (пир1) выключает у себя симуляцию физики и начинает обновлять положение мяча как и все остальные).

есть ли более разумные варианты?

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

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

Вы реально(как и многие) путаете понятия выделенный сервер и сервер обработки данных. Ни какой физики на спарковском серваке нет, как и экземпляра вашей игры. Да и вообще использовать реальную физику для перемещения акторов или вообще для чего угодно координатно важного, в сетевых играх- не лучшая идея. Физика считается на разных компьютерах немого по разному. В случае с уе4 для снарядов используйте или projetileMovement или таймлайны для ручной так сказать анимации. С мячом примерно тот же вариант. Никакого включает у себя симуляцию физики мяча
использовать не нужно. Геймспарк это событийно ориентированный сервер. Т.е. логика действий такая нужно просто управлять своим игроком и транслировать команды управления другим членам матча. Причём именно команды, а не координаты эктора. Координаты можно проверять пару раз в секунду для корреляции ошибок.
В спарке есть пример сетевого тетриса, если вы разберётесь как там всё работает то и смысл работы сервера спарка будет вам понятен.
Футбол, конечно казуалка , но всё же, уже был опыт создания(я только сетевой частью занимался) вот видос https://www.youtube.com/watch?v=HnC3_Uu0ifU
_________________
Project SKIT

ну чтож) видимо я коряво выразил свою мысли) попытка номер 2

на счет гейм спаркса - я знаю что там нет копии игры, и он просто пересылает пакеты с данными между игроками в матче) один один отправил - ушло на геймспаркс и от туда разослалось остальным игрокам.
но он также может и сам заставить делать вашу игру опреденные вещи, в fps-battle-royal-template (ссылка есть ниже) именно геймспарксовый реалтайм скрипт отвечает за сужени безопасной зоны

по поводу физики - её у меня единовременно использует только 1 игрок ( тот кто тронул мяч последним) и рассылает осальным пакеты с текущей позицией и вращением, остальные игроки в свою очередь через сет эктор ротейшн и сет эктор локейшн задают ему (мячу) положение у себя.

по поводу снарядов - как сделать сами снаряды и заставить их делать то что мне нужно я знаю) вопрос как их лучше их реплецировать?
у меня пока только 1 вариант:
по аналогии с мячом - игрок стреляет -> спавн снаряда -> отправить пакет (игрок №3) создание снаряда по таким то координатам -> у игроков получивших этот пакет создается своя копия снаряда привязанная к игроку №3 -> далее функция находящяяся в снаряде у игрока №3 начинает рассылать всем пакеты о положении этого снаряда

-----
Геймспарк это событийно ориентированный сервер. Т.е. логика действий такая нужно просто управлять своим игроком и транслировать команды управления другим членам матча. Причём именно команды, а не координаты эктора. Координаты можно проверять пару раз в секунду для корреляции ошибок.
не поясните почему? я не разбирал тетрис, но вдоль и поперек изучил вот этот вариант - https://www.unrealengine.com/marketplace/fps-battle-royale-template?prox=1 и что касается положения персонажей тот там высылаются именно координаты (вращения, позиция, ускорение, и питч(тот что мышка вверх)

к сожалению там нет ни снарядов типа ракет или гранат, ни физических обьектов, поэтому и решил поискать ответ здесь)
PS - описанный мной в первом посте метод реплики физического мяча работает нормально (отправки пакетов 10 штук в сек, 20 тоже держит нормально)

Как делал я ))). Принт своего игрока и противника один и тот же. Когда через плеерконтроллер игрок получает команду ударить по мячу мы вызываем соответствующую функцию в принте игрока и одновременно с этим отправляем вызов этой функции по средствам rtm op code остальным игрокам. У них соответственно тот игрок что мой для них он противник, получает туже команду что и у меня на локальной машине. Если у вас всё верно и мяч на всех клиентах находится в одном и том же месте и игрок соответственно бьющий его тоже синхронизирован, мяч на "клиентах" получит тот же импульс и тоже направление что и у вас, конечно из за разности в расчётах нужно корректировать полёт мяча на клиентах.
Вся работа со спарком заключается в вызове соответствующих функций управления через сеть причём они должны идти также как вызывались бы из плеер контроллера. Я в той демке что выше именно так и делал, там отправка команды происходила прямо из плеер контроллера, т.е. я реализовал как бы дистанционное управление своим игроком на машинах соперников, а не передавал постоянно данные о их местоположении.


P/S к сожалению я умудрился удалить эту демку что выше. Но на форуме спарков я кое что тогда объяснял показывал https://support.gamesparks.net/support/discussions/topics/1000081793
_________________
Project SKIT

у меня тоже принт игрока и противников одно и тоже), правда я передаю именно координаты так-как персонаж активно двигается в трех измерениях+различные скольжения итд, в общем информации только об инпутах не достаточно, а тут жесткая привязка к точке, ну и работает естественно как и у вас через "OPCode"
с персонажами проблем нет)))
вопрос в мяче) - в принципе работает - находится почти у всех одинаково (инет задержка всё же)


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

ну и копипаста на вопрос о авторитарной физике на геймспарксе - We don't have any special support (or restrictions) for physics as such but as it is essentially maths you could try to implement it yourself. Cloud Code scripts have a default timeout of 30 seconds so as long as your calculations come in under that (I assume they would to keep the game moving as quickly as possible) you should be ok to do this.

1.Нет , ну понятно что с помощью математики можно посчитать физику и на спарке, но это однозначно сложно сделать и дело не в знании скриптов спарка(это обычный java script) а именно в самой математике расчёта, в уе это делает здоровенная штука PhysicX, неужели вы хотите её портировать или как то эмитировать на сервере?

2.Насчёт критичности элемента, ну если умельцы смогут сломать это https://ru.wikipedia.org/wiki/TLS то конечно , да и то там всё хитрее, не просто TLS. И всегда можно добавить что то от себя я имею ввиду шифрование.

3.И вот как раз из за того что игрок активно двигается как раз и нужно снимать данные с плеер контроллера ну или непрерывно отсылать данные о координатах, но я слабо себе представляю такие массивы данных без лага. А вот человек на самом деле нажимает на клавиши не так уж и быстро. Оптимальный как по мне вариант снимаем данные с контролеера и отправляем вместе с текущим трансформом что бы одним пакетом.
Ещё одна хитрость ))) не нужно пытаться контроллер опрашивать в эвент тике, нужно смотреть только на изменение состояния т.е. первое событие нажал потом ещё событие отпустил, а между ними ничего. На клиенте обратная ситуация имитация нажатий как раз должна быть в основном лупе.
_________________
Project SKIT