Thema: Owlbear Rodeo

[schneeland]

Nachdem es hier noch keinen Sammelthread für den Eulenbären gibt: Version 2.0 wird planmäßig am 19. Juli veröffentlicht (siehe Owlbear Rodeo 2.0 Release Date Announcement). Wer Owlbear 1.0 nutzt, sollte sich darauf vorbereiten, dass diese am 18. Juli heruntergefahren wird und noch in Verwendung befindliche Karten exportieren.

[Tintenteufel]

Wer Owlbear 1.0 nutzt, sollte sich darauf vorbereiten, dass diese am 18. Juli heruntergefahren wird und noch in Verwendung befindliche Karten exportieren.

Oh, no! Habe mal 1-3 Testspiele mit der 2.0 gemacht und war echt underwhelmed…

[HEXer]

Magst du erzählen warum? Ich hab 2.0 noch nie ausprobiert.

[Tintenteufel]

Magst du erzählen warum? Ich hab 2.0 noch nie ausprobiert.

IIRC fand ich die Handhabung der Karten suboptimal und die Tokens konnten nicht mehr mit schlichten Farben versehen werden, sondern nur mit 5e-Zuständen. Das war bei Shadow of the Demonlord unnütz und sehr schade.

[Grummelstein]

Ich fand die Tutorial Videos ganz interessant:
https://www.youtube.com/watch?v=qB1yvHRweeE&list=PLYIWWqS_XJXhfdvzy5UaojlBXBfB4Ujxn

Ich finde es halt schade, das die neue kostenlose Variante so stark beschnitten ist. Owlbear Rodeo speichert dann max. 2 Räume, also Spiele gleichzeitig. Aber ich kann auch verstehen das sie für das Tool gerne Geld hätten. Ich spiele aber einfach zu wenig für solche Abos.
Was mir gefällt, falls es wirklich so ist, das Owlbear Rodeo auch auf mobilen Geräten funktioniern soll. Ist bei Roll20 ja leider nicht so.

[Germon]

Och, nö!
Ich habe Owlbear Rodeo 1.0 vor Kurzem erst kennen gelernt und war/bin sehr angetan. Das 2.0 habe ich auch angeschaut. Das hat mir aber nicht gefallen.

[schneeland]

Auf dem Owlbear-Discord hieß es mal, dass sie v1.0 eventuell als Open Source freigeben, wenn die v2.0 startet. Dann könnte man auch seine eigenen Eulenbären aufsetzen. Ich weiß allerdings nicht, wie weit das gediehen ist oder ob die Idee wirklich weiterverfolgt wurde.

[Germon]

Auf dem Owlbear-Discord hieß es mal, dass sie v1.0 eventuell als Open Source freigeben, wenn die v2.0 startet. Dann könnte man auch seine eigenen Eulenbären aufsetzen. Ich weiß allerdings nicht, wie weit das gediehen ist oder ob die Idee wirklich weiterverfolgt wurde.

In dem von dir verlinkten Release Announcement ist davon die Rede, es ist aber kein Termin genannt.
Das klingt schon interessant, aber ob ich Technik DAU das dann hinbekomme... 

[schneeland]

Ah! Man sollte auch bis hinter das Video scrollen 

Nachdem ich selber mit ein paar Designentscheidungen bei OR 2.0 nicht wirklich glücklich bin, werd' ich mir mal anschauen, wie viel Aufwand das mit dem Self-Hosting ist. Vielleicht kann ich dann hier nochmal was dazu schreiben.

[Tintenteufel]

Oh! Das wäre ziemlich großartig!!

[Germon]

Oh! Das wäre ziemlich großartig!!

+1

[Selis]

eine eigene Inatalation der alten Variante wäre echt toll.
Ich hatte vor einigen Wochen die Beta ausprobiert und war unzufrieden

[Sard]

Der Mensch ist ein Gewohnheitstier und scheut Neuerungen.

Bis gestern habe ich die hier vorherrschende Meinung ähnlich gesehen.

Nachdem ich heute mal reingeschaut habe, sage ich, dass  die Version einige Verbesserungen bringt, so dass es sich insgesamt wohl die Waage hält.

[schneeland]

Mittlerweile ist die alte Version von Owlbear auf Github verfügbar: Link. Netterweise haben die Entwickler auch ein paar Anmerkungen dazu geschrieben. Leider zeigt sich dabei auch, dass es wohl doch etwas aufwändiger ist, diese Version selber zum Laufen zu bringen, weil für die Übertragung der Dateien auch WebRTC genutzt wird. Der Einfachheit halber die Anmerkungen nachfolgend auch hier (im Spoiler):

