Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Because if the P2P system works the way it finds one player to be server, that player HAS to be stable. If it is like BitTorrent without a servernode it requires too many confirmations to be responsive and stable. If you know anything about networking, or even better networking in games, you would know that P2P is a bad system for games like this.
I guess a C/S network architecture would be the right way to do it, but I can see why the devs chose a P2P model.
Firstly, it is a very viable network solution for games where matches involve small number of players (in this case, 4), and secondly, it saves them a server bill, which is a great advantage for and indie dev studio.
Apart from the latency that OP mentioned as a con from P2P, another major drawback of the P2P networking model is there is no effective way to prevent players from cheating, which is a crucial point for a competitive game like this.
Exactly. I understand why they're using P2P, as it's much much cheaper. I was just hoping that maybe if they make enough money they can have servers for ranked games at least. Or an easier hosting and joining mode. That for example I can host, knowing that most people will have as good connection as possible in my region.
This is one of the biggest reason the connection is problematic. The camera is going back and forth in front and behind us.
Right now there are some fixes in the pipeline which should solve the issue shown in the screenshot.
We're also working on a general in-game player stat screen which displays information such as rank and ping of players. This also presents a nice space to do things like muting players or cheater reporting.
As far as cheating goes, any network architecture is open to cheating in various degrees and ways. Our approach therefor is not to start the technology cat and mouse game between developers and cheaters. But opt for a reporting system instead, which would allow us to eventually put cheaters in their own little cheaters league.
Thanks for responding and I'm sure I won't be alone to appreciate the additional information. As for private lobbies goes, is it always the "host" which is the server? Info like that is greatly appreciated as well. A really fun game when everything goes as planned.
Maybe you've got plans to change the servernode dynamically to keep the average ping as low as possible, or something like that.
I've got high hopes and I'm sure the game is only going to get better.
It's a misconception that a server-client architecture would make things better in terms of latency. If anything it makes it worse. Now all peers have a direct (shortest) connection with each other, having a server-client architecture would cause all traffic to go through a server which always makes the route longer.
There is an exception to this. When two peers are unable to connect with each other, all traffic will be routed through valve servers. This situation can be handled better. A solution will be implemented in the next major update (r31). After that there are some other optimizations I'd like to try to make the laggy situations more uncommon (reduced packet count, reduced bandwidth use).
If I understood the model you're using one clients acts server (Rather than all clients connecting to all clients), and if the said server has a very low bandwidth or high latency it will affect all players in the lobby.
I'm really looking forward to the optimizations in r31. Just one more question about this subject: Have you been thinking about integrating the server and the client more, in order to swap who's who more easily. This could possibly mean a lot of work, depending on the code structure at the moment. But if the client and server are based on the same base, polymorphic structure would make that very possible.
The reason is to dynamically fix "server-lag".
Thank you, Gert-Jan for actually looking into forums and caring about the community/customers. Time to craft that badge for extra $$$ for you.