Ooh, I’m late to this. Thanks @ThePurificator for opening the topic!
All in all, I had a great time. I really appreciated seeing something speed-based back in the limelight, and the puzzle theming was a nice idea.
Well, in a way I couldn’t care less about the theming, but it didn’t get in the way. Yay!
It seems like I performed just a bit too casual to qualify for a T-shirt (eating, chatting on XMPP and going to the toilet—what was I thinking!) but I’ve decided not to hate myself forever just because of that.
IIRC I skipped straight from I/O-puzzle-based contests to multis, so I’m not quite sure how much of this was new with regard to the solo-based contests. Please correct me when I’m wrong.
In this specific case where the puzzles are closely related, I appreciated the non-binding submit and the ability to switch back and forth between levels. Those two features weren’t obvious to me at all at first, be it from the interface or the pre-contest communication material. I didn’t even discover the puzzle selection buttons until mid-level 2! But they were definitely useful later on, if only to recover the previous code and work from it instead of screaming in despair and starting from scratch as we’d have done with the previous format.
This all goes in the right direction in giving us more time management leeway, and that’s very good.
I’m quite a bit more reserved about the fact the contest consisted solely in very minor variations on the same puzzle.
This was a big disappointment. That viewer was utterly useless. Worse, it took a lot of screen space, had its usual painful focus-attracting effect on test, for next to zero benefit. As in: just coloring and displaying the referee agent I/Os would have been better.
More generally: the viewer concept can be useful to show what happens. Transversely, its playback buttons can be useful to navigate the referee interactions in a turn-based game. (in all honesty, with the current interface I think they’re the only way to navigate the interactions.)
But no part of this contest was turn-based at all. It appeared like it could have been; it probably would have helped us to make it so; but in its released state it isn’t.
So we’re left with a graphical representation of a 2D square grid. ASCII would have been fine. Our code features a lot of movement along that grid, but the viewer doesn’t reflect that. All it tells us is where our answer was correct and where it wasn’t (I think—honestly, each time I tried looking at it I got a bit more confused, so in the end I stopped altogether) and it does it in one of the most confusing ways possible: top-down animation of the cells. It’s not the “top-down” part that’s confusing, it’s the part where it doesn’t follow the arrow, sorry, detective Pikaptcha’s movement at all.
The viewer could actually have been a great help in understanding, let alone debugging, the more contrived movement cases (hello Möbius!) But no, all I could get from it was laggy zooming and panning.
I initially wrote this thinking the referee mechanism made sense. That’s because I’m biased and would need it for some other stuff of mine. But it made me realize this entire contest would have been perfectly acceptable as I/O puzzles: static cases, single valid answer and no need for a viewer.
Shoehorning the unadapted solo game interface was a bad fit.
PS: So I tried it again while writing this up, and I actually saw Pikaptcha move around in a way that’s useful to understanding. Was this broken during the contest?! Or is the feature’s discoverability suboptimal? (Or is this user too stupid to use the platform?)
A small word on topology
Let’s address the elephant in the room right now: the infamous Möbius trainwreck.
I won’t delve again in whether we’re talking about an authentic strip or an open-ended twisty N-dimensional torus or anything weirder; let’s just assume the casual CodinGamer never heard about Möbius and won’t have time to DuckDuckGo or attend a topology course before the end of the contest.
[The level 3 map] is a surface with only one side and only one edge.
Knowing Möbius strips: ok, this checks out.
Not knowing them: in 2D (which was the context until now), a surface is usually considered as having only one side, so no surprise there. “Only one edge” feels weirder. Is that because we’re now considering all sides, sorry, ‘all four straight sections of the boundary’ as a single edge? Or because now only one of them is still impassable?
A reminder from level 1 is absent here:
The maze is enclosed in impassable rocks that are not included in the data.
Ok, so later on this is ‘clarified’:
Pikaptcha can step over the edge of the Möbius strip and continue his wall-following path on the same one and only side of the strip but at a different position.
I can understand it’s hard to tell us (with a straight face) that we have to step to the other side of a single side. But that might have been slightly less confusing than “continuing on the same side”, which gives a much more stable impression that crossing the edge is a no-op. Yes, “but at a different position”, but it’s not given! Not here at least.
So the only place we have something resembling a description of the edge-teleport is in the flawed paper-Möbius-HOWTO near the beginning. Flawed?
“Print the first half (along the x-axis) of the grid.”
I’ll assume the X axis is horizontal even though it’s said nowhere. But still, what do you call the first half along the X-axis? My paper strip that finally worked is an interpretation as ‘the top half’.
But an interpretation that would make quite a bit of mathematical and English sense would be ‘the left half’, as it’s the half with the lower X-axis values. It would happen to also make a lot sense in that it connects the strip left-to-right, which is a very usual interpretation indeed.
What happens if one of the axes is odd-sized?
Pretty drastic consequences on multiple topics, but not a word about it.
“Flip the paper over vertically.”
Mostly the same issue, though this one was closer to recovering me. What [I assume] was expected: flip the paper over by holding it in your stationary left and right hands. If this were an image editor, I might actually understand vertical flipping as meaning to exchange the top and bottom edges. But this is a piece of paper in a 3D world, so I can conceive of rotating it 180° around an axis—the horizontal one—or flipping it like a book page, which happens to reach a vertical state halfway through.
(The rest is standard Möbius.)
This is a special case of something that happens all too often in the community puzzle moderation queue: this is a description of ‘how the author did it’, not of ‘what is [expected] in general’.
So we’re in a good 20/20 hindsight situation: once you know what has been expected all along, all the information does happen to be there. But it’s kind of impossible to call it unambiguous: it’s strewn about, and each place is mildly inconsistent with the others, so we don’t know which to prioritize.
(In my case: my mind rejected the initially correct interpretation of the paper procedure because of the impossible odd size dimension case. Then I hit the no-op situation and went with the ‘it’s equivalent to no edge’ interpretation. As many, I ended up reverse-engineering the “Circle” test case to pass. And crossing my fingers that no validator had an odd-dimension case, because THAT’S STILL NOT FSCK’N SPECIFIED!)
What could have made it better? Here are two options:
- It’s one-sided? Own it! Give the input as the single side.
- Paper procedure? Own it! Give us the faces to print before twisting. One might argue that’s the case already, but no, don’t make us guess them, give them with the same representation as level 4’s six faces!
- (and don’t play on words with the edge pass)
So in the end, ‘twisted torus’ is what describes it best to me. Like, better than any kind of variant of a Möbius strip: passing over the edge negates there being an edge at all. I like the parallelogram roll interpretation a lot, but don’t think it would be appropriate as a puzzle statement.
Too bad for the pictures, but they’re merely photos of a Möbius strip with a Pikaptcha map on it. They unfortunately wouldn’t have disambiguated the actual problem. (And, as mentioned above, the viewer ironically could have.)
The rest of the statement(s) was nice. I suppose the story’s interesting to someone who’s into that.
The algorithm was a good fit. Wall-following is interesting in general, good for us that it simplified given the input format.
Interesting idea to adjust the topology with subsequent levels. I’ve got a few ideas for possible extensions…
If you intend to publish, please consider updating:
- In the level 1 statement (only), the map is described as made of 0s and #s. On CodinGame we usually have . and #. It makes perfect sense for consistency with the other levels that it’s a zero, but please disambiguate it from letter O!
- “You must analyze the given grid and return it with a small transformation”: this is fine in level 1 and kind of fine in level 2. For levels 3 and 4, it’s only a transformation between the input and the output, not compared to level 2; so it’s a bit confusing: I recall reading it in level 3 and wondering what the change to the output format was this time.
Thanks CG for bringing back speed contests! Give us more!
Thanks a lot @java_coffee_cup for a cool way to spend that Saturday afternoon!