Day 12 done.

I really didn't like this one. Basically have to do some bounds checking "it obviously always works" or "it obviously will never work" on it to get it to work on the actual input, but it still NEVER FINISHES on the example. I'm slightly bothered that the problem is more or less unsolvable as written, but I'm really bothered by the actual solution for the input not working on the example. That's not a fun puzzle, that feels like I'm being tricked, like the puzzle was a prank on me. Leaves a real sour taste, especially being the last puzzle of this year's AoC.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day12 #Day12 #Rust #RustLang #Programming #CodingChallenges #AoC #AoC2025 #AoC2025Day12

Day 11 done.

Memoization actually worked for this one. My first instinct was to just crawl the graph with a memo, and it fortunately did the right thing. It was effectively an exhaustive depth-first search. Really not much to discuss.

My code is not nice or clean, but after yesterday's, I can't even be assed to clean it up or properly comment it. I barely gathered the gumption to pass errors up, and when I started writing it, I was just throwing unwrap() everywhere.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day11 #Day11 #Rust #RustLang #Programming #CodingChallenges

Just finished #MetroidPrime4 with 100% scans. It was ok, but I really didn't like it all that much on the whole. I was really looking forward to this game, and like most things I'm excited about, I didn't look into it at all; I wanted to come in fresh. But I ended up being very disappointed.

Positives

• The game looks great. Vivid atmospheres, decent (if bog-standard) biomes. It doesn't break any barriers or look a hell of a lot better than the average Switch game, but the art direction is solid.
• The controls are really smooth and responsive when you get used to them. I turned off the free aim lock setting entirely so that I can always free aim while locked on, and I thought it was the best that a Metroid game has ever controlled.
• The music is really good. Definitely holds up against the rest of the series. Even while the game was frustrating me, I was still loving the soundtrack.
• Save stations also recharge ammo. I think I'd prefer separate ammo stations, because this is a touch too generous, but it beats the opposite extreme of the game wasting my time by forcing me to farm ammo.
• When you go back to a previous area to collect items you missed and don't have a companion, or a waypoint, or some other part of the game walling you into a specific path, it actually feels like a Metroid game and is pretty fun.

Negatives

• The plot. run-of-the-mill "Chosen One" prophecy story mixed with a "we scienced ourselves to death" plot. A mostly uninspired grab-bag of cliches.
• The tutorial section of the game is way too long. Like several hours long. It's not really over until you're out of Volt Forge, and the bike tutorial section was like pulling teeth.
• Annoying companions. And I'm not talking just about Mackenzie's Joss Whedon dialogue, but the nature of companions in a Metroid game in general. Constantly chattering, "Don't go that way, go this way instead", getting knocked out and needing to be healed. I legitimately like the sense of isolation and desolation in a Metroid game, and they seriously trashed the atmosphere. And that's before you get into the marines all fanboying over Samus and asking for her autograph. The Metroid series definitely does not benefit from full voice acting.
• The desert. Big, mostly empty, with some Breath of the Wild shrines. I don't get the point. They could have easily just connected the areas together directly and dropped the desert entirely and it would have been a strict improvement.
• Hand-holding on rails gameplay. It's virtually impossible to get lost or go the wrong way. The worst offender was at the volcano, where in a cutscene you are informed of the next 5 destinations in order, which doesn't matter because the game doesn't let you move on from one location until you've finished it, and then it shuttles you (literally) to the next goal. This is the closest Metroid has ever been to being a simple corridor shooter.
• Tons of cutscenes with some really unimaginative direction. I lost count of the number of times a cutscene ends with Samus just pointing her gun at the screen. Having Samus not talk in them is awkward, because all the other characters talk to her, even asking her questions, and she just stares blankly back at them.
• Lack of creativity around powerups in general. All the beams are more or less the same ones from the first Prime, but with different names and they take ammo. Almost all the powerups and abilities are also the same as before, but with the word "Psychic" as a prefix and little to no other differences (other than needing the purple boots to walk on purple platforms). I got déjà vu with the majority of the puzzles.
• Padding. Every extra shot chip needs to be brought back to Miles. You have to gather all the green crystals, which takes forever. You have to collect all of the mech parts. This isn't just ordinary backtracking like in a Metroid game. This is forced padding like the Zelda Wind Waker triforce fetch quest (which I actually appreciated to some degree, because I liked exploring the ocean), but elevated to a ludicrous degree.
• Amiibo-paywalled content.

To be fair, maybe the well has run a little dry, and there's only so much you can do with the formula. They did decently with Prime 2, mixing it up with the light and dark worlds. Prime 4 just feels like the most formulaic aspects of Metroid, with a big empty desert and companions that detract from the experience. It reminds me of a typical third person shooter from 20 years ago in a Metroid coat of paint and a hub world. Maybe I was set up for disappointment by having just recently finished #HollowKnight #Silksong, which is a legitimate masterpiece.

Definitely not worth the wait. I'm definitely not going to play hard mode; I probably won't ever replay the game at all.

#Metroid #Nintendo #NintendoSwitch #MetroidPrime4 #MetroidPrime4Beyond #GameReview #GameReviews #MetroidPrime #hollowknightsilksong

Day 9 done.

This one was really hard for me. Part 1 wasn't bad at all; I could basically use the entirety of what I did yesterday for it.

