Я звоню на игровой сервер каждые 30 секунд и получаю такой ответ:
{
name: 'test',
map: 'pool',
maxplayers: 12,
players:
[ { deaths: 0,
kills: '0',
ping: 50,
name: 'test',
score: 0
} ],
}
Как можно в console.info что-то вроде этого: "$ {name} присоединился к серверу!" тогда массив из последнего вызова изменится на это, например:
players:
[ { deaths: 0,
kills: '0',
ping: 50,
name: 'test',
score: 0
},
{ deaths: 0,
kills: '0',
ping: 20,
name: 'test2',
score: 0
}
]
Я думал использовать базу данных и сохранить ответ на нее, а затем сравнить с новым массивом из последнего вызова, но я чувствую, что должен быть лучший способ сделать это.
РЕДАКТИРОВАТЬ:
Я не объяснил, что правильно, я использую npm-модуль "gamedig" для получения статистики с игрового сервера Battlefield, у меня нет доступа к настоящему серверу, все, что я знаю, это ip.
Может быть, вы захотите взглянуть на: socket.io
Для таких вещей лучше всего использовать библиотеку. Например, что предлагает @programoholic
JSON.stringigy(firstObject) === JSON.stringify(otherObject) даст вам результат
@diEcho сообщит вам, есть ли изменения, а НЕ кто новые пользователи.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Есть много способов справиться с этим, но в качестве отправной точки я бы порекомендовал не опрашивать ваш сервер каждые 30 секунд и по возможности перейти на систему, основанную на событиях. Опрос не является злом по своей сути или чем-то подобным, но он потенциально может привести к проблемам масштабирования в долгосрочной перспективе и головным болям, связанным с обслуживанием кода, такими как та, которую вы описываете.
Для начала, если вы хотите убедиться, что ваши клиенты не могут внезапно синхронизироваться в середине игры, вам определенно понадобится какая-то база данных для хранения состояния игры. В противном случае любая ошибка или сбой, вызывающие перезапуск серверного кода, очистят состояние игры, и вам не повезло. Вы можете выбрать любой из нескольких, но я бы начал с рассмотрения чего-то вроде Redis или Firebase, в зависимости от того, какой тип сервера у вас есть / вы хотите иметь.
Во-вторых, вы можете легче восстанавливать пропущенные вызовы и тому подобное, если вы оба генерируете события (например, используя socket.io), чтобы сообщить клиентам, когда глобальное состояние игры изменилось, а также сохранять эти события в синхронизированном по времени журнале. Таким образом, если клиент не получал обновления в течение некоторого времени (некоторые игры поддерживают тактовый сигнал от сервера именно по этой причине), он может явно спросить сервер, что он пропустил, и получить набор событий, которые имеют произошло с момента последнего известного обновления. Этот последний бит подразумевает, что каждое отправляемое вами сообщение включает отметку времени, когда оно годно, поэтому вы можете просто игнорировать то, что произошло до вашего последнего обновления. Уникальные идентификаторы событий также очень полезны для отслеживания того, какие события вы уже обработали или нет.
РЕДАКТИРОВАТЬ
Итак, учитывая, что у вас нет серверной части для работы, вы действительно ограничены в вариантах. Я бы подумал, что лучше всего тогда преобразовать данные так, чтобы вам было легче обнаруживать изменения, например, например, хэш на основе имени пользователя:
const users = {
'user1': { deaths: 0, kills: 0, score: 0 }
'user2': { deaths: 1, kills: 5, score: 3000 }
}
Затем при каждом ответе сервера вам нужно будет просто проверять наличие каждого пользователя в массиве:
// serverUsers is whatever collection of users you get back in your poll
const newUsers = serverUsers.filter(u => Object.keys(users).includes(u.name));
Очевидно, что обнаружение игроков, переходящих в автономный режим, аналогично, только делается в обратном направлении, когда вы видите, кто находится в коллекции «users», а не в коллекции «serverUsers».
@ Джейси, хорошо, обновлено. Я оставил там оригинал на случай, если он кому-то пригодится в будущем.
Я бы вел журнал событий в базе данных сервера (сервер знает, что присоединился новый игрок, не так ли?) Тогда вам не нужно различать состояния, но вы просите сервер отправлять все соответствующие события новее, чем X.