samcf / ogres Goto Github PK

The websocket server will timeout connections that have not received or sent messages within the last 5 minutes. Either the server or client should periodically send PING messages.

• Is this an application-specific PING or something inherent with the WebSocket protocol?
• Should the server send these PINGs to clients, or vice-versa?

Consider the following improvements...

• Scale font size with zoom level, increasing them when zoomed out and decreasing them when zoomed in.
• Render token label with foreignObject to avoid SVG font rendering.
• Re-arrange token rendering order by vertical position so that tokens higher up on the screen are rendered last.
• Use background color to emphasize font instead of hacky text stroke.

The behavior is correct for the host view, but incorrect for player views.

Currently, players are invariably pulled into whichever scene the host opens, whether or not the host is ready for them to be there or not. This was done as a hack when first building out the multiplayer experience. This behavior is limiting since the scene is not always fully prepared by the time the players need to be moved to it.

This feature should allow hosts to create new scenes or open existing ones without automatically pulling players into it. This will give the host the freedom to explore and setup the scene and provide an explicit button that, when clicked, will pull the players into the scene using the host's current view.

This will also allow the host to focus the players on a new point in the existing scene.

Provide advanced initiative functionality, such as...

• Cycle forward and backwards through the initiative order
• Display number elapsed turns, rounds, and in-game time

In order to ensure that everyone in a multiplayer session is on the same release version, include the host's current version in the shared URL.

Example
https://ogre.tools?r=v1.1.0&join=mPxVZvZF8G

Hosts should be able to control what connected players are allowed to see and interact with during a multiplayer session.

There will be new toolbar buttons for the following actions and modes:

Snap
Player views are immediately transitioned to the current view of the host, but they can continue to pan and zoom their view freely.

Snap and lock
Player views are immediately snapped to the current view of the host, they can no longer pan or zoom their view, but they are not synced with the host's view.

Snap, lock, and sync
Player views are immediately transitioned to the current view of the host, they can no longer pan or zoom their view, and their views are synced with the view of the host until disabled.

Hosts may want to ensure that players can or cannot see the grid provided by the application. This improvement gives hosts a way to control and lock this setting for all players in the room.

There should be two new options in the "Friends" multiplayer panel form.

"Share cursors"
Toggles the live sharing of cursors for everyone. This option is only available to the host.

"Share my cursor"
This toggles the visibility of your own cursor for other players in the session and is available for everyone.

Fingers pulling apart should zoom in, fingers pulling in should zoom out.

Sharing the player view window over Discord or Zoom is a decent, effective way to create a collaborative experience. There are some pretty serious limitations, however.

• The operating system doesn't want to update windows that are hidden behind other windows; this forces the host to keep the player view window visible on their own computer.
• Players are limited to telling the host what they'd like their character to do and cannot move their own tokens.
• It is much less of an immersive experience; far removed from the traditional round table setup. Players feel more immersed in the experience if they can directly control the objects on the canvas.
• The visual quality and detail is vastly improved by rendering directly on the player's browser instead of through a video conference.

Many other virtual tabletops allow hosts to invite players to participate in a multiplayer lobby through the browser. This story represents the first step towards a more collaborative tabletop experience.

• The host may turn their session into a public lobby which can be accessed by anyone with the private URL that is shared by the host to the players.
• The players navigate to the given URL and can see the canvas and all the publicly visible elements on it.
• Players are restricted to only being able to move the camera around.

Right now, conditions and flags are only visible in token options and the initiative track. This work would render the conditions as small icons around the token itself.

Some things to think about...

• Make sure nearby adjacent tokens don't cover up the condition icons.
• Make sure tokens can bear to have all conditions at once without too much visual clutter.
• Include markers for "player", "hidden", and "in initiative" flags, as well.
• Optimize for at most 3 conditions on a token at any given time.

Having 6 or more conditions on a single token is very rare, and I'd like to optimize for condition legibility instead. Limit displayed conditions to 4 and make each larger in proportion.

Consider simply removing the "W" shortcut altogether since it is not that useful.

Consider the fonts offered by https://systemfontstack.com/

Serif

font-family: Iowan Old Style, Apple Garamond, Baskerville, Times New Roman, Droid Serif, Times, Source Serif Pro, serif, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol;

Monospace

font-family: Menlo, Consolas, Monaco, Liberation Mono, Lucida Console, monospace;

Players should started focused on the host's current view and not the top left corner of the scene.

Strange box rendered around selected tokens in Chrome. Kind of looks like a focused state on an input object.

This is likely caused by the way the application tracks whether or not the "Shift" key is currently depressed; we track key down and key up events, which can be unreliable.

Look into changing the render order for tokens from largest to smallest so that small tokens are always rendered on top of larger ones.

Introduce new tools for cutting, copying, and pasting tokens within a scene or across scenes.

One use case this is particularly useful for is when moving player character tokens between scenes, especially if there are, for example, many floors to a tower that they are moving up and down within. Cutting the tokens from one scene and pasting them into another saves a lot of time.

Copying tokens should preserve the following attributes:

• Image
• Label
• Size
• Conditions
• Visibility
• Lighting

The following attributes should not be preserved:

• Position
• Initiative

These new commands should be available as shortcuts:

ctrl + x for cut
ctrl + c for copy
ctrl + v for paste

Both hosts and players should be able to perform these actions freely.

Pasted tokens should appear in the center of the view. Multiple tokens should be pasted with minor horizontal adjustment so they don't all lay on top of each other.

Possibly caused by removing the unique React key that was added to the canvas element.

Currently, changing the size of a token does not also scale its label or condition flags. There is also considerable effort put into manually scaling the token element.

Consider using transform: scale(x, x) to scale the token parts uniformly.

It can be a huge pain in the ass if you accidentally close a window with a bunch of tokens and stuff on it. The application should prompt users to confirm when closing windows that seem to be in use.

When in a multiplayer session, draw the cursors of other players (and the host) on the screen.

https://icons.getbootstrap.com/icons/cursor-fill/

• Assign unique colors to every connection in the session.
• Fill the cursor with the assigned color.

As a player in a multiplayer session, it is very jarring when your selected panel tab changes when the host changes the workspace. This has made it obvious to me that panel state is not scoped to the current workspace, but to the local user state. Both the currently selected panel and the collapse state should be elevated to the local user scope.

When a player is disconnected from the multiplayer session, periodically attempt to retry establishing a connection to the room using the same key. The retry time should be randomized to help reduce "stampeding herd" conditions.

It's very helpful to know how far, in feet relative to the grid size, you are dragging a token.

• Display a move distance next to the token being dragged relative to its original position.
• Display the original position of the token as a "ghost" token.
• Display a line connecting the original position and its new position.

When a host creates a new multiplayer session, attempt to use the last used room key for the session identifier. This will prevent the host from needing to redistribute a new room key to the players, and ideally require no action on the players part to reconnect at all once automatic retries are implemented.

One of ogre.tools most important priorities is ease of use and low barrier to entry. Users can upload images directly from their computer and are not asked to crop and resize these images. It doesn't attempt to modify the image at all.

This works great when you are the only consumer of these images. However, sharing these images over the network to many different players on the session may introduce long loading times since these uncompressed images are sometimes very large; in both file size and dimensions.

The application should resize and compress token images via HTML Canvas before adding them to state and cache.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toBlob

Some concerns

• Is the checksum of the compressed image deterministic? The app should prevent uploading the same image twice, resulting in duplicates.

The following conditions are not supported:

• Deafened
• Poisoned
• Paralyzed
• Petrified
• Restrained
• Stunned

We can support another row of 5 conditions, at least.