This is a documentation for Board Game Arena: play board games online !

Studio logs

З пляцоўкі Board Game Arena
Перайсці да навігацыі Перайсці да пошуку
Studio Framework Navigation

File structure of a BGA game

Game logic (Server side)
Game interface (Client side)
Other components
BGA Studio game components reference
  • Deck: a PHP component to manage cards (deck, hands, picking cards, moving cards, shuffle deck, ...).
  • Counter: a JS component to manage a counter that can increase/decrease (ex: player's score).
  • 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)

  • Draggable: a JS component to manage drag'n'drop actions.
  • ExpandableSection: a JS component to manage a rectangular block of HTML than can be displayed/hidden.
  • Wrapper: a JS component to wrap a <div> element around its child, even if these elements are absolute positioned.
BGA Studio user guide


BGA Studio logs are available directly from your game development interface.

Logs allows you to check out what happened recently on server and to debug your game.

BGA request&SQL logs

This log is useful:

  • When you want to check what SQL requests has been built during a request.
  • When you want to debug your PHP code using "self::trace"
  • When you want to know why a request takes too many time.


On this log, you can see:

Your requests

Example:

 20/06 21:50:56 [info] [T403] [4/mytest0] /cinco/cinco/exchange4Cards.html?id=4&lock=97d1c7a1-903a-4d1f-8206-de39ce8204fc&table=403&testuser=4&dojo.preventCache=1371757856044

Note that the best way to check your Ajax request is to read the [Input/Output section].

Request responses

Example:

 20/06 21:50:56 [notice] [T403] [4/mytest0] OK-0 169 d141 c8 e0 I9 A158 V0 T0 /cinco/cinco/exchange4Cards.html?id=4&lock=97d1c7a1-903a-4d1f-8206-de39ce8204fc&table=403&testuser=4&dojo.preventCache=1371757856044

You can recognize a response because it contains [notice]. Usually, there is one response for each request.

Let's details the beginning of the log:

  • 20/06 21:50:56: the date
  • [notice]
  • [T403]: this is a log from table 403
  • [4/mytest0]: this is use "mytest0", with id 4
  • OK-0: it means that the request ended up successfully, with no exception (expected or unexpected).
  • 169: this is the time taken to process the request (169ms).
  • d141: this is the total Database time used to process the request (141ms).

SQL requests

Example:

 20/06 21:50:56 [info] [T403] [4/mytest0] 0.26 SELECT player_tokenColor FROM player WHERE player_id ='4'

All requests to Database are traced in this log. You can see here the time take by the request (0,26ms).

Custom trace

You can use special PHP methods in your PHP code to left some trace in this log:

  • self::trace( "your message here" ); // Display "your message here" in the log
  • self::dump( "My variable", $variable_to_dump ); // Display the content of $variable_to_dump in the log

BGA unexpected exceptions logs

In this log you can check the last Unexpected exceptions from your game.

Exceptions management on PHP side [is described here].

The log displayed the complete stacktrace of the exception, so you can debug it.

The SQL log is very verbose and sometimes it too hard to extract your tracing from it, in this case you can use error log for tracing temporarily. You can add debug statement using self::warn() which will appear in that the log. Do not leave these tracing method calls after you done debugging unless they are real warnings or errors (only the error log level will appear in production).