THINGS I LEARNED FROM TBT

Making a turn based strategy game had always been one of my dreams ever since I played Final Fantasy Tactics on the PSP back in 2007. So when the opportunity came up to work on a Passion Project as part of the VFS curriculum, making Turn Based Titans was one of my top choices.

From an educational standpoint, this was perfect because I had never touched on Artificial Intelligence before. In fact, I was intimidated by it because it had the word Intelligence in it! But as an aspiring programmer now, I cannot turn away from intellectual challenges, and so this served as a simple entry point to AI.

STATE MACHINES WITH PROPERTIES & INHERITANCE

The game has several different states

1. Waiting State (Default)

2. Unit Selected State

3. Pre-Game State (beginning of the game)

4. AI Turn State

Each State is a class that inherits from a Base State which provides virtual functions to determine what happens when you selected, deselected, highlighted, and dehighlighted a unit (or tile).

Swapping between states is done in a GameManager class that controls most things in the game. In the class is a property that holds the current state.

Once you set the state, it runs the OnStateExit() function of the previous state, which does a bunch of things like resetting the color of all the units, or changing the UI, etc.

Then it runs OnStateEnter() of the new state. The difference between this and Constructors is just different call orders.

To change states we just use the new keyword to construct a new state.

States are needed to determine what the player can see and do in different situations.

For example, you can't select your units when it is the enemy's turn. State Machines are a broad subject so I will only talk about implementation.

A* PATHFINDING

One of the best decisions I made for TBT was to keep it simple; every tile has the same movement cost, no changes to tiles, and no elevation. This is made it easy to learn the basics of pathfinding.

Each turn, the units are given a target destination to move towards, so it made the most sense to use A* algorithm because we don't need to find all the possible locations. To learn about the algorithm itself, I had to first understand Heap Priority Queues and Weighted Graphs.

The algorithm takes a graph as an input. A graph is a set of nodes with their connections to each other. These connections can have a weight to them which can help determine movement costs. It's easier to visualize the graph as a set of invisible waypoints overlapped on top of the grid floor.

The Priority Queue is for 2 main things

Enqueue tiles with their Priority values so that we can determine their movement costs.
Dequeues a tile as the front item by percolating down a binary tree. We bring it out in order to do the value comparison with neighboor tiles.

http://aigamedev.com/open/tutorial/symmetry-in-pathfinding/

http://www.redblobgames.com/pathfinding/a-star/introduction.html

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

http://www.gamasutra.com/blogs/JakobRasmussen/20160427/271188/Are_Behavior_Trees_a_Thing_of_the_Past.php

http://www.gamasutra.com/view/feature/129959/designing_ai_algorithms_for_.php?page=3

By grabbing these nodes from the graph and accessing them with a Queue to do value comparisons, it is now possible to determine which tiles are important enough to be put into the final path output (in the form of a List). I would definitely, absolutely, 100% not be able to implement this code as a junior level programmer. I used Crooked Head's implementation and read up on the concept afterwards to make sure I understand everything. The only difference between his implementation and this one is that he uses a 2D Dictionary for the graph edges.

In addition to the above links, this introduction to A* was immensely useful:

http://www.redblobgames.com/pathfinding/a-star/introduction.html

Utility AI is used most popularly in The Sims. The computer will choose an action for each character based on their needs, which are visually shown on the UI.

UTILITY AI

For TBT, since we are in a battle, it wouldn't make sense to have a bladder variable to determine actions :).

Instead, the conditions are based on things like health, position, and type advantage.

Below is the Utility AI table I used to design the AI.

Each Action on the left is a class. For each action, if the conditions are met on the battlefield, it adds a score to that action. The action that accumulates the most score is the action to be executed. This logic is done on each AI unit in a loop.

Writing the Utility AI was the absolute most fun thing in this project. I am also proud of the fact that I coded it all from scratch without third party frameworks :)

The Sims' Needs chart.

Weighted Graphs

Priority Queue

Inserting into a queue

So, these were the top things I learned and the most crucial elements to the game.

In terms of project management, Turn Based Titans is the most well structured and well paced project I have ever worked on by far.

Granted, it was a solo project. However there were so many unknowns before I started, coupled with having to do all the art myself, the game was actually overscoped. In the end, stuff had to be cut and I would say the finished product is about 90% of what I wanted it to be.

If I had to redo it, I would spend less time on the UI. There is that 80/20 rule where 80% of your outcomes come from 20% of your inputs, and the UI is DEFINITELY the remaining 20% outcome.

In the end, this game satisfied my desire to make something like FF Tactics, for sure.

Thanks for reading, hope it wasn't too dry :)

FINAL THOUGHTS

THINGS I LEARNED FROM TBT

Making a turn based strategy game had always been one of my dreams ever since I played Final Fantasy Tactics on the PSP back in 2007. So when the opportunity came up to work on a Passion Project as part of the VFS curriculum, making Turn Based Titans was one of my top choices.

STATE MACHINES WITH PROPERTIES & INHERITANCE

The game has several different states

1. Waiting State (Default)

2. Unit Selected State

3. Pre-Game State (beginning of the game)

4. AI Turn State

​

Each State is a class that inherits from a Base State which provides virtual functions to determine what happens when you selected, deselected, highlighted, and dehighlighted a unit (or tile).

Swapping between states is done in a GameManager class that controls most things in the game. In the class is a property that holds the current state.

Once you set the state, it runs the OnStateExit() function of the previous state, which does a bunch of things like resetting the color of all the units, or changing the UI, etc.

Then it runs OnStateEnter() of the new state. The difference between this and Constructors is just different call orders.

To change states we just use the new keyword to construct a new state.

States are needed to determine what the player can see and do in different situations.

For example, you can't select your units when it is the enemy's turn. State Machines are a broad subject so I will only talk about implementation.

A* PATHFINDING

One of the best decisions I made for TBT was to keep it simple; every tile has the same movement cost, no changes to tiles, and no elevation. This is made it easy to learn the basics of pathfinding.

​

Each turn, the units are given a target destination to move towards, so it made the most sense to use A* algorithm because we don't need to find all the possible locations. To learn about the algorithm itself, I had to first understand Heap Priority Queues and Weighted Graphs.

The algorithm takes a graph as an input. A graph is a set of nodes with their connections to each other. These connections can have a weight to them which can help determine movement costs. It's easier to visualize the graph as a set of invisible waypoints overlapped on top of the grid floor.

The Priority Queue is for 2 main things

Enqueue tiles with their Priority values so that we can determine their movement costs.

Dequeues a tile as the front item by percolating down a binary tree. We bring it out in order to do the value comparison with neighboor tiles.

FURTHER READING:

http://aigamedev.com/open/tutorial/symmetry-in-pathfinding/

http://www.redblobgames.com/pathfinding/a-star/introduction.html

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/

http://www.gamasutra.com/blogs/JakobRasmussen/20160427/271188/Are_Behavior_Trees_a_Thing_of_the_Past.php

http://www.gamasutra.com/view/feature/129959/designing_ai_algorithms_for_.php?page=3

​

In addition to the above links, this introduction to A* was immensely useful:

http://www.redblobgames.com/pathfinding/a-star/introduction.html

Utility AI is used most popularly in The Sims. The computer will choose an action for each character based on their needs, which are visually shown on the UI.

UTILITY AI

For TBT, since we are in a battle, it wouldn't make sense to have a bladder variable to determine actions :).

Instead, the conditions are based on things like health, position, and type advantage.

Below is the Utility AI table I used to design the AI.

Each Action on the left is a class. For each action, if the conditions are met on the battlefield, it adds a score to that action. The action that accumulates the most score is the action to be executed. This logic is done on each AI unit in a loop.

Writing the Utility AI was the absolute most fun thing in this project. I am also proud of the fact that I coded it all from scratch without third party frameworks :)

The Sims' Needs chart.

Weighted Graphs

Priority Queue

Inserting into a queue

So, these were the top things I learned and the most crucial elements to the game.

​

In terms of project management, Turn Based Titans is the most well structured and well paced project I have ever worked on by far.

Granted, it was a solo project. However there were so many unknowns before I started, coupled with having to do all the art myself, the game was actually overscoped. In the end, stuff had to be cut and I would say the finished product is about 90% of what I wanted it to be.

​

If I had to redo it, I would spend less time on the UI. There is that 80/20 rule where 80% of your outcomes come from 20% of your inputs, and the UI is DEFINITELY the remaining 20% outcome.

​

In the end, this game satisfied my desire to make something like FF Tactics, for sure.

Thanks for reading, hope it wasn't too dry :)

​

​

​

FINAL THOUGHTS