robotcity
> ты приписал мне чужой коммент
извини, сам не понял как ты попал туда )
greencrazycat
> сервер даёт "Petja" инфу вообще не дергая БД - т.к. вся эта инфа у сервера есть
где ?
greencrazycat
> что нужно знать новому игроку "Petja" который подключился ?
> 1. где находиться сейчас игрок "Vasja" и что у него есть камень
> 2. модель мира во всеми камнями которые есть в мире
1. - все верно
2. - а тут есть варианты - не модель мира со всеми камнями, ведь отключаясь Петя знал, что было с камнями на день 120-й .... и ему надо лишь знать что с ними случилось на день 122-й
tac
> Просто для клиента модель мира можно обновлять не целиком, а локально вокруг
> игрока (это тот скажем так 3 подход, на который указали говоря о майнкрафте)
ну как бы да - из коробки это есть в uNet, smartfoxserver (про photon не знаю)
ну либо свои велосипеды писать на том что есть
robotcity
> если у тебя мир имеет карту статичную и камни которые можно таскать, то
> статичную карту передавать не надо, а камни передавать чанками
правильно я понял, что есть чанка? набор камней вокруг игрока скажем на радиус его видимости * koef, где koef - запас на движение и обновление.
tac
> ведь отключаясь Петя знал, что было с камнями на день 120-й .... и ему надо
> лишь знать что с ними случилось на день 122-й
клиент всегда врет и всё забыл (а если что то помнит - читер)
сервер знает все про Васю, хранит в БД и отдает готового васю игроку Васе при авторизации - зачем усложнять ?
greencrazycat
> либо свои велосипеды писать
только так :)
greencrazycat
> клиент всегда врет и всё забыл (а если что то помнит - читер)
аргумент про безопасность я помню, лучше пока оставить в стороне ... (никто не мешает время от времени парсить логи на сервере, но не в момент активной игры, и выборочно сверять с данными клиентов)
greencrazycat
> зачем усложнять ?
ну скажем так, с толстым сервером - все понятно то ... главный аргумент нагрузка на сервер, в то время как тонкий клиент на мой взгляд даст СУЩЕСТВЕННО меньшую загрузку - он просто перекидывает данные об изменениях в мире и все.
Ну и потом, решение с толстым сервером - предполагает знание об бизнес-правилах самой игры, в то время как тонкий сервер - этого не требует.
tac
> главный аргумент нагрузка на сервер
где именно нагрузка ?
в передаче состояния мира которое и так есть на сервере без всякого БД 1 раз при подключении нового игрока ?
greencrazycat
> в передаче состояния мира которое и так есть на сервере
откуда оно там взялось? чтобы получить состояние мира на сервере - надо изменения о которых говорят клиенты парсить, находить где там координаты камня, что это за камень и много чего другого
"20:30 камень id122334 взял персонаж id12"
"20:34 камень id122335 выкинут в координатах 105, 257"
Чтобы получить состояние надо понять эти сообщения на сервере, и составить состояние
На 20:20
"По координатам .. лежит камень id122334"
На 20:35
"По координатам 105, 257 лежит камень id122335"
Ну, и есть убийственный другой аргумент )
Толстый сервер плох тем, что он не может руководить ботами в полной мере в определенной ситуации. Представим что у нас есть карта высот поверхности, но она есть только у клиента, т.к. там она нарисована. Теперь мы хотим, чтобы бот выкинул камень идя через каждых 10 метров. Но на какой высоте? На той на которой находится поверхность. Или мы затянем карту высот на сервер, что совсем не нужно, или собственно логика бота будет реализовывать на клиенте, и сервер просто получит от него уведомление как и от другого игрока. Обобщая - сервер не обладает полноценной информацией о мире, поэтому ему затруднительно в ряде вещей создавать состояние мира. В общем виде, на сервер придется перетащить всю физику мира, а зачем?
tac
> Чтобы получить состояние надо убрать понять эти сообщения на сервере, и
> составить состояние
ну может я не догоняю :)
есть сервер
есть объектная модель мира (в памяти сервера)
в модели есть камни
камни могут либо быть у игрока либо лежать в координатах
ситуация :
игрок Вася поднял камень id122335 и уведомил об этом сервер
сервер поменял модель мира и пометил что камня нет в мире и камень есть у Васи
зашел Петя
сервер рассказал Пете что в мире есть камни которые лежат по координатам ... (массив данных)
и что в мире есть Вася у которого за пазухой спрятан камень id122335
теперь Петя может у себя восстановить модель мира и добавить туда Васю с камнем за пазухой :)
greencrazycat
> ну может я не догоняю :)
ну, для толстого сервера все так ...
мы же говорим о сравнении с этим в альтернативе тонкого сервера. А там все проще - сервер не занимается моделью "сервер поменял модель мира и пометил что камня нет в мире и камень есть у Васи", вместо этого он просто записал в лог "20:30 Вася поднял камень id122335" (при этом даже не разбирал содержимое, не парсил)
зашел Петя
он играл до 19:00 и все прекрасно знает где какие камни
от сервера он лишь запросит что случилось с 19:00 и получит от сервера
"20:30 Вася поднял камень id122335"
обновит свою модель мира и пойдет играть
tac
> "20:30 Вася поднял камень id122335"
> обновит свою модель мира и пойдет играть
ага - тока если этот камень гулял по миру от Васе к Коле, потом к Даше с Машей а потом еще у кого то
и бедный Петя начинает восстанавливать историю камня в мире по логам
а потом вдруг оказалось что логи противоречат друг другу и камень у Маши и у Пети и у Васи одновременно :)
mciv
> Если в мире мало камней, но при этом их постоянно швыряют игроки, то записей
> логов во 2-м варианте окажется больше, чем записей о координатах камней в 1-м.
а вот это похоже критерий ... давайте оценим
Пример 1. есть 1000 деревьев в лесу, любое из них можно срубить ... играют 10 игроков, строят дом - ну думаю в 1 сек. изменяться не более 10 деревьев (1%) ... в каком случае начнет выигрывать толстый сервер? по мне так никогда )
> Если в мире мало камней, но при этом их постоянно швыряют игроки
если в мире чего то мало, то при равномерном распределении этого вероятность что игроки будут к этому иметь постоянный доступ стремится к нулю
greencrazycat
> ага - тока если этот камень гулял по миру от Васе к Коле, потом к Даше с Машей
> а потом еще у кого то
> и бедный Петя начинает восстанавливать историю камня в мире по логам
все верно.
Но тут есть варианты.
1. Петя может спросить у того, кто онлайн что с камнем ?
2. Камень в базе данных Пети имеет ID и ему можно читать лог с последней записи и назад (получив, что с ним что-то произошло, дальше уже не интересно, что было раньше)
2.1. Впрочем наверно такой уровень обработки можно сделать и на сервере, чтобы не передавать по сети логи в случае если кто-то постоянно перекладывал один и тот же камень
Тема в архиве.