Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[yed]

50 people rooms should help us find games...
https://getsatisfaction.com/goko/topics/what_do_the_different_rooms_courtyard_gardens_mean_why_can_i_sometimes_enter_a_room_sometimes_not#reply_12562665

I think the real reason is that lobby code is so bad, that it can't handle more people. But even that would not be a problem.... if they would hide people and games currently being played and kicked people from lobby after 1 hour of inactivity.

[Kirian]

We'll see if there's a response to my response...

[Fabian]

Kirian, now that this has finally been brought to their attention, I'm sure we'll see a non-laughable lobby system up by the end of the weekend.

[Drab Emordnilap]

Meet me in Outpost VI?

[SCSN]

What I've been doing lately is just opening a couple of tabs and wait in multiple rooms simultaneously.

[shraeye]

Could we have some Pro-exclusive rooms sorted by rating range???  Now THAT sounds like a good idea.

[shark_bait]

also it's easier to meet up in the less crowded room with your friends to set up the table

Because all of us would rather call up our friends and say, "You want to Goko it up tonight?" instead of saying "Alright, I've got 30 minutes, time for a quick fews games of Dominion." 

Now I know some people use Goko as a means to meet up with friends to play Dominion, but I think the majority of the player base is playing with random strangers who we've gotten to know via dominion screen names.  I'm not about to call Robz or ednever up on their cell phones saying, "Hey, dominion tonight?"  I'll go into the lobby and say to myself, "Who's online that I enjoy playing against."  And let me tell you, I won't ever find Robz or ednever by frequenting the likes of Treasury III.  Give us single lobby with with available players and a single lobby for in progress games (so we can see who's online, but playing) with the ability to search for players and propose games to players.  If Goko does that I could care less if they decided to go all the way to Doctor IX for "friend-finding" play.

Goko, please.  We've given you money, let's get a complete product.

[SCSN]

also it's easier to meet up in the less crowded room with your friends to set up the table

Because all of us would rather call up our friends and say, "You want to Goko it up tonight?" instead of saying "Alright, I've got 30 minutes, time for a quick fews games of Dominion." 

Now I know some people use Goko as a means to meet up with friends to play Dominion, but I think the majority of the player base is playing with random strangers who we've gotten to know via dominion screen names.  I'm not about to call Robz or ednever up on their cell phones saying, "Hey, dominion tonight?"  I'll go into the lobby and say to myself, "Who's online that I enjoy playing against."  And let me tell you, I won't ever find Robz or ednever by frequenting the likes of Treasury III.  Give us single lobby with with available players and a single lobby for in progress games (so we can see who's online, but playing) with the ability to search for players and propose games to players.  If Goko does that I could care less if they decided to go all the way to Doctor IX for "friend-finding" play.

Goko, please.  We've given you money, let's get a complete product.

The problem with all this is that it is way too logical for Goko. Try mixing your good stuff with a bunch of absurd suggestions (the addition of Treasury XI, say) and they might accidentally implement it.

[Fabian]

To be fair, I've messaged RL friends on facebook or whatever to come play Dominion online a number of times, I must have played at least 150-200 games like that over the years.

You know, out of ~10k or whatever.

And, you know, on Isotropic, obviously. Who would do that on Goko lol.

[Awaclus]

Also, I think the limit makes it more difficult to play games with people you've planned to play against too, because they'll often end up in different lobbies than you after the first game, since the lobby is full and there isn't enough room for everyone.

[hsiale]

What I've been doing lately is just opening a couple of tabs and wait in multiple rooms simultaneously.

Ah, so that's why recently it seemed you follow me instatly whenever I go to another room

[Awaclus]

What I've been doing lately is just opening a couple of tabs and wait in multiple rooms simultaneously.

Ah, so that's why recently it seemed you follow me instatly whenever I go to another room

Actually that's probably what SheCantSayNo has been doing - opening a couple of tabs and waiting in multiple rooms simultaneously is surely the most efficient way to stalk you. 

[phoenix9797]

Alas, while I wholeheartedly agree with all of this, I am not holding out hope: https://getsatisfaction.com/goko/topics/one_room_to_find_games.

The standard response seems to be: "That is a good idea."  Followed by the same (wrong) explanation that having scads of rooms actually helps people find games.

[Kirian]

Alas, while I wholeheartedly agree with all of this, I am not holding out hope: https://getsatisfaction.com/goko/topics/one_room_to_find_games.

