Flood game implementation
Overall, it's not bad. I only have some minor observations on the code itself:


You're setting, and re-setting @top in both the constructor and reset.
SIZE isn't used for anything.
Why does reset call flood? As far as I can tell, there's no need at all.
Doesn't seem like decreaseLimit has a point.
You could postfix a couple of if/unless statements and cut down on indentation.
in _flood the if i &lt; 0 or j &lt; 0 or i == DIMENSION or j == DIMENSION check could be written as:

return unless 0 &lt;= i &lt; DIMENSION and 0 &lt;= j &lt; DIMENSION


or you could simply skip it in favor of trying the coordinates and checking afterward:

square = @grid[i]?[j]
return unless square?

When looping through the @grid (in reset and hasWon) there's no need to use a [0...DIMENSION] range. You can just use regular CoffeeScript for...in loops:

for row in @grid
  for square in row
    # do something with square...

The IIFE at the end could be written more idiomatically using the do keyword

do ($ = jQuery, Game) -&gt;
  ...



Structurally, I have a few notes:


You inject both the Game object and a td element into Square, so Square doesn't really have that much to do. In fact, the first thing it does is set an event listener on the element that the game object created, and set it to call back to the game object. It just seems a roundabout way to set things up.
I'd probably move the td creation to Square.
You pass a tbody element to the Game constructor, which is nice. But Game also directly accesses #count and #counter-user. So it's not really decoupled from the markup at all.
Somewhat similarly: You pass in jQuery as $ in the IIFE that kicks things off. That's a perfectly good pattern. However, Game just uses $ "raw". So you're sort of half-way following the pattern.


Here's a (simplified) refactored version, just for fun.