Pen & Paper - Rollenspiel > VTT - Virtual Tabletop - alles zum virtuellen Spieltisch

Owlbear Rodeo

<< < (3/3)

Germon:

--- Zitat von: Tintenteufel am 29.04.2023 | 14:26 ---Oh! Das wäre ziemlich großartig!!

--- Ende Zitat ---
+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)
--- Zitat von: Owlbear Rodeo ---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.

--- Ende Zitat ---

Navigation

[0] Themen-Index

[*] Vorherige Sete