Game interface stylesheet: yourgamename.css

Game File Reference

Overview

• dbmodel.sql - database model
• gameinfos.inc.php - meta-information
• gameoptions.json - 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
• states.inc.php - state machine
• stats.json - statistics
• X.action.php - player actions
• X.css - interface stylesheet
• Game.php - main logic
• X.js - interface logic
• X.view.php - dynamic game layout
• X_X.tpl - static game layout

---

Useful Components

Official

• Deck: a PHP component to manage cards (deck, hands, picking cards, moving cards, shuffle deck, ...).
• 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).
• Stock: a JS component to manage and display a set of game elements displayed at a position.
• 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).

Undocumented component (if somebody knows please help with docs)

• Wrapper: a JS component to wrap a <div> element around its child, even if these elements are absolute positioned.

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

---

Game Development Process

• First steps with BGA Studio
• Create a game in BGA Studio: Complete Walkthrough
• Tutorial reversi
• Tutorial gomoku
• 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
• 3D
• 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!)

This is the CSS stylesheet of your game User Interface.

Styles defined on this file will be applied to the HTML elements you define in your HTML template (yourgame_yourgame.tpl), and to HTML elements you create dynamically with Javascript.

Usually, you are using CSS to:

1°) define the overall layout of your game (ex: place the board on the top left, place player's hand beside, place the deck on the right, ...).

2°) create your CSS-sprites: All images of your games should be gathered into a small number of image files. Then, using background-image and background-position CSS properties, you create HTML blocks that can display these images correctly.

Example:

    Example of CSS sprites (a black token and a white token, 20x20px each, embedded in the same "tokens.png" 40x20px image):

    .white_token {
        background-image: url('img/tokens.png');
        background-position: 0px 0px;
    }
    .black_token {
        background-image: url('img/tokens.png');
        background-position: -20px 0px;
    }
    .token {
        width: 20px;
        height: 20px;
        background-repeat: none;
    }

3°) ... anything else:

It is really easy to add and remove CSS classes dynamically from your Javascript with dojo.addClass and dojo.removeClass. It is also easy to check if an element has a class (dojo.hasClass) or to get all elements with a specific class (dojo.query).

This is why, very often, using CSS classes for the logic of your user interface allow you to do complex thing easily.

Note: on the production platform, this file will be compressed and comments will be removed. Consequently, don't hesitate to put as many comments as necessary.

Important: ALL the CSS directives for your game must be included in this CSS file. You can't create additional CSS files and import them.

Warning: using percentage in background-position

In the example above, you will see "background-position: -20px 0px;" is used for the black token. You could also write this as "background-position: -100% 0%;" which displays the image at the same offset, because it is relative to the size of the .token bounding box, and this means the size of your image file doesn't need to precisely match the size of objects on the screen (this can be easier to write, and you can also substitute different image files without having to rewrite all the css.) However, it is strongly recommended that if you do this, you also specify background-size as a percentage as well.

This is because, if the size of the div on screen after any further scaling - which is done for you by the framework to fit games into small windows - is not a whole integer number of pixels, then rounding must occur at some points in the calculation; if the background-size and background-position are calculated in different ways, the difference in rounding can result int the final image offsets being incorrect. This is most significant on Safari (on MacOS, iPhone and iPad) where the discrepancy can be substantial enough to make a game illegible; but other browsers can be off by a few pixels as well. (external demo). To avoid this issue, either:

• choose one unit (pixels, em, percentages etc) and specify all the background-size and background-position offsets of a div in the same unit.
• adjust the size of your div so that, after any global scaling (this.gameinterface_zoomFactor), it will occupy an integer number of pixels on the screen.

Warning: using Z-index

You may use z-index CSS property in your game interface, but you should pay attention to the following: BGA dialogs are displayed with a z-index of 950. If you want to use z-index safely, you should use value lower than 900.

About z-index: don't forget that if you are using a z-index, your element will be displayed above all elements that do not have a z-index. So it's no use to have big z-index values: 1 is enough most of the time :)

Warning: using drop-shadow

Drop shadows can look nice, but they currently cause big performance issues on Safari, especially if you have more than 1 on the page at once. To ensure you don't cause issues on this browser, you have some alternatives.

• Use box-shadow instead. This only works for square drop-shadows.
• Bake the shadow into the image. That is, the png contains the shadow, and no shadow is needed on the css side. This only works when the shadow doesn't need to be dynamic.
• Disable drop-shadow in Safari:, using the dj_safari class which is automatically added to the html tag.

.game-element {
    filter: drop-shadow(3px 3px 4px rgba(0,0,0,0.7));
}

html.dj_safari .game-element {
    filter: none;
}

Tip: how to make your cards looks beautiful :)

This piece of CSS (to adapt to your needs) is adding rounded corners + a shadow to your card.

    border-radius: 10px;
    border: 1px black solid;
    box-shadow: 5px 5px 5px 0px rgba(0,0,0,0.4);

spectatorMode

When a spectator (= a player that is not part of the game) is viewing a game, the BGA framework add the CSS class "spectatorMode" to the wrapping HTML tag of your game.

This way, if you want to apply a special style to some elements of your game for spectators, you can do this in your CSS:

.spectatorMode #your_element_id {
    /* your special style */
}

The most common usage of this is to hide some elements to spectators. For example, to hide "my hand" elements:

.spectatorMode #my_hand {
    display: none;
}