scribble.rs
scribble.rs copied to clipboard
scribble-rs
re-open an old lobby by URL
This ist kind of related to #194 but also a bit different.
I had quite a hard time, trying to integrate skribbl.io into a workadventure map when I found your project. In workadventure you have to hard-code the URL into your map, so it would be great to just reopen an expired lobby with an old UID whenever the first one to enter the region arrives.
The game will then open in an iframe.
when opening an existin lobby in workadventure it looks like this:
scribble.rs does open inside the iframe - which is a load better than skribble.io - but the user does not show up.
sorry actually this is a different issue ...
I am not sure what you are trying to tell me with the second comment.
Either way, I guess I could allow reuse, since there's more people that would want this.
So, while I would allow explicitly creating a new lobby via an old UUID that you can specify in the payload, I will not allow implicitly creating one by someone joining the link. This way, i'd have to save all UUIDs ever used. Which is a nono, since memory isn't free and the service is currently ephemeral.
I am not sure what you are trying to tell me with the second comment.
I am sorry, I was in a rush to report ;-)
The comment is about not being able to play when opening the (existing) lobby with the mechanisms provided by workadventure.
In worksadventure you hard-code an URL in your map and it will be opened inside an iframe the moment a "player" triggers it by moving on the area associated with this URL. When I do this with a scribblers lobby URL, it opens as shown in the screenshot – provided the lobby is still active. (Otherwise it brings up the "the requested lobby doesn't exist" message.)
So, while I would allow explicitly creating a new lobby via an old UUID that you can specify in the payload, I will not allow implicitly creating one by someone joining the link. This way, i'd have to save all UUIDs ever used. Which is a nono, since memory isn't free and the service is currently ephemeral.
Sounds like a viable solution. Thank you! Can I assist in some way?
I shall happily host the service myself when I'm sure, we will use it for our "virtual Campsite", that I try to build for my scout group.
Btw, I just realized what's going on in your screenshots. Can you reproduce that and show me the console output?
the console shows a series of these:
ssrEnterLobby?lobby_id=0ac6831d-575e-4f45-b20f-3cfe0d44b8d5:418 WebSocket is already in CLOSING or CLOSED state. (anonymous) @ ssrEnterLobby?lobby_id=0ac6831d-575e-4f45-b20f-3cfe0d44b8d5:418
is this, what you expected?
complete log attached. play.wa.binary-kitchen.de-1613981331387.log
Hey, regarding the iframe thing, in issue #247 I realized why that wouldn't work and there's also a workaround described.
Other than that, I'll probably get around to the lobby_id topic this weekend. However, I noticed there's a company that used this in workadventure. https://www.lullabot.com/articles/together-apart-lullabots-virtual-team-retreat
If this wasn't you, maybe we could ask them how they did it, as it'd probably solve your problem either way.
Uhm, sooooo I just implemented all of this basically. I even added a preset parameter so people can't manipulate the link and therefore the lobby parameters. However, I forgot that there needs to be a lobby owner, because with out that, the game can't be started. I guess I need to rework game starting first and maybe add more elaborate rules. I don't want an unclean implementation for this.
Not really, just gotta implement #187 tomorrow.
We'll see how it all fits together. I am not quite sure on the whole concept though. Maybe allowing to start by vote isn't actually always the right thing to do in this scenario. Let's say you have 6 players that are supposed to join, wouldn't it be nice to say something like autostart-condition=playercount:6|duration:120s?
I doubt that allowing people to randomly start the game is a good thing. Especially regarding #194
I thought about something like a hashcode could be used to join a running or reestablish a previous session. But I diden't think about starting a session by URL-parameters. You think about a mechanism to avoid session mass-invocations?
Nah, there's no spam protection or anything, but that's a different problem. Either way, the hashcode stuff won't really work, as all of these solutions require additional state. I don't want to introduce additional state for this feature, it's not worth.