The standard response seems to be: "That is a good idea."  Followed by the same (wrong) explanation that having scads of rooms actually helps people find games.

It's almost as though none of them actually... you know, play the game.

[LastFootnote]

Alas, while I wholeheartedly agree with all of this, I am not holding out hope: https://getsatisfaction.com/goko/topics/one_room_to_find_games.

The standard response seems to be: "That is a good idea."  Followed by the same (wrong) explanation that having scads of rooms actually helps people find games.

It's almost as though none of them actually... you know, play the game.

I think they actually play the game a lot. They just don't play on the public servers, so they haven't had much experience with their horrible lobby system.

[eHalcyon]

also it's easier to meet up in the less crowded room with your friends to set up the table

Because all of us would rather call up our friends and say, "You want to Goko it up tonight?" instead of saying "Alright, I've got 30 minutes, time for a quick fews games of Dominion." 

Now I know some people use Goko as a means to meet up with friends to play Dominion, but I think the majority of the player base is playing with random strangers who we've gotten to know via dominion screen names.  I'm not about to call Robz or ednever up on their cell phones saying, "Hey, dominion tonight?"  I'll go into the lobby and say to myself, "Who's online that I enjoy playing against."  And let me tell you, I won't ever find Robz or ednever by frequenting the likes of Treasury III.  Give us single lobby with with available players and a single lobby for in progress games (so we can see who's online, but playing) with the ability to search for players and propose games to players.  If Goko does that I could care less if they decided to go all the way to Doctor IX for "friend-finding" play.

Goko, please.  We've given you money, let's get a complete product.

The problem with all this is that it is way too logical for Goko. Try mixing your good stuff with a bunch of absurd suggestions (the addition of Treasury XI, say) and they might accidentally implement it.

There should be 7 rooms - one room each for people wishing to join 2-6 player games, one room for anything, and one room with all the in-progress games (potentially used for spectating?).

These rooms should be named as follows:

2p: Outpost IV
3p: Outpost II
4p: Treasury IIII
5p: Scout
6p: Hahahaha good luck with that
free play: Outpost 4
in progress: Dominion Room

Actually, Dominion Room should not simply house all in-progress games.  That would be ridiculous.  Instead, Dominion Room has multiple sub-rooms named Dominion Sub Room I through Dominion Sub Room CLVI.  Whenever a game begins, it is moved into one of these sub-rooms.  The specific room used is determined by a hash function -- add the current rankings of all players involved, mod 131 (and then add 1 until an empty room is found).  If somehow all sub-rooms are filled, Dominion Room VII is created.  If Dominion Room VII's sub-rooms are filled, then the in-progress game can stay where it is instead of being moved.

[shraeye]

I support this idea.

[WanderingWinder]

I support this idea.

The idea is fine, along with 47 others that don't include that which is currently in place.

[Dsell]

To be fair, I've messaged RL friends on facebook or whatever to come play Dominion online a number of times, I must have played at least 150-200 games like that over the years.

You know, out of ~10k or whatever.

And, you know, on Isotropic, obviously. Who would do that on Goko lol.

I do this. In fact, recently this has been the majority of my games. We complain about the interface the whole time, but Dominion is Dominion.

If half-decent matchmaking is ever implemented, I'll be more inclined to play random games.

[GeoLib]

There should be 7 rooms - one room each for people wishing to join 2-6 player games, one room for anything, and one room with all the in-progress games (potentially used for spectating?).

These rooms should be named as follows:

2p: Outpost IV
3p: Outpost II
4p: Treasury IIII
5p: Scout
6p: Hahahaha good luck with that
free play: Outpost 4
in progress: Dominion Room

Actually, Dominion Room should not simply house all in-progress games.  That would be ridiculous.  Instead, Dominion Room has multiple sub-rooms named Dominion Sub Room I through Dominion Sub Room CLVI.  Whenever a game begins, it is moved into one of these sub-rooms.  The specific room used is determined by a hash function -- add the current rankings of all players involved, mod 131 (and then add 1 until an empty room is found).  If somehow all sub-rooms are filled, Dominion Room VII is created.  If Dominion Room VII's sub-rooms are filled, then the in-progress game can stay where it is instead of being moved.