(Klicke zum Anzeigen/Verstecken)

This project marks one of the first big web projects Nicola and I made. With this in mind there are many things that aren't great with it.

The state management for the frontend relies primarily on React contexts. This is a bad idea. React contexts are great but not for a performance focused app like this. You'll see that every context that is used has to be split into a bunch of small chunks to prevent unnecessary re-renders. Don't do this. Just use a state management library like Zustand. It's so much easier and it's what we do in 2.0.

This code makes no effort to handle collisions when two users edit the same data at the same time. This means that it can be pretty easy to brick a map with a combination of delete/edit/undo between two users. Instead you should use a data structure that is designed to handle this like a CRDT. This is what we do in 2.0.

All images are stored client side in an IndexedDB database. I think this is a cool idea but browsers hate it when you do this. There are ways to tell the browser that you should keep this data around (the persistent storage API). But it's a bit of a mess. Chrome will silently decide if it wants to keep the data, FireFox will prompt the user for permission and Safari will ignore you. In fact if you don't visit the site every week Safari will delete all your data. I thought I was being pretty clever when I created 1.0 with no cloud storage but it bit us hard having to tell users every week that there was no way to recover their data because the browser was cranky at them.

Because this project doesn't have user accounts or cloud storage to share an image with other players we use a peer-to-peer connection. To do this we use WebRTC. Be warned though every time I've decided to use WebRTC in a project I've regretted it. WebRTC is great on paper but it will never be reliable. Many VPNs/Antivirus/ISPs will block all WebRTC traffic. So you end up having to proxy a bunch of traffic through TURN/STUN servers which end up eating up any cost savings you thought you were going to have.

There are some pretty cool things in the project though. I developed a Tensorflow model trained off of thousands of battle maps that can detect the number of grid cells visible in a map. The model is in the src/ml directory. The 3D dice roller is physics driven which makes it fun to just throw dice around. The pointer tool has a nice network interpolation model. This idea was expanded in 2.0 so that every interaction you do is synced in real-time with other players.

[Rentin]

Ich bin begeisterter Nutzer (mit 4 Spielern) von Owlbear Rodeo (aktuelle Version).
Daher hier nur ein paar kurze Worte:

Meine erstellten Karten, Token, Props (bewegliche Gegenstände), etc. kann ich schön groß machen (aktuelle Map 66 * 106 Felder) und dadurch entsteht ein Dungeoncrawl-Gefühl der 80er, sieht aber besser aus.
Es gibt einen Haufen Extensions für Nebel, Würfel, Maßbänder, Charakterbögen, etc.
Meine Liebste ist Smoke and Spectre. Damit kann ich die Sichtweiten aller Token anpassen, Türen und Wände auf meinen Karten platzieren.
Ich kann Gäste als Zuschauer dazu holen, deren Sichtweise anpassen.

Die Würfel funktionieren top, jeder Würfelwurf wird den anderen Mitspielern per Video angezeigt. Allerdings fehlen Spezialwürfel (die ich nicht benötige) in der Basisversion.

Jetzt kenne ich die anderen Möglichkeiten (roll20, vtt) nicht, aber ich bin so zufrieden mit Owlbear, dass mich das nicht stört.
Sobald ich allerdings von einem Tool erfahren in dem ich meine Dungeon Alchemist Karten mit 3D Ansicht nutzen kann... werde ich möglicherweise untreu.

[Nachtfrost]

Ich nutze Owlbear 2.0 auch seit zwei Jahren und bin sehr zufrieden. Die zwei Räume der kostenlosen Version reichen mir aus (1x D&D, 1x SW:EotE) und beim Speicherplatz der Assets bin ich auch noch nicht an die Grenze gestoßen. Prinzipiell wäre ich auch bereit zu bezahlen, aber noch kommen wir gut klar.
Die Bedienung ist intuitiver als bei Roll20 und Foundry. Gerade wenn ich mal on-the-fly Karten aus dem Netz reinziehe oder kurz was improvisiere. Die Einbindung der Würfelwürfe ist auch ganz nice.
Es könnte gerne ein paar mehr Extensions geben vor allem hab ich noch kein Online-Charaktersheet für 5E, bei dem sich meine Spieler eintragen und mit dem ich als SL glücklich bin. Owlbear ist im Vergleich zu Foundry auch sonst ziemlich basic, aber für meine Zwecke insgesamt gut ausreichend. Und erwähnte ich die einfache Bedienung?