Your game mobile version

Game File Reference

Overview

• dbmodel.sql - database model
• fonts/ - game fonts
• gameinfos.jsonc - meta-information
• gameoptions.jsonc - game options & user preferences
• img/ - game art
• Game Metadata Manager - tags and metadata media
• material.inc.php - static data
• misc/ - studio-only storage
• modules/ - additional game code
• sounds/ - game sounds
• States/ - State classes
• states.inc.php - state machine
• stats.jsonc - statistics
• X.action.php - player actions
• X.css - interface stylesheet
• Game.php - main logic
• Game.js - interface logic
• X.view.php - dynamic game layout
• X_X.tpl - static game layout

---

Useful Components

Official

• ItemManager: a PHP component to manage cards or other game items.
• PlayerCounter and TableCounter: PHP components to manage counters.
• Draggable: a JS component to manage drag'n'drop actions.
• Counter: a JS component to manage a counter that can increase/decrease (ex: player's score).
• ExpandableSection: a JS component to manage a rectangular block of HTML than can be displayed/hidden.
• Scrollmap: a JS component to manage a scrollable game area (useful when the game area can be infinite. Examples: Saboteur or Takenoko games).
• Zone: a JS component to manage a zone of the board where several game elements can come and leave, but should be well displayed together (See for example: token's places at Can't Stop).
• bga-zoom : a JS component for zoom controls.
• bga-animations : a JS component for animations.
• bga-cards : a JS component for cards.
• bga-dice : a JS component for dice.
• bga-autofit : a JS component to make text fit on a fixed size div.
• bga-score-sheet : a JS component to help you display an animated score sheet at the end of the game.
• bga-jump-to : a JS component to add board shortcuts

Deprecated

• Deck: a PHP component to manage cards (deck, hands, picking cards, moving cards, shuffle deck, ...).
• Stock: a JS component to manage and display a set of game elements displayed at a position.

Unofficial

• BGA Code Sharing - Shared resources, projects on git hub, common code, other links
• BGA Studio Cookbook - Tips and instructions on using API's, libraries and frameworks
• Common board game elements image resources
• Using AI for BGA game development

---

Game Development Process

• First steps with BGA Studio
• Create a game in BGA Studio: Complete Walkthrough
• Tutorial reversi
• Tutorial hearts
• BGA Studio Guidelines
• BGA game Lifecycle
• Pre-release checklist
• Post-release phase
• Player Resources - add player help/rules to your game page

---

Guides for Common Topics

• Translations - make your game translatable
• Game Replay
• Mobile Users
• Compatibility

---

Miscellaneous Resources

• Studio FAQ
• Tools and tips of BGA Studio - Tips and instructions on setting up development environment
• Studio logs - Instructions for log access
• Practical debugging - Tips focused on debugging
• Troubleshooting - Most common "I am really stuck" situations
• Studio Bugs - Reports against Studio itself (not BGA!)

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 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 scales the whole game document through a wider logical viewport.

Previously, when game pages were opened directly, BGA set the document viewport width and let the mobile browser fit it to the screen.

Games are now normally opened through /tableview. The game runs in an iframe, and its viewport cannot resize that iframe. Tableview emulates the same result by laying out the iframe at the requested width and applying transform: scale(...) to it.

In the example, the iframe is laid out at 740 pixels and displayed at approximately 53% scale. The game area and the BGA controls inside the iframe are scaled together.

CSS zoom participates in layout. transform: scale(...) scales after layout and usually creates a composited layer. Transforming a large iframe can be expensive on mobile devices.

Prefer autoscale: true or a responsive layout unless viewport scaling is required for compatibility.

​Legacy default_viewport

Some older games contain code such as:

 this.default_viewport = "width=740";

default_viewport started as internal framework state. Games later used it as an undocumented viewport override before game_interface_width.autoscale existed.

It remains supported to avoid breaking published games. In tableview, it enables the same iframe scaling as autoscale: "viewport" and takes precedence over the configured autoscaling mode.

Do not use it in new code. Existing games should test removing it and use game_interface_width instead.

​Mobile rendering performance

Large transformed interfaces can crash iOS browsers during pinch zoom. See BGA bug #229359 and WebKit bug #172206.

Reduce the risk:

• keep interface dimensions reasonable;
• reduce image pixel dimensions and file sizes;
• avoid unnecessarily large sprite sheets;
• limit large fixed or transformed elements;
• avoid unnecessary animation, canvas, and WebGL rendering.

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.