I think it would be easier to just have one main lobby like isotropic but have filter check boxes like hide in progress games, 2p, 3p, etc. min/max rating, pro/casual/unrated, #/types of sets available, etc. as well as search options for player names and the ability to directly propose a game with a person. That way if you want 2 or 3 player games with players who are 5000+ you can just view the lobby that way rather than having goko make a separate lobby for that specific subset. And if you want to meet up with friends then you can go to Outpost IV: the Reckoning or whatever. Also, you know, automatch would be nice...

[eHalcyon]

There should be 7 rooms - one room each for people wishing to join 2-6 player games, one room for anything, and one room with all the in-progress games (potentially used for spectating?).

These rooms should be named as follows:

2p: Outpost IV
3p: Outpost II
4p: Treasury IIII
5p: Scout
6p: Hahahaha good luck with that
free play: Outpost 4
in progress: Dominion Room

Actually, Dominion Room should not simply house all in-progress games.  That would be ridiculous.  Instead, Dominion Room has multiple sub-rooms named Dominion Sub Room I through Dominion Sub Room CLVI.  Whenever a game begins, it is moved into one of these sub-rooms.  The specific room used is determined by a hash function -- add the current rankings of all players involved, mod 131 (and then add 1 until an empty room is found).  If somehow all sub-rooms are filled, Dominion Room VII is created.  If Dominion Room VII's sub-rooms are filled, then the in-progress game can stay where it is instead of being moved.

I think it would be easier to just have one main lobby like isotropic but have filter check boxes like hide in progress games, 2p, 3p, etc. min/max rating, pro/casual/unrated, #/types of sets available, etc. as well as search options for player names and the ability to directly propose a game with a person. That way if you want 2 or 3 player games with players who are 5000+ you can just view the lobby that way rather than having goko make a separate lobby for that specific subset. And if you want to meet up with friends then you can go to Outpost IV: the Reckoning or whatever. Also, you know, automatch would be nice...

OK, well, we can keep the Dominion Room for in-progress games, though maybe it should be renamed Black Lotus II.  Then the main lobby should probably be named Outpost III (except on Thursdays, when it is Outpost IX).

[SirPeebles]

4p: Treasury IIII

This is where me, Robz, ednever, shark_bait's mom were last night 

[DG]

They also need a friends list.

[SirPeebles]

They also need a friends list.

A friends list would be nice, but that is just so far down the list of things that need to happen ASAP.  Consider that it's taken nearly a year to add a button that allows us to give them our money in exchange for a single, measly card.

I am honestly shocked by Goko's behavior.  I understand that there is always a tension between the interests of the user and of the provider.  I don't expect Goko to give us everything we ask.  But I do expect that to implement directly beneficial and profitable items like direct purchase of promo cards.  I also don't expect them to waste their time and money developing idiotic structural problems, like this whole room system.  Maybe the hope was that finding a game would be frustrating until you buy your own sets?

[Obi Wan Bonogi]

Further evidence that the developers never played on Isotropic's platform, ever.

[LastFootnote]

I may be misremembering, but it was my understanding that the room system was built to deal with server load issues.

I have no idea why that would help, though, unless different rooms run on different servers.

[jonts26]

I may be misremembering, but it was my understanding that the room system was built to deal with server load issues.

I have no idea why that would help, though, unless different rooms run on different servers.

It's a pretty crappy server if it can only handle 50 people.

[Kirian]

I may be misremembering, but it was my understanding that the room system was built to deal with server load issues.

I have no idea why that would help, though, unless different rooms run on different servers.

It's a pretty crappy server if it can only handle 50 people.

Back when I played WOW, there were routinely several thousand people on the server.  Now sure that's a different sort of game, and Blizzard was running ultra high end servers.  But 50?

[dondon151]

Am I doing this right?

[michaeljb]

So, seeing this thread reminded me of something nutki said in one of the last messages I received from him...

(btw, because of this line goko code is already n^2)

> open Chrome
> go to playdominion.com
> open up the developer tools
> click on the sources tab
> open lib/FS.MeetingRoom.Dominion.js
> line 6018 is the start of a function, onPlayerListChange; this is called every time a player enters the lobby (and maybe leaves too?)
> line 6061: "var currentRomPlayers = $('.fs-player-list li').length,"
> this means the number of players in the current lobby is counted every time a player is added
> that counting is O(N), where N is the number of players
> simply displaying the the player list turns out to be O(N^2)

Perhaps this is the real issue?

[StrongRhino]

