I Let The Perpetrator Escape - Help!
Abi
on 25 Nov 2025
Latest activity Reply by Matt Tearle
on 1 Dec 2025
Hi Creative Coders!
I've been working my way through the problem set (and enjoying all the references), but the final puzzle has me stumped. I've managed to get 16/20 of the test cases to the right answer, and the rest remain very unsolvable for my current algorithm. I know there's some kind of leap of logic I'm missing, but can't figure out quite what it is. Can any of you help?
What I've Done So Far
My current algorithm looks a bit like this. The code is doing its best to embody spaghetti at the moment, so I'll refrain from posting the whole thing to spare you all from trying to follow my thought processes.
Step 1: Go through all the turns and fill out tables of 'definitely', 'maybe', and 'clue' based on the information provided in a single run through the turns. This means that the case mentioned in the problem where information from future turns affecting previous turns does not matter yet. 'Definitely' information is for when I know a card must belong to a certain player (or to no-one). 'Maybe' starts off with all players in all cells, and when a player is found to not be able to have a card, their number is removed from the cell. Think of Sudoku notes where someone has helpfully gone through the grid and put every single possible number in each cell. 'Clue' contains information about which cards players were hinted about.
Example from test case 1:
definitelyTable =
6×3 table
G1 G2 G3
____________ ____________ ____________
{[ 0]} {0×0 double} {0×0 double}
{0×0 double} {[ -1]} {[ 1]}
{0×0 double} {[ 6]} {[ 0]}
{[ 3]} {[ 4]} {0×0 double}
{0×0 double} {[ 0]} {0×0 double}
{[ 5]} {[ 3]} {0×0 double}
maybeTable =
6×3 table
G1 G2 G3
_________ _______ _______
{[ 0]} {[2 5]} {[1 2]}
{[ 4]} {[ 0]} {[ 0]}
{[2 4 6]} {[ 0]} {[ 0]}
{[ 0]} {[ 0]} {[1 4]}
{[ 1 4]} {[ 0]} {[ 1]}
{[ 0]} {[ 0]} {[2 4]}
clueTable =
6×3 table
G1 G2 G3
____________ ____________ ____________
{0×0 double} {[ 5 6]} {[ 2 4]}
{[ 4 6]} {[ 4 6]} {0×0 double}
{[ 2 6]} {[ 5 6]} {0×0 double}
{0×0 double} {[ 4]} {[ 4 5 6]}
{[ 4]} {0×0 double} {[ 1 4 6]}
{[ 2 5]} {0×0 double} {[ 2 4 5 6]}
(-1 indicates the card is in the envelope. 0 indicates the card is commonly known.)
Step 2: While a solution has not yet been found, loop through all the turns again. This is the part where future turn info can now be fed back into previous turns, and where my sticky test cases loop forever. I've coded up each of the implementation tips from the problem statement for this stage.
Where It All Comes Undone
The problem is, for certain test cases (e.g., case 5), I reach a point where going through all turns yields no new information. I either end up with an either-or scenario, where the potential culprit card is one of two choices, or with so little information it doesn't look like there is anywhere left to turn.
I solved some of the either-or cases by adding a snippet that assumes one of the values and then tries to solve the problem based on that new information. If it can't solve it, then it tries the other option and goes round again. Unfortunately, however, this results in an infinite flip-flop for some cases as neither guess resolves the puzzle.
Essentially guessing the solution and following through to a logical inconsistency for however many combinations of players and cards sounds a) inefficient and b) not the way this was intended to be solved. Does anyone have any hints that might get me on track to solve this mystery?
11 Comments
Time Descending
That looks like a data structure you can work with. To simplify things further, you can put the knowledge about the envelope in the page assigned to your player (you know your own cards - no need to keep track of that). Follow these steps:
Eliminate all cards you know from the other players (incl. envelope) at the start.
While not all cards in the envelope known
For each hint
If result=-1, eliminate all cards from the answering player
If result>0, assign that card to the answering player and eliminate it for the others
If result=0 and from all cards being asked for exactly one is still 'maybe', assign that card to the answering player and eliminate it for the others
If exactly one card of a group remains 'maybe', it must be in the envelope (since the envelope contains all groups).
If the total number of assigned and 'maybe' cards of a player matches the required number of cards per player, assign all 'maybe' cards to that player and eliminate them for the others.
If a card is eliminated for all players and is neither in common cards nor in your cards, it must be in the envelope.
I finally managed to solve it! (Solution 14896745). Thank you for all your help; it made me realise I wasn't missing out any logic, I was just implementing it really poorly. There are a couple of fudges in my code, so there's probably still some bits to be improved, but I'm glad I managed to figure it out in the end.
My top tips for anyone attempting this problem themselves:
- Check your 'start known' matrix before you get into looping through the rounds where you don't get concrete information looks like it should. I ended up writing out all the players for tricky cases by hand and crossing it out myself to make sure my code was doing what I was expecting
- I followed Stefan's excellent advice about using the page assigned to my player for the envelope cards, but this meant when I was checking result=0 options I was forgetting to include a check for whether I held the card when determining whether I could exclude it. Make sure you're looking at both the cards you know in other players' hands, and your own!
- If there's still a logic fault, step through each of the turns in debug mode and write down the solution matrix for each player by hand. I spotted all of my bugs by noticing where my solve by hand did not line up with what my code was doing
- Don't be afraid to ask a duck. I may have asked a few too many, which led to all my internal confusion...
My solution is not particularly small or efficient, but I had a lot of fun with this problem (even if it had me tearing my hair out at times). Happy to try helping out anyone else who might be tripping up like I was :)
Very well done @Abi! Great responses and advice from everyone as well. Learning from so many other experienced coders is definitely one of my personal highlights of this contest. A few others have shared very useful advice and tips on solving this problem, such as @Athi from team Cool Coders, as well as @Dev Gupta and @David Hill from team Relentless Coders:
Solving Systematically The Clueless - Lord Ned in the Game Room (Also note that Athi's post was selected as the well-deserved article winner for Week 2)
It's also incredible to see how much the solution to this problem has been optimized over the past few weeks. @Stefan Abendroth's current leading solution is just 227 characters long, which is nothing short of amazing!
When I (perhaps more naively) solved it, I implemented 4 broad rules for the checking loop (which I now realise is a bit superfluous):
1) If a player has a card, no other player has it
2) If a player has ncards confirmed, they have no other cards
3) If (n - 1) cards in a category are located, the nth card is in the envelope
4) If a player has (3n - ncards) confirmed cards that they don't have, they must have the remaining unknown cards
Going back to the problem after seeing your thinking process and everyone's comments, it's interesting to see that many of the test cases can still converge with fewer rules, albeit often requiring more iterations. Specifically, all of the cases can eventually be solved without rule 2, or case 2 can either be solved by just rules 1 and 2 or rules 1 and 3 and so on.
Apart from all the brilliant discussions on the optimal structure of the knowledge matrix and other coding complexities, @Mohammad Aryayi from team Cool Coders has also expressed interest in playing the actual card game. I also share this sentiment as I've always enjoyed card games and I found the thought process and mechanics behind this one fascinating (props to @Matt Tearle for coming up with this), and I've put a pin on it to make a GUI game for it when I can get around it (another fun project down the line).
For now, I'm glad everyone else is also having fun and learning from each other during this contest.
"I'm glad everyone else is also having fun and learning from each other during this contest"
I'm loving the interaction, including this great discussion thread. I was intrigued by Abi's approach and was wondering if someone would help figure out a way to make it work. The different ways to tackle problems is fascinating to watch, as is, as Vasilis says, the way people can keep optimizing.
I'm glad I included this problem. I was a bit worried it was way more complex than many Cody problems. But it's currently the problem with the highest likes (but lowest number of solvers), so it seems you all like a challenge :)
And just to be clear: I didn't invent the game mechanic, just ported it over to the wacky world of Nedland. The :ahem: clue as to where I lifted it from is in the title. But apparently the basic structure goes back even earlier. (The fun things you learn when making silly Cody problems!)
Thank you @Vasilis Bellos
Update: I have started again from scratch and got up to 8/20 test cases passing. Fewer than I had with my spaghetti, but I think it's progress.
My knownCards is now a 3D matrix, where rows correspond to card number, columns are groups, and pages are player (@Stefan Abendroth, I think that's hopefully something along the lines of your suggestion?). I do a better job of setting up the hard truths at the start, filling in the confirmed cards players do or don't have, before going through all the cases where the player showed a card to someone else (and you don't know which).
I'm fairly confident I have:
- if number of 'yes' and 'maybe' cards is the total number a player should have, they own all those cards
- if all cards but one in a column have been assigned to a player, the remaining card is in the envelope
- if a player has all their cards, they cannot have any other cards
- for the 0 show case (shown card, you don't know which), I check the cards being asked against my knownCards matrix and eliminate ones that are already known. I skip over cards that I know are owned by the player being asked, since they could have shown that one. If there is only one card of which I don't already know the location, the player asked has that card
Annoyingly, there's an extra bit of logic that I'm missing since I rewrote that now loses me 8 test cases. Will have to come back to it tomorrow - any pointers to steps I might have missed always appreciated!
Abi,
The clue I overlooked at first is one that might be a little tricky to calculate from the way you've arranged your data, so maybe you've overlooked it too?
- Each player holds ncards cards. If you can identify 3n-ncards cards that a player definitely does not hold, then they must hold the remaining ncards cards. That is, if the no, yes, and maybe/unknown cards for a player are distributed such that there are ncards yes or maybe (and 3n-ncards no), then all the remaining maybes are yeses.
In your arrays above, for example, it looks like you know one of player 6's cards (G2 #3), and player 6 only appears once in your maybeTable. Since all the players have to have 2 cards, you can determine that player 6 must have card G1 #3.
I'm not sure I understand from your description how you're using the clueTable, but when you're going through the turns, remember to consider not just what was hinted, but also which cards were asked about together on the same turn. For example, if you know there was a turn where player 6 was asked about cards G1 #3, G2 #1, and G2 #6 and had one of them (but you don't know which one), and then you later determine someone else has cards G2 #3 and G3 #5, you can now say player 6 had G1 #3.
These are kind of just guesses, but maybe they'll give you some ideas to look into. It looks like you're off to a great start--I'm sure you'll get there!
-Abbey
Thanks for your comment!
I think I managed to implement the logic from your first point, which gave me a couple more of the solutions, but not all of them yet :(
I'm not actually using the clueTable at all, which is where I think I'm going wrong, but when I look at the clue table for the cases where I get stuck with no new information, I can't see what I'm supposed to do with that information to figure it out.
Back at it again today, will see if I can get further :)
Hi Abi,
you don't need any guessing for the test cases provided. Make sure to draw all possible conclusions from the knowledge you collected. Think about elimination of options.
Also consider putting all your knowledge in one place (one matrix or tensor), so you can take advantage of MATLABs powerful matrix operations.
Have fun learning and coding -
Stefan
Thanks for confirming I don't need the guessing - I knew once I got to that stage that I was missing something vital!
I think it must be to do with the fact that I haven't really utilised my clue table to eliminate any options. It might be time to try and condense all the information into a single matrix and attempt to simplify things.
Hey, congratulations for tackling this tricky problem.
As was earlier highlighted, considering the number of cards a player DOES NOT HAVE is as important as counting how many we definitely know they DO HAVE.
Then there is information about how many cards in each category have their location KNOWN versus UNKNOWN (i.e. nobody has them or maybe someone has).
And writing those conditions can be confusing, depending on how you decided to encode the information.
Maybe the logic you arranged is good but you just have a simple bug.
Hope that helps.
Good luck with solving and lots of fun!
Sign in to participate
