This is a Code Golf challenge.
Flood is a game in which the player is presented with a game board such as this:
On each turn, you choose a colour (on the link above, by clicking a square containing that colour), and the cell in the top-left corner is filled with that colour - this colour will absorb all adjacent cells with the same colour. So, for example, the first turn might be Blue, which will cause the yellow cell in the top corner to turn blue, and merge with the existing blue cell. The next turn might be Purple, which will fill both of the first two cells purple, merging them with the two-cell purple area attached to them. Then you might go Red, then Orange. With this sequence, the board will end up as:
Your task is to write a code that simulates the game, taking in an array or other data format containing the current state of the game, in a suitable format (picture, numbers in a square array, string with numbers indicating the dimensions, anything that can be identified with the game), along with one or more input commands (colours, cells that contain colours, etc - your choice of how to implement the sequence, but you need to explain it).
If (and only if) the input solves the board (causes all cells to be the same colour), then your code should print a message in some format informing the player that the board is cleared or completed. It is up to you how this is done, but it must be clear to any English speaker using the code without requiring separate documentation (so outputting "1" isn't good enough). Note that displaying a completed board is not sufficient.
Some example options for completion output include win
, done
, complete
, or clear
. If your language doesn't have a nice way to output a longer message, I recommend using win
.
Whether the input solves the board or not, the code should output (either as function output or as a displayed output) the final state of the board.
The code may take input of moves interactively (from STDIN, to simulate the actual game) or as a code input.
Scoring
Your goal is to minimise the number of bytes in the function or code.
Rules and Assumptions
Standard Loopholes are forbidden.
Code must be able to handle non-square boards, with each dimension being anywhere between 6 and 30 cells (more is fine, it must handle this range). It must be able to handle between 3 and 9 distinct colours or "colour" labels (numbers are fine).
You may assume that input is in simplest form - that is, if there are four colours, they will be labelled 1-4, or a-d, or any other similar system as appropriate. You will not need to handle situations such as incorrect inputs, unsimplified inputs (you won't have the numbers 1, 3, 6, and 9, without the others in between, unless it suits your code).
Your answer should include a description of formats, etc.
Request: If you believe you have identified a non-standard loophole, and it's definitely a loophole and not in the spirit of the question, please comment to have the loophole closed, rather than posting an answer using it. This is not a rule, per se, but an effort to keep the challenge interesting.
yes
good enough, isy
? Iswin
? Isw
? And I agree with rahnema that having to output a readable string there adds absolutely nothing interesting to the challenge and potentially having to compress the string if it's long distracts from the main challenge of implementing the game. \$\endgroup\$ – Martin Ender Mar 19 '17 at 12:32