Skip to content
CppCooperProgramming Portfolio
Selected projectProject year 2026

Word Search: Cheryl Engine 4 Port

A sequential trie solver with explicit occurrence rules, legacy and text puzzle loading, and an interface for selecting and revealing matches.

Version
Cheryl Engine 4 port
Status
Completed
Built with
C++, Cheryl Engine 4
My work
C++ solver, puzzle loader, and application interface
The case study

Project overview

The Cheryl Engine 4 version of Word Search pairs a new solver with a puzzle interface. It loads a grid and an answer list, finds occurrences in all eight directions, and lets the user select matches and reveal their cells. The solver uses a sequential trie scan, giving this version a different algorithm from the original threading exercise.

Word Search: puzzle to matches
The port’s solver is sequential. Its answer trie and occurrence records replace the original directional-string comparison model.

Following shared prefixes

The answer list becomes a trie: a tree in which each edge represents a letter. Words with the same beginning share that part of the tree. A scan starts at each puzzle cell and follows a straight line in each of the eight directions, advancing through the trie as it reads letters.

If the next letter has no edge, that scan stops. Reaching an answer node records a match, and scanning continues because the same prefix may lead to a longer answer. The result keeps the word, starting cell, and direction, which are enough to calculate its endpoint and highlighted cells.

The scan itself is sequential. Cheryl can run the application’s simulation on a worker thread, but that runtime option does not divide word comparisons among workers.

Defining an occurrence

A word can appear more than once, and two answers can overlap. Both cases remain in the result list. A palindrome read in opposite directions over the same cells counts once; a separate location counts as another occurrence. One-letter answers follow the same rule, avoiding eight copies of a match from the eight scan directions.

The interface lets the user move through those occurrences, reveal the selected match, or toggle all solutions. Rescanning clears the old selection and highlights. The puzzle and answer list have scrolling areas so navigation does not depend on fitting the whole input into one view.

Loading old and new puzzles

The loader accepts the original binary format: two dimension bytes, row-major letters, and a brace-enclosed answer list. A text format starts with WORDSEARCH width height, followed by the rows and answer list. Both forms normalize letters to uppercase and remove duplicate answers.

The text format makes small test puzzles easy to write and review. Input limits cap dimensions at 256 per axis and files at 2 MiB, with checks for malformed rows, invalid letters, and incomplete answer lists. A new sample supplies one word in each direction because the original instructor’s puzzle is unavailable.

Checking the search separately

The model tests compare trie results with an independent exhaustive scan on 32 generated puzzles. They also cover all directions, overlapping matches, palindromes, duplicate answers, empty results, both input formats, and selection/reveal resets. Keeping those checks outside the GUI makes the occurrence rules directly testable.

Cheryl handles startup, action input, the simulation lifecycle, retained rendering, and TGUI integration. The parser and search model remain independent of those services. The port is complete.

By Joshua Cooper Published Updated

Keep exploring

More projects

View the portfolio