Войти
ПрограммированиеФорумСеть

Мастер сервер и с чем его едят?

Страницы: 1 2 3 Следующая »
#0
19:17, 20 июня 2018

Доброго времени суток, уважаемые. Обращаюсь я к вам сегодня за советом.

Занимаемся мы с товарищами написанием небольшой пошаговой сетевой игры с гексогональным полем.
Пишем на Unity и основной каркас уже готов, вот только упёрлись в выбор того, на чём писать итоговый вариант сервера.
Вот и пришёл я сюда с надеждой, что, вы, господа, сможете пояснить мне за возможные технологии, их плюсы и минусы.

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

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

Итоговый вопрос крутится вокруг того, на чем же нам лучше делать сервер?
Какой-то готовый серверный движок? kbengine? NoahGameFrame? Nakama? BigWorld (его вообще получить ещё можно)? Свой сервер на C++? И присыпать всё это сверху логикой на скриптовом языке? 
Или может быть использование C#? И сервер на нем и игровую логику?

Вариантов много и многих я даже не знаю. Надеюсь, что кто-то из читающих сможет подсказать.


#1
20:02, 20 июня 2018

Только хардкор. Только С++. Его можно оптимизировать до предела.

#2
20:12, 20 июня 2018

ardru
т.е вообще всю логику на плюсах пидалить в том числе и игровую?
Или сервер на плюсах, а логика на том же питоне? И есть ли смысл писать сервер, может готовое что-то на плюсах уже есть?

#3
20:34, 20 июня 2018

Можно вообще всё на плюсах писать, как в UE4. По сути, скрипт нужен только для того, чтобы левел-дизайнер мог что-то сам сделать.

#4
20:45, 20 июня 2018

ardru
А есть ли вообще какая-то принципиальная разница какой язык использовать?

#5
21:08, 20 июня 2018

зависит от типа игры. Текстовый онлайн квест можно и на PHP писать, а вот для оффлайн игр PHP не очень подходит.

#6
21:29, 20 июня 2018

Конечно C#, остальное прошлый век ...

#7
0:30, 21 июня 2018

Germes
Мы используем Master Server Framework для Unity

#8
2:10, 21 июня 2018

Germes
> на чём писать итоговый вариант сервера
а чем фотон не устраивает? : )

#9
6:37, 21 июня 2018

С# и Java отлично подойдут для написания отдельного сервера. Если игра пошаговая, то можно даже не запускать экземпляра вашего приложения на сервере, проще вынести логику для проверок в отдельную библиотеку, и использовать её на сервере и клиенте. Выбирать стоит то, к чему душа лежит. Сам писал сервера на них и колоссальной разницы не заметил. Плюсы, конечно, можно хорошо оптимизировать, но только если есть хороший опыт за плечами, особенно с сокетами. Без него, возможно, выйдет даже хуже. Но если очень хочется, то можно взять Raknet (также есть возможность обертки через swig под C#), в нем уже реализован весь основной сетевой функционал и даже больше.

#10
8:26, 21 июня 2018

Sh.Tac.
> а чем фотон не устраивает? : )
Так я не говорил, что не устраивает) рассматриваем варианты просто.
Сейчас понятно одно - сервер нужно переписать почти с нуля.

Соответственно появился вопрос, а стоит ли продолжать использовать фотон или может есть более производительные варианты)
Например, при онлайне в 100 человек, уверен, разницы не будет, а если 10 000? а 100 000?  D:
Мы, конечно, реалисты) но всё равно, не хотелось бы потом ещё раз всё переписывать в стрессовом режиме

ardru
> зависит от типа игры.
Ну, я уже говорил в шапке - у нас пошаговая игра на гексагональном поле)

DoomGod
> и использовать её на сервере и клиенте.

Серверу же, наверное, всё равно нужно хранить информацию о текущем состоянии поля и всех элементов на нём.
У нас есть настройки для разных юнитов, которые хранятся в скрипт объектах и при валидации сервер должен учитывать все эти настройки.
Например, какой-то юнит может ходить на расстояние 5 клеток, а какой-то 4. И даже если клиент хакнут и заставят отправить шаг на 5 клеток, сервер должен послать его нафиг и сказать, что операция не валидна.

#11
10:00, 21 июня 2018

Germes
Про клиент я к тому что-бы в случае одиночной игры можно было делать эти проверки и не дублировать код.
А для чего серверу держать в памяти столько клиентской информации?

