Just here for screenshots. DO NOT RESOLVE!

This is a quick code review as of commit 1e899a1, before singleplayer went in. Hope it might be helpful.

• The code is nicely straightforward. That said, I'd be tempted to implement the game more as data, probably stored in a JSON file or something, and have the code be more generic. There's a lot of println!() that seems hard to edit and maintain; separate text would also allow translations. I can see why this would be more than one might want to do for a learning exercise, though.

• In the same vein, the fixed 120-column text formatting was a problem for me, who uses an 80-character terminal partly out of habit and partly out of poor vision. Having the text auto-wrapped would be nice.

• I think it would be better to use a Vec than an array for the sections and sub_sections. That way you don't have to carry around a separate constant for the length and could make the section lengths vary if desired. Rust arrays in general are kind of a niche data structure, and should only be used if you have a specific need for what they provide.

• I would give the last_result tuple its own struct type:

    struct LastRound {
        result: RoundResult,
        part_found: Option<usize>,
    }
  

  That would make the code clearer in my opinion. In general, use Option instead of sentinel values in Rust.

• Rather than implementing GameState::Default as a call to GameState::new(), you might just want to put the new() code into the Default() implementation and omit the new() method altogether.

• If you felt like being functional programmy, you could implement GameState::trap_exists() as

    self.sections.iter().any(|s| s.trapped)
  

  Similar things could be done for some of the other looping code in the game.

• I'm not sure about the check at the start of GameState::play(). I think this should be an assertion rather than an error return, and the input checking code should ensure that nobody goes out of bounds.

• The main gameplay loop in play() is clean and well-documented.

• My personal preference is to put data structures like game_state::RoundResult at the top of the file for easy reference. YMMV.

• There's some repetition left in killer_user::play_killer() and victim_user::play_victim() to be factored out.

• Not sure the section.rs and sub_section.rs code need to be in separate files.

• I have submitted a pull request to remove the unnecessary Rc<RefCell> instances for the AI.