1v1, 2v2, 3v3, 4v4 should look like checkboxes, and "Play" should look like a button. Like this:

@nex said in How exactly do we expect low rated players to play the game?:

@clyf yeah, the rating system isn't designed to handle large teams

On the contrary

https://www.microsoft.com/en-us/research/wp-content/uploads/2006/01/TR-2006-80.pdf

It's not the responsibility of anyone to sacrifice their evening playing games that they don't want to play. Furthermore, I don't think most low rating players would appreciate playing with much higher rating players on a regular basis. You can only get crushed so many times until you start to feel terrible.

Yes, there's clearly a problem onboarding new players. However, telling people to just play more with low ratings players is not a viable solution.

On a related note, I've been playing ladder in a different game recently where the matchmaking range is far too broad. I have 73 wins and 15 losses. It is not fun for me that the majority of my games are essentially meaningless stomps. I don't think it's fun for the opponents either.

I don't think the name and shame in OP is very nice.

For me personally the biggest hindrance in reading balance posts is the argumentation. This applies across the board to all ratings really. If there was a nice summary of everyones point of view I would likely read them, however in reality the threads tend to be branching arguments which rarely add any real substance and often appear more socially motivated than motivated by any enthusiasm to contribute to balance. Discord "forums" are particularly bad for this reason. I'd like to see just some nice bullet points or lists of pro/cons and such.

@waffelznoob said in Lots of people rage quitting in 3v3 TMM:

as a rage quitter, i apologise. i will do better

Can u also stop playing 10min chess when lobby is 7/8?

@exselsior said in Why would you have left FAF?:

The only change that has been mentioned that I think would count as actually having to relearn core gameplay is engy mod and that was more than 3 years ago. E storage and mass fab changes are relatively speaking so trivial that for anyone even remotely competent at the game it would take little to no effort at all to account for. And if you’re not somewhat competent they’re not big enough changes to matter whatsoever for you anyway.

Not just more than 3, that was like 9 or 10 years ago (2013-2014)

1v1

2v2

4v4

One of the best things about supcom is that anything that could be described as cheese barely even exists.

@nex said in Why would you have left FAF?:

@blodir I have also seen people talk about making it dynamic, but back then it wasn't very well received, as the micro potential and thus the gameplay changes drastically with input delay.
So if micro became better with lower ping this would either put players at a disadvantage that have a high ping to the relay server or (in the case of pure p2p) would make every game feel completely different on how well you can micro your units.

I can see that people find it off putting to have such a high input delay (though to me it always felt kinda natural), but I think that's part of the charm of supcom and people who don't like that are probably better off with a different game.

Yea apparently it's possible to have at least synchronous adaptive input scheduling.

I don't think there's any charm to high input delay, though I see the benefit of consistency in such a small community. Like if you could always get games entirely within your region it would be a non-issue, but if people got used to playing with low input delay and then have to play with high delay the next game I think they'd be pretty frustrated even if technically the overall experience is better.

