|
If that's the case, then there's likely a server-side queue that builds up commands if they fail sending, up to a certain point where the player is finally dropped for good. This is a poor way to implement a proper reconnect feature because it's a major security vulnerability. If you let the servers queue commands for disconnected players indefinitely, a malicious user could attack the server infrastructure by constantly connecting and disconnecting from games, or matching with collaborators and letting a game run indefinitely with a few players disconnected until the server runs out of memory. This is actually probably a problem with the observer system too, since the server is likely just storing a replay file and serving it to users. I wonder what they've implemented to prevent neverending games from consuming too much memory.
There's also the fact that this method would only work for minor internet outages like the one you described, where you've lost connection but are still physically in the game. If you crash or close out of the game, you will lose the game state and those queued commands will be useless. |
CoH doesn't have a central server that stores the game state like CSGO, Dota 2, or LoL. It's a deterministic simulation engine, which means every player is essentially running a separate instance of the game that's guaranteed to be exactly the same as every other players' instances. That way the battle servers only have to relay commands, since logic dictates that if all players are running identical game states, issued commands will give the same outcome for all players. That means reduced bandwidth, reduced latency, reduced server hardware requirements, and reduced replay file sizes.
Other RTS games like SC2 work around this by providing a play from replay option, where you can load a replay and resume the game at a predetermined time before the disconnect occurred. The problem with this approach is it requires every player to have a copy of the replay file; essentially, it's only ever used for tournaments, and it's impossible to reconnect in regular matchmaking.
Battle servers are storing a bit of game state information now, since the observing system is really just server-side replay generation. However, converting these replays into a means of reconnecting to a game is likely extremely difficult and not really practical in reality. It would also rely on additional features like pausing, which CoH lacks.
Until server-side RTS design becomes commonplace (which might never happen), reconnect from replay is the best you can realistically hope for here.
That's exactly the data that goes into a replay. I wouldn't call that huge. there's also playback of course that your pc should do and I have no idea how much faster than the replay's 8x it could go
The CoH engine runs at 8 ticks/second, so 8x is the fastest speed you will ever be able to watch a replay at. |
Minimap/tactical map for most movements with edge panning for small adjustments is the most efficient method because it's extremely fast and it frees up your left hand entirely to make use of control groups and hotkeys. There's a reason every single proper professional RTS player uses that method.
A few good resources regarding mechanics and control in RTS games:
https://www.youtube.com/watch?v=RUohpQKVf_A
https://www.youtube.com/watch?v=yP-Sm9QkdHo |
|
That makes more sense, but it's still drastically more expensive than simple command passing, and it scales terribly once you start considering anything beyond 1v1 because you have far more data to send and exponentially more calculations to make. |
|
But why, as a game developer, would you write two completely different versions of your netcode? It's impractical. Not only would you waste a lot of money on essentially duplicating code, but you would have to absorb the increased cost of running the game in a client-server environment. You would, right off the bat, need better servers and more bandwidth because even the most basic client-server setup is going to use more CPU power and bandwidth than simple message passing.
And what do you do about custom games? Do they use battle servers? If so, now you're maintaining two separate groups of servers that do essentially the same thing. Do they use straight P2P? Then you have hacking in tournaments. Do they just use this new server config? Then you need even more of the more powerful, more expensive servers to handle your load.
Then you have to worry about line-of-sight calculations on the server. This wouldn't really reduce bandwidth all that much, since the clients would still have to send you all of the information on all of their units every tick; still much more expensive than simple command passing. Then you would have to perform calculations on that data, and finally you would have to send the relevant details to the clients. No matter which way you slice it, you're suddenly forced to dedicate substantially more server resources to every single player in a game.
The simple fact is, something like that will never happen because no company is going to produce one version of netcode for ranked play and another for unranked play, because that's insane. So the only viable client-server setup is to make everything client-server and pony up for your substantially increased server costs. If a company like Blizzard didn't think that was worth it, you can bet a company like Relic won't think so either. |
Your suggestion is very strange. CoH2's approach isn't odd, it's actually fairly standard; Blizzard did the same thing with SC2.
As for why client-server is impractical in an RTS...
RTS games have to keep track of exponentially more entities than an FPS. Destructive and dynamic cover in a game like Battlefield actually isn't all that demanding for a server because it's structured. You can't just destroy anything, and everything you can destroy is set up to be destroyed in certain ways. All the server needs to do is keep track of the destructible entities and their current states, then refer to those states when making hitbox calculations.
In an FPS, you rarely have more than 128 players in a single server (competitive games usually only have 10-20, depending on the title). That means the server only has to keep track of the locations of 128 entities, and calculate hitboxes on those entities. It also only has to send very limited player data, such as location and player action (firing, reloading, changing weapon, etc.). Even though FPS games usually run at a significantly higher tickrate than RTS games (CoH's simulation engine runs at around 8 ticks per second, compared to between 64 and 128 ticks per second for CS:GO games), it still uses significantly less bandwidth than an RTS that has to transmit location, health, entity, and action data for potentially hundreds of different units.
This is a big problem in a game like Starcraft where players often control over 100 units late in games. If both players had 100 units to command and the game was running at 8 ticks per second, the game would have to transmit and receive 1600 (100 units * 2 players * 8 ticks/second) units of information per second. Compare that to a 1v1 in CS:GO, where at 64 ticks/second the game would only have to transmit/receive 256 units of information (note for games like Battlefield, where the tickrate is far lower than that of Counter-Strike, the difference would be even greater).
That's 6.25x the bandwidth being used in the RTS compared to the FPS in order to accomodate the same number of players. Now if we look at things from the CoH perspective and use 15 or so units per player instead of the large numbers typical of traditional RTS games, we can get the bandwidth down to something approaching that of an FPS. However, we still have to consider the cost angle.
Dota 2 is structured very similar to an RTS, which makes sense considering it was originally an RTS mod. It was designed from the start to use client-server because it was designed first and foremost as a competitive game, and a competitive game that cannot gracefully handle disconnects makes running serious competitions an administrative nightmare. However, such architecture comes at a pretty steep monetary cost. Servers have to be globally located in order to accommodate people around the world, have to be maintained, and most importantly, have to be able to handle the immense bandwidth that a client-server game with large unit counts is going to produce. That last point is the most expensive, and one of the main reasons (along with having to recode most of their engine) why Relic will never adopt such a structure for CoH2. Maybe for CoH3, but even then it's unlikely.
Valve was willing to spend that money because they were trying to build a competitive game and a competitive community and knew they needed consistency if they were going to be taken seriously. Hell, they committed $1.6 million to a tournament prize pool before the game was even released to the public. Relic has neither the money nor the inclination to invest in something like that when it's seen as a luxury and not a necessity.
So no, building an RTS with a client-server model isn't impossible, especially if you have low unit counts like CoH does. But it's expensive, and in the case of CoH2 it would require a major rewrite of most of their codebase. In other words, it's completely impractical to hope for such a system to be implemented in CoH2.
If you're interested in reading more, I'd highly recommend this Gamasutra article by a Supreme Commander developer. Very enlightening on the challenges surrounding synchronization, message passing, and bug fixing in RTS games: http://www.gamasutra.com/view/news/126022/Opinion_Synchronous_RTS_Engines_And_A_Tale_of_Desyncs.php
And another interesting article, this an academic piece on SC2's pseudo-client-server architecture: http://choongsoo.info/docs/starcraft2.netgames12.pdf
From http://www.coh2.org/topic/19148/drop-hack-continues/post/257032 |
|
Then you have a client-server game. There's a reason RTS games have traditionally never been client-server: it's impractical. The cost per player is insane, and while CoH generally has less individual units in play at any given time than other RTS games, it's still prohibitive. Not to mention the game engine would essentially have to be rewritten with a client-server architecture in mind. |
|
Because maphacking is relatively easy to do since it's necessary to make all game data available to every client. It's impossible to prevent maphacking in a deterministic simulation game engine, which every single RTS uses. There's no comparison between being able to display hidden data that you already have and issuing commands on behalf of another player; one is theoretically very easy, while the other is theoretically very hard, if not essentially impossible. The fact that you even think the two are comparable is laughable. |
They're not "out in the open", they're hashed and salted on the server, they're just posted in plaintext from the browser to the server. Which is not good practice, agreed, but it's nowhere near the level of vulnerability you claim it is. The main implication of this is if someone is sniffing packets from your machine (because they're on the same network as you or you're connecting over an insecure access point), they will be able to see the password you send to the server when you login.
Regardless, the appropriate people have been made aware of this. I haven't worked with the code in a long time, so I'm not in a position to fix it.
The OP doesn't really know what he's talking about, he's just parroting what someone else said and exaggerating. The current situation is not ideal, but also won't give anyone your password unless they're reading your network traffic. |
|
Almost all of the Western Starcraft scene moved to SC2, and the Korean scene only stuck to BW because they were under contract and getting paid insane amounts of money. Once KeSPA moved to SC2 almost all of the old BW pros followed, and today a lot of the top SC2 players are former BW pros. Saying CoH2 and CoH1 are completely different games is a bit of a stretch; there's a lot of overlap with core mechanics.
Anecdotal evidence doesn't really say much either. I could counter your "getting older" theory with anecdotes about CoH1 players with thousands of hours in Dota 2 and LoL and CSGO. I have 2000 hours in Dota 2, and I was up until 2AM last night spamming CS games. Sepha spams Dota games, DevM puts on his fairy anime costumes and plays LoL. But that doesn't really say anything useful. What we know for sure is, unlike many similar games, CoH2 failed to retain almost every single one of its predecessor's top players. That's a unique situation, and the reason behind it is no doubt complex. But it's interesting to think about. |
Canada
2
S73v0
Inverse
Relic Entertainment
cblanco ★ 
보드카 중대 
VonManteuffel 
