This is a documentation for Board Game Arena: play board games online !
Your game mobile version: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 58: | Line 58: | ||
=== Autoscale === | === Autoscale === | ||
<code>game_interface_width.autoscale</code> controls what happens when the available width is smaller than <code>min</code>. It accepts <code>true</code>, <code>false</code>, or <code>"viewport"</code>. The default is <code>true</code>. | <code>game_interface_width.autoscale</code> controls what happens when the available width is smaller than <code>game_interface_width.min</code>. It accepts <code>true</code>, <code>false</code>, or <code>"viewport"</code>. The default is <code>true</code>. | ||
The examples below use a 740-pixel game displayed in 390 pixels of available space. | The examples below use a 740-pixel game displayed in 390 pixels of available space. | ||
| Line 93: | Line 93: | ||
==== <code>autoscale: "viewport"</code> ==== | ==== <code>autoscale: "viewport"</code> ==== | ||
This mode | This mode presents the whole game through a wider logical viewport. The game area and the BGA interface around it are scaled together, preserving their relative sizes and layout. | ||
This option exists as a compatibility fallback. CSS <code>zoom</code> has behaved differently across browsers and has broken coordinate calculations or animations in some older games. Viewport scaling can keep those games working without rewriting their layout. | |||
It also has important drawbacks: | |||
* action bars, player panels, dialogs, and other game-page controls are scaled down with the game; | |||
* text and controls can become very small; | |||
* the layout does not adapt to the available space; | |||
* scaling the entire game document is more expensive to render. | |||
Do not use viewport scaling as a shortcut for building a responsive interface. Prefer <code>autoscale: true</code> or responsive CSS unless the game has a confirmed compatibility problem with CSS zoom. | |||
Prefer <code>autoscale: true</code> or | |||
{{Warn|1= | {{Warn|1= | ||
'''Legacy <code>default_viewport</code>''' | '''Legacy <code>default_viewport</code>''' | ||
Some older games | Some older games set the internal field <code>default_viewport</code> directly: | ||
this.default_viewport = "width=740"; | this.default_viewport = "width=740"; | ||
This undocumented workaround predates the <code>autoscale</code> option. It is still supported to avoid breaking published games, but now has the same effect as <code>autoscale: "viewport"</code> and takes precedence over the configured mode. | |||
It | |||
'''Do not use it in new code.''' Existing games should test removing it and configure scaling through <code>game_interface_width</code> instead. | |||
}} | }} | ||
Revision as of 16:54, 23 July 2026
Board Game Arena supports mobile phones and tablets. Most games are already playable on touch devices, but their layout and interactions still need to work on narrow screens.
Declare your interface minimum width
game_interface_width.min is the smallest logical width at which your game remains usable. The default is 740 pixels.
Declare it in gameinfos.jsonc:
"game_interface_width": {
// Smallest usable width. Default: 740
"min": 540,
// Default: true
"autoscale": true
}
The declared width must actually work. If you declare 540 pixels, the complete interface must remain usable at 540 pixels.
Keep the minimum as low as reasonably possible. Large values require stronger scaling on phones, make content smaller, and increase rendering work. Use fluid layouts and CSS media queries instead of declaring a large fixed width.
Below 490 pixels, player panels may no longer use a two-column mobile layout.
Examples:
- In Can't Stop, the dice are moved below the board on narrow screens:
@media only screen and (max-width: 990px) {
#dicechoices {
left: 180px;
top: 530px;
}
#cantstop_wrap {
height: 900px;
width: 550px;
}
}
- In Seasons, panels normally displayed to the right of the board are moved below it:
@media only screen and (max-width: 970px) {
#board {
float: none;
margin: auto;
}
.seasons_rightpanel {
margin-left: 0;
}
}
On mobile, BGA moves player panels above the game and adds mobile_version to #ebd-body. The desktop layout uses desktop_version. Use these classes for layout-specific CSS.
Autoscale
game_interface_width.autoscale controls what happens when the available width is smaller than game_interface_width.min. It accepts true, false, or "viewport". The default is true.
The examples below use a 740-pixel game displayed in 390 pixels of available space.
autoscale: true
BGA applies CSS zoom to the game content. In the example, the scale is approximately 53%.
The game content scales independently from the surrounding BGA interface:
- the top bar and tableview chat keep their normal size;
- the action bar and player panels use separate framework scaling on very narrow screens;
- standard BGA dialogs and tooltips generally keep their normal size;
- overlays inside the game area inherit the game zoom.
This is the default mode and should suit most fixed-width games.
Coordinates and animations
Browsers do not return consistent geometry for elements using CSS zoom. For custom positioning inside the zoomed game area, use:
const rect = this.getBoundingClientRectIgnoreZoom("my-element");
It returns logical, unscaled coordinates. BGA animation and positioning helpers already account for framework zoom.
Use the native getBoundingClientRect() when you need the visual position in the browser viewport, such as for an overlay outside the zoomed game area.
autoscale: false
BGA does not scale the game area.
Use this for responsive games or games with their own scaling system, such as BgaZoom. A fixed 740-pixel layout displayed in 390 pixels will otherwise overflow horizontally and may require scrolling.
autoscale: "viewport"
This mode presents the whole game through a wider logical viewport. The game area and the BGA interface around it are scaled together, preserving their relative sizes and layout.
This option exists as a compatibility fallback. CSS zoom has behaved differently across browsers and has broken coordinate calculations or animations in some older games. Viewport scaling can keep those games working without rewriting their layout.
It also has important drawbacks:
- action bars, player panels, dialogs, and other game-page controls are scaled down with the game;
- text and controls can become very small;
- the layout does not adapt to the available space;
- scaling the entire game document is more expensive to render.
Do not use viewport scaling as a shortcut for building a responsive interface. Prefer autoscale: true or responsive CSS unless the game has a confirmed compatibility problem with CSS zoom.
default_viewport
Some older games set the internal field default_viewport directly:
this.default_viewport = "width=740";
This undocumented workaround predates the autoscale option. It is still supported to avoid breaking published games, but now has the same effect as autoscale: "viewport" and takes precedence over the configured mode.
game_interface_width instead.Touchscreen compatibility
BGA adds touch-device to #ebd-body when it detects a touchscreen, and notouch-device otherwise.
CSS :hover
Touch devices have no persistent mouse cursor. Some emulate :hover after a short touch, which can block the intended interaction. Prefix hover-only rules with .notouch-device when they should not apply to touchscreens.
Tooltips
Do not make required information available only through hover. Provide a touch-accessible alternative.
Mouse events
Do not rely only on mouse-specific events such as mouseover. Prefer the Pointer Events API, which supports mouse, touch, and pen input.
Drag and drop
Common approaches:
- Pointer Events API
- Example: https://codepen.io/VictoriaLa/pen/MWOgYYZ
- Game example: Century
- Native HTML drag and drop
- Example: https://codepen.io/VictoriaLa/pen/rNGXKxj
- Game example: Patchwork
Add touch-action: none only to elements where you handle touch or pointer gestures and need to suppress native scrolling or zooming.