mirror of
https://github.com/ArnoldSmith86/virtualtabletop.git
synced 2026-03-02 22:57:02 -05:00
"Mirror" widgets #457
Labels
No labels
PCIO compatibility
Validator
automated testing
bug
documentation
duplicate
editor
enhancement
enhancement
library
library
maintenance
needs legacy server
pile related
reported client crash
routine operations
user interface
widget properties
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/virtualtabletop#457
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mousewax on GitHub (Dec 20, 2021).
A widget that displays an exact copy of another widget and everything inside of it, including their states.
Players cannot interact with anything on the Mirror widget aside from the
enlargemouse over but the Mirror can have its own position, rotation, and scale (but identical height and width).This would be useful for games where you have your stuff directly in front of you but still see the tableaus of other players in other spots.
Card games where left and right matter could also be simulated without rotating the room or translating x/y coordinates.
If I put a card in the main holder, all of the mirrors display that same card.
If I flip that card over, all of the mirrors display the now flipped-over card.
If I drag a meeple into that holder, all the mirrors will show a meeple in the same spot.
My player board stays nice and big and my opponents boards only have to be big enough that I can tell what they are doing:
When it's your turn, your player board gets a thick red outline, which means other people will see your smaller player board with that thick red outline so you know whose turn it is if that's part of the game. If the
seatis in that widget, all f the styling is applied to that mirror seat.Maybe Tichu?
@robartsd commented on GitHub (Dec 20, 2021):
I like the idea, but it seems like it would be difficult to implement (much more difficult to implement than a free camera table would be). We would basically need the mirror to keep a "shadow copy" of each of widget's children. Other player's cursors would also still move in "My play area" rather than the area for the other player. Game designers might need to be responsible for the application of any custom stylesheet rules (I have no idea how the selectors would work). Hover effects would not be mirrored (but hover effects are per client anyway, so that wouldn't matter for your use case).
@robartsd commented on GitHub (Dec 20, 2021):
Your use case does not actually require a "mirror", just separate viewports with each player having the viewports arranged and scaled differently. If the actual widgets were descendants of the viewports, the challenges of synchronizing the "shadow copy" and associated styles goes away.
@mousewax commented on GitHub (Dec 20, 2021):
I guess I don't know how viewports fixes this kind of issue. Is there an issue or PR or discussion somewhere I can look at? I know of them, but know nothing about them really.
@robartsd commented on GitHub (Dec 21, 2021):
They don't exist yet. It's just an alternate idea. Rather than "mirror" a widget, you'd create viewports. The key thing is that the actual interactive widgets will live in the viewport rather than being some sort of copy of the actual widgets. Different seats would have a different layout of the viewports.
@robartsd commented on GitHub (Dec 21, 2021):
Perhaps we need the concepts of 'surface' and 'viewport'. Each viewport would be a direct descendant of
#roomArea. Each viewport could display one surface (and each surface could appear in at most one viewport); but the assignment of surface to viewport might be different in different clients and surfaces not assigned to a viewport could exist in a hidden DOM element. Within a viewport the view of a surface might be translated, scaled, or rotated. All widgets would belong to a surface (either directly or through theirparentwidgets). By default,#roomAreawould contain one viewport filling the room and containing a fixed view of the default surface.@RaphaelAlvez commented on GitHub (Dec 21, 2021):
What you are asking is a view section of the room, even if you cannot interact with it and if is is constrained to one widget.
I believe a broader option would be to be able to interact with the other side and to be set and section of a room.
Another thing we tend to consider is how would this related to irl board games. I think we can maybe think of it as a side table or simply a way to represent sections of a table.
@robartsd commented on GitHub (Dec 21, 2021):
To be clear, this is what OP asked for (widget including descendant widgets).
This sounds like what I am proposing as an alternative. I do impose the limitation that noting can be duplicated - each widget is on only one surface (synchronized across all clients) and each surface is in only one viewport (the surface to viewport relationships might not be the same in all clients).
@ArnoldSmith86 commented on GitHub (Dec 21, 2021):
Your use case would also be solved by my proposed
playerOverrides(in #878) where you could set position and scale per player. So there wouldn't be a copy; the actual widget would be smaller and somewhere else for other players.That would be trivial to implement.
@ArnoldSmith86 commented on GitHub (Dec 21, 2021):
The more I think about
playerOverridethe more I think we should just add it. Withownerarrays and complicated cloning it can be done already anyway and it would give a lot of power that would be way easier to use.It doesn't mean we can't support viewports and free cameras as well.
@robartsd commented on GitHub (Dec 21, 2021):
That solution does require the game designer to implement a lot of the machinery; but would be possible (player cursors would remain an issue).
@ArnoldSmith86 commented on GitHub (Dec 21, 2021):
The first example would be pretty easy to do. Every player area has a scaled down spot on the left and each has a playerOverride for its owner.
It's also easy to set rotation of a whole game board per player but you would probably notice very quickly that many children have to be rotated back so your chess pieces aren't upside-down and you can read text.
I'm not saying it's the perfect solution but it might be a nice tool in the toolbox. 🤷♂️
@mousewax commented on GitHub (Dec 22, 2021):
These are all very interesting ideas. I don't think I have my head wrapped around how viewports would work. The idea of
playerOverrideis interesting. In your example it had a player name, but I assume it would actually be tied to a seat?@ArnoldSmith86 commented on GitHub (Dec 22, 2021):
Hmm, that sounds interesting. Should probably support both.