The Logelium consists of a set of programs, scripts and graphic elements that interact more ore less smartly. The set of modules is intended to reduce functional redundancy as well as trying to keep the critical core algorithm as small as possible. The core is designed for efficiently calculating puzzle solutions. Even more important is the simple extensibility in a way that does not endanger other puzzle features. The architecture allows most extensions without touching the kernel by adding configuration files related to the new puzzle.

This chapter gives a brief overview of the Logelium components. This is of course not enough to fully understand how it works, which would require a book of its own right. My intention is rather to show some interesting results than to give lectures about programming technique, boring for most people on the planet.

The architecture of the Logelium is extremely modular and supports currently about one hundred puzzle types. There is a static part that contains the basic definitions of each puzzle with its grid and tiles. Related to these definitions you can define forms to solve with the tiles. The kernel algorithm reads the corresponding definition files into memory and solves the puzzle. The resulting solutions are stored in a text file and will be post processed by a graphic generator to produce visible solution pictures.



Descriptions of Module and Relations:

Grid Definition

For each Logelium puzzle family there is a common grid definition, which is made manually in most of the cases. The Pentomino e.g. is part of the family Mino, that contains all puzzles with squares. The grid definition keeps all properties which are common to all family members.

Tile Generator

The tile definition requires most of the work when creating a new puzzle. Besides the tile definition tables one ore more Visio master shapes for the graphic generator will be constructed. The tile generator is a very important tool for tile definition, its not used in the solving phase.

Tile Definition

The tile definition refers to exactly one grid definition and describes formally all properties of all tiles of a puzzle set. For each puzzle exists one tile definition file and one or more sets of graphic shapes. Creating tile definitions manually is only possible for very simple puzzles. I use some ad-hoc Perl scripts to generate the definition lists that can be quite complex.

Form Definition

The form definition is the actual problem statement and refers to exactly one tile definition of a puzzle. The form to solve is stored in a text file along with additional parameters. The syntax is pretty simple. (Example)
The number and selection of tiles can be changed and additional directions for the graphics generator are possible.
Of course this procedure is not really comfortable. An interactive user interface is still barely missing. So there is a lot of work waiting, if time is plenty.

Solution Kernel

The kernel is a console program. This keeps the program independent from any system environment. It produces a text file with the solution list and a log file. The kernel supports breadth first features to support parallel computation or partial tree search. A number of alternative solver variants are available.
An important function is the limitation of the recursion depth. This produces an intermediate result file, which can be used with subsequent program runs. This way a parallel processing can be managed.

Solution List

The solution list is a text file related to a form definition containing an abstract description of the solutions found and the form outline. (Example)

Graphics Generator

To produce visible graphics out of the solution list there is another Perl script. It uses only the corresponding Visio master shapes to convert the solutions and does not need any tile definition information (Example PDF). Optional output is SVG source code.
Because solution data and graphics definition are separated, we can easily produce different styles and shapes of graphics based on the same solutions.