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.
| 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) |
| 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. |
| 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. |