Very very true. This is why I originally did not include the correspondence games in the graphic.
From the perspective of a correspondence game player the CG setup actually makes sense. Although again even our correspondence only friends have a split player pool.
I guess what the site tried to achieve is to marry the live crowd design (which usually prefers AF) with the correspondence crowd design (which usually prefers CG) and it did this in the worst way imaginable.
Considering this it makes sense to remove the correspondence games from the AF entirely but therefore give it its own section where people can still play CG ranked for correspondence games. Live CG should stay unranked though.
I don’t play correspondence anymore, but if I did my answer would be that the vast majority of my correspondence games were/are tournaments or ladders. These are the games I took most seriously and put most effort into, and definitely should remain ranked.
Because i like to customize and be ranked.
I don’t want OGS to be a clone of let say Goquest, i just go play there if i am in the mood and i prefer that any game here with various settings can be ranked.
Im completly against your suggestion.
What I don‘t quite understand still is how custom games take away from the automatch queue. Of course they do in a literal sense, but the open game requests are sitting there right below the automatch box. If you‘re waiting too long for a game on automatch, why not scroll through the list of open games and accept one of those instead? If there is no suitable game request there, that means that even if we got rid of CG, your queue time would be the same.
I totally agree. I said as much in my last comments. Just the way they are presented should change imo.
I see the issue. You got used to all these options for live ranked games and now you would be upset if someone would take them away again. In my opinion you should have never had them in the first place but I can sense that my proposal will be a hard sell.
I obviously don’t want that either. OGS is an awesome web app with many great features and nothing like GoQuest.
I love this comment. No offense but it kind of shows the train of thought for people that are not that involved with software development.
Imagine a hobby car manufacturer would build his own car. And in the final design he welds all the car doors shut so that they cannot be opened. And I’m asking “Why did you do that. Just don’t weld them so that people can still enter through the door to sit in the driver’s seat?”. And then you say “If you want to get into the car, why not get in through the trunk and then climb the way to the driver’s seat?”. That’s what this sounds like to me.
But more seriously:
There are situations where what you suggest is not even possible. Many Front-Ends that use the OGS API for match making did not implement it in such a way that doing both at the same time would be possible, e.g. Conquest of Go
The whole point of AF is that I can just click it, think about the universe and the sound of Bs and Ps for a second, and get my match. I do not want to spend time on the OGS page and look through lists in order to be the first to click when a new challenge pops up. I mean what year is this, 1965? Where did myspace go?
Ok i don’t regret at all to have them since long ago and instead of trying to analyse why i have an issue you could try to analyse why you have an issue yourself with the system we have and you can’t appreciate it.
On this just keep respect on our different tastes and let’s move to another topic.
It is very frustrating to see how well you are explaining the situation and how difficult it seems to be for some to even understand your arguments (…and mine that I brought up years ago…).
You would not even need to touch the UI at all to improve this! It could all be done in the backend: Just make sure that people who want to play a game and who would have a common ground are paired against each other.
If the parameters of a custom game request and a request via AF do overlap, just create that .ucking game. I can’t wrap my mind around why some people are opposing this. It would only have positives and not a single drawback that I could think of.
I even consider it a bug that the server isn’t doing that. I was flabbergasted when I first learned that AF- and CG-requests are totally separate and the reactions to the topic in the forum did significant damage to my initial enthusiasm regarding OGS.
Fritz, as far as I’m aware, no one is opposing the possibility for Custom games to be picked up by Automatch. In fact I proposed this idea earlier in the thread:
The opposition is to @Regenwasser 's proposal that Custom should be only available as unranked.
Me too! As long as the custom game parameters are within reasonable limits.
I didn’t pick up that notion from @Regenwasser. Sorry, my bad.
I would be very hesitant taking features away from users.
I agree with you guys that just connecting the player pools would already be a huge step forwards! I do also support that idea. I just do not think that it goes far enough.
Imagine someone creates a CG with Time Control set to “Absolute”. This user would still not be able to be matched with the AF folks. Or let’s say the CG user changes the Byo-Yomi periods to 4. Same issue. This could be handled in many different ways. But the one I personally like the least is “Just let the CG player create the ranked game with 4 Byo-Yomi periods”. Because of the obvious consequences.
Another issue is the general issue of the OGS config palooza described here:
And a third issue that immediately pops to mind is the weird surprises you get as a AF user. Sometimes people set games to “Ing” rules which is not even shown in the UI if you do not explicitly click on game information. If suicide play is allowed or not can be a significant information. Also sometimes people set the time control to their favorite “Fisher” or “Canadian” and these can have a huge impact on the game flow. Now as an AF user you have two options: A. You just live with what you get. B. You choose your required config and get longer queueing times. This situation is also avoidable.
Can you just stop repeating again the same arguments?
I don’t want to eat the same OGS pizza everyday, the only perfect system is not yours not mine either, but at least don’t kill the chicken with golden eggs: customization is de facto an appreciated feature of OGS. Point.
I find it a bit much that you compare looking at a handful of open game requests (which I did just now, it took less than 5 seconds) to welding the doors on a perfectly fine car shut. But I am not trying to tell you how to use OGS, that is just what I do. My main point was that even if you get rid of CG, the queue wouldn’t get much bigger. My impression is that the CG folk don’t nearly take away as much from the AF folk as you think they do. This gut feeling should be something that can be verified or falsified. In other words, what is the proportion of games started via AF compared to CG? If it is say 80/20, then getting rid of CG does not change much. If it is 50/50 the queue time could get a bit better, and if it is 20/80 maybe we should get rid of AF?
To be fair, putting away the end of custom rated games of course, I could propose another view on a automatch system fitting with someone who like customization.
That is the users of automatch could keep some default setting or take the time to define exactly what they accept. Please take the time to fix what you want (or not) at first at least, but that’s not even mendatory. Then automatch works like a very simple help to get players paired. Laziest one who seek a kind of standard game will be coached anyway by the default setting, more carefull will get more, or less according to their customization.
For convenience we could even consider how to transfer (add or replace) a set of setting you put in a custom game offer to your automatch settings (and reverse)
Made me smile. Well not that I am against AF. But what i see when i take the time to watch the custom game offers, you rather have to pick the one you want quickly or it will disapear in a few sec. Sometimes a game offer stay a bit longer, with unusual settings, fine to me. Players can elaborate on their will and test it, nothing wrong and i won’t push anyone in a please just play what people use to play.
If there are a few people with strict preferences waiting, doesn’t that mean that someone who doesn’t care about the settings (like you, I suppose) can come in and instantly get a match? Whereas if you didn’t allow strict preferences, Seunghyeon and Gustav might have paired with each other, leaving you partnerless.
As you said, they are happy with their choices. So the scenario you described actually benefits everyone.
On the other hand, if you are on the default settings and not getting matches, that means there’s nobody around your rank waiting in the queue at all, and restricting the game options for nobody isn’t going to help you match any faster.
My guess would be that most people sit around waiting for an interesting CG to show up, because they want to know what they are going to get, and AF doesn’t do that for them. Especially for AF time settings, why don’t we at least say what they are somewhere?
Would’ve been nice if you’d read my comment before writing this. These are different arguments directed at a different situation.
The great thing about Go pizza is that you never get the same because the Salamis will be placed somewhere else every time. That is the magic of Go.
Not that this is too important but just to clarify the analogy: I compared your “looking at a handful of open game requests while also starting the AF queue” to climbing to the driver’s seat through the trunk. On the other hand I compared “welding the doors on a perfectly fine car shut” to “creating a gaming web app that has customization options which cannibalize its own match making queue”.
So your main point is the gut feeling. The thing is, and I’ve said that before, saying that having this feature does not have a huge negative impact because people are not using that feature anyways is a very bad justification for an app design.
Not if they are waiting on their CG.
That is not what I said. I said “they both disliked waiting 25 minutes”. And that is the point here, they both keep using the settings which then increases their queueing time and in the end reduces their satisfaction.
This would be true, like mentioned above, if we could get every CG game into the queue. But this is currently not the case and actually implementing it in such a way will/would also be a challenge. But even if we managed to solve all that, this would still turn using the AF into a game of chicken. Either I risk long waiting times or I will always have to eat what my opponent dishes. Furthermore, it is not always easy to use the “default settings”, as I wrote before, I myself sometimes choose “required no handicap” because I do not like handicap games all that much. In the end queueing times are much more important to me than the handicap option but I’m betting on the other player’s in the queue not having set that option → game of chicken.
Not that this is too important but just to clarify the analogy: I compared your “looking at a handful of open game requests while also starting the AF queue” to climbing to the driver’s seat through the trunk. On the other hand I compared “welding the doors on a perfectly fine car shut” to “creating a gaming web app that has customization options which cannibalize its own match making queue”.
You ignored my main point that your analogy is too much.
So your main point is the gut feeling. The thing is, and I’ve said that before, saying that having this feature does not have a huge negative impact because people are not using that feature anyways is a very bad justification for an app design.
You ignored my point that maybe we should get some data. Yes, my opinion is based on a gut feeling and reasoning from there, but so is yours. I agree that your plan might be a sensible thing to do, if it actually works (which would require a 50/50 split and not one of the extremes). Then one can still debate if it should be implemented.