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

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

Страницы: 1 2 3 4 Следующая »
#0
18:06, 18 мар 2012

В общем-то озвучу мысли которые пришли в голову.
Вариант 1. Использовать саму Юнити в роли сервера
Плюсы - физика уже встроенная, информация обо всем мире такая же как и на клиенте (имеется ввиду вся геометрия и т.д. для просчета коллизий)
Минусы - на самом севрере придется скорей всего использовать Windows Server (придется докупить лицензию и т.д.), не ясен расход с памятью, если использовать теже префабы для обсчета коллизии будут тянуться и текстуры (либо вручную для версии сервера удалять текстуры и т.д. либо искать возможность программно отключать их загрузку), так же не ясно какую нагрузку на процессор будет оказывать такой вариант....

Вариант 2. Сервер писать на специальный серверных движках (либо самописных)
Плюсы - могут работать на Linux подобных системах
Минусы - каким то образом нужно будет получить информации об геометрии объектов и считать коллизии вручную, в данном случае все хорошие феньки встроенные в Юнити по управлению персонажем становятся не доступны (типа CharacyerController придется писать самим с нуля)

Вариант 3. Сервер писать на специальный серверных движках (либо самописных), но просчет коллизий делать на самом клиенте, а серверу посылать обновленные данные,а сервер будет отвечать за пересылку данных о игроках, выдачу миссий и т.д.
Плюсу - малая нагрузка на сервер.
Минус - в том что идея совсем не продуманная и реализация очень сложная / много подводных камней, также недобросовестные игроки смогут легко мошенничать например с координатами перемещения в мире.


С сетью опыт небольшой написал сетевые 2д танчики на Delphi.
Так что советуйте, что кто может, поправляйте меня если ход моих мыслей не правильный....

#1
19:42, 18 мар 2012

Если оно в юнити встроенное зачем переизобретать велосипед? Пользуйся встроенным, виндовые сервера недорого стоят в аренду, покупать полностью серверную лицензию для винды не нужно. Память  недорого стоит.

#2
20:05, 18 мар 2012

kvakvs
Вот толкьо остается проверить запустится ли приложение написанное на юнити на удаленном серваке (там же нет видеокарты)

#3
21:54, 18 мар 2012

Kavis
> Вот толкьо остается проверить запустится ли приложение написанное на юнити на
> удаленном серваке (там же нет видеокарты)
открой для себя опцию -batchmode
http://unity3d.com/support/documentation/Manual/Command%20Line%20Arguments.html

#4
21:57, 18 мар 2012

Kavis
> Использовать саму Юнити в роли сервера
это как? : )

зачем люди изобретали Photon и SmartFoxServer?

> Плюсы - физика уже встроенная
плюс-то он плюс, тока PhysX слабо подходит для рилтайм клиент-сервера потому как бывает нужно подсмотреть/изменить нечто в прошлом

#5
22:37, 18 мар 2012

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

>>зачем люди изобретали Photon и SmartFoxServer?
Если к ним присмотреться то получается то что я  описал выше, почти все феньки юнити отваливаются...
>>плюс-то он плюс, тока PhysX слабо подходит для рилтайм клиент-сервера потому как бывает нужно подсмотреть/изменить нечто в прошлом
Если все происходит на сервере ничего откатывать не придется

#6
15:17, 19 мар 2012

Первый вариант - влоб. Если нужно быстро и не качественно, не оптимизированно, и не сильно развиваемо в будущем, то вариант сносный.
Второй естественно самый нормальный. Дело в том что разработка сетевых игр должна начинаться с продумывания геймплая как сетевой игры. Делать порт сингла, порой является не простой задачей, и во многом не будет возможной в полной мере.
Та же физика - это сложный элемент для сети, и физика в сетевой игре очень "опасный" момент. Заметь, в современных играх стараются максимально избегать количество физ. объектов при этом физика либо простая, либо естественно движок очень мощный в плане сети (например HL2).

#7
15:29, 19 мар 2012

Логика клиента должна дублироваться/валидироваться на сервере. А вообще очень по-разному пишут. Естественно только 2й вариант.

#8
16:41, 19 мар 2012

akaAngeL
> Логика клиента должна дублироваться/валидироваться на сервере. А вообще очень
> по-разному пишут. Естественно только 2й вариант.
Не соглашусь.

Логика клиента проста: визуализировать и отсылать серверу инпут.
Сервер всё вычисляет, и рассылает только нужные для синхронизации данные для последующей визуализации на клиенте.

#9
16:56, 19 мар 2012

MoKa
> Не соглашусь.
> Логика клиента проста: визуализировать и отсылать серверу инпут.
> Сервер всё вычисляет, и рассылает только нужные для синхронизации данные для
> последующей визуализации на клиенте.
И что тут противоречит тому, что я сказал?

#10
17:00, 19 мар 2012

> Вариант 2. Сервер писать на специальный серверных движках (либо самописных)


Самый нормальный вариант.

> в данном случае все хорошие феньки встроенные в Юнити по управлению персонажем становятся не доступны (типа CharacyerController придется писать самим с нуля)

Character Controller в Unity - просто обертка над Character Controller-ом в nVIDIA PhysX. Так что никаких преград нет.


> каким то образом нужно будет получить информации об геометрии объектов

Геометрию можно "спросить" у того же юнити и сохранить в файлы для сервера.

#11
14:55, 20 мар 2012

akaAngeL
> И что тут противоречит тому, что я сказал?
Ты сказал:
> Логика клиента должна дублироваться/валидироваться на сервере.
При этом я считаю что логики на клиенте как таковой игровой нету. И валидировать тем самым нечего, кроме как инпута.

#12
15:54, 20 мар 2012

MoKa
> > Логика клиента должна дублироваться/валидироваться на сервере.
> При этом я считаю что логики на клиенте как таковой игровой нету. И
> валидировать тем самым нечего, кроме как инпута.
Если логики на клиенте нет, то придётся каждый кадр пересылать от сервер клиенту?
Если же клиент на основании каких то состояний объектов считает следующий кадр, что бы например продвинуть вперед на столько то пикселей, то это уже логика :)

#13
11:43, 21 мар 2012

>>При этом я считаю что логики на клиенте как таковой игровой нету. И валидировать тем самым нечего, кроме как инпута.
Видимо ты не имел дело с написанием онлайн игр)

#14
12:50, 21 мар 2012

akaAngeL
> Видимо ты не имел дело с написанием онлайн игр)
Парень вообще-то полностью прав.

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

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