8
votes
Day 24: Lobby Layout
Today's problem description: https://adventofcode.com/2020/day/24
Join the Tildes private leaderboard! You can do that on this page, by entering join code 730956-de85ce0c
.
Please post your solutions in your own top-level comment. Here's a template you can copy-paste into your comment to format it nicely, with the code collapsed by default inside an expandable section with syntax highlighting (you can replace python
with any of the "short names" listed in this page of supported languages):
<details>
<summary>Part 1</summary>
```python
Your code here.
```
</details>
I put today's success entirely on my memory of random game-dev blog articles I'd read in the past.
C#
Part 1
Part 2
Helper
Commentary
Red Blob Games has this article, which is pretty much the definitive source for how to implement hex-grids. I went with the Axial coordinate scheme, because it made finding neighboring tiles the easiest (and I didn't care about the visual representation or storage layout, because I was using a Dictionary anyway)
After the hex-grid stuff is done, I basically reused my code from Day 17 verbatim - as usual, just gotta reimplement the "find-neighbors" function and the criteria for toggling cells on or off. I was lazy with the bounds-checking and just expanded the board bounds on every step because I wasn't confident in determining whether new cells were actually pushing the bounds out. Part 2 runs in under 2s, so /shrug.
Python
Alright, anyone still doing these? I decided to come back and do at least this one, since hex grids sounded fun.
My first challenge was making sense of numbering a hex grid cell so I can compare where the directions lead. I found a great guide on dealing with hex grids and settled on "cube" coordinates, which seem to be the simplest for the directional input. I parsed the text input manually since I don't feel confident enough with regex stuff to detect potentially overlapping rules such as "nww" being interpreted as "nw", "w", "w" instead of "nw", "w". Maybe it would have been easy? Once this was implemented, part 1 was easy.
Part 2 was also fairly straight forward. I was just terribly afraid it could turn out to run for days and be an optimization exercise after all. So I spent about half the total calculation time implementing a time estimator based on the average run time increase per step. Turned out it takes about 16 minutes on my aging laptop, which is fine by me. I wonder how much you can optimize these things. You pretty much have to check for every single tile adjacent to a black tile.
Part 1+2
Python
Repo Link
Part 1
After reading the problem description, I realized that you could solve it by view the tiles as a sort of graph. The only problem is figuring out how to connect the tiles to each other. Initially, I started with a
Tile
class that had attributes for each direction (ie.e
,w
, etc.) but soon realized that this approach wouldn't work b/c it would be difficult to connect tiles together (ie. have them reference each other appropriately).Instead, after some thinking and drawing pictures (I literally used some pencils and colored pens to draw tiles), I realized that you can project the tiles onto a coordinate system where each direction is a particular offset. For instance,
w
would be(-1, -1)
ande
is(1, 1)
. Once I saw this, then the solution was straightforward: make a table of the tiles where the key is the coordinate and the value is the color. To make this table, I would just follow the "steps" in the input and if the location I ended up at was not in the table, then I set it to white, otherwise, I flipped the current value.Part 2 (diff)
The second part was similar to what we have done for the cellular automata / grid problems previously. In this case, for each round / day, I just found all possible tiles by looking at their neighbors and then counted the number of black tiles and then applied the specified rules to form the next table of tiles.
Rust
Pretty pleased with this one. The code came out pretty clean.
Rust