But yeah with current sim tick rate we can at best reduce it to max 200ms delay, which is still dramatically higher than eg. sc2 (I'm pretty sure they have around 50ms ticks). Still a lot better than what we have currently

@nex said in Why would you have left FAF?:

@Blodir

Supcom has an inbuilt input latency, which is independent from both the sim latency(which comes on top, if at all) and network latency(which the input latency is meant to compensate for).
so no matter how good your ping is you will have those 500ms of input lag. this could in theory be a variable lag, but from what I can remember it's fixed (and apparently to 500ms), to make every game feel consistent.
so every tick (or possibly every frame) the game collects your inputs for tick n+5 and sends them to all other players.
At tick n+5 the game checks if it received inputs from all players and if not pauses.
So these 500 ms are currently fix. assuming the game might take about 100ms to send your inputs(if it gathers them all over the course of a tick and then sends them once) then you get up to 100 ms of extra lag (if you press right before it's send you get 0ms, if you press right after a send you get 100 ms extra lag), so on average that is 50 ms lag, which you could halve by doubling the sim rate, so you'd gain 25ms on average but the 500ms (which is chosen so that players with a ping of up to 250ms to each other can play together) will always come on top of that, so the net gain is between 5-10%

so tl;dr there is a 500ms inbuilt lag to compensate for any network lag, which overshadows any amount of lag introduced by the sim tick rate.

Yes, I talked with Jip yesterday and he confirmed that inputs are scheduled for 5 ticks in the future. It's possible to (almost) completely eliminate this by scheduling the inputs at a proxy server like sc2 (or seemingly BAR). Basically they asymmetrically schedule inputs based on latency, such that people with high ping to the server have higher input lag than those with low ping to the server. So in those cases input lag is totally dominated by sim tick length.

I get what you are saying now though, I thought you were saying that there's some nebulous other source of input lag or that network latency dominates, which is not true. It's just a somewhat arbitrary value of 5 ticks chosen to be acceptable by gpg in order to avoid writing dynamic scheduling logic x) Even in pure p2p it should be easily possible to communicate input scheduling changes based on latency (though then the scheduling has to be synchronous).

@nex said in Why would you have left FAF?:

@zlo said in Why would you have left FAF?:

Current inputlag is 500 ms

huh interesting
my brain somehow had this number 150 saved for some reason.
Well with 500ms input lag assuming the sim tick "lag" comes on top that is currently 50ms on average (100 max) so you could reduce the input lag by 5-10%, by doubling the sim tick rate.
Doesn't sound like a good trade tbh.

This is not correct. Here's some approximations for magnitudes of different latencies:

• Sim/physics update/input sampling. Note, as I said earlier, that the worst case scenario is that the length is doubled for an input! So if supcom runs at 10hz (which idk if it does) that would be worst case of 200ms delay! (or more, if the inputs are scheduled to be processed at an even later tick)
• Framerate, monitor offsync with framebuffer and vsync. This on the scale of <16ms for 60fps.
• Display lag, input devices, drivers, and so on. <5ms

Network latency between two players with reasonable ping is not at all relevant, because the sim tick rate dominates!

Like say you are playing an 1v1 game with someone with a direct connection (without proxy). You can tell from experience that you still experience a comparable amount of input lag. Keep in mind that ping refers to round-trip-time. So if you have 40ms ping between two players, that would amount ot only 20ms one-way latency. So when you are sending an input packet at tick n that is destined for tick n+1, the other player will receive it 20ms later - even though, assuming 10hz tickrate, there's still 80ms of the tick left! So we can easily expect that at low ping and slow sim rate contexts network latency is practically irrelevant.

Also note that if someone is late, the time window might be extended multiple ticks in the future so eg. inputs collected at tick n would be processed at tick n+2 instead of n+1. A higher sim tick rate gives more flexibility in this sense, where a slower one introduces a large additional delay in the worst case.

@blodir said in Why would you have left FAF?:

@nex said in Why would you have left FAF?:

@blodir said in Why would you have left FAF?:

@nex said in Why would you have left FAF?:

As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.

I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)

Might entirely be I just looked at what was posted above
https://springrts.com/phpbb/viewtopic.php?t=37637
and how the syncing works:
https://springrts.com/wiki/Syncing_System
these all mention a server/host, which must not necessarily be a dedicated server, but there is still a host and clients in the architecture

First link the first reply clarifies that it's regular ol' deterministic lockstep. However, the second link appears to describe a re-syncing feature. Yea, this is a hybrid approach where the system falls back on authoritative server approach if the parallel simulations get out of sync. As a downside whoever is selected as the authority gets to cheat to their heart's content

From the first link it does sound like they have an ad-hoc server implementation that gets to determine the destination tick of each input packet so the high ping players experience more input delay. Unfortunately this would require supcom source code and a new proxy server implementation (but it is still the same network model and only a minor optimization). Again didn't look too closely tho just skimmed...

@nex said in Why would you have left FAF?:

@blodir said in Why would you have left FAF?:

@nex said in Why would you have left FAF?:

As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.

I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)

Might entirely be I just looked at what was posted above
https://springrts.com/phpbb/viewtopic.php?t=37637
and how the syncing works:
https://springrts.com/wiki/Syncing_System
these all mention a server/host, which must not necessarily be a dedicated server, but there is still a host and clients in the architecture

First link the first reply clarifies that it's regular ol' deterministic lockstep. However, the second link appears to describe a re-syncing feature. Yea, this is a hybrid approach where the system falls back on authoritative server approach if the parallel simulations get out of sync. As a downside whoever is selected as the authority gets to cheat to their heart's content