Part 2 was really hard. At first, I tried actually building a HashSet of all the red and green tiles, and then a HashSet of all the areas for each pair, and checking them against each other. Needless to say, that wouldn't work. Building the tile HashSet alone would have eaten up more memory than I have on my computer, and I should have realized that immediately looking at my answer to part 1 (which was an area of over 4 billion tiles). I thought that checking a line of green tiles through the area wouldn't necessarily work, because a malicious input could make that not work (two immediate right or left turns could make a pair of adjacent green tile lines that would still work), but it turns out that it works fine for my input. Probably all inputs.

It works. I don't feel totally satisfied with the solution, but it works.

I think a more robust solution could be to trace the outline and fill it with square area units, then for each area to test (ordered from largest to smallest), repeatedly cut area out of it with the green tile squares. If all overlapping areas are tested and there are still un-cut squares, the area is invalid; move on to the next. If the area is cut completely to nothing, then it is the best area. I'm not going to implement this, because it sounds like a total fiddly pain, but I would be interested in seeing somebody else's solution along these lines.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day9 #AdventOfCode2025Day09 #Day9 #Day09 #Rust #RustLang #Programming #CodingChallenges

Day 7 done.

Typical "don't even try brute-forcing it" part 2. I kept track of the timeline count as I worked my way vertically down the graph, and then added up the beams' shared timelines at the end. I also considered that dynamic programming with a recursive solution would probably have worked fine as well, but went for the approach that most matched the way I was already doing it.

I'll probably follow up with the dynamic programming approach, just for fun.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day7 #AdventOfCode2025Day07 #Day7 #Day07 #Rust #RustLang #Programming #CodingChallenges

Day 6 done.

This was a funky one. Pretty easy for part 1. Just trimming, splitting, and parsing all the numbers and operators and grouping them columnwise. Nothing too hard.

Part 2 was awkward. I always am a bit flustered when I have to go back and parse the input differently, especially because I build things around FromStr in Rust, so I have to do either a Part2Input for the second part or a separate parsing function. This one was fiddly because I tried to parse it into the same Input structure as before, but that didn't work because not all the equations had the same quantity of numbers this time. I also wanted to do some sort of zip that let me zip over an iterator of iterators, but I couldn't find a good way of zipping a dynamic number of iterators, even in itertools (it has multizip, but that only works on a compiletime number of iterators). In the end, I needed to do this awkward loop:

number_buffer.clear();
for number_line_iterator in &mut number_line_iterators {
    match number_line_iterator.next() {
        Some(digit) => number_buffer.push(digit),
        None => {
            equations.push(Equation {
                numbers: numbers,
                operator: operators.next().unwrap(),
            });
            break 'outer;
        }
    }
}

Not the prettiest, but it did get the job done.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day6 #AdventOfCode2025Day06 #Day6 #Day06 #Rust #RustLang #Programming #codingchallenges

Day 5 done. Now this one was the easiest one so far. I was shocked at how simple part 2 was. Just combining all overlapping ranges and doing some simple arithmetic. I initially tried a linear search, and it finished in 1.5ms. Then I switched to a binary search, and now it finishes in 1.7ms. Do not underestimate the power of the processor cache line. If the fresh ranges list were much larger, the binary search would have sped it up, I'm sure.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day5 #AdventOfCode2025Day05 #Day5 #Day05 #Rust #RustLang #Programming #codingchallenges

Day 4 done. This was probably the easiest one so far, but it might be because I'm so used to the grid problems from previous years.

I felt like just doing the count for part 1 would end up forcing me to rewrite something, so I returned the coordinates, hoping they'd come in handy for part 2. Fortunately, they did, and my part 2 was a 10-second addition, just adding a loop around the part 1 function. The whole thing runs in about 86 milliseconds. I could probably optimize it by storing a neighbor count in each live cell, decrementing those in accessible neighbors on each removal, and maybe keeping them in a sorted vector via Rc<RefCell> or an internal Cell, but I'm happy with this right now.

Edit: I ended up doing the optimization anyway

This runs in 10ms now. It might even run a bit faster if I make the rolls keep track of their neighbors with weak refs too, to prevent lots of extra neighbor lookups in the HashSet. I'll experiment with that a tiny bit, but I'm not going to spend all too much effort on it, and probably won't add an update unless it is a big speed boost.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day4 #AdventOfCode2025Day04 #Day4 #Day04 #Rust #RustLang #Programming #codingchallenges

Day 3 done. This one was pretty easy.

My part 1 solution mostly generalized to part 2, but I ended up having to rewrite the whole function anyway because I didn't make it flexible enough. For part 1 I initially just scanned for the max digit in the whole line except for the right-most digit, then found the max digit to the right of that.

For part 2, I effectively generalized it, but had to calculate how many digits I was allowed to find the max in, and loop over each number of digits I still needed to keep room for. A little fiddly, but not too hard at all. I'm kind of curious if doing it arithmetically using a bigint would be faster or slower. My gut says that it would probably be slower, and just save a little bit of memory.

#AdventOfCode #AdventOfCode2025 #AdventOfCode2025Day3 #AdventOfCode2025Day03 #Day3 #Day03 #Rust #RustLang #Programming #Coding