Practical debugging

This page gives you practical tips to debug your game during the development. Don't hesitate to share with us your difficulties in order we can improve this section.

Tools

To work on BGA Studio, we recommend you to use [www.google.com/chrome Google Chrome] as it's the current fastest browser for BGA platform, and it's available in all OS.

Another reason to use Chrome is that it embed all tools you need to work on BGA Studio. You can see them by pressing "F12" or from the menu ("Tools > Development tools").

A good practice is to use a second browser to develop the game, in order to check that your game is working fine on this browser too.

To debug with Firefox browser, we advise you to use these 2 extensions:

• Firebug
• Web developper

To debug with Internet Explorer, we advise you to use one of the most recent version (ex: IE9). Last versions of Internet Explorer have way better development tools than the previous ones...

General tip for debugging

In general for debugging, think of using the 'save & restore state' functionality. It enables you to save the state of your game just before the issue you are investigating, then come back to that point with one click as many times as needed to understand what is going wrong.

You can save up to 3 different states.

Debugging my game when it cannot start

If your game don't start because of an error, you are probably in one of these situations:

• There is a SQL error in your dbmodel.sql file.
• You have a syntax error in your PHP file.
• Your PHP "setup" - or any method used during the game initial states - generates an exception.

If the error is not explicitly displayed when you click on "Express start", you should check the "Gameserver error log" as per Studio logs.

Debugging my PHP game logic (or my view)

Most of the time, debugging PHP is quite easy. Here's what I do when I want to develop/debug some game logic that is triggered by some game action:

• At first, I make sure that I can reproduce the needed game situation in one click. To do this, I use the "save & restore" function.
• Another possibility for this is to place a die('ok'); PHP statement right after the PHP I am developing/debugging. This way, I make sure that every request will fail and then nothing will be commited to the database, anyway.
• Then, I use var_dump function to dump PHP variables and check what's wrong, until it works.

Example:

// (...my code to debug)

var_dump( $my_variable );
die('ok');

// (...my code to debug)

Add traces to your code

You can use the following functions in your game to add server side logging:

self::debug( $message ); // debug level logging, goes to BGA request&SQL logs

self::trace( $message ); // info level logging, goes to BGA request&SQL logs

self::warn( $message ); // warning level logging, goes to BGA unexpected exceptions log

self::error( $message ); // error level logging, goes to BGA unexpected exceptions log

Check Studio logs for more details on how to access your logs.

This can be useful when you need to follow the flow of your code and not just stop it to see how it goes at some point.

Only the error log level will appear in production. This level should be used only for critical problems. Other levels will show only in the development environment and can be used as you see fit.

Debugging my HTML/CSS layout

Situation examples:

• why my game element doesn't show up in the interface?
• why my CSS property hasn't been applied to this element?
• why this game element is displayed at this position?

A first useful tip when an element does not show up in the interface is to give it a red background:

#my_element {
  ... some CSS definitions ...
  background-color: red;
}

This way, you know if the element is not visible because of some of its CSS property or because of anything else.

Another tip: sometimes, you change a CSS property with no visible effect on your interface. In that case, add a "display:none" property. If your element does not disappear, the bug probably comes from your CSS selector and not from your CSS property.

Using Chrome "Elements" tab (thre first one), you can:

• See the CURRENT HTML of your page. Remember that the classical "show page source" is inefficient with BGA as you are modifying the page source with your Javascript code.
• Using the "magnifying glass", you can click on any part of your game interface and check it's HTML code and associated CSS styles.
• You can even modify directly some CSS property and see if how it looks immediately on the game interface.

Debugging my Javascript game interface logic

Compare to PHP debugging, Javascript debugging can sometimes be painful.

Here's are some tips to make your life easier while developing and debugging Javascript:

Do complex things on PHP side

PHP side is more reliable and simpler to debug than Javascript. Then, when you need to perform a complex operation, check first it you can't write it on server side first.

The most frequent case is the following: you want to compute possible moves in a game situation. Doing it in Javascript is a nightmare. Then, do it on PHP, and transfer the result to your client interface using the "args" game state property.

Note: check Reversi example for this.

Add traces in your code

You can use the following:

console.log( variable_to_inspect )

It will give you the object structure of the variable in the Javascript console, without blocking the execution.

It's often a good idea to precede this call with a console.log( '### HERE ###' ); to find more easily the appropriate line in the console log.

alert( variable_to_inspect )

It will popup what you wish and pause the execution until you click ok.

This won't be useful for complex structures, only native types will get plainly displayed. But this is sometimes useful just with messages to make sure which way the execution goes.

Some frequent errors

See Troubleshooting.