Create, deploy, and maintain analytic applications that engage users and drive revenue. See a Logi demo

Tips + Tricks

Logi Tutorial: Using Conditional Branching to
Build Tic-Tac-Toe in Logi Info

By Michael Kujawski | July 19, 2019
Share on LinkedIn Tweet about this on Twitter Share on Facebook

As data-driven applications become increasingly complex every day, it’s necessary to build in smarter programmable checks into the system to help you add, audit, and update business rules over time. With Logi Info Studio’s new Procedure.Else and Procedure.Switch elements, you have the ability to easily create powerful and robust If, Then, Else statements. These conditional expressions help to build an easy-to-understand visual representation of your business rules, which can be easily changed and audited over time.

>> Related: How to Embed Dashboards with Logi Analytics [Tutorial] <<

These elements extend the power of the Process Task elements in Logi Info to notify users, upload data, change data, switch and set new values, and much more. To demonstrate how easy-to-use these elements are, I built a Tic-Tac-Toe game using Logi Info.

Tic-Tac-Toe is a 3×3 matrix represented in the form of a board. The rules are simple: the first player to have three consecutive markers placed next to one another wins. To show you how the new Procedure.Else and Procedure.Switch elements work, we’ll take a look at the Process Task elements used to create this game in Logi Info Studio.

The first step to building Tic-Tac-Toe is to model out the system interactions and what is required to build a robust system of checks and balances. We know that a series of eight different combinations on the board will result in a win. If neither of the two players are able to match any of these conditions, the game results in a stalemate or tie.

Logi’s conditional branching elements allow you to map out the entire Tic-Tac-Toe game in three, easy-to-understand Process Task branches—using these new conditional elements as the backbone. Here’s how I did it.

Building the Report Definition:

The first step is to create a game board where the player interactions can take place. In Tic-Tac-Toe, this requires a 3×3 matrix where each square has a unique value of 1 through 9. These values are known as a sqNumber parameter or the ID of the square. Using a Data Multi Column List element⁠—with its Multi-list Direction attribute set to Across⁠—produces a 3×3 matrix as shown below.

Now that we have a game board, we can create the Process Task elements required to play Tic-Tac-Toe. Note that this document does not cover building the report definition known as the game board, but the report definition, itself, does have many Note elements to help you fully understand the building blocks.

Creating the Process Task of X or O:

Whenever a player clicks on a square in the board, the first Process Task element to be called is the tXorO Task element. This task does two primary things: it checks which player clicked on a square and changes the player turn while also setting the square value.

This is built by using the following elements:

Procedure.Switch – This element retrieves the current players turn and passes that value into the child Procedure.Switch Case elements. Here, we are determining what player clicked on a square and then which Procedure.Switch Case element should be evaluated based on that value.

Each Procedure.Switch Case element is looking for a value of ‘1’ or ‘2’. If that value is found, then the next path is taken to determine which Procedure.If element should be executed. Each Procedure.If element is checking to see what sqNumber value was passed.

When the sqNumber value matches to the correct Procedure.If elements’ Expression attribute and creates a True statement, it updates the parameters for which player turn it currently is and the new value of that square as an X or O.

This Procedure.If element then calls on the next Process Task element, tSqCheck, which is where we check the status of all the squares and look for a possible winner.

You’ll notice a Procedure.Switch Else element at the bottom. If for some reason both Procedure.Switch Case elements do not find a player 1 or 2 value, this element will push the player back to the game board report definition with all the previous parameter values. As with all If, Else, Then statements and programing in general is to code for and protect for the unknown.

Creating the Process Task to Check for a Winner:

The next Process Task to build is called tSqCheck. This Task element checks for one of eight different ways in which the player can win for both X and O. Within Tic-Tac-Toe, the eight ways to win are:

Winning solutions are grouped together by the square in which we check for a win first. For example, the player can win by selecting the top three squares. Though, we know that it doesn’t matter in which order or direction those squares were selected. So we are only concerned about the first row and first column cells. One, two, three, four, and seven. These determine our groups and is used to guide us when creating the next step of our conditions.

In this Process Task, tSqCheck; we look for any winning grouping by using a Procedure.If element where the Expression attribute is the following simplified condition:

If (

(Square ID is equal to X)

AND

(Square ID is equal to X)

AND

(Square ID is equal to X)

)

Returns True

The same is run for O.

If this Procedure.If element evaluates to True, which it does in the above example, then it will run the appropriate Process Task element for the winner.

Building on this overview, we can see that for each winning group there is a separate Process.If element for X and O respectively. For instance, to win the top row the following Procedure.If elements’ Expression attribute needs to evaluate to True for X to win.

“@Request.sq1~”=”X” && “@Request.sq2~”=”X” && “@Request.sq3~”=”X”

If this is True, then the last Process Task element is called, tUpdateWinValueX or tUpdateWinValueO for player 2. Passed into this last Process Task element is a new parameter called winGroup where we pass in the group of squares that won. Following the example above, Group A won with the top row of boxes so we pass a value of A1.

In the event that all squares are filled with an X or O but no one is the winner the last Procedure.If element is used with the following Expression attribute:

“@Request.sq1~”!=”” && “@Request.sq2~”!=”” && “@Request.sq3~”!=”” && “@Request.sq4~”!=”” && “@Request.sq5~”!=”” && “@Request.sq6~”!=”” && “@Request.sq7~”!=”” && “@Request.sq8~”!=”” && “@Request.sq9~”!=””

This is merely checking that each square is not empty. Since this element is placed at the end of the element stack and no further win checks are made, this equates to a tie. The player is then returned to the game board with a new parameter ‘win’ set to ‘0’. This will be used in Conditional attributes of the report definitions’ elements to determine what to show in the case of a tie.

However, if not a single Procedure.If element evaluates to True then Procedure.Else element is triggered. This element takes all the currently selected square values and the player turn values and then returns the player to the game board. Unless there is a win or tie, this is the path most taken by the players so that the game can progress forward.

Our last Process Task elements, tUpdateWinValueX or tUpdateWinValueO, are used for some housekeeping and to update tracked wins. The Process Task used is dependent on the identified winner.

The Default Request Parameters element retrieves the Cookie value for xWins and updates by one. If no Cookie value is present, then it will be null + 1 which equals 1.

The Procedure Set Cookie Vars element sets the updated xWins value to the local players’ browsers cookie cache.

As this Process Task road comes to an end, we pass three new values to the report definition; ‘win’ to tell the Conditional attributes that a win occurred, ‘winGroup’ to state which squares were a part of the winning selection, and ‘winner’ to set the winner as player one or two so we know who won.

Mapping Out the Rules

Below you will find a flow of the steps which show the rules of Tic-Tac-Toe within a Logi Info Studio application (click to enlarge).

Final Thoughts

We outlined the Process Task elements that power a Tic-Tac-Toe game, but there is much more than can be done with this process element. I invite you to not only learn from this report definition but to also expand on it to further your Logi skills—you can add additional rules or combine the Process Task elements into a much more compact and streamlined statement. You might even find a whole new way to power your business rules.

Download the game files here and try it for yourself!

About the Author

Michael Kujawski is an Application Support Engineer with Logi Analytics. He has more than five years of experience helping customers tackle creative challenges in application development and production.

Subscribe to the latest articles, videos, and webinars from Logi.