Am I doing this right?

It'd probably work better with no "We" and no second part, like the first Advisor meme. Like the Advisor is telling the king- "Psst, make rooms cap at 50"

_{I know you didn't really want advice, but whatever.}

[ragingduckd]

So, seeing this thread reminded me of something nutki said in one of the last messages I received from him...

(btw, because of this line goko code is already n^2)

> open Chrome
> go to playdominion.com
> open up the developer tools
> click on the sources tab
> open lib/FS.MeetingRoom.Dominion.js
> line 6018 is the start of a function, onPlayerListChange; this is called every time a player enters the lobby (and maybe leaves too?)
> line 6061: "var currentRomPlayers = $('.fs-player-list li').length,"
> this means the number of players in the current lobby is counted every time a player is added
> that counting is O(N), where N is the number of players
> simply displaying the the player list turns out to be O(N^2)

Perhaps this is the real issue?

I don't think N is really very large here. Anybody who is actually playing neither generates nor receives lobby updates.

[Kirian]

But in a 200 player lobby, a function that runs in O(N^2) starts to get unwieldy.  There are ways around this, the most common of which is not to write functions that take that long to run.  Which could have been done here I'm sure.

[SCSN]

So Goko did in fact do a pretty remarkable job

[Tombolo]

I just play bots!

[LastFootnote]

Sorry, but n^2 is not 2^n. Not even close.

[SCSN]

Sorry, but n^2 is not 2^n. Not even close.

It might help to not edit out the part where I implied that.

[Kirian]

Sorry, but n^2 is not 2^n. Not even close.

Remember, Advisor doesn't actually give good advice...

[LastFootnote]

Sorry, but n^2 is not 2^n. Not even close.

Remember, Advisor doesn't actually give good advice...

Right, fair enough. I guess I just don't consider "Displaying the player-list is NP-Hard" to be advice. He's not telling the guy to do something. He's just lying.

[markusin]

So, seeing this thread reminded me of something nutki said in one of the last messages I received from him...

(btw, because of this line goko code is already n^2)

> open Chrome
> go to playdominion.com
> open up the developer tools
> click on the sources tab
> open lib/FS.MeetingRoom.Dominion.js
> line 6018 is the start of a function, onPlayerListChange; this is called every time a player enters the lobby (and maybe leaves too?)
> line 6061: "var currentRomPlayers = $('.fs-player-list li').length,"
> this means the number of players in the current lobby is counted every time a player is added
> that counting is O(N), where N is the number of players
> simply displaying the the player list turns out to be O(N^2)

Perhaps this is the real issue?

Hold the phone! Can someone help me clear this up? Is $('.fs-player-list li') a Javascript array? It seems to me like that recalculating runs in O(N) time, since it apparently has to find the largest index key to determine the length.

My real question is, if it is an array, doesn't the O(N) updating of the length property get calculated whenever the size increases anyway, thereby resulting in O(N^2) time no no matter what you do? The post I quoted seems to suggest that not asking for the length property prevents this counting from happening. That doesn't sound right.

[michaeljb]

Hold the phone! Can someone help me clear this up? Is $('.fs-player-list li') a Javascript array? It seems to me like that recalculating runs in O(N) time, since it apparently has to find the largest index key to determine the length.

My real question is, if it is an array, doesn't the O(N) updating of the length property get calculated whenever the size increases anyway, thereby resulting in O(N^2) time no no matter what you do? The post I quoted seems to suggest that not asking for the length property prevents this counting from happening. That doesn't sound right.

$('.fs-player-list li') traverses the DOM and returns an array containing all the elements matching the selector (ie, list items in the player list).

I'm pretty sure simply storing the count and incrementing/decrementing by 1 when someone enters/leaves would work, and would definitely be faster than recounting every time.

[LastFootnote]

Hold the phone! Can someone help me clear this up? Is $('.fs-player-list li') a Javascript array? It seems to me like that recalculating runs in O(N) time, since it apparently has to find the largest index key to determine the length.

My real question is, if it is an array, doesn't the O(N) updating of the length property get calculated whenever the size increases anyway, thereby resulting in O(N^2) time no no matter what you do? The post I quoted seems to suggest that not asking for the length property prevents this counting from happening. That doesn't sound right.

$('.fs-player-list li') traverses the DOM and returns an array containing all the elements matching the selector (ie, list items in the player list).

I'm pretty sure simply storing the count and incrementing/decrementing by 1 when someone enters/leaves would work, and would definitely be faster than recounting every time.

I'm not much of a networking guy, but how would you tell when somebody leaves if they don't actually click the little home button? If they just kill their browser, it shouldn't kick off any events, right?

[michaeljb]

Looks like it doesn't, and I don't know off the top of my head how you'd tell, and Goko definitely hasn't figured it out (just did a test with Chrome and Firefox, after closing Firefox the account that had been logged in there was still visible in the lobby player list on Chrome).

Looks like there's an onunload event.

http://www.w3schools.com/jsref/event_onunload.asp
http://stackoverflow.com/questions/1631959/browser-window-close-event

[markusin]

Hold the phone! Can someone help me clear this up? Is $('.fs-player-list li') a Javascript array? It seems to me like that recalculating runs in O(N) time, since it apparently has to find the largest index key to determine the length.

My real question is, if it is an array, doesn't the O(N) updating of the length property get calculated whenever the size increases anyway, thereby resulting in O(N^2) time no no matter what you do? The post I quoted seems to suggest that not asking for the length property prevents this counting from happening. That doesn't sound right.

$('.fs-player-list li') traverses the DOM and returns an array containing all the elements matching the selector (ie, list items in the player list).

I'm pretty sure simply storing the count and incrementing/decrementing by 1 when someone enters/leaves would work, and would definitely be faster than recounting every time.

Ah, That makes sense. I suppose it would be possible to store some count variable, since the size should only increase/decrease by 1 each time. That could lead to a whole bunch of tracking issues though. At any rate, it shouldn't matter much for room sizes of 50, but then is that the reason why the max size is 50 in the first place.

What I really want to see is some indicator for whose currently playing a game and who isn't.

[Polk5440]

Why is a discussion about counting people in a lobby going over my head?

[mail-mi]

Why is a discussion about counting people in a lobby going over my head?

You and me both.

[ragingduckd]

> this means the number of players in the current lobby is counted every time a player is added
> that counting is O(N), where N is the number of players
> simply displaying the the player list turns out to be O(N^2)

Perhaps this is the real issue?

Not a chance.

Complexity theory matters when you're dealing with large N. These are tiny N, miniscule even. At this scale, the time for one operation is way more important than how quickly the number of operations grows with N. Some operations take a single processor flop while others take quadrillions. Are we talking about N^2 integer comparisons or N^2 renders for a 3D movie? And is that N^2 operations per hour or per millisecond?

Goko needs to send information every time a player logs on or off, starts/finishes a game, or joins/creates/changes a table. I probably create a table once every 20-ish minutes, then I auto-kick a couple joiners, then I get an opp and I start a game. So I'm generating about 15 events an hour. Sometimes I chat in the lobby or change rooms too, and maybe I'm underestimating... let's call it 60 events per hour, so each of N clients is receiving 60N messages per hour, which is a total of N²/60 per second that the server has to send. If that seems off, you can test it with the attached GM script, which listens to the Goko server and outputs every message they send you to the JS console.

But wait! I'm not actually receiving lobby events most of the time I'm logged in. When I'm playing a game, I don't care what's happening in the lobby and Goko isn't telling me. When I come back, they send me one "big" message that gives me the whole current state of the room. That one big message doesn't cost much more than any of the small ones do. So if I'm in games 90% of the time I'm connected, then Goko really only has 1/10th the obligation we calculated before. You can check that estimate by counting the number of running games vs connected players in the lobby at any given moment.

So now we're down to N²/600 messages per second. If there are N=200 people in a lobby, then Goko will need to send about 200²/600 = 67 messages per second. Is that realistic?

Why not try it out? Ask my server to send you some websocket messages and see how long it takes. If it can send 67 in less than a second, then my $500 computer is ready to handle a unified Goko lobby.

Ok, ok... Sending 67 messages per second is so easy it's not even worth testing. Let's try a bigger N.... leverage that O(N^2) running time. Maybe Goko grows by a factor of 10 so that N=2,000. Is my server capable of sending (2,000^2)/600 = 6,667 websocket messages in less than a second?

This was my result:

Server sent 6667 messages.
Server clock time elapsed: 0.1139 sec

Edit: Ok, looking back at the original conversation, I see that I missed the point. We're not talking about the time to send messages but the time to read an array. Same argument applies though, rather more so in fact.