Контакт с задержкой в сетевых играх
На самом деле это не ответ, а расширенный комментарий к комментарию вопроса OP: «ну, вы можете передать массив, не зная количества строк с этим, но тогда как вы узнаете, когда прекратить печать строк?»
Ответ: как правило, вы не можете, не передавая размер массива тоже. Посмотрите на этот 1-D пример, который разбивает размер массива.
#include <stdio.h>
int procarr(int array[16], int index)
{
return array[index];
}
int main (void)
{
int arr[16] = {0};
printf("%d\n", procarr(arr, 100));
return 0;
}
Вывод программы (хотя все элементы, инициализированные на 0):
768
Это было неопределенное поведение и не было предупреждения о компиляторе. C не обеспечивает защиту от переполнения массива, за исключением инициализаторов определения массива (хотя такие инициализаторы могут определять длину массива). Вы также должны передать размер массива, как в
#include <stdio.h>
int procarr(int array[16], size_t index, size_t size)
{
if (index < size)
return array[index];
return -1; // or other action / flag
}
int main (void)
{
int arr[16] = {0};
printf("%d\n", procarr(arr, 100, sizeof arr / sizeof arr[0]));
return 0;
}
Выход программы:
-1
4 ответа
Выезд, как Клапан делает это в Исходном Механизме: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
, Если это для шутера от первого лица, необходимо будет, вероятно, копаться в некоторых темах, как которые они упоминают, такие: прогноз, компенсация и интерполяция.
Выезд Сетевые образовательные темы в веб-сайте Клуба Создателя XNA. Это копается в темах, таких как сетевая архитектура (одноранговый узел для пиринга или клиент/сервер), Сетевой Прогноз и несколько других вещей (в контексте XNA, конечно). Это может помочь Вам найти ответы, которые Вы ищете.
http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1
You could try imposing latency to all your clients, depending on the average latency in the area. That way the client can try to work around the latency issues and it will feel similar for most players.
I'm of course not suggesting that you force a 500ms delay on everyone, but people with 50ms can be fine with 150 (extra 100ms added) in order for the gameplay to appear smoother.
In a nutshell; if you have 3 players:
- John: 30ms
- Paul: 150ms
- Amy: 80ms
After calculations, instead of sending the data back to the clients all at the same time, you account for their latency and start sending to Paul and Amy before John, for example.
But this approach is not viable in extreme latency situations where dialup connections or wireless users could really mess it up for everybody. But it's an idea.
I find this network physics blog post by Glenn Fiedler, and even more so the response/discussion below it, awesome. It is quite lengthy, but worth-while.
In summary
Server cannot keep up with reiterating simulation whenever client input is received in a modern game physics simulation (i.e. vehicles or rigid body dynamics). Therefore the server orders all clients latency+jitter (time) ahead of server so that all incomming packets come in JIT before the server needs 'em.
He also gives an outline of how to handle the type of ownership you are asking for. The slides he showed on GDC are awesome!
On cheating
Mr Fiedler himself (and others) state that this algorithm suffers from not being very cheat-proof. This is not true. This algorithm is no less easy or hard to exploit than traditional client/server prediction (see article regarding traditional client/server prediction in @CD Sanchez' answer).
To be absolutely clear: the server is not easier to cheat simply because it receives network physical positioning just in time (rather than x milliseconds late as in traditional prediction). The clients are not affected at all, since they all receive the positional information of their opponents with the exact same latency as in traditional prediction.
No matter which algorithm you pick, you may want to add cheat-protection if you're releasing a major title. If you are, I suggest adding encryption against stooge bots (for instance an XOR stream cipher where the "keystream is generated by a pseudo-random number generator") and simple sanity checks against cracks. Some developers also implement algorithms to check that the binaries are intact (to reduce risk of cracking) or to ensure that the user isn't running a debugger (to reduce risk of a crack being developed), but those are more debatable.
If you're just making a smaller indie game, that may only be played by some few thousand players, don't bother implementing any anti-cheat algorithms until 1) you need them; or 2) the user base grows.