x = {move_radius: 1}
o = {move_radius: 3}

field = {
  1:{1:{o}, 2:{o}, 3:{o}}
  2:{1:{_}, 2:{_}, 3:{_}}
  3:{1:{x}, 2:{x}, 3:{x}}
}
Этой информации серверу достаточно что-бы понять что x из 3:3 не сможет пойти в 2:1. Тогда для чего ему всё приложение?
Просто нужно вынести необходимые классы в отдельный пакет и использовать его. 
#12
10:24, 21 июня 2018

DoomGod
> Про клиент я к тому что-бы
Одиночной игры как таковой не будет. Даже PvE работает на сервере, т.к. за него выдаются плюшки, которые записываются в аккаунт.
Если оставлять какую-то логику на клиенте, то её можно будет взломать и набить себе сколько и чего угодно.
Его логика должна использоваться исключительно для отображения игроку того, что он может сделать, но т.к. все настроечные файлы на клиенте можно взломать и переписать - конечный вердикт выносит сервер.

DoomGod
> Этой информации серверу достаточно что-бы понять что x из 3:3 не сможет пойти в
> 2:1.

Достаточно, если мы делаем PvP шашки с авторитарным сервером, где все сущности - шашка) а если делать игру с большим количеством сущностей, то серверу нужно знать, кто именно стоит в 3:3.
Если в 3:3 стоит гном, у которого длинна шага 1 клетка, то он должен отвергнуть попытку игрока передвинуть его в клетку 2:1.
А если там стоит какая-нибудь гарпия с дальностью шага в 3 клетки, то сервер должен провести эту операцию и разослать клиентам команду на её отображение.

Вот и получается, что настройки эти должны быть и на сервере для расчётов и на клиенте для отображения игроку чего он может собственно сделать.

#13
10:37, 21 июня 2018

Сервер нынче можно написать на любом высокоуровневом языке из топа.

Если у вас цель "сделать игру" стоит первее чем "получить фан", то рассматривайте только движки на тех технологиях, которые знаете.

Если совсем нет опыта в геймдеве и в серверах, по производительности особо не загоняйтесь - сначала сделайте, потом (с помощью нового опыта) сможете уточнить требования и технологии.

Фотон и прочиее saas не рекомендую - дорого, что пипец. Они берегов не знают. Но если игра небольшая и для друзей, то можно и на saas делать. Если планируете небольшую денюшку зарабатывать, то берите какие-нибудь dedicated сервера, например, у того же Hetzner. Если большую денюшку планируете, то смотрите большие облака, которые железки дают.

Не пишите сервер на C++, если не знаете ТОЧНО, что делаете. Максимум, на нём можно написать логику матча и сделаь биндинги на более гибкие ЯП.

Не забудьте, что кроме самого сервера матчей, требуется ещё обвеска вроде регистраций, рейтингов, рассылок почты, личных сообщений, лобби и прочих штук.

Далее сугубо моя религия:

- Не понимаю зачем писать сервера на Java и С#, по-моему это ересь.
- Пишите на Python, если планируюется сложная логика сервера и её частое изменение - он очень гибкий и достаточно быстрый.
- Пишите на Go, если логика простая, как пробка.

#14
10:39, 21 июня 2018

Germes

Да и к тому же:
> Например, при онлайне в 100 человек, уверен, разницы не будет, а если 10 000? а 100 000?  D:
100 000 игроков, 1vs1, 50 000 экземпляров? Или 1 экземпляр и 50 000 полностью инициализированных "полей"? Даже есть запускать с каким-нибудь ключём —no-graphic, в любом на сервере будет лежать куча неиспользуемого хлама.

> серверу нужно знать, кто именно стоит в 3:3.
Пожалуйста, допустим:

gnome = {move_range: 1, damage: 2, health: 10} //это данные из ваших настроек
x = {class: gnome, owner: player_one, current_health: 9, count: 5, position: {x:2, y:1}}

harpy = {move_range: 3, damage: 3, health: 6} //это данные из ваших настроек
o = {class: harpy, owner: player_two, current_health: 2, count: 4, position: {x:1, y:2}}
Не суть ведь. Клиент скажет, хочу передвинуть юнита из 2:1 в 2:3. Сервер посмотрит кто там стоит передвинет если надо. В данном случае пошлёт лесом.

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумСеть

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