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:
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].
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
- [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).
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).
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).