Edit Mode Debug

The Debug button of the Edit Mode Menu (right sidebar) displays the debug information for recently activated routines together with a game validation table.

Displays the debug information for recently activated routines.

If you want to follow along with this portion of the documentation in a live room, load up the Hangman game from the Public Library. Click on Edit Mode. Then make sure the Debug button on the Menu is active. Uncheck the box in the top right that says "Clear after each interaction." Start a game by pressing the "1 player button" (using the mouse button that you have set to interact in game mode), then press the "J" button. You should see the screen below (this may vary slightly depending on what other Menu buttons you have active, but in the screenshot below, only the Debug button is active):

The first line indicates that what follows is the clickRoutine for the 1Pbtn widget. Each line after that is a single function in that routine; by comparing with the text at the right, you can see that this is the case. The information on each line tells you what was done, and what the results were. After the lines of that clickRoutine, you can see the clickRoutine for the letter J widget. Since you activated 2 clickRoutines for this example, the Debug shows the output of both of them. Take a look at the letter J entry. The first line inverts the clickable property for the widgets in thisButton (which contains only letter J), while the second line puts the widget mainCheck into the DEFAULT collection. At the end of the line, in grey, is the time in milliseconds that it took to complete the operation. If you notice lag time in your room during routine execution, you can look at these times to get an idea of where the slowdown is taking place.

You can get more detail on any of these operations by clicking on a line with a triangle on it. For example, clicking on the final line in the letter J debug information produces:

Here you can see what happened when the letter J routine caused a click on each button in the DEFAULT collection (in this case, the mainCheck button). The purpose of this routine is to check if the guessed letter is in fact in the word, and to fill the appropriate blanks with the letter if it matches.

Next, note that the CLICK function in the letter J clickRoutine has no explicit parameters. To see how this function was interpreted, click on the line labeled "Original and applied operation". This shows you the function as it appears in the JSON together with the fully expanded version:

If the original function invocation had had a variable expansion, for example

    {
      "func": "CLICK",
      "count": "${number}"
    }

then the applied operation would show you what value had been substituted for ${number}.

If you also click on the final line in the CLICK function invocation, labeled "Variables, collections and delta afterwards", you will see the variables and collections that are defined at the end of that function invocation:

The variables that every routine starts with anyway - playerName, playerColor, seatID, seatIndex, thisID, mouseCoords, activePlayers, activeColors and activeSeats - are not part of that list, since they would repeat unchanged on every single operation. They sit behind a Built-in variables expander below it instead, so what you see first are the variables the routine itself works with. If a routine assigns a variable that happens to have one of those names, it stays in the main list, where you can see the value it was given.

Finally, suppose that your JSON contained some error. For example, if you change the relation in the SET function of the letter J clickRoutine to "no such relation" and click the button, the debug information, after a little bit of expansion, looks like this:

From this, you can find, from the red text, the offending statement, together with an explanation of what is wrong. If the erroneous statement is nested within some routines or other nested construct, the expandable arrows for the ancestors of that statement will be red as well. This allows you to quickly locate any erroneous statements.

Below the routine execution area there is a game validation table. The table checks for a variety of possible errors that may not show up when playing a game or when examining routine debug statements. In this game, there are multiple reports of "unrecognized and seemingly unused) property. This means that there are properties on the identified widgets that are not used by any routine. That is not necessarily a problem, but it would be a good practice to remove those unnecessary properties. Many games that were implemented before 2026, like Hangman in this example, will have validation issues like this that do not impact the operation of the game.

The messages in the table will indicate various types of problems that may exist. For example: there could be an undefined collection or variable, there may be cards in the deck that have not been added to the room, widgets that are mentioned in routines but are missing, properties in deck "faceTemplates" that are both directly set and in the "dynamicProperties", and other problems. Also, if you have both the debug and the JSON menu buttons selected and are looking at both at the same time, then clicking on a widget in the table will take you to that widget and to the line with the problem.

The validation table is updated as changes are made in the room. However, if the validation code starts to slow things down it will detect that and you will see a button like the one below instead. Press it to run the validation code and update the table.

Finally, if there are no validation errors being reported, you get this message: