We're continuing this ongoing saga of different game algorithms using the simple game Color Walk. In the last post we started exploring the fundamental graph search algorithms with breadth-first search (BFS), because after all, the full set of move choices and resulting board positions of any game can be arranged as a graph. After looking at BFS and finding that we can nominally improve the search for shortest number of moves, on average, it's time we look at the close sibling of BFS: depth-first search (DFS). We'll quickly run into performance issues just like we did for BFS, but let's see if we can come up with a reasonable way to limit DFS so that it can be a useful algorithm.

# Lucid Mesh

Musings on software development, technology, and their interconnections with a programmer's everyday life

### Explore Simple Game Algorithms with Color Walk: Part 7

We're continuing to explore different game algorithms using the simple game Color Walk. In the last post we took a deep dive into other heuristics that could be used instead of the obvious maximize-the-number-of-blocks-removed approach and found that the obvious choice is actually hard to beat. After looking at various heuristics, it's time we fill in some gaps in our exploration of algorithms by looking at a couple of fundamental graph algorithms: breadth-first search (BFS) and depth-first search (DFS). These algorithms are the two basic ways to search for something in a graph of nodes (or vertices) connected by edges, and a graph is exactly what we have when we draw out all possible move choices with each node representing a move and edges connecting sequential moves. We'll focus on BFS for this post.

### Explore Simple Game Algorithms with Color Walk: Part 6

What's next with exploring different game algorithms using the simple game Color Walk? We've come a long way so far with building out the game's interface to support looking at different algorithms, looking at trivial round-robin and random algorithms, and designing a greedy algorithm that picked each move based on the most blocks removed. The last post showed how far we could push the greedy algorithm to look ahead and try to pick a better move that would result in more blocks removed up to five moves ahead, but even after improving the data structure for the board, we hit diminishing returns in looking more moves ahead. It's time to expand our search for algorithms by looking at other heuristics we can use to pick the best move. The greedy algorithm used a heuristic of "the most blocks removed" for any given move, but there are others that we can use.

### Explore Simple Game Algorithms with Color Walk: Part 5

We're continuing to look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post covered our first foray into a non-trivial algorithm, namely the greedy algorithm. We found that using the strategy of grabbing the most blocks from the board on each move was a reasonable thing to try, and it outperformed all the previous trivial algorithms. Then we extended the greedy algorithm to look ahead one move and found that it performed even better. Now we're going to extend the greedy algorithm to look ahead arbitrarily far and see how far we can actually look before the run time of the algorithm becomes prohibitive. In this process we should be able to find a way to improve the current data structure of the board to make searching more efficient and allow the algorithm to search more moves ahead as a result.

### Explore Simple Game Algorithms with Color Walk: Part 4

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post showed how to add multiple algorithms and select between them, as well as exploring a random choice algorithm and an enhanced way to skip useless choices for both round-robin and random choice. This post will get into our first non-trivial algorithm, the greedy algorithm. Greedy algorithms don't care too much about the future. They will look at the choices immediately in front of them and try to pick the choice that will get them the most stuff right away. That's why they're called greedy, you see? In this case, the greedy algorithm will pick the color that will remove the most blocks on the next turn. Let's see how it stacks up to the trivial algorithms.

### Explore Simple Game Algorithms with Color Walk: Part 3

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post showed how to implement one of the simplest algorithms I could think of, round-robin, and how to develop some tooling around the game so that we can quickly run through multiple iterations in a batch mode and see statistics on the run. This post will start exploring some more algorithms, and we'll start needing to think about how to improve the algorithms so they aren't so naive.

### Explore Simple Game Algorithms with Color Walk: Part 2

In this series we are taking a look at different game algorithms using the simple game Color Walk as a sandbox for exploration and discovery. The last post was an introduction that described what Color Walk is, explained how to get it running on your own setup, and presented some brainstorming of possible algorithms to explore. This post will start digging into the simplest of those algorithms: round-robin, but first, we need to build up some tooling around the Color Walk JavaScript code to make it easier to test out our algorithms and benchmark their performance. We'll use the round-robin algorithm as a vehicle to help develop this tooling, so we have something to play with while getting the benchmark tooling up and running.

Subscribe to:
Posts (Atom)