Color Flood commentary

As stated on the main page, I started to think about this game after first playing the game "Zen loops" and later "Colorshift". Although Colorshift is mostly more advanced than Zen loops, one thing that it lacks is empty tiles, which can be useful for deducing how tiles are oriented. In any case, I've always liked hexes as a plane-filling regular polygon over squares, so I decided to use those.

Design decisions

Sorry, this is pretty much random rambling, as I didn't write really any notes while developing the game. That being said...
Most of my coding has been done with C or C++, and Javascript is similar enough that I just went with checking the differences when troubles came up. The provided Array figures heavily in the code; on the other hand, since objects can't be encapsulated as easily, I didn't bother with using them very strictly. With more planning, I might've gone more with the usual Model-View-Controller architecture, but since the browser does away with all the compiling, I just jumped in in a semi-Agile manner. The Tile object maybe does a bit too much work, but I think the functions are separated well enough, so it's not too bad. Implementing non-square wrapping did take some thinking through, and in general, the whole hex-based thing was a big reason that I went for just passing through the whole Tiles array in so many places rather than some two-dimensional approach like I might've used with squares.

Layout algorithms

Source-sink pairs

The current algorithm works by first creating source-sink pairs with a path between them, then connecting some paths to each other, then twisting those straight lines, and finally branching out to fill the empty spaces. It should be reasonably easy to think out other algorithms (though implementing them might take a bit longer).

Layout algorithm rules

Some basic rules layout algorithms should follow; these apply to the "solved" layout. The terms aren't quite as strict as with RFCs, but reasonably close approximations. A "route" is the line from the center of a tile to it's edge. An "area" means a bunch of connected routes; the area where a color spreads.

Sinks must have only one route into them; sinks that have more than one route will probably exhibit strange behaviour.
Each source should have at least one route out of it, and each area should have at least one sink. An area may have no sinks, but this does not lead to meaningful gameplay, and should thus be avoided if easily possible; the same applies to sources that have no routes out of them. Each route out of a source should spread its color into a different area.
Tiles with only one route should be either sources or sinks; carriers should have at least two routes.
The algorithm may create areas that receive color components from more than one source, and it is suggested that it attempts to do so, as this makes for better gameplay. An area that has only one color component should not have multiple sources. An area that has multiple color components may be connected to more than one source of the same color component, though this should be avoided if easily possible; this is mainly as it may be confusing to figure out which source of the same color component is affecting a particular tile.

Future ideas

Color fixing

When all are at the usual maximum value for RGB (255, or FF), blue is a lot darker than green and red is somewhat darker. Fixing this is possible, but probably not that easy. Still, it's the most likely thing I might work on. I might add some general parameters for user at the same time, dunno.

More efficient flooding

Improved flood calculation: first "flood" from changed tile to find sources, then flood only from those sources, since other areas are unaffected. This efficiency only really matters with size > 15 and enough sources.
(Suggested by Codez.)

Changelog

1.01: Better color distance to RGB values algorithm.
1.02: Slight tweaks to drawing stuff, added cutoff so that distant sources don't affect color correctness.
1.03: Now needs to get all routes correct, changed cutoff to avoid sudden hue changes, enlargened tile click areas, improved source and sink drawing on large sizes.
1.04: Added white dots to distinguish sources better. Layout algorithm slightly changed. Large boards should now be pretty playable, though the natural limits of too much stuff in too few pixels still exist.
1.05: A few small fixes to wrapping mode.
1.06: Exact sink requirements shown with middle mouse button, reverse movement possible. (Also, mouse Y coordinates should now work with Chrome, Explorer and other browsers than Firefox... sorry.)
1.07: Changed "Stop" button to "Pause" (might be useful on hand-helds?) and added the "Oops" button that allows to fix one mistake in normal mode.
1.08: Added cookies to remember the settings.
1.09: The "I" key will now give some information about the board tile distributions.