# Run a game of Flood

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

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.

• We must be able to handle non-square boards, but what about non-rectangular ones? – orlp Mar 19 '17 at 6:08
• @orlp - no need to deal with non-rectangular boards. – Glen O Mar 19 '17 at 6:10
• Also I just I just noticed the part about the output message. "it must be clear to any English speaker using the code without requiring separate documentation" is clearly not objective and makes it possible to make answers comparable. Is yes good enough, is y? Is win? Is w? 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. – Martin Ender Mar 19 '17 at 12:32
• After reading this interesting challenge, I am disappointed with the subjective output format and scoring. If those were changed to be the standard boolean output rules, and standard golf scoring (or at least something that could be scored by an automated and objective script), then I would consider writing an answer. – Patrick Roberts Mar 19 '17 at 16:52
• Nothing about anyone's constructive criticism of this challenge was as childish as calling it that, and then complaining that your challenge wasn't well-received since you didn't follow the recommended standards that the community agreed on for a reason. And as for the output format, I'm sure most if not all of the community would back me up in saying that it's not difficult to just say "output a truthy value if the simulation runs to completion." It's not that difficult to make sense of. – Patrick Roberts Mar 20 '17 at 5:15

# Octave, 68649492 83 bytes

a=f(a,s)m=a;for k=s;[~,x]=bwfill(a~=k&m,1,1,4);m(x)=0;a(x)=k;end;~m&&puts("win\n");


A function that takes as input a matrix a and a vector s as the sequence of commands and outputs the final state of the board.

Explanation:

function a=Flood(a,s)
m=a;
for k=s
[~,x]=bwfill(a~=k&m,1,1,4);
m(x)=0;
a(x)=k;
end
~m&&puts("Game Completed\n");
end


Usage:

num_colors = 4;
a = randi(num_colors, 5 ,7)
s = randi(num_colors, 1 , 15);
Flood(a,s)


Use m as a mask representing the filled region so far. Repeatedly run commands and flood fill the masked grid from the top left corner.

• Nice, using a function that performs a fill as though the array were an image. I suspected some languages might be able to do that. Pleased to see it happen with one of the languages I know well. – Glen O Mar 19 '17 at 12:19
• I've made it a little clearer regarding output options. Feel free to reduce the output message to win (unless Octave has a nice way to output something like clear or done, or another such message). – Glen O Mar 20 '17 at 4:37
• Thank you for reading comments and making the challenge "a little" clearer! – rahnema1 Mar 20 '17 at 4:50