New Exercise Proposal: Mazy Mice

Hi everyone,

I’m excited to share that I’ve submitted a pull request for a new practice exercise called “Mazy Mice”!

This exercise challenges students to generate “perfect” mazes with a single solution path, using box-drawing characters for the output. It involves algorithm design for maze generation and handling seeded randomness.

I’ve included a canonical-data.json file with various test cases, including specific maze outputs for given seeds and error handling.

You can find the pull request here

I’d love to get your feedback on the exercise description, instructions, and the canonical data. Please let me know if you have any thoughts or suggestions!

Thanks,
Jegors

1 Like

@ErikSchierboom his commentary on the PR already covers mine.

I like it! I think this is a great exercise to implement.

1 Like

I’m away for a bit, but I’ll try and review soon-ish.

1 Like

Hi @ErikSchierboom,

Thanks for the heads-up, no rush at all!

While Mazy Mice is on your mind for a future review, I wanted to raise a point that’s come up: how best to accommodate different implementation approaches across tracks. Specifically, for some languages, it might be more idiomatic for students to return a data structure (e.g., List[List[CellType]] in Scala) rather than a fully formatted string maze. This would allow them to focus on the generation logic itself.

For instance, a Scala 3 approach might look something like this:

// Enum representing elements in the maze's character grid
// (Illustrative: a full version would include all specific wall/corner/T-junction types)
enum MazeElement:
  case PATH_SPACE      // e.g., ' '
  case WALL_HORIZONTAL // e.g., '─'
  case WALL_VERTICAL   // e.g., '│'
  case WALL_CORNER_TL  // Top-Left corner, e.g., '┌'
  // ... other specific wall types like WALL_CORNER_TR, WALL_T_LEFT, etc.
  case ENTRANCE        // Represents the entrance marker
  case EXIT            // Represents the exit marker

// Function signature for generating the maze structure
// 'rows' and 'cols' are for the room grid; output grid is (2*rows+1) x (2*cols+1)
def generateMaze(rows: Int, cols: Int, seed: Option[Int] = None): List[List[MazeElement]] = {
  // ... logic to return the structured maze ...
  ???
}

(A complete MazeElement enum would detail all components corresponding to the box-drawing characters and path/entry/exit points, allowing a track to map these to characters if needed or test the structure directly.)

My main questions, when you have a moment to consider, are:

  1. Should the canonical description.md somehow acknowledge that some tracks might expect a data structure return, even though the description itself will visually showcase the string representation?
  2. Would it be useful to include hints or guidelines for track maintainers on adapting the exercise for a data structure approach (e.g., suggestions for Enum design, how property-based tests apply)? Our current canonical-data.json is property-based and seems compatible.

This also relates to the ongoing thought about ensuring the visual examples in description.md are as robust as possible (e.g., using > for the entrance/exit arrows). Even if some tracks don’t output strings, the description.md is the primary visual reference for the maze’s structure and components.

It’s worth noting that, if I recall correctly, the use of UTF-8 didn’t work very well in the awk track until the locale settings in the Docket container got updated. There is potential for UTF-8 not working “out of the box” on other tracks.

1 Like

On Java track it works out of the box :slight_smile:

Most modern languages have first class UTF support :slightly_smiling_face: Some tracks might have trouble with UTF, though.

2 Likes

Batch, Cairo, and probably the assembly languages would have some level of difficulty, but I think it’ll be mostly fine. Batch could swap out UTF-8 for similar ASCII characters. Cairo could do a two-dimensional array of enum variants as well. Both could be surfaced in instructions appends.

1 Like