Skip to content

glennfu/hexiomsolver

Repository files navigation

Hexiom Solver
=============

This is an attempt to write a solver for the game 'Hexiom' which can be found here:
http://www.kongregate.com/games/Moonkey/hexiom


To run
======
ruby hexiom.rb


Optional arguments
==================

To select the level, do:
-l #{level number}

To choose which 'tried tracker' to use, do:
-t #{true | false}

To show the before/after states of the board (verbose mode), do:
-v

To show the all recorded board states, do:
-w


Example 1
=========

ruby hexiom.rb -l 11 -t false

 Level 11, Using Hash
 Solution found
 Took: 12.352264, recorded 9261 tries
add_tried        0.0998789999999931
area_is_valid    2.14741799999996
flat             3.6891719999998
is_valid?        1.05271600000002
solved?          0.004008
tried_include    0.117846999999976

Example 2
=========

ruby hexiom.rb -n 3 -t true

 Level 2, Using Tree
 Solution found
 Took: 0.033264, recorded 32 tries
add_tried        0.003053
area_is_valid    0.007756
flat             0.000784
is_valid?        0.003354
solved?          0.000328
tried_include    0.00222


Current Status
==============

Levels 2, 3, 5, 6, 11 are fairly quick (all under 13 sec) and worth trying for testing.

Levels 26, 30, 36 are ones I would love for it to solve, but currently aren't solved by the code.
They fill up all memory (swap too) before finding a solution.  However I haven't tested them since the addition of the HippyTree class which I built in hopes to help with the memory problem.


TODO
====

 - Skip looking at NO_SPACE (9) since it never moves and doesn't need to be considered
   - Possibly Try turning NO_SPACE (9) into nil so that the stored strings don't include them at all.  They shouldn't be needed there.
   - Or in the HippyTree, skip over it when you reach a 9 instead of adding it in
 - Make the 'ranked_options' method smarter
 - Apply more logic to 'lock in' pieces that we know need to be placed
 - Review the outputs more to try to find better optimizations.  When the code goes through billions of similar combinations, I'm sure many can be cut out.  When I solve games I'm certainly not considering that many solutions.  What logic does a human apply that the code currently does not use?


Hexiom-Solver 1
===============
Running:
ruby hexiom-solver-1.rb
will run an old version of the code.  I've kept it around for reference's sake, although the current versions, both with HippyTree and HippyHash, should be superior in every way by now.



Interacting with the app while running
======================================
ctrl-c (interrupt) will kill the app and print out the current status of the board, like:
^CInterrupted, here's how what I got so far:
 Took: 0.704699, recorded 575 tries
add_tried        0.109009
....

ctrl-z will print out the current status of the board without killing the app, like:
^ZCurrent state:
 Took: 0.895112, recorded 701 tries
add_tried        0.129265
....


Copyright (c) 2008 GlennFu, LLC

About

solver for the puzzle game Hexiom

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages