I've fixed tests in Ruby instead of description

Very cool kata! After finishing the Encode method in like half an hour I thought it was rated too easy but Decode is definitely way harder.

I still don't understand what exactly you mean by "ambiguous" then. In the fifth good example you can turn left or right when you get to the first cross, how is that not ambiguous?

You say the first it false because it's ambiguous because you can go the long way or the short way but the short way does not satisfy the rule "Every line "character" found in the grid must be part of the line. If extras are found then the line is not valid." Am I missing something here? This one should be true based on my understanding

Would be nice if the C# tests used a char[][] as an argument so I didn't have to reimplement Preloaded.MakeGrid. Other than that awesome kata!

where is your logic in this? have u ever played chess?
pawns only move foward
the only condition for them to move diagonally they have to capture an enemy Piece

or did the autor of the kata do mistakes?

I'm confused, is

a = [2; 2; 3]
b = [4; 9; 9]

supposed to return true or false?

Agreed, I think 4 would be fair if you didn't have to take into account mountains in a ring stopping water from flooding the interior plain

Test case a6,g5 says expected 1, this is wrong unless the knight is allowed to wrap around the board. Is the knight allowed to "wrap around" from the a file to the g/h file? In that case it should be called out in the problem statement.

This was a great kata, I really enjoyed it! I think the description should clarify that a square does not need to be occupied for a capture to be valid though.

There should be a test where a variable gets reassigned a new value. There was a bug in my code and it still passed all the tests

Usually mathematical expressions like this are calculated left to right so it would be 2 * 3 = 6

Fair point. I added a couple more crossing examples. Thanks for feedback

Great kata, super fun and creative! My only nitpick is that it's not stated explicitly that a diagonal piece of track can leave a "+" intersection though. I know it's in the example given, but it should be called out in the track types above.

I'm pretty sure it's the same in