@nex said in Why would you have left FAF?:

As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.

I don't know much about springRTS, but based on quick googling this is incorrect and it works the same as supcom and just about every other RTS. Note that the client-server network topology is not mutually exclusive with deterministic lockstep. When people refer to a server in the context of games like eg. sc2 they are referring to a proxy server that facilitates connections between the players (just like what we have in faf!) (though it is possible to have some extra functionality too, just not the kind that you are describing)

@nex said in Why would you have left FAF?:

@blodir Isn't the input lag something that's deliberate (and not related to the sim)?
Because you need the input lag, to compensate for potential network lag.
That's why the game has a standard input lag of X ms, so people that have X ping to each other can still play together without stuttering.
That is because the engine expects input from every player on every tick, so if you have a higher ping than the input lag, the game micro freezes till all inputs arrive.
Changing the simulation tick rate shouldn't matter, but you'd need to rewrite how the engine works to be able to solve this lag problem. You'd need to introduce some kind of rollback code, that when there is no input from a player continues the simulation, but once the input for an earlier frame arrives, you'd need to roll back to that state and recompute up to the current tick (that's how most fighting games work), but that's a pretty heavy workload for a complex simulation like supcom (that doesn't even manage to run in real time sometimes).

As far as I understand springRTS, it handles it by having a server-client architecture, with the server as the single source of truth, so when someone lags behind they'll just get updated to the state of the server.

Tick n:

• collect pooled inputs during the time between tick n-1 and now and send to other players. Mark these inputs as destined for tick n+1
• run simulation with inputs destined for tick n (if inputs for tick n have not been received from all players, then pause)

So with 500ms sim tick length if you enter input (eg. give a move command to a unit) 10ms into tick n-1, then the input will be sent at 500ms, and executed at 1000ms. That is a 990ms input delay, which is tied to the sim tick rate.

@redx said in Why would you have left FAF?:

Even if you could somehow convince Nordic to care about FAF, you would have to completely rewrite the game to completely solve lag and connection issues. The reason the game is so susceptible to connection issues is literally the very core of how the game's simulation engine works. You'd literally be better off porting all of the game mechanics and units to Spring or something than trying to change SC:FA into a client/server game.

Spring uses deterministic lockstep like supcom, besides you don't want an authoritative server RTS regardless.

Connection issues are in no way 'core' to how the game works. You wouldn't need to rewrite the game to solve network lag.

You'd most likely have to make significant changes to increase the sim tickrate (source of most of what appears as input lag) gracefully though.

Funnily enough, the vibe that I'm getting from the low rating / gapper balance complaints is not too dissimilar from high level balance complaints. A common sentiment among high level mapgen players is that arty/nukes/sat are lame, and people seem to generally prefer exp land wars in lategame. So I don't think the views are totally incompatible.

@broker said in Why would you have left FAF?:

@blackyps I suggested making two sets. for different players. In my proposal, labor costs are minimal. I understand it.

And so the game will remain a game of nerds. it's a pity.
although nothing prevents you from doing an experiment.
except for the desire and fear that now no one will play with nerds if there is an alternative)))

Son, these are the faf forums. You are, in fact, a nerd.

@etfreeman said in Matchmaker Pool Feedback Thread:

...

Hey apologies for not communicating the change properly. The 1v1 map pool now considers your current rating bracket and the one below it, like the other matchmaker queues. This means that the ratio of 20km maps is approx. 30% (4/13) for the highest bracket. I'll get someone with moderator rights to add that to the map pool post. Regardless, we'll consider decreasing the amount of 20km maps for the next pool.

As for Bermuda and Crossfire, I do agree that they are outliers. However, there's an unfortunate lack of navy maps suitable for 1v1. I'm not sure if we can get rid of maps such as those entirely. We'll take your feedback into consideration though. For what it's worth, note that there's no Ditch, Daroza, Painted Desert, or such maps.

Thanks for the feedback!

(damn storm replying while I was writing!)

1v1

The 1v1 map pool is no longer cumulative, but instead works the same way as the other map pools. The average rating of the two players is considered when picking the match rating. The map to be played is then picked from the map pool of that rating range, and the one below. So, for example, a 1500 player will get maps from both 700-1200 and 1200+ pools.

2v2

The pool will be next updated in October.

4v4

The pool will be next updated in October.